ソフトウェア開発の成果物による進捗管理 プロジェクト管理の仕組み (その16)

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
スタートアップ知財支援とは 新規事業・新商品を生み出す技術戦略(その67)

1. 特許庁主催の知財活動表彰ニュース  2020年3月19日、特許庁のスタートアップの支援やイベントの開催を行う知財コミュニティポータルサイト「I...

1. 特許庁主催の知財活動表彰ニュース  2020年3月19日、特許庁のスタートアップの支援やイベントの開催を行う知財コミュニティポータルサイト「I...


GTE法 【快年童子の豆鉄砲】(その50)

  1.GTE法 夢商品の開発・商品化で、受注側にとって最も難しいケースが「夢」の所在が顧客にある場合です。しかも、その夢は、商品化でき...

  1.GTE法 夢商品の開発・商品化で、受注側にとって最も難しいケースが「夢」の所在が顧客にある場合です。しかも、その夢は、商品化でき...


時間軸(Time) 普通の組織をイノベーティブにする処方箋 (その53)

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...

        イノベーションに必要な要素を表したKETICモデルの2つ目、Experience(経験)の解...


「技術マネジメント総合」の活用事例

もっと見る
スーパーマンではなくプロフェッショナルな技術者に(その3)

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...


材料研究、最適化のワナと温故知新の事例

  1.  材料研究と最適化  材料研究の場合、「最適化」という言葉でモノを考えない方がいいでしょう。  若い人、時にはおじ...

  1.  材料研究と最適化  材料研究の場合、「最適化」という言葉でモノを考えない方がいいでしょう。  若い人、時にはおじ...


トレーサビリティの保証 プロジェクト管理の仕組み (その44)

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...