なぜIT業界は炎上案件を生み出すのか
大規模案件では割と炎上案件が起こりえます。
最近ではグリコの製造関連システムがカットオーバー時に問題を起こして実際に工場が稼働できない事態が起きています。
なぜこんな事が起こりえるのでしょうか。
プロジェクトが炎上する理由は様々ですが、基本的には無理な工程や開発環境がリスクの温床になっているケースが多いのです。
筆者は今までに多くの炎上案件を経験してきました。
その中で比較的、炎上になりにくいのが小規模案件です。
これも様々な理由があり、プロジェクトの参画者のノウハウなどが低ければ炎上します。
プロジェクトの詳細については守秘義務がありますので開示する事はできませんが、プロジェクトの炎上ケースには一定の傾向が存在します。
■開発に必要なライセンスをケチるとロクな事が起きない
これは一般的に共通して言える事です。
例えばMicroSoft系で言えばImputManという入力コンポーネントツールがあります。
「コンポーネントの仕様が限られているし、大層な機能は必要ないから独自実装してしまえ」
これで炎上してしまったプロジェクトが実際にあります。
もっと言及するならば原因はそれだけでは無いのですが、コンポーネントを作成したと思っても実際に実装してみて画面設計やイベント周りの作りなどの都合で想定しなかったコンポーネントバグが発生した場合、下手すると利用した画面規模分の再テストが都度発生してしまいます。
これだけで甚大な浪費時間が発生してしまうのです。
独自コンポーネントの作成は小さい積み重ねの実績が無いプロジェクトで採用すると失敗します。
常にコンポーネントの実装や改変や追加を独自にやってきた企業こそが発揮できるコスト削減手法です。
OracleDevelopperという開発ツールもあります。
このツールは小規模で単純な画面構成であればそれなりのコストパフォーマンスを実現できます。
しかし、これが大規模開発になると悲惨です。
そもそも開発言語ツールであるにも関わらず、以下の問題を抱える事になります。
●バッチ処理以外はステップデバックが事実上できない
●画面コンパイルには簡易コンパイルも存在するが、最終的にはフルコンパイルしなければ真面目に動くか分からない
●画面は少しの設定ミスで動いた様に見えて実際には挙動が不規則に変わったりすることがある
画面開発でステップデバック出来ないのは致命傷です。
本当に単純な画面なら良いのですが、少しでも複雑な画面を作って意図しない挙動が発生すると原因を調べる為にログ出力の記述を至る所につけていかなくてはなりません。
そうしている内、予算都合で安価な開発ツールを利用してサックと終わる筈が、高価な開発ツール（ライセンス料）より何十倍もの人件費投入をしながらマゾな労力環境が発生してしまい、結果として泥沼化するという悲惨な状況が起こりえます。
おぉ神よ、アーメン・・・
では、何でこんなアホな選択をしたのか？
という話になるのですが、薄利商売などでそんなに大きくは利益を確保出来ていないエンドユーザからすると「交渉されても予算が出せない」これでSier側が折れて受けてしまうのが現実なのです。
25年前は開発ツールと言えばVisualstudioが主流でJavaの開発ツールも真面目に動く環境ではありませんでした。
今ではJAVAの開発環境は無償でフレームワークも無償になっているものがありますので今となっては特殊事例になるかもしれません。
しかし、JAVAやPHPやpythonといった言語が増えて無償の環境も充実したからといって安易に踏み込むとバージョンの組み合わせなどが引き金になって痛い目に遭います。
特に帳票ツールは高価なものが多く、安価な帳票を使う場合は独自実装の枠が増えるのが現実です。
そして、最大のリスクは経費を削減しようとして安価なものを組み合わせた結果、意図しない挙動が起きた時にサポートが無ければ自力で解決していく必要があり、この調査コストにも時間と人件費を食い潰す結果になりえます。
実績のある開発ツールの組み合わせを前提で進めなければ思わぬ所ではまってしまう可能性があります。
■エンドユーザは予算をウォーターフォールで要求するが、納品に向けての仕様はアジャイルで要求されてしまうパターンが多い
実は殆どの場合、エンドユーザにヒアリングして仕様書まで作って了承を得ていながら、開発が進んで土壇場の所で仕様変更を要求されるパターンが普通にあります。
エンドユーザからすれば、高い額を払っているんだから「これくらいやってよ」というのが現実なのです。
予算がブレてしまうとエンドユーザは経理の都合で困るので予算を確定してしまいたいのです。
だから設計もウォーターフォール型になってしまうのです。
実はこれを受けてしまったが為に、蓋を開けてみればビックリ仰天物の影響範囲だったケースもあります。
要望・ヒアリングを受けて再設計や開発を途中からやってしまった都合で別の個所も辻褄が合わない等の理由で修正が必要になったり、ひっきり無しに納品直前まで変更・修正を加えてしまう。
特に大規模開発でこういった事例はよく発生するのですが、大規模開発の多くが赤字になる理由は開発規模に比例して細部の仕様まで重箱の隅をつつくまで熟知はできない（開発が終わった後になって実態を理解するパターンが殆ど）という現実があります。
規模が小さい場合、確認する範囲も限定されるので影響も比較的少ないのですが、規模に比例してエスカレーションする時間も長くなり、調査結果を纏めて判断するまでにも時間を要します。
大規模案件で重要なのは必要以上の機能を実装はしないのが正解です。
これはエンドユーザが納得するかどうかに掛かっていますが、必要最低限以上の実装を行った結果、複雑怪奇な仕様を作って墓穴を掘っているプロジェクトが幾つもあります。
その様なプロジェクトは結果として保守フェイズでバグを改修しながら運用する事になり、結果として品質が悪く満足度の得られないシステムになってしまう可能性があります。
必要最低限の機能に限定した後、フェイズを分けて後付け開発するといった方向を取れば無理な納期で開発しなければならない状態も抑えられます。
これはSierの営業センスや交渉力、エンドユーザが納得して貰えるかに掛かっていますので、確実性の無い手法なのですが少しでも無理を感じる規模なら提案してみる価値はあるでしょう。
少なくとも今までに良好なお付き合いのあるユーザなら了承して貰える可能性があります。
■設計書は先に書いてしまわないと下流の工程は円滑に進まない
多くのプロジェクトでは設計書を書き切ってしまう事が通常の慣習です。
何故なら実装工程に遅れが発生した時のリスク回避としてオフショアを利用する選択ができなくなるからです。
とにかく急いで物だけでも作るといった状況ならば、オフショアの力を借りる事も選択の一つになりますが、設計書が無ければ仮に受注して貰えたとしても全く信頼性の無いものが納品されるだけです。
とあるプロジェクトで1画面毎に設計書と開発とテストをペアにした方が効率が良いという話で各チームが右に習って動きました。
元々、余裕の無かったプロジェクトが3カ月後、突然アンビリバボーな発言を参画者全員が耳にします。
このままだと納期に間に合わないのでオフショアに発注する必要があるのに設計書が無い！どういう事か？
お察しの通り、設計書を全部作っていたのならプロジェクト統括の指示を無視した事になるので設計書が存在するなんてありえない話です。
凡人の我々にはこの難局を乗り越える為のエスパーを召喚する事はできませんでした。
結果は設計書を今更、全部作って発注するにも時間が無いので基本的にオフショアは諦める結果になりました。
体制は変わらず、設計・開発・テストをセットにしましたが設計書は、ダミーに近いレベルです、こういう状況のプロジェクトって真面目に書いてもどうせ後で仕様が大きく変わってしまうのですから・・・そして仕様が変わる毎にテーブルの仕様も勝手に書き換わってしまい、都度動かなくなるので開発が終わった筈のものを何度もテストする羽目になるのでした。
■大規模案件のシステムリプレイス、焼き直し案件は現行の作りを変えてはいけない
筆者がなぜ、こんな事を断言できるかと言うと大規模案件のシステムの定番は凡そ、仕様が複雑怪奇になっているからです。
現行にバグを持っているケースもありますし、デスロジックが残っている事も普通にあります。
これを綺麗に整理しようとすれば時間が幾らあっても足りません。
特に金融系のプロジェクトでは、ほぼ定番になっていますが現行のロジックから移行する場合は明確な理由が無い限り、下手にロジックを改変しないのが正しいです。
何故なら現行システムの結果と製造しているシステムを動かした結果の比較と妥当性の検証が出来ないからです。
ロジックを下手に変えてしまうとイレギュラーケースが発生した時に何処に問題があるのか疑う箇所が増えて特定が難しくなり、必要以上の労力を費やす結果になります。
バグやデスロジックを削除するのは保守の観点から見れば必要ですが、開発の段階で纏めてやってしまうと新旧比較が本当に出来ないので、根拠の提示要素が無くなってしまいます。
現行の結果から推測した結果を元に妥当かどうかを確認する事は出来ますが、確認する為には想定されるシナリオパターンを全て用意し、予測される結果も計算しなければなりません。
そこから想定外の結果が出た場合、原因を突き止める労力までかかってしまいます。
■類似した思想の画面を違う人が設計したりレビューしてしまうとレビューも製造工数も保守性も当然悪くなる
当たり前の様に思えるのですが、規模が小さい場合は見える範囲も正確なので融通が利きやすいでしょう。
規模に比例して画面やバッチの本数も増えるのですから当然、似たような作りになる画面やバッチも出てきます。
所が規模に比例してそんな細部まで確認して割り振り出来るような事は稀です。
本当は類似した画面はレビュアやレビュイを限定した方が良いですが、実際にはそうもいかないケースの方が多いです。
しかし、この段階で潰しておかなければ製造工程で設計通りに作った後に結合や総合テストで改修して再テストを行う必要が出てきます。
見逃した場合、将来的な保守性の問題やバグを発生させるリスクを増やします。
稀にレビュアが言語特有の考え方を理解していない場合、理解していない実装を推奨して設計に落としこんでしまう事があります。
理由はレビュアが理解している範疇でしかチェック・担保できないからです。具体的に言えばレビュアがCOBOL経験者でJAVAの実装経験が無く詳細設計をレビュしてしまうと良いか悪いかは別として、COBOLの考え方に寄った設計になってしまいます。
これもケースバイケースで現行システムに習う方向なら敢えて言語特有の考え方よりも現行に近い設計・実装の方が望ましいでしょう。
本来ならば類似画面が複数存在する場合、特にレビュアの担当割り振りを考えた方が良いかと思いますが、難しい場合はシステムの全体像をある程度把握している人がレビュー後の設計書をチェックする様にした方が良いでしょう。これも実際にはそれだけの余裕を持っている人は現実的に難し
いかもしれません。
方法は大きく2つありますが、何れも情報共有が必要です。
情報共有が無かった場合、あらぬ方向に進んでしまう可能性があります。
●設計段階で手の空いている人が全体をチェックして類似する設計を複数見つけた場合は共通化ないし、相当する方向を検討する
（見つけた場合、情報共有して他に類似機能がないか確認するなど）
●設計段階で巻き取れない場合は実装段階で類似機能を先に実装されたものをベースに共通化へ倒す様に検討する
（但し、このやり方はGitなどに開発された最新ソースが常に上がっている状態で参画者全員が上がっているソースを常に確認している体制でなければ難しいでしょう。）
■不明瞭な設計を放置するとツケの規模は肥大化する
規模の大きい開発は特に他業種連携のインターフェースなどが決まりにくい傾向にあります。
システム連携で各システムが別々の企業が受託している場合、自分達の作業が手一杯で情報共有は殆どされません。
結果としてズルズルになってしまう傾向が良くあります。
企業間の内、どちらかがアクションを起こさない限り、進展はまずありません。
もう一つは既存システムが稼働している場合、参入した開発側は色々な嫌がらせをを受ける事が多くあります。
テーブルデータの仕様や組み込んだ仕様に関する部分やソースの開示を渋ったりする事はよくあります。
特にデータ移行に関する部分は既存システムを保守している企業から開示して貰えても実際には食い違っている事はよくあります。
筆者の経験上、原因は以下のケースが考えられます。
●仕様書が常に更新されているとは限らない
●2世代前のシステムで稼働していたデータを残している（ゴミデータだがシステム設計の思想を変える事が多い理由でリスクを回避する為に敢えて移行できなかったデータを残したが資料には残していない）
●単純にバグが存在していた
その都合で本来予定していた納期に間に合わず、プロジェクトが破綻するように妨害するような商売をするのはソフトもそうですが周辺で扱う機器搬入を行う業者も同様です。
妨害してしまった方が短期的な収益を考えると既存システムの業者側に契約が継続される訳ですから破綻してしまえば一定期間内は契約延長によって安泰するのです。（このようなケースは大抵がエンドユーザと現行システムの納入業者が不穏な関係にある事が多く、エンドユーザ側が考える納入業者の印象は更に悪くなりますが。）
設計が不明瞭な部分は絶対に潰しておく必要があります。
何故なら、確定していない理由で放置を続けると放置した時間分だけ納品の期限に近づく訳ですから対策できないリスクを増大させる結果となります。
大規模開発で赤字を生む原因は凡そ、複数に跨るケースの方が多いのですが、「大きい枠で何のデータをどのように保存し連携しなければならないか」という所をしっかり掴んでおかなければ連携データの内容も定まる事もありません。
不明瞭な中でも「これだけは絶対に必要」とする項目ないし処理は存在するのですから、その核となるものだけでも先に確定してしまい、後から肉付けをしていく形でもよいでしょう。
特にデータの連携に関する部分は不明瞭だから、手戻りが嫌だからと動かなかった場合、そこから何も進展はないです。
設計段階で不明瞭な部分を残したまま開発を始めると、不明瞭な部分は凡そ開発保留になります。
その保留をしていた部分が思わぬ所でシステム全体に関わる様な仕様だった場合、システム全体のフロントやバックの処理、テーブル定義やデータの受け渡しを全て見直すコストが発生してしまいます。
■赤字支出は経理上の問題で土壇場にならない限り、一般的には承認が下りない
一般的に多くの企業は炎上状態にならない限り、人員投入や残業をさせる事はありません。
理由は無駄なコストを削減する為です。
所がIT業界の中でも設計枠でこの考え方を大規模開発に充てると多くの場合は失敗を生みます。
設計と実装に時間を割り当てる比率を間違えると実装工程で悲惨な状況を生みます。
しかし、多くのプロジェクトはざっくり設計と実装が半分くらいの比率で考えているケースが多く、結果として余裕が無ければテストの時間工数は軽視されます。
テストシナリオや単体・結合で発生した改修に割り当てる時間が十分に割り当てられなかった場合、自動的にカットオーバーした後に改修しながら運用しなくてはなりません。
こういった状況の多くは品質が担保されないまま納品に至ってしまうのです。
最も、設計に時間を掛けてしまえば済むという問題でもありません。
実際に設計に7割以上の時間を費やしてプロジェクトが炎上したケースも筆者は経験しています。
そういったケースで問題となったのは以下です。
●エンドユーザが捕まらないので折衝が出来ない（仕様が不明瞭のまま2年以上も放置）
※不明瞭になった温床は業務知識が特殊で理解が難しい
●他システムの連携も含まれていて、連携仕様もわからない
こういった状況のプロジェクトは残念ですが確実に大赤字です。
結果として、受託した会社が倒産するかどうかの話まで来てようやく、スポットで大量募集する方向に向きます。
その経緯に至るまでの事務処理には色んな理由を説明し、責任所在まで明らかにして上長の承認まで得る必要が出るため、誰かが首になる様な覚悟が必要になります。
ですから、少し不穏な状況だからといって予防措置として簡単に人員を増やしたり残業をさせるという事が出来ないケースも多いのです。
これは大規模開発特有の事例の様に感じます。
規模が小さい場合、精々頑張っても2～3人しか割り当てが出来ない上、下手すると1人で全て設計や開発から納品作業まで行う必要が出てきます。
そういったプロジェクトの方がフレキシブルに動きやすく、責任のある立場の人は確実に納品する為に黙ってでも内職を始めます。
1日2～3時間の残業代を請求するかしないかで責任所在を求められるのなら大抵の場合、作業方法を見直すか無償残業をしてでも確実に納品させた方が得な訳です。
社風にもよりますが、小規模開発はよくも悪くも参画者本人の裁量で小回りが利き易いという事です。
■小規模システムでもノウハウの無い参画者が固まると炎上はする
そもそもの納品に対する姿勢の問題もありますが、納品するシステムに選定した言語の実務経験が無い人と納品に対する責任の無いPMがセットになると最悪です。
納品する事が優先されるので、楽観ロックや悲観ロックの考え方を度返しで組み込んでしまって、保存したデータにそもそも信頼性が無い状態を納品しようとした業者もいます。（失笑
仏の顔という言葉もありますが、恐らくは仏様もビックリ仰天な事案でしょう。
当然、エンドユーザは激怒してしまいます。
そしてエンドユーザーから色々と疑われて開発環境なども全て自由が利かない状態に至るのでした・・・
筆者は最終の土壇場の所でこのプロジェクトに参加したのですが、JAVAに旧来のVB6の様な組み込み方をして真面目に動く筈もなく、単純な画面（マスタ管理画面の類）ですら壮絶なバグを抱えている状態でした。
救いだったのはPM以外は参画者がJAVAの実務経験が無くとも努力家で真面目だった事です。
会社事情で最後まで残る事は出来ませんでしたが、なんとか真面目に動かせる所までは常駐していました。
ある意味、JAVAの経験が無い人にノウハウを持たせる挑戦といった部分では賞賛出来るのですが、せめて始動時に経験者を1人でも入れてしっかり管理する必要があったプロジェクトでしょう。
こんなプロジェクトは稀です。
■特段の信頼がないオフショアに基本設計から一括で委託してはいけない
何を何処で間違ったのか、詳細の事情は不明ですがオフショアに基本設計から一括で請け負いさせて炎上してしまったケースがあります。
元々、他社パッケージの業務（C/S系）をそのまま移管してとある言語からJAVAに置き換えるだけなので、設計もクソもないだろ・・・って話で発注したのかもしれませんが、これがとんでもない話になってしまいます。
実は発注先のオフショア企業にJAVAをマトモに開発できる技術者が存在せず、初っ端から基本設計で止まってしまいます。（合掌）
既に土壇場の状態で筆者は参画したのですが、C/SからWebに置き換えるには幾つかクリアしなければならないものがあります。
それはユーザインターフェイスとC/Sだけでしか実現できないものとWebでしか実現できない対象の判別です。
具体的にはC/SだとクライアントにワークDBなどを持たせて内部処理を独自に行う事ができますが、web系は原則としてサーバー側で処理を纏めてしまう所でしょうか。
インターフェイスで言えば、C/S特有の部品を持っていると、その部品に相当するものをWeb用として基盤設計/開発する必要が出ますが、その中に実現が難しいものも存在します。
もっと細かく言えば、IMEの制御もC/Sでは細かい制御が容易だったとして、Webになるとブラウザの特性や制約が追加されるのでIMEを制御するのは困難です。
所で、オフショアが「JAVAで製造できない」という話に戻ります。
そもそも共通処理の概念すら理解出来ていなかったら、どうなるでしょう・・・しぇしぇしぇのしぇ～（おそ松くんのイヤミ）
2012年頃だったと思いますが、先方からオブジェクト指向がわからないのでVB6の様な作りこみにさせてくれという話に発展します。
ご存じの方ならお察しの通り、同じロジックが色んな箇所に散在する作り方なので品質管理も保守も困難を極めます。
ここまで来ると参画者全員が「・・・」です。
当時のPM（上位会社）からは設計思想の意思として、既存システムをマネしないで欲しいという要求がありました。
理由はパッケージ固有の思想で表に見えない不要な機能やカスタマイズを容易にする目的で複雑な仕組みで構築されていたからです。
（炎上案件で大量の画面が存在するのに半年後には納品するプロジェクト）
うん、それは破綻しているので無理です。。。
設計を進めていくに従い、複雑な画面になると、曖昧でふんわりとした設計は表現が困難な状況に直面します。
様はDB設計を軽視して現行ソースの動きを読んでふんわり作り過ぎると如何様にでも作れるのでアジェンダが無ければ軸がブレて全体の設計が破綻してしまいます。
筆者は方針を切り替えて現行通りに作った方が・・・と進言しましたが却下、ＰＭの逆鱗に触れてお役御免になってしまいます。
（筆者自身の所属企業が付き合い都合で一部を持ち帰って受託。）
すったもんだの挙句、現行のC/Sのコードを可能な限りJAVAに愚直移管。
斯うして元々のC/Sパッケージでしっかり共通ロジックや継承に関する記述が存在していたものまで、全て個別の画面に埋め込むという改悪システムが出来上がったのでした・・・
あぁ、朝日が眩しい・・・
※2024年現在、安価なPCが普及した事によって恐らくは上記の様な事象が起こる事は一般的には皆無と思われます。但し基本設計から発注する場合はオフショアの選定先が過去に何度も実績のある企業に留めておいた方が良いでしょう。
■大規模開発の中に真面目に仕事をしない人が出るとプロジェクトはカオス化する
近年は業界で真面目に仕事をしない人はほぼ見かけませんが、20年前は割と失踪したり仕事をしない人がいました。
大規模開発で炎上になった末、単体製造のフェイズで本当に納品出来ないと判断した場合は上長と相談した上でダミープログラムをねじ込んで表向きは製造完了にする事があります。
しかし、そのままでは納品出来ないので裏工作しながら結合テストや総合テストに入るまでになんとか製造を完了させるように努力します。
この流れを知っていてサボタージュを考える人は鼻から製造しない体で考えてしまい、勝手にダミープログラムを入れてしまいます。
ソースを確認すればランダムを使って表示させているだけでスッカラカンなので直ぐに分かるのですが、PMやPLは基本的にメンバーを信じていますし多くの場合、メンバーも真面目な人が入ります。
そういった所に真面目に製造しない人が入って契約満了で出て行かれたらどうなるでしょう。
多くの場合は退出する際に期間を設けて引継ぎが必要なのですが、引継ぎもしっかりやらなくて良い体制だったとすれば、逃げ勝ちです。
恐らくはカレーに生卵を入れる革命を知ったインド人並みにビックリ仰天でしょう。残された人はワッショイのお祭り騒ぎです。
そうして契約終了で退出した人の担当分が多い程、蓋を開けると納品が出来ないという想定外の緊急事態に至るのでした・・・ウソの様な話で実話です。
残った人が分担してなんとか実装とテストを完了しなければなりません。
本来はクロスチェックやレビューを行っていれば、この様な問題は発生していない筈なのですが各地方の気質や状況によって考え方は左右されます。
そもそも炎上案件はクロスチェックやレビューに割くだけの人的リソースも確保するのが難しい事情もあります。
PMやPLは基本的に製造サポートやスケジュール調整や上層やシステム連携する他社とのミーティングなどに時間消費してしまい、成果物まで確認できる程の余裕がありません。
ですから他の人がチェックしなければ製造されたかどうかの保障が出来ないのですが、外部から来た派遣を過度に信頼してしまうとこの様な事が起こります。
当然、そういった履歴を付けた人は上位会社から要注意人物として次の仕事を紹介して貰えない事態に至ります。
サボタージュするにも常駐先の体制や色んな不満や理由があっての事とは思いますが、散らかした本人が信頼を消失して苦しむだけです。
実際の所、ここまで酷い人は稀ですが製造する本人が真面目に作っていても仕様の理解不足により、実装の欠落や誤った実装をしているケースは普通にあります。
この状態を放置していると必ず何処かでツケが回ります。
ですから炎上案件で厳しいプロジェクトこそ敢えて、クロスチェックやレビューを行う必要性を筆者は提示したいと思います。
物は考えよう次第なのですが、例えば類似した画面などでソースがパクれるようなものが存在していて先行したものがあれば軽くでもチェックも平行して行うという事も出来るでしょう。
理想は常に誰かが他人のソースの作りを確認できる体制が望ましいです。
もし、クロスチェックなどが出来ない状態であれば、システムテストに入るまでに作業工程を前倒しする計画を立てて置き、リスク回避を担保しておく体制を考えておいた方が良いでしょう。
IT業界のスキル習得はその人が経験してきたプロジェクトや学習力に依存するので一人一人のスキルレベルが均等になっている訳ではなく、一長一短です。
誰もが完璧なものを作れる訳ではないし、完璧を望む事は無謀だという事です。
よく自分のレベルがこれくらいだから相手も出来て当たり前だという考え方を持っている人がいますが、そういう人がプロジェクト管理を行った時にはストレスを感じる事でしょう。
何故なら、その様な人は大抵が優秀なのでゴールまでの道のりを明確に描けていて作業環境さえ与えたらほぼ理解して貰えると思っています。
そして仕事を頼む相手が理解出来なければ無能と判断しがちだからです。
プロジェクトに長く常駐して作法などを理解していれば当たり前の事が新規参画した人には必ずしも当たり前ではないと考える事が重要です。
残念ですがPMやPLが設計・製造者の認識をキャッチ出来なければ意図しないものが製造されてしまう結果にも繋がります。
キャッチする情報についても色々な手法はありますが、聞かなくても理解しろという空気のあるプロジェクトは超優秀層と超劣等層に分離してしまう傾向にあります。
特に聞けない環境を作ってしまうと以下の悪循環を生み出す温床になります。
●劣等層はノウハウが蓄積出来ない
●超優秀層にきつい仕事が盛らてしまう（劣等層に伝授するだけの時間が無い）
●結果的に優秀な人だけが更にスーパーマンになってしまう（その人に依存してしまう）
●優秀な人がいつまで経っても楽にならない
●長期プロジェクトの場合、優秀な人が長年でしか得られない特定の情報を持っていて病気や事故に遭遇した時にプロジェクトのリスクを高める
これはIT業界だけではなく、他業種でも類似する現象があります。
自分のタスクが慣れていると、そのタスクが当たり前で出来ないのは本人の問題と捉えられる事は割と普通なのですが、実際には経験を積んでいなければ求められているタスクをこなす事は難しいケースの方が多いです。
筆者自身、過去に飲食のアルバイトで座席番号や入れ替わりする客の顔などが覚えられない理由で「誰でも出来る事が何故貴方だけ出来ないのか」と常に叱咤された経験を持ち、3か月で離職しました。
それからかなり年数が経った後に類似した単発バイトを年12回くらい続けて行くと2～3年後にはスポットで常に異なる座席配列だったとしても凡その座席の位置や人の顔を覚えられる様に脳が適合していきます。
つまりこの事例で行くと短期記憶能力を持っている人と持っていない人の差であり、短期記憶能力を早く伸ばせるか伸ばせないかの話になります。
短期記憶能力を常に鍛えている人には極当たり前なのですが、鍛えていない業種にいた人からすると当たり前の事が出来ないのです。