開発効率の推移

本節では開発効率の推移より，開発中におけるプロジェクトの状況を説明する．まず，図

6-10に示すCPI，SPIのグラフより，本プロジェクトの開発効率の時間的推移を確認する．

図 6-10 CPI，SPIの時間的推移

時系列に沿って，CPI，SPIの値の傾向を確認し，その時点においてプロジェクトの開発状 況がどうであったのかを説明する．

①はイテレーション0における開発効率を示している．値を見てみるとCPI，SPIともに1 より低く，効率が悪い状況であるといえる．特にCPIは0.55であり，所要工数のおよそ2倍 の工数を必要とする効率である．SPIも0.77と低く，開発開始直後から開発に遅れが発生し てしまったという状況である．これは開発初期である為に，メンバが開発に慣れておらず，

当初予想した通りの効率を発揮できなかったためである．

本プロジェクトではリスク対策として，筆者は要件定義フェーズの時期から開発言語であ るRubyやフレームワークRuby on Rails，ソースコード管理システムGit，プロジェクトマネ ジメントツールRedmineについて先行調査を行い，使用経験が無いメンバに対して手順や実 装の指導を行っていた．こうした事前準備により，筆者は開発初期からある程度効率良く開 発が出来ると考え，計画を立てた．しかし実際は開発言語などの基本的な理解だけでは十分 でなく，技術の応用的な利用やメンバ間の連携など，開発に入って初めて直面する問題や課 題が多かった．その結果，思った通りに開発を進める事が出来ず，遅延が発生してしまった と考えている．

イテレーション0の振り返りの際に，開発効率が悪い事についてチームメンバと簡単な意 識共有と議論を行った．その結果，プロジェクトメンバのほとんどが実装技術に慣れず，ま た他のメンバとの連携も曖昧で効率的に行えなかったと考えていた．しかし2週間の開発で

ある程度慣れ，次回イテレーションからは効率的に開発を行うことが出来ると考えた．その ため，筆者は計画の再設定は行わず，経過を伺う事にした．

②は休み明けのイテレーション1 における開発効率を示している．値を見てみるとCPI，

SPI共に改善の傾向が見て取れる．特にSPIは1.0になり，計画に実績が追いついた．これは メンバ各自の作業効率が①の時に比べて大幅に向上したためである．CPIが0.55から0.67に 上がっている事からもこれが分かる．

③はイテレーション2 の前半部分の開発効率を示している．ここで，SPI が再度減少して いる事が分かる．これはイテレーション0，1で作りこんだバグがイテレーション2の実装箇 所と結合する際に顕在化したことに起因し，その対応に当たったため進捗に遅れが出てしま ったと考えている．

顕在化したバグは「週カレンダ閲覧機能」において表示に欠陥が生じるというものであっ た．このバグについて品質マネジメント担当者より，クラス設計及びデータモデル設計に関 して，コード保守性に問題があると報告を受けていた．この問題はイテレーション2におい て実装が計画されていた代行管理機能群の実現において，その生産性の低下やバグ混入の可 能性の増大などのリスクが想定された．この問題への対応として，品質マネジメント担当者 と筆者でデータモデル及びクラスの再定義とリファクタリング案をチームに提案した．リフ ァクタリング案はその対応にかかるコストの大きさ等により再議論され，部分的な対応を実 施する事に決まった．この一連の作業と，実際のリファクタリング，顕在化済みのバグ対応 などに時間を割いてしまったため計画に対する実績を生み出すことが出来ず，遅延に繋がっ たと考えられる．

③以降はSPIとCPI共に上昇傾向が続いている．特にSPIは1.0に近い値を維持し，進捗 上特に問題の無い状態を維持することが出来ている．CPI は閾値の 0.8 より低い状態が続い ているが，作業時間が8時間を超える事はほとんどなく，健全性を保つことが出来た．

以上のように，本プロジェクトでは投資コストの超過が期間全体を通じて発生していたが，

開発効率においては許容範囲内の数値を維持し，開発を完了することが出来ている．また，

開発効率に関しては時間経過に伴って向上している．CPI，SPIの値をそれぞれ軸とし，同時 点における値の組合せをプロットした図を基に，プロジェクトの開発効率の改善傾向を確認 する．拡大した図を次の図 6-11に示す．

図 6-11 CPI，SPIの改善傾向

この図は，実測値に基づく図 6-5のグラフにおいて，第3象限の箇所を拡大したものであ る．グラフの見方については6.6.2項で既に説明した通りである．このグラフでは左下に行く ほど開発効率が悪く，右上に行くほど開発効率が良いと評価することが出来る．

図のプロットの流れを時系列に見ていくと，一度左下に推移し，CPI，SPI 共に悪化する．

これは，当初の学習コストによる開発効率の悪化によるものである．その後，SPIが回復し，

続いてCPIも回復する．開発メンバが実装技術に慣れた事，チーム内での連携が強まった事 により開発効率が上がった状態である．その後SPIは一度低下するが，その後CPIの回復に 伴い再度回復し，完了日を迎える．大局的にみると，イテレーション0で最低値を記録した 後はプロットが右上に推移し，CPI，SPI共に改善していく傾向であった事が分かる．