アジャイル（Agile）開発は、現代のソフトウェア開発においては無くてはならない概念となりました。今回、アジャイルソフトウェア開発の基本概念とその背景を、改めてまとめまてみました。
アジャイル開発とは？
アジャイル（Agile）開発とは、反復（イテレーション）と呼ばれる短い期間で完了する開発の繰り返しを行う事によって、状況の変化に機敏に適応できるようなソフトウェア開発手法の総称です。
プロジェクトの状況によりますが、反復期間はおよそ１〜４週間程度となり、また、チーム人数もせいぜい１０人程度で構成されることが多いです。大規模なシステムであっても、小さなソフトウェア開発単位に分割して繰り返し開発を進める事で、時間とともに変化する状況の変化に柔軟に対応し、またプロジェクト進行におけるリスクを低減する事ができます。
アジャイル開発が生まれた背景
旧来の開発手法
アジャイル開発の考え方が生まれる以前（〜２０００年以前）は、「ウォーターフォール（滝）型」と呼ばれる開発手法が広く普及していました。ウォーターフォール開発は、１つのソフトウェア開発プロジェクトを幾つかの工程に区切って、順を追って進めて行く開発手法です。
工程は、より細かく分類もできますが、おおよそ下記のようなものです。
- 要件定義
- 設計（仕様定義、および機能設計）
- 実装
- テスト
- リリース
ウォーターフォール開発の問題点
このフローは、各工程の前段階の工程に「間違いがなく」、また「変更されない」という前提においては、最高の開発効率を達成することができました。
ただし、一般的なビジネスにおいて、顧客（クライアント）はシステムの知識や開発の経験が乏しい事が多く、また、開発側もクライアントのビジネスやそのニーズを正しく理解できているケースは稀です。そのような理由から、正確な要件定義を行うには、高度な対話スキルや、両方の分野に精通した翻訳者が必要となり、もともと非常に難しい場合がある事がわかっていました。
実装工程もまた、プロジェクト初期の楽観的な見積もりから作られたスケジュールを達成するため、品質を担保することが難しくなっていきます。品質の低下は、テスト工程の開始の遅れや長期化に繋がってしまいます。
そして、プロジェクトが長期化する間に、顧客のビジネスを取り巻く状況はどんどん変化してしまいます。開発当初の想定とは異なる要件が多く発生してしまう事例も出始めます。例えば、現代の変化の速いインターネットビジネスの世界を見れば、ものの数ヶ月でシステムに必要となる機能が変わりうる事態は想像しやすいでしょう。
このような背景から、ウォーターフォール開発の問題点が指摘され始めていました。
アジャイル開発の誕生
そのような背景から、2001年、ソフトウェア開発に造詣の深い１７人が集まり、「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development) という文書をまとめました。アジャイルソフトウェア開発宣言は、現在も http://agilemanifesto.org で公開されています。
アジャイルソフトウェアの１２の原則
このマニフェストには「１２の原則」が同時に記されています。いずれも、アジャイルソフトウェア開発の基本となる概念について言及しています。
アジャイルソフトウェアの１２の原則
私たちは以下の原則に従う:
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
上記の原則にはから、アジャイル開発における重要なキーワードが見て取れます。
- 顧客満足
- 要求の変更を前提
- 短い期間でのリリースを繰り返す (Incremental development)
- ビジネスサイドとの共同作業
- 対話と信頼（Face-to-face)
- 無駄を省く
- 常に動くソフトウェア
- 継続的開発
これらの概念はやや抽象的ですが、ここから多くの具体的な方法論が派生しました。後述する「スクラム」もその一つで、例えば、バックログ（要求の管理手法）、ふり返り（次のイテレーションでの改善のためのミーティング）、などは、誰しもが一度は聞いたことがある言葉なのではないでしょうか。
アジャイルソフトウェア開発の概念は、現在は米国の 非営利組織である「Agile Alliance」によって推進しています。こちらにも（英語ではありますが）詳しいアジャイルソフトウェア開発や関連する手法の解説が多く掲載されています。
アジャイル（Agile）の語源
「Agile」の定義をケンブリッジ辞書で見てみましょう。
Agile
- Able to move your body quickly and easily
- Able to think quickly and clearly
もともとは、肉体的な動作において、「機敏に」「俊敏に」に動かす能力をもっっている状態を表す形容詞です。ここから転じて、知性においても「機転の利く」「頭の回転が速い」などといったスマートさを指すようになったようです。
上記のアジャイル宣言に見られるように、従来の重厚で非柔軟な開発手法に対して「より素早く」「より適応的に」といった開発における考え方をよく表した言葉だと言えるのではないでしょうか。
実際の日本語での利用においては「アジャイル」という単語単体で開発の方針を指すことも多く「アジャイルな開発」「アジャイルに進める」といった表現もよく聞かれます。
アジャイル開発の実践
上述の通り、「アジャイル」とは、特定のソフトウェア開発プロセスを厳密に定義するものではなく、開発の進め方における指針であり、考え方の一つです。そのアジャイル開発の考え方に基づいて開発プロセスをより詳しく提案したものに「スクラム」や「エクストリームプログラミング」があります。
「スクラム」の概要
「スクラム」は最も一般的なアジャイル開発の実践例で、チームでのアジャイル開発における具体的な方法論を提唱しています。下記に特徴をキーワードでかいつまんで取り上げてみます。詳細はより詳しいサイトや、書籍を参考にして下さい。
スプリント
スクラムでは、およそ５〜９人の開発チームで、最長４週間の「スプリント」と呼ばれる開発を繰り返しながら開発を行います。チームには、開発者の他に「プロダクトオーナー」と「スクラムマスター」など、特定の役割を配置します。
- プロダクトオーナー：それぞれ顧客の要求の管理を行う。
- スクラムマスター：チーム内の問題の折衝や解決を行いながら、スクラムが正しく進める。
バックログ
開発要求の管理には「バックログ」と呼ばれる一覧表を用います。下記の２種類のバックログを用います。
- プロダクトバックログ：プロダクトの最終的な要求の優先順位を管理します。
- スプリントバックログ：そのスプリントで達成する要求を管理します。
スクラムでは、各スプリントの達成を重要視します。スプリントの開始時に、スコープ（対応範囲）を決め、スプリントバックログを作成しますが、ひとたびそのスプリントが始まれば、次のスプリントまでは要求の変更を認めません。
ユーザーストーリー
スプリントで消化すべき要求を定義するスプリントバックログにはできるだけ「ユーザーストーリー」という形で要求を記載します。ユーザストーリでは「INVEST」を意識した単位で記載されるのが理想的とされています。
- Independent: 他の機能に依存せず、独立して機能する
- Negotiable: あとで変更可能な
- Valuable: プロダクト自体の価値に寄与できる
- Estimable: 良し悪しの評価が可能な
- Small: イテレーションに収まる大きさの
- Testable : テスト可能な
スクラムミーティング
スプリントの終わりには、必ず「テスト可能な」状態のソフトウェアをリリースし、スコープとなっていた要求がすべて達成されたことを確認します。これを「スプリントレビュー」といいます。プロジェクトによっては、レビューをパスした機能を、そのまま顧客に受け渡したり、市場にリリースすることもあります。
振り返り
スプリントが終われば「振りかえり」をチーム全員で行い、発生した問題点や、改善点を話し合い、次のスプリントで改善できるようにします。
開発技法
特に開発においては、下記のような方法論をとり入れることが多いです。
- テスト駆動型開発（Test Driven Development）
- 継続的インテグレーション（Continuous Integration）
テスト駆動とは、実装や設計より先に、テストを作成し、そのテストをパスするような実装を行うことです。また、継続的インテグレーションは、ソフトウェアを常にテスト可能な状態にとどめておくことで、リスクを最小に留めることです。
この２つは、自動化したユニットテストと、CIツール（Jenkins）を組み合わせてと呼ばれるツールを利用することが一般的です。
アジャイル開発のメリット・デメリット
アジャイル開発のメリット
アジャイル開発を取り入れるメリットは上述の通り、ウォーターフォールなどの一貫のプロジェクトにおいて発生しやすい、下記の課題を解決できる点です。
- 実際の動くプロダクトを見ながら、最終ゴールに向かって調整できる。
- 要求の変更に対応しやすい
アジャイル開発のデメリット
アジャイル開発も万能というわけではなく、アジャイル開発には特有の問題点もあります。
計画の希薄さが生まれやすい
アジャイル開発では、綿密な計画よりも変更の柔軟性を重視するため、プロダクト自体のコンセプトや価値に関する熟考が軽んじられる傾向が発生します。アジャイル開発はあくまでソフトウェアの開発手法であり、ビジネスやプロダクトの最大の成功方法についてを問うているものではありません。
開発のゴールとは顧客の満足であり、顧客の真の満足とは、多くの場合、プロダクトのビジネス的な成功を意味します（そうでないケースももちろんあります）。何を達成すれば最大の成功を収められるかの問いは、プロジェクトの根底をなす概念であり、これに関する変更や方向修正は、出来る限り避けるべきでしょう。
これはビジネス要件を管理する顧客側や、もしくはプロダクトオーナーが強くコントロールすべきものと言えるでしょう。
プロジェクト全体のを俯瞰しにくい
細かいイテレーションを繰り返し、要求の優先順位や、方針が何度も変更される事で、プロジェクトの最終ゴールがどこにあるのかを認識するのが難しくなります。イテレーションによる繰り返しを行いつつも、最終ゴール「いつ」「何を」達成すればよいのかをプロダクトオーナーは常に意識し、同時にチームメンバーに伝え続ける必要があるでしょう。
メンバーのスキルセットに合わせた、細かな役割の采配と調整が必要
アジャイル開発では、バックログに記載されたユーザストーリをベースに、開発がスタートします。言い換えれば、あいまいな要求から具体的な仕様を定め、設計し、実装して動作をテストするところまでを一人の開発者が担うかもしれません。
多くの開発の現場では、主に「与えられた仕様を実装する」「指示通りに実装する」事が業務の中心となっているケースも少なくありません。そのようなエンジニア個人に突然仕様設計やテスト設計までを行うとすれば、果たしてうまくいくでしょうか。
もしそうであれば、そのような作業者をうまく先導できるような役割が新たに必要になります。それはスクラムマスターかもしれませんし、チーム内の経験あるエンジニアかもしれません。もしくは、仕様設計者をチーム内に配置する必要があるかもしれません。
現場に最適化した役割分担を作ることも、リソースのマネジメントスキルを必要とします。そのような調整を乗り越えて、アジャイル開発を遂行できる前提であれば、アジャイル開発に挑戦する価値はありそうです。
アジャイル開発が不向きな例
上記でアジャイル開発のデメリットとして触れましたが、どうしてもアジャイル開発が向いていないケースというものも存在します。いくつか列挙してみます。
スキル・経験の浅い開発者がいるチーム
アジャイル開発では、個々の開発者の自立性が強く問われます。言い換えれば、一人一人のエンジニアに、機能設計や実装のみならず、自己管理やコミュニケーションなど、すべてのスキルが必要となります。もしチームに自立して設計が行えないメンバーが多い場合、純粋にフラットなチーム体制ではなく、設計、指示、進行管理などの役割を最適に分配する必要があるでしょう。
メンバーのアジャイル開発への理解が浅い
上記と同様に、チームに何人かアジャイルの特徴をよく知っている経験者をチームメンバーに含めるべきでしょう。例えば、誰もアジャイルを経験したことがないメンバーでアジャイル開発を始めるのは、漕ぎ方を知らないメンバーだけで手漕ぎボートに乗り込むのによく似ています。突如として沈むことはありませんが、効率よく前に進むためには、ある程度の練習が必要です。
要件変更が発生しないプロジェクト
あらかじめ作るべき機能が明確で、その要件に変更が発生しないことがわかっていれば、あえてイテレーションを行う必要は低いでしょう。イテレーションは、その都度テストやレビューの工数面のオーバーヘッドを生むため、通期的にみた開発効率は、ウォーターフォールに劣ります。
不具合が許されない深刻なシステムの開発
「速く」「機敏な」を重視するアジャイル開発では、イテレーションごとに１００％の品質保証を達成しようとすることは、非効率となってしまいます。少しの不具合の発生によって、深刻な問題を引き起こし得るシステムには不向きです。そのような場合は、少なくとも、開発工程の最終フェーズに入念なテストフェーズを設置し、システムを安定化させる必要があります。
現場におけるアジャイル開発
優れた道具も、使い方次第
繰り返しになりますが、上述のスクラムにおいても、実際はより細かな開発手法が定義されていますが、現実をみれば状況はプロジェクトによって様々です。
一概に一つのやり方がすべてのチームに当てはまるとは限りません。チーム規模や状況に合わせて、柔軟にやり方を変化させるべきでしょう。大切なのは、状況に合わせた最適化の改善を試みながら、顧客の最高の満足を達成する事がゴールとなります。まさしくそれこそがアジャイルと呼べるはずです。
現場に合わせた採用と工夫を
ノンアジャイルからのアジャイルの変化は、想像以上に大きいものです。一度に切り替えるのではなく、アジャイルの考え方を少しずつ取り入れ、段階的な移行を試してみるのもよいでしょう。
チーム全員で取り組もう
とくにアジャイル開発は、管理者が独断で行ってチームを引っ張るのではなく、個々のチームメンバーの意思が伴って初めて機能します。もしアジャイルな方法を試してみたいときは、チームメーンバーにその事を共有し、一緒に開発プロセスをより良いもにしたいという意思を全員でもって取り組むことが必要でしょう。アジャイル開発をスタートした後も、チームでの対話を通して、改善を繰り返していく事にも、アジャイル開発の本質的な価値があります。
参考リンク
アジャイルソフトウェア開発は今となっては重要でかつ一般的な概念です。多くの書籍や情報が出回っています。
下記は、今回言及した開発手法についてWikiペディアのページです。
こちらの記事は、アジャイル開発について、詳しくまとめられています。
