昨今、クラウド化やDXに取り組む企業が増えています。しかし、急速に変化する市場状況に対応するには、単にシステムを変えるだけではなく、開発環境や組織体制そのものを変えることを求められる場合があります。そこで現在注目されているのが、「アジャイル開発」という手法です。本記事ではアジャイル開発の概要や手法、進め方を解説します。
アジャイル開発とは？
アジャイル開発とは、短期間で開発・リリース・フィードバックのプロセスを繰り返しながらアプリケーションを構築していく開発手法です。
アジャイル開発では、およそ2週間程度を1サイクルとする「スプリント」と呼ばれるフェーズ を設定し、こまめにクライアントとコミュニケーションを取りながら、重要性ないしは緊急性の高い機能から順に開発・リリースします。そしてその後、開発者とクライアントの間でエンドユーザーからのフィードバックも加味した検証を行い、その後の開発に柔軟に活かしていくのです。
これにより、アジャイル開発ではクライアントのニーズに迅速かつ柔軟に応え、顧客満足度やROIの高い開発ができます。日本語で「迅速さ」を意味するアジャイル(agile)という名前が付けられているのも、開発期間の短さや顧客の要望に対する鋭敏な反応を端的に表したものと言えるでしょう。
ウォーターフォール開発との違い
アジャイル開発の特徴を際立たせるためには、ウォーターフォール開発との比較が役立ちます。アジャイル開発が機能ごとに開発とリリースを小さく繰り返す漸進的なアプローチをとるのに対して、ウォーターフォール開発の場合は、最初に入念な要件定義を済ませたら各工程を一本化して開発を行います。
小説に置き換えるならば、アジャイル開発は連作短編集、ウォーターフォール開発は一篇の長編小説に例えられるでしょう。短編ごとに作品を発表することも可能な連作短編集に比べ、長編小説は構想から発表までに数年間要することも珍しくありません。それと同様に、ウォーターフォール開発もシステム全体が完成してからリリースするので、アジャイル開発と比べてリリースするまでの開発期間は必然的に長くなります。
また、ウォーターフォール開発は、最初の要件定義の時点で全体最適化された設計を描いて開発に当たる分、システム全体の整合性は確保しやすくなりますが、仕様変更やトラブルへの対処が難しいという弱点を抱えています。たとえば、アジャイル開発の場合、追加した機能が不具合を起こしたら、基本的にその追加機能部分を抽出して修正するだけで対処可能です。しかしウォーターフォール開発の場合は、各機能が相互依存的に構成されているため、システム全体の見直しをしなければなりません。
こうした特性から、顧客ニーズを主導にした柔軟性の高い体制を取るアジャイル開発と比較して、ウォーターフォール開発はプロジェクト主導型であるため硬直的だと評価されます。
アジャイル開発の主な手法
アジャイル開発を具体的に実践する手法は複数に分けられます。以下では、その中でも代表的な手法である「スクラム」「XP」「FDD」を紹介します。
スクラム
スクラムは、アジャイル開発において最も使われている代表的な手法です。スクラムチームは大まかに分けると、「プロダクトオーナー」「スクラムマスター」「開発チーム」の3要素で構成されます。プロダクトオーナーは製品の品質についての最終的な責任を、スクラムマスターは開発チームがスクラムの方法論に従って円滑に開発を進めることをサポートする責任を負う役割です。スクラムチームはおよそ10人以下の少数で構成されるため、各メンバーの果たす役割と結束の重要性は非常に高くなります。
スクラムにおいては、プロジェクトを細分化し、およそ2～4週間ごとにスプリント（開発期間）を設定して段階的にアプリ等を作っていきます。スプリントの終わりには、その成果をクライアントに提供し、そのフィードバックを得て次のスプリントへと活かすのです。このサイクルは、プロジェクト全体が終了するまで続きます。
エクストリーム・プログラミング（XP）
エクストリーム・プログラミング（XP）は、柔軟性が高いプログラマー中心のアジャイル手法です。XPは、2人から10人程度の少人数のプログラマーチームが、高い技術力を要するプロジェクトに取り組む際に最適です。
XPでは、クライアントと開発者の共同作業やペアプログラミングが重視されており、チームは「コミュニケーション」「シンプル」「フィードバック」「勇気」からなる4つの価値観を共有して仕事に当たります。これは要するに、設計は最小限のシンプルなものに留め、顧客との対話やフィーバックに勇気を持って応えていこうという理念です。XPにおける開発作業は柔軟性や即応性に富んだものになるため、各メンバーのスキルも相応に高いレベルが要求されます。
ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（FDD）は、ユーザーにとっての機能価値を重視して開発を進めていくアジャイル的手法です。FDDは、「全体モデルの作成」「機能リストの作成」「機能別計画の作成」「機能別設計」「機能別構築」の5つの基本活動から構成されています。まずは、クライアントのニーズに合わせてプロジェクト全体のモデルを作成し、そこで必要となる機能リストを作ります。そしてそのリストに記載された機能を構築するために、最後の3つの活動を2週間以内の短い期間で繰り返し実行していくのです。
FDDもクライアントとのやりとりを重視するという点は前掲の2つの方法と同じです。ただし、どちらかと言えばクライアントとの口頭での対話に努めるスクラムやXPに対して、FDDは「機能別リスト」に示されるようにドキュメントでのやりとりも非常に重視します。また、スクラムやXPは基本的に少数チームでの運用が想定されていますが、FDDは大規模なチームでスケーラブルにアジャイル開発を進める場合に適しています。
アジャイル開発のメリット・デメリット
続いては、アジャイル開発が伝統的なウォーターフォール開発と比べて、どのようなメリット・デメリットを持っているのかを解説します。
アジャイル開発のメリット
アジャイル開発の主なメリットとしては、「開発スピードの向上」、「顧客ニーズの反映」「トラブル発生時の対応力」などが挙げられます。
アジャイル開発では、重要度の高い特定の機能から順にアプリケーションを開発・リリースしていく手法です。したがって、アジャイル開発はウォーターフォール開発と比べて、遥かに早くアプリケーションを市場に投入できます。オプション的な機能は、後から徐々に追加していけばいいのです。競合他社に先駆けてシェアを獲得したい場合、この開発スピードは大きな価値を持つと言えるでしょう。
また、アジャイル開発は短期間のスプリントごとに成果物を納品するので、クライアントは実際に動いているアプリケーションを見て修正や変更を検討する機会を多く持つことが可能です。これはアジャイル開発がコンテナやマイクロサービスなどの技術を用いて、柔軟性に富んだスケーラブルな開発体制をとることも関係しています。アジャイル開発ならば、クライアントの指示をリアルタイムに製品に反映していけるのです。
さらに、トラブル対応のしやすさもアジャイル開発の大きな強みです。独立的に開発された機能を順次追加していくアジャイル開発は、機能追加によってアプリケーションに不具合が起きたとしても、問題の特定や切り離しを簡単に行えます。アプリケーション全体の稼働を止めずとも問題に対処できるので、エンドユーザーへの悪影響も最小限に留め、結果としてユーザー体験を高く維持することが可能です。
アジャイル開発のデメリット
上記のように大きなメリットがある反面、アジャイル開発にもデメリットが存在します。
第一のデメリットは、スケジュール管理が難しいことです。仕様変更などの流動的な開発を前提としているアジャイル開発は、そもそもプロジェクト全体としてのスケジュール設定が難しい部分があります。また、各スプリントが非常に短く設定されているので、ちょっとした遅れが計画全体に大きな影響を与えがちです。たとえば、「クライアントに急いで確認してほしいことがあるのに担当者が捕まらない」という事態も十分に考えられることでしょう。スケジュールの遅れはコスト増加にも繋がる大きな問題です。
第二のデメリットは、開発が本来のコンセプトからそれてしまう可能性があることです。アジャイル開発を成功させるにはクライアントの高度な関与が必要ですが、必ずしもそれが可能とは限りません。短い開発期間に追われる中、開発チームとクライアントの合意形成が十分になされないまま開発が進めば、チームは指針を失って迷走する恐れがあります。アジャイル開発を成功させるには、クライアントもアジャイル的手法の特性をしっかり理解し、積極的に協力することが不可欠なのです。
アジャイル開発の基本的な流れ
続いては、アジャイル開発の基本的な進め方を解説します。なお、上記で説明したようにアジャイル開発には複数の種類があるため、開発の進め方も一様ではありません。以下で紹介するのは、アジャイル開発の代表格であるスクラムの例です。また、IPA（情報処理推進機構）は『アジャイル開発の進め方』という資料を公開しているので、そちらを参照することもおすすめします。
参照元：IPA「アジャイル領域へのスキル変革の指針アジャイル開発の進め方」
プロダクトバックログの作成
プロダクトバックログとは、簡単に言うと、製品全体の設計書のことです。プロダクトバックログの作成には当然開発チームも協力しますが、製品にどのような機能が必要か、優先順位が高いかを最終的に決定するのはプロダクトオーナーが担当します。
スプリントバックログの作成
スプリントバックログは、当面のスプリントで開発する機能や、そこで必要とされる実際の作業工程を抽出したリストです。基本的にプロダクトオーナーが決定した優先順位に従ってプロダクトバックログから抜き出されます。
スプリント（開発）の実施
ここからが個別の機能の開発工程です。スプリントバックログに基づいて、メンバーそれぞれが割り振られた作業に従事します。スクラムにおいてはコミュニケーションが非常に重要視されており、各メンバーは自分の作業がどこまで進んでおり、次はどこまで進める予定なのかを毎日報告し合います。また、何か問題があれば当然それも報告が必要です。スクラムにおいてはこのコミュニケーションや協力が非常に重要になります。
スプリントレビューとレトロスペクティブの実施
スプリントが終了したら、関係者間で成果物のデモンストレーション（スプリントレビュー）を実施します。開発チーム以外の関係者にとってこれは製品の状態を確かめる貴重な機会です。レビューが終了したら、今回のスプリントで良かったこと、悪かったこと、次のスプリントに向けた改善点などを話し合う振り返り（レトロスペクティブ）を実施し、製品の品質向上に役立てます。
アジャイル開発から始まるクラウドネイティブの進め方
アジャイル開発は、クラウドコンピューティングの発展と共に影響力を強めてきた側面があります。スケーラビリティの高いクラウドの仕組みは、アジャイル開発と非常にマッチしているのです。クラウド活用を前提とした柔軟かつ迅速なアプリケーション実行環境を「クラウドネイティブ」といい、現在この環境構築に取り組む企業が増えています。クラウドネイティブを推進する企業が持っている課題としては、主に以下のようなものが挙げられます。
(a) 低コスト・短時間でサービスをリリースしたい
(b) リリース時のサービス停止時間を短縮したい
(c) システムの要件・仕様の変更を柔軟にしたい
上記のいずれの課題も、本記事で紹介してきたアジャイル開発のメリットとも対応していることは明らかでしょう。クラウドネイティブの特性を活かすには、単にシステム環境を置き換えるだけでなく、開発手法そのものも従来のウォーターフォール開発からアジャイル開発に切り替えることが重要なのです。したがって、クラウドネイティブの導入はアジャイル開発の導入と並行して、次のようなロードマップで進められることになります。
- アジャイル開発 / クラウドリフト
- コンテナ化
- 自動化
まず、アジャイル開発とクラウド環境への移行により、迅速かつ柔軟なアプリ開発環境を整えられます。次いで、コンテナという軽量の仮想化環境を利用してアプリ開発をすることで、オーバーヘッドを抑制しつつ、無停止でのサービスリリースを実現可能です。さらに、CI/CDなどの自動化技術を活用することで、開発スピードの迅速化を図れます。このように、アジャイル開発とクラウドネイティブ技術は組み合わせて活用することで大きな相乗効果を発揮するのです。
まとめ
アジャイル開発とは、クライアントのニーズを最大限に反映して、迅速なアプリケーション開発を行う手法です。アジャイル開発は伝統的なウォーターフォール開発と比較して仕様変更やトラブル対応にも強く、現在急速に普及が進んでいるクラウド技術とも相性が抜群なことから、非常に注目されています。迅速かつ柔軟なアプリケーション開発を可能にするアジャイル的手法とクラウドネイティブの導入は、DXを促進するための両輪と言えるでしょう。
