Club-Zコラム第17回

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | コラム | グローバル化は設計・製造の仕組みを見直すチャンス | 第17回 | P2 |

更新日 2016-01-20 | 作成日 2007-12-03

コラム


グローバル化は設計・製造の仕組みを見直すチャンス

【第17回】ソフト作業成果物による進捗管理は相互の関連づけでパワーアップ!

株式会社RDPi  代表取締役 石橋 良造


2008.12.18

作業成果物メトリクスで忘れがちなことがもう一つあります。作業成果物は開発工程ごとに違うということです。

ソフトウェア開発では、開発工程を定義して工程ごとのインプットやアウトプットなどの定義を明確にすることが基本ですが、この開発工程定義によれば作業成果物は工程ごとに違うとなっているはずです。これは、進捗管理のための作業成果物メトリクスは工程ごとに違うということです。したがって、工程ごとに図47LinkIconの条件を満たす作業成果物メトリクスを整備する必要があります。

column_20081218_2.JPG

図48 はソフトウェア開発工程と作業成果物メトリクスの例です。この図では工程ごとに一般的な作業成果物メトリクスを記載しているのでわかりやすい例になっていると思いますが、実はこの中には適切ではないメトリクスが含まれています。わかりますか?

それは要件定義工程です。「仕様書項目数」や「仕様書ページ数」が仕様書作成までの作業量に比例した値になることは非常にまれだからです。一般的に、仕様書の書き方は明確に定義されておらず、人やプロジェクトによってかなりバラツキがあります。また、以前の仕様書を流用して作成することも多いと思いますが、一般的な仕様書ではその際のカウント方法を決めるのは非常に難しいことになります。普通の仕様書というのは表現や内容の制限が緩くて自由度が高いため量のカウントに向いておらず、また、記述の基本単位を特定することが難しいので、測定対象のバラツキが大きなものになってしまうのです。

したがって、要件定義工程で適切な作業成果物メトリクスを設定する場合には、まずは、ユースケースやシナリオなどにより要件の記述方法を標準化し、その上で、測定対象を基本ユースケースと派生ユースケースにするなどの対応をとることになります。また、流用開発がメインの場合は、仕様の変化点を抽出できる変化点管理シートのようなフォーマットを定義し、変化点という基本単位が明確になるような工夫が必要になります。

作業成果物の測定は多くのソフトウェア開発現場で行われているわけですが、このような検討が不十分なままにルールとして決まっているからという理由だけで、かなりの時間をかけて収集・管理しているようなケースも多いものです。データ収集などのオーバーヘッドが問題になっている場合は、改めて現在収集している作業成果物メトリクスが、適切な作業量との相関をもっているかどうかを確認するのが良いかもしれません。