全2回　ちゃんと理解していますか？「アジャイル開発」を基礎から解説 《連載:第2回》 アジャイル開発の進め方と注意点

前回記事では、アジャイル開発の概要と、実施する前に払拭しておきたい誤解や勘違いについて解説しました。今回は実際にアジャイル開発を進める際のポイントや注意点を紹介します。

アジャイル開発の代表的手法

アジャイル開発の進め方には複数の手法がありますが、代表的なのは「スクラム（Scrum）」と呼ばれるアプローチです。もともと日本人研究者の製品開発技法に関する論文を、アメリカ人がソフトウェア開発に応用して生まれたプロセスと言われています。

スクラムの大きな特徴はチーム一丸となって取り組むところ。というと何やらスポーツみたいですが、スクラムのチームには顧客やユーザーも含まれるのがポイントです。そして要件定義からテストまでを1～最大4週間という短い期間で反復しながらプロジェクトを進めていきます。この一連のプロセスを「スプリント」と呼びます。

スクラムに限らず、アジャイル開発の進め方に厳格な決まりはなく、プロジェクトの規模や開発方針によっても違いがあるため、ここでは経済産業省の『第12回_デジタルサービス実現 応用編③アジャイル開発』を参考に基本となるモデルを紹介します。

■スクラムチームの構成

スクラムは1チーム7～10名程度で組むことが一般的です。チームメンバーはプロダクトオーナー、スクラムマスター、開発チームで構成されます。先述の通り、顧客（ユーザー）も重要なステークホルダーとして位置づけられています。

それぞれの役割は以下の通りです。

・プロダクトオーナー

ROIを含め、プロダクトのビジネス価値を最大化するミッションを担います。そのために顧客（ユーザー）から定期的に要求を抽出し、「プロダクトバックログ」と呼ばれるリストに優先順位を設定し、イテレーション（開発～テストのサイクル）ごとの開発する機能要件に落とし込みます。プロダクトバックログにおいて、メンバーとステークホルダーに合意を得た上で作業の完了条件について定義しておくことも重要な任務です。

・スクラムマスター

ROIを含め、プロダクトのビジネス価値を最大化するミッションを担います。そのために顧客（ユーザー）から定期的に要求を抽出し、「プロダクトバックログ」と呼ばれるリストに優先順位を設定し、イテレーション（開発～テストのサイクル）ごとの開発する機能要件に落とし込みます。プロダクトバックログにおいて、メンバーとステークホルダーに合意を得た上で作業の完了条件について定義しておくことも重要な任務です。

・開発チーム

ROIを含め、プロダクトのビジネス価値を最大化するミッションを担います。そのために顧客（ユーザー）から定期的に要求を抽出し、「プロダクトバックログ」と呼ばれるリストに優先順位を設定し、イテレーション（開発～テストのサイクル）ごとの開発する機能要件に落とし込みます。プロダクトバックログにおいて、メンバーとステークホルダーに合意を得た上で作業の完了条件について定義しておくことも重要な任務です。

■スプリントの流れ

プロダクトバックログからスプリントで扱うタスクを選出後、計画を策定し、それに則って1～4週間でスプリントを進めます。スプリント期間中は日次で進捗確認・共有するためのデイリースクラムを実施。スプリント終了後は成果物のデモンストレーションとユーザーによるレビューをおこないます。そこで得たフィードバックを踏まえて新たなスプリントへ……というのが大まかな一連の流れです。全体像を簡単にまとめると下の図のようになります。

以上がスプリントの（あくまで）基本的な流れになります。上手く進めるためのポイントとしては、チーム内での問題の早期発見と知識の共有、進捗の明確化が挙げられます。そのためには、前回引用した『アジャイルソフトウェア開発宣言』の宣言文にもある〈対話〉を重視することはもちろん、付箋とボードを使ってやるべき作業やステータスを可視化するといった工夫なども大切です。スプリントのより詳しい進め方やスクラムに必要なスキルなどは、独立行政法人 情報処理推進機構（IPA）の『アジャイル開発の進め方』という資料が参考になるでしょう。

アジャイル開発導入前の注意点

前回紹介したように、アジャイル開発はビジネスに多くのメリットをもたらしてくれる開発手法ですが、当然ながら、他の手法と同じく向き不向きな領域があります。

■アジャイル開発に向いている領域れ

要件が固まりにくい、あるいは時代や環境の変化に対応するために頻繁に更新が求められる領域の開発には適しています。具体的には、SoE（System of Engagement）と呼ばれるユーザーとのつながりを重視して設計されるシステム（レコメンデーションエンジンやモバイルアプリケーションなど）や、営業関係のシステムなど。その他、仮説検証用のMVP（Minimum Viable Product：実用最小限の商品）の開発にも最適です。

■アジャイル開発に不向きな領域

要件がまとまりやすい領域や、あらかじめ成果物の詳細が明確になっているケースは、アジャイル開発の強みである柔軟性を生かすことができません。ただし、ウォーターフォール型開発によるシステム開発において、フロントエンドのUI（ユーザインタフェース）など、一部にユーザーフィードバックを得ながら構築したほうが効果的な領域がある場合は、アジャイル開発を組み合わせると効果的です。

また開発対象のプロダクト以外にも、ベンダーや自社の人材スキル、さらに組織構造なども、アジャイル開発を採用するか否かの判断基準となり得ます。例えば、いわゆる大企業型組織と呼ばれるようなガチガチの縦割りの組織では、スクラムのメンバーだけではなく、顧客やユーザー、ビジネスサイドも巻き込んだ一体型かつ自律型のチーム構築が難しいケースが想定されます。これはユーザー企業としてアジャイル開発を活用する際も同様で、ユーザーは要件を確定する以外にも積極的なコミットメントが求められるため、変化より現状維持を重視するような組織では思うように進められない可能性があります。

アジャイル開発のメリットは計り知れないが、必ずしも万能ではない——そういった意味では、前回記事で「ドキュメントは不要」などのアジャイル開発に関するよくある誤解を数点紹介しましたが、「ウォーターフォールはもう古い」「今はアジャイル開発でなければいけない」といった思い込みやメディアによる刷り込みこそ、最も注意すべきポイントなのかもしれません。実施前には、ぜひ入念な検討をおすすめします。