ホーム >  要求工学 >  2007年9月号 >  第35回：アジャイル開発の要求工学 

最近、製造業で発達したリーン生産方式に基づくアジャイル開発手法（Agile Methods）がソフトウェア開発でも注目されている。

今回は、アジャイル開発における要求工学がどういうものなのかについて紹介しよう。

アジャイル開発とは

アジャイル開発では、顧客が開発者との協働プロジェクトを通じて開発者から提供される価値を理解し、満足することに注力することでソフトウェア開発のさまざまな無駄を省くことを目的としている[1]。たとえば無駄なドキュメントやコードを作らないことや、逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がある。

幾つかのアジャイル手法が提案されているが、アジャイル手法に共通する特徴がアジャイル宣言としてまとめられている。代表的なアジャイル宣言の例を表１に示す。

たとえば、アジャイル手法では個人や顧客との対話を尊重することで、開発プロセスに縛られない人間的なソフトウェア開発を目指している。また、リーン生産方式に学ぶ点として無駄な文書やコードを作らないために、顧客が望む機能だけを開発し、それ以外は絶対に作らないことも宣言されている。したがって、将来必要になるかもしれない機能であっても顧客がすぐに望まないのであれば開発しないことになる。

アジャイル開発のプラクティス

要求作成のためのアジャイル手法のプラクティスを表２に示す。アジャイル手法は人間中心の手法なので開発チームと顧客の能力に応じて、顧客参画の度合い、逐次開発期間、要求の文書化、開発要求の試験などを調整する必要がある。

・顧客の参画

継続的な要求変更のフィードバックを通じて顧客が開発チームとの協働作業に参加する。

・逐次開発

顧客価値を生む少数のよく定義された問題に集中するため開発工程を短期間の逐次工程に圧縮する。

・要求の優先順位付け

逐次工程の前に顧客と開発チームが追加要求を識別して、要求の優先順位を見直す。

・頻繁なリリース

逐次工程の最後に開発チームが顧客に開発結果を提供し、顧客がそれを試験してフィードバックを開発チームに提供する。

アジャイル手法では、顧客と開発チームの直接的な対話によって要求を抽出し逐次開発することで、顧客が要求の妥当性を確認する。このとき開発チームと顧客が、第三者を仲介することなく直接対話することにより必要な文書を削減できるだけでなく、不必要な対話が減少するので誤解もなくなる。このような対話では開発者の言葉ではなく、顧客の言葉で要求を抽出することが重要になる。つまり、開発者が顧客の領域知識を直接理解できる必要がある。また、開発者が複雑だと考える要求を顧客がより単純な複数の要求に分割することで、開発者が要求を容易に理解できるようになる。

開発チームの全員が顧客からの要求抽出に参加することで、情報共有のための文書量やコミュニケーションコストを低減することもできる。もし開発者の誰かが顧客との要求抽出の対話に参加していないと、その開発者に顧客の要求を伝えるための文書が必要になる。全員が参加して要求を抽出することができれば、このような文書を作成して理解する必要がなくなる。

アジャイル手法の対話におけるこれらの留意点を表３にまとめる。

開発要求の決定

開発要求の決定プロセスを図１にUMLのアクティビティ図で示す。

まず顧客が要求を提示し、開発者が要求の開発規模を見積もる。このとき、もし要求の開発規模が大きければ要求を分割する。そうでなければ、顧客が要求の優先順位を決める。次に開発者が要求の開発リスクを見積もると、顧客が優先順位と開発リスクを考慮して開発する要求を決める。

アジャイル手法の仮説

アジャイル手法では、要求進化について表４に示すような３つの仮説がある。

［仮説１］要求はプロジェクトの最初の段階では良く分からない

仮説１の根拠は、プロジェクト開発の最初の段階で要求を顧客から前もって抽出するのは難しいことである。

［仮説２］要求は変化する

仮説２の根拠は、顧客が意図を変更したり技術環境や社会経済環境の変化から、時間の経過に従って要求が進化することである。

仮説１と仮説２は、一般的なソフトウェア開発でも言えることであろう。

［仮説３］変更経費は高くない

仮説３の根拠は、各逐次開発期間を短期化することにより、要求変更経費を時間経過とともに一定にできることである。

仮説３は一般には成立しない。通常は要求変更コストは、開発工程が進むに従って増大するからである。仮説３の前提には、逐次開発される要求が互いに独立であって、開発順序が影響しないように、要求間の依存関係がないことがある。このときは、逐次開発された要求が変更されたとしても、変更経費がその逐次開発経費を大幅に超えることはないであろう。

顧客と開発者の役割

顧客の役割

表５に示したように、顧客の役割がアジャイル手法では非常に重要である。むしろ開発者よりも責任が重くなる。この理由は、開発チームに参画する顧客が、すべての意志決定を即時的に実施できることが迅速な開発の絶対条件になっているからだ。したがって、顧客がこのような役割を果たすことができなければ、アジャイル開発は間違いなく失敗する。しかし、このようなすばらしい能力をすべて持つことは難しい。これらのうち、いくつかの能力が欠けることになれば、開発期間の短期化が減速されることになるだろう。それでもアジャイル手法に挑戦する価値はあると思われる。

・参画性

顧客が開発チームに参画することで要求定義文書を削減できる。顧客が開発結果に対する評価をフィードバックすることがアジャイル・プロジェクトの重要な成功要因である。

・可用性

開発チームの質問にいつでも回答できるように顧客が待機している必要がある。開発期間の短い逐次開発では、回答の遅れが開発の遅れに大きな影響を与える。

・知識完全性

顧客はすべての利害関係者の代表であることから、開発者によるすべての質問に回答できる必要がある。たとえば、アプリケーションの振る舞いや入出力データの妥当性にも回答できる必要がある。一人の顧客が回答できる知識の総量には限界があるから、開発規模は限定される。

・意思決定性

開発チームに参画する顧客が、開発された機能についての妥当性や要求変更に関する最終的な意志決定を行う必要がある。

開発者の役割

開発者の役割は表６に示したように、全員参加、顧客関係の維持、開発責任の３つが重要である。

まず顧客からの要求抽出に開発者全員が参加し、開発結果に対するフィードバックを顧客から抽出する必要がある。とくに顧客との信頼関係を構築することが、短期開発を成功させる絶対条件である。また顧客と直接対話し協働活動するために、顧客の言葉で理解し説明するスキルが必要である。

開発者は、ソフトウェア開発の全工程を実施する責任がある。とくに顧客価値を生まない機能を開発しないことがアジャイル手法では重要になる。

アジャイル手法と従来手法

表７にアジャイル手法と従来手法を比較した結果を示す。

規模・スコープ・価格

IEEE830に示されるような要求定義手法は、明確に要求仕様書を作成するので、大規模開発であれば多数の開発者や利害関係者間で、情報共有するための文書化の効果が大きいと考えられる。この場合、開発のスコープが予め要求仕様書によって定義されるので経費も固定できる。

これに対してアジャイル手法では、顧客と開発チームが一緒に活動することで文書化の無駄を省くことができる。一方、顧客要求が必要に応じて逐次的に抽出されるので、要求の全体像は開発がすべて終わらないと分からないから、開発のスコープも価格も変動するのである。もちろん顧客にとって価値のある機能しか開発しないので、変更されることはあるかもしれないが、アジャイル手法では使われない機能は基本的に存在しない。したがって、価格は変動するが無駄な経費がかかることはないというわけである。

要求定義

従来手法では、多数の利害関係者から要求を抽出・文書化して合意形成により要求を定義する。

アジャイル手法では、特定の顧客を開発チームに参画させ、逐次開発に基づく要求変更により要求を段階的に定義する。

要求の特性

従来手法では、将来の要求変化を予測し一般性のある機能や構成を抽出するだけでなく、性能やセキュリティなどの非機能要求も仕様書で明確化する。

アジャイル手法では、顧客が個別的に価値を認めた逐次開発できる範囲の機能要求だけを抽出し、必要最小限の範囲で文書化する。

また、性能などの非機能要求は開発結果を直接確認できるので、文書化する必要がない。

再利用

従来手法では、将来の機能追加を容易化するためのアーキテクチャや部品を考慮する。

アジャイル手法では、今必要な機能だけを開発するので、将来必要となるかもしれない機能のためのアーキテクチャや部品は無駄であると考える。

アジャイル手法の課題

アジャイル手法には、表８に示すように規模の制約、個人管理、適用領域の制約という３つの課題がある。

規模の制約

開発チームの人数が少ないほど、直接対話でき文書量も削減できる。逆に開発チームが大きくなると、情報共有のための文書量と間接的な対話が発生するので、アジャイル手法による大規模システム開発は困難である。もちろん、中規模開発のためにアジャイル手法を拡張する研究も進められているようであるが、その場合には人間的なコミュニケーションの効率化をどう図るかという、新たなプラクティスやそのためのツールの開発が求められるだろう。

個人の育成

個人による問題解決能力とチームによる情報共有を尊重するので、自律的で協調性のある個人を育成してこれらのスキルを身につけさせる必要がある。優秀な開発者であっても、顧客とのコミュニケーション能力がなければアジャイル開発チームのメンバにはなれない。したがって、優秀なアジャイル開発チームを養成することは難しいのである。

適用領域の制約

一般的には、アジャイル手法の適用領域は、基幹系以外の小規模なアプリケーションに限定される。安全性が要求される分野や、大規模で複雑なシステムの開発は多数の専門家の参加が必要になるので、少人数によるアジャイル手法の適用は困難であると考えられている。適用領域の拡大に向けたアジャイル手法の発展を期待したい。

まとめ

今回は、アジャイル開発とその要求工学との関係について文献[1]に基づいて考察した。今後もアジャイル開発のための要求工学の研究が進むことを期待したい。

---

■参考文献

• [1]Alberto Sillitti and Giancarlo Succi, Requirements Engineering for Agile Methods,
  Engineering and Managing Software Requirements, Springer, 2005.