アジャイル開発の要件定義で失敗しないためのやり方4ステップ

はじめてアジャイル開発に取り組むと「要件定義でどこまで決めるべきなのかわからない」「途中で変更になるなら要件定義自体が不要ではないのか」と悩む人もいるだろう。

アジャイル開発の要件定義の仕方がわからず、簡易的なフロー図のみを用意した結果、開発が進むにつれ考慮漏れが多発して混乱を招いてしまったというケースもあるかもしれない。

アジャイル開発の要件定義はウォーターフォール開発の要件定義とは違い、開発途中での変更に柔軟に対応できるように厳密な仕様設計や内容決定はしない。

ただし、開発に携わる人が目的と手順を共有した上で進めていける程度の明確さを持った計画は必要だ。

本記事では、アジャイル開発の要件定義ではどこまで決めておく必要があるか、反対にどこは決めないでおくのか、その基準について解説する。さらにアジャイル開発の要件定義の手順を6ステップに分けて紹介していく。

アジャイル開発の要件定義のやり方に悩んでいる方の参考にしていただけたら幸いである。

1 アジャイル開発で要件定義をするとき知っておくべき4つのこと
アジャイル開発で要件定義を行う上で、知っておくべき4つのことを紹介する。

1-1 ウォーターフォールと具体的に決めることは変わらない

アジャイル開発はウォーターフォールと対比して語られることが多い。しかし、要件定義における成果物は、両者に大きな違いはない。

たとえばウォーターフォールでは次のような構成で「要件定義書」というものが作られることが多い。

アジャイルでは要件定義書こそ存在しないものの、これと同じ内容を決めて文書化してクライアントと認識を合わせる。クライアントを満足させるシステムを開発するためには、どちらの開発手法であっても同じような成果物が求められるということだ。

1-2 要件定義には２種類ある

アジャイル開発における要件定義は大きく２種類ある。一つ目がプロジェクト全体のキックオフであり、全体のプロジェクトの進め方などを決めるものだ。二つ目が個別の機能について定義していくものだ。

一つ目の要件定義においては、作りたいものの全体像をはっきりさせ、作る順番を確定していく。この後で説明するユーザーストーリーの作成などがそれに当たる。

この要件定義で行う具体的なイメージとしては以下の通りだ。例えばタスク管理アプリを作る場合、誰に向けてどのような機能を作るか、またどういった順番で開発していき、いつ何をリリースするかを大まかに決める。

二つ目の要件定義においては、個別の機能を開発するために要件を確定させていく。これは要件を固められる段階になったら都度実施していく。大体２週間に一度は行われている感覚だ。

ここで行う具体的なイメージとしては以下の通りだ。例えば先ほどと同じくタスク管理アプリを作る場合、「タスクのステータス管理機能を追加する」という案件があったとする。その場合に、ステータスは何があって、それぞれのステータスになるとどうなるのか、誰がステータスを変更できるのかといった具体的な仕様を詰めていく。

1-3 一度に全てを要件定義するのではなく、優先度をつけて機能ごとに順番に行う

アジャイルとウォーターフォールでは進め方が異なる。アジャイルではウォーターフォールのように一番最初に全ての要件を定義するのではなく、機能ごとに優先順位をつけて順番に行っていく。

なぜならアジャイルではシステム要件は常に変わっていくという認識があるからだ。そのため、最初に全体の要件を定義するのは作業工数が無駄になる可能性があるから危険なのだ。

実際、システム開発が進んで徐々にユーザが触れるシステムができてきた段階で「やっぱりこうしたほうがよいかも」といった具合に要件を変えたくなる可能性は大いにある。

そのため、何を作るかが明確なものにだけ要件定義の工数を割いていくというのがアジャイルの進め方だ。

2 アジャイル開発の要件定義のやり方

アジャイル開発における要件定義の、実践的なやり方について大きく4つのステップで解説する。

2-1 クライアントにヒアリングを実施

最初のステップはクライアントへのヒアリングである。ここで聞きたいことは大きく以下の２つある。
・プロジェクト全体の制約条件
・開発するシステムを使うユーザのストーリー（次の章で説明する）

「プロジェクト全体の制約条件」はさらに大きく２つに分けられる。

一つ目は、プロジェクトとしていつまでに何を実現していたいかというマイルストーンである。これがわからないと「最低限いつまでにどんな機能が必要か」、「どの機能から作っていくべきか」という優先順位決めができないためだ。

二つ目は、どれくらいの開発人員を投入できるのかだ。これがわからなければ、どれくらい開発に力を割けるのかわからず、一定期間でどれくらいの機能を開発できるかがわからない。

「開発するシステムを使うユーザのストーリー」は以下の観点からこのシステムの特徴を簡潔に記述したものだ。（詳しくは次の章で述べる）
・誰が
・何のために
・なにをするか

2-2 ユーザストーリーを作成

ユーザーストーリーとは、前の章で述べた通り、以下の観点からシステムの特徴を表した複数の簡潔な文章である。
・誰が（ペルソナ）
・何のために（目的）
・なにをしたいか（ニーズ）

例えばプロジェクト管理システムを開発しようとしている場合は以下のようなストーリーが考えられる。
・PMが、プロジェクトに参加する全員のタスクを可視化して、簡単にプロジェクトの進捗状況を把握したい
・PMが、個別タスクに期限を設定して、進捗確認をしやすくしたい
・プロジェクト参加者が、タスクとタスクを関連づけて、タスクの関連付けや依存関係を把握しやすくしたい
・プロジェクト参加者が、個別タスクのステータスを明示して、進捗をわかりやすくしたい
・プロジェクト参加者が、自分のタスクに関係ある情報をまとめて、関係ないタスクの情報を見なくても良い状態にしたい
・PMが、システムの課金と解約をシステム内のページでクレジットカードなどで行い、煩雑な請求書対応や銀行振込などをしないようにしたい

2-3 ユーザーストーリーマッピングを実施

ユーザーストーリーマッピングとは、個別のユーザーストーリーを時系列に並べ、それぞれのストーリーに対応する機能を紐づけたものだ。それぞれのストーリーに対応する機能は複数考えられる可能性があるため最低限必要な機能から並べていく。

これによって、以下の3点が明確になる。
・ユーザ体験のどの段階にどんなストーリーがあるのか
・それぞれのストーリーで必要な機能は何か
・それぞれのストーリーで最低限の機能と高級な機能は何か。

下記のユーザーストーリーマップは、先ほどのプロジェクト管理ツールの例だ。

具体的な作成手順としては以下の通りだ。
1 ユーザーストーリーを時系列で横に並べていく
2 ユーザーストーリーに対応する機能をリストアップする
3 2でリストアップされた機能を必要工数が少ない順に上から下に並べ替える

2-4 機能の優先順位を決定する

ユーザーストーリーマッピングを行った後に実装する機能の優先順位を決めていく。その際に重要なのが以下の観点だ。
・機能の重要性
・その機能の使われ方の明確さ
・必要な開発工数の多さ

たとえば、タスク管理システムにおいてタスクを入れ子構造で登録できることは重要性が高そうだ。

しかしその「使われ方」が明確でなければ、まだ着手すべきではない。一口に入れ子構造といっても、何階層まで入れ子構造を許すか、入れ子になっていなかったもの同士に親子関係を持たせられるように更新を許すべきかなど考えられる使い道は多い。

また、その開発規模が莫大なものであったりする場合は、その機能が本当はどれくらい重要なのかを改めて考える必要がある。例えばタスク管理システムの例で言うと、入れ子構造以外の機能は3ヶ月でできるのに、入れ子構造を作るとしたらもう3ヶ月かかるとする。その場合は最初に入れ子構造の機能を作ってリリースを遅らせるべきなのか、入れ子構造以外を3ヶ月でリリースして後追いで入れ子構造を作るべきなのか検討が必要だ。

こう考えてくると、重要性が多少低い機能でも、使われ方が明確であれば優先順位を上げて開発に着手すべきだ。また、優先度が低くても簡単に作れてしまうようなものは早めに作ってしまうと言う判断もあり得る。システム全体では軽視されがちな小さな機能を起点として、重要性の高い機能の使用が具体的に決まっていくことは、アジャイル開発において少なくない。

機能ごとの優先順位をはっきりさせるためにも、下記のような表を使用することをお勧めする。