開発方針を相談する

受託開発で炎上しやすい要件定義の特徴

"いい感じに作ってほしい" が、後で一番高くつく。

この記事の結論

「要件定義書ができたので、開発開始でいいですよね」

発注時によく言われる言葉ですが、そこに書かれている内容次第 で開発の成否が決まります。立派な要件定義書でも、炎上する案件はあります。逆に、シンプルな 1 枚設計書でも、うまく進む案件もあります。

Anthropic の Claude Code 解説でも、コードベース固有の規約・標準・ワークフローを CLAUDE.md として明示する ことの重要性が紹介されています (Using CLAUDE.md files / Anthropic)。発注者と開発会社の間でも、要件と制約を明示することが、認識のズレを防ぎます。

この記事では、炎上しやすい要件定義の特徴と、防ぐためのチェック項目を整理します。

炎上する要件定義の共通点

実際の失敗パターン:

1. 目的が曖昧

「便利なツールを作ってほしい」「他社事例を参考に」だけ。なぜ作るのか、誰のために作るのかが書かれていない。

2. 機能リストはあるが、業務フローがない

「予約管理機能」「顧客検索機能」とだけ書かれている。実際の業務でどう使うかが分からない。

3. 例外処理が抜けている

ハッピーパスだけ書かれていて、キャンセル、返金、誤入力、特殊対応がない。

4. 運用担当者が決まっていない

「リリース後の不具合対応は誰が見るか」「軽微改修は誰がやるか」が決まっていない。

5. 権限が後付け前提

「最初は 1 ロールで」と決めて、ロールが増えたときの対応方針がない。

6. データモデルが整理されていない

主要なデータ (顧客、注文、在庫など) の項目と関係が、図でも一覧でも示されていない。

7. 「ケースバイケース」が多い

判断基準が言語化されておらず、「現場の判断」「担当者の経験」に依存。

これらが揃うと、開発途中で「思っていたものと違う」「これも入れてほしい」が頻発し、追加見積もりで予算超過、納期遅延につながります。

目的が曖昧なケース

「目的」と「機能」を混同して書かれている要件定義は、炎上の典型。

悪い例

予約管理システムを作ってほしい。 機能: 予約登録、検索、編集、削除、レポート。

良い例

目的: 紙と電話の予約管理から SaaS に移行することで、予約取りこぼしを月 5 件から 0 件にし、複数店舗の状況共有を可能にする。 ユーザー: 店舗スタッフ (1 日 30 回操作)、本社管理者 (月数回レポート確認)、顧客 (月 1 万人がスマホで予約)。 検証したい仮説: 予約取りこぼしが減ることで、月の機会損失が 20 万円減る。

目的が決まっていれば、外注先から「もっと安い代替案」「別のアプローチ」の提案を受けやすくなります。

詳しくは 開発会社に依頼する前に作るべき "1 枚設計書" で展開しています。

例外処理が抜けるケース

ハッピーパスだけで設計されたシステムは、例外で破綻します。

よく抜ける例外

対策

AI で作った業務システムが、リリース後に破綻する 5 パターン でも、例外フローの設計不足が破綻の典型として紹介しています。

運用担当者が決まっていないケース

「リリース後に決める」では遅すぎます。

決めておくべき項目

これらを発注前に決めておくと、リリース後にスムーズに運用が回ります。

ここまでで「自社の要件定義を見直したい」と感じたら、要件整理のワークショップから相談するのが現実的です。

要件整理ワークショップを相談する →

要件定義で決めるべきこと

最低限、以下を明示します。

項目内容
目的なぜ作るか (1 段落)
ユーザー役割と人数規模、利用頻度
業務フロー入力・判断・出力・承認・例外の 5 要素
画面 / 機能Must / Manual / Later / Never の仕分け
データ主要エンティティと項目
権限役割と見える範囲のマトリクス
例外想定する例外と対応方針
通知誰に、いつ、何を通知するか
運用責任リリース後の担当者と対応経路
予算上下のレンジ
納期絶対の締め日と希望日

これらが揃っていれば、見積もり精度と提案の質が大きく上がります。

「決めていないこと」を明示する

要件定義の盲点は、「決まっていない」のに「決まっているように見える」 ことです。

決めていないことのリスト化

このリストを 週次で更新 することで、開発中の遅延が大幅に減ります。

AI 時代の要件整理

AI ツール (Cursor / Claude Code / Codex) を使う開発では、要件と制約を プロジェクト文脈ファイル にまとめておきます。

CLAUDE.md / AGENTS.md に書く要件関連の情報

OpenAI のドキュメントでも、AGENTS.md は 作業を始める前に Codex が読む プロジェクト固有指示として説明されています (Custom instructions with AGENTS.md / OpenAI Developers)。これは AI 用の要件定義書とも言えます。

詳しくは CLAUDE.md / AGENTS.md に何を書くべきか で展開しています。

要件定義を重くしすぎない

「完璧な要件定義書」を目指すと、開発開始までに数ヶ月かかります。これは MVP・新規事業では非現実的。

軽い要件定義の例

これくらいでも、開発はスタートできます。走りながら決める 部分を明示することで、要件定義の重さを減らせます。

発注前チェックリスト

要件定義の完了度を確認するチェックリスト:

項目確認すること
目的1 段落で書ける
ユーザー役割と人数が明示
業務フロー5 要素 (入力・判断・出力・承認・例外) が整理
機能Must / Manual / Later / Never に分けてある
データ主要エンティティと項目が 1 枚
権限役割マトリクスがある
例外想定例外がリスト化
通知誰に何を通知するか明示
運用リリース後の担当者が決まっている
決めていないことリスト化されている

8 つ以上揃っていれば、発注可能な状態です。

min's の要件整理支援

min's では、要件定義の整理を以下の形で支援しています。

Phase 1: 要件ワークショップ (1〜2 日)

Phase 2: 要件定義書化 (1〜2 週間)

Phase 3: 発注先比較サポート

要件整理について相談したい方へ

min's では、要件整理ワークショップ、要件定義書の作成、発注先選定までを支援しています。

以下のような状態であれば、ご相談ください。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する