プロジェクト測定実践記 第5回

これまでの記事ではプロジェクト測定の目的、測定したデータの分析方法や実例をご紹介しました。プロジェクト測定では機能規模の測定が必須となりますが、今回は、機能規模測定手法COSMIC法の測定コストを削減し、スピード化するための概算法をご紹介します。

概算法はCOSMIC法に基づいて概算で機能規模を測定する方法です。概算法を適用した結果、通常のCOSMIC法と比べて機能規模の測定コストが80～90%程度削減でき、より早い段階で機能規模を測定することが可能となりました。本記事では概算法の概要と測定手順、また、概算法適用の検討内容についてご紹介します。

目次

• 概算法の必要性
• COSMIC法と概算法
• 機能規模の測定方法の選定
• COSMIC法の測定手順
• 概算法の測定手順
• 概算法の適用結果
• その他の概算法
• おわりに
• 参考文献

概算法の必要性

機能規模測定の課題

私たちが行っているプロジェクト測定では、COSMIC法に基づいて機能規模を測定しています。COSMIC法は比較的シンプルな測定方法で、測定方法が一般に公開されていることから習得しやすく、これまでの測定結果からCOSMIC法で測定した機能規模が妥当であることも分かっていますが、測定するプロジェクトの大きさによっては測定コストの大きさが問題となります。

より多くの現場にプロジェクト測定を展開するには、機能規模の測定コストを削減する必要があります。機能規模の測定コストを削減することができれば、これまで測定コストが妨げとなってプロジェクト測定が難しかったプロジェクトや大規模プロジェクトの測定も可能となります。

概算法の適用検討

そこで、2012年頃から機能規模の測定コストを削減するためにCOSMIC概算法の確立と、確立した方法が実際に適用可能であるかの検討を開始しました。以降は、COSMIC概算法を概算法と呼びます。

概算法の適用可能性は、以下から判断しました。

• 概算法で測定した機能規模が妥当であること
• 概算法の測定コストがCOSMIC法と比べて削減できること

確立した概算法の説明と、概算法が適用可能だと判断した根拠については以降の章でご説明します。

概算法のメリット

概算法で測定することによって以下のようなメリットが得られます。

• 測定コストの削減
• 早い段階での機能規模の概算

◎測定コストの削減

概算法で機能規模を測定した時の測定コストは、通常のCOSMIC法で測定した時と比べて80～90%程度削減できます。これまで機能規模の測定コストがネックとなってプロジェクト測定が実現できなかった大規模プロジェクトも、概算法を適用することで測定が可能となります。

実際に、これまでに500人月を超える大規模プロジェクトの機能規模も概算法で測定しました。

◎早い段階での機能規模の概算

概算法によって機能規模測定のスピード化が実現できます。COSMIC法で機能規模を測定した場合に1ヶ月以上かかるようなプロジェクトでも、概算法で測定した場合、数日で機能規模の概算を出すことも可能です。

プロジェクト開始後の早い段階で機能規模の概算を測定できれば、その概算規模を元に見積りの概算を出すことができます。

概算法の必要性

このように、概算法を適用することで、これまで測定コストが課題となって測定できなかったプロジェクトも測定が可能となります。プロジェクトにとっては、測定結果の見積りへの応用が関心事であることが多いですが、より早く短期間で機能規模を測定できる概算法は見積りでの活用も可能にします。

つまり、概算法はプロジェクト測定を推進する上で欠かせない機能規模の測定方法と言えます。以降の章では、COSMIC法と概算法の説明とそれぞれの測定手順をご紹介します。

COSMIC法と概算法

COSMIC法のデータ移動「COSMIC機能規模測定法 ver3.0 手法概要編」の図を引用

COSMIC法とは

COSMIC法はソフトウェアの機能規模を測定する手法で、ISO標準の手法です。

COSMIC法では、システム境界をまたがったデータ移動数と永続記憶域に読み書きするデータ移動数の合計値を求めることでソフトウェアの利用者の立場から見た機能の規模を求めます。

概算法とは

前回の記事でもご紹介しましたが、概算法は、COSMIC法に基づいて概算で機能規模を測定する方法です。

COSMIC測定マニュアル応用編[1]に4種類の概算法が例示されており、私たちは、この中の「平均機能プロセス数法」を元に具体的な手順を定めて適用しました。

平均機能プロセス数法を用いた概算法では、識別した機能プロセスのうち一部をサンプリングし、これを正確に測定して機能プロセスの平均規模を決定して、この平均規模と、機能プロセスを識別して数えた機能プロセス数を掛けて概算します。式で表すと以下の通りです。

なお、サンプリング数は、これまでのプロジェクト測定の結果から機能プロセスの機能規模が正規分布していると仮定し、母平均の区間推定に基いて求めました。また、機能規模の分布は機能の処理形式（オンラインorバッチ）によって異なるため、処理形式毎に機能プロセスの平均規模を決定することにしました。

概算法の適用結果

概算法を適用したところ、測定した概算規模は妥当であり、測定コストは通常のCOSMIC法で測定したときより80～90%程度削減できることが分かりました。このため、概算法は測定コストを下げるための方法としてその後のプロジェクト測定で適用しています。

概算法の適用結果については、後の章でもう少し詳しくご説明します。

機能規模の測定方法の選定

ソフトウェアの機能規模を測定する際、COSMIC法か概算法のどちらの方法で測定するかはプロジェクト測定にかけられるコストと測定に求める精度で判断しています。COSMIC法は精密に測定できると仮定し、これに対して概算法は誤差の範囲を30%程度見込んでいます。これまでの測定実績を元に測定コストを試算した以下の表を参考にして、測定方法を選定しています。

（注1）測定コストは測定経験や機能の複雑さによって幅があるので範囲で示しました。測定コストの根拠についてはこちらをご覧ください。
（注2）概算法は誤差30%を見込んだときの測定コストを表示しています。

COSMIC法の測定手順

概算法の測定手順は、COSMIC法の測定手順の一部を簡略化したものです。このためCOSMIC法の測定経験があれば、概算法の測定を簡単に行うことができます。そこで、まず基本となるCOSMIC法の測定手順をご紹介し、その後、概算法の測定手順を説明したいと思います。

COSMIC法の測定手順

COSMIC法による測定の流れは以下の通りです。

1. 測定対象のソフトウェアの利用者機能要件を識別する
2. 利用者機能要件毎に機能プロセスを識別する
3. 機能プロセスの機能規模を測定する
4. 機能規模を集計してソフトウェアの機能規模を求める

1.利用者機能要件の識別

利用者機能要件（FUR：Functional User Requirement）はユーザの視点でとらえたソフトウェアの機能のまとまりです。ユースケースを識別している場合は、これを利用者機能要件と考えることができます。

まず、利用者機能要件を識別して利用者機能要件の一覧を作成します。

2.機能プロセスの識別

機能プロセスは利用者機能要件を構成する基本要素です。重複がなく、まとまりがあって、独立して実行可能であるものを一つの機能プロセスとして識別します。機能利用者からのトリガーによって、2つ以上のデータ移動（エントリーとライトまたはエグジット）が実行されるものが機能プロセスとなります。

画面機能の場合は、機能利用者がボタンを押すことで機能プロセスが実行されることが多いので、まずボタンなど画面上でアクションを起こすものを元に機能プロセスを識別します。例えば簡単な例では、検索ボタンがある時、検索機能プロセスを識別します。画面レイアウトが分かる画面設計書や画面モックを元に機能プロセスを識別していきます。

バッチ機能の場合、機能利用者は人ではなくタイマーかもしれません。基本設計書などを見ながら、タイマーなど何らかのトリガーによって動く機能のまとまりを確認して機能プロセスを識別します。

利用者機能要件毎に、機能プロセスを識別し、識別した機能プロセスは1.で作成した利用者機能要件の一覧に追記します。この機能プロセスの識別は、比較的簡単にできる作業です。

3.機能規模の測定

機能規模の測定は2.で識別したすべての機能プロセスを対象に行います。

機能規模の測定では、機能プロセス毎に、データグループというデータのまとまりが移動する数を数えます。データグループは論理データモデルのエンティティにほぼ相当します。

データ移動の種類は次に示す4種類です。

• エントリー（E）：システムの境界からユーザインタフェースや通信を通じて入力されるデータの移動
• エグジット（X）：ユーザインタフェースや通信を通じてシステムの境界に出力されるデータの移動
• リード（R）：永続記憶域から読み出されるデータの移動
• ライト（W）：永続記憶域に書き込まれるデータの移動

基本設計書などを見ながら、その機能プロセスでどのようなデータのまとまりが入出力され、永続記憶域に読み書きされるかを確認して記録します。データ移動の総和が機能プロセスの機能規模となります。

2.で作成した利用者機能要件の一覧に各機能プロセスの機能規模を追記します。

◎機能規模の測定の例

以下に示す簡単な例でデータ移動の数え方を確認してみます。

利用者機能要件：「顧客情報検索機能」･･･受付担当が顧客名の一部を入力して検索を実行すると、システムが条件に合う顧客情報の一覧を表示する

利用者機能要件「顧客情報検索機能」の機能プロセス：「顧客検索機能プロセス」･･･受付担当によってトリガーされ、顧客名の一部を元に検索して顧客情報の一覧を表示する機能プロセス

この機能プロセスのデータ移動を測定すると以下のようになります。

• ユーザインタフェースである画面の検索ボタンを押すことによって「検索条件」のデータのまとまりが入力される･･･エントリー（E）
• 顧客検索機能プロセスはデータベースから「顧客」テーブルの情報を読み出す･･･リード（R）
• 顧客検索機能プロセスは「顧客情報」の一覧を画面に出力する･･･エグジット（X）

上記のデータ移動の総和から、「顧客検索機能プロセス」の機能規模は3CFPとなります。

データのまとまりをどのような単位で考えればよいか、などデータグループについての詳しい説明は、別の記事「ビジネスアプリ開発者のための機能規模測定手法 COSMIC法入門」の第2回、第3回やCOSMIC機能規模測定法マニュアル[2]をご覧ください。

4.機能規模の集計

3.で測定した機能規模を集計してソフトウェアの機能規模を求めます。

COSMIC法の測定手順は以上です。

概算法の測定手順

概算法の測定手順の一部はCOSMIC法と同じです。本章では、COSMIC法と異なる手順を中心に、概算法の測定手順をご紹介します。

概算法の測定手順（COSMIC法の測定手順と異なる部分は赤枠で示した）

概算法による測定の流れは以下の通りです。COSMIC法の測定手順と異なる部分は太字で示しました。

1. 測定対象のソフトウェアの利用者機能要件を識別する
2. 利用者機能要件を処理形式（オンラインorバッチ）で分類する
   *以降の手順は処理形式毎に行います
3. 利用者機能要件毎に機能プロセスを識別する
4. 機能プロセスをサンプリングする
5. サンプリングした機能プロセスの機能規模を測定する
6. 機能プロセスの平均規模を求める
7. 機能プロセス数と機能プロセスの平均規模を掛けてソフトウェアの概算規模を求める

以下に概算法の測定手順を説明します。COSMIC法の測定手順と異なる部分を中心に記述しました。COSMIC法の測定手順についてはCOSMIC法の測定手順をご覧ください。

1.利用者機能要件の識別

利用者機能要件を識別して利用者機能要件の一覧を作成します。

2.処理形式で分類

各利用者機能要件の処理形式がオンラインかバッチを分類します。以降の手順は処理形式毎に行うため、オンラインとバッチで利用者機能要件の一覧を分けます。

3.機能プロセスの識別

利用者機能要件毎に、オンライン機能の場合は画面レイアウトが分かる画面設計書や画面モック、バッチ機能の場合は基本設計書などを確認しながら機能プロセスを識別していきます。識別した機能プロセスは2.で処理形式毎に分類した利用者機能要件の一覧に追記します。

4.機能プロセスのサンプリング

機能規模を測定する機能プロセスを選ぶため、3.で機能プロセスを追記した利用者機能要件の一覧をランダムに並び替えます。そして、上位からサンプリング数に相当する機能プロセスを選びます。これが次のステップで機能規模を測定する機能プロセスとなります。

5.機能規模の測定

機能規模の測定は4.でサンプリングした機能プロセスを対象に行います。

基本設計書などを見ながら、その機能プロセスでどのようなデータのまとまりが入出力され、永続記憶域に読み書きされるかを確認して記録します。データ移動の総和が機能プロセスの機能規模となります。

4.で並べ替えた利用者機能要件の一覧に、測定した機能プロセスの機能規模を追記します。

6.平均規模の算出

5.で測定した全ての機能プロセスの機能規模から平均規模を求めます。

7.概算規模の算出

3.で識別した機能プロセスの数と6.で算出した平均規模を掛けて概算規模を求めます。

概算規模は処理形式毎に求めるので、その総和がソフトウェア全体の概算規模となります。

概算法の測定手順は以上です。

概算法の適用結果

概算法の適用可能性は、概算法で測定した機能規模の妥当性と測定コストの削減率から判断しました。本章では、適用可能性の検討内容についてご紹介します。

概算法で測定した機能規模の妥当性

［グラフ1］プロジェクト毎の概算規模と本体コード量

概算法を実際のプロジェクト測定で使えるか判断するには、概算法で測定した機能規模が妥当かどうかの判断が必要です。概算法で測定した機能規模の妥当性は概算規模とコード量の相関から判断しました。

［グラフ1］に、測定した各プロジェクトの概算規模とコード量の相関を示します。これを見ると概算規模とコード量の相関が高いことが分かります。このことから、概算法で測定した機能規模は妥当な大きさを表していると判断しました。

コード量はソフトウェアの大きさを表す指標であるため、機能規模がソフトウェアの妥当な大きさを表しているか確認するために比較対象としています。

なお、グラフ上には概算規模で見込んでいる誤差±30%を誤差範囲として示しました。

測定コストの削減率

次に、概算法による測定コストの削減率を確認します。

◎COSMIC法の測定コスト

概算法による測定コストの削減率を確認するため、まず、比較対象となるCOSMIC法の測定コストを考えてみます。COSMIC法の測定では、以下のコストが発生します。

• ソフトウェアの全ての機能プロセスを識別するコスト
• 全ての機能プロセスの機能規模を測定するコスト

上記それぞれのコストとソフトウェアの機能プロセス数が分かれば、COSMIC法の測定コストを試算できます。上記それぞれのコストの基準値は、これまでのプロジェクト測定の実績値から以下のように定義しました。

• 1機能プロセスを識別するコスト ： 0.01人日
• 1機能プロセスの機能規模を測定するコスト ： 0.4～0.1人日

1機能プロセスの機能規模を測定するコストは、機能規模を測定する担当者の測定経験や測定対象の機能の複雑さにより幅があるため範囲で示しました。大きい方の値は初めてCOSMIC法で機能規模を測定した担当者の実績、小さい方は測定経験が豊富な担当者の実績を元に出したものです。

この基準値を元に、例えば40機能プロセスのソフトウェアのCOSMIC法の測定コストは、初心者の場合、0.01人日×40機能プロセス＋0.4人日×40機能プロセス＝16.4人日と試算できます。

◎概算法の測定コスト

概算法の測定では、以下のコストが発生します。

• ソフトウェアの全ての機能プロセスを識別するコスト
• サンプリングした機能プロセスの機能規模を測定するコスト

1点目の全ての機能プロセスを識別するコストはCOSMIC法でも概算法でも同じで、機能プロセス数に比例して大きくなります。一方、2点目の機能プロセスの機能規模を測定するコストは、サンプリング数（すなわち、機能規模を測定する機能プロセス数）が一定である概算法ではプロジェクトの規模に関わらず同程度です。この2点目のコストがCOSMIC法と概算法の測定コストの差となります。

◎測定コストの削減率

概算法で測定した3つのプロジェクトの測定コストと削減率を［表2］に示します。測定コストの削減率は、COSMIC法測定コストの推測値との比較で求めました。COSMIC法測定コストの推測値は、機能プロセス数と前節で示した基準値のうち初心者の測定コストを元に試算しました。なお、測定時期が異なるため、サンプリング数が測定手順でご紹介した数と異なることをご了承ください。

概算法とCOSMIC法の測定コストを比較すると、測定初心者の場合の測定コストの削減率は78～95%となり、測定コストが大幅に削減できることが分かりました。

以上の適用検討の結果から、概算法が適用可能であると判断しました。

その他の概算法

ここまでにご紹介した概算法は、COSMIC測定マニュアル応用編[1]に例示されていた4種類の概算法の中から「平均機能プロセス数法」を元に確立した方法です。COSMIC測定マニュアル応用編には他にも概算法の例が記載されていますので、この中から一番粗いレベルで概算する「平均ユースケース法」を最後にご紹介します。

◎平均ユースケース法

「平均ユースケース法」は、プロジェクトの開発初期に得られるユースケースの情報を元に概算規模を求める方法です。ソフトウェアのユースケース数を数え、あらかじめ定義したユースケースの平均規模を掛けて概算します。ユースケースの平均規模は、過去の他のプロジェクトの測定結果を元に、ユースケースの平均機能プロセス数と機能プロセスの平均規模から求めます。式で表すと以下の通りです。

ユースケースの平均規模を2つの係数から生成してこれを元に概算するので、前の章までにご紹介した概算法より機能規模の精度は低くなります。ただし、測定方法が簡単なこと、測定コストが非常に小さいことから、例えば粗いレベルでの見積りが必要な場合などに有用な方法だと考えられます。

このように概算法には何通りかの方法があります。測定の目的や用途によって概算法を確立し、選択して使うことで、プロジェクト測定をより役立つものにできると思います。

おわりに

今回は機能規模を概算で測定する概算法をご紹介しましたが、今回までの内容で、プロジェクト測定についての説明はほぼ終了しました。これまでの内容では、プロジェクトがより良い開発を行うため、また、プロジェクトの改善点や強みを明らかにするためにプロジェクトの測定と分析を行う方法や実例をご紹介してきました。

最終回となる次回の記事では、これまでとは視点を変え、プロジェクトからも要望が多い見積りについてご紹介します。

本記事の中でも少し触れましたが、概算法によってプロジェクトの早い段階で概算規模を測定することで、見積りへの活用が期待できます。私たちは、プロジェクトの実績データと熟練のプロジェクトマネージャの経験値を組み合わせて見積りモデルを構築する手法「CoBRA法」を用いて見積りモデルを構築し、COSMIC法とCoBRA法を組み合わせた見積り手法の適用を開始しました。次回は見積り手法「CoBRA法」の概要と社内での検討過程についてご紹介します。

参考文献

• [1]COSMIC機能規模測定法 3.0版 応用編,
  JFPUGのCOSMIC法のダウンロードページhttps://www.jfpug.gr.jp/cosmic/CFFP-index.htmlで提供されているCOSMIC法ver3.0のマニュアルに含まれている, (参照 2014-07-03)
• [2]COSMIC-FFPによる業務アプリケーションソフトウェア規模測定の指針,
  https://www.jfpug.gr.jp/cosmic/BAGv1_0j.pdf, (参照 2014-07-03)

参考文献[1][2]について：
本記事を掲載した時には日本語訳のドキュメントがリンク先で公開されていましたが、2016年2月現在はリンク先に存在しないようです。日本語訳としては、代わりにJIS規格「JISX0143 ソフトウェア－ＣＯＳＭＩＣ機能規模測定手法」をご覧ください。JIS規格は、日本工業標準調査会JISCの公式サイトhttps://www.jisc.go.jp/のJIS検索ページにてJIS番号「X0143」で検索すると閲覧できます。（2016年2月追記）