オブジェクトの広場は株式会社オージス総研グループのエンジニアによる技術発表サイトです

プロジェクト測定

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

プロジェクト測定とは
株式会社オージス総研 技術部 アジャイル開発センター
木村めぐみ
2014年2月6日

本連載は、2007年頃から社内で実践してきたソフトウェア開発プロジェクトの測定について紹介するものです。連載初回の今回は、プロジェクト測定の概要を説明します。なぜプロジェクトを測定をするのか測定の目的と、私たちが実践しているプロジェクト測定の方針、測定の流れ、それから測定したデータの分析の視点についてご紹介します。プロジェクト測定について興味のある方、取り組みを考えている方のご参考になれば幸いです。

目次

プロジェクト測定の目的と課題

kagi

ソフトウェア開発プロジェクトの現場では、他社との差別化を図るために開発生産性を上げてより良い開発を行うことが求められています。ところが、開発の多様化により開発生産性に影響する潜在的な要因は多く、どの要因が影響したかを特定するのはなかなか困難です。けれども、開発生産性に大きく影響する要因が特定できないと、より良い開発を行うために改善すべき部分や継続した方がよい部分が明確になりません。このため、開発生産性を上げてより良い開発を行うには、プロジェクトの状況を客観的に把握し開発生産性に影響する要因を明らかにすることが課題となります。

プロジェクト測定の目的

  • より良い開発を行う
  • 開発プロジェクトの改善点や強みを明らかにする

課題

  • プロジェクトの状況を客観的に把握する
  • 開発生産性に影響を与えた要因を明らかにする

この課題を解決するために、私たちはプロジェクト測定の方法を研究してきました。2008年度から実開発プロジェクトの測定に取り組み、これまでに、約30件の実開発プロジェクトを測定し、生産性に影響を与えた要因を分析しています。

プロジェクト測定を試行している段階では測定で得られるメリットを実感できればよいのですが、プロジェクト測定を現場に展開していくには測定コストが課題となります。プロジェクト測定にコストがかかってしまうと測定で得られるメリットよりコストがかかるというデメリットの方が大きく効いてしまうからです。私たちは、プロジェクト測定を進めていく中で、測定コストについても検討してきました。測定コストの削減については次回以降に説明していきたいと思います。

プロジェクト測定を現場へ展開するための課題
  • 測定コストを削減する

プロジェクト測定の方針

プロジェクト測定を実施するにあたり、測定の方針を以下のように決めました。

  1. ソフトウェアの機能の大きさを機能規模測定手法COSMIC法*1)で測定する
  2. 機能ユニットと作業種別に基づいて労力を記録する
労力

COSMIC法で測定したソフトウェアの機能の大きさは機能規模と呼び、単位はCFP(COSMIC Function Point)です。

機能ユニットとは、画面、バッチ、ユースケースなどの大きなレベルでソフトウェア機能を分割したものを言います。共通機能部分は「画面共通」などと定義します。作業種別は、分析、設計、実装など開発の作業内容を識別するための種別です。

労力は、機能ユニット×作業種別の組み合わせで記録します。右図に示したような労力を記録するファイルをプロジェクトメンバーに渡し、作業時間を記録してもらいます。

測定データの使い道

これらの方針に基づいて測定することで、生産性に影響する要因を分析するために必要な、以下のような値を求めることができます。

・開発生産性

プロジェクトが開発するソフトウェアの機能規模と開発労力を測定すると、これら二つの値から以下の式で開発生産性を求めることができます。

開発生産性を求める式

私たちのプロジェクト測定では、上記のように、COSMIC法で測定した機能規模を用いて開発生産性を求めます。開発生産性はコード行数から求めることもできますが、コード行数はプログラムの書き方など実装方法に依存し、開発側の視点で見た大きさとも言えます。これに対してCOSMIC法で測定した機能規模は、ユーザの視点で見える機能の大きさを示しています。私たちのプロジェクト測定では、ユーザーの視点で規模を把握し、その規模から生産性を求めたいという理由から、COSMIC法で測定した機能規模を用いて生産性を求めることにしました。

・10CFPあたりの作業時間

機能ユニット×作業種別の組み合わせで記録することで、どの機能ユニットのどのような作業に時間がかかっているかを知ることができます。例えば、機能ユニット毎の実装時間の違いは、10CFPあたりの実装作業時間を求めて比較します。機能規模が異なる機能ユニット間でも、10CFPという単位規模に正規化することで、同じ基準で実装時間を比較することができます。

10CFPあたりの作業時間を求める式

このような比較は、生産性に影響を与えた要因を分析するときに有用な手段です。分析については後ほど「分析のアプローチ」で説明します。

プロジェクト測定では、上記の方針のもと、機能規模と労力を測定することを必須とし、オプションでコード量、コードカバレッジ、欠陥数などを測定しています。 測定したデータはBI(Business Intelligence)機能を用いた測定分析システムに登録し、多面的に分析できるようにしました。

*1) 機能規模測定手法COSMIC法:COSMIC法はソフトウェアの機能規模を測定する手法で、ISO標準の手法です。 COSMIC法では、システム境界をまたがったデータ移動数と永続記憶域に読み書きするデータ移動数の合計値を求めることでソフトウェアの利用者の立場から見た機能の規模を求めます。COSMIC法については別の記事「ビジネスアプリ開発者のための機能規模測定手法 COSMIC 法入門」で詳しく説明していますのでご覧ください。

プロジェクト測定の流れ

ここで、実際のプロジェクト測定の流れを簡単にご紹介します。

測定の体制

まず、測定の体制を説明します。プロジェクト測定には「開発プロジェクト」と「測定担当」の二つの役割があります。測定担当は、私の所属するアジャイル開発センターが行っています。開発プロジェクトから見ると第三者的な立場にあります。開発プロジェクトは測定対象のプロジェクトのことを総称しています。

プロジェクト測定に関する測定や分析は、おもに測定担当が行います。将来的には開発プロジェクト自身がプロジェクト測定を行える仕組みにしていきたいと思っていますが、現在はプロジェクトが測定のメリットを実感できるよう、測定の負担をできるだけ減らす体制で測定を行っています。

測定対象プロジェクトの決定

測定のイメージ
測定のイメージ

測定対象のプロジェクトは、プロジェクトが開始する前に決定します。各部署の開発状況をウォッチして測定できそうなプロジェクト探したり、プロジェクト測定報告会など社内への広報活動を行って測定への協力を呼びかけたりしています。現在は、測定担当が開発プロジェクトに測定の協力を依頼して実現することが多いです。

プロジェクトの測定

測定することが決まったら、まずは開発プロジェクトのプロジェクトマネージャに簡単なプロジェクトのプロフィール(新規開発か改修か、プロジェクトの期間など)、マスター情報(機能ユニット名、作業種別名、プロジェクトメンバー名など)を確認し測定システムに登録します。

機能規模は、要求が確定し基本仕様が固まった段階で、COSMIC法に基づいて測定担当が測定します。画面モックや簡単な設計書を元に測定し、測定システムに登録します。

労力はプロジェクトメンバーに日々記録してもらい、2週間毎など一定の期間毎に測定システムに登録します。コード量も同様に一定の期間毎にスナップショットを取得し、コード量をカウントして測定システムに登録します。一定の期間毎に測定する労力やコード量はプロジェクトが完了するまで測定を続けます。

プロジェクトへの測定結果のフィードバック

フィードバック

測定したデータは、あらかじめ決めておいた1ヶ月毎や反復毎などの開発途中のタイミングと、プロジェクト完了時に測定担当が分析します。分析した結果はグラフや表を用いたレポートにまとめ、プロジェクトにフィードバックします。

開発途中のフィードバックでは、労力の記録に間違いないか、機能ユニット毎の実装時間の違いはどうか、など測定データを確認します。もし、他の機能ユニットより大きく実装時間がかかっている機能ユニットがあった場合、何らかの問題が隠れている可能性が考えられます。このような潜在的問題点が開発途中の早い段階で見つかれば、その原因を見つけて改善することが可能です。

プロジェクト完了時のフィードバックは打合せ形式で行い、測定担当と開発プロジェクトの主要メンバーの双方が分析レポートを確認します。この場では、測定担当が分析した内容に対してプロジェクト側の実感を確認したり、データからでは分からない開発の進め方や気になる項目のヒアリングを行います。打合せの場で得られた情報を最終的な分析レポートに反映してプロジェクトの測定と分析が完了します。

社内へのフィードバック

ここでは一つのプロジェクトの測定の流れで説明しましたが、過去に測定した他のプロジェクトの分析結果がこれからの開発に役立つこともあります。このため、測定分析結果は、年に2回開催する社内報告会で報告しています。

分析のアプローチ

分析のアプローチは分析するタイミングが開発途中か完了時かによって若干異なりますが、ここでは開発が完了したときに分析する場合のアプローチについて紹介します。

分析で使う値には、労力、機能規模、コード量など測定データをそのまま使用した測定値と、測定値から算出する開発生産性などの分析値があります。開発生産性に影響を与えた要因は、測定値や分析値を異なるグループ間で比較して生産性のバラつきの要因を見極めることで特定します。

測定値、分析値

  • 機能規模(CFP)
  • 労力(人月)
  • コード量(行)
  • 開発生産性(CFP/人月)
  • 機能規模で正規化した作業種別毎の労力(10CFPあたりの作業時間)
  • コード量生産性(行/人月)
  • 機能規模で正規化したコード量(10CFPあたりのコード行数)

など

グループ

  • プロジェクト
  • アプリ種別(画面/バッチ)
  • アプリ固有/アプリ共通
  • 機能ユニット

など

それでは具体例をもとに、生産性に影響を与えた要因を分析する過程を説明しましょう。今回例に挙げたのはP2というプロジェクトが開発したバッチ機能の一部である6機能です。この6機能は扱うデータは異なりますが振る舞いは類似した機能です。まず、この6機能の生産性のバラつきを確認するため、機能ユニット別開発生産性を確認してみましょう。なお、機能ユニット別開発生産性は「分析値:開発生産性」を「グループ:機能ユニット」で比較するグラフです。

機能ユニット別開発生産性は以下の式で求めます。共通部分を開発する労力は含まない、機能固有の部分を開発した労力をもとに求めます。機能ユニット毎の開発生産性のバラつきを見ることができます。

機能ユニット別開発生産性を求める式

下のグラフに示した機能ユニットBT-013の測定値は

  • BT-013の機能規模・・・25CFP
  • BT-013の労力(BT-013を開発した作業時間)・・・40時間

でした。1人月=160時間と換算しているので、式に当てはめると、BT-013の開発生産性は25CFP/(40h/160h)=100CFP/人月となります。実際にはこれらの計算は測定システムで行っています。6機能の機能ユニット別生産性は以下のグラフとなりました。

6機能の機能ユニット別生産性

BT-013、BT-015、BT-016は生産性が100CFP/人月以上と高く、BT-014、BT-022、BT-012は前者の生産性の2分の1以下と低いことが分かります。このバラつきは何に起因しているのでしょうか。

これら6機能は類似機能であるため、開発が進むにつれて習熟度が上がり生産性が上がることが期待できます。実はこのプロジェクトはオフショア開発を行っており、まず国内でサンプルとなる機能を開発しその成果物を参考に残りの機能をオフショア委託先が開発するというプロセスを取りました。上のグラフは機能ユニットを開発順に並べたものです。BT-013は国内で開発した機能ユニット、それ以外がオフショア先が開発した機能ユニットでした。国内で開発したBT-013を除いて考えると、前半で開発した機能ユニットに比べて後半に開発した機能ユニットの生産性が上がっていることが分かります。以下に、コメントを記入したグラフを示します。

6機能の機能ユニット別生産性(コメント入り)

生産性を比較しただけでは推測にとどまるため、機能規模で正規化した作業種別毎の労力である「分析値:10CFPあたりの作業時間」を確認します。機能ユニット別の10CFPあたりの実装作業時間は以下の式で求めます。他の作業種別で求める場合は、式の「実装」に当たる部分を、をそれぞれの作業種別である分析や設計、結合テストなどに置き換えてください。

機能ユニット別の10CFPあたりの実装作業時間

下のグラフに示した機能BT-013の測定値は

  • BT-013の機能規模・・・25CFP
  • BT-013の実装・単体テスト(非UI)時間・・・37.5時間

でした。式に当てはめると、BT-013の10CFPあたりの実装・単体テスト(UI)時間は37.5h/25CFP×10=15hとなります。これらの計算も実際には測定システムで行っています。6機能の10CFPあたりの作業時間は以下のグラフとなりました。

6機能の10CFPあたりの作業時間

先に述べたようにBT-013は国内で開発した機能ユニットなのでこれを除いて考えると、10CFPを開発するのにかかった実装・単体テスト時間は前半のBT-014、BT-022、BT-012では30時間以上でしたが、後半のBT-015、BT-016では約半分の15時間に短縮されていることがわかります。

後半に開発した機能ユニットの実装・単体テスト作業時間が小さくなっているため、推測通り、類似機能の開発経験によって実装効率が上がったと考えられます。この結果から、P2プロジェクトにおいてバッチ生産性を上げた要因は類似機能の開発経験だと分析できました。

実際には開発プロジェクト全体の測定結果を分析します。P2プロジェクトはオフショア開発だったため、オフショア開発中の委託元と委託先の労力を比べました。他にも過去の類似プロジェクトと比べたり、データを見る視点はいろいろあります。そこがプロジェクト測定の面白いところだと思います。

これまでの測定結果から考えた生産性に影響する要因

これまでのプロジェクト測定の結果から、生産性に影響を与える要因を分類すると以下のようになります。なお、現在、測定しているプロジェクトは全てビジネスアプリを開発するプロジェクトです。

  • 開発プラクティス
    • 共通機能のくくり出し
    • ドキュメント量の多さ
    • ライブラリなどの利用
  • 技術要素とプロダクト
    • 既存アーキテクチャの利用
    • 開発言語
    • 機能の難易度
    • 類似機能の開発経験
    • 特定技術の開発経験
    • 要求/設計/実装不具合による手戻り
    • 個人のスキル
    • コミュニケーション手段

これら生産性に影響する要因は、開発形態や組織によって様々だと思いますが、私たちのこれまでのプロジェクト測定では、複数のプロジェクトで要因に挙がる項目もあります。分かりやすいところでは、機能の難易度、類似機能の開発経験などは出てくることが多かった項目です。このように、これらの要因は、新たなプロジェクトを分析するときの参考にもなります。

おわりに

今回の記事ではプロジェクト測定の目的、測定分析でどのようなことをするかの概要を説明してきました。プロジェクト測定についてイメージをつかんでいただけたでしょうか。

次回は、実際のプロジェクトの測定結果を詳しくご紹介したいと思います。大規模プロジェクトの測定結果についてもご紹介する予定です。