研究内容要旨:

本論文は,アプリケーション・ソフトウェア開発の最初のプロセスである要求定義の品質とプロジェクトの最終成果の関連がテーマであり,企業で実際に行われた業務アプリケーション・ソフトウェア開発プロジェクトに関連するデータを調査分析した研究をまとめたものである.

筆者は実務を通じて要求定義の重要性と困難さを痛感しており,その重要性を実証し困難さを克服することを研究の課題としている.本論文は,「ソフトウェア開発プロジェクトの問題低減は,最上流プロセスから取り組む必要があるのではないか」という問題意識から出発し,要求定義とITプロジェクトの結果の関連性を調査し,要求定義の品質(Quality)の向上が,プロジェクトのコスト(Cost),納期(Delivery)に影響を与えることを確認しようと試みたものである.

ソフトウェア開発現場にとって,「要求定義が悪ければプロジェクトの結果も悪くなりやすい」,あるいは「要求定義が良ければプロジェクトの結果も良くなる傾向がある」という関連は自明のようであるが,実際にデータを用いて分析した研究例は少ない.このテーマが困難である理由は,大きく2つある.ひとつは技術的な理由ではなく,失敗例も成功例も含めて現実のソフトウェア開発に関するデータが通常公開されていないことにある.それらの実データは企業の機密情報であり,関連データを入手し分析することについての障壁は高い.研究対象としてのデータでさえ入手できないことが,このテーマを困難にしているひとつの理由である.

もうひとつの困難さは,納期やコストといった要素も含めてプロジェクトの最終成果の品質に影響を及ぼす要因の多さと,その影響度合い(比率)が明らかでないことである.ウォーターフォール型の開発工程でプロジェクトを進めて,全工程に対する要求定義の期間や作業工数がわかったとしても,要求定義が最終的な成果にどの程度影響を与えているのかは,誰も明確に回答できない.通常,プロジェクトの過程で問題が発生すると,多くの現場では問題を早期解決することに集中せざるを得ないことが多く,その問題の真の原因まで追及することはワークロードや納期の観点から容易ではない.さらに他のプロジェクト事例と関連づけて問題の構造を明らかにするような取り組みは,極めて実施が困難といえるだろう.品質管理の観点で考えると,工業製品の製造工程に適用されている手法をソフトウェア開発にも適用することが提案されており,実際に適用されている例もある.しかしそれらは製品の品質管理の視点が強く,完成したソフトウェアのバグ率や稼働率が指標であり,真の問題の構造を解き明かして,ソフトウェアの品質に影響を及ぼす要因を見つけるものではない.筆者は,現在のコンピュータ・ソフトウェアの役割を鑑み,作成されたソフトウェアのバグ率も重要であることは間違いないが,ITプロジェクトに強く求められる「品質・コスト・納期(QCD)」に重点をおいて調査分析することで,プロジェクトの最終成果に影響を及ぼす要因やその度合いも明らかにできると考えた.

本論文では,実際にソフトウェア開発現場に携わらない管理者や経営者にもソフトウェア開発のQCD向上と要求定義フェーズの質向上の関係をわかりやすく示すために,開発工程の途中の要因分析は省いて,要求定義の成果とソフトウェア開発プロジェクトの結果の関連に絞り込んだ分析を行うことととした.また,現場にとっても意義のある成果にするため,研究対象データには実企業で行われた要求仕様書を用いることを必須とした.現場の材料を基に学術的視点で問題の本質を探り,再び現場視点で研究の結果得られた知見を示すことが,本論文にとって重要だと考えたからである.しかし実際に要求仕様書をサンプリングしてみると,筆者の予想以上に記述方法もレベルも網羅している項目も多様であり,単純に並べて比較できるものではなかった.そのようなばらつきの多いデータを分析するためには,そのままではなくいったん汎化する必要がある.そのため,データ提供企業の品質管理部門の協力を得て,データの汎化に共同で取り組んだ.ばらつきの多い素のデータをどのように活用したかについては3章に詳しく述べたが,品質管理部が要求仕様書を評価した結果と,要求定義に関するIEEE Std.830・1998(IEEE Recommended Practice for Software Requirements Specifications:以降IEEE Std.と記する)を関連づけることにより,仕様書の形式に拠らない同一基準の評価結果を得られた.その結果,多岐に亘る内容の要求仕様書でも同一基準の下で扱うことが出来るようになった.さらに汎化された評価結果を要求定義の品質の代用特性と捉えて,そこに統計手法を適用することにより,プロジェクトマネジメントの観点で評価されたプロジェクト結果との関連性を可能な限り客観的に示そうとしたものである.この協業を通じて,筆者はデータの分析準備を行うことができ,品質管理部門は日頃感じていた暗黙知を形式知へと展開することができた.このような段階を経て,要求定義の品質とプロジェクト結果との関連性について,統計手法を用いて可能な限り客観的に示したことが本論文の成果である.

以下で本論文の構成と概要を述べる.

第1章では研究の背景と研究の位置づけについて述べた.要求定義に関する種々のサーベイ結果の分析や関連研究を紹介し,本論文の意義について述べた.関連研究ではソフトウェア工学以外に,プロジェクトマネジメント分野についても言及した.

第2章では,要求仕様書品質とソフトウェア品質について,IEEEやISOなどの標準を中心に解説した.本来は,要求仕様書ではなく要求定義自身の品質と,その最終成果であるソフトウェア品質を比較することが望ましいが,ソフトウェア開発全体を通じて顧客が感じる"妥当性"の確認方法が確立されていないために,それでは品質評価として不十分な結果となる.妥当性の確認については各種標準でもV&V(Verification:検証とValidation:妥当性確認)として分割して捉えられている.すなわち,検証とは書かれたこと・仕様にされたことがその通りに実現されているのを示すことにより,比較的容易に評価できるが,妥当性は本来の意図や希望・要望と深く関わる事項であり,「要求定義品質」を考える上で妥当性の証明は大きなテーマである.しかしこの妥当性に関するテーマについては本論文では追求せずに,要求定義の品質を要求仕様書に書くべき事項の達成度合いで測ることとした.これは,多くの実プロジェクトの異なる仕様書を分析する場合でも有効な手法として,また可能な限り客観的に要求定義品質を測定するための手法として,代用特性を用いたものである.

第3章では,実データを用いて要求仕様書品質とプロジェクトの成果の関連を分析し,考察した.主にプロジェクトごとに異なる実際の要求仕様書をIEEEStd.を介在させて汎化し,その評価とプロジェクト結果の関連について分析した.具体的にはプロジェクトの結果を,正常/遅延/コスト超過の3つのカテゴリに分類し,それぞれのカテゴリに対して有意に影響を与えている要求仕様書の品質要因について,平均値比較・分散分析・因子分析を用いて分析した.この分析の結果,より良いプロジェクト結果に導くためには,プロジェクトの目的や概要といった基本的事項が重要な役割を果たしていることがわかった.

第4章では第3章の結果を踏まえ,ケーススタディとして各カテゴリに属する3ケースずつを取り上げて,プロジェクト・レビューの記録を追った.これらのサンプルプロジェクトの中には,必ずしも問題の主原因が要求定義でなかったものも含まれていた.それも含めて,第3章の統計的な分析結果と,実際のプロジェクトがどのような経緯をたどってそれらの結果に至ったのかを,レビューの記録と合わせて読み解くことが第4章の目的である.

第5章ではまとめとして,全体を振り返って以下の結論を提示した.

1.要求仕様書のいくつかの項目はプロジェクト成果に対して影響を及ぼしていることが,統計的手法によって示された.

2.成功したプロジェクトの要求仕様書はIEEE Std.のSRSテンプレートのすべての項目について一定以上の品質で記述されているという特徴があった,

3.成功プロジェクトは特に,IEEE Std.SRSテンプレートの第1章を詳しく記述しており,中でも[1.1目的]と[1.5概要]について,問題があったプロジェクトとの間に有意な差が認められた.

4.コスト超過が発生したプロジェクトは,個々の要求の仕様は詳細に記述されていたが,プロジェクトにおける要求の全体像や要求の優先度について,ほとんど記述されていなかった.

5.遅延プロジェクトについては,要求の発生元や発生理由が把握できていない,あるいは現行システムや社内標準などとの関連付けは明確ではないが,他方,要求の詳細やソフトウェアの仕様について詳しく記述されていた.

これらの分析結果は従来の要求定義研究では踏み込まれていなかった領域であり,最上流工程である要求定義とプロジェクトの成果を結びつける研究のひとつの方向となりうると考えている.なお,本論文はある条件下で収集したデータを,特定の方法で分析し解釈したものであり,データの属人性,品質評価の客観性,分析対象データの設計,データ源の限定などにおいて制約がある.

最後に今後の展望として,本研究の今後の方向性について以下の3案を提示して締めくくりとした.案1:分析対象データを増やして同様の分析を行い,精度を向上させる,案2:他社のデータについても分析を行い汎化(もしくは特化)する,案3:ソフトウェア開発プロセス変更発生時の影響を分析する.

なお,本論文で研究対象としたデータは実際の企業で採取されたものであり,機密保持のためすべてを開示できないことをあらかじめお断りさせていただく.

以上

ソフトウェア・システムの開発プロジェクトでは,何を作るべきかというシステム要求を明確にまた正確に記述する要求分析プロセスが重要だということは,広く認識されている.しかし,多くの開発現場では要求分析に十分な時間をかけず,品質に問題のある要求仕様書をもとに開発が進められがちである,という現実もある.要求分析プロセスが中途半端になる大きな理由の一つは,要求分析に手間をかけて質のよい仕様を作ることが,実際に開発コストの減少やプロジェクト期間の短縮につながる,という実証的な研究結果がこれまでほとんど出されておらず,プロジェクト管理者が納得する証拠が得られていないことにある.

論文提出者は大手のIT企業での実務経験から,要求仕様の品質とプロジェクトの成否の関連を実証的に分析する必要を痛感し,この研究に取り組んだ.分析の対象として,2003年から2005年の間に実施された実際のソフトウェア開発プロジェクト32件を取り上げ,その企業内の開発チームとは独立した品質評価グループが行った要求仕様の評価データを収集した.一方,同じ企業でプロジェクトのコストや開発期間を把握し評価している別のデータを突き合わせて,種々の統計的な分析を行うことにより,要求仕様の品質とプロジェクトの成否の関連を精細に分析した.

この論文では,このような実証分析の結果とその解釈が報告されている.

本論文は5章で構成されている.

第1章では本研究の背景と,これまでの関連研究の流れを述べ,本研究の位置づけを明確にしている.それにより要求仕様の品質とプロジェクトの成否の関連を実証的に分析することの意義が明らかにされている.

第2章では,本研究の主要概念となるソフトウェアの品質,とくに要求仕様の品質について,IEEEやISOの標準と既存研究をサーベイし,この研究の基盤を明示するとともに,第3章以降に展開する研究成果の記述の根拠を示している.

第3章は,本研究の主要な成果である,32の実プロジェクトの要求仕様品質データとプロジェクトにかかったコストと時間のデータとの実証的な分析結果を記述する.その結果,要求仕様書の品質とプロジェクトの成功・不成功には明確な関連があること,要求仕様項目のうち比較的少ない項目が大きな影響を持つこと,正常プロジェクトは一般に要求項目全体をバランスよく記述していること,とくにIEEE標準の要求仕様書構成で第1章に相当するプロジェクトの目的,概要,全体文脈などの記述の品質が,正常プロジェクトでは一般に高く,コストや期間超過のプロジェクトでは一般に低いこと,逆に第1章に相当する部分の記述が弱いのに個別の機能要求記述量が多いプロジェクトは,当初見積もりよりコスト超過が起こりやすいこと,などの重要な知見が得られている.

第4章では第3章の統計的な分析を補足する意味で,32プロジェクトの中から代表的なものをいくつか取り上げ,具体的なプロジェクトの実施状況を個別に分析して,成功や失敗に至ったプロセスを明らかにしている.その内容は,ソフトウェア開発のケーススタディとしても有用であり,単なる統計分析結果とは別の視点からの知見を与える.

最後に第5章で,全体のまとめと今後の課題が述べられている.

このように,本研究はソフトウェア開発プロジェクトに与える要求仕様の品質の評価という実践的なテーマを扱いながら,精緻な分析とケーススタディを行い,研究者にも実務者にもこれまでにない知見を提供したものとして,大きな学術的貢献があると認められる.

よって,本論文は博士(学術)の学位論文として相応しいものであると審査委員会は認め,合格と判定する.