カミナシでエンジニアをしている osuzu です。
この半年、Claude Codeを利用しながらプロダクトディスカバリに参加する業務を中心に行ってきました。
カミナシは現場ドリブンというValue（行動指針）を大切にしていますが、私もエンジニアながら今月(2025年10月)だけで月6件の現場訪問に参加予定です！
AIの進化が激しい現代に、エンジニアとしてがっつりプロダクトディスカバリに参加する経験を得られたため、そこから得られた学びについて共有させてください。
プロダクトディスカバリってそもそも何？
書籍『INSPIRED』の中では、プロダクトディスカバリの目的を「良いアイデアと悪いアイデアをすばやく切り離すこと」であり、「その成果は、検証されたプロダクトバックログである」と定義しています。
著者のCaganさんは、成功する製品ディスカバリーのために、製品チームが以下の4つの重要な問いに答えることを推奨しています。
- 価値: そのアイデアはお客様にとってお金を払うに値するほど価値のあるものか？
- ユーザビリティ: 顧客が使い方を理解でき業務の中に取り入れられるか？
- 実現可能性: エンジニアリングチームがそれを実現できるか？
- 事業実現性: ビジネス目標の推進力となるか？
私自身が考える「良いプロダクトディスカバリ」とは以下の感覚をチーム全体で共有し、迅速に学習しながらプロダクトバックログを作成していくことだと考えています。
- 「これは売れる！」という確信をもつこと
- 「これは使ってもらえるし、サクセスできる！」という自信を持つこと
- 技術的な難しさを持つ場所の特定や実現までのロードマップの明確化
- 「これは売れる」「これは使ってもらえる」という感覚や熱意を、SalesやCSや経営層に伝えられていること
エンジニアがプロダクトディスカバリに参加することは難しい？
プロダクトマネジメントという言葉が一般的になった頃から、ユーザビリティや実現可能性のリスクを踏まえたプロダクトバックログを作っていくためにも、エンジニアがプロダクトディスカバリに参加した方が良いという共通認識はありました。
ただし私自身も複数のスタートアップで働きSaaSを開発する中で、現実には以下のような難しさがあったと考えています。
- エンジニアは仕事のリードタイムやライフサイクルがPMやデザイナーとズレやすく、一部の手がとても早いエンジニア以外はディスカバリに参加しづらい部分があった。 そのためこれまではFigmaなどで紙芝居のようなプロトが作られ、それだけでヒアリングを済ますことは一般的だった。
- 価値のリスクを判断すること（本当にお金を払ってまで使いたいものか）は特にVerticalなSaaSにおいて、エンジニアやプロダクトチームには判断が難しかった。
- エンジニアとして参加してもミニデザイナーやミニPMとしての動きが求められ、通常の開発の延長線上とはまた別のスキルが必要だった。
プロダクトディスカバリの世界に起きている異変
私は前職でもプロダクトディスカバリの経験がありますが、この半年活動してみて大きな変化が起きていると感じました。
異変①: プロトタイピングの高速化
エンジニアがディスカバリに参加する上での課題の一つに、PdMやデザイナーとの仕事のリードタイムのズレがありました。
しかし、AIの活用により、プロトタイピングの速度は劇的に向上しました。例えば、私が関わったプロジェクトでは、自分自身フロントエンドが得意な方のエンジニアだと思っていますが、それでもプロトタイプのクオリティで1週間はかかるだろうなというフロントエンドの機能が3時間程度で完成します。
プロダクションクオリティではなく、プロトタイプのクオリティで良い（メンテしなくて良い）というディスカバリフェーズとの相性の良さもあります。
※ 補足 v0やFigma Makeなどのツールも出てきていますが、プロトタイピングであっても、複雑なDB設計であったり状態を持つSPAの場合、まだ専門職以外難しいと感じます。
ドメインモデリングやドメインロジックや依存関係のルールなど重要な部分の設計は人間が手綱を持ち、それ以外の部分でVibeするバランス感覚が、今までもこれからも重要だなと感じています。
AIが自由に走れるための道を用意してあげるというか。そこまでしてもコンポーネントがuseEffectで溢れて悲しくなることもありますが、拘りすぎないこともまたプロトタイピングでは重要でした笑
異変②: 職能の越境しやすさ
AIツールは、専門外の領域へのアクセスを容易にし、チームメンバー間の越境を促進しています 。例えば、デザイナーやPMがFigma Makeで動くプロトタイプを作成することは、私のチームでは日常になってます。
またエンジニアが、プロト用にデザイナーがざっくり作った大枠のUIデザインを補完しながら実装を進めるといったことも、特にデザインの専門知識がなくても可能になってきました。
これにより、仕様書や要件定義書がない状態（何を作るかをこれから考えていく状態）でも、チームで同期を取りながら迅速に意思決定を下し、学習サイクルを回すことが可能になっています。
包括的なドキュメントよりも動くソフトウェアとはアジャイルマニフェストの言葉ですが、現代ではまた違った意味で捉えられるなと感じます。
異変③: "AI体験"の重要性の高まり
顧客の期待値としてもAIがプロダクトに組み込まれるのが当たり前になりつつある今、価値のリスク（顧客がお金を払ってまで使いたいか）を検証する方法も変化していると感じました。
従来はFigmaなどで作成した静的なプロトタイプ（紙芝居）でも価値検証は可能としてきた組織も多いと思いますが、AIプロダクトの品質、特に「AIが生成したものが顧客の業務で本当に使えるか」という点は、実際に動くものでなければ伝わりません。
私も最近商談やカスタマーサクセスの文脈で現場訪問させて頂く機会が多いですが、顧客の実際のデータを使ってデモを見せることが圧倒的にWowの反応が大きいです。
異変のまとめ
プロダクトディスカバリにエンジニアを参加させることの難しさ（リードタイムの長さや他職能のスキルが必要なこと）は多くがAIによって解消されつつあります。
一方でプロダクションの難易度やリスクはAIでもまだ減っていません。むしろAgentやRAGを構築する場合、LLMOpsも含めるとプロダクションの難易度は上がっていたりします。
またユーザビリティのリスクにおいても、AI時代では新しく直面する課題がむしろ増えているでしょう。
そんな時代にエンジニアがプロダクトディスカバリに参加することは、これまでよりもリスクが少ない状態なのに関わらず、これまでより大きな価値を持ちます。
PMやBizDevだけで事業を検証し、エンジニアにウォーターフォールするような働き方をしているなら、それはすぐにでも見直したほうが良いと私は考えています。
最後に: エンジニアがディスカバリに参加してよかったこと
エンジニアとしてディスカバリに参加して個人的に良かったことを紹介させてください。
良かったこと①: さまざまな技術を試せる
普段の業務では運用負荷などを考えて躊躇してしまうような新しい技術も、ディスカバリの期間中であればカジュアルに試すことができます。
私自身も、ベクトル検索の運用検討から、LangChain(LangGraph, Langfuse)の導入、各種AIベンダーのAPIの組み込み可能性の調査、これまでとは違うフロントエンドの状態管理（jotaiをLocalDBに永続化しつつパフォーマンス良いフォームにする、Tanstack DBでローカルファーストなフォームを作る）など多岐にわたる技術を試す機会に恵まれました。
良かったこと②: ディスカバリとデリバリを接続する
ディスカバリを通じてユーザビリティや実現可能性のリスクを事前に検証することで、確度の高いロードマップとプロダクトバックログを作成できます。
さらに、AI時代においては一度プロトタイプとして実装してみることで、デリバリーの際には「実質的なやり直し」として、より洗練された設計・実装が可能になります。
エンジニアリングは今までもこれからも、設計と実装が不可分というかお互いを行ったり来たりしながら作る面があり、一度作ってみることで役に立つことが本当に多いです。
また、エンジニア自身がディスカバリに参加することで「これは売れる」という強い想いを持つことが出来ますし、その中で開発のどの部分に時間をかけるべきか、なぜこの機能が必要なのかといった「Why」の解像度が高まり、将来の機能のあり方も踏まえて、設計やモデリングの質を向上させると感じました。
良かったこと③: 自身が今この場で働いてる意味を再認識する
最後に、私がなぜカミナシで仕事をしているのかを再認識したエピソードをお話しさせてください。
私はいまカミナシ 教育という企業向けの教育管理やマニュアル作成の為のプロダクト開発に携わっています。
先日ディスカバリの一環として某社を訪問しました。そこでは海外からの技能実習生を受け入れていますが、その中では珍しく（これがどれほど凄いことかは伝わりづらいかもしれませんが）業務の中の教育マニュアルを外国人従業員の方が作成されています。
私も（おそらく皆さんも）転職や就職した初期に仕事の中でクイックウィンやライトサクセスがあるとその後会社でどれだけ働きやすくなるか、エンゲージメントに繋がるかは実感されてると思います。
海外の方が日本に来て職場に馴染んでもらったり、また広く言うとその後日本で楽しく暮らしてもらうためにも、教育マニュアルはとても大切だと私は考えています。
その活躍できるための研修マニュアルを外国人従業員の方自らが作成し、あらゆる国籍の新入社員の人が働きやすい環境を作っていました。
その姿を見て、私は感動し本当に役に立つプロダクトを届けたいと思いましたし、現場で今の業務を少しでも改善しようと努力する人が報われる社会を目指したいと感じました。
エンジニアが現場に足を運び、顧客の課題に直接触れること。それこそが、本当に役に立つプロダクトを生み出す原動力になるのだと感じる日々です。
[宣伝]
私の所属するチームでエンジニアを募集しています。
現場でプロダクトディスカバリしていきたい、AIで現場を良くしていきたい、そんな皆さまのお力をお貸しください。
