工事進行基準が進ちょく管理に変化をもたらす：これから始める進ちょく管理（1）（2/2 ページ）

[高田淳志，株式会社オープントーン]

工事進行基準の導入は歓迎すべき？

　工事進行基準の導入において受託ソフトウェア開発を行う側がきちんと進ちょく管理を行うことについて、「歓迎（積極）派」と「敬遠（消極）派」にはっきり分かれるような気がします。敬遠派には、自分自身のマネジメントスキルに依存する不安、自分自身が抱えるお客さまへの対応方法に関する不安などがあるのではないでしょうか。

　進ちょく管理というキーワードにフォーカスすると、具体的にどのような現象が起こるのでしょうか。

（1）進ちょく管理工数の膨張

　プロジェクト管理に必要な工数を算出し、相応の費用を計上する（見積もりに含める）ことについて違和感を持たれる発注側担当者は少なくありません。

　会議に合わせてスケジュール表を更新し、会議に出ても深い議論に参加するわけでもなく、取りあえずプロジェクトメンバーからの報告を淡々と読み上げる。そのような、単に開発現場のお目付け役または窓口役。そんな働きの（本来あるべきではない）プロジェクトマネージャに遭遇してしまったのかもしれません。確かに、そのような役割・営みだけに対して、費用の一部を出したくはないですね。

　しかし、ご存じの方も多いとおり、本来的なプロジェクトマネジメント業務は多岐にわたり、そのかじ取りの成否が、そのままプロジェクトの成否を左右することにもなります。

　例えば、私が進ちょく管理を行うとき、収集した各WBSタスクごとの進ちょく実績値を進ちょく管理ソフトウェアに入力し、EVMSを使用して予定・実績の乖離を確認し、必要であればタスクごとに予定を調整し、社外関係者の参加が予定されているタスクに影響が及ぶようであれば各関係者に告知・調整し……、のような作業が定期的・恒常的に発生します。

　進ちょく実績値の収集が週に1度だとしても、毎週こうした作業を行い、毎週プロジェクト計画を作成している（し直している）わけです。方法の差こそあれ、多くのプロジェクトマネージャはこのようなマネジメント業務に大きな工数を費やしています。

　これまで、そのように取り組んでいたプロジェクトマネージャでも、定期的な進ちょく管理状況が会計上の計算に反映されるとなれば、より精緻（ち）な適用を目指すことになります。そのため、これまで以上にプロジェクト管理工数が必要となるでしょう。

（2）より高度なことを求められる進ちょく管理スキル

　進ちょく管理を行う前提となる「作業の棚卸し（どのような作業が、どれくらいの作業量で発生するのか）」を正確に実施しなければなりません。開発ソフトウェアのサイズや総作業工数などを確定させるための見積もり作業に関しては、「プロジェクトの闇、見積もりに光を！」で解説しています。

　さらに、プロジェクト内の各工程や各タスクの中でも「作業の棚卸し」を行います。「どのようなタスクが必要か」や「それぞれのタスクにどれほどの作業（量・時間）が発生するか」などの情報を把握するのです。そうしなければ、進ちょく度を計測するための分母（進ちょく度＝実績作業量÷予定作業量としたときの「予定作業量」に該当する数字）を確定することができないからです。

　「やってみなければ分からない」ことだらけでは、プロジェクトマネージャは務まりません。プロジェクトマネージャ自身で解決できない部分については、プロジェクトメンバーのITエンジニアの支援を仰いで、技術的要素（難易度やリスク）も加味しながら予定作業量をより正確なものとし、より精緻な進ちょく状況の評価を行うための準備が必要となります。

（3）厳格な要件管理

　ソフトウェアは建築物と異なり、開発途中の製品の姿をなかなか見ることができないため、要件変更（仕様変更）ということの重大性が視覚的にとらえにくいのは確かです。

　ソフトウェアの場合、ちょっと大げさですが、パソコンの前で人間がキーボードをカチャカチャと打っていけば（プログラムを作っていけば）、出来上がってしまいます。だから、はたから見ると、仕様変更が必要になったとしても同じようにキーボードをカチャカチャとまた打てば簡単に変更ができるのではないかと思うのも仕方ありません。実際は、安易な変更はプログラムの品質や保守性を落とすことになります。

　工事進行基準適用後は、安易な仕様変更を行うことはできません。実現要件があいまいなままでは、開発受託側が開発ソフトウェアのサイズ（ひいては作業工数）を見積もることもできません。開発委託側が詳細なRFP（提案依頼書）を作成し、それを前提に見積もりを実施し、開発へと進んでいく。

　そんな本来あるべきフローの実現が求められます。RFPを自社で作成することができなければ、開発委託側もRFP作成だけを別契約として切り出し、専門家の支援を仰ぐような体制を取ることを検討する必要があります。

　もともと要件を確定してからプロジェクトがスタートしていれば、プロジェクトの途中で発生する要件変更も原因を明らかにしやすくなります。また、要件が確定しているということは、作業総量を把握しやすくなりますから、より精緻な進ちょく管理をしやすくなります。

　「要件には書いてないけど、察してくれよ」という「なあなあ」な発想は、この工事進行基準の適用プロジェクトに関しては捨てるべき発想です。

　さて、（1）〜（3）まで進ちょく管理に大きな影響を与える3点について見てきました。よくよく眺めてみると、これまでも客観的・定量的なマネジメントを目指してきたプロジェクトマネージャにとって、困難な点はあったでしょうか。

　プロジェクトマネージャはこれまで、あいまいな要件のコントロールに苦心してきました。今後は、要件の確定に向け開発委託側から積極的に協力を得ることができるはずです。

　これまで、どうしたら進ちょく管理の精度を向上できるかについて常に改善を目指してきたはずです。今後は、そうした悩みの中で身に付けてきたスキルが大いに生きます。また、その取り組みが、信頼に足りるものであれば「プロジェクトマネジメント」という行為に対して十分な報酬を得やすくもなります。

　プロジェクトマネジメントという役割・重要性をより強く認識してもらうことのできる絶好の機会のように思うのですが、いかがでしょうか？

補足

WBS（Work Breakdown Structure）

プロジェクトをより細かいタスクに分解して表現した図表。またはそれを通してプロジェクト全体を把握する手法です。

EVM（Earned Value Management）

予算と実績を基に、プロジェクトが現在どのような状態にあるかを定量的に評価するための手法です。本連載の第3回で詳細を説明する予定です。

今後の進ちょく管理に求められるエッセンス

　プロジェクトマネージャの立場で工事進行基準に適応可能な進ちょく管理を行うためには、どのような準備が必要でしょうか？

　前提として、おそらく工事進行基準の適用を受けるのは、数年にわたって続くような大規模な案件であることがほとんどだと思います。しかし、そうした大規模プロジェクトにかかわる機会のあるプロジェクトマネージャは、すべてのITエンジニアの割合で考えると、少数派かもしれません。また、そのような大規模プロジェクトを多く抱える企業では、どのように管理業務をこなしていくかのルール化（マニュアル化）が進んでいて、個人の判断の余地は少ないと思われます。

　しかし、そのプロジェクトの一部が再委託や再々委託という形ですそ野が広がっていけば、関係するプロジェクトマネージャも多くなりそうです。進ちょく状況の報告を求められることもあるでしょう。そのときに、まさか「進ちょく度は感覚で決定しています」というわけにもいかないでしょう。

　次回は、プロセス改善のためのガイドラインであるCMMIをご紹介する予定です。工事進行基準に対応可能なプロジェクトマネジメント能力という点では、そのレベル2相応のプラクティス（実現ゴール）は身に付けておきたいところです。今回はその前提で、簡単な質問を読者の皆さんにさせていただきたいと思います。そして、次回で踏み込んで説明する予定です。

【工事進行基準適応度（可能性）チェックリスト】

最初に種明かし。チェックした数が多いほど工事進行基準に基づく進ちょく管理への順応度が高いといえます。

• （1）要件の獲得時には、RFPがあったとしてもより多くの関係者からヒアリングや説明を受け要件を定義するようにしている
• （2）要件定義時には、クライアント部門間のいい争いのような議論も有意義に感じる
• （3）要件定義書には、やることだけでなく、やらないこと（やれないこと）も明示的に記載するようにしている
• （4）プロジェクト計画時に参照する過去のプロジェクト実施結果（生産性など）を持っている
• （5）プロジェクト計画時のタスクは1週間程度を目安に区切っている
• （6）プロジェクト実施時に、全員が共有する進ちょく状況報告ルール（○○が完了したら50％など）が定義されている
• （7）プロジェクト計画は、定期的に更新している
• （8）「こうなったら対応策発動」のようなタイミングを、客観的な指標で決めている
• （9）開発委託先の進ちょく報告時は、前回の報告と対比し、不審な点があれば必ず確認するようにしている
• （10）例えばEVMSのように、予定と実績を感覚ではなく機械的に行う仕組みを導入している

　それでは次回の記事でまたお会いしましょう。

筆者プロフィール

高田 淳志（たかだ あつし）

株式会社オープントーン 取締役

「これから始める進ちょく管理」バックナンバー

• Microsoft ProjectでEVMに挑戦！
• EVMで進ちょく管理も予測も実現
• 進ちょく管理で実践したいプラクティス
• 工事進行基準が進ちょく管理に変化をもたらす