進捗状況や問題の発生といった情報の収集はプロジェクトを推進する上で欠かせないが，精度の低さに悩まされる場合がある。例えば，「プログラマに単体テストを含むコーディング作業の進み具合を進捗率で自己申告してもらっていたところ，結合テストの間際になって，実はほとんど作業が進んでいないことが判明した」などのトラブルとなって現れる。
2～3日で終わるタスクに細分化する
進捗把握がうまくできない場面の多くは，進捗管理の対象となるタスクの粒度が粗すぎることに原因がある。タスクの粒度が粗いと途中経過を進捗率で評価することになるが，そうするとメンバーは作業が進んでいることを示したい誘惑に駆られ，予定納期までの日数から逆算するとか，前回の進捗率に適当な数字を上積みするなど，実態と異なる進捗率を報告しがちになる。結果，「自己申告される“進捗率”はほとんど信用できない」（NECシステムテクノロジー 第一産業システム事業部 第三流通グループ プロジェクトマネージャー 溝渕直樹氏）という事態に陥る。こうした進捗率と実態とのかい離が納期間際になって判明しても，打てる手だては限られてしまう。
この問題は，タスクをできるだけ細分化することで解決できる。WBSの最小作業単位とされる「ワークパッケージ」のレベルでは細分化したことにならない。「2～3日で完了するアクティビティ＊3まで掘り下げる」（ソフト開発のDTSのシステム開発本部 産業事業部 産業第一部 プロジェクトマネージャ 川端久生氏）ことが必要である。
Javaなどオブジェクト指向言語による開発であれば，「クラス設計の段階で一つのクラスを数日でプログラミングできる単位に切り分け，1クラスを1タスクと扱う」（エスジェイソリューションズ プロジェクトマネージャー 武内和弥氏）。その上で，プログラミング，単体テスト，バグ修正を別々のサブタスクとして管理する。
このようにタスクを細分化すれば，進捗状況は未完了（進捗率0％）と完了（同100％）だけで把握できる。「メンバーの目標が明確になるし，予定と実態のズレを早期に見つけられるので，メンバーのタスク割り当てを見直すといった対策も立てやすい」（NECシステムテクノロジー 溝渕氏）。
もっとも，タスクの細分化が困難な場合もある。ユーザーからの要件の聞き取りや，仕様書の取りまとめなどがその例だ。クオリカの沖山英明氏（ストラテジックシステム事業部 システム第一部 部長）は，ある大手企業の要件定義プロジェクトの進捗管理で，次のようなテクニックを使った。それは，進捗率を20％刻みで報告させ，端数を禁じたことだ。「端数を許すと，作業が進んでいなくても進捗率を5％とか高めて進展しているように見せようとしがち。だが，端数を禁止すれば，作業が進んだという実感をメンバーが持つまで進捗率は上がらない。端数を禁止したときのほうが実態に近い印象がある」（沖山氏）。
事務的なタスクまで管理する
 図2●事務的なタスクまで洗い出して“カレンダー”に書き込む 日本アドバンストシステムの朝倉氏は，Excelシートでカレンダーを作成。各メンバーは実施予定のタスクを洗い出してカレンダーに記述する。記述内容は「朝会」で確認し，実施状況は「夕会」で報告する [画像のクリックで拡大表示] |
 図3●進捗の予定と実績などからタスク漏れを洗い出す 野村総合研究所の安田氏は，「EVM（Earned Value Management）」をベースに，1週間単位で予定と実績を比較する [画像のクリックで拡大表示] |
 図4●要件や仕様に対する指摘事項を集めて品質評価に生かす ある大手金融会社の情報システム部門では，要件や仕様を説明するときにユーザーが指摘した事項の件数から，ユーザーの理解度や，要件/仕様の品質を推し量る [画像のクリックで拡大表示] |
 図5●ツールの導入でプロジェクトの状況を「見える化」する 富士ゼロックス情報システムは，プロジェクト管理ツール「Primavera」を使い，進捗状況などの情報を収集・管理できるようにした [画像のクリックで拡大表示] |
WBSのアクティビティにさえならない細かな粒度のタスクでも，プロジェクトの成否を大きく左右しかねないものがある。例えば，ユーザーへの電話連絡や，書類の発送，担当者間の根回しなどの事務的なタスクがこれに当たる。日本アドバンストシステムの主任でPMを担当する朝倉啓喜氏は，こうした事務的なタスクの進捗まで管理する。
事務的なタスクの情報を集めるために，朝倉氏はExcelシートで“カレンダー”を作った（図2[拡大表示]）。メンバーは，事務的なものからアクティビティ・レベルのものまで，タスクの内容をカレンダーの実施予定日に書き込む。翌日以降に持ち越したタスクの実施予定も，随時カレンダーに書き加えていく。これにより，「WBSによる進捗管理だけでは見落とされやすい細かなタスクの実施漏れを防いでいる」（朝倉氏）。
タスクの過不足を検証する
タスクは細分化するだけではなく，過不足の有無をチェックすることも必要だ。そのためには，一般的にレビューが有効とされるが，レビューでは客観的な評価は難しい。
野村総合研究所 生産性向上推進部長の安田守氏は，作業の進捗度を成果物の出来高で評価するマネジメント手法「EVM（Earned Value Management）」を活用し，漏れたタスクの有無を定量的に検証している（図3[拡大表示]）＊4。
EVMでは，スケジュール通りに成果物を作ることができた場合にかかる工数「出来高計画値（PV）」と，作成済みの成果物にあらかじめ割り当てていた予定工数の累積値「出来高実績値（EV）」，実際にかかった工数「コスト実績値（AC）」を比較検討する。例えばEVがPVを下回れば作業遅れだし，PVよりACが上回ればコスト超過を意味している。
そこで安田氏は，EVとPV，PVとACに差がある場合に，その理由をプロジェクト・リーダー（PL）などから聞き取るようにした。すると，「（進捗予定表にない）会議を招集していたなど，漏れていたタスクが洗い出されるようになった」（安田氏）。
洗い出したタスクは，進捗予定表に追加する。こうしたやり取りを継続することで，次第にPLの“気づき”が促され，プロジェクト終盤までにタスク漏れは解消していくことになる。
指摘事項の件数で品質を量る
プロジェクトを成功に導くには，タスクの進捗だけでなく，成果物の品質についての情報も集める必要がある。特に，上流工程の成果物の品質については，これまで定量的な指標が無く，困難だった。
ある大手金融会社の情報システム部門では，ユーザーからの指摘事項の件数という身近な情報を活用し，要件や仕様の品質を定量的に評価する試みをしている（図4[拡大表示]）＊5。
まず，設計者のスキルやシステムの複雑さなどを考慮し，同規模システムの実績値からの類推法によって，あらかじめ評価基準値（しきい値）を算出する。次に，ユーザーへの仕様報告会の席上で挙がった指摘事項の件数を集計。妥当な範囲（図4の例では3～10件）より少なければ，「ユーザーの理解が不十分な可能性がある」と判断し，ユーザーに確認を求める。
逆に妥当な範囲を超えていれば，仕様書の品質不足を疑う。この場合は，ユーザーの指摘事項の内容に目を向ける。指摘事項の内容に応じて，「設計者の設計ミス」「ユーザーの仕様変更」「単なる記述ミス」に分類し，設計ミスが多ければ，聞き取りの方法を変えるなど対策を打つ。「上流で品質不足を洗い出せば，手戻りが減り，コストや納期への悪影響を封じやすい」（関係者）という。
雰囲気作りなど環境を整備する
情報を集めやすい環境を整備することも欠かせない。例えば，進捗の遅れや問題の発生を隠さない雰囲気作りが挙げられる。
建築業の東建コーポレーションの情報システム部でPMを担当する大塚基喜氏（課長）の場合は，進捗遅れや問題発生の連絡を受けても，「絶対に怒らない」ことを心がける。なぜなら，経験上，報告を受けたときに怒ってしまうと，次からは怒られない内容の報告しか集まらなくなるからだ。「遅延や問題の発生はやむを得ないこと。どうするのか，やり方に問題がないかを，冷静に話し合う」（大塚氏）。
PMから積極的に声をかけるアプローチもある。クオリカの沖山氏は，「メンバーの半数くらいは，問題を抱え込んでしまう傾向がある。同じ画面を見たままメンバーの手が止まっているようなときは，すかさず声をかける」という。このとき，「うまくいってるか」ではなく，「何か問題あるか」と問いかける。“問題はあって当然”というスタンスで望まないと，問題を抱え込む“殻”を破れないからだ。
人間系の雰囲気作りに加え，情報を集める仕組みの整備も有効だ。富士ゼロックス情報システムはプロジェクト管理ツール「Primavera」（販売はITエンジニアリング）を使い，進捗情報を収集・管理することにした（図5[拡大表示]）。
PMやPLは専用クライアントを使い，掘り下げたタスクを入力し，実施担当者を指定する。メンバーは，Webブラウザ経由で進捗率や工数を入力する。「従来はプロジェクトを構成するチームごとに実態がブラックボックス化していた。それが透明化され，視覚的に状況を確認できるようになり，進捗の見通しがつきやすくなった」（ERPソリューション部 システムエンジニアでPMを担当する川崎浩一氏）。
