アジャイル開発に対する誤解と真実

  アジャイル開発は、当初は数名の1つのチームだけで開発する小規模プロジェクトに適用が限られていた。しかし、グローバル化の進展による市場変化の迅速化に対応して、数十人、百人を超えるような規模のプロジェクトでもアジャイル開発を適用したいというニーズはかなり高くなり、欧米ではアジャイル開発を採用する企業が多くなってきている(1)。
 しかし、日本では必ずしもアジャイル開発を全面的な採用に踏み込んでいないのが現状である。その原因の一つとして考えられるのが、アジャイル開発に対する誤解が考えられる。アジャイル開発を正しく理解することが、アジャイル開発の普及を促進することにつながると思われるので、今回はよく聞くアジャイル開発に対する誤解とその真実について述べてみたい。

誤解1.アジャイル開発は、計画を立てない。
 これは、「計画に従うよりも変化に対応する」というアジャイル開発宣言(2)の「計画に従うよりも」の語句に基因する誤解と思われる。
アジャイル開発の計画では、まず、顧客ニーズを優先順位付けした要求事項をいつまでに完成するかというリリース時期と、リリースまでの期間中の反復回数をリリース計画としてプロダクト・バックログを作成する。次に、リリース計画をベースに、反復を実行する前に、開発チームの作業能力や容量をみて一反復期間に対象となる優先順位の高い要求事項を決め、反復バックログを反復計画として作成する。すなわち、アジャイル開発では、概略計画としてリリース計画を作り、それをもとに詳細計画として反復計画を作成し、反復計画に従って毎日の計画を立て、反復の実行を繰り返して行うのである。アジャイル開発では、3種類の計画-リリース計画、反復計画、毎日の計画-を立てて実行している。

誤解2.要求変更は自由である
 この誤解は、「計画に従うよりも変化に対応する」というアジャイル開発宣言に基因する誤解と思われる。
「変化に対応する」のが、アジャイル開発の重要な基本的な考え方であるが、完全な自由ではない。一反復期間中で実装中の要求機能の変更や開発チームの意に沿わない変更追加はできない。一反復期間中にビジネス価値の高い変更要求が来たら、次の反復計画で優先順位を見直して対応する。その場合、一般的に優先順位の低い要求機能と入れ替えをしたりして無制限な変更に歯止めをかけることができる。

誤解3.アジャイル開発は、ドキュメントがいらない。
  この誤解は、「包括的なドキュメントよりも動くソフトウェア」というアジャイル開発宣言の「包括的なドキュメントよりも」の語句に基因する誤解と思われる。
アジャイル開発では、決められた反復期間の中で要求事項の重要な機能から少しずつ取り出し、設計、開発、テストを行い「動くソフトウェア」を作り出していき、反復の終了ごとに「動くソフトウェア」をレビューして品質状況を把握する。開発に必要なドキュメントはできるだけ簡単にしてドキュメント作成の負荷を減らし、「動くソフトウェア」の開発に注力する。アジャイル開発チームは、開発上のいろいろな問題解決を簡単にすばやく行える「個人との対話」を大切にして、ムダなドキュメントは極力減らすのである。アジャイル開発では、ドキュメントが不要であるといっているのでない。例えば、法律で出すことが義務づけられたドキュメントや「動くソフトウェア」をユーザーが動かすための必要なユーザーマニュアルなどは当然必要である。反復に関係のない不要なドキュメントは極力少なくしようということである。

誤解4.アジャイル開発は、統制が取れない。
 この誤解は、「最良の構想、要求事項、設計は自己組織的チームから出現する」というアジャイル原則(3)の「自己組織的チーム」の語句に基因する誤解と思われる。
アジャイル開発におけるチームは、高い能力とモチベーションを持ったメンバーで構成され、共通の目標を一緒に協力して達成するために、チーム自ら計画作成や意志決定して行動する自己組織的チームである。すなわち、チームは組織から命令されなくても、自らの判断でプロセスを守り、高いモチベーションで行動することができるのである。統制が取れないのではなく外部から統制する必要がないのである。

誤解5.アジャイル開発は、プロジェクト・マネジャーがいらない。
 この誤解は、「最良の構想、要求事項、設計は自己組織的チームから出現する」というアジャイル原則の「自己組織的チーム」の語句に基因する誤解と思われる。
チームが自己組織的チームであれば、目標に向かってチーム自ら判断しながら行動できるので、プロジェクト・マネジャーは必要ないかもしれない。しかし、タックマンのチーム発展段階モデル(4)によると、チーム形成には成立期、動乱期、安定期、遂行期の4つの発展段階があるが、初めの成立期では、メンバーはリーダーに依存することが多く、メンバーの振る舞いはまだよそよそしく、個々に行動する。遂行期になってはじめて、お互いが相互依存関係を保ち、課題を円滑かつ効果的に自律的に対処でき、非常に高いパフォーマンスを上げる自己組織的チームとなるのである。プロジェクト・マネジャーは、開発チームを指示管理するのではなく、チームのやる気を引き出し、開発チーム自らが課題を円滑かつ効果的に対処できるような自己組織的チームになるようリーダーシップを発揮し、目標達成に協力するのである。プロジェクト・マネジャーは、重要な役割を持っている。
                                                                     以上
参考資料
(1) Dr Dobb’s 2008 Agile Adoption Survey
(2) Agile Manifesto: http://www.agilemanifesto.org
(3) 12 Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html
(4) タックマン・チーム発展段階モデル(Wiki),http://en.wikipedia.org/wiki/Forming-storming-norming-performing             


                         HOMEへ