提案書や報告書などの品質を上げるにはレビューが必須である。しかし、何度レビューをしてもなかなか品質が上がらないという悩みはよく聞く。これは多くの場合、レビューをする側に問題がある。筆者が品質リカバリーに関わった、PMOによるプロジェクトの報告書作成の例で話をしたい。

　報告書は、同時期に実施した10件の開発プロジェクトについて各1本作成し、評価と改善提案をするというもの。マネジャーのレビューのもと、担当者がまとめていた。10本のうち1本をまず書き上げ、残り9本のひな型とする方針で進めていた。しかし、最初の1本目の品質が上がらず、残りも考えると納期に間に合いそうになかった。

　マネジャーによると、担当者のスキルが低いことが原因という。最初に表の体裁やインデントの付け方がばらばらだったので、担当者に直させた。次に日本語が意味不明なので、話を聞いて修正した。そして、整理してみると分析が強引で納得できないことが分かったというのだ。例えば、実装時の問題に対しその主要因として設計時のチェックリストの運用不備を指摘しているが、なぜそれが主要因か理解できないという。

　著者はこの話を聞いてがっくりきてしまった。レビューの手順が逆だからだ。筆者はレビューを受ける心得として、 最初に落とし所を決めて、次に資料の構造を決め、内容を正確にするという手順を踏むように指導している。 体裁や「てにをは」は、最後に見てもらう。逆の手順だと手戻りが起きるからだ。しかし、レビューアーがこの逆順をしているのだ。

　しかも、課題分析のポイントも押さえられていない。この報告書では、同時に進められた複数のプロジェクトをまとめて評価する。したがって、有効な改善案を出すには、複数プロジェクトに共通する事象とその原因を分析することが決定的に重要になる。

　担当者に作業用のエクセルシートを見せてもらうと、複数のプロジェクトで類似の問題事象が挙がっていた。実装時の機能不足、設計完了時のトラブルなど多くの問題が、チェックリストの運用不備という共通の原因から発生しているようだった。

全体構造を整備して組み立てる

　このエクセルシートを読み込んでいくと、1本の報告書を見ているだけでは分からなかった、2種類のツリー構造が複合した構造が浮かび上がってきた。一つはプロジェクト単位で問題事象を示して分析した構造だ。報告書はこの単位で作られている。

　もう一つは、問題事象と原因を対応付けてプロジェクト横断で分類したツリー構造だ。つまり全体を俯瞰する構造があったのだが、エクセル上では個々の記述に埋没していたため、構造として把握されていなかったのだ。