プロジェクト管理:プロジェクトを可視化する重要性(その6)
2016-10-05
メトリクス管理の仕組みづくりの際に陥りがちな過ちの一つが、取れるデータは何でも取ってしまい、手間がかかることです。そうならないためには、プロジェクトの開発活動を特定する必要最小限なデータを知っておく必要があります。適切なプロジェクトのインプットとアウトプットを選ぶことで、プロジェクトの振る舞いが把握できます。
このようなデータ一式を基本メトリクスセットといいます。プロジェクトに対するインプットとしては開発工数、アウトプットとしてはWBS要素、作業成果物、不具合の三つ、合計4種類のデータ(メトリクス)があります。
開発工数を収集することにより、開発のどの作業にどれだけの時間をかけているのかが分かります。WBSとアクティビティーの2軸を使うことで、作業進ちょくなどプロジェクトの振る舞いをさまざまな視点から把握できる重要なメトリクスとなります。
WBS要素を集計することで、作業項目数(WBS 要素数)で進ちょくを把握できます。WBS要素ごとに作業の着手予定日や完了予定日なども管理しておけば、いろいろな見方ができます。例えば、遅れを生じている作業項目(WBS要素)の個数により、遅れの度合いを把握できるなどです。
開発の各工程における作業成果物のサイズ(量)を計測すれば、各工程の作業進ちょくが分かります。ただし、計測対象を決めるのは簡単ではありません。作業成果物は開発工程で変わります。従って、開発工程が明確に定義されている必要があります。その上で、①開発工程ごとに作業進ちょくに合わせて作成される作業成果物を洗い出す。②その作業成果物が一定のフォーマットやルールに基づいて作成されることを検討する。③その作業成果物のカウント方法を検討し実現する。という手順を通じて実際のメトリクスを決めます。図3は、工程ごとの管理指標の例です。これは、工程ごとにプロダクト・メトリクスを決めます。メトリクス間で見積もりモデルが作成できれば、作業時間や品質が予測できます。
図3.プロダクト・メトリクスの定義例
開発工程定義によって、各工程での作業や入力物、開始条件、終了条件、出力物などが明確なら、各工程での成果物を特定するのは難しくありません。ただし、作業成果物をカウントする際のバラつきをなくすため、それぞれの作業成果物のフォーマットや作成手順が標準化されている必要があります。「サブアセンブリ」が作業成果物となっているが、サブアセンブリは回路ブロックやソフトウエアモジュールのことで、ほかとのインタフェースが明確になっていることや一定の表記方法があることなどが前提条件です。「コンポーネント」なども同様です。
開発工程ごとの管理指標が決まれば、管理指標間の関係式ができます。管理指標間は一定の相関を持つことが多いようです。そして図3のように、すべての工程で管理...
指標間の関係式が作れれば、ある工程の作業成果物を計測することで、それ以降の工程の作業成果物を見積もれます。最終的には必要工数まで見積もれます。
評価やテストにより検出した不具合を計測したものです。不具合として記録する属性の中に、起因工程、障害部位などを含んでいることが大切です。不具合は前述のプロダクト・メトリクスの一つですが、品質などの非常に重要なデータとなるため別扱いにしています。
次回、その7では、基準モデルについて解説します。