非エンジニアでもできる要件定義の進め方と伝え方
「開発会社に要件を伝えたいけど、技術用語がわからないから何をどう書けばいいかわからない」——事業責任者やPdMの方からよく聞く悩みです。エンジニアに任せきりにすると仕様が迷走し、かといって自分で細かい仕様書を書こうとすると手が止まる。実はこの悩みは、技術知識がないことが原因ではありません。「機能を並べる前に決めるべきこと」を飛ばしているために起きています。この記事では、技術用語を使わずに要件を固める手順を、具体的な順番で解説します。
「機能一覧」から始めてはいけない
要件定義でつまずく人の多くは、いきなり「欲しい機能」を箇条書きし始めます。ログイン機能、検索機能、通知機能、管理画面……。これは一見早そうに見えて、実は最も遠回りです。
機能一覧が先にあると、開発チームは「なぜその機能が必要か」がわからないまま実装することになります。結果、優先順位がつけられず、見積もりも膨らみ、完成しても「思っていたのと違う」が起きます。
機能より先に決めるべきことは2つだけです。
- 誰の、どんな課題を解決するのか(対象ユーザーと困りごと)
- 何ができたら成功と言えるのか(成功の定義)
この2つが決まっていれば、機能はその手段として後から自然に絞り込まれます。逆にここが曖昧なまま機能を積み上げると、後から「本当にこれ必要だっけ」という手戻りが必ず起きます。
誰の何の課題かを1文で書く
まず、次の形式で1文を作ります。
「〇〇という状況の人が、△△という理由で困っていて、それを□□できるようにしたい」
例えば「経理担当者が、月末に請求書を手作業で突合していて時間がかかっている。これを自動でチェックできるようにしたい」というように書きます。技術用語は一切使いません。この1文が、以降のすべての判断基準になります。機能を追加するかどうか迷ったときは、常にこの1文に立ち返って「この機能はこの課題の解決に効くか」を問います。
複数の課題を1つに詰め込みたくなったら要注意です。優先順位をつけ、最初に解く課題を1つに絞ってください。
成功の定義を数字で決める
「使いやすいアプリを作りたい」だけでは、開発チームは何を目指せばいいかわかりません。成功の定義は、できるだけ数字や具体的な状態で書きます。
- 「月末の突合作業が3時間から30分に減る」
- 「問い合わせ対応の一次回答までの時間が半分になる」
- 「申込みフォームの離脱率が20%下がる」
数字がまだ出せない場合は、「〇〇という状態になっていれば成功」という具体的な光景を書くだけでも構いません。ここが曖昧だと、開発が完了しても「成功したのかどうか誰にも判断できない」という状態に陥ります。
ユーザーストーリーで要件を書く
課題と成功の定義が決まったら、機能ではなく「誰が、何をしたくて、その結果どうなるか」という単位で要件を書きます。これをユーザーストーリーと呼びますが、呼び方を覚える必要はありません。次の型に当てはめるだけです。
「〇〇(利用者)として、△△したい。なぜなら□□だから」
例: 「経理担当者として、請求書と入金データを自動で突き合わせたい。なぜなら手作業だと見落としが起きるから」
この型のいいところは、機能の背景にある理由が自然と言葉になることです。理由がわかれば、開発チームは想定していなかった実現方法(もっと簡単な方法)を提案できます。逆に「この機能をつけてください」とだけ伝えると、要望の裏にある本当の課題を取りこぼします。
全部書き出す必要はありません。主要な利用者(多くても2〜3種類)を洗い出し、それぞれ「一番困っている場面」から1〜2個書いてみれば十分です。
画面イメージは「言葉で説明」しようとしない
画面のイメージを言葉だけで伝えようとすると、驚くほど時間がかかり、しかも伝わりません。技術がわからないなら、次のどれかを使ってください。
- 似ているサービスのスクリーンショットを集める: 「この画面のこの部分のような一覧表示」「このアプリの検索の使い勝手」など、実在するものを指差す方が正確に伝わります。
- 手書き・スライドの簡単な図で十分: きれいなデザインである必要はなく、要素の配置と情報の優先順位がわかれば足ります。
- 既存の紙の帳票や社内Excelをそのまま渡す: 業務がすでに紙やExcelで回っている場合、それ自体が最良の仕様書になることが多くあります。
「うまく説明できない」と感じたら、無理に言語化せず、実物や参考例を複数集めて渡す方が早く正確に伝わります。
優先順位は「これがないと成立しない」で決める
要望が出揃うと、全部同時に欲しくなります。優先順位づけには、次の3段階の質問が有効です。
- これがないと、そもそも成功の定義を達成できないか(必須)
- これがなくても手動・代替手段で回せるか(後回し可能)
- あると便利だが、成功の定義には関係ないか(今回は対象外)
1だけを最初のスコープにします。2は「今は手動で運用する」と明示して次のフェーズに送り、3は今回の会話から外します。事業責任者やPdMが1人で最終判断できる状態にしておくと、やり取りが格段に速くなります。
開発チームに渡す最小限のドキュメント
ここまでの内容を、次の4つにまとめれば十分です。分厚い仕様書は不要です。
- 課題と成功の定義(1文+数字または具体的な状態)
- 利用者ごとのユーザーストーリー(主要な利用者×1〜2個ずつ)
- 画面イメージの参考資料(スクリーンショット・手書き図・既存帳票)
- 優先順位(必須/後回し/対象外の3分類)
このレベルの情報があれば、開発チームは技術的な要件(データの持ち方、画面遷移、細かい仕様)を専門家として補って提案できます。技術的な仕様まで発注者側で決めようとすると、かえって手戻りが増えます。「何を、誰のために、なぜ」を発注者が固め、「どう実現するか」は開発チームに委ねるのが、双方にとって一番速い分担です。
要件の固め方に自信が持てない場合や、社内の要望が割れていて1文にまとめきれない場合は、外部の目を入れて一緒に整理するのも一つの手です。torcheeesでは要件整理・開発診断という形で、この記事で説明した手順を実際のヒアリングを通じて一緒に進めています。
まとめ
- 機能一覧より先に「誰の何の課題か」と「成功の定義」を決める
- ユーザーストーリー(誰が・何をしたくて・なぜ)の型で要件を書けば、技術用語なしでも開発チームに正確に伝わる
- 開発チームに渡すのは課題・ストーリー・画面参考・優先順位の4点で十分。技術的な実現方法までは委ねる
自分たちだけで要件を固めるのが難しいと感じたら、無理に抱え込まず、お問い合わせから一度壁打ちしてみてください。1〜4週間の要件整理・開発診断を通じて、思いつきの機能一覧を「何のために作るか」から組み立て直すお手伝いをしています。