モック先行開発とは｜要件定義の失敗を防ぐ「動くモック」の進め方と依頼のコツ

システム開発の失敗は、要件定義で決まっている

「納品されたものが、思っていたのと違う」「途中で仕様変更が重なり、費用も納期も膨らんだ」——システム開発の失敗談の多くは、要件定義の段階に原因があります。もっと正確に言えば、「動くものを一度も見ないまま、文章と図だけで完成形を決めなければならない」という進め方そのものに原因があります。

要件定義書には「顧客一覧画面で、氏名・電話番号・担当者で検索できること」と書けます。しかし、検索結果がどう並ぶのか、一覧から詳細へどう遷移するのか、担当者が変わったときに履歴はどう見えるのか——実際に使う場面での細かな期待は、文章にした時点で抜け落ちます。抜け落ちた部分は開発側の解釈で埋められ、納品時に「違う」として表面化します。

モック先行開発とは

モック先行開発とは、要件定義書を書き上げる前に「実際に操作できる試作品（モック）」を作り、それを触りながら仕様を確定していく進め方です。プロトタイピングとも呼ばれますが、ここで言うモックは画面の絵（デザインカンプ）ではなく、ボタンを押せば画面が動き、データが入り、業務の流れを再現できるものを指します。

この進め方自体は以前からありましたが、モックを作る工数がそれなりにかかるため、「モックを作る費用と時間がもったいない」と敬遠されがちでした。状況を変えたのが生成AIです。AIコーディングエージェントを使えば、画面と基本的なロジックを短期間で生成できるため、モックを作るコストが劇的に下がりました。axflowでは、ヒアリングから動くモックのお渡しまでを最短1〜2週間で行っています。

「絵のモック」と「動くモック」の違い

観点	絵のモック（デザインカンプ・画面遷移図）	動くモック
確認できること	見た目、レイアウト	見た目に加えて、操作の流れ、入力と表示の関係、業務の再現
気づけるズレ	色・配置・文言	「この順番だと現場で使いにくい」「この情報が足りない」
現場担当者の反応	想像で意見を言う	実際に触って意見を言う
本開発への引き継ぎ	設計書に翻訳が必要	モックそのものが仕様になる

決定的な差は「現場の人が触れるかどうか」です。システムを実際に使うのは経営者ではなく現場の担当者であることが多く、その人たちが触って初めて出てくる意見が、使われるシステムと使われないシステムを分けます。

参考：ユーザビリティ研究のNielsen Norman Group「UX Prototypes: Low Fidelity vs. High Fidelity」は、プロトタイプを忠実度（fidelity）で分類し、実際に操作できる高忠実度のプロトタイプほど、利用者から実運用に近いフィードバックが得られると解説しています。「動くモック」で仕様を確定する進め方は、この考え方を発注プロセスに応用したものです。

モック先行開発の進め方（5ステップ）

STEP 1：業務の流れを聞く

「どんな機能が欲しいか」ではなく、「今、誰が、何を、どの順番でやっているか」を聞きます。Excelの管理表、手順書、実際の画面キャプチャがあれば、それが一番の資料です。要件定義書は要りません。

STEP 2：業務の流れを再現するモックを作る

聞いた業務の流れを、そのまま画面と操作に落とし込みます。データはダミーで構いません。重要なのは「入力→一覧→詳細→次のアクション」といった流れが一通り動くことです。

STEP 3：現場の人に触ってもらう

決裁者だけでなく、実際に使う担当者に触ってもらいます。「ここで戻れないと困る」「この項目は毎回同じだから省きたい」といった意見は、この段階でしか出てきません。

STEP 4：反映して仕様を確定する

意見を反映したモックが、そのまま仕様になります。ここで初めて「確定した仕様」に対する見積もりが出せるので、費用と期間の見通しが立ちます。

STEP 5：本開発

モックで固めた画面と流れをもとに、データベース設計、認証・権限、外部連携、性能・セキュリティといった「モックでは省いた部分」を本実装します。仕様が固まっているため、実装中の手戻りが少なく、進捗も動く状態で随時共有できます。

モックを触るときのチェックリスト

モックを受け取ったら、次の観点で触ってみてください。見た目の好みよりも、「業務がこの流れで回るか」に集中するのがコツです。

• 朝一番の操作：ログインして最初に見る画面は、自分が今日やるべきことが分かる画面になっているか。
• 一番多い操作：1日に何十回もやる登録・更新は、最短の手数でできるか。毎回同じ値を入れる項目は初期値になっているか。
• 探す操作：「先週の◯◯社の案件」をすぐ見つけられるか。絞り込み・並び替え・検索は現場の探し方に合っているか。
• 例外の操作：キャンセル、差し戻し、担当者変更、入力ミスの修正。例外時に「戻れない」「履歴が消える」箇所がないか。
• 締めの操作：月末・週末の集計や報告は、ボタン一つで出るか。Excelに書き出す必要があるなら、その形式で出るか。
• 権限：見せてはいけない情報が、見せてはいけない人に見えていないか（モックでは簡易でも、方針は確認）。
• 他のツールとのつながり：メール、チャット、既存の基幹システムなど、前後の業務とどうつながるか。

このチェックで出た意見が、そのまま仕様の確定事項になります。要件定義書を読んで「たぶん大丈夫」と判断するのと、実際に触って「ここが困る」と言えるのとでは、納品後の満足度がまったく違います。

モックと要件定義書は、どう使い分けるか

モック先行開発は「要件定義書を一切作らない」という意味ではありません。役割が変わります。

画面の流れ・入力項目・表示内容といった「触って分かること」はモックが担い、要件定義書には「触っても分からないこと」を書きます。たとえば、データの保存期間、権限のルール、外部システムとの連携仕様、性能やセキュリティの要件、稼働時間や障害時の対応などです。モックで確定した内容を前提に書くので、要件定義書は薄く、具体的で、解釈のブレが少ないものになります。

発注する側にとっての利点は、「文章を読んで想像する」作業がほぼなくなることです。モックを触った経験があるので、要件定義書の記述も具体的にイメージできます。

モックを依頼するときの注意点

モックで「確認しないこと」を決めておく

モックはあくまで業務の流れと画面の確認が目的です。処理速度、大量データでの挙動、セキュリティ、細かなデザインは本開発で扱う領域です。「モックが遅いから不安」といった評価は本来の目的とズレます。

モックの費用と権利を確認する

モック作成が有料か無料か、モックを見て発注しなかった場合にどうなるか、事前に確認しておきます。axflowではモック作成は無料で、モックを見てから発注を判断いただけます。

「作り込みすぎ」を求めない

モック段階で完璧を求めると、モック自体が長引きます。「流れが確認できる最小限」で早く出してもらい、触って直す回数を増やす方が、結果的に良い仕様になります。

まとめ

要件定義の失敗は、担当者の能力の問題ではなく、「文章で完成形を約束する」進め方の限界です。生成AIによってモックを作るコストが下がった今、「まず動くものを作り、触って、直す」進め方が現実的になりました。発注前に動くモックを見せてくれる開発会社を選ぶことが、失敗しないシステム開発の一番の近道です。

axflowのAI駆動開発では、最短1〜2週間で動くモックを無料で作成しています。詳しくは AI駆動開発のサービスページ をご覧ください。

参考資料

• Nielsen Norman Group「UX Prototypes: Low Fidelity vs. High Fidelity」
• The Lean Startup「Principles」（エリック・リース）
• IPA「DX白書2023」
• 関連ページ：AI駆動開発（動くモックを最短1〜2週間で無料作成）／AI駆動開発とは／システム開発の費用相場

よくある質問

モックは本開発でそのまま使われますか？

画面と業務の流れは本開発に引き継がれます。データベース設計や認証、外部連携などの基盤部分は本開発で改めて実装します。

要件がまとまっていなくてもモックを頼めますか？

頼めます。むしろ、まとまっていない段階でモックを作り、触りながら整理する方が、モック先行開発の本来の使い方です。

モックを見て発注しないこともできますか？

できます。axflowではモック作成とお見積りまで無料で、発注するかどうかはモックを見てから判断いただけます。