当初の計画通りに作業が進んでいることを確認する見える化は大切だ。しかしそれだけでは、現場で問題が発生したことを早期にはつかめない。現場で起こっている問題を浮かび上がらせる工夫が必要になる。
数字による報告だけでは、プロジェクトの状況は見えてこない──。シーイーシーの栗原誠氏（第一システム事業本部 第二システム開発事業部 第三システム開発部 グループマネジャー）は、PM（プロジェクトマネジャー）として参画したあるプロジェクトで、こう痛感した。
それは、プログラミング/単体テスト工程の終盤でのことだった。栗原氏はそのプロジェクトで、「プログラム20本のうち10本のプログラミング作業が終わったので進捗率は50％。単体テストまで完了したのは5本なので進捗率25％」といった数字を基にした報告を、週次ミーティングでメンバーから受けるようにしていた。
報告を聞く限りプロジェクトは順調に進んでいるように見えたが、突如として問題が判明する。プログラミング/単体テスト工程があと1週間で完了するというタイミングのミーティングで、メンバーから「担当しているプログラムの仕様に大きな抜けがある。要件を再確認して修正し単体テストを行いたい」という報告を受けたのだ（図1左）。前の週のミーティング時点でそのメンバーは問題に気付いていたものの、当初与えられた仕様書に基づいて「進捗率は90％」と報告していた。栗原氏は、こんな問題を抱えているとは予想もしなかった。
仕様の漏れを確認してプログラミングと単体テストを終わらせるには、1週間以上かかることも明らかになった。栗原氏は慌てた。プロジェクトを納期通りに完遂させるには、翌週から結合テストに着手する必要があったからだ。急いで結合テストの計画を見直す必要がある。栗原氏は、仕様の再確認から単体テストまでの作業と、結合テストを並行して進められるように計画を大幅に変更。「土壇場での計画変更だったが、なんとか納期遅れを回避できた」と栗原氏は振り返る。
問題の発生が分かる報告に改善
「プロジェクトが短期化しているなか、メンバーが見つけた問題をPMが1週間後に気付くようでは手遅れになってしまう」。プロジェクトを振り返って栗原氏は、現場で起こっている問題を早期発見できるように、次のプロジェクトではメンバーからの報告の仕方を見直すことにした。
報告書には、計画と実績に加えて問題点を書き出す欄を設けた。メンバーには毎日記入してもらい、翌日の朝のミーティングに提出してもらうことで、メンバーが気付いた問題点を見えるようにする。メンバーに対しては、「プロジェクトで問題が出てくるのは当たり前のこと。箇条書きで構わないので、隠し立てせずに書くようにして」と依頼し、日課にした（図1右）。
朝のミーティングでメンバーから問題が報告されると、栗原氏はその場で対応策を指示するようにした。「毎日、報告書の内容を基にメンバーとコミュニケーションを取ることで、メンバーが気付いた問題をすぐにつかめるようになった」と栗原氏は効果を語る。
