日々の作業ではどうしても仕様変更や不具合が起こってしまうもの。そこで、集める情報や情報の集め方に工夫を凝らしてみよう。従来の管理帳票よりもはっきりと仕様変更や認識違いの問題がつかめる。
悪い情報ほど早く報告するのが基本。とはいえ、欲しい情報は待っていても集まらない。ITプロジェクトの現場で起こっている問題をいち早くつかむには、想定される問題を狙って取りに行かなければならない。例えば、「仕様変更の頻発」「仕様の不備」「担当者の認識違い」「不十分な作業」といったことは、起こってほしくはないが、実際のプロジェクトでは珍しくない。これらが浮かび上がるように情報を集める工夫が必要だ。
また、特定のタイミングで集中的に情報を集めることで、これから起こりそうな問題をある程度予測できる。例えば、機能ごとに結合テストを行う場合、最初のテストで集中的に問題点を分析し、その傾向をつかむ。そうすれば、以降のテストでどのような問題が起こりやすいかをある程度予測できる。先手を打った対策も立てられる。
悪い情報は狙って取りに行くべきだが、メンバーはプロジェクトの作業で忙しい。大きな負担を強いることはできない。そこで以下では、小さな負担で情報を集めている、6人の工夫を紹介する。
捨てた文字を集める
宮本氏、水口氏（ジャステック）
システムインテグレータであるジャステックの宮本伸二氏（製造本部 製造1部長）や水口学氏（製造本部 製造1部 開発5課長）がPMを務めている現場では、メンバーの作成する日報に「棄却」という欄がある。この情報を集めることで、「仕様変更や認識違いという問題が現場で起こっていることが見える」と宮本氏は話す。
棄却とはいったい何か。一度作成したものの、成果物には含めず捨てることになるもののことだ。具体的には、設計書やプログラムファイルに記述した文字のうち、捨てることになる文字である（図1）。
棄却として集める数値は2種類ある。一つは、仕様変更が原因で削除することになった設計書やプログラムファイルの文字数。宮本氏や水口氏は「仕様変更による棄却」と呼んでいる。この数値が急激に上がると、仕様変更の頻発が起こっていることが分かる。もう一つは、設計書やソースコードのレビューの結果、削除することになった文字数だ。前者と区別するため「手戻りによる棄却」と呼んでいる。この数値が増えると、「担当メンバーが仕様を十分に理解せずに設計している」「リーダーが作成に当たっての注意点や指示をメンバーに的確に伝えていない」といった、現場の状況を把握できる。
「収集はたやすい」
メンバーは日報を提出する際、作業時間や作業内容と併せて棄却の情報を報告する。報告内容が増えることになるが、オフィスソフトが備える（文字数を数える）機能を使えば手間はかからない。「日課にしてしまえば収集はたやすい」と宮本氏は話す。
水口氏は、棄却の数値が急増したり成果物の5～10％以上になったりしたとき、必ずその原因を確認している。あるプロジェクトで水口氏がPMを担当したとき、仕様変更の棄却量が急増したことがあった。担当メンバーに状況を尋ねたものの、説明内容にまとまりがなかった。実はこのとき、そのメンバーのもとにユーザーから直接、仕様変更の要望が次々と寄せられていた。「メンバーは仕様変更に追われ、混乱していた」（水口氏）。
水口氏はすぐにユーザー側の責任者と相談し、一部の機能は要件定義をやり直すことで決着した。「適切な判断をすぐに下すことができ、結果的にプロジェクトの遅延を回避できた」と、水口氏は振り返る。
