要件定義は「何を作るか」を決めるだけではない
要件定義は難しいです。
最近、新しいプロダクトのコンセプトを要件に落とし込む作業をしていて、あらためてそう感じました。
「こういう価値を届けたい」という話は、最初は抽象的です。
ですが、開発に進むためには、
- 誰が使うのか
- 何をできるようにするのか
- どこまでを今回作るのか
- 何を作らないのか
- 成功をどう判断するのか
まで具体化する必要があります。
要件定義は、単に機能一覧を作る仕事ではありません。
抽象的な目的と、具体的な仕様を行ったり来たりしながら、作るものの輪郭をはっきりさせる仕事だと思っています。
抽象のままだと作れない
たとえば、次のようなコンセプトがあったとします。
チームの情報共有をスムーズにしたい
方向性としては分かります。
ですが、このままでは作れません。
なぜなら、具体的に何を作ればよいかが分からないからです。
- チャットなのか
- ドキュメント管理なのか
- 週報なのか
- 通知なのか
- 検索なのか
どれも「情報共有をスムーズにする」手段になり得ます。
抽象的な目的は必要ですが、そのままだと実装には進めません。
具体だけでも迷子になる
一方で、具体だけを積み上げても迷子になります。
たとえば、
- 投稿機能
- コメント機能
- 通知機能
- 検索機能
- タグ機能
のように機能を並べるだけでは、なぜそれが必要なのかが見えません。
目的に戻らないまま機能を増やすと、作るものは増えるのに、価値がぼやけます。
なので、具体化したあとに、もう一度抽象へ戻る必要があります。
この機能は、何の目的に効いているのか？
今回のコンセプトに本当に必要なのか？
今作るべきなのか、後でもよいのか？
この往復が要件定義の中心だと思います。
具体と抽象を往復する型
自分が要件を整理するときは、次のような順番で考えたいです。
1. 目的を書く
2. 想定ユーザーを書く
3. ユーザーの困りごとを書く
4. 必要な行動を書く
5. 機能に落とす
6. 作らないものを書く
7. 成功条件を書く
たとえば、情報共有ツールならこうです。
目的:
- チーム内で重要な決定が流れないようにする
ユーザー:
- 日々開発しているメンバー
困りごと:
- Slackで決定事項が流れる
- 後から探せない
- 新しく入った人が経緯を追えない
必要な行動:
- 決定事項を残す
- 経緯を追える
- 検索できる
機能:
- 決定事項の投稿
- タグ
- 検索
作らないもの:
- リアルタイムチャット
- 詳細な権限管理
こう書くと、機能が目的とつながります。
考えるために、まず書く。設計が進まないときの思考整理 と同じで、書き出すことで論点が見えやすくなります。
AIを使うなら、抽象と具体を分けて渡す
AIに要件定義を手伝ってもらうときも、抽象と具体を分けたほうがよいです。
いきなり「要件定義して」と頼むと、一般的な機能一覧になりがちです。
自分なら、次のように渡します。
目的:
- チーム内で重要な決定が流れないようにしたい
背景:
- Slack上で決定しているが、後から探しにくい
- 新しく入った人が経緯を追いづらい
相談したいこと:
- 必要な機能を洗い出したい
- 最初のMVPに入れるものと入れないものを分けたい
- 成功条件を決めたい
AIには、機能案だけでなく、抜けている前提や確認事項も出してもらいます。
AIに質問する前に、AIが理解しやすい文章へ直す のように、AIに渡す前の整理が大事になります。
作らないものを決める
要件定義では、作るものだけでなく、作らないものも決めたいです。
作らないものを決めないと、要望がどんどん増えます。
たとえば初期版では、
- 高度な権限管理は作らない
- 通知はメールだけにする
- 外部連携は後回しにする
- 管理画面は最低限にする
のように決めておきます。
これは妥協ではなく、意図を持ったスコープ調整です。
「良いだろう」で書いた実装は、レビューでだいたい指摘される と同じで、判断理由を残しておくと後で説明しやすくなります。
明日からできること
要件定義で詰まったら、まず次の5行を書くだけでも進みます。
目的:
誰のため:
困りごと:
今回作るもの:
今回作らないもの:
これだけでも、抽象と具体を行き来しやすくなります。
まとめ
要件定義は、具体と抽象を往復する仕事です。
抽象のままだと作れません。
具体だけだと迷子になります。
目的に戻りながら、機能へ落とす。
機能を見ながら、目的に戻る。
この往復を丁寧にやることで、作るものの輪郭がはっきりしていくのだと思います。