メディア

構成管理とプロジェクトマネジメントの関係：意外と知らない構成管理の正体（最終回）

» 2005年01月07日 12時00分公開

[今村智，ボーランド]

プロジェクトマネジメントとは何か

　プロジェクトマネジメントとは何でしょうか？形式ばった定義ではなく、現実に求められるものとしてはどのように表現できるでしょうか？（プロジェクトマネジメントを）極めて簡潔に表現すると「プロジェクトの計画とそれに対する現実との差異を認識し、プロジェクトの最終ゴール達成のために、継続的に、適切な軌道修正を行っていくこと」だと考えられます。

　ちなみに、PMP（プロジェクトマネジメントに関する国際資格。Project Management Professionalの略）の教科書には「プロジェクトマネジメントとは、計画を策定し、プロジェクト計画書を実行に移し、進ちょくと成果を測定するプロセス」とあります。また、PMBOK（注1）ガイドでは「プロジェクトの要請に応えるために、知識、スキル、ツール、技法をプロジェクトアクティビティへ適用すること」と説明されています。

　両者とも、背景にある考え方に大きな違いはありませんが、作業の軌道修正を継続的に行うことが要（かなめ）となります。マネジメントというよりは、コントロールといった方が適切かもしれません。なお、プロジェクトの計画とはQCD（品質、納期、コスト）に関する目標達成に至るまでの計画です。単純なスケジュール線表ではありません。

　さて、本連載をここまでご覧いただいている読者の方々であれば、上で述べた“計画”と“現実”のどちらも、構成要素として構成管理の配下に置けることをご理解いただけると思います。そこで、今回は、これまでのまとめも兼ねて、構成管理を実施することによって、どのようにプロジェクトマネジメントに役立つのか？という視点で解説したいと思います。

　ただし、これらを徹底的にやろうとすると、何らかの構成管理ツールを使わないことには、人手が掛かり過ぎてとても現実的でない内容も多くあります。ただ、本連載は構成管理の本質的な考え方の解説に重点を置いていますので、ツールを使った具体的なHowToの解説は避けさせていただきます。私がお伝えしている内容は、程度の差こそあれ、現時点で入手可能な構成管理ツールを使うことで、かなり自動化、効率化が可能です。決して理想論だけを語っているのではないことをあらかじめお伝えしておきます。

　構成管理を軸に以下のトピックに絞って解説を行います。

見積もり
リスク管理
スケジュール
品質保証と監査

　なお、「変更管理」も重要な要素ですが、「変更管理」については「第3回変更管理、その正体と対策」の記事を参照ください。

見積もり

　それでは、見積もりから始めましょう。見積もり手法にはいろいろあることはご存じのとおりですが、乱暴ないい方をすれば、どのような手法を用いようとも基本は同じです。見積もりとは、ソフトウェアあるいはタスクの規模を測り、その実現にどれだけのコストを要するかを予測するという行為を指します。

　十把ひとからげの人月見積もりの是非について、いまさらここで論じることはしません。しかし、原価をあらかじめ見込んでおくことはとても重要です。人月という単位が問題なのではなく、「十把ひとからげ」が問題なのです。私の場合、要求の実現に必要な工数を、基本工数と重みの積算で求めます。重みは、処理の複雑さや技術的な難易度などで決まります。ポイントは、基本工数の前提となるスキルレベルを設けているということです。そして、そのスキルレベルの開発者でチームを構成することを前提とします。前提となるスキルレベルを満たすことができない場合には、重みの決定要因に担当者のスキルレベルを加えて、さらに調整することになります。

　さまざまな種類のプロジェクトを見てきて不思議に思うのは、「この規模なら＊＊人月」と非常に安易に工数を出しているプロジェクトが多いことです。人月工数を求めるのであれば、せめて「この規模で、このレベルの開発者であれば＊＊人月」というべきではないでしょうか？さて、少し脱線しましたが、それでは基本工数はどのようにして決めればよいのでしょうか？

　要求の規模を安定的に求めるために、要求定義の方法、要求の粒度を極力そろえることが必要です。そのうえで、その規模の要求の実現に、どのようなスキルプロファイルの担当者が、どれだけの工数を要したかを計測します。計測といっても方法は極めて単純です。各担当者には、毎日の終わりに必ず成果物を構成管理システムにチェックインしてもらいます。

　その際、その日の成果物の作成に要した時間もコメントなどで入れてもらうようにします。このことで各担当に余計な負担が掛かることはほとんどありません。「データがない状態では、工数を見積もることができないじゃないか！」と思われた方もいらっしゃるかと思います。それはそのとおりです。まったく何もない状態から、統計的に根拠のある数値は出せません。ですから、最初は“経験から来る勘”に頼らざるを得ないのは仕方がありません。あるいは、アプリケーションのタイプ別ファンクションポイントベースの標準データなるものもありますので、そちらを取りあえず使ってみるという手もあります。運良くピタリと当てはまることもあれば、皆さんの組織には全く当てはまらないということもあるはずです。

　だからこそ、今後は構成管理の仕組みを通して経験を数値化して残していこうということなのです。ものすごく精度の高い勘を持っている人がときどきいますが、それはその人の中で経験が数値化されているからです。とはいえ、そのままでは会社組織の経験として蓄積することはできません。データとして継続的に取り続け、それを組織内で共有できるようにすることで、経験の浅い人間でも見積もりの精度を上げることが可能になります。確かに、いままでこのようなデータを継続的に蓄積していない組織にとっては、明日の提案書のための見積もりには全く役に立ちません。データの蓄積を始めなければ、いつまでたっても変わらないのです。そこで、各担当者にできるだけ負担を掛けずに実績工数データを収集することを考えたとき、構成管理のシステム、プロセスを通してそれらを収集することはとても有効です。間違っても、進ちょく会議を開催して報告してもらうというような、時間の浪費だけは避けたいものです。

リスク管理

　リスク管理といっても、ここでお伝えするのは、リスク管理そのものについてではありません。プロジェクトには、それはそれはたくさんのリスクがあることは、＠ITをご覧の皆さんはすでに身をもって経験なさっていることと思います。例えば、PMP教科書に載っているほんの一例を挙げると、

予算／資金
スケジュール
スコープまたは要求の変更
技術問題
人事問題
ハードウェア
政治的な懸念
ビジネスリスク
法的リスク
環境リスク

などがあります（くどいようですが、あくまでも一例にすぎません）。

　実際のプロジェクトでは、さらに掘り下げて潜在リスクを識別し、それらが顕在化してきたときにどのような対処を行うかも決めておくことが必要となります。トム・デマルコ氏は、これらとは少し違った視点でのリスクのとらえ方をしており、ツールも提供しているので、そちらも参考にしてください（Riskologyを参照）。

　さて、リスク管理を行ううえでのポイントは、リスクの兆候をどれだけ早く認識できるかということです。例えば、前項の内容にも関連してきますが、各担当者の実績作業時間を毎日収集することで、オーバーワークになっていないかを日々確認することができます。また、不具合情報も構成管理化で一元管理することで、どの担当者の成果物に不具合が多く発見されているのか、ということも日々確認することが可能になります。ここから、メンバーの過労、不満、その他モチベーションに関する問題を発見できるかもしれません。

　あるいは、いつまでたってもステータスが変わらない課題がどれだけあるかを、リアルタイムに知ることによって、組織的なコミュニケーションの問題、背景にある法制度の改正との関係などに気付くかもしれません。繰り返しになりますが、大切なことは、できるだけリアルタイムにプロジェクトの状態を把握し、そこからリスクの兆候を見つけ出すことです。そのために、プロジェクトを丸ごと録画したかのような構成管理の仕組みを構築することは有効な手段となります。

スケジュール

　スケジュールは、プロジェクト完了までの道のりを、タスクのつながりとして表現したものです。そして、日々の活動においては、進捗という視点で扱われています。成果物を生み出すすべてのタスクをWBS（Work Breakdown Structures）として定義し、各タスクの進み具合から、プロジェクト全体の進み具合を把握し、適切なコントロールを行うことが進捗管理です。

　各タスクの進み具合は、「見積もり」の項で書いたように、構成管理の仕組みを通して作業時間を収集することによって、各作業者に余計な負担を掛けずに“消化時間”を把握できるようになります。しかし、消化時間だけでは、本当にそのタスクが予定どおりの期日に完了するかどうかの判断はできません。そこで、消化時間とともに、何らかの方法でタスクの進捗状態として進捗率を把握する必要があります。

　このタスクの進捗率は、どのプロジェクトでも扱いに困っている代表選手です。各担当者に進捗率として聞くと、80％くらいまでは一気に進捗し、その後は急に進捗しなくなるということは皆さんご存じのとおりです。そこで、有効な手段の1つとして、各成果物のステータスを細かく定義し、それぞれのステータスごとに進捗率を割り当てておくことで、進捗を把握するというものです。各担当者は、成果物を構成管理システムにチェックインするときに、ステータスを登録するだけですから、こちらも余計な負担を強いることはありません。

　ここで重要なポイントとなるのは、以下の2点です。

各タスクの完了までの期間が長くなり過ぎないようにすること

→長くとも3週間を目安とし、これ以下になるようにタスクを分解する

各ステータスにとどまる期間が長くなり過ぎないようにすること

→長くとも5日を目安とし、これ以下の期間で遷移するようにステータスを設定する

　さて、ここまで書いておきながらこのようなことをいうのもどうかと思うのですが、私は、進捗率を細かく把握することの意義には疑問を持っています。というのは、経験的に、細かく進捗を把握した場合と、そうしなかった場合でのプロジェクトの目的達成における違いがほとんど感じられないからです。

　実際にはどのようなレベルで進捗を見ることが多いかというと、各成果物が完成したか、完成していないか、つまり、0％か100％のどちらかのみです。お気付きの方も多いと思いますが、SCRUMに似たやり方です。また、これもSCRUMと同様ですが、日々、各担当者に「後何日で成果物が完了するか？」を作業時間とともに教えてもらいます。これは、日々作業を行う中で担当者の作業見積もりの精度も上がるため、スケジュール調整の判断に非常に有効なデータとなります。

　詳細については、別の機会にでもお伝えできればと思いますが、このような進捗管理を行うには、進ちょく管理のテクニックだけをまねしてもうまくいきません。プロジェクトの開始段階から、そういった進捗管理でもうまくチームが機能するような準備、仕掛け作りが必要だからです。ただ、どれだけの細かさで進捗を把握するかとは別に、進捗の基本は成果物の完成度で決まるという考え方に立てば、進捗の把握に構成管理の仕組みを利用することは、自然なことであるとご理解いただけると思います。

品質保証と監査

　品質保証については、「何をもって品質保証とするか」を定義しなければ始まりません。そこで、まずは品質とは何かを確認しておきましょう。

　品質とは、システムに求められる機能／非機能要求をどれだけ満たしているかです。そして品質保証とは、品質がある水準以上にあることを保証することです。システム開発においては、各機能／非機能要求に対応して、それらの実現の確認方法をテストケースとして定義し、テスト結果をもって最終的な品質の保証としています。

　しかし、これでは入力（前工程の成果物）→処理（設計、実装、テストなど）→出力（成果物）という開発活動の構成中の、最終出力に対する品質を保証したにすぎません。最終出力のすべてをテストし保証することの難しさとコストの問題、さらには最終出力の作成に掛けたコストが適切なものかどうか（本来必要ないお金をお客さまからもらっていないか？）という疑念に対処するためには、処理に対する品質も保証すべきです。つまり、合意の下に定められたプロセスが守られていることの保証です。これを行うのが監査ということになります。

　構成管理の仕組みを工夫して使うことによって、テスト結果の集計や、障害情報のステータス追跡、成果物への変更手続き、変更履歴の確認のほとんどを自動化することが可能になります。連載第1回にも書きましたが、構成管理を単なるバージョン管理と考えるのではなく、プロジェクトを丸ごと組織の資産として管理することというように考え方を変えることで、非常に効果的な取り組みとすることが可能になることをご理解いただけたのではないでしょうか。これらは、それなりの工数を掛けて頑張れば、すべてを人手で行うことも不可能ではありませんが、どのような長期的視点をもって、何に重きを置くかをよく検討し、適切な費用配分で取り組むことが大切なことはいうまでもありません。

（注1）PMBOK

プロフィール

今村智（いまむらさとし）

　メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。個人Webサイト(http://www.human-process.com/)からの情報発信

も行っている。

「意外と知らない構成管理の正体」バックナンバー