アジャイルとは？~代表的な手法についても紹介~

2023.02.10 株式会社システムインテグレータ

アジャイルとは、柔軟な開発やチーム運営によって迅速なデリバリーを行うという価値観のもと行うソフトウェア開発です。本記事ではアジャイルの代表的な手法について解説します。

アジャイルとは

アジャイルの手法の解説の前にアジャイルの特徴について解説します。アジャイルは特定の手法を指すものではなく、後述するようにアジャイルの考え方で行う多くの開発手法があります。多くのアジャイルの手法に共通している特徴は以下です。

・最初のリリースからすべての要件を実現することを目指さない
・小規模な開発サイクルを短期間で何度も繰り返す
・仕様や開発計画の変更にも柔軟に対応する

アジャイルの手法を用いて開発することで開発工数の削減、リリースまでの時間の短縮が期待できます。また、クライアントの要望にも柔軟に応えることができます。

いくつかのアジャイルの手法は1990年代中頃から登場し始めていましたが、アジャイルが広く知られるようになったのは著名なソフトウェア開発者17名の議論の末にまとめられた「アジャイルソフトウェア開発宣言」が2001年に発表されてからです。

その後アジャイルが注目され普及するようになった背景として、2000年代前半ごろからコンピューターやインターネットの爆発的な普及によって、ビジネスにおけるITの重要性がますます高まったこと、ビジネスの変革スピードが速くなったことがあります。そのため、より「ビジネス（ユーザー）と一体になって開発できる」「変化に柔軟に対応できる」手法が求められるようになりました。

ウォーターフォールとの違い

伝統的なシステム開発の考え方であるウォーターフォールは、水が低いところへ流れるように各工程を完全に完了させてから次の工程へと進みます。ウォーターフォールがアジャイルと大きく異なる点は以下です。

・最初の要件定義でシステムの仕様を確定すること
・各工程が明確に区切られており、たとえばプログラミングとテストを並行したりはしないこと
・システムが利用可能になるのはすべての開発工程の完了後であること

そのためウォーターフォールはアジャイルと比べて仕様変更の際の影響が大きくなります。またシステムの完成イメージを実際にみたり操作したりするのが遅くなるため、開発途中でのクライアントとの認識合わせがしにくいです。

アジャイルに向いているのは以下のような特徴を持つプロジェクトです。

・クライアント、ユーザーと密に連携できる
・プロジェクト開始時に要件がすべて固まっていない、あるいはプロジェクト途中で仕様変更が見込まれる

ステークホルダーが多い等ユーザーの希望をタイムリーに聞くことが難しい場合は、ウォーターフォール型を選択して最初にしっかり全員の要望をとりまとめて要件を固め、以降の仕様変更のハードルは高くしたほうがよいでしょう。

また頻繁に改修や追加機能開発が見込まれるプロジェクトは、細かい開発単位で進める、ユーザーからのフィードバックを受けながら開発するといったアジャイルのメリットを活かしやすいです。Webサービスやスマートフォンアプリ、ゲームなどはこの特徴にあてはまるプロジェクトが多いでしょう。

一方で正式リリース後の機能追加などがあまり見込まれない「一度きり」のプロジェクトはウォーターフォールのほうが向いているかもしれません。

さらにウォーターフォールのプロジェクトは初心者のOJTに適しています。各工程が区切られていることでメンバーはその工程に注力することができるためです。また最初に要件を固めることで全タスクとその担当者も事前に明確にすることができ、初心者メンバーの作業をコントロールしやすいこともメリットになります。

アジャイルの手法

代表的なアジャイルの手法をご紹介します。
XP

XPはExtreme Programmingの略で、技術者を中心とした開発手法です。XPでは以下の基本的な5つの価値観に従って選択を行います。

コミュニケーション

メンバー同士、クライアントとのコミュニケーションを密にする

単純さ

設計を極力シンプルなものにする

フィードバック

システム・クライアント・チームからのフィードバックを受けながらシステムを作りこんでいく

勇気

変更を受け入れる勇気を持つ

尊重

互いの意見を尊重する

また、プラクティス（慣習となっている手法）を用いて開発を進めます。チーム全員向けの4つのプラクティス（共同プラクティス）、コーディングやテストを行う開発チーム向けの15のプラクティスがあります。そのなかでも特徴的なプラクティスを簡単にご紹介します。

テスト駆動開発

実装よりも先にテストを書き、テストをパスすることを目標に実装することでシンプルかつ漏れのないコードを作成する

ペアプログラミング

実装する人とチェック・ナビゲートを行う人の2人1組でコーディングする
実装役・チェック役は適宜交代する

継続的インテグレーション

開発者は変更したコードを定期的にメインリポジトリにマージし、そのマージをトリガに自動化されたビルドとテストを実行することでコードの問題点を早期に発見する

スクラム

スクラムはチーム内のコミュニケーションを重視する開発手法です。ネーミングはラグビーのスクラムが元になっています。

スクラムのチームは3人から10人程度の少人数で構成されます。また、開発のかじ取りをするプロダクトオーナーとチームの生産性を落とす問題を検知し解決するスクラムマスターを各1人ずつおきます。開発期間をスプリントと呼ばれる短い単位で区切るのも特徴です。

スクラムでは2種の「バックログ」と呼ばれるリストを用いて情報共有を行います。バックログのうちプロダクト・バックログは必要な作業に優先順位をつけて記述したもので、スプリント・バックログはプロダクト・バックログから今回のスプリントで行うべき作業を抜き出したものです。バックログの作成・優先順位付け・管理はプロダクトオーナーが最終責任を持ちます。

さらに毎日デイリースクラム（朝会）にて各メンバーが現状報告を行い、スプリント・バックログであがっている作業が期間内に達成できるか、そのほかチームに問題が発生していないか確認します。何か問題がある場合は適宜スクラムマスターが解決のために動きます。

かんばん

かんばんはトヨタで開発されたジャストインタイム生産方式（かんばん）を元にした、限られた資源を有効に活用することを重視する開発手法です。

かんばんでもっとも特徴的なのは、仕事やプロジェクトの状態を可視化するツール「カンバンボード」を用いて進捗管理やプロセス改善を行うことです。ホワイトボード等にタスクを書き出した付箋などをその状態、進捗がわかるように貼ります。
また、かんばんでは現在進行中（WIP）のタスク数を制限することで、生産性の向上を目指します。カンバンボード上でWIPのタスクが上限に達した際にはボトルネックになっている作業の特定などを行います。