生成AI時代のシステム開発｜画面を先に作るべきか、機能を先に作るべきか
山崎講師こんにちは。ゆうせいです。
新人研修中に受講者から以下の質問をいただきました。
生成AIを使った開発においては画面と機能どちらから作り始めるべきでしょうか？
今回はこの質問の答えたいと思います。
最近は、ログイン画面、一覧画面、入力フォーム、管理画面のようなUIを生成AIに作ってもらいやすくなっています。
UIとは、ユーザーインターフェースの略です。
ユーザーインターフェースとは、利用者がシステムを操作するための見た目や操作部分のことです。ボタン、入力欄、メニュー、一覧表などがUIです。
たとえるなら、レストランのメニュー表や注文タブレットのようなものです。
厨房の中でどれだけおいしい料理を作れても、お客さんが注文しにくければ困りますよね。システムも同じで、機能が優れていても、画面が使いにくければ価値が伝わりません。
では、生成AI時代の開発では、画面を先に作るべきなのでしょうか。
それとも、機能を先に作ってから、生成AIで画面を作るべきなのでしょうか。
結論から言うと、「どちらか一方を必ず先にする」ではなく、最初にユーザーの流れを決めて、小さく画面と機能をつなげて作るのが一番おすすめです。
つまり、画面だけ先に全部作るのでもなく、機能だけ先に全部作るのでもありません。
小さな単位で、画面と機能をセットで作る。
この考え方が大切です。
画面を先に作る開発とは何か
画面を先に作る開発とは、まずユーザーが見る画面を作り、その後に裏側の処理を作っていく進め方です。
たとえば、車を管理するシステムを作るとします。
最初に次のような画面を作ります。
| 画面 | 内容 |
|---|---|
| 車一覧画面 | 登録されている車を一覧表示する |
| 車登録画面 | 車名や価格を入力する |
| 車詳細画面 | 1台の車の情報を見る |
| 車編集画面 | 登録済みの車情報を変更する |
画面を先に作ると、完成イメージが早く見えます。
「この入力欄は必要だね」
「価格で検索したいね」
「削除ボタンは一覧にもほしいね」
このような会話がしやすくなります。
家づくりでたとえるなら、間取り図や完成イメージを先に見るようなものです。
「ここにリビングがあるなら、キッチンは近いほうがいいね」と話しやすくなりますよね。
画面先行のメリット
画面を先に作るメリットは、利用者目線で考えやすいことです。
エンジニアは、どうしてもデータベースやAPIから考えがちです。
APIとは、アプリケーション同士がデータをやり取りするための窓口です。
たとえば、画面から「車一覧をください」とAPIにお願いすると、サーバーが車のデータを返します。
画面を先に見ると、「このAPIでは何を返すべきか」が考えやすくなります。
たとえば、車一覧画面に表示する項目が次の4つなら、
車ID
車名
価格
削除日時
APIもそれに合わせてデータを返せばよいとわかります。
画面先行のメリットを整理すると、次のようになります。
| メリット | 内容 |
|---|---|
| 完成イメージが早く見える | 利用者やチームと認識を合わせやすい |
| 必要な項目が見つかりやすい | 入力欄や表示項目から仕様を考えられる |
| 操作の流れを確認しやすい | ユーザーが迷わないか検討できる |
| 生成AIと相性がよい | 画面のたたき台を素早く作れる |
特に新人エンジニアの場合、画面から入ると「何を作っているのか」が見えやすくなります。
これは大きなメリットです。
画面先行のデメリット
一方で、画面を先に作ると危ない場面もあります。
見た目だけ完成して、裏側の処理が追いつかないことがあります。
たとえるなら、レストランのメニュー表だけ立派に作ったのに、厨房には材料も調理器具もない状態です。
お客さんから見ると期待してしまいますよね。
でも、実際には注文できません。
システム開発でも同じです。
画面だけ先に作りすぎると、次のような問題が起きます。
| 問題 | 内容 |
|---|---|
| 見た目だけ完成する | 実際には保存や検索ができない |
| 仕様変更が多くなる | 裏側の制約を考えずに画面を作ってしまう |
| データ構造と合わない | 画面項目とDB項目がずれる |
| AI生成コードが増えすぎる | 理解しないまま画面コードだけ増える |
生成AIで画面を作ると、見た目の完成がとても早いです。
だからこそ、「動いていないのに完成した気分になる」という落とし穴があります。
ここは本当に注意してください！
機能を先に作る開発とは何か
機能を先に作る開発とは、画面よりも先に、データベース、業務ロジック、APIなどを作る進め方です。
業務ロジックとは、そのシステム特有のルールを処理する部分です。
たとえば、車管理システムなら次のようなルールです。
価格は0円未満にできない
削除済みの車は一覧に表示しない
同じ車名を登録できるかどうか決める
更新時には存在する車IDか確認する
業務ロジックは、システムの中身そのものです。
車でたとえるなら、エンジンやブレーキのような部分です。
外からは見えにくいですが、ここが弱いと安全に走れません。
機能先行のメリット
機能を先に作るメリットは、システムの土台が安定しやすいことです。
たとえば、先に次のようなAPIを作ります。
車を登録する
車を検索する
車を更新する
車を削除する
その後、画面からAPIを呼び出せば、見た目を変えても機能は使い回せます。
スマホ画面でも、管理画面でも、同じAPIを使える場合があります。
機能先行のメリットを整理しましょう。
| メリット | 内容 |
|---|---|
| 土台が安定しやすい | データ構造やルールを先に固められる |
| テストしやすい | 画面なしでもAPI単体で確認できる |
| 再利用しやすい | 複数の画面から同じ機能を使える |
| 複雑な処理に強い | 業務ルールを丁寧に作り込める |
特に、お金、在庫、権限、予約、契約のような重要な処理では、機能を雑に作ると大きな問題になります。
見た目よりも先に、正しく動くことを確認すべきです。
機能先行のデメリット
ただし、機能を先に作る開発にもデメリットがあります。
一番大きいのは、利用者目線からズレやすいことです。
エンジニアだけでAPIやDBを作っていると、「技術的には正しいけれど、画面から使いにくい」設計になる場合があります。
たとえるなら、厨房の効率だけを考えて料理を作った結果、お客さんが注文しにくいメニューになってしまうようなものです。
機能先行のデメリットは次の通りです。
| 問題 | 内容 |
|---|---|
| 完成イメージが見えにくい | 利用者や上司に伝わりにくい |
| 画面に合わないAPIになる | 実際の操作に必要なデータが足りない |
| 手戻りが起きる | 画面を作る段階で設計変更が発生する |
| 新人には全体像が見えにくい | 何のための処理か理解しづらい |
機能だけを先に作りすぎると、「誰が、いつ、どの画面で使うのか」がぼやけることがあります。
生成AIで画面を作れるなら、機能先行でよいのか
ここが今回の質問の核心ですね。
「画面は生成AIで後から作れるなら、機能を先に作ればよいのでは？」
答えは、半分正解で、半分注意が必要です。
たしかに、生成AIは画面のたたき台を作るのが得意です。
HTML、CSS、React、Vueなどの画面コードを素早く作れます。
しかし、生成AIは「利用者が本当に何に困っているか」までは自動で完全に理解してくれません。
また、業務ルールの細かい事情も、きちんと伝えなければ反映できません。
たとえば、車の価格入力欄をAIに作らせるとします。
見た目はきれいな入力フォームができます。
でも、次のようなルールはどうでしょうか。
価格は税込みか税抜きか
0円の車を登録してよいか
小数を許可するか
上限金額はあるか
値引き前価格と販売価格を分けるか
削除済みの車を再登録できるか
こうしたルールは、単に画面を生成するだけでは決まりません。
人間が業務を理解して、仕様として決める必要があります。
生成AIは、優秀なアシスタントです。
でも、プロダクトの責任者ではありません。
電卓があるからといって、何を計算すべきかまで電卓が決めてくれるわけではありませんよね。
生成AIも同じです。
おすすめは「小さな縦切り開発」
では、どう進めるのがよいのでしょうか。
おすすめは、小さな縦切り開発です。
縦切り開発とは、画面、API、業務ロジック、データベースを小さな機能単位でまとめて作る方法です。
たとえば、車管理システムなら、まず「車一覧を見る」だけを作ります。
その中で、次の範囲を小さくつなげます。
| 層 | 作るもの |
|---|---|
| 画面 | 車一覧画面 |
| API | 車一覧取得API |
| 業務ロジック | 削除済みを除外する処理 |
| データベース | carsテーブルから取得するSQL |
このように、上から下まで細く一本通します。
太い道路を一気に作るのではなく、まず細い道を1本通すイメージです。
道が通れば、人が歩けます。
その後に道幅を広げたり、信号をつけたり、舗装をきれいにしたりできます。
システム開発も同じです。
最初から全画面、全API、全DB設計を完璧に作ろうとしないでください。
まずは小さく動くものを作る。
ここがとても大切です！
実務でおすすめの順番
新人エンジニアには、次の順番がおすすめです。
| 手順 | 内容 |
|---|---|
| 1 | ユーザーが何をしたいかを文章で書く |
| 2 | 画面のラフ案を作る |
| 3 | 必要なデータ項目を洗い出す |
| 4 | DBとAPIを小さく設計する |
| 5 | 1機能だけ画面とAPIをつなげる |
| 6 | 動かしながら改善する |
最初にいきなり画面コードを書かないでください。
また、いきなりDB設計だけにこもるのも避けたほうがよいです。
まずは、利用者の行動を言葉にしましょう。
たとえば、
利用者は車の一覧を見たい
利用者は車名で検索したい
利用者は価格を見て比較したい
管理者は不要な車データを削除したい
このように書くと、画面と機能の両方が見えてきます。
この利用者の行動を、ユースケースと呼びます。
ユースケースとは、利用者がシステムを使って達成したい目的や操作の流れです。
料理でいうと、「カレーを作るために、材料を切って、炒めて、煮込む」という一連の流れに近いです。
材料だけ見ても料理はわかりません。
完成写真だけ見ても作り方はわかりません。
流れを見ることで、必要なものがわかります。
画面を先に作ったほうがよい場面
すべての場面で同じ進め方がよいわけではありません。
画面を先に作ったほうがよい場面もあります。
| 場面 | 理由 |
|---|---|
| 要件があいまい | 画面を見ながら会話すると仕様が決まりやすい |
| 利用者の操作性が重要 | 使いやすさを早めに確認できる |
| デザインの合意が必要 | 関係者と完成イメージを共有しやすい |
| 新規サービスの検証 | 需要があるか早く試せる |
たとえば、新しい予約サービスを作る場合、いきなり裏側を作り込むより、予約画面のたたき台を見せたほうが話が進みやすいです。
「このボタン名だとわかりにくい」
「日付選択はカレンダー形式がいい」
「スマホで片手操作できるようにしたい」
このような意見は、画面があると出やすくなります。
この段階では、生成AIがかなり役立ちます。
画面のたたき台を素早く作り、会話の材料にできるからです。
ただし、たたき台はたたき台です。
そのまま本番コードにする前に、設計、セキュリティ、保守性を確認してください。
機能を先に作ったほうがよい場面
逆に、機能を先に作ったほうがよい場面もあります。
| 場面 | 理由 |
|---|---|
| 業務ルールが複雑 | 先に正しい処理を固める必要がある |
| データの整合性が重要 | 間違った保存や更新を防ぐ必要がある |
| 外部システム連携がある | 接続やデータ形式の確認が先に必要 |
| セキュリティが重要 | 認証や権限を先に設計するべき |
たとえば、決済システム、勤怠管理、在庫管理、医療情報、契約管理などは、見た目よりも正確性が重要です。
ボタンがきれいでも、金額計算が間違っていたら大問題ですよね。
このような場合は、まず業務ロジックやデータの扱いを丁寧に確認してください。
生成AIで画面を作るのは、その後でも構いません。
新人エンジニアがやりがちな失敗
新人エンジニアが生成AIを使うとき、特に注意したい失敗があります。
それは、生成AIが出したコードを理解しないまま貼り付けることです。
画面はすぐに動くかもしれません。
でも、なぜその構造なのか、どこでAPIを呼ぶのか、エラー時にどうなるのかを理解していないと、修正できなくなります。
たとえるなら、友達に数学の宿題を全部解いてもらったけれど、テストでは自分で解けない状態です。
開発では、あとから必ず変更が入ります。
そのときに理解していないコードは、借金のように重くなります。
このような状態を技術的負債と呼びます。
技術的負債とは、短期的に楽をした結果、後から修正や保守が大変になる状態のことです。
借金と同じで、最初は助かります。
でも、放っておくと利息のように負担が増えます。
生成AIを使うなら、「作ってもらう」だけでなく、「説明させる」「分解させる」「改善案を出させる」使い方をしてください。
結論
生成AIでシステム開発をする時代でも、画面だけを先に作ればよいわけではありません。
また、機能だけを先に作って、画面は全部AIに任せればよいわけでもありません。
大事なのは、ユーザーが何をしたいのかを先に決めることです。
そのうえで、画面と機能を小さくつなげて作ります。
おすすめの考え方は、次の通りです。
| 状況 | おすすめ |
|---|---|
| 要件があいまい | 画面のたたき台を先に作る |
| 業務ルールが複雑 | 機能やデータ設計を先に固める |
| 新人が学習中 | 小さな縦切り開発で進める |
| 生成AIを使う場合 | 画面生成だけでなく設計確認にも使う |
一言でまとめるなら、こうです。
画面先行か機能先行かで悩むより、ユーザーの目的を中心にして、小さく動く単位で作れ！
生成AIは、開発を速くしてくれる道具です。
しかし、何を作るべきか、どの順番で作るべきか、どの品質まで上げるべきかは、人間が考える必要があります。
新人エンジニアのうちは、まず「車一覧を見る」のような小さな機能を選び、画面、API、DB、処理を一本につなげてください。
今後の学習では、ユースケース、UI設計、API設計、データベース設計、テスト設計の順番で学ぶと、生成AIを使っても振り回されにくくなります。生成AIに画面を作らせる前に、「誰が、何のために、その画面を使うのか」を言葉にする習慣を身につけていきましょう！
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール
