第2回では機能ユニット間で分析値を比較する一番詳細なレベルの分析を、第3回では反復開発プロジェクトで反復毎に分析を行ってプロジェクトにフィードバックする分析をご紹介しました。これらはプロジェクト測定分析の取り組みを始めたら、最初に試していただける基本的な内容です。
今回は、次のステップとも言える大規模プロジェクトの測定についてご紹介します。大規模プロジェクトでデータ量が多い場合に実践する分析のアプローチ、また、COSMIC法に基づいて機能規模を測定するコストを削減するために適用したCOSMIC概算法の概要をご紹介します。
なお、本記事では、開発労力が250人月以上、機能ユニット数が200個以上のプロジェクトを指して大規模プロジェクトと呼んでいます。機能ユニットとは、画面、バッチ、ユースケースなどの大きなレベルでソフトウェア機能を分割したものを言います。
目次
- 大規模プロジェクトの測定の目的
- 大規模プロジェクト測定の課題
- 大規模プロジェクトの分析のアプローチ
- 大規模プロジェクトの分析例
- COSMIC概算法による機能規模測定コストの削減
- 大規模プロジェクト測定での考慮点
- おわりに
- 参考文献
大規模プロジェクトの測定の目的
第1回の記事でご紹介したように、プロジェクト測定の目的は
- より良い開発を行う
- 開発プロジェクトの改善点や強みを明らかにする
です。
大規模プロジェクトであっても、プロジェクト測定の目的は変わりません。より良い開発を行うため、開発プロジェクトの改善点や強みを明らかにするために測定を行います。
加えて、より広い視点で言うと、プロジェクト測定の分析結果をより活用できるものにするために、大規模プロジェクトを測定します。分析結果を組織内で蓄積していくと、新たなプロジェクトの計画を立てるときに、過去の同じようなプロジェクトの結果を参考にできます。分析結果の活用を考えると、測定対象のプロジェクトは小中規模だけでなく大規模プロジェクトも測定してバリエーションを用意しておく方がよいと言えます。
大規模プロジェクト測定の課題
大規模プロジェクトを測定するには、大規模プロジェクトならではの課題を解決する必要があります。大規模プロジェクトの測定では、データ量が多く、測定期間が長いため、分析対象のデータが多くなるためです。
着目すべき機能ユニットの把握
データ量が多い大規模プロジェクトの測定分析では、機能ユニット間の分析を行う際に、着目すべき機能ユニットを把握するのが難しくなります。
例えば、200個以上の機能ユニットがあるとき、第2回でご紹介した手順で機能ユニット毎の10CFPあたりの作業時間を示すグラフを作成しても、横軸に200個以上の機能ユニットが並ぶため一覧はできないでしょう。一覧できないグラフでは他より作業時間がかかっているような着目すべき機能ユニットを見つけるのは難しくなります。
このため、数が多い分析値から着目すべき機能ユニットを絞り込むための効率の良い方法を確立することが必要です。
測定コストの削減
もう一つの課題は測定コストの削減です。これまでの記事では測定コストについて詳しく言及しませんでしたが、プロジェクト測定には、もちろんコストが発生します。仮に、小中規模のプロジェクトと同じ方法で大規模プロジェクトを測定した場合の測定コストを、実績を元に試算したところ、大規模プロジェクトの測定に10人月以上かかることが推測されました。通常、測定にこれほどのコストはかけられないため、大規模プロジェクトの測定を実現するには測定コストを大幅に削減する必要があります。
私たちは、測定コストを開発労力の1%以下にとどめることを目標に、測定コストの削減に取り組みました。
大規模プロジェクトの分析のアプローチ
本章では、前の章で挙げた一つ目の課題を解決するために、実際に大規模プロジェクトの測定分析を行うときに実践している内容を説明します。
課題に挙げたとおり、大規模プロジェクトは機能ユニット数が多くなるため、これまでにご紹介した機能ユニット全てを一度に分析するアプローチを取ると、有効な分析をするのが難しくなります。
このため、大規模プロジェクトでは、プロジェクト全体の分析値の分布を把握して着目したい機能ユニットを絞ってから、機能ユニット毎の詳細な分析を行う二段階の分析を行います。
機能ユニットの絞り込み
分析値の分布を把握するにはヒストグラムを使います。ヒストグラムはデータの分布を知ることができます。例えば、機能ユニット毎の開発生産性をヒストグラムで表すと、開発生産性がどの範囲に分布しているか、生産性が低い機能は多いか、などが確認できます。
更に、この分布の中から分析値が他の機能ユニットと異なる機能と生産性が低い機能を絞り込みます。ヒストグラムと箱ひげ図を併用した右図のようなグラフを使えば、分析値が他の機能ユニットと異なる機能は外れ値として表されるため便利です。箱ひげ図は分析値のバラつき具合や外れ値を把握することができます。
まずは、外れ値を持つ機能ユニットと生産性が低い機能を絞り込みの対象とし、分析を進める中で必要があれば、他の機能ユニットを詳細な分析の対象にすればよいでしょう。生産性が低い機能をどの程度の値とするかは、分析対象のプロジェクトの生産性から相対的に判断してください。
30機能くらいまでに絞り込むと次のステップで行う詳細な分析を進めやすいですが、あまり最初から数を気にして絞り込んでしまうと、本来詳細に分析すべき機能ユニットが分析対象から漏れてしまう可能性があるので注意が必要です。
なお、ヒストグラムや箱ひげ図は統計解析ソフトを使用すると簡単に作成できますが、Excelでも作成することができます。
絞り込んだ機能ユニットの詳細な分析
機能ユニットを絞り込んだら、それらの機能ユニットを対象にして第2回でご紹介した機能ユニット間の分析を行います。そして、生産性に影響した要因を特定していきます。
次の章では、実際の分析結果を使って、大規模プロジェクトの分析をもう少し説明します。
大規模プロジェクトの分析例
本章では大規模プロジェクトの分析例を、Lプロジェクトの分析結果を用いてご紹介します。
Lプロジェクトは開発期間が約1年半、開発労力が500人月超、ピーク時のメンバー数は約40人のプロジェクトです。開発に入ってからは3回の反復を行ったプロジェクトです。
画面機能ユニットの生産性の分布
先に述べた通り、大規模プロジェクトの分析ではまず全体を大まかに把握します。ここでは、例としてLプロジェクトの反復2回目で開発した画面機能ユニットの開発生産性の分布を示します。
機能ユニット毎の開発生産性は以下の式で求めます。共通部分を開発する労力は含まない、機能固有の部分を開発した労力をもとに求めています。
画面機能ユニットの開発生産性の分布を確認するには下の［グラフ1］で示したヒストグラムを用いました。まず、上の式で全ての機能ユニットについて開発生産性を求めて、その値を統計解析ソフトを利用してヒストグラムに表しています。
［グラフ1］のヒストグラムの横軸は機能ユニットの開発生産性の区間を、縦軸は開発生産性の各区間に属する機能ユニット数を示しています。これを見ると、一番低い開発生産性の区間に属する機能ユニット数は少なく、非常に高い生産性の機能ユニットが外れ値として存在しています。
生産性が低い機能ユニットは少なく、特に問題がありそうな機能ユニットはありませんでしたが、プロジェクトにフィードバックする際には生産性が低い機能10～20個と生産性が高い機能10～20個の分析値を機能ユニット別に示しました。この結果、生産性が低い機能には難易度が高い機能が含まれており分析値が開発の実態と合っていることが確認できました。
次に、機能ユニット毎の作業時間の違いを見るため10CFPあたりの作業時間の分布を確認します。
10CFPあたりの作業時間の分布
10CFPあたりの作業時間は機能規模で正規化した作業種別毎の労力で、機能規模が異なる機能ユニット間でも、10CFPという単位規模に正規化することで、同じ基準で実装時間を比較することができるものです。
機能ユニット毎の10CFPあたりの実装作業時間は以下の式で求めます。他の作業種別で求める場合は、式の「実装」に当たる部分を、それぞれの作業種別である分析や設計、結合テストなどに置き換えてください。
10CFPあたりの作業時間の分布も開発生産性と同様、全ての機能ユニットについて10CFPあたりの作業時間を求めて、その値を統計解析ソフトを利用してヒストグラムに表しました。今回は10CFPあたりの実装・単体テスト時間の分布を確認した例を下の［グラフ2］に示します。
［グラフ2］を見ると、他より10CFPあたりの実装・単体テスト時間が大きい9つの機能ユニットが外れ値として示されました。この9つの機能ユニットに着目して第2回 機能ユニット間の分析結果と同様に、機能ユニット毎の詳細な分析を行います。
機能ユニット毎の詳細な分析では、例えば、9機能について［グラフ3］で示すような10CFPあたりの作業時間のグラフを作成して、機能ユニットの難易度や特徴など確認しながら他より実装・単体テスト時間が大きい要因を分析します。この過程については第2回と同じですので、今回は説明を省きます。分析の結果、問題点があった場合は早い段階でプロジェクトにフィードバックします。
COSMIC概算法による機能規模測定コストの削減
大規模プロジェクトを測定する際のもう一つの課題は測定コストの削減です。特に大規模プロジェクトの測定コストに大きく影響するのは機能規模の測定コストです。この機能規模の測定コストを削減するために、私たちの測定では、COSMIC法を簡易に行う「概算法」を適用しました。
概算法とは
概算法は、COSMIC法に基づいて概算で機能規模を測定する方法です。COSMIC測定マニュアル応用編[1]に4種類の概算法が例示されていますが、この中の「平均機能プロセス数法」を元に、具体的な手順を定めて適用しました。
平均機能プロセス数法を用いた概算法では、測定されるソフトウェアの一部を正確に測定して機能プロセスの平均規模を決定し、この平均規模と、機能プロセスを識別して数えた機能プロセス数を掛けて概算します。
本記事では便宜上、平均機能プロセス数法を用いた概算法のことを概算法と呼びます。
概算法で測定した機能規模の妥当性
概算法で測定した機能規模が妥当であるか検証するために、概算法で測定した機能規模とコード量の相関を見たところ、相関は高く、概算法で測定した機能規模は妥当であると判断しました。コード量はソフトウェアの大きさを表す指標であるため、機能規模がソフトウェアの妥当な大きさを表しているか確認するために比較しています。
測定コストの削減率
測定コストの削減は、精密に測定する機能を一部の機能に絞ることで実現しました。実際に大規模プロジェクトの機能規模を概算法で測定した結果、測定コストは開発労力の0.2～0.4%の範囲内に収まり、目標とした1%以下をクリアしました。また、概算法を適用せずに機能規模を測定した場合の推測値と比べると、80～90%前後の測定コストを削減できたことが分かりました。
概算法の具体的な手順については、次回の記事で詳しくご説明したいと思います。
大規模プロジェクト測定での考慮点
最後に、ここまでの章で述べた内容以外に、大規模プロジェクトの測定で考慮する点を書いておきます。
定期的なフィードバック
反復開発を行っている大規模プロジェクトは特に、定期的に分析結果をプロジェクトにフィードバックすることをお勧めします。 このフィードバックには、以下の二つの目的があります。
- 潜在的問題点を見つける
- 測定上の間違いを見つける
開発の早い段階で潜在的問題点に気付けば、開発途中で問題点を改善できることが期待できます。
また、測定上の間違いを早く見つけることも大規模プロジェクトの測定分析では重要です。プロジェクト後半に、例えば労力の登録漏れが発覚すると測定作業の一部やり直しが発生して測定コストが大きくなってしまいます。測定データはこまめにチェックして早めに間違いに気付くことが必要です。
多面的な分析
大規模プロジェクトの開発期間の間に分析の回数を重ねていくと、そのプロジェクトで着目すべき点が分かります。これまでにご紹介した分析は基本的な内容の一部に過ぎず、分析の視点はさまざまです。
例えば、大規模プロジェクトを測定していると、プロジェクトの関係者が増えるにつれて打合せの時間が大きくなったり、連携先システムの数が増えるにつれて連携先とのやりとりの工数が大きくなることが分かります。このような場合、例えばプロジェクト管理に関する作業に絞ってデータを分析し、プロジェクトに提供することもできます。
データの変化に注意して必要に応じた分析を行って、プロジェクトに有用な情報を提供することが重要だと考えています。
おわりに
今回の記事では大規模プロジェクトの測定分析についてご紹介しました。次回の記事では、大規模プロジェクトを測定するときにも役立つCOSMIC法の概算法を用いた機能規模の測定手順をご紹介します。
参考文献
- [1]COSMIC機能規模測定法 3.0版 応用編,
JFPUGのCOSMIC法のダウンロードページhttps://www.jfpug.gr.jp/cosmic/CFFP-index.htmlで提供されているCOSMIC法ver3.0のマニュアルに含まれている, (参照 2014-06-05)
参考文献について：
本記事を掲載した時には日本語訳のドキュメントがリンク先で公開されていましたが、2016年2月現在はリンク先に存在しないようです。日本語訳としては、代わりにJIS規格「JISX0143 ソフトウェア－ＣＯＳＭＩＣ機能規模測定手法」をご覧ください。JIS規格は、日本工業標準調査会JISCの公式サイトhttps://www.jisc.go.jp/のJIS検索ページにてJIS番号「X0143」で検索すると閲覧できます。（2016年2月追記）