モックアップから始める要件定義｜生成AIで商談の段階から画面を作り、現場に当てて要件を固める進め方ARTICLE

「要件定義書を何十ページも読んで承認したのに、できあがった画面を見たら現場から『これでは使えない』と言われた」。システム開発でよく聞く話です。文書で要件を固めてから作る進め方では、実際に使う人が画面を目にするのは、要件定義の終盤か、開発が進んでからになりがちでした。

この順番が、生成AIで変わりつつあります。画面の試作（モックアップ）を短い時間で作れるようになり、要件定義に入る前の提案・商談の段階から画面を作って、実際に使う人に見てもらうことが現実的になりました。

本記事では、モックアップを先に作って現場に当てる進め方を、K.S.Rogers の現場で起きている変化とあわせて整理します。モックアップを要件定義の中で合意の道具として使う方法は、要件定義の進め方のステップ5で扱っているので、ここでは「もっと前の段階で作る」ことに絞ります。

この記事の要点

• 生成AIで画面の試作が手軽になり、モックアップを作る時期を、要件定義の終盤から提案・商談の段階へ前倒しできるようになりました
• 先に作った画面を実際に使う人に当てると、使い勝手だけでなく、現場の業務、課題に感じていること、今のシステムの不具合まで聞き取れます。聞き取った内容は、要件・やらないこと・確認事項に仕分けて提案と要件定義書に戻します。いちばん大事なのは、使う人にどんなメリットがあるかを画面を前にすり合わせることです
• 当社でも、この半年〜1年で、商談の段階からモックアップを作って当てに行くことが大きく増えました。店舗を展開している会社様では、店舗に伺って店長やスタッフの方に画面を見ていただき、その聞き取りをもとに提案しています
• モックアップは完成品ではありません。作り込みすぎず、見た目の議論に寄せず、合意した内容は要件定義書に言葉で残します

要件定義の進め方は、何が変わったのか

これまでの一般的な進め方では、商談では文書や過去の事例で提案し、受注してから要件定義に入り、ヒアリングと文書で要件を固め、その終盤に画面のイメージで確認する、という順番でした。画面を作るには、デザインやコーディングの手間がかかるため、何を作るかがある程度決まってからでないと作れなかったからです。

生成AIで画面の試作にかかる手間が小さくなったことで、この順番を入れ替えられるようになりました。

K.S.Rogers の現場から

これまでの当社の提案は、「まず要件定義の工程をしっかり設けて、そこから進めましょう」という形が基本でした。生成AIでモックアップを作りやすくなり、利用者がその画面をどう使うか（ユーザー体験）もつかみやすくなったことで、この半年〜1年は、提案・商談の段階からモックアップを作って当てに行くことが大きく増えています。そこまでやらなければ受注にはつながらず、当社がご一緒する価値もない、と考えています。要件定義の手前の商談から、進め方そのものが変わってきました。

モックアップ・プロトタイプとは ―― 要件定義での役割

本題に入る前に、言葉をそろえておきます。画面の試作には、作り込みの度合いによっていくつかの呼び方があります。

どれも完成品ではなく、「作るものを、関係者が同じ絵で思い浮かべる」ための道具です。要件定義の中でモックアップを使って認識のずれをつぶす効果は大きく、当社の支援でも、使われなくなっていたシステムを、利用者への調査とモックアップでの合意から作り直し、利用率が20%から65%に上がった例があります（詳しくは要件定義の進め方）。

生成AIのツールでは、言葉で伝えるだけで、触って動かせるプロトタイプに近いものまで作れるようになりました。本記事では、この3つをまとめて「モックアップ」と呼びます。

生成AIで、商談の段階のモックアップが現実的になった

画面の試作を作るには、これまでデザイナーやエンジニアの手が必要でした。何を作るかが決まっていない商談の段階で、相手の業務に合わせた画面を毎回作るのは、手間の面で現実的ではありませんでした。

いまは、画面に載せたい項目や業務の流れを文章で伝えると、試作の画面を作ってくれるツールがあります。たとえば次のようなものです（いずれも2026年10月確認）。

• Figma Make：Figma が提供するツールで、テキストの指示からプロトタイプやアプリを作れます。作ったものはキャンバス上で見た目を調整できます
• v0：Vercel の AI エージェントで、言葉で伝えた内容から画面とコードを作れます

ツールの名前は、ここでは例として挙げています。大切なのは、提案の前に相手の業務に合わせた画面を何度でも作り直せるようになったことです。1回目の訪問で聞いた話をもとに画面を直し、2回目の訪問でまた見ていただく、という往復が、商談の期間の中で回せるようになりました。

一方で、手軽に作れるからこそ、何を確かめるために作るのかを先に決めておかないと、きれいな画面が増えるだけになります。この点は後の「気をつけること」で扱います。

モックアップを先に現場に当てると、何が分かるのか

画面を前にすると、会議室で「どんな機能が欲しいですか」と聞いたときには出てこない話が出てきます。先に当てることで分かるのは、主に次の4つです。

特に4つめの「今のシステムの不具合」は、新しいシステムの話だけをしていると出てきにくい情報です。今の画面と並べて新しい画面を見せると、「今のこれが困っている」という話につながりやすくなります。

K.S.Rogers の現場から

店舗を展開している会社様へのご提案では、店舗に伺い、店長やスタッフの方にモックアップを見ていただきながら、「この使い勝手はどうですか」とお聞きしました。あわせて、店舗での業務の流れ、課題に感じていること、今お使いのシステムの不具合まで伺い、それをもとに提案をまとめています。本社で伺う要望だけでなく、毎日その画面を使う方の声を、提案の段階から入れておくことを大切にしています。

店舗の業務なら、商談の段階で用意する画面は、たとえば次のようなものです。お客様がスマホで見る画面と、店舗のスタッフがタブレットで使う画面を、1つの仕組みの両側として見せます。下の図は説明のために作ったダミーの画面（架空の自転車店）で、実際のご提案の画面ではありません。

現場に当てるときの進め方

モックアップを作って見せるだけでは、聞き取りが「いいですね」「ここの色が」で終わってしまいます。作る前から、聞き取りを提案と要件に戻すところまでを、ひと続きで考えておきます。

1. 仮説を画面にする

最初の打ち合わせで伺った話から、「この業務の、この場面で、こう使うのではないか」という仮説を立て、それを画面にします。画面の数は、仮説を確かめるのに必要な数枚で十分です。すべての機能を網羅する必要はありません。

• 業務の中で一番よく使う場面の画面から作る
• 項目名や言葉づかいは、相手の社内で使っている言葉に合わせる
• 実在のお客様の名前や数字は入れず、仮のデータで作る

2. 誰に見せるかを決める

見せる相手は、発注の窓口の方だけでなく実際にその画面を毎日使う人を含めます。店舗なら店長やスタッフ、工場なら現場の担当者、営業なら外回りの営業担当です。役職の高い方だけに見せると、「こうあるべき」という話に寄り、毎日の使い勝手の話が出てきにくくなります。

可能であれば、現場に伺って、ふだん使う場所で見ていただきます。オンラインでも見せられますが、店舗のレジ横や倉庫の中など、実際に使う環境で見ると、画面の大きさや操作のしやすさについての話が具体的になります。

もう一つ、見せる相手の中に、画面を見て自分の業務に置き換えて話せる現場の担当者を、少なくとも一人は入れておきます。ITに詳しい方である必要はありませんが、画面を見ても使う場面が思い浮かばない方ばかりだと、話が進みにくくなります。

K.S.Rogers の現場から

お話しする相手は、ITに詳しい方ばかりではありません。文書や口頭の説明では伝わらなかったイメージが、モックアップを見て初めて伝わり、「実際に使うとしたらどうか」という感想やコメントが、そこで初めて出てくることがよくあります。モックアップを土台にすることで、初めて議論が進む場面は多いと感じています。それでも、モックアップを見てもイメージがつきにくい方はいらっしゃいます。だからこそ、最低限のITリテラシーがある現場の担当者の方とお話しできることが、とても重要だと考えています。

3. 何を聞くかを決めておく

画面の感想を聞くだけで終わらないよう、聞くことを先に決めておきます。

中でもいちばん大事なのは、このシステムを使うことで、使う人がどんなメリットを受けられるのかを、画面を前に説明し、すり合わせることです。「便利になります」ではなく、「この入力が要らなくなる」「この確認がその場でできる」と、その人の毎日の仕事に置き換えて話せるかどうかで、提案の受け止められ方が変わります。

聞き取りの観点そのものは、要件定義のヒアリングと変わりません（質問例は要件定義の進め方にもまとめています）。違うのは画面という具体物を前にして聞くことで、答えが具体的になる点です。

K.S.Rogers の現場から

当社のご相談では、業務の一覧や書類のサンプルをお送りいただくまでに時間がかかり、検討が止まってしまうことがよくあります。そうした場合は、資料を待つより、1日現場に伺ってその場で業務を見せていただくほうが早く進みます。モックアップを当てるときも同じで、こちらから現場に出向くことが、話を前に進める近道になります。

4. 聞き取った内容を仕分ける

現場で聞いた話は、そのまま全部を要件にはしません。次の4つに仕分けます。

「確認が要る」に入るものは、特に大事です。現場の要望と本社の方針が食い違うことは珍しくありません。どちらかに勝手に寄せず、決める立場の方に判断していただく材料として残します。

5. 提案と要件定義書に戻し、画面を直してもう一度当てる

仕分けた結果をもとに、提案の範囲・優先順位・概算を組み立てます。あわせて画面を直し、次の打ち合わせや訪問でもう一度見ていただきます。この往復を、提案の段階で1〜2回回しておくと、要件定義に入ったときには「現場で一度確かめた画面」と「聞き取りの記録」が手元にある状態から始められます。

要件定義そのものの進め方（要求の言語化、やらないことの決め方、合意の取り方）は、要件定義の進め方を、要件定義書に何を書くかは要件定義書に書くことをご覧ください。

気をつけること

モックアップを早く作れるようになったことで、新しいつまずき方も生まれています。

特に「要件定義書は要る」は強調しておきます。モックアップは「どう見えるか」を伝える道具で、例外のときの扱い、データの持ち方、権限、性能やセキュリティといった非機能要件、そして「今回はやらないこと」は画面に出てきません。画面で合意したことを要件定義書に書き起こして初めて、開発側が見積もり・実装できる形になります。失敗のパターンとしては、要件定義が失敗する原因と防ぎ方もあわせてご覧ください。

発注側にとっての意味 ―― 提案を比べるときの見方

この変化は、開発会社の側だけの話ではありません。システム開発を発注する側にとっても、提案を比べるときの見方が1つ増えます。

モックアップを持ってくるかどうかは、その会社が業務と利用者をどこまで理解しようとしているかを見る、判断材料の1つになると考えています。ただし、画面のきれいさで選ぶのは避けたほうがよいでしょう。生成AIで見た目の整った画面は作りやすくなったため、見るべきは画面そのものより、その画面を誰に当て、何を聞き、どう提案に反映したかです。

発注側から「現場の担当者に一度見せてもらえますか」と頼んでみるのも1つの方法です。現場の声を早い段階で入れておくことは、発注側にとっても、できあがってから「使えない」と言われるリスクを減らすことにつながります。

K.S.Rogers の支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。モックアップを使って現場の声を早い段階で集め、要件定義書に言葉で落とし込むところまで、発注側と開発側の間に入ってご一緒します。

全国どちらの企業からのご相談にも、面着とオンラインで対応します（よく伺うのは関西・関東・名古屋です）。現場に伺ってお話を聞くことを大切にしています。

まとめ

• 生成AIで画面の試作が手軽になり、モックアップを作る時期を、要件定義の終盤から提案・商談の段階へ前倒しできるようになりました
• 先に作った画面を実際に使う人に当てると、使い勝手だけでなく、現場の業務、課題に感じていること、今のシステムの不具合まで聞き取れます
• 聞き取った内容は、要件・やらないこと・確認事項・今のシステムの課題に仕分け、提案と要件定義書に戻します。モックアップは完成品ではなく、要件定義書は引き続き要ります
• 発注側は、提案を比べるときに「画面を持って現場に来るか」「聞き取りが提案に反映されているか」を判断材料の1つにできます

モックアップを使った要件定義の進め方や、開発会社の提案の見方でお悩みの際は、お問い合わせよりお気軽にご相談ください。