前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについて解説しました。前回はハードウェア開発中心の解説でしたので、今回はソフトウェアの成果物メトリクスについて解説します。
ハードウェア開発の場合、設計部門は、購買や生産管理、工場技術、製造など多くの関連部門との関わりを持つ必要があるため、ある意味強制的に進捗や設計内容を整理しおく必要がありますし、回路図や基板などのモノを見ればだいたいの状況はわかります。したがって、進捗はある程度把握できるものです。一方、ソフトウェア開発の場合は、技術部門だけで一通りの開発作業ができてしまうことや、ハードウェアを組み合わせて動かしてみないと確認が難しいことなどから、進捗や設計内容はブラックボックスになりがちです。したがって、意識的に進捗を見える化して外部に伝えることが重要です。
このような要求に応えるために、すでに多くのソフトウェア開発現場では作業成果物を使った進捗の見える化を行っています。たとえば、プログラム・ステップ数は多くのところで収集され、進捗指標として利用されています。そういう意味では、ソフトウェア開発における作業成果物メトリクスはなじみのある考え方ですが、確認のためそのポイントを整理しておきましょう。図47 をご覧ください。
図47. 作業成果物メトリクスの条件
この中で、「作業量との相関があること」というのは、あまり意識していない場合があります。たとえば、ほとんどのソフトウェア開発現場で収集しているプログラム・ステップ数は、作業量との相関が高いことがわかっているから指標として使われているのです。しかしながら、ステップ数に対して複雑なカウント方法や計算を行っているところに出会うことがあります。流用の場合には流用元の関数全体のステップ数にある係数を乗じて加算するとか、開発中に削除したプログラムについてもそのステップ数にある係数を乗じて加算するとか、これらの係数もいろいろと場合分けされているとか、いろいろと手の込んだ方法をとっているところがあります。
理由を聞くと、「削除しているプログラムも作業の結果なのだからカウントするべきだ」というような説明があり、一見すると論理的根拠のある計算方法のようにも思えるのですが、ここで問題なのは、このような計算方法にすることが妥当かどうかを検証していないことです。工数などの実際の作業量との相関が高いかどうかを検証した上で、計算方法が妥当かどうかを判断する必要があるのです。ただ多くの場合、複雑にしてもその相関が高くなることはまれです。作業成果物メトリクスで忘れがちなことがもう一つあります。作業成果物は開発工程ごとに違うということです。
ソフトウェア開発では、開発工程を定義して工程ごとのインプットやアウトプットなどの定義を明確にすることが基本ですが、この開発工程定義によれば作業成果物は工程ごとに違うとなっているはずです。これは、進捗管理のための作業成果物メトリクスは工程ごとに違うということです。したがって、工程ごとに図47の条件を満たす作業成果物メトリクスを整備する必要があります。
図48. 開発工程ごとの作業成果物メトリクス例
図48 はソフトウェア開発工程と作業成果物メトリクスの例です。この図では工程ごとに一般的な作業成果物メトリクスを記載しているのでわかりやすい例になっていると思いますが、実はこの中には適切ではないメトリクスが含まれています。わかりますか？
それは要件定義工程です。「仕様書項目数」や「仕様書ページ数」が仕様書作成までの作業量に比例した値になることは非常にまれだからです。一般的に、仕様書の書き方は明確に定義されておらず、人やプロジェクトによってかなりバラツキがあります。また、以前の仕様書を流用して作成することも多いと思いますが、一般的な仕様書ではその際のカウント方法を決めるのは非常に難しいことになります。普通の仕様書というのは表現や内容の制限が緩くて自由度が高いため量のカウントに向いておらず、また、記述の基本単位を特定することが難しいので、測定対象のバラツキが大きなものになってしまうのです。
したがって、要件定義工程で適切な作業成果物メトリクスを設定する場合には、まずは、ユースケースやシナリオな...
