Comments
Description
Transcript
修論TEXファイル - ソフトウェア設計学研究室
NAIST-IS-MT0951139 修士論文 ソフトウェア発注者視点からの 開発プロジェクト理解支援 オユンビレグ チングン 2011 年 2 月 3 日 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 本論文は奈良先端科学技術大学院大学情報科学研究科に 修士 (工学) 授与の要件として提出した修士論文である。 オユンビレグ チングン 審査委員： 飯田 元 教授 （主指導教員） 西谷 紘一 教授 （副指導教員） 松本 健一 教授 （副指導教員） 吉田 則裕 助教 ソフトウェア発注者視点からの 開発プロジェクト理解支援∗ オユンビレグ チングン 内容梗概 ソフトウェア開発の仕様凍結後に発生する要件の変更・追加は開発コストの増加 につながる．このように発生したコスト増加の具体的な原因はソフトウェア発注者 の関心事項である．要件の追加や変更が開発コストに及ぼす影響を理解すること で，次回以降の発注あるいは反復の際，コスト見積もりの参考にする情報が得られ る．しかし発注者によるプロジェクト分析は容易ではない．この理由は，ソフト ウェア開発に関わる専門用語の理解が困難であることや，受注者とは別組織のた め，開発プロジェクトの進捗を逐次に把握することが困難なためである．本研究 は，開発プロジェクトの分析方法について専門知識を持たない発注者を対象に，要 件の追加・変更がコストに及ぼす影響の理解を支援する手法を提案する．提案手法 は発注者が関心を持つ“要件”と“コスト”という２つの概念に着目し，その関係を 発注者にとって理解容易な形で可視化する．要件の観点から増加コスト分析を支援 するため，要件変更・追加とコスト変動を結び付けて追跡する．具体的には，コス トデータを日付・要件ごとに分類提示し要件変更・追加の行われた時期とその他要 件に与える影響を時系列上に提示する，要件ごとの工程別コストや増加コスト及び その修正作業の生産性を提示しこれらの把握を支援する．本論文では，提案手法を 適用する仮想プロジェクトを想定し，本手法に沿った分析例を示した．考察では， 提案手法に沿った分析支援環境の必要性について議論し，最後に今後の課題につい て述べる． キーワード ソフトウェアプロセス，プロジェクト分析支援，要件管理，定量的管理，コスト見 積り ∗奈 良 先 端 科 学 技 術 大 学 院 大 学 情 報 科 学 研 究 科 情 報 シ ス テ ム 学 専 攻 修 士 論 文, NAIST-IS- MT0951139, 2011 年 2 月 3 日. i Support of Realizing Development Project from Software Acquirer’s Perspective∗ OYUNBILEG CHINGUN Abstract In software development, changes or additions to requirements after specification freeze lead to cost increase. The reason for this increase is a concern for software acquirers. Analysis to specify the reason for the cost increase can be used as a reference for the estimation of next order or iteration. However for software acquirers, understanding with vendor, especially technical terms, as well as if they are in separate organizations can make project analysis difficult for them. In this thesis, we propose a method to support the analysis of cost impact caused by requirement additions and changes, which is dedicated for software acquirers who likely do not have prior professional knowledge on project analysis techniques. The method is for analyzing change costs by investigating the relationship between cost and requirements, which are immediate interests for acquirers. More specifically, by classifying development costs by date, for each requirement and per development phases, software acquirer would be able to understand the timing of changes, additional cost and its performance. We assumed a project to apply this method, and exhibited an example of analysis. In consideration, we discuss about the necessity of an application tool according to the proposed method. Keywords: Software Process, Supporting Project Analysis, Requirements Management, Quantitative Management, Cost Estimation ∗ Master’s Thesis, Department of Information Systems, Graduate School of Information Science, Nara Institute of Science and Technology, NAIST-IS-MT0951139, February 3, 2011. ii 目次 1. はじめに 1 2. 関連研究 3 2.1. プロジェクト分析手法 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. 要件分析・管理手法 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. 開発コスト見積り手法 . . . . . . . . . . . . . . . . . . . . . . . . . 6 提案手法 7 3.1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. 入力データ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. 分析のための提示情報 . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. 分析の用途 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. ユースケースに基づく分析例 4. 14 4.1. 想定プロジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. 分析目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. 分析対象データ 4.4. 分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5.1. 分析結果に対する考察 . . . . . . . . . . . . . . . . . . . . . . . . 25 4.5.2. 提案手法の適用可能性 . . . . . . . . . . . . . . . . . . . . . . . . 25 分析支援環境 ReQuost の設計 5. 6. 28 5.1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. 提供する機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3. 分析シナリオ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4. データフォーマット . . . . . . . . . . . . . . . . . . . . . . . . . . 33 おわりに 34 iii 謝辞 35 参考文献 36 iv 図目次 1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 アプローチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 作業日報の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 可視化観点と情報提示 . . . . . . . . . . . . . . . . . . . . . . . . 9 5 時系列に着目した可視化 . . . . . . . . . . . . . . . . . . . . . . . 10 6 工程に着目した可視化 . . . . . . . . . . . . . . . . . . . . . . . . 11 7 増加工数に着目した可視化 . . . . . . . . . . . . . . . . . . . . . . 11 8 生産性に着目した可視化 . . . . . . . . . . . . . . . . . . . . . . . 12 9 要件別の工数集計表 . . . . . . . . . . . . . . . . . . . . . . . . . 17 10 セルの書式ルール 11 各要件の工程別工数（人時） 12 各要件の工程別工数と各要件合計工数の比率 . . . . . . . . . . . . 19 13 各要件の合計工数に対する比率の分析例 . . . . . . . . . . . . . . . 20 14 各要件の工程別工数と総工数の比率 . . . . . . . . . . . . . . . . . 20 15 総工数に対する比率の分析例 16 要件・工程別の増加工数（人時） . . . . . . . . . . . . . . . . . . 22 17 増加工数と合計増加工数の比率 . . . . . . . . . . . . . . . . . . . 22 18 増加工数の総工数に対する比率 . . . . . . . . . . . . . . . . . . . 23 19 実装工程での増加工数に関わる作業の生産性 . . . . . . . . . . . . 24 20 分析支援環境 ReQuost の概念図 . . . . . . . . . . . . . . . . . . . 28 21 分析支援環境 ReQuost： 時系列ビュー . . . . . . . . . . . . . . 31 22 分析支援環境 ReQuost： 工程ビュー . . . . . . . . . . . . . . . 31 23 分析支援環境 ReQuost： 増加コストビュー . . . . . . . . . . . . 32 24 分析支援環境 ReQuost： 生産性ビュー . . . . . . . . . . . . . . 32 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 . . . . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . . . 21 v 表目次 1 想定プロジェクトでの要件 . . . . . . . . . . . . . . . . . . . . . . 15 2 作業日報（工数単位：人時） 3 各要件ごとの作業工数（工数単位：人時） . . . . . . . . . . . . . 16 . . . . . . . . . . . . . . . . . . . . 16 vi 1. はじめに この数年，ソフトウェア開発の需要が増加すると共に，ソフトウェア開発プロ ジェクトへの発注者側の理解と参加をより向上させる枠組みが求められるように なってきている．一般的なソフトウェア開発では，受発注者間で話し合った上で， 要件を定義し，開発コストを見積もる．しかし開発が終わってみれば，実コストが 見積もりより超過している事が深刻な問題となっている [11]． 開発コスト超過の主な理由としては，仕様凍結後に発生する要件変更・追加が挙 げられる．これは，プロジェクト開始後に要件の変更・追加が発生すると，要件の 再定義や設計，コーディング，マニュアルなどの修正作業が発生するためである [3]．要件の変更・追加は，発生する時期がプロジェクトの後半にさしかかるほどコ ストに与える影響が大きくなる傾向にある．大規模プロジェクトでは，要件定義工 程での修正コストと保守工程での修正コストの差が 100 倍程度生じたという調査結 果が実際にある [10]．日本情報システム・ユーザー協会 (JUAS) の調査では，要件 変更の程度が大きいほど，工期が遅延する傾向にあることが報告されている [23]． このような開発コスト増加の発生原因はソフトウェア発注者の関心事項である． コスト増加の原因を分析することで，次回以降のコスト見積もりの参考にすること が可能となる．もし，発注者自身で開発コスト超過原因を分析できれば，開発者側 の負担を増やさず追加コストを節約出来る．しかし発注者自身による開発プロジェ クト分析は容易ではない．これは，ソフトウェア開発に関わる専門用語の理解が困 難であることや，受発注者は通常，別組織のため，どのような原因で発生していた か内部情報を用いて詳細に把握することができないためである [1]． 図 1 背景 1 本研究では，ソフトウェア開発プロジェクトの分析について専門的な知識を持た ない発注者を対象に，要件とその実装に費やされたコストの関係に関する分析を支 援する手法を提案する． 図 2 アプローチ 具体的には，下記に示す 4 つの観点から要件とそれに関連するコストや生産性に 関する情報を可視化する． （A）各要件に関連する作業がいつ行われ，どの程度のコストが費やされたか． （B）各要件に関連する作業がどの工程で行われたか．また各工程においてどの程 度のコストが費やされたか． （C）プロジェクト開始後に追加や変更が発生した要件について，これらの要件の 再実装にどの程度のコストが費やされたか． （D）プロジェクト開始後に追加や変更が発生した要件は，これらが発生しなかっ た要件と比較して生産性に違いがあるか． 発注者はこれらの観点から整理された情報を用いることで，要件とコストの関係 について分析を行うことが可能となる． 本論文では仮想のプロジェクトデータを用いて，発注者がどのような手順でプロ ジェクト分析を行えばよいか，そのユースケースを示す．また，このユースケース を通して，提案手法の妥当性及び制約について考察する． 以下，第 2 章では関連研究について述べ，第 3 章において本研究で提案する分析 支援手法について述べる．第 4 章では架空のプロジェクトデータを用いて提案手法 のユースケースを示すとともに，提案手法の妥当性について考察する．最後に第 5 章で本論文のまとめを行う． 2 2. 関連研究 ソフトウエア開発プロジェクトの管理および分析の支援に関する研究はこれまで 盛んに行われてきている．特に近年では，開発プロジェクトの可視化に関する研 究や，定量的なプロジェクト管理手法に関する研究が多く行われている．実際に PMBOK[15] や CMMI[5] などのプロジェクト管理に関わる規格・フレームワーク では，プロジェクトの定量的管理が達成すべき項目の一つとして掲げられている． また，近年ではソフトウェア開発において発注者・受注者間で開発状況を表す データを共有する必要性が指摘されている [18]．発注者・受注者間で開発データが 共有されることで，開発におけるリスクの低減・回避や，円滑なコミュニケーショ ンが期待されている． 以下では，開発プロジェクトの管理および分析支援に関する既存研究について述 べる．また，本研究で提案する手法で着目する「要件」に関して，その分析・管理 手法に関する研究について紹介する．さらに，提案手法を適用した結果の応用例の 一つである「コスト見積もり」に関連して，開発工数の見積もりに関する研究も併 せて紹介する． 2.1. プロジェクト分析手法 開発プロジェクトの分析手法は，定性的なアプローチをとるものと定量的なアプ ローチをとるものに大別される．定性的なアプローチとしては，プロジェクトのス テークホルダー一覧やシステム構成，スケジュールの俯瞰図を作成してプロジェク トの全容を把握する方法や，自己評価シートやチェックシートを利用してプロジェ クトのリスクを把握する方法がある [19]．定量的なアプローチとしては，開発成果 物や開発過程の特徴を表すメトリクスを収集し，その傾向を分析する手法があげら れる．定量的なアプローチの具体例としては，設計文書のレビュー密度とバグ検出 密度を 2 次元にプロットすることで分析するゾーン分析手法 [20] やプロジェクト 遅延リスクの検出 [24]，ソフトウェア品質会計 [27] などがある． また，近年多くの開発プロジェクトで版管理システムやバグ管理システムに代表 される開発支援ツールが利用されている．それに伴い，これらのツールで自動的に 3 収集されたデータをもとに，先に示したようなプロジェクトの分析を支援するツー ルがいくつか提案されている． フラウンホーファー協会実践的ソフトウェア工学研究所など 7 組織が参加す る SoftPit プロジェクト*1 では，定量的管理を支援する環境の提供を行っている． SoftPit プロジェクトは，Münch らが提唱する Software Project Control Center という概念 [9] に基づき，開発に関わる複数のステークホルダーが持つ，プロジェク ト管理に関する種々の目的を扱うことを想定している．また，SoftPit では Specula というツールを開発している*2 ．Specula は，プロジェクトで収集されたデータを 一箇所に集約し，多種多様な分析のためのビューを提供している．このビューはプ ロジェクトの管理目的に沿ってカスタマイズが可能となっている． EASE プロジェクトで開発された EPM（Empirical Project Monitor）[12] は， 広く普及している開発支援ツール（版管理システム CVS*3 ，障害管理システム GNATS*4 など）と連携し，開発履歴データをリアルタイムに収集し，定量データ 分析を可能にするシステムである．EPM では，個々の開発支援ツールが収集した データを集計，分析することで，グラフなどの形で可視化する．これにより分析者 は，開発プロジェクト実施時に，開発者に作業負荷をかけることなく，プロジェク トの状況をリアルタイムに分析，可視化することが可能となる． Ohkura らが開発しているプロジェクトリプレイヤ [13] は，版管理システムやバ グ管理システムに蓄積されたデータをもとに，開発プロジェクトをビデオのように 再生する機能を持つ分析ツールである．プロジェクトリプレイヤはプロジェクトの 事後分析に用いられ，プロジェクト実施中に発生したイベントを振り返り，今後の プロジェクトにおいて活かせる知見の抽出を目指している． 同様に Okumura らが開発した IZMI[14] は，プロジェクトの進捗状況を把握す るための可視化ツールである．IZMI は版管理システムに記録された開発成果物 （設計書やソースコードなど）の編集履歴を入力とし，成果物がいつ・誰が・どの程 度編集したかを時系列上可視化する． *1 http://www.soft-pit.de/ *2 http://code.google.com/p/specula/ *3 http://www.nongnu.org/cvs/ *4 http://www.gnu.org/software/gnats/ 4 2.2. 要件分析・管理手法 本研究で着目しているソフトウェア開発の要件に関しては，これまでに種々の分 析手法や管理手法が提案されている． 要件管理に関しては，web を用いてチケットベースの案件管理を行うシステムで ある Trac*5 や Redmine*6 の障害管理機能を拡張し要件を管理する試みがある [28]． また，商用ソフトウェアでは，ReqMan*7 や RaQuest*8 といった要件管理ツールが ある．ReqMan は要件を管理するとともに，要件変更が発生した際には自動的に 追跡を行い，要件変更を可視化する．また，統合開発環境上で動作し，ユースケー スの生成などを通して要求分析に関わる機能も提供している．RaQuest も同様に， 要件の把握，管理，追跡を目的としたツールである．RaQuest は UML モデリング ツールと連携して，要件と設計情報との関連も管理し，要件から実装までのトレー サビリティを実現している． 近年盛んに行われているアジャイル開発における要件管理に関する調査として は，Ramesh らの研究があげられる [16]．この調査はアジャイル開発を行っている アメリカの 16 のソフトウェア開発組織を対象に実施された．その結果，アジャイ ル開発における要件定義に関するプラクティスとして，「対面コミュニケーション」 や「反復型で行うこと」といった 6 つのものが明らかになった．また，文献 [16] で は，上記のプラクティスを実践した際のリスクを評価するフレームワークも提案し ている． Bencomo らは要件の追加・修正を自身で行う自己適応型ソフトウェア（SelfAdaptive System，SAS）の概念を提唱している [2]．SAS は要件自体をソフトウェ ア内で管理し，ソフトウェア実行時に周囲の環境に合わせて動的に要件を修正して いくというものである． Syeff らはエンドユーザ自身により早期の要件整理支援を目的とした要件導出 ツール iRequire を提案している [17]．iRequire はスマートフォンなどの携帯端末 *5 http://trac.edgewall.org/ *6 http://redmine.jp/ *7 http://www.requirementone.com/ *8 http://www.raquest.com/ 5 で動作するよう実装されている．ユーザは日々の生活の中で Blog を書くような感 覚で気軽に要件を記述することができる． 2.3. 開発コスト見積り手法 プロジェクトの定量的な管理を行う際に着目される要素の一つに開発時に発生す るコストがある．ソフトウェア開発プロジェクトでは，開発コストの単位としては 工数が採用されることが多い．この工数の見積もりは，プロジェクト管理を行う上 で重要な要素の一つとしてあげられている [15]． 工数見積もり手法としては，類似プロジェクトの結果から新規プロジェクトの工 数を見積もる類似法 [7, 21] や作業項目を洗い出しその工数を足し合わせる積算法 [15]，COCOMO II[4] などの数学的なモデルを用いた見積もり手法などがある． 本研究でも着目している，要件の追加や変更を考慮した工数見積もり手法にして は，Mizuno らによる研究 [25] や Lavazza らによる研究 [8] が挙げられる． Mizuno らは仕様変更に伴って発生する作業の工数を見積もる手法を提案してい る [25]．この手法では，オブジェクト指向パラダイムに基づく設計開発を対象に， 仕様変更作業を開始する前に作業内容を推定する．その上でそれぞれの作業につい て，オブジェクト指向プログラムの特性を考慮に入れた上で重み付きの得点を集計 し，作業量を求める． Lavazza らは要件変更によって発生する影響の定量的な分析手法と，要件変更 に伴う工数の見積もり手法について提案している [8]．提案手法では，要件変更に 伴って影響をうける作業やそのコストを，再実装プロセスとプロダクト変更モデル を計測することで算出する．これにより，従来の行数やファンクションポイントを 用いた工数見積もり手法と比較して，要件の特徴を反映した見積もりを行うことが できる． 6 3. 提案手法 3.1. 概要 本研究では，ソフトウェアを発注した顧客（ユーザ）による開発プロジェクト分 析を支援する手法を提案する．提案手法は「要件」に着目し，要件がどのように実 装されたかをユーザに提示する． 要件とはユーザがソフトウェアがなすべき機能に加え，応答速度などの非機能要 件も含めた，ソフトウェアに対する要求である． 要件は設計書やソースコードといった開発成果物に比べ，ユーザがソフトウェア に求めているより具体的な概念である．よって，要件の観点から開発プロジェクト の分析を行うことは，よりユーザにとって理解が容易であると考えられる．また， 要件はソフトウェア開発中に，発注者側の要請により追加されたり，設計を進めて いる間に要件が変更されると言ったことがある．これらの要件の追加・変更に関し ては，しばしば開発終了後に問題となることがあり，場合によっては訴訟に発展す る場合にもある．このような訴訟において争点となるのは，「ソフトウェアが必要 十分な機能を実装していなかった」といった点である．このような観点からも，要 件の観点からプロジェクトを分析する必要があると考える． 提案手法では，各要件を実装するために，いつ・どの程度のコストがかかったか を把握できるように可視化する．コストも要件と同じくユーザによってわかりやす い概念であり，ユーザによるプロジェクト分析に向いている観点と言える． 提案手法では，ソフトウェア開発プロジェクト時に要件ごとにかかった工数を記 録していることを前提としている．このようなデータの収集に関しては 3.2 節で述 べる．このデータを用いて，要件ごとにそれを実装するための作業が，いつ・どの タイミングで発生していたかを分析者（ユーザ）に提示する．このように要件ごと の情報を提示することで，ソフトウェアに対する要求を満たすためにどのような作 業に工数が費やされていたか，また要件の間で作業にどの程度の工数差があるかを 分析することができる．分析結果からは，要件ごとの工数見積りに関する基礎デー タを蓄積することや，問題発生時に要件やコストの観点からプロジェクトにおける 問題の発生要因の特定が可能になることが期待される． 7 以下，3.2 節で情報提示に必要なデータの形式について述べる．3.3 節では本手法 で提案する分析のための 4 つの提示情報とその観点を整理する． 3.2. 入力データ 本研究では，開発で生じるコストを工数*9 で表現する．提案手法では，要件ごと および工程ごとにどの程度の工数がいつ投入されたかを時系列に記録された情報を 必要とする．このようなデータは図 3 に示すような作業日報をもとに，作業内容が どの要件に関わる作業であったかを人手で判断することで，要件・工程ごとに投入 された工数を算出することができる． 図 3 作業日報の例 このようなデータ収集は人手による判断が必要となるため，分析コストが高くな る．一方で，近年 StagE プロジェクトで策定しているソフトウェアタグ規格 [18] や，この規格に基づいて開発されている自動収集ツール [26] を利用することで，分 析のためのデータ収集コストを低く抑えることが可能になると考えられる．さら に，Monden らが提案する TaskPit[22] や，Hayashi らが提案するツール [6] を利 用することで，開発時に行っていた作業がどのような意図（ある要件に対する試験 を行っていた，など）を持って行われていたかを正確に記録することが可能となる． *9 作業量を表す概念．時間と人数の積で表される． 8 3.3. 分析のための提示情報 下記の（A）から（D）に示す 4 つの観点から要件の追加・変更に伴い開発コス トがどのように変化しているか，開発コストに関わるデータを提示する．発注者は 提示された情報をもとに，コスト増加の原因を分析する． （A）要件変更・追加が行われた時期を把握するため，開発作業日ごとのコストを 要件別に提示する． （B）要件ごとにどのような作業に時間がかかっているかを把握するため，要件ご とに工程別にかかった開発コストを提示する． （C）追加・変更された要件の再実装に要したコストを把握するため，要件・工程 ごとに増加コストを提示する． （D）要件変更・追加によって生産性に違いがあるかを把握するため，これらの要 件に関わる増加作業の生産性を提示する． 図 4 可視化観点と情報提示 （A）および（B）は日時や工程の観点から，要件ごとに費やされた工数を可視化 する．一方（C）および（D）ではプロジェクト開始後に発生した要件の追加や変更 に要した工数に着目して可視化する．以降では（A）から（D）の情報提示について 詳細を示す． 9 （A）時系列に着目した可視化 プロジェクト全体で作業がどのように行われていたか，要件の観点から俯瞰す る．図 5 は要件の観点から作業に費やした工数を可視化している．図 5 で各行は要 件を，各列は日付を表している．各セルの数字は工数であり，対応する要件がその 日にどの程度工数が投入されていたかを表している． 図 5 時系列に着目した可視化 これにより，要件ごとにいつどの程度の工数が費やされていたか俯瞰できる．こ のような可視化を行うことで，どの要件に関する作業がいつ行われていたかを把握 することができる．また，仕様が確定したにも関わらず，作業が進んでいないもの なども把握することが可能となる． （B）工程に着目した可視化 （A）では要件ごとにどの時点で工数がかかっていたか，時間軸で表示していた． （B）では各要件に対応する作業にどの程度の工数が投入されたか，工程ごとに表示 する． 図 6 で各行は要件を，各列は工程を表している．（A）と同じく，各セルの数字は 工数であり，対応する要件がその工程でどの程度工数が投入されていたかを表して いる．これにより，要件ごとにどの工程で工数がどの程度費やされていたかを把握 できる．例えば，要件定義や設計に十分工数が割かれていなかった要件や，実装に 最も工数が費やされている要件などを発見することができる． 10 図 6 工程に着目した可視化 （C）増加コストに着目した可視化 （A）および（B）では要件ごとに投入された工数を，時間軸に沿って可視化した り工程ごとに可視化していた．（C）では要件が追加・変更された際に投入された工 数を表示する． 図 7 増加工数に着目した可視化 図 7 で各行は要件を，各列は工程を表している．各セルの数字は対応する要件 の追加もしくは変更に費やされた工数（以降，増加工数と呼ぶ）であり，対応する 要件がその工程でどの程度修正・追加の作業に工数が投入されていたかを表してい る．これによりプロジェクト開始後に追加で発生した修正作業や追加作業にどの程 度の工数が費やされたかを分析することができる． 11 （D）生産性に着目した可視化 （D）ではプロジェクト開始後に追加・変更された要件に関わる追加・修正作業の 生産性を可視化する． 図 8 生産性に着目した可視化 図 8 で各行は要件を示し，各要件について変更量，修正工数および生産性を示し ている．このように要件がプロジェクト開始後に追加されたものか，プロジェクト 開始前に確定していた要件から変更されたものかで，生産性にどの程度の違いがあ るかを分析することが可能となる． 12 3.4. 分析の用途 3.3 節で示した情報を用いて，下記のような用途で分析を行うことが想定される． 作業実施状況の確認 ソフトウェア発注者（ユーザ）にとって，開発作業が適切に行われていたかソ フトウェアの構築状況を把握することは重要な関心事の一つである．提案手法は， ユーザのソフトウェアに求める要件の観点から，各要件を実装するためにどの程度 作業が実施されていたかを提示する．要件はソフトウェアの品質に直結する要素で あり，要件の観点から作業状況を把握することは，設計書やソースコードといった 成果物の観点からの把握と比較して，ユーザにとってよりわかりやすいと考える． 見積り基礎データの構築 ソフトウェア開発の計画時における開発工数の見積もりは非常に重要なものと なっている．工数見積の方法としては，類似プロジェクトからの類推による方法 や，COCOMOII に代表されるモデルによる算出法，WBS を用いた積算法などが ある．この中で積算法は，開発時に発生する作業を洗い出し，各作業に必要な工数 を積み上げていく方法である．提案手法は積算に置いて工数を積み上げる際，作業 が要件の追加によるものなのか？修正によるものなのか？という観点から，工数を 見積もる際に参考となるデータを分析することができる． 次章では見積もり基礎データの構築を目的とした分析を行う際に，どのような手 順で行えば良いかユースケースシナリオを示す． 13 4. ユースケースに基づく分析例 本章では， 3.3 節で述べた開発プロジェクト分析支援のために提案した提示情報 を利用した分析について例を示す．例示にあたっては，架空の開発プロジェクトの データを示し，このデータを用いて分析を行う．以下，4.1 節でシナリオ例で想定 しているプロジェクトについて述べる． 4.1. 想定プロジェクト 分析対象のプロジェクトは，研究室の成果として発表した文献（論文や学会発表 資料など）を一元管理するための Web アプリケーション（以降「文献管理システ ム」と呼ぶ）の反復型開発プロジェクトを想定している．このプロジェクトは，発 注者が民間のソフトウェア開発会社（以降「開発者」と呼ぶ）に発注を依頼したケー スを想定している．また開発時にはソースコード行数や作業時間などのプロジェク トの分析を行うのに必要なデータの収集しているものとする． 開発ではシステムの機能的要件を発注者が整理し，その後発注者と開発者との間 で数回にわたる質問表ベースの回答のやり取りを通じて要件定義を行ったものとす る．要件定義後は開発者がシステム開発および，データ収集を実施する． 4.2. 分析目的 反復型開発は， 「要件定義」 ， 「設計」 ， 「実装」 ， 「テスト」の一連の工程を１つのま とまり（反復）として，この反復を複数回実施する．ただし，各工程をどの程度実 施するかは反復ごとに異なり，初期の反復では要件定義に重点が置かれ，終盤の反 復ではテストに重点が置かれる． ここでは追加要件と要件変更でその作業に生産性の違いがあるかを確認すること を分析の目的とする．分析結果は，次回以降の反復において作業工数を積算法で見 積もる際の基礎データとして利用することができる． 14 4.3. 分析対象データ 開発に当たっては，表 1 に示すように 8 つの要件が最終的に発生したものとす る．ここで，R1，R3，R6 は開発中に仕様変更が発生した機能である．また，R7， R8 は開発中に追加された機能である． 表 1 想定プロジェクトでの要件 追加 変更 要件 ID ○ R1 R2 R3 R4 R5 R6 R7 R8 ○ ○ ○ ○ 要件の内容 文献登録 文献情報詳細 文献検索 文献情報編集 文献情報削除 ファイル添付 文献インポート ユーザ管理 工数に関するデータとしては，表 2 に示すような形式で作業日報が記録されてい たこととする．この作業記録にある作業内容から表 1 に示した機能のうちどの機能 に関わる作業か対応を取ったものを表 3 に示す．以降では表 3 に示したデータを提 案手法を用いて可視化し，どのような分析が可能であるかを示す． 15 表 2 作業日報（工数単位：人時） 表 3 各要件ごとの作業工数（工数単位：人時） 16 4.4. 分析 本節では，3.3 節で示した (A) から (D) の 4 つ観点からの可視化をもとにした， 具体的な分析のユースケースについて述べる． (A) 時系列に着目した可視化の分析 収集されたデータから，時間軸に沿って各要件にどの程度の工数が投入されてい たかを把握するために図 9 に示す集計表を作成した．図 9 では，各要件に投入され た工数を，投入された日付で時系列にまとめている．左列にはそれぞれの要件に対 して要件変更や要件追加が行われたかどうかを判別するためのチェックボックスを 備えている．また，要件ごとの工数と並列して開発工程ごとの工数も下段に提示し ている．さらに，分析をより円滑に行うために，図 10 に示すルールに従って工数 を示す各セルに色づけを行った．これらの情報により，工数がかかりやすい要件や 開発工程，時期などを俯瞰することが可能となる． 図 9 要件別の工数集計表 図 10 セルの書式ルール 17 この可視化により，ユーザは次のような分析を行うことができると考えられる． 各要件項目のコスト内訳を時系列に沿って把握 各要件項目の行に着目することで，それぞれの要件でどれだけのコストが掛 かっているのかを把握することができる．各要件の大まかなコスト内訳は， 工数の合計で把握することができるが，時系列で提示された工数の遷移を確 認することでより詳細な情報を得ることができる．例えば，仕様変更の有無 によってコストがどれだけ増えるのか，或いは開発後期における機能追加が 他の要件項目に与える影響（機能追加に伴う追加や修正作業の工数）といっ た情報を得ることができる． 各開発工程のコスト内訳を時系列に沿って把握 各開発工程の行に着目することで，工程別の大まかなコスト内訳を知ること ができる．本章で想定しているプロジェクトは，要件定義，設計，プログラ ミング，テスト，レビューの順で開発が進むこととしている．このようなプ ロジェクトでは，時系列で各工程の工数を見た場合，時間の経過と共に工数 の発生がその後の工程へと推移すると考えられる．例えば要件定義や設計の 工数が開発の全般にわたって記録されている場合，プロジェクトが正常に遂 行されていない可能性が考えられる．また，要件の変更や追加で新たに発生 する工数を工程別に把握することで，次回発注時のコスト見積もりや納期時 期の推定を支援することができると考えられる． 要件の変更と追加が行われた時期とその影響を把握 セルの色分けによって，発注者が要件の変更や追加を行った時期を俯瞰する ことができる．また，要件の変更や追加が他の要件にもたらしたコスト増 加や，時期によって掛かる工数の違いを把握することができる．例えば，レ ビューが終わった直後に発生した要件変更と，しばらく時間をおいてから 行った要件変更とで工数にどれだけの差が出るか，といった分析が可能と なる． 18 (B) 工程に着目した可視化の分析 前述の分析 (A) では図の横軸に時間をおいて，要件ごと，開発工程ごとに時系列 分析を行った．本節では開発工程ごとに各要件にどの程度の工数が投入されていた かという観点から分析を行う．縦軸に要件項目，横軸に開発工程を図 11 に示す． 図 11 各要件の工程別工数（人時） 図 11 では，各要件に投入された工数を工程ごとにまとめている．これらの可視 化によって，要件ごとに掛かるコストの違いを明らかにできる．例えば，要件 R4 の総工数は 30.5 と，R1 の 32.5 よりも低いが，プログラミング工程に掛かった工 数は R4 が 14.5，R1 が 13 と R4 の方が高くなっている．これらの情報から，R4 は実装に掛かるコストは高いが機能としては単純な要件であり，R1 はやや複雑な 機能であるが実装は R4 よりも容易であると推測できる．このような情報を得るこ とで，要件変更を行った際に発生するコストの大小などを見積もることが可能であ ると考えられる．また，各要件でそれぞれどの工程に一番工数が投入されていたか を明らかにするため，図 12 のように要件ごとに工数の比率をまとめた． 図 12 各要件の工程別工数と各要件合計工数の比率 図 12 で最も工数の多い要件は R3 の 37.5 であり，総工数の割合でみると 18.2% と なっている．R3 の工程別工数を見ると，合計工数に対して要件定義とテストがそ 19 図 13 各要件の合計工数に対する比率の分析例 れぞれ 16.0%，20.0% と割合が高くなっている．また，要件定義に関しては R6 も 20.5% 突出している．これらは要件変更が行われたことが原因であると考えられ る．また，R2 は設計とプログラミングが 80% 以上を占めており，要件の変更や 大きなトラブルなどは発生しなかったと考えられる．このように，工程別の工数を パーセンテージで示すことで要件ごとの特徴を把握することができると考えられ る．図 13 に分析例のまとめを示す． 本分析ではさらに，全要件・工程の中で最も工数が投入されていた箇所を明らか にするため，図 14 のようにプロジェクト全体の総工数に対する比率をまとめた． 図 14 各要件の工程別工数と総工数の比率 図 14 は要件の変更や追加が行われた際のコストの変動を特付けている．分析例 を以下に示すと共に，図 15 に図示する． 1 図 15 において赤い線で囲まれた項目は，それぞれの列で高い割合を占めて ⃝ 20 図 15 総工数に対する比率の分析例 いる箇所である．他の行（要件項目）と比べて値が高くなっている場合は， 要件の変更や追加が発生している可能性があると考えられる． 2 要件 R3 のプログラミング工程は 8.3% となっており，これは全工程，全要 ⃝ 件の中で最も高い値である．実装コストが非常に高い機能であったり，要件 変更・追加が発生したりしている可能性があると考えられる． 3 工程別合計工数の割合から，設計，プログラミング，テストで全工程の 85 ⃝ ％を占めていることが確認できる．これは，要件定義やレビューに工数が多 く割かれている場合に変更や追加が発生している可能性が高いことを示唆し ていると考えられる． 4 要件 R1，R3，R6 は変更が発生したことが確認されている要件である．こ ⃝ れらの要件の合計工数には，要件変更によって増加した分の工数が含まれて いるが，図 14 からは増加した工数の内訳は確認することができない．増加 コストの分析については次節で述べる． 5 要件 R7，R8 は追加要件である．これらは新規で追加した機能であるため， ⃝ 工程別の工数の割合には特徴は見られない．合計工数の割合を見ると，要件 追加による増加コストの割合は 23.8% であることがわかる．要件修正と要 件追加の増加コストの比較は次節にて行う． 21 (C) 増加工数に着目した可視化の分析 前節では，開発工程別に各要件の工数を可視化した．ここでは，工数のうち要件 の変更と追加のみに着目して分析を行う．工程ごとに各要件の変更・追加にどの程 度の工数が投入されていたかを図 16 に示す． 図 16 要件・工程別の増加工数（人時） 図 16 では，各要件の追加・修正のために投入された工数を工程ごとにまとめて いる．また変更や追加のために最もコストが投入された要件を把握するために，増 加工数と増加の合計工数の比率を図 17 にまとめる． 図 17 増加工数と合計増加工数の比率 図 17 からは，次のような分析例が考えられる（番号は図 14 中の番号に対応）． 1 要件別にみた増加コストの割合では，要件 R8 が 29.9% と最も高い値を示し ⃝ ている．これは，新規に追加した要件であることと， 「ユーザ管理機能」とい う他の要件から独立した機能であることが原因の一つであると考えられる． 2 要件 R3 は修正に伴う増加コストであるにも関わらず，要件別割合では ⃝ 23.0% と高い値を示している．工程別にみると，プログラミングとテストだ けが追加要件である R7，R8 と並ぶ値となっている．これは，前節で述べた 22 R3 の実装コストの高さを裏付けるものと考えられる． 3 要件 R7 と R8 は追加要件であるため，工数がそのまま修正工数となってい ⃝ る．要件の追加と修正で増加コストにどの程度の差があるのかを明示するた めに，総工数に対する各増加工数の割合を次に示す． 図 18 増加工数の総工数に対する比率 図 18 は，総工数に対する増加工数（修正工数＋追加工数）の比率を要件別に示し ている．これにより，要件追加によって増加したコストは総工数の 23.8%（図中の 1 ），要件変更によって増加したコストは総工数の 18.5%（図中の⃝ 2 ）であり，修 ⃝ 3 ）にのぼることが確認 正・追加の作業にかかった工数は総工数の 42.2%（図中の⃝ できた． 23 (D) 生産性に着目した可視化の分析 要件の追加や変更に伴って生産性に違いがあるかを把握するため，各要件につい てプログラミング工程における生産性の比較を図 19 に示す． 図 19 における変更量として，以下の式で表されるソースコードの変更行数（工 程中にソースコードの追加された行数と削除された行数を足したもの）を用いる． 変更量 = 削除行数 + 追加行数 また，生産性として，ソースコードの変更量を工数で割ったものを用いる． 生産性 = 変更量 修正工数 図 19 実装工程での増加工数に関わる作業の生産性 追加行数や削除行数は開発時に収集しているものとする．図 19 より，追加され た要件に比べて，変更された要件の方が生産性が高いことがわかる．この理由とし ては，追加要件が新しく機能を実装するのに対し，変更要件は既存のものに機能を 加えるため生産性が高くなると考えられる． 以上のような分析を通して，次回反復時の作業見積もりに参考となる情報を得る ことができると考えられる． 24 4.5. 考察 4.5.1. 分析結果に対する考察 本節では，ここまでの分析経緯からどのような考察が可能であるかを示す*10 ．図 19 で示したように，変更があった要件（要件 R1，R3，R6）に関する作業の生産性 は 50∼60 の値を示している．一方で，プロジェクト開始後に新規に追加された要 件（要件 R7，R8）に関する作業の生産性は 30 台前半の値となっている．これよ り，変更があった要件に関する作業の生産性が生産性の平均値（41.4）より高い値 を示している一方で，新規に追加された要件に関する作業の生産性は平均値よりも 低い値を示している． この原因として，変更があった要件に関する作業は，対象となる要件に関して事 前にいくらかの知識があるため，比較的問題なく作業が進み，生産性も高くなった と考えられる．一方で，追加された要件に関する作業は，新たに追加された機能に 関するものであるため，その機能に関する事前知識が無く，変更があった要件に関 する作業に比べて作業が滞り，結果として生産性が低くなったと考えられる． 以上より，要件が追加されたものか修正されたものかによって，その作業の生産 性に違いがあることが確認できた．これにより，次回反復時の見積もりに参考とな る情報を得ることができると考えられる． 4.5.2. 提案手法の適用可能性 提案手法を用いることで，(A) 時間観点からの分析ではコストが投入された時期 が把握でき，(B) 工程観点からの分析ではコスト投入時の工数を把握できる．また (C) 修正のために費やされた工数では要件変更と要件追加を把握する．さらに (D) 生産性の観点からの分析では要件の追加と要件の修正における生産性の比較を行っ た．生産性の観点からの分析では，今回はソースコードの変更量を用いて生産性を 計測している．実際には全ての工程を考慮した上で生産性を計測する必要がある． 他の工程の生産性を計測する方法としては，設計書の変更ページ数やテストケース *10 ただし，利用データはあくまで仮想プロジェクトのものであり，実際のデータでも同一の結論が導 かれるとは限らない．本稿はあくまで想定される考察の道筋を示したものである． 25 数の増減などによって計測できる． 上記 (A) から (D) の観点の情報を用いることで，発注者は要件とコストに着目 した分析を行う事が可能となる．これにより，今回示したユースケースの他に，ソ フトウェア開発知識が無い顧客でも発注先の判断を行うための支援が可能となる． 提案手法を用いて開発プロジェクトの分析を行うことで，発注者は，下記に示す発 注先（ベンダー）を決めるための判断材料として，(1) プロジェクト管理能力の把 握，(2) 見積もりの明確さ，(3) 開発力の把握，という 3 つの判断材料を得ることが できる． 管理能力の把握は，的確なプロジェクト管理を行わなければ提案手法を用いた情 報提示が難しいためである．つまり，プロジェクト管理を怠ったメーカは本提案の ような情報提示ができないためである． 見積もりの明確さは，過去のプロジェクトで類似システム（類似機能）を開発し たことがあるベンダはコストも明確に提示可能である．そのため，発注者に対して 抽象的な工数見積もりではなく，明確な工数を提示することが可能である． メーカの開発力の把握は，時期と工数が明確になるため，例えば開発に大量の工 数を投入している場合，開発力の無いメーカと判断できる．ただし，単純に工数が 多いだけでは判断するのは安易な判断材料となってしまう．そこで，要件追加・修 正状況の把握である．開発工数が多く，かつ追加作業・修正作業が多いプロジェク トは要件定義や設計工程等の何らかの問題があった可能性があると考えられる． このように，ベンダーが時系列にコストを提示することで，ベンダーの信頼度を 発注者に伝えることができる他に，開発力やコストの妥当性，また実績等を伝える 事が可能となる． 本章で示した分析例は，作業記録をもとに，要件の分類や可視化などをすべて手 *11 この中で，時系列・工程別の工数データ集計や， 動で行ったことを想定している． 要件の分類など情報提示に必要な作業は，手動で行うには非常にコストがかかり， また煩雑な作業である．提案手法が発注者の利用を想定していることを踏まえる と，このような分析作業に関わる作業コストはできるだけ低く抑える必要がある． よって，このような一連の分析作業を支援する環境を用意することが望ましい． *11 実際に本章で示した作業は，著者自身が要件の分類を行い，表計算ソフトウェアを利用して情報の 可視化を行った． 26 具体的には，要件ごと・工程ごとに時系列に開発コストが記録されたデータを入力 として， （A）から（D）の情報を自動的に提示（描画）するソフトウェア（ツール） が求められる．このようなツールを利用することで，発注者の分析に関わるコスト を低減し，要件とコストに着目した分析を体系的に支援することが可能になると考 えられる． 27 5. 分析支援環境 ReQuost の設計 以下 5.1 では，分析支援環境 ReQuost の概要を述べたのち，5.2 でツールが提供 する機能について述べる．5.3 では，ツールの利用シナリオについて述べる． 5.1. 概要 本研究では，要件項目や開発コストデータの集計提示と分析過程が全て手動で 行ったものである．提案手法の対象は発注者であるため，これらの労力をなくし， 発注者による分析作業の負担を軽くしなければならない．したがって，本手法で提 案している情報提示に沿ってコストデータを総合的に集計する分析支援環境ツール の必要性が高いと考える．以下の図 20 に ReQuost の概念図を示す． 図 20 分析支援環境 ReQuost の概念図 本論文で示した分析例で，分析以外に労力を要した作業は次の通りである．記録 データの整理作業，要件ごとのコストを開発期間時系列上に集計する作業，要件ご との工程別コストを分類提示する作業，要件の変更・追加に伴う修正や追加作業の 増加コストを分類提示する作業，増加コストに関わる修正や追加作業の生産性を算 出し提示する作業．記録データの整理作業を省き，それ以外の情報提示・データ集 28 計の作業を自動化すれば，発注者をコストデータの分析のみに専念させることがで きる．開発者に記録データを用意してもらい，そのデータを発注者がツールに読み 込ませ，各提示情報を表示させる．ReQuost は分析者に対して，(1) 要件の変更・ 追加が行われた時期，(2) 各要件の工程ごとに費やされたコスト，(3) 増加コスト及 びその要件・工程別の内訳，(4) 要件の変更・追加に伴った作業の生産性の理解を 促進する機能を備える． このようなツールを開発し，発注者向けの分析支援環境を提供することで，発注 者の作業負担が大幅に軽減され，分析が容易になると考える．それは，データの記 録と準備の作業が開発者側で行われ，発注者はその用意されたデータをツールで開 いて，表示された集計データを分析するのみになるからである． 5.2. 提供する機能 ReQuost は Visual Basic で実装され，入力として CSV 形式で記述された要件 項目別コストデータを読み込んで機能する．ReQuost のプロトタイプとして現在 開発中の試作物画面スクリーンショットを図 21∼図 24 に示す．以下 (1) ∼ (4) で は，ツールの機能について説明する． (1) 時系列ビュー機能 読込データに含まれる要件ごとの開発作業日別コストを用いて，横軸に開発 期間時系列・縦軸に各要件項目を縦並び続けて配置し，コストの値を該当す る日付の列に表示する時系列ビューを実装する．行ごとの合計をビューの最 終列に集計し，要件別の工数合計を表示する．また，変更があった要件と新 しく追加された要件の要件名の左列にチェックマークを表示し，要件の変更 や追加に伴って発生したコストを色分けて表示する．この機能により，どの 要件にいつどれくらいコストがかかったかを分析者が俯瞰することが容易に なる．また，要件の変更・追加が行われた時期を把握することが可能になる． (2) 工程ビュー機能 要件項目ごとのコストから，横軸に工程・縦軸に各要件項目を配置し，要件 29 ごとの工程別コストを表示する工程ビューを実装する．また，行ごとの合計 値を最終行に，列ごとの合計値を最終列にそれぞれ集計する．この機能によ り，どの要件がどの工程にどれくらいコストがかかったかを分析者が俯瞰す ることが容易になる．また，開発コストの要件別内訳（ビューの最終列）と 工程別内訳（ビューの最終行）を把握することが容易になる． (3) 増加コストビュー機能 時系列ビューで色分けした，要件の変更・追加に伴ったコストを，それぞれ の当てはまる要件と工程ごとに表示する増加コストビューを実装する．ま た，行ごとの合計値を最終行に，列ごとの合計値を最終列にそれぞれ集計す る．この機能により，要件の変更・追加がどの工程にどれくらい増加コスト を発生させたかを俯瞰することが容易となる．また，増加コストの要件別内 訳（ビューの最終列）と工程別内訳（ビューの最終行）を把握することがで きる． (4) 生産性ビュー機能 データからは変更または追加された要件ごとの作業変更量*12 の増加コスト （増加コストビューで集計した）を表示する生産性ビューを実装する．ビュー の最終列に，それらの値を割り算して算出される増加作業時間当たりの変更 量を集計する．この機能により，各変更要件あるいは追加要件に伴った修正 や追加作業（以降は合わせて「増加作業」と呼ぶ． ）の生産性を分析者が把握 し，それぞれの機能内容・変更内容と結び付けて分析することが可能となる． 以下の図 21∼図 24 には，現在開発中の分析支援環境 ReQuost プロタイプ版の 画面スクリーンショットを示す． *12 第 4 章で示した分析例では，コーディング作業のみの変更量（追加行数＋削除行数）を扱いました． 詳しくは，4.5.2 を参照． 30 図 21 分析支援環境 ReQuost： 時系列ビュー 図 22 分析支援環境 ReQuost： 工程ビュー 31 図 23 分析支援環境 ReQuost： 増加コストビュー 図 24 分析支援環境 ReQuost： 生産性ビュー 32 5.3. 分析シナリオ 分析支援環境 ReQuost を用いた要件コスト分析作業のシナリオを以下に示す． 分析者（発注者）は，ツールを立ち上げ，要件と作業種ごとに細かく記録したコス トデータをオープンし，システムを実行する． 表示される 4 つのタブの１番目の時系列ビューでは，要件項目ごとの開発作業日 別コストを集計した開発期間時系列を分析し，いつどの要件にどれくらいコストが かかったかを把握する．また，要件の変更・追加が行われた時期を把握する． 2 番目の工程ビューでは，要件項目ごとの工程別コストを分析し，どの要件がど の工程にどれくらいコストがかかったかを把握する．また，開発コストの要件・工 程別の内訳を把握する． 3 番目の増加コストビューでは，要件の変更・追加によって発生した修正や追加 作業を分析し，ぞれらに伴った増加コストを当てはまる要件と工程別に把握する． また，増加コストの要件と工程別の内訳を把握する． 4 番目の生産性ビューでは，要件ごとの増加コストとそれらに関わる作業変更量 を分析し，各変更要件あるいは追加要件に伴った作業の生産性を把握する．また， その増加コストに関わる作業の生産性を，それぞれの当てはまる要件の内容・変更 内容と結び付けて分析し，増加コストについてより詳細に把握する． 5.4. データフォーマット 発注者による分析を支援するためのデータ集計ツール作成るでは，データをどの ようなフォーマットで記録するかが重要である．[変更 or 追加, 要件 ID, 要件名, 変 更内容, 日付 1 ＝工数 1,…日付 n ＝工数 n] のようなフォーマットでデータを用意 し，ツールで読み込ませて情報提示を実装すると考えている．以下に，第 4 章の分 析例で想定したデータのフォーマット例を示す． 変更,R1, 文献登録機能,URL を登録する項目を追加,32.5,20100907 ＝ 3 … ,R2, 文献詳細表示機能,,17,20100907 ＝ 2, … ・・・ 33 6. おわりに 本研究では，発注者観点からのソフトウェア開発プロジェクトの理解・分析を支 援する手法を提案した．提案手法は，ソフトウェア開発時に発生する要件と，その 実装に費やされたコストの関係に着目した．提案手法では，ソフトウェア開発プロ ジェクトで定義した要件について，時系列・工程・増加工数・要件の追加・修正に 伴って発生した作業の生産性の 4 つの観点から各要件とその要件の実装に費やされ たコストの関係を可視化する．提案手法を用いることで発注者は，作業実施状況の 確認や見積もり基礎データの構築を行うことが期待される． 提案手法に関しては，仮想のプロジェクトデータを用い，見積もり基礎データの 構築を目的として，提案手法を用いたプロジェクト分析の例を示した． 提案手法はソフトウェア開発に関する深い知識を持たない発注者であっても， 「要 件」と「コスト」という発注者にとってもイメージしやすい観点からプロジェクト の状況を提示し，発注者による分析うぃ可能とするものである． 以下に，本研究をさらに探求するための，今後の課題を挙げる．． 実プロジェクトへの適用 今回，提案手法はあくまで仮想のプロジェクトデータを用いた検証しか行ってい ない．そのため，実際のプロジェクト分析を行う際に，提案手法を適用し評価を行 う必要がある．評価にあたっては，発注者観点から要件とコストの関係に関する分 析を行うことができたかを評価する必要がある．また，このような実プロジェクト への適用を通じて，提案手法の分析用途や分析結果を知見として蓄積していく必要 があると考える． 分析支援ツールの構築 4.5.2 で示したように，発注者が分析をする際に発生する作業コストを低減するた めには，提案手法の一部を自動的に行う支援ツールの整備を行う必要がある．ツー ルへの整備にあたってはソフトウェアタグ形式 [18] のデータ入出力への対応を行う ことで，他の分析・可視化ツールとの連携やデータ互換と言った工夫が考えられる． 34 謝辞 本研究を進めるにあたり，大変多くの方々にご指導，ご協力，御支援を頂きまし た．巻末ではありますが，ここに感謝の意を添えて御名前を記させて頂きたいと思 います．本当にありがとうございました． 奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学講座 飯田 元 教授におかれましては，本研究の主指導教員として，終始本研究の全般に対するご 指導，ご協力を頂きました他，研究に対する姿勢や発表に関するご指導，また，研 究以外の場においても様々なアドバイスをして頂きました．心より厚く御礼申し上 げます． 奈良先端科学技術大学院大学 情報科学研究科 システム制御・管理講座 西谷 紘一 教授におかれましては，副指導教員として，本研究の発表において根本的かつ新し い視点からの貴重なご意見，ご指摘を頂きました．深く感謝いたします． 奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学講座 松本 健一 教授におかれましては，副指導教員として様々なご助言，ご支援を頂きました他， 研究生活を送る上での心構えや研究のあり方について，多大なるご指導を頂きまし た．心より，厚く御礼申し上げます． 奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア設計学講座 吉田則裕 助教におかれましては，本研究を進める上でのご指導はもちろん，日々の研究生活 においても多大なるご支援，ご協力を頂きました．心より厚く御礼申し上げます． 最後に，日々の研究生活において著者を支えて下さった奈良先端科学技術大学院 大学 情報科学研究科の皆様，特に，ソフトウェア設計学講座，ならびにソフトウェ ア工学講座の皆様には，日頃より多大なご協力と御助言を頂き，公私ともに支えて いただきました．深い感謝の意を述べさせて頂きます．皆様の励まし，尽力，支援 無くして，本研究を続けることはできませんでした．改めて，厚く御礼申し上げま す．本当にありがとうございました． 35 参考文献 [1] 有力企業 357 社 CIO 調査. 日経情報ストラテジー. 2008 年 3 月. [2] Nelly Bencomo, Jon Whittle, Pete Sawyer, Anthony Finkelstein, and Emmanuel Letier. Requirements reflection: Requirements as runtime entities. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2, pp. 199 – 202, May 2010. [3] Barry W. Boehm. Software Engineering Economics. Addison Wesley Professional, October 1981. [4] Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, and Bert Steece. Software Cost Estimation with Cocomo II. Prentice Hall PTR, 1st edition, 2000. [5] CMMI Product Team. Capability maturity model integration for system engineering / software engineering / integrated product and process development, version 1.1. Technical Report CMU/SEI-2002-TR-004, Software Engineering Institute, August 2002. [6] Shinpei Hayashi and Motoshi Saeki. Recording finer-grained software evolution with IDE: An annotation-based approach. In Proceedings of the 4th International Joint ERCIM/IWPSE Symposium on Software Evolution (IWPSE-EVOL 2010), pp. 8 – 12, September 2010. [7] Jacky Wai Keung, Barbara A. Kitchenham, and David Ross Jeffery. Analogy-x: Providing statistical inference to analogy-based software cost estimation. IEEE Transactions on Software Engineering, Vol. 34, pp. 471 – 484, July 2008. [8] Luigi Lavazza and Giuseppe Valett. Requirement-based estimation of change cost. Empirical Software Engineering journal, Vol. 5, pp. 229 – 243, March 2000. [9] Jürgen Münch and Jens Heidrich. Software project control centers: Con- 36 cepts and approaches. Journal of Systems and Software, Vol. 70, No. 1-2, pp. 3 – 19, 2004. [10] Glenford J. Myers. Software Reliability: Principles and Practices. Wiley, September 1976. [11] 中村建助, 矢口竜太郎. 2008 年情報化実態調査 プロジェクトの成功率は 31.1%. 日経コンピュータ, 2008 年 12 月 1 日号, No. 718, pp. 38 – 53. [12] 大平雅雄, 横森励士, 阪井誠, 岩村聡, 小野英治, 新海平, 横川智教. ソフトウェ ア開発プロジェクトのリアルタイム管理を目的とした支援システム. 電子情報 通信学会論文誌 D-I, Vol. J88-D-I, No. 2, pp. 228 – 239. 2005 年 2 月. [13] Kimiharu Ohkura, Keita Goto, Noriko Hanakawa, Shinji Kawaguchi, and Hajimu Iida. Project replayer with e-mail analysis – revealing contexts in software development. In Proceedings of the 13th Asia Pacific Software Engineering Conference (APSEC06), pp. 453 – 460, December 2006. [14] 奥村哲也, 大蔵君治, 伏田享平, 川口真司, 名倉正剛, 飯田元. ソフトウェア タグの適用を支援する開発履歴可視化ツール. 情報処理学会研究報告, 第 2009-SE-166 巻, pp. 1 – 8. 2009 年 10 月. [15] Project Management Institute. プロジェクトマネジメント知識体系ガイド 第 3 版. Project Management Institute, 2005 年. [16] Balasubramaniam Ramesh, Lan Cao, and Richard Baskerville. Quantifying requirements elaboration to improve early software cost estimation. Information Systems Journal, Vol. 20, No. 5, pp. 449 – 480, September 2010. [17] Norbert Seyff, Florian Graf, and Neil Maiden. End-user requirements blogging with irequire. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2, pp. 285 – 288, May 2010. [18] Masateru Tsunoda, Tomoko Matsumura, Hajimu Iida, Kozo Kubo, Shinji Kusumoto, Katsuro Inoue, and Ken ichi Matsumoto. Standardizing the software tag in japan for transparency of development. In M. Ali Babar, M. Vierimaa, and M. Oivo (Eds.), International Conference on Product Focused Software Development and Process Improvement (PROFES 2010), 37 Vol. LNCS, pp. 220 – 233, June 2010. [19] 独立行政法人 情報処理推進機構ソフトウェア・エンジニアリング・センター. 定量的品質予測のススメ IT システム開発における品質予測の実践的アプロー チ. オーム社. 2010 年 10 月. [20] 独立行政法人 情報処理推進機構ソフトウェア・エンジニアリング・センター. IT プロジェクトの「見える化」 上流工程編. 日経 BP, 2007 年. [21] 角田雅照, 大杉直樹, 門田暁人, 松本健一, 佐藤慎一. 協調フィルタリングを用 いたソフトウェア開発工数予測方法. 情報処理学会論文誌, Vol. 46, No. 5, pp. 1155 – 1164. 2005 年 5 月. [22] 門田暁人, 亀井靖高, 上野秀剛, 松本健一. プロセス改善のためのソフトウェア 開発タスク計測システム. ソフトウェア工学の基礎 XV, 日本ソフトウェア科 学会 FOSE2008, pp. 123 – 128. 2008 年 11 月. [23] 経済産業省 情報処理振興課, 社団法人 日本情報システム・ユーザー協会. ソフ トウェアメトリックス調査 2008. 社団法人 日本情報システム・ユーザー協会, 2008 年. [24] 玉田春昭, 松村知子, 森崎修司, 松本健一. プロジェクト遅延リスク検出を目的 とするソフトウェア開発プロセス可視化ツール ProStar. NAIST Information Science Technical Report NAIST-IS-TR2007002, Nara Institute of Science and Technology. 2007 年 2 月. [25] 水野修, 伊登友美, 上原智, 菊野亨. オブジェクト指向プログラム開発における 機能変更に伴う更新作業工数の見積り. ソフトウェアシンポジウム’99 論文集, pp. 79 – 81. 1999 年 6 月. [26] 西川倫道, 鵜久森将隆, 山田慎也, 楠本真二. ソフトウェアタグデータ収集シス テムの試作. ソフトウェア信頼性研究会第 5 回ワークショップ論文集, pp. 57 – 65. 2009 年 3 月. [27] 誉田直美. ソフトウェア品質会計 NEC の高品質ソフトウェア開発を支える品 質保証技術. 日科技連出版社. 2010 年 6 月. [28] 小川明彦, 阪井誠. Redmine によるタスクマネジメント実践技法. 翔泳社. 2010 年 10 月. 38