要件は、量ではなく順番で決まります。目的から書き始めて、機能は最後に書いてください。
このシートの使い方
上から順に埋めてください。途中で「これは決まっていない」と気づいた欄は、空欄のまま「未定」と書き残します。空欄を隠すより、どこが未定かを見せたほうが、相談相手は適切な提案をしやすくなります。1枚に収まらないときは、たいてい範囲が広すぎるか、複数の目的が混ざっています。書ききれない内容は別紙に逃がさず、範囲を分ける判断材料として扱ってください。所要はチームで30分から1時間程度を見込みます。
欄1: このシステムで何を実現したいか
機能ではなく、事業として何が変わるかを1〜2文で書きます。「予約システムを作りたい」は手段であって目的ではありません。「電話とメールで受けている予約を、スタッフの手作業なしに受け付けたい」のように、今の状態と変えたい状態を対にして書くと、後の判断がぶれにくくなります。ここが複数ある場合は、いま最も困っていることを1つだけ残します。
- 今はどうしていて、何が問題になっているか
- この開発が終わったとき、何がどう変わっているか
- その変化を、どんな数字や様子で確かめるか
欄2: 誰が使うか
利用者を役割ごとに書き出します。顧客だけでなく、社内で運用する人、外部の協力先も利用者です。役割ごとに「その人が1日に何回使うか」「どんな場面で使うか」を添えると、画面設計と性能の前提が決まります。役割が5つ以上になるときは、最初のリリースで本当に全員分が必要かを見直してください。使う人が1人もいない役割の機能を作ってしまう事故は、この欄を書かないときに起こります。
欄3: やること(最初のリリースに入れる)
欄1の目的を果たすために、どうしても必要な操作だけを書きます。画面名ではなく「利用者が何をするか」の動詞で書くのがコツです。「管理画面」ではなく「担当者が申し込みの内容を確認して、承認または差し戻しをする」と書くと、範囲の解釈がずれにくくなります。5〜10項目に収まらないときは、次の欄で削る候補を探してください。
- 利用者が行う操作(動詞で、上から使う順に)
- 運営側が行う操作(同じく動詞で)
- システムが自動で行うこと(通知、集計など)
欄4: やらないこと(今回は作らない)
この欄がある資料と無い資料では、見積りの精度が大きく変わります。話題に出たが今回は作らないもの、将来やるかもしれないものを、理由とともに残します。「書いていない=作らない」ではなく「書いてある=意識的に外した」と示すことで、途中の追加要望が起きたときに、判断の経緯に立ち返れます。外した理由まで書いておくと、状況が変わったときに再検討すべきかどうかも判断できます。
- 今回は作らない機能と、その理由(検証に不要・手作業で代替できる・別の目的に属する)
- 将来やりたいが、今回の設計では前提にしないこと
- 他社サービスや既製ツールで代替すると決めたこと
欄5: 制約
制約は、選択肢を狭める代わりに、判断を速くします。期日・予算の枠・使わなければならない既存システム・社内のルールなどを書きます。金額は総額の目安か「この範囲を超えるなら相談したい」という線でかまいません。制約が1つも無いと書かれている資料は、たいてい制約が共有されていないだけなので、必ず何か書いてください。
- 期日と、その期日が動かせない理由(イベント、契約更新、調達のタイミングなど)
- 予算の枠、または「この線を超えたら相談したい」という目安
- 使い続ける必要がある既存のシステム・データ・業務
- 社内の承認ルールや、守る必要のある業界の決まり
欄6: 扱うデータ
どんなデータが入り、どこから来て、どこへ出ていくかを書きます。個人情報や決済情報を扱うかどうかは、設計・費用・運用の負担を大きく左右するため、ここで明示します。既存のデータを引き継ぐ場合は、その形式(表計算ファイル、既存システムからの書き出しなど)と、おおよその件数も添えてください。件数が数百なのか数十万なのかで、移行の段取りは大きく変わります。
- システムに入るデータ(誰が入力するか、どこから取り込むか)
- 個人情報・決済情報・機微な情報を扱うか
- 既存データの移行があるか(形式と、おおよその件数)
- 外部サービスとのやり取り(会計、メール配信、チャットなど)
欄7: 決める人と、未定の一覧
最後に、この資料の内容を最終的に決める人の名前と、まだ決まっていない項目を並べます。未定項目には「いつまでに誰が決めるか」を添えます。開発が止まる原因の多くは、技術ではなく、この欄の空白です。未定が多いこと自体は問題ではありません。未定であることを共有せずに進めることが問題になります。決裁の流れが複雑な場合は、別紙の関係者マップを併用してください。
- この内容を最終的に決める人
- 日々の質問に答える窓口(誰が、どの手段で、どれくらいの速さで)
- 未定の項目と、決める期限・決める人
書き終えたら
1枚に収まったら、社内で声に出して読み合わせてください。読み合わせで質問が出た箇所が、そのまま開発中に揉める箇所です。相談相手には、この1枚をそのまま渡します。相手が「この欄が空いていますね」と指摘してくるか、「この目的なら、この機能は要らないのでは」と提案してくるかは、相手を見極める材料にもなります。費用は範囲と制約によって案件ごとに異なりますので、金額の話は、この1枚が揃ってから始めるのが結果的に早道です。
関連するインサイト
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- 開発パートナーの選び方|4つの選択肢の違いスタートアップがプロダクト開発の依頼先を選ぶときの判断軸を整理します。大手SIer、Web制作会社、フリーランス、小規模開発会社、内製の向き不向きを資金調達フェーズと速度の観点で比較し、契約前に確認したい質問と、内製化への移行の考え方を解説します。
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開