外注開発会社に渡す前に埋めるべき4つのこと — 見積もりが出ない本当の理由
要件を渡したのに見積もりが遅れたり後から膨らんだりするのは、文書にケースが書かれていないからです。画面ごとに状態・条件・結果・失敗の4つを埋めれば、開発者が聞き返さずに判断できる文書になります。
企画書を送ったのに、見積もりが来ません。来たとしても「確認事項が多い」という一言が添えられています。
ようやく契約にこぎつけると、今度は別のことが起きます。出来上がった画面を見ると、自分が考えていたものと違います。直してほしいと伝えると「それは最初になかった内容です」という答えが返ってきます。
どちらかが悪かったわけではありません。判断するための根拠が、文書になかっただけです。
開発者はこういうことを聞いてきます
要件定義書を受け取った人が聞き返す質問は、だいたい決まっています。外注開発会社が見積もりを出す前に聞くことも、ほぼ同じです。
- 「この画面はいつ表示されますか？」
- 「連携が進行中のとき、ユーザーはどこにいますか？」
- 「拒否されたら画面はどうなりますか？」
- 「これは数値ですか、日付ですか？直接入力できますか？」
- 「このデータはどこから来ますか？APIひとつで足りますか？」
- 「このボタンを押すと何が追加され、どこに遷移しますか？」
- 「ログインに失敗したら？」
- 「終了日が開始日より前だったらどうなりますか？」
質問が細かすぎるからではありません。この答えがないと、コードが書けないからです。だから見積もりも出せません。見積もりを出すには作るものの数とケースの数を数える必要があるのに、そのケースが文書に書かれていないのです。
文書から抜けているのは、たいてい同じ4つです
画面は描かれています。機能も書かれています。抜けているのはいつもこの4つです。
1. 状態 — この画面はいまどんな状態か
同じ画面でも、状態によって見え方が変わります。空のとき、読み込み中、読み込み完了、失敗したとき。たいていは読み込み完了の状態ひとつだけが描かれています。
- これでは足りません — 連携済みの口座一覧が表示される
- こう書くべきです — 連携前 / 連携中 / 連携完了 / 連携失敗 — 4つの画面
2. 条件 — いつそれが表示されるか
ボタンや案内文が常に表示されるのか、特定の条件でだけ表示されるのかが書かれていないと、開発者は質問するか、独自に決めることになります。
- これでは足りません — 再申請ボタン
- こう書くべきです — 直前の申請が拒否された場合のみ再申請ボタンを表示
3. 結果 — 押すと何が起きるか
ボタン名だけがあって、その先がないケースがよくあります。何が保存され、どこに遷移し、ユーザーに何が表示されるかまでがワンセットです。
- これでは足りません — 確認ボタン
- こう書くべきです — 確認 → 申請を保存 → 完了画面へ遷移 → 受付番号を表示
4. 失敗 — うまくいかないときどうなるか
特に抜けやすい項目です。うまくいく流れだけを描いて終わってしまいます。しかし実際のサービスで時間を取られるのは、ほとんどがうまくいかないときの処理です。
- これでは足りません — （何も書かれていない）
- こう書くべきです — ネットワーク失敗時は再試行を案内 / 重複申請時は既存の申請を案内 / 入力値エラー時は該当欄を表示
なぜ4番目がいちばん重要なのか
機能は想像すれば出てきます。失敗は経験しないと出てきません。
だから失敗の項目が空の文書は、多くの場合まだ一度も実際に回したことのないサービスです。開発会社もそれを見抜きます。その状態で出た見積もりは、後から膨らむことが多いのです。書かれていなかったケースが、開発の途中でひとつずつ現れるからです。
逆に、失敗時の処理が書かれていれば見積もりはすぐに出ます。数えられるからです。
フィンテックサービスを作っていたとき、オープンバンキング連携を統括したことがあります。金融機関の審査を通過するには、機能が動くだけでは不十分でした。機能テストとセキュリティ文書まで揃える必要がありました。どんな条件でどう失敗し、そのとき何を表示し、何を記録するかまでです。
その過程は手間がかかりましたが、その文書があったおかげで、少人数チームでも審査を通過できました。埋めないと通らない文書を一度書いてみると、それ以降はそれが標準になります。
渡す前のチェックリスト
画面ひとつごとに、下の4行を埋めてみてください。4行が埋まらない画面があれば、そこが後で見積もりが膨らむポイントです。
画面名:
____________
1. 状態 — この画面が取りうる状態は？（空 / 読み込み中 / 完了 / 失敗）
2. 条件 — いつ表示されるか？
3. 結果 — ユーザーが操作すると、何が保存されどこへ遷移するか？
4. 失敗 — うまくいかないとき、何を表示し何を記録するか？
ここにもうひとつだけ加えるとよいでしょう。このデータはどこから来るのか。画面に表示される数値がどのシステムから来るのかが書かれていないと、開発が始まってから「その値はありません」という答えを聞くことになります。
AIに任せるときも同じです
最近は要件の初稿をAIで書くことが多くなっています。このときも条件は同じです。
「画面設計書を書いて」と頼むと、うまくいく流れだけが出てきます。AIも失敗を想像することはできないからです。代わりにこう頼むと変わります。
「この画面の状態を4つに分けて、それぞれの状態でユーザーに見えるものと、失敗したときの処理を一緒に書いて。」
AIが得意なのは空いている欄を埋めることです。何を埋めるべきかは、人が教える必要があります。
今日ひとつだけやるなら
いま作っている画面の中からひとつだけ選んで、上の4行を埋めてみてください。
いちばん早く見えてくるのは4番目です。失敗の項目が空なら、その画面はまだ渡す準備ができていません。
自分たちの文書が渡せる状態か分からないときは
2分の診断で、いま最初に手をつけるべき課題ひとつと、2週間パイロットの開始案、人が必ず確認すべきリスクを整理してご覧いただけます。無理のない範囲でお答えいただければ大丈夫です。
脚注
① 参考資料・確認日
この記事は外部の統計・研究を引用していません。根拠は、講義・コンサルティングの現場で要件定義書をレビューする中で繰り返し確認した質問パターンです（起業予定者との1:1コンサルティング累計500件以上・経歴SSOT基準）。本文のオープンバンキングの事例は、2021年にフィンテックサービス（2019.09〜2022.06在籍）で連携を統括した経験です。確認日 2026-08-04。
② 使わなかった数値
開発期間の短縮率や見積もりの削減率といった数値は使っていません。私たちが測定した値ではなく、プロジェクトごとのばらつきが大きく一般化できないためです。社内アンケートやCS対応の数値も使用していません。
③ 作成方法
AIで初稿を作成し、人が検証・編集しました。公開前に事実・トーン・法務の3つのチェックを経ています。
Engagement
閲覧数とリアクションは内部コンテンツ運用指標として保存されます。
要点
- •見積もりが出ないのは文書の出来が悪いからではなく、ケースが書かれておらず数えられないからです。
- •文書から抜けるのはたいてい、状態（空・進行中・完了・失敗）、条件（いつ表示されるか）、結果（押すと何が保存されどこへ遷移するか）、失敗（うまくいかないときの処理）の4つです。
- •特に抜けやすいのは失敗時の処理で、失敗の項目が空の文書は、多くの場合まだ実際に回していないサービスです。
- •画面に表示される値がどのシステムから来るのか（データの出所）を書かないと、開発着手後に値がないと言われることになります。
- •AIに要件の初稿を任せるときも、状態を分け、失敗時の処理を一緒に頼む必要があり、何を埋めるべきかは人が教える必要があります。
よくある質問
外注開発会社に見積もりを依頼しましたが、返事が遅いです。まず何を補うべきですか？
画面ごとに状態・条件・結果・失敗の4つが書かれているかを確認してみてください。見積もりは作るもののケースを数えて出すものですが、この4つがないと数えられません。特に失敗時の処理が空だと、見積もりが後から膨らみやすくなります。
要件定義書にはどこまで書けば十分ですか？
開発者が聞き返さずに判断できれば十分です。基準は「この画面はいつ表示されるか、失敗したらどうなるか、このデータはどこから来るか」に、文書だけを見て答えられるかどうかです。
AIで画面設計書を作ってもよいですか？
初稿の作成には役立ちます。ただ、そのまま頼むとうまくいく流れだけが出てくることが多いため、状態を分け、失敗したときの処理も一緒に頼むほうがよいでしょう。何を埋めるべきかを決めるのは人の役割です。
STAR-T
STAR-T代表コンサルタント
ITサービス企画・デザイン専門家として、様々なスタートアップと企業の成功事例を研究・共有しています。
今すぐ実行へ
読んで終わらず、今すぐ実行できるサービスや相談へ。
インサイトで課題を理解したら、次のステップは実行構造を決めることです。関連サービスや無料ミーティングへすぐに進めます。