進ちょく管理で実践したいプラクティス：これから始める進ちょく管理（2）（2/3 ページ）

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

PMBOKでの進ちょく管理

　ソフトウェア開発の現場では、「進ちょく管理」とまったく関係のないタスクなどないに等しいのですが、特に深いかかわりを持つ知識エリアが「タイムマネジメント」と「コストマネジメント」です。

　タイムマネジメントはさらに5つの細かいプロセスに分類されています。その1つ「スケジュール・コントロール（スケジュール管理）」について、取り上げてみます。

補足

プロジェクト管理に関する書籍によっては、「スケジュール・コントロール」が「スケジュール管理」と訳されているものもあります。その訳が間違っているとは思わないのですが、読む人によって解釈が変わってしまいやすいように思います。

皆さんは、管理という単語を聞くと、「監視・監督し、その結果を記録する」という受動的な行動のイメージを強く感じないでしょうか。しかし、PMBOKやCMMIを含め、プロジェクトマネジメントにおいての「管理」とは、事実の収集はもちろんのこと、さらにはその分析、そして分析結果に基づく対策の実施をも含め、かなり積極的な行動までを含めた意味で使われることがほとんどです。

そういった意味で、私は「管理」というより「コントロール（制御）」と表現した方が正確に伝わるのではないかという印象を持っています。皆さんはいかがでしょうか。

スケジュール・コントロールとは

　スケジュール・コントロールは、以下を目的とするプロセスです。

1. 納得できる変更となるように、スケジュールの変更をもたらす要因に働きかけること
2. スケジュールが変更されたことを確定すること
3. 変更の発生に際し、実際の変更をマネジメントすること

　スケジュール・コントロールに必要な入力情報として、「（1）プロジェクトスケジュール」「（2）実績報告書」「（3）変更要求」、そして「（4）スケジュールマネジメント計画書」の4つが想定されています。（1）プロジェクトスケジュール、（2）実績報告書は詳細を説明するまでもなく、ほとんどのプロジェクトマネージャが作成・活用していると思います。

図1　スケジュール・コントロールは、タイムマネジメントに属している

　これら4つのうち、（3）に変更要求が挙げられていますが、これは何でしょうか。

　PMBOKは、「当初の計画どおりに遂行されるプロジェクトはほとんどない」という前提で構築されています。そこで、計画を変更する一要因となる何かしらの変更要求についての情報を必須入力情報としているのです。ここには、「発信手段（口頭か、文書か）」「発信元（顧客要求か、開発要求か）」「強制度（法的要求か、規格要求か、任意か）」などの情報が含まれます。

　さらに（4）スケジュールマネジメント計画書が必要とされています。これは、スケジュールに対する変更をマネジメントする方法を規定したものだと考えてください。工事進行基準適用時は、大きなスケジュールの変更は企業会計に影響を及ぼしていきますから、「何をしきい値として変更をやむなしとするか」「どのような承認フローとするか」など、スケジュール変更への対応策を、プロジェクト計画の一部として、事前に顧客と調整・合意しておくことが、より重要となるでしょう。

　また、「ツールと技法」では明確に「（4）プロジェクトマネジメント・ソフトウェア」が定義されています。「（2）実績測定」した結果を基に、計画と実績値の「（5）差異分析」を行い、さらには新たな要求事項に対応するタスクについて「（3）追加の決定」を行う。そのような一連の作業を迅速に実施するには、ソフトウェアの存在は欠かせないと考えているわけです。

　「スケジュール管理」とか「予実管理」と聞くと、ガントチャートを思い浮かベル人が多いと思います。ただ、ガントチャートは、多くのプロジェクトデータの中からスケジュールに関する一部を抜き出して表現したビュー（見え方）にすぎません。

　私は普段、マイクロソフトのプロジェクト管理ソフトウェア製品である「Microsoft Office Project（MS-Project）」を使用してプロジェクトデータを管理しています。

　スケジュールデータやリソースデータ（人員および各人員の単価、稼働状況など）、コスト消化状況（アーンド・バリュー・マネジメント：EVM）を利用した予定・実績情報など）を入力して調整を図るのですが、ある程度は自動的にソフトウェアがやってくれるおかげで、「考える」部分により多くの時間を割くことができます。それでも、結構な時間がかかります。

　そのようなデータの入力や加工に多くの時間を割くのではなく、それに対するコントロール策を練るのがプロジェクトマネージャ本来の仕事のはずですから、プロジェクトマネジメントに特化した機能を持つソフトウェアを導入することは必須であると考えられます。

補足

私はプロジェクトの特性ごとに「MS-Project」のテンプレートを何種類か使い分けるのですが、どのテンプレートにも共通の仕組みがあります。

それは、いくつかの計測項目（開始・終了日やコストなど）にしきい値を設定しておき、予定どおりであれば「黄色」、計画より良い方向に乖離（かいり）している場合は「緑色」、悪い方向に乖離している場合は「赤色」のスマイリーアイコンを表示するようにし、状況を概観できるようようにしています。

ですから、順調でない状況でMS-Projectのファイルを開くと、まさしく真っ赤に炎上したタスク一覧画面が表示されてしまいます。自分自身を鼓舞、追い立てるためのこのような工夫も、プロジェクトマネージャには必要かもしれませんね。

コストコントロールについて

　次にコストマネジメントの中のコストコントロールについて、スケジュール・コントロールと重複する部分の説明は割愛し、コストコントロール固有の内容について説明することにします（図2）。

図2　コストコントロールはコストマネジメントに属する

　コストコントロールは、通常はスケジュール・コントロールと合わせて実施されていることがほとんどだと思います。例えば、100人月相当のソフトウェア開発だとしても、「10人／月×10カ月」体制で開発するのと、「5人／月×20カ月」体制で開発するのとでは、必要コストも変わってきます。そのように、スケジュールとコストはお互いに影響を及ぼし合う関係にあり、スケジュールとコストの両方を複合的・総合的に検討して決定していく必要があるからです。

　そのため、入力情報のほとんどはスケジュールコントロールの場合と同じですが、「（1）コストベースライン」という定義が含まれています。

　ベースラインという表現は、この後説明するCMMIでも使われます。「ある時点での基準値」と考えると理解しやすいでしょうか。PMBOKに限らず、比較的新しい開発プロセスや知識体系では、ほぼすべて「プロジェクトは変化しながら進行するものである」という前提に立ち、それへの対応を含んだ内容となっています。

　前提が変化すれば当然、プロジェクトのスコープ・スケジュール・コストも、変化することになります。そこで、「現在の計画」を「ベースライン（基準）」と呼んでいるのです。

　つまり、コストをコントロールしていくうえでは、スケジュール計画と同様に現時点で適正かどうかを判断するための「コスト計画」のようなものが必要で、それを「コストベースライン」と表現しているわけです。ソフトウェア開発では、原価のほとんどを人件費が占めますから、例えば、「もともと5人で完了すべきタスクに、倍の10人をアサインした結果、予定どおりには完了した」という状況が、プロジェクトの最終コストに及ぼす影響を、当初の計画とその時点での消化コストの差異分析を行って定量的に把握するための入力情報です。

　コストベースラインを含むそれらの入力情報を基に、ツールと技法に定義されている「（3）EVM」を使用して将来予測し、アウトプットにある「（4）完成時総コスト見積もり」を算出するわけです。EVMについては、次回に詳細を解説したいと思います。