今回はリスク管理の共通課題を取り上げる。リスク管理はプロジェクト管理そのものといってもよいくらい重要なものだ。プロジェクトの各段階でそれぞれのリスクと向き合い、適切な対応を取らなければならない。
 |
工程遅延が判明したら、まず何が原因で遅れたのか、その真の原因を徹底追究し、その原因を排除したり、何かでカバーして、その影響を軽減するのが工程遅延対策である。
例えば、顧客との間で要件定義が遅れていることが原因であれば、単に要員追加だけで対策を打とうとすると、かえってプロジェクトは混乱してしまう。担当者の能力不足が原因であれば、技術力の不足なのか業務知識の不足なのかを見極めなければならない。技術力不足なら他部門から支援もできるが、業務知識となると顧客を含むプロジェクト内部で対処せざるを得ない。
時には、担当者と周囲との人間関係や、家庭の問題など、極めて人間くさい事情が原因になっていることもある。よく事情を聞いて、可能な対応策を考える必要がある。
 |
あるプロジェクトで、外注先に任せていた部分の品質がなかなか安定せず、ついに社内のベテラン設計者に応援させる羽目になったことがある。ベテランのおかげで品質は大幅に改善されたものの、なかなか完ぺきにはならず、時々バグが出る状況が長く続いてしまった。
ベテラン設計者を入れたとき、問題のソフトの構造が汚いことはすぐに分かったはずだから、本来なら思い切ってやり直させるべきだった。それを、いくらベテランとはいえゼロからやり直すと時間もかかるので、バグ対策をしながら何とか収束させたいと考えたのが失敗だったのだ。
最優秀スタッフに応援させるなら、土台があやふやな問題ソフトは捨ててやり直せば、意外と早く完成したのではないかと反省している。
 |
ピート・マクブリーン氏は、著書『XP懐疑論』で、「ソース・コードは、時間、エネルギー、業務知識など、多大な投資の結晶だ。初めからやり直すことは高くつくうえ、2度目がましになるという保証はない。実際ほとんどの場合、既存コードを修正するほうが最初からやり直すよりもましだ」と言っている。
一方で、トム・デマルコ氏は、『ソフトウエア開発プロジェクト技法』において、「すでに欠陥が発生しやすいと分かっているコードをきれいにしようと金をかけるより、そのコードは捨てたほうがよい。コーディングの費用は、不良が発生しやすいコードを修正する費用に比べれば、ほとんど問題にならない」と言う。どちらが正しいか。どちらも正しいのである。要は、直すか捨てるかは、対象の評価いかんにかかっているだけに、実態をよくつかむことが何より大事である。
 |
先述したように、工程表の書き直しは極力やめるべきである。しかし、やむを得ず書き直す場合は、徹底的に現状を洗い直し、思い切って実態線表にすることである。そして書き直したら、メンバー全員に納得させ、メンバー全員が絶対に二度とは遅らせないということを決意することが肝要である。線表を引き直してもまたずるずる遅延するのは、顧客の信頼を失うだけでなく、担当者のモラルも落すことになり、一番まずい。
ある部下が顧客に早期対策を迫られ、あわてて修正工程を出したが、1週間もしないうちに計画が再破綻した事例がある。彼には、「最初のイベントくらいは、自分でできるとみた日程の倍くらいみたほうがいいよ」と忠告した。とにかく、引き直した工程が1週間で破たんしてしまうようでは困るのである。
