非エンジニアこそプロダクトを作るべき理由——ドメイン知識がAI時代の最大の武器になる

ある社内ツールの開発プロジェクトで、エンジニアが設計したUIと、営業出身のメンバーがBolt.newで作ったUIを並べてユーザーテストした。結果、営業出身のメンバーが作った方が「使いやすい」と評価された。

技術的な完成度はエンジニアの方が上だった。でも、ユーザーの業務フローに沿った画面構成、よく使う機能の配置、入力項目の順序——すべてにおいて、営業メンバーの方が「顧客の言語」で設計できていた。

これは特殊な事例ではない。AIコーディングツールが技術的な壁を取り除いた今、プロダクト開発のルールが変わりつつある。

ボトルネックは「実装力」から「顧客理解」に移った

2025年からのAIコーディングツール——Bolt.new、Lovable、v0、Cursor、Claude Code——の進化は、プロダクト開発の前提を根本から変えた。プログラミング経験がほぼない人でも、自然言語で指示を出すだけで動くUIと基本機能を作れるようになった。

以前なら100〜200万円かかっていた「動くプロトタイプ」が、ツール費用月数千円と自分の時間だけで作れる。これは事実だ。

でも、プロダクトが成功するかどうかは「動くものが作れるか」で決まらない。**「正しい課題を、正しいユーザーのために解いているか」**で決まる。

ここで重要なのが、技術力はAIが補える一方、顧客理解はAIが補えないという非対称性だ。

経済産業省の調査によれば、AI活用プロジェクトの約7割が「業界や現場の知識不足」を理由に十分な効果を出せていない。技術は揃っている。足りないのはドメイン知識の方だ。

開発の制約条件が変わった。かつてのボトルネックは「コードが書けるか」だったが、今は「顧客を理解しているか」に移っている。

ドメイン知識がある人がUIを作ると何が起きるか

従来のプロダクト開発では、ビジネスサイドが要件を定義し、エンジニアがそれを実装するという分業が当然だった。この構造には、避けられない「伝言ゲーム」が存在する。

営業が「こういう画面がほしい」と言う。ディレクターがワイヤーフレームに落とす。エンジニアがコードに変換する。各ステップで「翻訳ロス」が発生する。

ドメイン知識がある人がAIツールで直接プロダクトを作ると、この伝言ゲームが消える。

Zennで話題になった記事では、業務を一番理解しているステークホルダー（非エンジニア）がAIを使って1週間でプロダクトを完成させ、品質でもスピードでもエンジニアに勝ったという事例が紹介されている。著者は「業務を深く理解している人がプロダクトを作ったほうが、認識の差異がなくなる」と結論づけた。

これは個別の事例ではなく、構造的な優位性だ。

tebiki社のテックブログでは、ドメイン知識がないチームがBtoBプロダクトを作った場合、ISO9001の変更履歴管理で「差分表示機能」を作ってしまった事例が紹介されている。実際にユーザーが必要としていたのは「いつ誰が更新したかのログ」だけだった。ドメイン知識があれば、最初から正しい機能を作れた。

顧客の言語でUIを設計できる人が作ると、3つのことが同時に起きる。

• 画面構成が業務フローに沿う——ユーザーが迷わない
• 入力項目が過不足ない——不要な機能を作らず、必要な機能を落とさない
• 用語が一致する——ユーザーの頭の中にある言葉がそのまま画面に出る

この3つが揃うと、プロダクトの精度は劇的に上がる。

非エンジニアが作った方がいいプロダクトの条件

とはいえ、すべてのプロダクトを非エンジニアが作るべきだとは言わない。向き不向きがある。

非エンジニアが作ると精度が高くなるケース：

• BtoB・業務特化型のプロダクト——会計、物流、医療、不動産、飲食店管理など、業務知識が深い領域。エンジニアがゼロから理解するよりも、当事者が直接作る方が圧倒的に速い
• 社内ツール——自分自身がユーザーである場合。日報管理、顧客リスト、在庫管理など。毎日使う人が作ったUIに勝てるエンジニアはいない
• 初期MVP——最初のユーザーフィードバックを得るフェーズ。完璧なコードより「正しい課題を解いているか」の検証が優先

エンジニアに任せた方がいいケース：

• リアルタイム処理やP2P通信が必要なアプリ
• 大規模トラフィックを前提としたインフラ設計
• 決済や個人情報の高度なセキュリティ要件

大事なのは、「何を作るか」を選ぶこと自体が、非エンジニアの強みだということだ。業務を知っている人は、どこにペインがあり、何を作れば解決するかの解像度が高い。AIツールの限界もわかった上でスコープを絞れる。これは要件定義そのものだ。

「作れる」と「公開できる」は別の話

ここで正直に書く。AIツールで作ったプロダクトをそのまま本番公開するのは危険だ。

AIが一貫して苦手な領域がある。

• セキュリティ設定——SupabaseのRLS（行レベルセキュリティ）を省略したり、全データが誰でも見られる設定を書いてしまう
• 認証・認可の適切な実装——ログインは動くが、権限管理に穴がある
• 本番インフラの構成——環境変数の管理、ステージング分離、スケーリング設定
• エラーハンドリング——正常系は動くが、異常系で白い画面が表示される（エラーメッセージの読み方を知っておくと対処しやすい）

AIツールでプロダクトの70%は作れる。残り30%——セキュリティ、インフラ、運用設計——が本番公開の壁になる。

この壁の存在を知った上で作り始めることが重要だ。「AIで全部できる」という前提で進めると、公開直前で詰まって数ヶ月止まることになる。

→ AI生成コードのリスクについてはAIが書いたコードのセキュリティリスクと対策で詳しく解説している

→ この「残り30%」が具体的に何かは「最後の30%」が本番公開を阻む理由と突破法にまとめている

非エンジニアがプロダクト開発を始めるための3ステップ

Step 1: 自分が一番詳しい業務課題を1つ選ぶ

「何を作ろう」ではなく、「自分が毎日感じている非効率は何か」から考える。営業なら顧客管理の手間。CSならFAQ対応の繰り返し。マーケターならレポート作成の時間。

自分がユーザーであり、かつドメインエキスパートである領域を選ぶ。これだけで、プロダクトの精度が担保される。

スコープは徹底的に小さくする。「全部の業務を改善する」ではなく「この1つの作業を半分にする」に絞る。

Step 2: AIコーディングツールでプロトタイプを作る

最初のツール選びで悩む必要はない。Bolt.newかLovableで始めるのがおすすめだ。自然言語で指示を出すだけでUIとデータベースが生成される。

大事なのは、最初から完璧を目指さないこと。まず「自分が使って便利か」を確かめる。自分が毎日使いたいと思えるなら、同じ業務をしている人も使いたいと思える確率が高い。

→ ツール選びの詳細はVibe Codingの始め方完全ガイドを参照

→ ノーコードとVibe Codingで迷っている方はノーコード vs Vibe Coding比較も参照

→ データベースの基礎を知りたい方は非エンジニア向けデータベース基礎が役に立つ

Step 3: 「動いた」あとの仕上げを専門家に任せる

プロトタイプが動いたら、本番公開に必要な「仕上げ」を専門家に依頼する。全部を外注するのではなく、AIが苦手な部分だけを依頼する。具体的にはセキュリティ設定、認証強化、本番インフラ構成、エラーハンドリングの追加だ。

この分業が成立すれば、開発会社にゼロから依頼する場合の1/3〜1/5のコストで本番公開できる。

→ エンジニアなしでSaaSを開発・公開するプロセスはエンジニアなしでSaaSが作れる時代に「あとしまつ」が必要な理由で解説している

→ エンジニアと協業する場合のコツはエンジニアとの上手な付き合い方にまとめている

エンジニアは不要になるのか？——役割の再定義

この話は「エンジニア不要論」ではない。むしろ逆だ。

AIがコードを書く時代に、エンジニアの価値は「コードを書けること」から**「コードの正しさを担保できること」**にシフトする。セキュリティレビュー、アーキテクチャ設計、パフォーマンス最適化、運用設計——これらは今後もエンジニアにしかできない仕事だ。

つまり、「作る人」と「仕上げる人」の分業が合理的になる。

ドメイン知識がある人がプロダクトの形を作り、エンジニアがそれを本番品質に仕上げる。ドメイン駆動設計（DDD）の世界では、ドメインエキスパートとエンジニアの協働がベストプラクティスとされてきた。AIツールの登場で、この協働の形がより現実的になった。

非エンジニアは「作れない人」ではなくなった。エンジニアは「書くだけの人」ではなくなった。両者の役割が再定義された結果、プロダクト開発はより顧客に近い場所から始められるようになった。

あなたの業務知識は、そのままプロダクトの競争優位になる。

→ プロトタイプは作れた。次のステップが見えない方は「最後の30%」が本番公開を阻む理由と突破法へ