課題管理表は本来、課題そのものや対応状況を見るためのものだ。ところが見方を変えるとメンバーのスキル不足といった問題がつかめる。その他進捗報告やCcメールなど現場にある情報も、問題の見える化に役立つ。
前のPART2では、現場で起こっている問題が浮かび上がるようなデータの集め方を紹介した。PART3ではもっと手軽に始められるように、たいていのプロジェクトで収集している情報に注目。それらの見方を変えることで、現場の状況を見えるようにする。
具体的には、「課題管理表」「進捗報告」「プロジェクト関係者間でやり取りされるメール」「変更構成管理システムのログ」の四つ。これらは多くのプロジェクトで作成したり、利用したりしているものだ。これらをどのように見れば現場の状況が浮かび上がるのか、ベテランPMが現場で実践している工夫を紹介する。
課題管理表
メンバーの性格が見える
「課題管理表は、PMがプロジェクトメンバーの状況を把握できる『窓』。これを活用しない手はない」。こう語るのは、出光興産 情報システム部門のPM、竹内章裕氏（e-ビジネス室 上席主任部員 シニアコンサルタント）と立野毅氏（e-ビジネス室 シニアコンサルタント）だ。
細かく書き込むメンバーは要注意
同社のプロジェクトでは課題管理表をExcelファイルで作成し、共有サーバーに格納している。メンバーが課題に直面すると、その内容を自分の名前とともに課題管理表に入力していく。その際、仮に課題とはいえないものが書き込まれても、「こういった内容は課題とはいえないので管理表に書き込まないようにしてほしい」といった注意はあえてしない。
課題として書き込まれた内容から、経験の度合いや性格などが見えてくるという（図1上）。例えば、課題の内容が、業務の大まかな仕様やプロジェクトで採用するERPパッケージの機能に関することだった場合、そのメンバーは「業務の仕様を策定したり、パッケージを利用したりした経験があまりないことが窺える」（立野氏）。
課題の内容を細かく書き込んでいると、そのメンバーの作業遅れが懸念される。「今後プロジェクトを進めていっても、大きなミスをすることはない。しかし細かい点が気になる余り、慎重になり過ぎて、作業がはかどらなくなることが多くなる」（竹内氏）。
ユーザーや協力会社からの問い合わせ内容をそのまま課題管理表に載せているメンバーは、自分自身で解決に乗り出すことに躊躇して問題の解決に手間取ることが少なからずあるという。
このほか、課題として記入する内容があっさりしているメンバーはコミュニケーションの不足によって、課題を詳細に把握していなかったり、把握していても課題への対応依頼の内容を相手に十分に伝えられなかったりする可能性が高いという。
対応期限日の更新は問題を表す
課題管理表の内容から読み取れることはほかにもある。NTTデータの浜里敬二氏（法人システム事業本部 ブロードバンドビジネス事業部 第一統括部 第一テレコム開発G 課長代理）は、課題の対応期限日が更新されていないかどうかに注目している（図1左下）。
期限日が繰り返し更新されていると、「課題に対応するメンバーのスキルが不足しているか、メンバーがその課題を解決することに重要性を見いだしていないかのいずれかを意味している」と、浜里氏は説明する。
浜里氏は期限日が更新されているのを見つけると、担当メンバーのところに出向いて話を聞く。もしスキルが不足しているなら、課題の対応策を含めて一緒に計画を立てる。課題解決に重要性を見いだしていないようであれば、担当メンバーの判断が正しいかどうかを見極めるようにしている。
システムインテグレータ、クレッシェンドの村中直樹氏（代表取締役社長）は、質問表の記入日や項目数から、「メンバーとユーザーとの間でコミュニケーションが滞っているのが見える」という（図1右下）。
村中氏がPMを務める現場では、メンバーが気付いた仕様に関する課題を、ユーザーへの質問表という形で管理している。表はExcelで作成し、プロジェクトの共有サーバー上で、PMである村中氏とメンバーがアクセスできるようにしている。
同じ日にたくさんの質問が出ていると、ユーザーに回答を催促していない状況が見えてくる。「一つ前にした質問の回答がなかなか返って来ないと、その間に新たな質問が生まれ、結果的にまとめて質問をすることになる」（村中氏）という。こうしたことが繰り返されると、プロジェクトの遅延につながるので、ユーザーに回答期限を守ってもらうようメンバーに指示を出している。
また、ユーザーへの質問の数が少ないと、手戻りが発生する恐れが出てくるという。村中氏はある短期プロジェクトで次のような状況を経験した。プロジェクトは順調に進んでいるように見えたが、後工程になって手戻りが頻発し、プロジェクトは大幅に遅延してしまった。実は「ユーザーに質問することなく、メンバーが自分なりに仕様を解釈し、勘違いしたまま開発を進めてしまっていた」（村中氏）のだ。
