将棋のテレビを見ていると、対局後に棋士同士が開始から終了までを再現する「感想戦」をしているのが分かる。時には解説者も加わり、打った手の良しあしや、最善手を話す。プロ棋士のほとんどは、その対局の棋譜を記憶しているそうで、これにはとても感心する。感想戦はもはやプロ公式戦では定例化。結果を踏まえて振り返ることで、棋力の向上につなげている。

 言うまでもなくITエンジニアも、プロフェッショナルとして振り返りによる成長が不可欠だ。ITプロジェクトの振り返りは「ポストモーテム(post mortem)」と呼ぶ。筆者が最初にこの言葉に接したのは、2000年代前半。W.ハンフリー氏の名著「Team Software Process」に記されていた。翻訳本では「事後検証」と訳されていた。

 ところが、辞書によるとポストモーテムのもともとの意味は「検死」。その後、複数の外国人が使うのを聞いて、何でこんな言葉を使うのかと不思議に感じた。最近知ったが、チェスの感想戦もポストモーテムと呼ぶらしい。その意味では、プロジェクトのポストモーテムも感想戦と捉えられる。

「誰が悪かったのか」を追及してしまう

 では、プロフェッショナルとしてどんな振り返りをすべきなのか。もちろん、ITプロジェクトは期間が長く、ステークホルダーも多いので棋士のように正確に経緯をたどるのは困難だ。しかし、あらゆる局面で打った手の良しあしを振り返り、最善手を考え抜くという感想戦の本質には学べる。

 例えば、筆者は立場上、失敗プロジェクトの振り返りのファシリテーターを務める機会が多い。このときまず留意するのは、個人の責任追及の場にしないこと。誰が悪かったのかを追及する場ではなく、具体的で実行可能な再発防止策、最善手を導き出すことが目的だ。ある程度抽象化された留意点などにたどり着くことが望ましく、個人の反省はその議論のあとでもよい。

 議論が責任追及にならないようにするには、システマチックな振り返り方法を準備することだ。混乱したプロジェクトの場合、直接的な原因がはっきりせず、複数の要因が絡んでいるケースがある。例えば納期遅延の原因をたどると、最終的に起こったのが品質問題だったとしよう。この場合、品質問題の原因がテスト工程での作業のやり方に加え、設計段階でスコープが膨れたにもかかわらず体制を強化しなかったことなどが挙がる。さらにスコープが膨れた原因が見積もり時のスコープの曖昧さに起因するとなると、振り返りのポイントが見えにくくなる。結果、ある人はテスト段階のことを発言し、別の人は見積もり時の意見を言う。これでは議論が発散し、なかなか最善手にたどり着けない。

 そこで、最初のステップで事象の因果関係を分析し、次のステップで特定できた複数の原因ごとに、それぞれ深掘りしていく。因果関係の分析は、事象を時系列に整理することから始めよう。このときに、ステークホルダーがどう関与したかを明確にする。  週報などをこまめに書く習慣があると、振り返りもしやすくなる。振り返り時には週報を整理し、各事象の中から混乱につながった事象を特定する。そして、上で説明したように、それぞれの事象に因果関係を付け、時系列に並べる。これはまさに「棋譜」である。これをベースに議論をすれば、振り返りを感想戦に仕立てられる。

出典:日経SYSTEMS 2016年11月号 p114
記事は執筆時の情報に基づいており、現在では異なる場合があります。