【システム開発プロジェクト炎上診断】　～　④管理編

「今週は、何々をやりました。」
進捗報告会で、このような報告をしていると、「こいつは、分かっていない奴」とマネジメントから思われているかもしれません。
問題のあるプロジェクトに参画すると、管理が何かを分かっていないPMに愕然とします。
どのプロジェクトでも必ず週1回は開催される進捗報告会に出たら、そのプロジェクトの管理能力は知れますし、他にも課題の管理方法、会議運営、文書管理の徹底度合いを見ればプロジェクトの危険度はだいたい分かります。システム開発では多くの管理要素がありますが、その中でも抑えるべき項目について解説します。

１．システム開発プロジェクトにおける管理とは

そもそも管理とは何なのか、そしてシステム開発における管理とはどういうものか、を端的に答えられるでしょうか。
管理という言葉の意味を辞書で引いてもその本質は分かりにくいです。管理とは、健全さを保持することであり、システム開発における健全とは、基準値通りであるということです。つまり、何等かの基準があって、はじめて管理ができる状態になります。例えば、進捗管理で言えば基準は計画であり、計画に対しての乖離を見ていくのが進捗管理です。品質についても品質基準に照らして合格か評価します。
つまり基準がないものは管理が出来ませんし、正しい基準でなければ管理の意味すらないのです。そのことを理解したうえで管理していなければ、健全さを保つことは出来ないのです。

２．進捗報告書は日記ではない

進捗は、競争ではないので早ければ良いということではなく、遅いと言っても他人と比べて遅くても悲観する必要はありません。
予定より先に行っているか、予定より遅れているか、基準となる計画に対する進み具合を管理することが進捗管理です。具体的にはスケジュールの最小単位となるWBSのどのタスクが何日、予定より遅れているか、これを把握し評価することが進捗管理です。当然、基準となるWBSが正しいことが大前提であり、正しくなければ進捗管理の意味はありません。
遅れている場合にはリカバリ策を検討する必要がありますが、この検討の材料となるのが計画に対する現状の乖離値と、そこから算出した着地点の予測です。この乖離値を知ることが”現状評価”で、着地予測を出すことが”見通し”となります。
進捗報告書では、この”現状評価”+”見通し”を報告することが大切です。
何をした、何をする、という日報的な報告は、進捗管理の補足情報でしかありません。

３．”見通し”のために数字は必須

システム開発は、出来るだけ数字で管理することが大切です。大規模になればなるほど、詳細を言葉で語っていたら時間もかかりますし、全体を把握することも難しくなるため、数字の重要性は高まります。
本質的には中身を把握したうえで、数字で評価するというのが正しいと思っていますが、たまにしか登場しないマネジメントにとって数字は、過去や他プロジェクトとの比較も出来るため分かりやすいファクトです。
プロジェクトマネージャーにとっても”見通し”をはじき出すために数字は重要です。

例えば、100本の機能を20日間で設計する計画とします。
4日目の実績が計画値20本に対して16本だとすると、
　”現状評価”=4本のマイナス（遅延）
　”見通し”=完了までに25日かかる（5日遅延して完了する見込み）
となります。
この25日がどのように算出されたかというと、4日間の実績が16本なので、1日平均4本となり、100本を終わらせるには25日間かかるということになります。進捗管理では、この”現状評価”と”見通し”を把握し、報告書にもこれを記載するべきです。

また、数字はリカバリ対策を評価することにも役立ちます。
例えば上記の例であれば、予定納期を死守するためには残り16日間(20-4)で84本(100-16)となるため、1日当たり5.25本(84/16)となります。4日間の実績である1日当たり4本との乖離は、約1.3倍(5.25/4)です。つまり30%残業でリカバリできる試算にはなります。
当然、4日間の実績が既に目いっぱい残業しての結果であれば、さらなる追加残業は負荷が高過ぎて取り得る対策ではないと判断することも出来ます。

この簡単な算数が出来るかは、計画値と実績の両方が数字で把握できているかにかかっています。1本当たりの難易度も違えば、人による習熟カーブもあるので、単純計算では正解は導き出せませんが、目安として数字は非常に参考になります。
少なくとも進捗報告で、数字がない、ころころ数字が変わる、といった場合は、”現状評価”も”見通し”もできないため危険だと思った方が良いです。

４．課題一覧は、先延ばしタスクの集積場

PMが、課題管理表の種類と所在を即座に答えられなければ、それは管理できていないということです。
プロジェクト課題、開発課題、内部課題などに分けて課題を管理している場合がありますが、課題が上がった時にどの課題表に記載するかを考えるだけで時間の無駄ですし、数日後には、どこに何の課題を書いたかすら忘れてしまいます。「その課題どこかに書いた記憶があるなぁー」というやり取りは呆れるしかありません。これはExcelだろうがRedmineだろうがBacklogでも同じことです。課題を記載したことを忘れていること自体が問題なのです。

IT部門でベンダー管理を主な仕事にしている人は管理という言葉を使いたがり、何かあれば課題表に記載して管理してくださいと言いますが、そんなことを真に受けていたら課題に溺れて、逆に管理不能に陥ります。
そもそも課題をクローズするためには、誰かが何かしらの活動をしないといけません。つまりタスク化できるのです。だとすると課題管理表に記載して満足することは、リスクの先送り、タスクの先延ばしでしかありません。
課題管理表に記載することは簡単ですが、結局、先延ばしタスクが溜まる一方で、課題の数が増えるほど管理は難しくなっていきます。
全ての課題をWBSでタスク化しろとは言いませんが、考え方として、出来るだけ管理対象を少なくする発想を持っておくことは大切なことです。

５．会議運営の是正は、効率的な推進に効果的

プロジェクトにおいて、会議はかなりの時間を占めます。レビューも含めたら、チームリーダー以上の人は、週の半分くらいは会議をしているのではないでしょうか。
それがわかっているにもかかわらず、非効率なやり方をしているプロジェクトは多いです。会議の目的とゴールを明確にする、最小限のメンバーで開催する、事前に考えてきてもらうなど当たり前に出来ることは沢山あるはずなのに、何かあればすぐに会議ソリューションを短絡的に取ってしまうプロジェクトは、エンジニアの負荷が高まり、遅延の可能性が高まります。
多くの時間が使われるレビューについても問題はあります。レビューする人は言わば先生なので、正解を知っていないとレビューはできません。先生が生徒と一緒に答えを探しているようでは、時間は足りません。育成面で考えさせることは必要ですが、全てのレビューでこれをやっていたら確実に遅延します。
会議運営を厳しい目で見ることは、効率的な推進をするためにはとても大切です。

６．ドキュメントが見にくいと出来上がるシステムも醜い

システム開発プロジェクトでは、成果物以外にも検討資料や報告書など多くを作成し、検討結果や指摘によって更新もされるため履歴や派生したバージョンも含めると、すごい数のドキュメントが存在します。
最新のドキュメントがどれか、承認された成果物がどれか簡単にわからない状況は危険です。成果物に検討事項が残っていたり、ドキュメントによって異なる検討結果が書かれていたり、同じ格納場所に検討資料と成果物が混在していたりする状況は、成果物を完成できていないことと同じです。
記載内容についても、構造化されていなかったり、人によって書き方が違ったりすると、レビュー品質もばらつき理解するのも時間がかかります。見た目が美しくない資料は内容もわかりにくいため認識齟齬を生みやすく、障害や手戻りを引き起こします。
あげたら切りがありませんが、ドキュメント管理を軽視するプロジェクトは、確実に問題を引き起こします。ドキュメントごときの管理をできない人が、システム開発の管理が出来るはずがありません。ドキュメントが見にくいプロジェクトは、システムの出来上がりも醜いものです。

■炎上診断チェックリスト（④管理）

④－1．管理表の種類
・管理表（一覧）がいくつあるか
・PMとチームリーダーは、その所在をすぐに言えるか
④－2．課題
・オープン課題の数が10以上ある
・ToDoが混在していないか
・課題を対応しない場合の影響がわかるように否定文で書かれているか
・影響タスクに関連付けされた意味のある期限が設定されているか
④－3．WBS
・概要スケジュールとWBSとのリファレンスが取られているか
・1行に複数の人が含まれるようなタスクがないか
・1行が1週間以上のタスクになっていないか
④－4．進捗報告書
・報告単位が概要スケジュールのタスク単位になっているか
・状況は3択（遅延、オンスケ、アヘッド）で示されているか
・状況詳細は、定量的な数で現状を評価しているか
・遅延の場合は、遅延工数（あるいは日数）、リカバリ策、見通しが記載されているか
④－5．会議
・進捗会議と検討会は全て定例化されているか
・会議には必ず目的がわかるタイトルとアジェンダを付けているか
・会議の参加者は常に最小限で行うようにしているか
④－6．ドキュメント
・フォルダ構成が明確に定義されているか
・成果物と検討資料が明確に区別されているか
・フォルダ内に古いファイルや作業用ファイルが混在していないか