AIで「イケてるプロダクト」を作るために、エンジニアが出来ること

note / 5/2/2026

💬 OpinionIdeas & Deep AnalysisTools & Practical Usage

Key Points

  • エンジニアがAIを活用して「イケてるプロダクト」を作るには、モデル性能だけでなくユーザー体験(価値の出し方)を起点に設計することが重要だと述べている。
  • 成果を出すために、要件定義〜データ/評価〜実装〜運用までを見通した開発プロセス(学習・改善のループ)を意識する必要がある。
  • 実際のプロダクトでは、精度だけでなくコスト、レイテンシ、安定性などの制約を踏まえた意思決定(適切なモデル/構成の選定)が求められる。
  • エンジニアが担うべきこととして、プロンプトやプロダクト仕様の設計、品質評価の仕組み化、継続的な改善に関する実務が挙げられている。
見出し画像

AIで「イケてるプロダクト」を作るために、エンジニアが出来ること

41
Moriya Hiroyuki

株式会社IVRyでAIエンジニア/technical PdMとして働いているMoriyaです。

コーディングエージェントはめちゃくちゃ便利だな〜と思っています。コーディングエージェントによって、コードを書くスピードは上がりました。
一方で、イケてるプロダクトの出現頻度は変わってないと感じています。むしろ、リリース総数が増えている分、その中でイケてるプロダクトが占める割合は下がっているのではないか、とすら感じます。
「コーディングエージェントに投資しているのに、うちの会社は良いプロダクトがリリースされないじゃないか!」と感じる方もいるのではないでしょうか?

この記事ではそんな『コーディングエージェントに投資したのに、イケてるプロダクトがリリースされない問題』への対処法をまとめてみました。

1. イケてないプロダクトは、なぜ作られてしまうのか?

「イケてない = リリースされたけど誰にも使ってもらえない」プロダクトはなぜ生まれてしまうのでしょうか?
一言で言えば、「イシュー = 解決したい課題」が曖昧だからです。特にtoBサービスにおいては、「クライアント = 現場」に答えが落ちています。なので、商談に同席しているセールスの方に聞けば、課題が分かります。しかし、組織が大きくなると、エンジニア / PdMが直接クライアントの声を聞く機会は減っていきます。
例えば、「セールス => セールスマネージャー => PdMマネージャー => PdM => エンジニアチーム」のような伝言ゲームをしたら、「イシュー = 解決したい課題」は段々と違った形に変わってしまうでしょう。
そうすると、「歪んでしまった課題を解決するプロダクトを作る」「現場主導でプロダクトを作ってしまう」ということが発生します。その結果、「何を解決するのかわからない新規プロダクト」が生み出されます。

2. なぜコーディングエージェントを使っても、イケてるプロダクトが作られないのか?

では、なぜコーディングエージェントが現れても、「イケてるプロダクト」はつくれないのでしょうか?

イケてるプロダクトが作れないのは、コーディングスピードの問題ではなく、「イシュー = 解決したい課題」が曖昧なまま開発しているからです。そのため、コーディングスピードが改善したとしても、イケてるプロダクトが生まれる確率は変わりません。
「イシュー = 解決したい課題」が曖昧なまま作ったプロダクトがイケてる確率が1%だとします。リリース数が多少増えたところで、1%を改善しない限り、イケてるプロダクトを作ることはできないでしょう。
つまり、イケてるプロダクトを作れない理由が「情報伝達経路」「プロダクト開発のスタイル」にあるのであれば、コーディングスピードを多少上げてもイケてるプロダクトは作れません。

3. コーディングエージェントを活かして、イケてるプロダクトを作るには、どうすればいいのか?

幸いなことに、コーディングエージェントのおかげで、エンジニアの生産性が改善しました。生産性が改善して生まれた余剰時間を「コーディング」に使うのをやめて、「イシュー = 解決したい課題」の解像度を上げることに時間を使いましょう。

例えば、セールスの人たちとエンジニア・PdMが直接議論する時間を作ったり、エンジニア・PdMが商談同席してクライアントの生の声を聞く、といったことをすれば、「イシュー = 解決したい課題」の解像度が上がって、クライアントに必要なプロダクトは何なのか?を考えやすくなるでしょう。
実際、私自身も商談同席するようになって「イシュー = 解決したい課題」の解像度がかなり上がったように感じています。

マネジメント・経営陣観点で言えば、組織構造を作り変える必要が出てくるのだろうと感じています。中長期的には、AIエージェントによって組織コミュニケーションスタイルが大幅に変わるでしょう。Jack Dorseyの記事にも書いてありましたが、プロダクトも組織もAIを中心に再編されていくことが予想されます。

4. 商談同席するようになって良かったこと

私が商談同席するようになって良かったことを列挙します。

一次情報から仕様を設計できる

商談同席に出て、自分で一次情報を取りに行くと、課題が腹落ちした状態で実装に入れます。「この課題を解決するだけなら、もっと最小の実装で十分です」という建設的な提案もしやすくなり、無駄な開発を削れます。また、ユーザー課題を自分の言葉で語れるようになるので、他のエンジニアに実装の意図を説明するときの解像度がまったく変わってきます。

期待値調整ができる

エンジニアが商談に出ないと、本来は実現が難しいことに対して「できます」と言ってしまうリスクがあります。悪気があるわけではなく、単に技術的な制約が現場まで届いていないだけなのですが、後工程でしわ寄せが来ます。コーディングエージェントがあれば作れるのでは?と思われることもありますが、現実的に作ることができないものは、コーディングエージェントでも作れません。自分自身が商談に同席していれば、「何が実現可能で、何が実現不可能なのか」をクライアントと直接コミュニケーションできます。

セールスとの共通言語ができる

商談に同席すると、セールスの人たちが普段見ている世界の解像度が上がります。プロダクトを作るために必要な情報は、仕様書やドキュメントだけでなく、セールスの人の頭の中、顧客とのやり取りの行間、ふとした立ち話の中に分散して存在しています。商談同席は、そこへの接続点を増やす行為です。心理的距離が近づくことで、以前よりもセールスから情報が流れてくるようになった実感もあります。

まとめ

最後まで読んでいただき、ありがとうございました。
商談に同席しながら自分でプロダクトを作ることに興味がある方がいれば、ぜひカジュアル面談にご応募ください。お待ちしています。


ダウンロード
copy

いいなと思ったら応援しよう!

チップで応援する

この記事が参加している募集

41