アジャイル開発では、要件定義（および要件定義書）やドキュメントは不要といった話をよく耳にします。では、どのように要件定義が行われ、システムや要件（要求）に対する成果物が作られていくのでしょうか。

そこで本記事では、アジャイル開発の要件定義における前提やその方法、実際に行う流れから「作られる成果物」まで詳しく解説します。

そもそもアジャイル開発とは

そもそもアジャイル開発とは、プロジェクトを小さい単位で区切って開発する手法のことです。短期間のサイクルで開発工程を繰り返し（イテレーション）、計画から設計、実装からテストといった順にリリースを繰り返します。

機能単位で開発を進めることで、プロジェクトの大枠を決めてプロジェクトをスタートでき、計画途中の仕様変更にも柔軟に対応できます。

アジャイル開発の主流であるスクラムとは

アジャイル開発の主流となっているスクラム（Scrum）は、チームが一丸となってシステム開発を行うフレームワークのことです。
今回は、このアジャイル開発における要件定義について詳しく解説しますので、概要から知りたい方は以下のページをご覧ください。

【関連記事】【2022年版】アジャイル開発とは？特徴や費用・見積もりの内容までプロが解説

アジャイル開発の要件定義における基本

アジャイル開発の要件定義は、従来型であったウォーターフォールと比べて厳密な仕様設計・内容の決定を実施しない特徴があります。およその仕様や要求を取りまとめ、設計に対して余白を残す形で定義することにより「開発後からでも柔軟に仕様変更へ対応できる」ためです。

変化し続ける市場に対抗するためには、開発途中での仕様変更が必要不可欠となります。また、小さな単位で開発を繰り返すことで完成した機能ごとに顧客へ提供でき、細かくフィードバックを実施・反映できることで価値の最大化を狙うこともできます。

ただし、アジャイル開発には必ずしもこの要件定義が実施されるとは限りません。要件定義はフェーズを指し示すものではなく、要件（要求）の大枠を決めるまでのプロセスとして取り扱われる傾向にあるからです。

また、要件という言葉を使わずに「ユーザーストーリー（顧客の意図や要求の断片など）」という概念によって、ステークホルダーとの合意形成を実施するといったケースもあります。

ここからは、もう少し詳しく要件定義について知るために、前提となる知識を以下にわけて補足します。

• アジャイル開発における要件定義の前提

• ドキュメント・計画不要という認識の誤り

アジャイル開発における要件定義の前提

アジャイル開発の要件定義は、「顧客（クライアント）は要件（要求）を正確に明言化および理解できていない」という前提で成り立っています。

例えば、システムは何かの課題を解決するために作られるのが一般的ですが、実際に開発する際には未知数である項目が多くあります。仮説を前提に作られたものである以上、「解決できるはず」という状態からプロジェクトが進むはずです。

では、この要件（要求）を明確に満たすシステムを作るためにはどうするべきかというと、「実際に作りながら検証する」しか方法が有力な候補となります。アジャイル開発は、この側面をよく理解して作られており、機能を作りながら実際に検証（フィードバックを得る）ことで、求める要件にマッチしたシステムを開発できる手法です。

また、ウォーターフォールにおける仕様変更というデメリット（ネガティブ）な傾向に対し、アジャイルは最初から要件定義を細かく決めておくのは困難であるという前提によって、仕様変更はいわゆるメリット（ポジティブ）に置き換えられます。

こうした要件定義の前提があるからこそ、現代の急速に変化を続ける市場に対し、適切なシステムやプロダクトを作り上げる方法としてアジャイル開発を選ぶといったことがあるわけです。

そして、アジャイル開発における要件定義は、この要件（要求）の大枠を決めることで、どのような機能が必要で・どのように開発するのかを決めて（プロダクトバックログ）、優先順位をつけて落とし込むことで開発を行う形となります。

ドキュメント・計画不要という認識の誤り

アジャイル開発は、しばしば「ドキュメントは不要の開発」「計画を立てない開発」といった誤解を生むことがあります。その背景には、アジャイル開発が普及するきっかけと言われている2001年「アジャイルソフトウェア開発宣言」に記述された以下の文章が挙げられます。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
出典：アジャイルソフトウェア開発宣言

アジャイル開発におけるドキュメントや計画の必要性が低いとする文面により、こうした誤解が生まれたとされています（諸説あります）。しかし、あくまでも価値をどこに置くかであり、アジャイル開発には要件定義およびドキュメントや計画が必要であるケースはあります。

ただし、要件にあわせて複数の機能が求められる一方で、その「求める要件」が変われば「機能の選択肢が異なる」という性質があり、ウォーターフォールのように細かく内容を決めるといった形式をとることはほぼないでしょう。

アジャイル開発の要件定義書とは

そもそも要件定義書とは、開発会社が情報をまとめて、発注者に提出する書類のことです。成果物の完成イメージをすり合わせできるもので、ヒアリングによって合意を得られた内容が盛り込まれます。

アジャイル開発は、仕様変更に強い側面を持った開発手法であるものの、限られた工数で際限なく変更を続けることはできません。あらかじめ作るべき機能であったり、どのようなモデルに仕上げるのかだったりなどを把握しておく必要があります。

そのため、アジャイル開発の要件定義書では「ユーザーストーリー」を基本とし、そこに合わせて以下の例に挙げる内容を書き記します。

• 誰が

• なぜ

• 何をしたいのか　など

ステークホルダーとの合意形成には、この要件定義書を作成する手法が一般的です。

要件定義書となるユーザーストーリーの原則

アジャイル開発における要件定義書となるユーザーストーリーは、以下に挙げた6つの原則にしたがって書くとまとめやすくなります。

• Independent（独立している）

• Negotiable（交渉可能である）

• Valuable（価値がある）

• Estimable（見積もりができる）

• Small（小さい）

• Testable（テストできる）

これらの頭文字をとって「INVEST」と呼ばれ、開発側で発生する事象に影響されにくく、顧客（クライアント）の視点を常に意識して開発を継続するために作られます。

また、要件定義書となるユーザーストーリーは小さく作られることでスケジュールを立てやすく、さらには要件の変更によって必要な機能の変化にも柔軟に対応できるというアジャイルならではといえます。

なお、要件定義書の基本については以下の記事でまとめているので、ぜひ参考にしてください。

【関連記事】システム開発の要件定義書とは？項目や内容をプロがまとめてみた

【一言メモ】
要件定義には、依頼の内容やシステム全体の概要および機能要件に加えて、予算やスケジュールが記載されています。一方で、ユーザーストーリーには「誰が・どのような目的で・何をしたいのか」という機能がかなえるべき経験・体験が短い文章でまとめられています。要件定義ではあるものの、その粒度は大きく異なり、要件が変化するかどうかといった部分にも違いがあるのが特徴です。

ユーザーストーリーの活用と流れ

ユーザーストーリーは、プロジェクトのマネージャーまたはプロダクトオーナー（スクラムの場合）によって作成されるのが基本です。そして、ストーリーの実装が予定されている間はエンジニアに共有され、そのストーリーが完了した時点で顧客へ返還される仕組みとなります。

ユーザーストーリーはそのもので利用するものではなく、ユーザーストーリーマッピングによって全体を視覚化することがあるため、優先順位と時系列の軸で記されることでプロジェクトを俯瞰でき、どのようにリリースするか（リリース計画）が決められるといった流れとなることもあります。

アジャイル開発の要件定義に関連するドキュメントとは

アジャイル開発では、「ドキュメントは不要である」といった認識が広がっている傾向にあります。しかし、実際にはドキュメントを使用することがあり、以下の種類に大別できます。

• 開発者用：設計書等の開発に必要な情報をまとめたドキュメント

• 顧客用：顧客との合意形成に必要な認識をまとめたドキュメント

• 契約書類：顧客との契約に必要な形式的なドキュメント

• 保守運用書類：保守・運用に関する情報をまとめたドキュメント

いずれもある程度まで形式が決まっていますが、開発者用のドキュメントは各社によって異なります。例えば、ソースコードの書き方が決められていたり、メンテナンスを実施しやすいフォーマットであったりするなどが挙げられます。

アジャイル開発の要件定義における流れ

アジャイル開発の要件定義における流れは、以下のとおりです。

1. ユーザーストーリーを作成する

2. ユーザーストーリーマッピングを実施する

3. プロダクトバックログを作成する

まず、顧客（クライアント）が持つ要件（要求）に合わせて、ユーザーストーリーを作成します。この際、本記事で触れた以下の原則（INVEST）にしたがって書くことを意識します。

• Independent（独立している）

• Negotiable（交渉可能である）

• Valuable（価値がある）

• Estimable（見積もりができる）

• Small（小さい）

• Testable（テストできる）

次に、必要に応じてユーザーストーリーから「ユーザーストーリーマッピング」を実施します。ペルソナを設定したり、ユーザーの行動・感情を時系列に並べたりすることで、価値を視覚的に整理し、プロダクトの方向性を明確化するためです。

そこから、プロダクトバックログと呼ばれる「開発チームが目標を達成するために必要なアイテム・タスク」に、優先順位をつけてリスト化したものを作成します。なお、このバックログは顧客（クライアント）が理解できる言葉でまとめるようにし、進捗の共有にも用いられます。

こうした流れでアジャイル開発の要件定義が実施され、開発効率や完成率を高めながら、求められる要件（要求）にあったシステムを開発する形が一般的です。

【補足】アジャイル開発の要件定義で成果物は何になるのか

補足として、アジャイル開発の要件定義で決められない「成果物」は何になるのかに触れておきます。

アジャイル開発の要件定義では、変化する要件（要求）に対応するため、ユーザーストーリーが用いられます。その際、明確な機能のゴールを示すものではないため、『成果物が曖昧』であることが特徴的です。

ただ、アジャイル開発のゴールは「特定のシステムを開発すること」ではなく、「要件（要求）を満たすこと」であることから、成果物を納品するという形式でないケースが意外に多くあります。

あえて、成果物として明確にする場合には、アジャイル開発におけるスプリントによって開発した「動くシステム（いわゆるデモ）」の存在が挙げられます。スプリントにおいて、レビューが行われる際にもこのデモを成果物とし、議論が交わされることになるためです。

こうした背景からアジャイル開発の成果物を考えた際には、「スプリントで作られたデモ」を想定しておくと良いでしょう。なお、スプリントレビューに関しては、以下のページをご覧ください。

【関連記事】スプリントレビューとは｜概要や目的・やり方をわかりやすく解説

TechUnit（テックユニット）は、技術コンサルティングと専属エンジニアチームの構築を行うサービスです。

下記に当てはまる方はお気軽にご相談ください。

• ✔ エンジニアが退職してしまった
• ✔ 開発が進まない
• ✔ すぐにエンジニアを増やしたい
• ✔ 今依頼している開発会社に不満がある

費用が発生しないご相談の段階で、「ソースコード解析」「要件定義」に関与し、プロジェクト毎に最適なチームをご提案しております。

プランに応じて柔軟な開発体制を構築いたします。もちろん、開発状況に応じたメンバーの増減も可能です。

無料相談も承っております。まずはお気軽にお問い合わせください！

お問い合わせはこちら

まとめ

アジャイル開発の要件定義は、ユーザーストーリーを作成することで対応します。ユーザーストーリーはマッピングされたり、プロダクトバックログを作成したりするのに使われ、プロジェクトにおける要件（要求）を満たした成果物を開発する流れです。

また、以下の流れで要件定義が行われるのが基本となります。

1. ユーザーストーリーを作成する

2. ユーザーストーリーマッピングを実施する

3. プロダクトバックログを作成する

要件定義書となるユーザーストーリーは小さく作られることでスケジュールを立てやすく、さらには要件の変更によって必要な機能の変化にも柔軟に対応できるというアジャイルならではといえます。

ぜひ本記事を参考に、アジャイル開発によるシステム開発を検討してみてください。