画面から始まる要件定義の落とし穴 — 設計者ができる対処法

業務システムの開発現場で「まずは画面モックから始めよう」という場面に遭遇したことはありませんか？

本来、要件定義は業務ルールやデータ構造から固めるべき…と思っていても、ユーザーや営業が求めるのは「見える画面」。このギャップに戸惑う設計者は少なくありません。

私自身も最初はその流れに違和感を覚えましたが、そこには現場ならではの理由があることがわかってきました。

この記事では、画面先行で進む要件定義の背景と、そのメリット・落とし穴、設計側が主導権を握るための工夫についてお伝えします。

要件定義で画面イメージが先行する背景とは

かなり前ですが、とある現場に入った際、「まずは画面のモックから見せるね」という流れが当たり前のように進んでいました。

ユーザーや営業が「こんな画面がほしい」と提示し、それをもとに要件が決まっていく…。（その当時）自分が思っていた「要件→設計→画面」の順とは違い、最初は混乱しました。

ただし、これにはそれなりの理由があります。とくに業務系システムでは、非ITのユーザーにとって画面イメージが一番伝わりやすい。抽象的な業務要件やデータ構造よりも、目に見えるものをベースに話すほうが納得感が得やすい。だから現場では「まず画面から」の発想が根強くなりがちです。

現場でよくある「画面先行型」の流れ

要件定義の初期段階で、ExcelやPowerPointで作った簡単なUIモックが共有されるケースは少なくありません。

そこで「この入力欄はいる？」「ここに一覧を出したい」といった会話が交わされ、気づけばそれが正式な仕様のベースになっていることもあります。

このやり方は、話を進めやすくする効果があります。ただし、業務ルールや帳票要件、データの整合性といった深い要素が置き去りになる可能性もあります。

なぜUIから始めたがるのか、その理由

ユーザー側の立場で考えるとわかりやすいです。

多くの業務担当者は「業務要件を文章で書く」ことに慣れていません。一方で、「こういう画面が欲しい」と伝えるのは比較的簡単。だからつい、UIイメージをベースに会話したくなるのだと思います。

また、画面を先に出すことで「検討してる感」を出しやすく、関係者の合意形成も進めやすいという現実的なメリットがあります。

業務理解が浅い段階での危うさ

一方で、開発側が業務理解を深めきれていない状態で画面に振り回されると、重大な見落としにつながります。

たとえば、複雑な承認ルートや例外処理の存在は、画面だけでは表現しきれないことが多いです。

要件定義では、UIだけでなく「背景にある業務の筋道」を押さえる必要があります。そこを飛ばしてしまうと、あとから「この画面では実現できません」となりがちです。

---

画面から仕様を固める進め方のメリットと落とし穴

画面イメージを先に作ると、ユーザーとの会話がしやすくなり、認識合わせにも役立ちます。ただし、それが仕様そのものになってしまうと、本質が抜け落ちてしまうこともある。メリットとリスクは表裏一体です。

実際、画面中心で進めたプロジェクトでは、途中から「あれ？この処理どこに出すんだっけ」といったブレが多々発生することがありました。

ユーザーとの認識合わせがしやすい利点

画面を見せながら話すと、ユーザーの理解度は格段に上がります。

紙の帳票やExcel管理に慣れている方には、「この項目がどこに出るのか」が一目でわかるほうが安心なんですよね。

また、「この機能って要りますか？」と聞くより、「このボタンは使いますか？」と見せた方が、会話が具体的になります。だから、ある程度のプロトタイプやUIイメージを使うのは有効な手段でもあります。

要件の抜け漏れが起きやすいパターン

ただし、見えている部分しか議論されないという落とし穴があります。画面に出ていない「非機能要件」や「例外フロー」は話題に上がりにくくなります。

たとえば、「画面には出てないけど、自動メール送信も必要だった」と後から判明する…というのはよくある話です。これは画面ベースで話を進めすぎた結果と言えます。

あとで仕様がブレる原因になりやすい

画面から要件を引き出していくと、開発が進んだあとで「そもそも業務的にこの設計で良かったのか？」と立ち返る場面が出てきます。こうなると、仕様変更の連鎖が起きやすくなり、結果として手戻りが増えてしまいます。

特に、UIだけに基づいてデータ構造まで決めてしまうと、拡張性や保守性に難が出る場合があります。そうした設計上の“つじつま合わせ”が後々の負債にならないように注意が必要です。

---

画面ありきで進めるときに設計側が主導権を持つには

現場では「もう画面ができてます」という状況が先に来ることも珍しくありません。そんなとき、「これで要件定義って成り立つの？」と不安になるかもしれません。

でも、画面から始めること自体は問題ではなく、“どう主導権を保って設計的に意味あるプロセスにしていくか”が重要です。

画面が先に出てきても、設計者が「何を整理すべきか」を持っていれば、ブレずに進めることができます。以下は私が意識をしているポイントです。

1. 業務フローを後づけでも構わないから、必ず描く

たとえUIから始まっても、「この画面は業務のどの場面か？」をセットで把握しないと、全体設計ができません。

画面ベースで進む場合でも、あとから業務フロー図を手で描いて紐づけるだけでも、設計の視点がぐっと明確になります。

このステップを挟むことで、「この画面だけで済む話じゃないのでは？」といった視点が持てるようになります。つまり、“画面に業務を引っ張らせない”ように設計側から補足するイメージです。

2. 画面ごとにユースケースを明文化して整理する

画面を起点にしても、「誰が、いつ、何のために使うのか」というユースケースを言語化すれば、見えてくる背景はかなり変わります。とくに、UIに出てこない部分──自動処理、例外系、通知など──はユースケースにしか出てきません。

以下のような簡易メモでも、考える道筋が整います。

flowchart TD
    A[営業担当] --> B[受注登録画面を開く]
    B --> C[得意先からの注文を入力]
    C --> D[納期を自動計算]
    D --> E[出荷予定表に反映]
    B --> F{顧客マスタあり？}
    F -- いいえ --> G[エラー表示：顧客未登録]
    F -- はい --> C

こういった整理があるだけで、「この画面、実はあと2処理足りないかも」といった気づきにつながります。

3. モックは“見せる道具”ではなく“設計の確認ツール”にする

UIが先に出たときでも、それを鵜呑みにせず、「設計視点での整合チェック」に使う意識があると強いです。

たとえば、画面だけ見て要件を語るのではなく、「この検索条件って業務で本当に必要？」「このボタン、他の画面と一貫性ある？」といった問いを挟むようにします。

モック自体は以下のように簡単な構成でも問題ありません。

　【画面名】受注一覧 　
・検索条件：受注日、顧客名 　
・一覧項目：受注番号、顧客名、受注日、ステータス 　
・操作：詳細、編集、削除 　

モックを“説明資料”としてではなく、“設計者が仕様を点検する道具”と見立てることで、ただの見た目合わせで終わらない要件整理ができます。

“画面の完成度”ではなく“要件の粒度”に目を向ける

ときどきあるのが、「この画面、よくできてるし、もう要件出たよね？」という空気。でも、画面の完成度と、要件定義の精度はまったく別の話です。

画面がきれいにできていても、「この処理、いつ起きる？」「どのデータをどう使う？」といった粒度で設計者が掘り下げないと、曖昧なまま開発に入ってしまいます。

だからこそ、「画面の体裁が整っているか」ではなく、「この画面がカバーしている要件は十分に定義されているか」を主軸に見るべきです。そこを意識するだけで、開発後の手戻りがぐっと減ります。

まとめ

画面先行で進む要件定義は、ユーザーとの会話を円滑にする一方で、本質的な業務要件を見落とすリスクもはらんでいます。

大切なのは「画面ありき」に流されず、設計者が業務フローやユースケースを丁寧に補足していく視点です。

私自身、このアプローチを意識してから、仕様ブレや手戻りが減った実感があります。

とはいえ、現場によって最適な進め方は異なるため、今回の内容も一つのヒントとして柔軟に活かしてもらえたらと思います。