アジャイルの要件定義とは？最初に決めることと後で決めること

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

アジャイル開発に要件定義はある？決め方とタイミングが違うだけ

アジャイルとは、短い期間で作って確かめる、を繰り返しながらシステムを育てていく開発の進め方です。

『アジャイルは要件を決めずに作り始めるやり方でしょ？』というイメージを持つ方も多いはずです。

実は、そこが一番の誤解なんです。

アジャイルでも、誰のために何を作るのか、どこまでを今回の範囲にするのかは最初に決めます。

決めずに作り始めると、作っては壊すを繰り返すだけになってしまいますよね。

アジャイルソフトウェア開発宣言が言っていること

アジャイルの考え方のもとになったのが、2001年に出された「アジャイルソフトウェア開発宣言」です。

そこでは、次の4つの価値が示されています。

ここで大事なのは、右側にも価値はあると書かれている点です。

ドキュメントや計画を捨てるのではなく、左側をより重く見る、という考え方なんです。

だから、アジャイルの要件定義でも文書は作ります。ただ、最初に分厚い文書を完成させることより、動くもので確かめることを優先します。

要件定義そのものの意味から確かめたい方は、要件定義とは？意味をわかりやすく解説もあわせて読んでみてください。

アジャイルでは要件をどこに書く？スクラムの要件定義の考え方

アジャイルの進め方の中でも、よく使われるのがスクラムです。

スクラムでは、スプリントと呼ばれる短い期間を区切りにして、作って確かめるを繰り返します。

スクラムで要件に関わる役割

スクラムで要件定義に関わる役割を、ざっくり並べると次のとおりです。

ウォーターフォールでは発注側と開発側が文書でやり取りする場面が多いですよね。

スクラムでは、プロダクトオーナーと開発者が同じ一覧を見ながら、毎回の話し合いで要件を詰めていきます。

プロダクトバックログとユーザーストーリー

プロダクトバックログは、作りたいことを優先順位の高い順に並べた一覧です。

上のほうの項目ほど細かく決まっていて、下のほうはまだ大まかでもかまいません。

一覧の項目は、ユーザーストーリーの形で書くことが多いです。「〈利用者〉として、〈目的〉のために、〈機能〉がほしい」という形ですね。

ここでは架空の題材として「社内研修の申し込みを、紙の申込書からアプリに置き換える場合」で書いてみます。

『こんなざっくりした一覧で大丈夫なの？』と不安になりますよね。

ここで大事なのは、すぐに作る上のほうの項目だけ、作り始める前に細かく決めておくことです。

ユーザーストーリーを書く時のコツ

ユーザーストーリーは形が決まっているぶん、慣れないうちは「機能の名前」だけを書いてしまいがちです。

目的の部分が抜けると、優先順位を付ける時に「なぜ必要なのか」が分からなくなるんです。

1つのストーリーが大きすぎる時は、1回のスプリントで作れる大きさに分けておきましょう。

「申し込みから受講後の感想まで全部」のような項目は、申し込み、承認、感想のように分けると扱いやすくなります。

ウォーターフォールと比べてみる：最初に決めること、後で決めること

アジャイルの要件定義で一番迷うのが、「どこまでを最初に決めるか」ですよね。

ここでは、ウォーターフォールと並べて、決めるタイミングを仕分けしてみます。

ポイントは、後から変えにくいものほど先に決める、という見方です。

例えば、性能やセキュリティの水準は、後から上げようとすると全体の作りを見直すことになりがちです。

IPAの「非機能要求グレード」の6つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）を最初にざっと見ておくと、抜けを防げます。

研修申込アプリで仕分けると、こうなる

先ほどの研修申込アプリの例で、最初の打ち合わせで決めることを書き出してみます。

反対に、申込画面のボタンの位置や、一覧の並べ方は後回しにして大丈夫です。

最初のスプリントで動くものを見せて、「並びは開催日順がいいですね」と利用部門に決めてもらうほうが早いんです。

ウォーターフォールでの要件の固め方は、ウォーターフォール開発の要件定義で詳しく扱っています。

アジャイルの要件定義の進め方：最初の数回とスプリントごとの詰め方

アジャイル開発の要件定義は、大きく次の流れで進みます。

受け入れ条件で「できた」の基準を決めておく

ユーザーストーリーだけでは、どこまで作れば完成なのかがあいまいですよね。

そこで、作る前に「受け入れ条件」を決めておきます。これを満たせば完成、という確かめ方のことです。

会話にすると、こんなやり取りで詰めていきます。

「定員がいっぱいの研修を選んだ時は、どうなればいいですか？」と開発者が聞きます。

「キャンセル待ちに登録できると助かります。繰り上がりの知らせ方は、まず使ってから決めたいです」とプロダクトオーナーが答えます。

このように、決めることと後に回すことを、その場で言葉にして残しておくのがコツです。

要件を詰める話し合いの場を決めておく

スクラムでは、スプリントの計画を立てる場や、作ったものを見せる場が決まっています。

それとは別に、次のスプリントに向けてプロダクトバックログの項目を詳しくする時間を取っておくと、要件の詰めが追いつかなくなるのを防げます。

途中で目的からずれていないかを見直す

スプリントを重ねると、目の前の要望に応えるうちに、最初の目的から少しずつ離れていくことがあります。

『気づいたら、頼まれた機能をこなすだけになっていた…』というのは、アジャイルの現場でよく聞く悩みです。

要件定義全体の手順をおさらいしたい方は、要件定義の進め方・手順も参考になります。

アジャイルの要件定義書は必要？何をどこまで書くか

『アジャイル開発の要件定義書って、何を書けばいいの？』と迷う方も多いですよね。

会社のルールで要件定義書の提出が決まっていることもあります。

そんな時は、変わりにくいことと変わり続けることを分けて考えると書きやすくなります。

アジャイル開発の要件定義書の目次の例

アジャイル開発の要件定義書は、次のような目次にすると、変わりにくいことだけをまとめやすくなります。

最後の項目に一覧の置き場所を書いておくと、細かい要件はそちらを見ればいい、と読む人に伝わります。

この分け方なら、アジャイルの要件定義書が古くなって誰も読まない、という状態も防げます。

要件定義でほかにどんな成果物を作るのかは、要件定義の成果物一覧で確かめられます。

よくある相談に答えます

テストの段階で機能の漏れが見つかった。要件定義が悪かったの？

ウォーターフォールの現場で、テストに入ってから機能の漏れに気づき、どこに責任があるのか悩むという相談があります。

結論から言うと、まず確かめたいのは、その機能が要件定義書や議事録で合意されていたかどうかです。

合意されていたのに作られていなければ設計か開発の漏れ、合意に入っていなければ要件定義の漏れ、と分けて考えると話が進みます。

アジャイルでは、作ったものを短い期間ごとに見せるので、こうした漏れに早めに気づけるのが強みです。

要件があいまいなまま作り始めるのは、ただの拙速では？

『アジャイルって、要件を決めないで急いで作るだけじゃないの？』という疑問もよく見かけます。

違いは、後に回すことを自分たちで選んでいるかどうかです。

アジャイルでは、目的と範囲の大枠を決めたうえで、作って見せたほうが早く決まることだけを後に回します。何も決めずに作り始めるのとは、出発点がまったく違うんです。

要件定義でもめたくなければ、アジャイルにすればいい？

要件定義で発注側ともめるくらいなら、最初からアジャイルにすればいいのでは、という相談もあります。

ただ、アジャイルでも優先順位の決め方や範囲の大枠で意見が分かれることはあります。

アジャイルにすれば話し合いが減るわけではありません。話し合いの回数が増える代わりに、一回で決める量が小さくなる、と考えるのが近いです。

使ってみないと何が欲しいか分からない案件ならアジャイル、業務のルールがはっきりしている案件ならウォーターフォール、と案件の性質で選んでみてください！

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

ウォーターフォールの要件定義とは？固め方と変更の扱い方

要件定義の成果物一覧と中身｜誰が承認していつ使うかの表つき