最終回　愚者は経験に学び、賢者は歴史に学ぶ

落合和雄
2008/2/3

皮肉なことに、プロジェクトと失敗とは相性がよい。「納期に間に合わない」「要求に合致しない」「機能を削減することが多い」など、もともとの目的、スコープから後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいか。これらの疑問に対する解答を本連載で明らかにする。

プロジェクトはなぜ失敗するのか 各回のインデックス

第1回　システム化範囲がぶれていれば失敗する

第2回　破たんした見積もりはプロジェクト失敗への近道

第3回　営業の押し込み案件は失敗への扉を開く

第4回　デフォルトの契約内容は、失敗への招待状

第5回　納期優先の無理なプロジェクトが失敗を招く

第6回　問題ベンダの選別基準

第7回　日本人の器用さがプロジェクトを失敗させる

第8回　リスクマネジメントの障害は社内にある

第9回　納期優先のツケを後で払うことになる開発方法

第10回　顧客要求を安易に受けてしまう人の良いSE

第11回　実績工数がない進ちょく報告はまず疑え

第12回　コストは現場で管理し、出来高で把握せよ

第13回　上流工程のバグは、下流工程で増幅する

第14回　納入したソフトの検収を速やかに終えてもらう方法

最終回　愚者は経験に学び、賢者は歴史に学ぶ

■プロジェクトの失敗を覆い隠そうとする経営者

　あるSIベンダで大規模なプロジェクトが失敗し、数十億円の赤字を計上した。開発当初、そのプロジェクトは成功すれば大きな利益がもたらされるという良いうわさが流れていたが、しばらくして「プロジェクトがうまくいっていない」という悪いうわさが流れるようになった。このころから、プロジェクトメンバーの変更が頻繁になされるようになり、変更になったメンバーの多くは関係会社へ出向させられていった。最終的に、大きな損失を残してプロジェクトは終結したのだが、プロジェクト終結時には当初の関係者はほとんど残っていなかった。経営トップの間では、このプロジェクトに関する反省が行われたのかもしれないが、少なくとも担当・部門の中では、このプロジェクトの総括がなされた形跡はなかった。

■過去の他人の失敗から学ぶことの重要性

　これは第二次大戦で日本軍が取った行動と非常に似ている。当時の日本軍は、ある作戦が失敗すると、その原因などを分析するのではなく、失敗を覆い隠すことをしていた。作戦を立てた指揮官は、いつのまにか後方部隊などに配置転換されていた。このような行動は非常にもったいない話である。ドイツ初代宰相のビスマルクは、「愚者は経験に学び、賢者は歴史に学ぶ」と語ったそうだが、愚者は自分で失敗して初めて失敗の原因に気付き、その後同じ失敗を繰り返さないようになるが、賢者は過去の他人の失敗から学び同じ失敗をしないようにする。プロジェクトも同じである。できれば、他社の失敗から学んで同じ失敗をしないようにするのが望ましい。だが、実際には他社の情報を正確に入手できることは少ないので、これは少し難しいかもしれない。それであれば、せめて自社のほかのプロジェクトの失敗から学ぶぐらいは、当然行うべきである。これを行わず、失敗を覆い隠すような行為をするから、同じ失敗を何度も繰り返してしまうのだ。

■完了報告書の重要性

　過去のプロジェクトの教訓を今後のプロジェクトに生かすには、どのような仕組みが必要だろうか。一番重要なことは、プロジェクト完了時に、必ず完了報告書を作成させることである。この完了報告書でプロジェクトの良かった点や反省すべき点を記述しておけば、次に類似のプロジェクトがあったとき、気を付けなくてはいけない点が分かる。

　さらに定性的な情報だけでなく、進ちょく管理や品質に関する情報を残しておけば、そのプロジェクトのどの部分で遅れが発生し、どの部分の品質が悪かったのかなど、プロジェクトの失敗の原因が明確に分かるようになる。

■リスクマネジメントの重要性

　だが、完了報告書に過去のプロジェクトの状況を蓄積しても、それを活用しなければ意味がない。毎回プロジェクト開始時に、どのようなリスクがあり、それを防ぐためにはどのような対策が必要かを検討する仕組みが必要である。この仕組みがリスクマネジメントである。

　リスクマネジメントでリスクを洗い出す際に、過去の類似プロジェクトをチェックすることを義務付ければ、その際過去の完了報告書が参照され、過去の失敗を教訓にすることができる。完了報告書を作成するだけでなく、リスクマネジメントの仕組みも同時に確立しておくことが重要である。

■経験の積み重ねによりリスクを減らす

　冒頭でも述べたが、プロジェクトがリスクや失敗の可能性が高い理由は、プロジェクトに独自性があるからである。新規プロジェクトには、必ず何らか新しい要素が入り込むためにリスクが大きくなる。従って、リスクを減らすためには新しい要素をできる限り少なくすることが重要だ。一番確実なのは、自分の経験に基づいてリスクを減らすことだが、これでは一度は失敗をしないといけないことになる。賢者は他人の失敗から学ぶ。過去のプロジェクトの結果を分析して、同じ失敗を繰り返さないことがプロジェクトで失敗しない最良の方法である。

　この連載は、今回で最終回です。長い間、ご愛読いただきありがとうございました。いままで書いてきたことが、プロジェクト失敗の減少に多少でもお役に立つことができれば幸いです。

関連記事

メンバーに贈るプロマネ基礎講座

PMBOKの最新バージョンとは？

システム開発プロジェクトの現場から

プロジェクトマネジメントスキル 実践養成講座

開発現場で学べること

落合和雄

1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム（現新日鉄ソリューションズ）などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』（翔泳社）、『実践ナビゲーション経営』（同友館）、『情報処理教科書システム監査技術者』（翔泳社）などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。

» ＠IT自分戦略研究所 トップページへ

» ＠IT自分戦略研究所 全記事一覧へ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）