プロジェクトの反省会で確認すべき3つのポイント

2020年1月25日

プロジェクトが終わったらプロジェクトの反省会を開こう

記憶が新しいうちに反省会を開く

プロジェクトは成功させるだけでも難しいことで、もめ事を起こしながらもなんとか完了させたということが多いのではないでしょうか。
炎上状態やデスマーチ状態のプロジェクトを終えるとホッとして二度と関わり合いを持ちたくなくなりますが、どんなプロジェクトであっても反省会を開くことが大切です。
とくに記憶が新しいうちにプロジェクトメンバーで集まり、反省会を開くことをおすすめします。

プロジェクトの反省会では何を話し合うか?

プロジェクトの反省会では何を話しあうべきでしょうか。
最も重要な議題は「要件」「スケジュール」「予算」が予定通り達成できたかです。
なぜなら、これら3つのポイントが当初の予定通りに達成できていないことが「プロジェクトの失敗」であるため、完了していたプロジェクトが失敗状態だったのか否か、失敗していなくても、失敗状態にどの程度近づいていたのかを確認することは重要です。

要件

予定されていた要件は充足できたか?

要件を確認する上で重要なのは、当初の要件をすべて充足させることができたかという点です。
当初の計画上対応するとしていた要件を、スケジュールや予算の関係で対応しなかったというものはなかったか確認していきましょう。

認識の齟齬が発生した要件はなかったか?

要件で未充足なものがなくとも、プロジェクトメンバー間で認識の齟齬があった要件がなかったか議論してみるとよいでしょう。
ITプロジェクトではプロジェクトメンバー間や取得者供給者間で想定していた要件が違うということが頻繁に発生します。
取得者・供給者間での認識の齟齬は、多くの場合機能の充実度が争点になっています。
例えば「お問合せフォームを作成する」という要件であっても、開発をする供給者(ベンダー)はフォームに入力した内容を特定のメールアドレスに送るシンプルなシステムを創造するのに対して、取得者であるクライアントは様々な条件分岐で入力内容に適した担当者にメールが送られ、なおかつ最先端のセキュリティ対策を施されたお問合せフォームを期待しているかもしれません。
こうした要件の詳細については要件定義などのプロセスで確認していくものですが、それでも認識の齟齬が発生してしまった場合は、要件定義のプロセスのあり方や、要求事項の伝え方を改善しなければ同様の問題を再度招いてしまいます。

スケジュール

予定通りにプロジェクトは完了したか?

スケジュールが予定通りに完了したかというのは、比較的検討しやすい題材です。
もしプロジェクト全体のスケジュールが予定通りに完了したとしても、個々のプロセスアクティビティまでも予定通りに進行できたか確認しておくとよいでしょう。
プロジェクトは生き物ですので、個別のプロセスやアクティビティが予定通りの期間に完了できないということは多々あります。
しかし、「プロジェクトってそういうものだよ」という感想だけで終わるだけでなく、「なぜ予定通りの期間に終わらせることができなかったか」を議論することで、今後の不安要素を解消していくことができます。

設計・実装・テストのバランスはどうだったか?

反省会でスケジュールの振り返りをする際は、設計・実装・テストの期間を見比べてみると新たな課題が見つかるかもしれません。
スケジュールの「1/3の法則」というものがあります。ITプロジェクトのスケジュールを考える上で、設計・実装・テストの3つのフェーズに使われる時間は、全体のプロジェクトの期間を三等分したものを割り振った形になるというものです。言い換えれば設計・実装・テストの期間はだいたい同じくらいの期間になるというものです。
これは『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』の中で紹介されている手法で、確立された手法ではないものの、説得力をもつ法則です。
完了したプロジェクトがこの1/3の法則に従っていなかった場合、つまり設計・実装・テストの各期間がバラバラだった場合、そのプロジェクトは何かを見落としていた可能性があります。
例えば設計の期間に比べて実装やテストの期間が長ければ、それは要件の漏れがあって開発の手直しがあったことを意味しているかもしれません。
あるいは設計や実装の期間は同じくらいなのに、テストの期間が長くなってしまっていれば、開発した成果物の品質がよくなかったのかもしれません。
このように、1/3の法則に照らし合わし、設計・実装・テストの期間を見比べてみることで、プロジェクトの反省点、ひいてはプロジェクトマネジメントの課題が浮かび上がってくるかもしれません。
この1/3の法則については、以下の記事もご参照ください。

より早くプロジェクトを終えることはできなかったか?

プロジェクト及びその各プロセス・アクティビティが予定通りに終わったとしても、「さらにスケジュールを短縮できなかったか」ということを考えるとさらなる改善活動につながります。
例えば「アクティビティAが終わってからアクティビティBを開始したけど、並走させることができた」「このタスクを外注していればさらに開発期間を短くできた」というように、さらにスケジュールを短くするための施策を考えることで、今後のスケジュールの見積りを改善することができるだけでなく、今後のプロジェクトでスケジュールの遅延が発生しそうな場合でも、うまく乗り越えられるノウハウを蓄積することができます。

予算

予算通りにプロジェクトは完了したか?

要件とスケジュールの反省が終わったら、最後に予算通りにプロジェクトが完了したかを振り返ります。
要件とスケジュールの問題は、プロジェクトの費用に影響していきます。例えばプロジェクト後半に要件が満たせなくなりそうであったから、追加費用を支払って急遽さらに外注を行った場合や、スケジュールが間に合いそうになかったからリソースを追加したという場合はプロジェクトの費用を増加させてしまいます。
こうした事態が発生したとしても、それも当初の計画で想定しうる範囲内なのであれば問題ないのですが、予定の範囲を超えてしまうと最悪の場合経営戦略をも変えていかなくてはならないかもしれません。経営戦略の変更が必要なまでの予算超過が発生したかも、最後に確認しておいた方がよいでしょう。

反省会の内容を組織のノウハウとする

反省会で話し合われた内容や、そこから得られた教訓は、PMBOKで紹介される教訓リポジトリのようにして保存し、今後同様のプロジェクトがあった時に組織のノウハウとして使えるようにしておくとよいでしょう。
反省会で得た教訓を蓄積していく流れが生まれると、プロジェクトの成功率を高めるだけでなく、パフォーマンスの改善にもつながり、新人教育にも使用することができます。
教訓リポジトリについては、以下の記事でも紹介していますので、よろしければご参照ください。