6．プロジェクト管理サイクル
メトリクスを使ったプロジェクト管理サイクルは、次の①～④の流れです。
① 基準モデルを使って見積もりを作成する
② 可視化のための実績データを収集する
③ 予定と実績の差を進ちょくメトリクスによって管理する
④ 開発終了後、基準モデルを改善する
② 可視化のための実績データを収集する
③ 予定と実績の差を進ちょくメトリクスによって管理する
④ 開発終了後、基準モデルを改善する
大切なのは、このサイクルをすべてのプロジェクトで実行すること、サイクルの各ステップで適切な方法論、技法・手法、ツールを使うことです。徒手空拳で仕組み作りをすることは可能ですが、大変な時間がかかります。まずは、技法・手法を導入し、確実に仕組みを運用できるようにするべきです。
7．WBSとアクティビティー
実績データを収集するのは手間がかかります。このため、収集するデータを特定するための軸を適切に設定することが重要となります。では、手間を最小限にして最大限にデータを活用できる軸とは何でしょうか。それが、WBSとアクティビティーです。WBSとは、 Work Breakdown Structureです。プロジェクト管理において、遂行に必要なあらゆる作業を洗い出し、プロセスや責任範囲・管理範囲といった管理しやすい単位で階層化して表現したものを指します。WBSとアクティビティーの2軸により開発作業を特定するのです（図1）
図1.アクティビティーとWBSによる2次元管理
WBSは開発作業の範囲を特定する軸で、進ちょくの管理単位となります。アクティビティーは開発作業工程、つまり作業の流れを特定する軸である。最初にアクティビティーについて解説しよう。開発作業の流れは大きく、企画、設計、製造、評価などの開発工程で表される。それを分解したものがアクティビティーである。通常は3レベルくらいまで分解します。アクティビティー軸を明確にするには、開発工程をしっかりと定義しておく必要があります。開発対象と独立して、共通に定義できるものを抽出します。開発工程の定義には、個々の作業の説明のほか、作業の目的、開始条件、終了条件、入力物、出力物、責任者などを含めておきます。
次にWBSとは、開発作業全体を階層的に詳細化した構造のことです。分解した一つひとつの要素をWBS要素、または単にWBSと呼びます。WBS要素を積み重ねると開発作業全体になります。開発対象の分解の仕方で、進ちょくを管理する単位が決まるため、WBSの作成には十分に注意が必要です。PMBOKなどの普及で、WBSの重要性は広く知られてきました。しかし、どういう単位で進ちょくを管理するかが明確になっていないプロジェクトは多いようです。
WBSは進ちょくの単位なのですが、運用するには注意が必要です。メトリクス管理でのWBSは、一般的なWBSと考え方が少し違います。一般的なWBSでは、作業の分解の方法が明確ではなく、図2（a）に示すようなものが多いのです。これは、開発対象と開発行為を同じレベルで扱っているため、進ちょく管理には向いていません。
図2.WBS の考え方(a)
「デバイスドライバの製作」というWBS要素がありますが、製作（コーディング）という作業行為とデバイスドライバという作業対象とが一緒で、進ちょく管理単位としては使いづらいようです。この場合、デバイスドライバの開発進ちょくや、製作作業の進ちょく度合いを知ることは困難です。メトリクスの仕組みでは、作業行為を含まず作業対象だけにしてWBSを作成します。前述の例では「デバイスドライバ」となります。開発対象だけに注目してWBSを作成したのが図2（b）です。これは、メトリクスの仕組みでは、 WBS は開発対象のみに限定して作成し製品の内部構造と一致させます。
...
図2.WBS の考え方(b)
WBSは製品の内部構造と一致します。このように、WBSとアクティビティーという相互に独立した軸でデータを特定することで、データが最大限に活用できます。例えば開発工数なら、製品構成上の任意の範囲でかかった工数が分かります。図2（b）に示す製品全体はもちろん、処理エンジン部分だけの工数も分かりますし，処理エンジンの一部である画像処理コア部分だけの工数も分かります。また、入力機などの任意の範囲で、発生している工数が設計なのか製造なのかの把握も可能です。さらに、評価に時間が掛かっている部分（WBS要素）はどこか、手戻りが多いチーム（WBS要素）はどこかなども分かります。