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

プロジェクト測定

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

測定分析の実例 ~ オフショア開発プロジェクトの機能ユニット間の分析 ~
株式会社オージス総研 技術部 アジャイル開発センター
木村めぐみ
2014年3月6日

第1回の記事では、プロジェクト測定の概要や分析のアプローチについてご紹介しました。続いては、今回から2回に渡ってプロジェクト測定分析の実例をご紹介します。

今回ご紹介するのは、機能ユニット間で分析値を比較する、一番詳細なレベルの分析です。機能ユニットとは、画面、バッチ、ユースケースなどの大きなレベルでソフトウェア機能を分割したものを言います。機能ユニット間で分析を比較して、生産性に影響を与えた要因を特定する過程をご紹介します。また、今回分析結果をご紹介するプロジェクトはオフショア開発を行ったため、オフショア開発の労力についても分析しています。

目次

機能ユニット間の分析の目的

分析の目的

機能ユニット間の分析は、機能ユニット毎の分析値を比較して生産性のバラつきの要因を特定するために行います。機能ユニットとは、画面、バッチ、ユースケースなどの大きなレベルでソフトウェア機能を分割したものを言います。プロジェクトの生産性に影響する要因を特定するために必要な、一番詳細なレベルの分析です。

分析のタイミング

この分析を行う時期は、1ヶ月毎や反復毎などの開発途中のタイミングとプロジェクト完了時です。

分析対象プロジェクトについて

今回分析結果をご紹介するのはP2プロジェクトと呼ぶプロジェクトです。P2プロジェクトでは、通常のプロジェクトで行う機能ユニット間の分析に加えて、オフショア開発の労力についても分析しました。オフショア開発では、立ち上がりの習熟度が低い段階と難易度が高い機能を開発するときには、オフショア先の労力だけではなく国内の労力も増える傾向がデータから読み取れました。

分析結果は次の章でご紹介しますが、本章では、分析対象であるP2プロジェクトのプロフィールと測定、分析で行ったことの概要を説明します。

P2プロジェクトのプロフィール

P2プロジェクトは継続開発プロジェクトで、初回プロジェクトで開発したシステムの機能追加を行いました。画面機能とバッチ機能を開発しましたが、本記事ではバッチ開発部分の分析結果をご紹介します。

P2プロジェクトで開発したバッチ機能は、初回プロジェクトで開発した機能とは異なる新しい技術要素を用いたものでした。バッチ機能の開発はオフショア開発を行い、バッチ機能の半数以上に当たる約20機能をオフショア先が開発しました。

バッチ機能の開発の簡単な流れを下図に示します。

P2プロジェクト

バッチ機能はまず国内で分析・設計を行い、このうちオフショア開発のサンプルとする代表的な機能を国内で先行開発しました。先行開発したソースコードは、サンプルとして仕様書と共にオフショア先に提供し、開発のインプットとしました。オフショア開発期間中は、国内・オフショア間で情報共有サービスを利用し、質問やレビューなど必要に応じてリアルタイムにやり取りしました。

開発が完了した機能から随時、国内で検収を行い、オフショア開発期間中に発覚した不具合はオフショア先が修正しました。オフショア開発期間が完了した後に不具合が発生した場合は国内で対応しました。

測定したデータ

測定したデータは、機能規模と労力です。

機能規模は機能規模測定手法COSMIC法に基づいて測定しました。労力は機能ユニットと作業種別に関連付けて記録しました。作業種別は、分析、設計、実装など開発の作業内容を識別するための種別です。

測定、分析とフィードバック

P2プロジェクト

◎測定

機能規模は、基本設計書をインプットに、COSMIC法に基づいて測定担当が測定しました。

労力は、第1回の記事の「プロジェクト測定の方針」で示した労力ファイルを、国内とオフショア先のプロジェクトメンバーに渡して記録してもらいました。プロジェクトが完了するまで、2週間毎に測定システムに登録しました。

◎分析

プロジェクトが完了すると、すべての測定データを元に測定担当が分析し、グラフや表を用いたレポートにまとめました。グラフや表の作成はExcelのピボットテーブル機能を利用しました。

◎フィードバック

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

機能ユニット間の分析結果

それでは、P2プロジェクトのバッチ機能の機能ユニット間の分析結果をご紹介します。

分析のアプローチ

P2プロジェクトでは以下のようなアプローチで分析しました。以下の2.と4.は、P2プロジェクトの特徴に合わせた内容ですので、一般的に当てはまるものではないことをご了承ください。

  1. 機能ユニット毎の開発生産性を比較する
  2. 類似機能でグルーピングして開発生産性を比較する
  3. 10CFPあたりの作業時間を比較する(プロジェクトへのヒアリングも実施)
  4. オフショア先・国内の10CFPあたりの作業時間を比較する

以下に、1.から4.までの分析内容をご紹介します。

機能ユニット間の開発生産性の比較

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

開発生産性=規模/労力
グラフ1
[グラフ1]P2プロジェクト バッチ機能 機能ユニット別開発生産性

[グラフ1]の横軸は機能ユニット、縦軸は開発生産性を示しています。開発生産性は、1人月に開発した機能規模(CFP)の大きさを表したものですから、数値が大きいほど生産性が高い機能と言えます。[グラフ1]を見ると、機能ユニット間で生産性のバラつきが大きいことが分かります。しかし、この情報だけでは生産性に影響する要因を特定するのは難しいので、それぞれの機能ユニットの振る舞いを確認しました。すると、今回のバッチ機能は類似機能でグルーピングできることが分かりました。

類似機能でグルーピングした開発生産性の比較

類似機能でグルーピングして、機能ユニット毎の開発生産性を示したものが下の[グラフ2]です。類似機能は、グループ毎に背景を色分けして示しました。P2プロジェクトはバッチ機能をオフショア開発しており、まず国内でサンプルとなる機能を開発し、その成果物を参考にして残りの機能をオフショア委託先が開発するというプロセスを取りました。グラフでは、国内で先行開発した機能に矢印のマークを付けています。矢印が付いていない機能はオフショア先が開発しました。

グラフ2
[グラフ2]P2プロジェクト バッチ機能 類似機能でグルーピングした機能ユニット別開発生産性

[グラフ2]を見ると、生産性のバラつきに傾向があることが分かりました。まず、類似機能のグループ間で生産性を比較すると、類似機能のグループによって生産性が比較的高いグループと比較的低いグループに分かれます。次に、類似機能のグループ内で生産性を比較すると、国内で先行開発した機能の生産性は高く、オフショア先が開発した機能は、特に生産性の高いグループでは生産性にバラつきがあることが分かります。

グラフを見て分かったことは、以下の通りです。

  • 類似機能のグループ間で生産性にバラつきがある
  • オフショア先が開発した機能ユニット間で生産性にバラつきがある

10CFPあたりの作業時間の比較

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

10CFPあたりの作業時間=労力/規模×10

10CFPあたりの作業時間を[グラフ3]に示します。

グラフ3
[グラフ3]P2プロジェクト バッチ機能 10CFPあたりの作業時間

[グラフ3]の縦軸は10CFPを開発するのに要した作業時間を表しています。他の機能ユニットと比べて作業時間が大きい場合は、何らかの理由で作業に時間がかかり作業効率が悪かった機能ユニットであると言えます。

P2プロジェクトでは、労力を記録する際に分析・設計作業のほとんどをバッチの共通部分の開発に関連付けて記録したため、個別の機能ユニットの値を示した[グラフ3]には分析・設計時間がほとんど出てきません。このため[グラフ2]が示す情報とあまり変わりがないのですが、通常は機能ユニット毎に分析・設計や結合テスト作業などの時間を記録するため、作業種別毎の時間を比較するときに有用なグラフです。

◎生産性に影響した要因

[グラフ3]を見て分かったことをグラフ中の吹き出しに記述しました。星印を付けた内容は、プロジェクトにヒアリングして分かったことです。この内容から、生産性のバラつきに影響した要因は、以下であると分析できます。

  • 機能の難易度
  • 類似機能の開発経験

オフショア先・国内の10CFPあたりの作業時間の比較

さらに、P2プロジェクトはオフショア開発であるため、オフショア先の生産性や品質も気になるところです。これを確認するため、先ほどの10CFPあたりの作業時間をオフショア先と国内に分けて確認しました。

品質は、ここでは受入れ後の国内労力の大きさで判断しています。受入れ後にオフショア開発した機能の不具合が発覚すると、国内で対応する必要があり国内労力が大きくなるためです。欠陥数を測定している場合は、欠陥密度など欠陥に関する分析値と合わせて分析すればよいでしょう。

下に示した[グラフ4]は、[グラフ3]で示した10CFPあたりの作業時間を、オフショア先と国内に分けて示したものです。オフショア先のグラフ上には、担当者を識別するためのアルファベットを記入しました。P2プロジェクトでは、オフショア委託先に協力いただいてメンバー別の労力を記録してもらいました。この労力は測定分析の目的のみで使い、個人の評価には使わないという条件で測定しています。

なお、[グラフ4]には国内で先行開発した機能のデータは表示していないので、[グラフ3]と機能ユニット数が異なります。

グラフ4
[グラフ4]P2プロジェクト バッチ機能 オフショア先・国内別の10CFPあたりの作業時間
  • ①担当者別に見ると、bさんは、最初に開発した機能BT-007より、後半で開発した機能の方が実装・単体テスト時間が小さくなりました。
  • ②BT-026は後半に開発した機能ですが実装・単体テスト時間が大きくなっています。また、国内で受入れ後の実装・単体テスト時間が大きく発生しました。これはシステムテスト中に不具合が発覚して対応したためです。
  • ③オフショア先の実装・単体テスト時間だけを見ると小さいですが、国内の実装・単体テスト時間がオフショア期間中と受入れ後に発生しています。オフショア先と国内の作業時間を合わせると、前半に開発した他の機能と変わりません。この機能ユニットのグループは難易度が高いため、前半に開発した機能は国内・オフショア間のレビューや質問対応に多く時間がかかったことが分かります。
  • ④担当者bさんが後半に開発した機能は、質問やレビュー対応など国内の労力が発生していません。
  • ⑤後半にかけて実装・単体テスト時間が小さくなりました。質問やレビュー対応など国内の労力も発生していません。
  • ⑥他の機能と技術的に大きく異なり、難易度が高い機能でした。オフショア先・国内共に実装・単体テストが他と比べてかなり大きく時間がかかったことが分かります。

◎オフショア開発について分かったこと

[グラフ4]のオフショア先・国内の10CFPあたりの作業時間を比較すると、[グラフ3]の10CFPあたりの作業時間を見て分かった事に加えて、オフショア開発に関する以下のことが分かりました。

  • 前半に開発した機能と難易度の高い機能は、質問やレビュー対応の国内労力が比較的大きい(③⑥)
  • オフショア期間中に質問やレビュー対応の国内労力がかかった機能は、受入れ後の国内労力が発生する割合が高い(BT-028, BT-009, BT-026, BT-019, BT-022, BT-030)
  • 後半に開発した機能は、質問やレビュー対応の国内労力が小さくなるかゼロになる(①④⑤)
  • 受入れ後に不具合が発生した場合、不具合対応のため国内労力が大きくなる(②)

◎オフショア開発の生産性と品質

オフショア先の生産性を見たところ、難易度による影響はあるものの全体的に生産性は良いと言えます(実際には生産性が良いかの判断は、開発言語が同じである他のプロジェクトのバッチ生産性と比較しています)。オフショア開発の品質に関しても、受入れ後に不具合が発生したのは1機能であることから良いと言えるでしょう。

生産性と品質が比較的良かったのは、P2プロジェクトの以下のような進め方による効果だと考えています。

  • 開発事前準備資料として、サンプルコードや開発環境設定手順書を提供した
  • 情報共有サービスを利用してリアルタイムにやり取りした
  • オフショア開発期間中に国内での検収をきちんと行った

また、前節のオフショア開発について分かったことから、P2プロジェクトと同じような進め方をするオフショア開発では、以下の点をできるだけ考慮することで、より生産性を上げることができると考えられます。

  • 類似機能ごとに同じメンバーが開発を担当する
  • 開発時の質問やレビューでの指摘が多い機能は、国内からのフォローを強化する

分析結果のまとめ

さいごに、P2プロジェクトのバッチ機能ユニット間の分析結果を簡単にまとめます。まず、データから分析したバッチ生産性に影響した要因は以下でした。

  • 機能の難易度
  • 類似機能の開発経験

P2プロジェクトのバッチ機能の開発生産性は、機能の難易度と関係していました。また、類似機能のグループ内で後半に開発した機能の生産性が上がる傾向が見られ、類似機能の開発経験によって実装効率が向上したと分析しました。

また、P2プロジェクトのオフショア開発の生産性と品質は比較的良く、前節に挙げたP2プロジェクトのオフショア開発の進め方の効果だと考えることができました。

分析結果のフィードバック

P2プロジェクトは、プロジェクト完了後にプロジェクトへの分析結果のフィードバックを行いました。フィードバックは打合せ形式で行い、測定担当とプロジェクトメンバーが分析結果を確認しながら開発期間を振り返り、データから分かったことだけでなくプロジェクトメンバーが感じた良かった点や改善すべき点も共有しました。

フィードバック後、フィードバックの場で得た新たな情報を含めた最終的な分析レポートを作成し、プロジェクトに提供しました。

この分析レポートから分かったことは、今後のプロジェクトの開発計画に活用できると考えています。

また、P2プロジェクトの分析結果はP2プロジェクトメンバーと共有するのはもちろんですが、他のプロジェクトが参考にできる部分もあると思います。分析結果を他のプロジェクトで活用してもらうため、私たちは年に2回開催する社内報告会で各プロジェクトの分析結果を報告しています。

おわりに

今回の記事では機能ユニット間の分析の例として、実際に測定分析したデータを元に分析の過程を紹介しました。分析した結果は、それほど目新しい内容ではないかもしれませんが、何となく感じていたことを定量的に示されることでプロジェクトにとって新たな気付きがあるかもしれません。

さて次回は、今回は記事の量が多くなってしまったため紹介しきれなかった大規模プロジェクトなど他のプロジェクトの測定結果をご紹介する予定です。