最近、製造業で発達したリーン生産方式に基づくアジャイル開発手法(Agile Methods)がソフトウェア開発でも注目されている。
今回は、アジャイル開発における要求工学がどういうものなのかについて紹介しよう。
アジャイル開発とは
アジャイル開発では、顧客が開発者との協働プロジェクトを通じて開発者から提供される価値を理解し、満足することに注力することでソフトウェア開発のさまざまな無駄を省くことを目的としている[1]。たとえば無駄なドキュメントやコードを作らないことや、逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がある。
幾つかのアジャイル手法が提案されているが、アジャイル手法に共通する特徴がアジャイル宣言としてまとめられている。代表的なアジャイル宣言の例を表1に示す。
宣言 | 説明 |
---|---|
個人と対話の尊重 | 開発プロセスやツールではなく,顧客や開発者の問題解決能力と直接的な対話を重視する。 |
顧客の尊重 | 厳密で詳細な契約よりも,顧客と開発チームとの協働作業を重視する。固定価格・固定スコープではなく,変動価格・変動スコープで契約する。 |
動くソフトウェアの尊重 | 開発チームのゴールは顧客に価値を提供する動作するコードである。文書化は可能な限り省略する。 |
変更への対応の尊重 | 開発チームは顧客からの変更要求に可能な限り迅速に対応することを重視する。計画活動は顧客ニーズに限定し,それ以外の将来を予測するような活動は無駄を生むので禁止する。 |
たとえば、アジャイル手法では個人や顧客との対話を尊重することで、開発プロセスに縛られない人間的なソフトウェア開発を目指している。また、リーン生産方式に学ぶ点として無駄な文書やコードを作らないために、顧客が望む機能だけを開発し、それ以外は絶対に作らないことも宣言されている。したがって、将来必要になるかもしれない機能であっても顧客がすぐに望まないのであれば開発しないことになる。
アジャイル開発のプラクティス
要求作成のためのアジャイル手法のプラクティスを表2に示す。アジャイル手法は人間中心の手法なので開発チームと顧客の能力に応じて、顧客参画の度合い、逐次開発期間、要求の文書化、開発要求の試験などを調整する必要がある。
プラクティス | 説明 |
---|---|
顧客の参画 | 継続的な要求変更のフィードバックを通じて顧客が開発チームとの共同作業に参加する。 |
逐次開発 | 顧客価値を生む少数の良く定義された問題に集中するため開発工程を短期間の逐次工程に圧縮する。 |
要求の優先順位付け | 逐次工程の前に顧客と開発チームが追加要求を識別して優先順位を見直す。 |
頻繁なリリース | 逐次工程の最後に開発チームが顧客に開発結果を提供し、顧客がそれを試験してフィードバックを開発チームに提供する。 |
・顧客の参画
継続的な要求変更のフィードバックを通じて顧客が開発チームとの協働作業に参加する。
・逐次開発
顧客価値を生む少数のよく定義された問題に集中するため開発工程を短期間の逐次工程に圧縮する。
・要求の優先順位付け
逐次工程の前に顧客と開発チームが追加要求を識別して、要求の優先順位を見直す。
・頻繁なリリース
逐次工程の最後に開発チームが顧客に開発結果を提供し、顧客がそれを試験してフィードバックを開発チームに提供する。
アジャイル手法では、顧客と開発チームの直接的な対話によって要求を抽出し逐次開発することで、顧客が要求の妥当性を確認する。このとき開発チームと顧客が、第三者を仲介することなく直接対話することにより必要な文書を削減できるだけでなく、不必要な対話が減少するので誤解もなくなる。このような対話では開発者の言葉ではなく、顧客の言葉で要求を抽出することが重要になる。つまり、開発者が顧客の領域知識を直接理解できる必要がある。また、開発者が複雑だと考える要求を顧客がより単純な複数の要求に分割することで、開発者が要求を容易に理解できるようになる。
開発チームの全員が顧客からの要求抽出に参加することで、情報共有のための文書量やコミュニケーションコストを低減することもできる。もし開発者の誰かが顧客との要求抽出の対話に参加していないと、その開発者に顧客の要求を伝えるための文書が必要になる。全員が参加して要求を抽出することができれば、このような文書を作成して理解する必要がなくなる。
アジャイル手法の対話におけるこれらの留意点を表3にまとめる。
プラクティス | 説明 |
---|---|
全員参加 | 開発チームの全員が顧客からの要求抽出に参加することで,情報共有のための文書量やコミュニケーションコストを低減する。 |
共通言語 | 顧客の言葉で要求を抽出することで,開発者が顧客の領域知識を直接理解できる必要がある。 |
直接対話 | 開発チームと顧客が第三者を仲介することなく直接対話する。 これにより必要な文書を削減できるだけでなく,不必要な対話が減少するので誤解もなくなる。 |
要求分割 | 開発者が複雑だと考える要求を顧客がより単純な複数の要求に分割することで,開発者が要求を容易に理解できるようになる。 |
開発要求の決定
開発要求の決定プロセスを図1にUMLのアクティビティ図で示す。
図1 開発要求の決定
まず顧客が要求を提示し、開発者が要求の開発規模を見積もる。このとき、もし要求の開発規模が大きければ要求を分割する。そうでなければ、顧客が要求の優先順位を決める。次に開発者が要求の開発リスクを見積もると、顧客が優先順位と開発リスクを考慮して開発する要求を決める。
アジャイル手法の仮説
アジャイル手法では、要求進化について表4に示すような3つの仮説がある。
仮説 | 根拠 |
---|---|
要求はプロジェクトの最初の段階では良く分からない | プロジェクト開発の最初の段階で要求を顧客から前もって抽出するのは難しい |
要求は変化する | 顧客が意図を変更したり,技術環境や社会経済環境の変化から,時間の経過に従って要求が進化する |
変更経費は高くない | 各逐次開発期間を短期化することにより,要求変更経費を時間経過とともに一定にできる |
[仮説1]要求はプロジェクトの最初の段階では良く分からない
仮説1の根拠は、プロジェクト開発の最初の段階で要求を顧客から前もって抽出するのは難しいことである。
[仮説2]要求は変化する
仮説2の根拠は、顧客が意図を変更したり技術環境や社会経済環境の変化から、時間の経過に従って要求が進化することである。
仮説1と仮説2は、一般的なソフトウェア開発でも言えることであろう。
[仮説3]変更経費は高くない
仮説3の根拠は、各逐次開発期間を短期化することにより、要求変更経費を時間経過とともに一定にできることである。
仮説3は一般には成立しない。通常は要求変更コストは、開発工程が進むに従って増大するからである。仮説3の前提には、逐次開発される要求が互いに独立であって、開発順序が影響しないように、要求間の依存関係がないことがある。このときは、逐次開発された要求が変更されたとしても、変更経費がその逐次開発経費を大幅に超えることはないであろう。
顧客と開発者の役割
顧客の役割
表5に示したように、顧客の役割がアジャイル手法では非常に重要である。むしろ開発者よりも責任が重くなる。この理由は、開発チームに参画する顧客が、すべての意志決定を即時的に実施できることが迅速な開発の絶対条件になっているからだ。したがって、顧客がこのような役割を果たすことができなければ、アジャイル開発は間違いなく失敗する。しかし、このようなすばらしい能力をすべて持つことは難しい。これらのうち、いくつかの能力が欠けることになれば、開発期間の短期化が減速されることになるだろう。それでもアジャイル手法に挑戦する価値はあると思われる。
役割 | 説明 |
---|---|
参画性 | 顧客が開発チームに参画することで要求定義文書を削減できる。顧客が開発結果に対する評価をフィードバックすることがアジャイル・プロジェクトの重要な成功要因である。 |
可用性 | 開発チームの質問にいつでも回答できるように顧客が待機している必要がある。開発期間の短い逐次開発では,回答の遅れが開発の遅れに大きな影響を与える。 |
知識完全性 | 顧客はすべての利害関係者の代表であることから,開発者によるすべての質問に回答できる必要がある。たとえばアプリケーションの振る舞いや入出力データの妥当性にも回答できる必要がある。一人の顧客が回答できる知識の総量には限界があるから,開発規模は限定される。 |
意思決定性 | 開発チームに参画する顧客が開発された機能についての妥当性や要求変更に関する最終的な意志決定を行う必要がある。 |
・参画性
顧客が開発チームに参画することで要求定義文書を削減できる。顧客が開発結果に対する評価をフィードバックすることがアジャイル・プロジェクトの重要な成功要因である。
・可用性
開発チームの質問にいつでも回答できるように顧客が待機している必要がある。開発期間の短い逐次開発では、回答の遅れが開発の遅れに大きな影響を与える。
・知識完全性
顧客はすべての利害関係者の代表であることから、開発者によるすべての質問に回答できる必要がある。たとえば、アプリケーションの振る舞いや入出力データの妥当性にも回答できる必要がある。一人の顧客が回答できる知識の総量には限界があるから、開発規模は限定される。
・意思決定性
開発チームに参画する顧客が、開発された機能についての妥当性や要求変更に関する最終的な意志決定を行う必要がある。
開発者の役割
開発者の役割は表6に示したように、全員参加、顧客関係の維持、開発責任の3つが重要である。
役割 | 説明 |
---|---|
全員参加 | 顧客からの要求抽出に開発者全員が参加し,開発結果に対するフィードバックを顧客から抽出する必要がある。 |
顧客関係 | 顧客との信頼関係を構築することが短期開発を成功させる絶対条件である。 顧客と直接対話し協働活動するために,顧客の言葉で理解し説明するスキルが必要である。 |
開発責任 | ソフトウェア開発の全工程を実施するスキルが必要である。 顧客価値を生まない機能を開発しない。 |
まず顧客からの要求抽出に開発者全員が参加し、開発結果に対するフィードバックを顧客から抽出する必要がある。とくに顧客との信頼関係を構築することが、短期開発を成功させる絶対条件である。また顧客と直接対話し協働活動するために、顧客の言葉で理解し説明するスキルが必要である。
開発者は、ソフトウェア開発の全工程を実施する責任がある。とくに顧客価値を生まない機能を開発しないことがアジャイル手法では重要になる。
アジャイル手法と従来手法
表7にアジャイル手法と従来手法を比較した結果を示す。
従来手法 | アジャイル手法 | |
---|---|---|
規模 | 大規模開発 |
小規模開発 |
価格 | 固定 |
変動 |
スコープ | 固定 |
変動 |
要求定義 | 多数の利害関係者から要求を抽出・文書化して合意形成により要求を定義 |
特定の顧客を開発チームに参画させ,逐次開発に基づく要求変更により要求を段階的に定義 |
要求の特性 | 将来の要求変化を予測し一般性のある 機能や構成を抽出する 非機能要求も抽出する |
顧客が個別的に価値を認めた逐次開発できる範囲の機能要求だけを抽出する 非機能要求は実装によって確認できるので文書化しない |
再利用 | 将来の機能追加を容易化するためのアーキテクチャや部品を考慮する |
今必要な機能だけを開発するので将来必要となるかもしれない機能のためのアーキテクチャや部品は無駄であると考える |
規模・スコープ・価格
IEEE830に示されるような要求定義手法は、明確に要求仕様書を作成するので、大規模開発であれば多数の開発者や利害関係者間で、情報共有するための文書化の効果が大きいと考えられる。この場合、開発のスコープが予め要求仕様書によって定義されるので経費も固定できる。
これに対してアジャイル手法では、顧客と開発チームが一緒に活動することで文書化の無駄を省くことができる。一方、顧客要求が必要に応じて逐次的に抽出されるので、要求の全体像は開発がすべて終わらないと分からないから、開発のスコープも価格も変動するのである。もちろん顧客にとって価値のある機能しか開発しないので、変更されることはあるかもしれないが、アジャイル手法では使われない機能は基本的に存在しない。したがって、価格は変動するが無駄な経費がかかることはないというわけである。
要求定義
従来手法では、多数の利害関係者から要求を抽出・文書化して合意形成により要求を定義する。
アジャイル手法では、特定の顧客を開発チームに参画させ、逐次開発に基づく要求変更により要求を段階的に定義する。
要求の特性
従来手法では、将来の要求変化を予測し一般性のある機能や構成を抽出するだけでなく、性能やセキュリティなどの非機能要求も仕様書で明確化する。
アジャイル手法では、顧客が個別的に価値を認めた逐次開発できる範囲の機能要求だけを抽出し、必要最小限の範囲で文書化する。
また、性能などの非機能要求は開発結果を直接確認できるので、文書化する必要がない。
再利用
従来手法では、将来の機能追加を容易化するためのアーキテクチャや部品を考慮する。
アジャイル手法では、今必要な機能だけを開発するので、将来必要となるかもしれない機能のためのアーキテクチャや部品は無駄であると考える。
アジャイル手法の課題
アジャイル手法には、表8に示すように規模の制約、個人管理、適用領域の制約という3つの課題がある。
課題 | 概要 |
---|---|
規模の成約 | 開発チームの人数が少ないほど直接対話でき文書量も削減できる。 逆に開発チームが大きくなると情報共有のための文書量と間接的な対話が発生するので,アジャイル手法による大規模システム開発は困難である。 |
個人の管理 | 個人による問題解決能力とチームによる情報共有を尊重するので,個人のこれらについてのスキルが必要である。 したがって,優秀なアジャイル開発チームを養成することは難しい。 |
適用領域 | 一般的には,アジャイル手法の適用領域は,基幹系以外の小規模なアプリケーションである。 安全性が要求される分野や大規模で複雑なシステムの開発は多数の専門家の参加が必要になるので,少人数によるアジャイル手法の適用は困難であると考えられている。 |
規模の制約
開発チームの人数が少ないほど、直接対話でき文書量も削減できる。逆に開発チームが大きくなると、情報共有のための文書量と間接的な対話が発生するので、アジャイル手法による大規模システム開発は困難である。もちろん、中規模開発のためにアジャイル手法を拡張する研究も進められているようであるが、その場合には人間的なコミュニケーションの効率化をどう図るかという、新たなプラクティスやそのためのツールの開発が求められるだろう。
個人の育成
個人による問題解決能力とチームによる情報共有を尊重するので、自律的で協調性のある個人を育成してこれらのスキルを身につけさせる必要がある。優秀な開発者であっても、顧客とのコミュニケーション能力がなければアジャイル開発チームのメンバにはなれない。したがって、優秀なアジャイル開発チームを養成することは難しいのである。
適用領域の制約
一般的には、アジャイル手法の適用領域は、基幹系以外の小規模なアプリケーションに限定される。安全性が要求される分野や、大規模で複雑なシステムの開発は多数の専門家の参加が必要になるので、少人数によるアジャイル手法の適用は困難であると考えられている。適用領域の拡大に向けたアジャイル手法の発展を期待したい。
まとめ
今回は、アジャイル開発とその要求工学との関係について文献[1]に基づいて考察した。今後もアジャイル開発のための要求工学の研究が進むことを期待したい。
■参考文献
- [1]Alberto Sillitti and Giancarlo Succi, Requirements Engineering for Agile Methods,
Engineering and Managing Software Requirements, Springer, 2005.
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要