ポストモーテム
List
間違った反省会からの脱却
TSP（Team Software Process）を原書で取り寄せて中を覗いてみて目に付いたのは「Chapter 10 The Post Mortem」というタイトルでした。３０数年、この世界にいて初めて目にするものでした。辞書で調べてみると「検死解剖」という意味だと分かって妙に納得したことを、いまでも鮮明に覚えています。同時に「どうしてこんなタイトルが考えつくのだろう」とも思ったものでした。（“やっかみ”が含まれていますね）
プロジェクトは、多くの場合、満足な結果で終わっていません。途中で仕様変更の頻発に見舞われて混乱し、さらにテストの段階では品質問題で大幅な手戻り工数が発生し、最終的に納期を数ヶ月オーバーして終了するのです。もちろん、当初想定したコストはとっくに越えているのです。つまり当初想定されていた「QCD」をはるかに越えているのです。程度の差はあっても、ほとんどがこのパターンです。そこでなぜこのような結果になったのか、プロジェクトを解剖して検証することになるのですが、その様子はまさに「検死解剖」といえるものでもあります。
日本では、プロジェクトの終了時に「反省会」というものが行われます。そこでは、期待された結果とは違った形で終結したプロジェクトに対して、失敗した原因を明らかにし、さらに今回の失敗を次回に活かすための施策（対策）が示され、いくらかの手直しを経て承認されます。反省会ではプロジェクトの関係者が、失敗に至った経緯について弁明し、今後の対応策を説明するのですが、失敗に至った経緯は、いろいろな段階での「反省会」で何度も説明しているのです。意地悪い言い方をすれば暗唱できているのです。そこでの対応策の中身はお寒い状態なのですが、この場では、「反省の深さ」を評価する傾向が強いのと、関係者に“具体的”ということについての認識が曖昧？なために、対応策の具体性についてはあまりチェックされません。したがって反省の色が濃いことが重要になるのです。
実はこの様子はソフトウェア開発の現場だけの問題ではありません。日本社会の「文化」としての形でもあるのです。例えばJR西日本のＨＰでは、先の宝塚線での列車転覆事故に対する「反省」とその「対策」について公表されています。そこでは事故に至った原因として６つの項目が上がっています。そして、それぞれの原因に対して考えられた対策の内容が第３章で展開されています。この「安全性向上計画」が公表されたのは平成17年5月31日です。でもその後にATSの設置ミスが明らかになったりして所轄官庁からの改善の指示が出されています。そもそも、この「安全性向上計画」は、実際に現場を指揮する人たちが考えたものかどうかも疑わしいのではないかと思っています。
反省会もポストモーテムも、失敗の原因を明らかにし、同じ失敗をしないように考えるということでは、目指しているところは同じなのですが、そこで行われていることには大きな違いがあります。
反省会では
「最初に○○を把握することを忘れたために・・・」
「○○さんが体調を崩したときに行き詰まっていることに気付いていれば・・・」
「○○の時期に要求仕様とテスト仕様を照合していれば・・・」
というように、失敗の経緯や原因について何度も説明させられます。何度も説明させられているので、諳んじているほどです。でもこれって、何の効果もありません。私に言わせれば、失敗した原因や経緯を何度も復唱しているだけです。これを説明させる度に、彼の「経験のメモリー素子」に「レジスト」して焼き付けているのです。それよりも大事なことは対応策の方です。反省会でも対応策は求められることがあります。問題は、
・その対応策が「具体性」を持っているかどうか、
・改善したい点の効果が上がる方法かどうか、
・その効果を測る方法が考えられているかどうか
です。実際の反省会の様子を見ていると、そこで出されている対応策には、具体性に欠けるものや原因に届いていないものが多いのです。原因は要求仕様の構成にあるのに「レビューしなかった」ことに原因を求めている状態では何も改善されません。でもその対応策が承認されているのです。なぜ、このような対応策しか出て来ないのか。その原因と考えられることは、
１）原因の捉え方が単純過ぎる
２）成功したときに「因」と「果」の視点で評価していない
ことにあると思われます。
従来の反省会では、成功したことは評価されません。もちろん、最終結果での成功は評価されるのですが、個々のプロセスでの成功は、反省会の議題には登りません。つまり、そこでは最終結果しか問われていないのです。最終結果で失敗したときに、その「原因」を追及し、二度と同じ間違いをしない（させない）ための場なのです。このような中では、成功させる「眼」は養われません。ポストモーテムは、失敗だけを扱うのではありません。むしろプロセス単位の「成功」の方を積極的に扱うのです。ある結果を狙って取り組んだ結果として成功しているのですから、その要因を特定しやすいのです。最終結果としての成功は、個々のプロセスの小さな成功を積み上げた結果として表面に現れたものです。したがって、個々のプロセスの単位で「○○をしたことで、□□の効果が現れた」という視点で評価することが必要なのです。もちろん、「効果が現れた」といっても、まだまだ満足できるレベルではないとすれば、さらに効果を上げるための提案（プロセス改善提案「PIP」）を残しておくことになります。ある程度の効果が上がっている状態では、「あそこをもう少し○○しておけば・・」ということは幾つか見えているのと、プロセスの記憶が新しい状態であること、そして普段から「因」と「果」で物事を考える習慣がついていることで、具体的にどこをどのように改善すれば目指す効果が得られるのではないか、ということが考えられるのです。
この意味からも、反省会からポストモーテムへの転換をお勧めします。
補足：TSPが2002年に翻訳され「チームソフトウェア開発ガイド」（コンピュータエージ社刊）として出版されています。その中では「Post Mortem」を「事後分析」と訳されていますが、これでは「反省会」のイメージが残ってしまいますので、私としては「ポストモーテム」のまま使用することをお勧めします。同じ問題が「進捗管理」にも現れています。初期のCMMでは「Tracking & Oversight」を「進捗管理」と訳されてしまったために、多くの現場で行われてきた「進捗管理」のやり方が運用の中で表面に出てしまいました。CMMIでの「Monitering & Control」を「進捗管理」と訳さなかったのは、過去の反省が働いているものと（勝手に）推測しています。「レビュー」にも同じ症状を見ることがあります。このように、言葉によって従来の概念が甦ってしまい、新しい行動の障害になることがあるのです。
「銀の弾丸」になってしまう仕組み
ソフトウェア開発の現場の問題を解決する「銀の弾丸」は存在しない、というのは、フレッド・ブルックスの有名な言葉で、ソフトウェア開発の現場にいる人なら、そしてチームリーダー以上の人ならおそらく誰でも知っていると思います。でも、多くの現場での取り組みは、結果的に「銀の弾丸」に成っていることに気付いている人は少ないのではないでしょうか。自分たちの問題を解決するような「銀の弾丸」はないということを知っていることで、そこに陥ることはないと安心しているのかも知れません。
例えばコンサルタントに勧められて「派生開発」（註１）に取り掛かったものの、「間に合わないモンスター」の誘惑に負けて、成果物を簡略化してしまったたために、変更モレは思ったように減少せずに当初の納期も守れなかったとします。反省会では、なぜ変更モレが減らなかったのか、工数がオーバーしてしまったのか、ということを追及され、今回の「派生開発」の取り組みでは十分な効果を得られないということになって、もっと効果が上がる「新しい方法」を探すことになります。本来なら、結果は不十分であっても、「派生開発」としてのある程度の形はできているのですから、「原典」に戻って、何が違ったのか、どこを勝手に変えてしまったのかを調べて、改良すべきなのですが、現実には１回で廃棄され、「新しい方法」を求める行動がとられます。でもこれはまさに「銀の弾丸」を探していることと同じなのですが、その現場ではそのように認識されていません。たしかに、その現場の人たちは、「銀の弾丸」はないということは頭では知っているのです。でも、実際の行動は「銀の弾丸」を求めているのです。
いわゆる「手法」と言われるものは、いろんな場面で適用され、実験された上で公表されます。これに対して、この手法を必要としている現場の人たちのプロセスとの違い（差）が大きいときは、手法の中で触れていることのすべてが１回で受け止めることができないのです。たとえば、Ｅ・ヨードンの「ソフトウェアの構造化ウォークスルー」（近代科学社刊）の本を読んだことのある人は多いと思いますが、その中で68ページの4行目に「一つの肯定意見」という文字を認識した人は何人いるでしょう。レビューに対してある種の先入観を持っていて、レビューの目的は欠陥を指摘することであって、そのような場で「肯定意見」を出すことなどまったく考えたこともない状態では、「一つの肯定意見」という文字が目に止まらないのです。少なくとも意識の中に残らないのです。そうした状態で「ウォークスルー」を実施したとしても、ヨードンが勧めたウォークスルーで得られるはずの効果は得られないのです。2004年に翻訳された「ピアレビュー」（日経ＢＰソフトプレス刊）でも、「ほめる」という言葉が使われていますが、果して読者の目に止まったかどうか。
この場合、もう一度「ソフトウェアの構造化ウォークスルー」の本を読み直して、何が違っているのかを探すべきなのですが、なぜか、多くの人はもう一度戻ってくることはしません。こうして、この取り組みは捨てられるか、勝手に曲解された状態で効果が上がらないまま続けられるのです。その結果、効果を上げるための「新しい方法」を探すことになります、ただし新しい方法を見つけたとしても、このような姿勢しか持ち合わせていない状態では、同じように中途半端に取り組まれて、また新しい方法を探し求める可能性の方が高いのです。これは紛れもなく「銀の弾丸」を探す行為なのです。
ポストモーテムでは、結果は満足な状態ではなくても、ある程度の効果を上げていることがデータなどで把握できれば、それは「うまくいったプロセス」として取り上げます。そのとき、うまくいった「因」と「果」を言葉や文章で表現する（註２）ことによって、取り組みと効果の関係をハッキリと認識することになるのです。こうした認識によって、今回の取り組みが必ずしも満足な結果を上げていないとしても、それだけで廃棄されることはありません。このとき、判断するのにデータを参考にしていますので、さらに効果を上げるための工夫を考えるにもヒントになるのです。
このように、反省会に変わる方法としてポストモーテムを取り入れることで、安易に「銀の弾丸」を求めるのではなく、改良を重ねる方向に行きやすくなるのです。
註１：「派生開発」については、2006年4月の「Software People」vol.8で「XDDPによる派生開発プロセス」として紹介します。
註２：「因と「果」で結んで表現するというのは、私が昔からやっていたことで、それをポストモーテムに持ち込んだものです。