要件定義のフェーズは終わったはずなのに、開発が進むにつれて「思っていたのと違う」「これも必要だった」が積み重なっていく——システム開発の現場でよく見る失敗構造です。発注側は「ちゃんと打ち合わせたつもり」、ベンダー側は「決まったとおりに作っているだけ」と認識がずれたまま進み、リリース直前で大きな揉め事になります。本記事では、要件定義で失敗するシステム開発に共通する3つの曖昧さを、中小企業の経営者向けに整理します。
この記事の結論（3行）
- 要件定義の失敗は「機能の曖昧さ」「データの曖昧さ」「運用の曖昧さ」の3要素から生まれる
- 要件定義書に画面イメージ・データ項目・運用フローが揃っていなければ、リリース後の揉め事は確実に起きる
- 経営者は要件定義書を「使う側の言葉で読める」レベルになるまでベンダーに修正させる権限を持つべき
なぜ要件定義のフェーズで失敗が起きるのか
要件定義は、システム開発で最もコミュニケーションコストがかかるフェーズです。発注側の「やりたいこと」をベンダーが理解し、技術的な制約を踏まえて「作るもの」に翻訳する作業ですが、この翻訳の過程で必ず情報が落ちます。中小企業の現場では、業務知識を持つ人とITに詳しい人が同じ場にいないため、翻訳の精度が特に下がります。
- 発注側の「やりたいこと」が業務単位でしか語られない
- ベンダー側が「技術用語」で要件をまとめてしまう
- 双方で「あいまいに合意した」気になっている
要件定義書ができた時点で「合意」と扱われ、次の工程へ進んでしまうケースが多いのですが、その時点で実は3つの曖昧さが残っていることがほとんどです。
発注側の「やりたいこと」が業務単位でしか語られない
経営者や現場担当者がベンダーに伝える要望は、「在庫管理を効率化したい」「営業の見積もり作成を早くしたい」など業務単位の表現になりがちです。これだけでは、ベンダー側は「どの画面で、どの項目を、どんな操作で」を決められません。業務単位の要望を、画面・項目・操作のレベルまで分解する作業が要件定義です。ここを怠ると、後の工程で必ずブレが出ます。
ベンダー側が「技術用語」で要件をまとめてしまう
要件定義書が「マスタテーブル」「権限ロール」「バッチ処理」のような技術用語で書かれていると、発注側は読み解けません。読まずに承認してしまい、開発が進んでから「これは違う」と気づきます。要件定義書は使う側の言葉で書かれているのが理想で、技術用語が多いほど後で揉める確率が上がります。
双方で「あいまいに合意した」気になっている
打ち合わせの席で「だいたいこんな感じで」と口頭で合意したつもりが、文書化されていないというパターンです。記憶は人によって変わるため、3ヶ月後には「言った」「言わない」になります。打ち合わせ記録を必ず残し、要件定義書に反映させる流れを作っておかないと、リリース直前に対立構造が生まれます。
後で必ず揉める3つの曖昧さ
要件定義の失敗を、3つの曖昧さで整理します。リリース後の揉め事のほぼ全てが、この3つのどれかに起因します。
| 曖昧さの種類 | よくある症状 | リリース後の揉め事 | 防止策 | |---|---|---|---| | 機能の曖昧さ | 「だいたい」「適宜」「必要に応じて」が要件定義書に多い | 「この機能はあると思っていた」 | 画面遷移図と全画面モックを用意 | | データの曖昧さ | データ項目・桁数・必須有無が曖昧 | 「既存データが移行できない」 | データ項目一覧を全テーブルで作成 | | 運用の曖昧さ | 誰がいつ何をする運用フローが不明 | 「誰が登録するか決まっていない」 | 業務フロー図と権限マトリクスを作成 |
3つの曖昧さは、それぞれ独立して防止策があります。要件定義書の最終版を確認するときに、この3観点でチェックすると揉め事の8割は防げます。具体的なチェック方法を整理したい場合は、業務改善・システム見積もりAI適正診断で個別に整理できます。
曖昧さ1: 機能の曖昧さ
「機能の曖昧さ」は最も起きやすい失敗です。要件定義書に「だいたい」「適宜」「必要に応じて」が並んでいるなら、ほぼ確実に揉めます。「商品マスタは適宜編集できる」と書かれていても、「適宜」が具体的に何を指すのかは人によって違います。発注側は「現場で自由に追加削除できる」と思い、ベンダーは「管理者画面で1件ずつ操作」と捉える、このズレが後で揉め事になります。
防ぐには、要件定義書に画面遷移図と全画面のモックアップ（または手書きでも可）を添付してもらってください。実際の画面を見ながら「ここでこのボタンを押すと何が起きるか」を確認すれば、機能の曖昧さは大幅に減ります。
曖昧さ2: データの曖昧さ
データ項目・桁数・必須有無・初期値などが曖昧なまま開発に入ると、リリース直前にデータ移行で必ず詰まります。「顧客マスタ」とだけ書かれていて、項目が何個あるか、どの項目が必須か、文字数の上限がいくつかが定義されていないと、既存のExcelデータが新システムに乗りません。
防ぐには、データ項目一覧を全テーブル分作ってもらってください。項目名・データ型・桁数・必須・初期値の5列があるシンプルな表で十分です。これがない要件定義書は、データ周りで必ず再調整が発生します。
曖昧さ3: 運用の曖昧さ
「誰がいつ何をするか」の運用フローが定義されていないと、リリース後に「誰がこのデータを登録するんですか」「この承認は誰が押すんですか」となり、システムが宙に浮きます。要件定義書に機能仕様だけ書かれていて、業務フロー図と権限マトリクスがない場合に起きる典型的な失敗です。
防ぐには、業務フロー図（誰が何をする順番の図）と権限マトリクス（ロール × 画面 × 操作の表）を要件定義の成果物に必ず含めてもらってください。この2つがあれば、運用周りの揉め事はほぼ防げます。さらに「異常系の運用」も合わせて定義しておくと、リリース後のトラブル対応が格段に楽になります。「データを間違えて登録した場合の取り消し手順」「承認者が不在のときの代理承認ルール」「入力途中で離席した場合のデータ保持」など、業務で実際に起きる例外パターンを5〜10個ほど洗い出して、それぞれの運用ルールを文書化しておくと、リリース後の混乱が抑えられます。
経営者目線で考える「要件定義書の読み方」
ここからは経営の話です。要件定義書は技術文書ではなく、発注側と開発側の「契約書に近い文書」です。経営者が要件定義書を読まずに承認すると、後の揉め事で「サインしたじゃないですか」と言われる立場になります。技術的に全てを理解する必要はありませんが、3つの観点で「使う側の言葉で読めるか」を必ず確認してください。
経営者が要件定義書を見るときの3つの観点。第一に、「業務の流れが図で書かれているか」。文章だけの要件定義書は、3ヶ月後に誰も読み返さないため、図がない要件定義書は信頼性が低いと判断してください。第二に、「画面のイメージが添付されているか」。手書きでも構わないので、画面のイメージがない要件定義書は機能の曖昧さを残しています。第三に、「データの項目一覧があるか」。データ項目一覧がない要件定義書は、リリース直前にデータ移行で詰まります。
この3つが揃っていない要件定義書を承認するのは、白紙の契約書にサインするのと同じ意味合いです。経営者は「これでは分からない、書き直してください」と言える権限を持っているはずで、その権限を行使しないことが要件定義失敗の根本原因になっています。
ぷらすわんの実例：じちなびで採用した要件定義のスタイル
ぷらすわんが手掛けた「じちなび」では、要件定義の段階で3つの成果物を必ず揃える方針を取りました。業務フロー図、全画面のモックアップ、データ項目一覧の3点です。
じちなびは自治体・地域DXのマッチングポータルで、市場相場では300〜800万円のところを200万円規模で立ち上げました。コストを抑えながらリリース後の揉め事をゼロにできた理由が、この3点セットの要件定義です。業務フロー図で「事業者が登録→自治体が承認→利用者が検索」の流れを共有し、全画面モックで「この画面でこのボタンを押すと何が起きる」を確認し、データ項目一覧で「Supabaseのどのテーブルにどの項目が入る」を明示しました。
中小企業のシステム発注でも、この3点セットを要件定義の必須成果物にすると、後の揉め事が大きく減ります。発注前にベンダーへ「要件定義の成果物に業務フロー図・画面モック・データ項目一覧を含めてほしい」と一文伝えるだけで、要件定義の品質は2〜3割上がります。ベンダー選定段階で要件定義の品質を項目別に整理したい場合は、現状を整理してから比較するのがお勧めです。
要件定義で揉めないための5つのチェックポイント
要件定義書を承認する前に、経営者が確認すべき5つのチェックポイントを整理します。
- 業務フロー図が「誰が何をするか」レベルで書かれている
- 全画面のモックアップ（手書きでも可）が添付されている
- データ項目一覧が全テーブル分揃っている
- 「適宜」「必要に応じて」など曖昧な表現が排除されている
- 権限ロールと操作範囲のマトリクスが完成している
この5つは、どれも要件定義書を承認する前に確認できる項目です。承認後に追加を依頼すると追加見積もりが発生してしまうため、必ず承認前に揃えてもらってください。
業務フロー図が「誰が何をするか」レベルで書かれている
業務フロー図は、システムを使う登場人物（営業担当・経理担当・管理者など）と、その人物が行う操作を時系列で図解したものです。文章だけで運用を説明している要件定義書は、3ヶ月後に誰も読み返せません。図があるかないかで、リリース後の運用立ち上げの速度が大きく変わります。図を作る際は、ツールにこだわらず、PowerPointや手書きでもよいので、登場人物のレーンを縦に並べて、上から下へ時間の流れで操作を書き並べる形式が読みやすくなります。
全画面のモックアップ（手書きでも可）が添付されている
全画面のモックアップは、要件定義の品質を最も明確に示す指標です。手書きでも構わないので、画面の構成・項目・ボタンが視覚的に示されているかを確認してください。ない場合は、開発が始まってから「思っていたのと違う」が必ず発生します。
データ項目一覧が全テーブル分揃っている
データ項目一覧（項目名・データ型・桁数・必須・初期値）が、全テーブル分揃っているかを確認してください。1〜2テーブルだけサンプルがある状態では不十分で、リリース直前にデータ移行で詰まります。既存のExcelやAccessから移行する場合は、現行データのサンプル100件を出力して、データ項目一覧と突き合わせる工程まで要件定義に含めると安心です。「電話番号がハイフン込みで入っている」「郵便番号が4桁になっている」など、現場ならではのデータの揺れがここで見つかります。
「適宜」「必要に応じて」など曖昧な表現が排除されている
要件定義書を全文検索し、「適宜」「必要に応じて」「だいたい」「将来的に」などの曖昧な表現が残っていないか確認してください。残っているなら、その箇所が後で揉める種になります。
権限ロールと操作範囲のマトリクスが完成している
権限ロール（管理者・一般・閲覧のみなど）と、各画面での操作範囲を示すマトリクスが完成しているかを確認してください。これがないと、リリース後に「この画面を別の人にも見せたい」「この操作は管理者だけにしたい」が次々と出てきて追加見積もりが膨らみます。要件定義の品質を発注前に他社と比較を依頼する場合は、この5項目を比較軸にしてください。
まとめ
要件定義の失敗は、「機能の曖昧さ」「データの曖昧さ」「運用の曖昧さ」の3要素から生まれます。これらを防ぐには、業務フロー図・全画面モックアップ・データ項目一覧という3点セットを要件定義の成果物に必ず含めてもらうことが効きます。経営者は要件定義書を「使う側の言葉で読める」レベルまでベンダーに修正させる権限を持っており、その権限を使い切ることで揉め事の8割は防げます。
要件定義の品質は、システム開発全体のコストと成否を決める要素です。発注前の段階で要件定義のスタイルを診断することで、後の揉め事を未然に防げる構造を作れます。