はじめに
カミナシで新規プロダクトの開発をしているShimmy(@naoya7076)です。
現在、新規プロダクトをプロトタイプとして開発しており、顧客に提供しながらフィードバックを得ています。Claude Codeをはじめ、開発の全工程でAIを活用しており、開発アイテムは予定以上のスピードで実装できています。
「AIでコーディングが速くなった。ではその空いた時間で何をやるのか？」
この問いに対して、自分が新規プロダクト開発で実践してきたことを書きます。
「もっと作る」はアンチパターン
AIで実装速度が上がると、「もっと作ろう」という方向に引っ張られがちです。しかし、むやみに作るものを増やすのはアンチパターンです。理由は2つあります。
コードの意図の希薄化
AIによってコードを爆速で書けるようになりましたが、それを続けていると人の理解を超えた「意図が希薄なコード」が増えてしまいます。プロトタイプは本番プロダクトの土台であると同時に、顧客のドメイン理解の記録でもあります。なぜそのコードが存在するのかを読み取れなければ、プロダクションに活かせるドメインを発見することや、フィードバックを本番コードに活かすことが難しくなり、その両方の機能を失ってしまいます。
作るコスト <<< 取り下げるコスト
作るのが簡単になった一方、リリースしたものを取り下げるコストは変わらず高いままです。B2Bではこれがより深刻で、ほとんど使われていない機能でも、一社でもその機能で業務を回していれば取り下げコストは大きくなります。特にカミナシのお客様は製造業の現場であり、会社ごとに業務フローの差異が大きく、プロダクトが業務に深く食い込むためこの非対称性はさらに大きいです。「何を作るか」の精度を上げないまま作る量を増やすと、メンテナンスコストだけが積み上がります。
AIで空いた時間は何に使うか
AIで空いた時間は、新機能を増やすのではなく
- 何をどこまで作るかの精度
- 作ったものが「顧客に届くまで」の速度
を上げることに使うべきだと考えています。コーディングだけが速くなっても、顧客検証まで含めた開発フロー全体に詰まりがあれば、顧客に価値が届くスピードは変わりません。速さを価値のスループットに変えるには、ボトルネックをコーディングから段階的に遠いところへ広げ、顧客に価値が届くまでの全体として捉える必要があります。
ボトルネックを追う
自分が実践してきたことは、次のステップの繰り返しです。
- ボトルネックを見つける — コーディングが速くなった今、ボトルネックはコーディング以外にある
- スケールしないところに自ら入る — 入ることで初めて、何がボトルネックで何がスケールの余地なのかがわかる
- 得た知見をプロダクトに還元し、スケールできるところは技術で解決する
ここからは、コーディングから始まり、徐々に遠いところへボトルネックを追っていった流れを話します。
コードレビューのボトルネックを解消する
AIでコーディングが速くなった後、最初に直面したのはコードレビューのボトルネックでした。
Claude Codeで実装速度が上がった結果、コードのフィードバックやレビューが追いつかなくなりました。1人エンジニアの体制なので、レビュアーは自分自身とチームメンバーです。AIが書いたコードの品質担保が課題になっていました。
AIが生成したコードをレビューしてみると、指摘点が多く、レビュー自体に想定以上の時間がかかっていました。そこで、静的解析やAIレビューを導入し、コードレビューの負荷を下げました。設計ルールをdependency-cruiserなどで機械的に強制し、AIが生成したコードの品質をプロセスで担保する仕組みを作りました。詳しくは以下のブログに書いてます。
kaminashi-developer.hatenablog.jp
顧客理解のボトルネックを解消する
コードレビューのボトルネック解消と合わせて、次に顧客理解のボトルネックに取り組みました。
私(エンジニア)やデザイナーが後からチームに入ったため、顧客やプロダクトについての知識がありませんでした。「なぜこの機能を作りたいのか」「顧客がどういう仕事をしているのか」がわからず、詰め切れていないところを都度他の人に聞く必要がある。顧客理解の薄さが、コミュニケーションコストと判断の詰まりとして現れていました。
そこで私やPM、デザイナーなど含めて顧客訪問やヒアリングに自ら行きました。多い時には週1〜2回ペースで訪問しました。
補足
カミナシには「現場ドリブン」というカルチャーがあり、プロダクト開発に関わる人も積極的にお客様の現場に行く土壌があります。昨年は会社全体で3900回訪問しました。
エンジニアが現場に行く意味
「AIで二次情報はいくらでも取れるようになった今、差別化できるのは現場でしか取れない一次情報です。」
PMやセールスを通じた伝聞では、情報は「要望」や「課題」として整理された形で届きますが、大事なのはその裏にある背景です。なぜその機能が欲しいのか、どんな業務でどんな事情があって出てきた声なのか。綺麗に整理された要望から背景を組み立て直すのは難しいので、エンジニア自身が現場で「なぜ」を聞いてはじめて、複数の要望を抽象化したり、もっとシンプルに実現できると判断できるようになります。
実際に新規プロダクト開発チームでヒアリングに行ったことで、顧客ごとに異なるプロダクトの重要な値が、実は設定値の組み合わせで表現できるとわかりました。その定義を体系化し、ドメイン知識の勉強会を行ったことで、チーム全体の資産にできました
顧客検証に開発を従属させる
顧客理解が進んで開発が動き出すと、次に見えてきたのは顧客検証そのものがボトルネックだということでした。
たくさん作っても、お客様にヒアリングできるのは一部です。検証のタイミングや範囲には上限がある一方、開発はAIで速く動く。全体のスループットは顧客検証で決まるため、開発をそれより速く動かしても、仕掛かり品のように検証されない機能が溜まるだけです。そこで顧客検証に開発を従属させるため、次の2つを組み合わせました。
1. 作るものを、検証で聞くべきことに絞る
限られた検証機会は「正解がわからず、お客様に聞かないと判断できないもの」に集中させます。具体的にはプロダクトのコア機能や、お客様の業務課題を本当に解決できるかに関わる部分にフォーカスしました。逆に、設定画面のような一定のベストプラクティスがある部分は、検証も実装もせず、設定に必要なデータは自分が直接投入することで代替しました。
2. 作るタイミングを、検証のサイクルに合わせる
チームで「次の検証で何を聞きたいか」を合意し
事前ヒアリング → 開発 → お客様に使ってもらう → フィードバック持ち帰り
のサイクルに開発スケジュールを合わせました。余った開発リソースは他のボトルネック解消などにあてました。
この2つの判断により、開発と検証が同じリズムで回り、「作ったのに検証してない」機能を溜めず、本当に必要な機能だけを開発できる状態になりました。
顧客訪問をスケールさせる
検証サイクルが回り始めると、顧客訪問そのもののスケールしにくさが次の課題になりました。さらに人と人とのコミュニケーションや移動が発生するため、訪問に多く行く人の周辺業務の負荷も大きくなっていました。ここで次の2つに取り組みました。
一次情報をチームで共有 & 活用する
一次情報をチームで共有、活用するための基盤は、カミナシのUXリサーチャーが以前から整えてくれていました。Centouというサービスを使って顧客訪問で得たインサイトを蓄積・検索できる仕組みが、会社全体で運用されています。新規プロダクト開発チームにもリサーチャーが入ってくれていて、この基盤の上にインサイトを貯めていくことで、現場に行かなかった人もいつでも一次情報を取得できる状態が作れました。訪問自体がスケールしない以上、得た情報をスケールできる形で蓄積して活用することが、チームとして一次情報の解像度を上げることにつながっています。
周辺業務をAIで楽にする
日々の仕事が忙しい人こそAIを活用したいのに、仕事に追われて導入が進められていない。そんな状況がありました。エンジニアへの導入とは違った観点が必要で、具体的には以下の取り組みをしました。
- AI活用の主導: チーム全員のAI活用状況を事前アンケートで把握した上で、ClaudeやConnectの導入、セキュリティ面を含む運用設計、既にAIを活用している人からのユースケース共有までをまとめて実施しました。結果としてエンジニア以外のロールへのAI活用展開につながりました。
- Google Docs/Drive/Slides連携MCPの自作: 公式のGoogle MCPがうまく動作していなかったので、自作して社内展開しました。以前なら公式の修正を待つしかありませんでしたが、AIを使えば1日足らずで実装できたのはAI時代ならではの変化です。
一次情報の基盤を整えたこと、AIで周辺業務を軽くしたことで、スケールしない顧客訪問そのものに時間を使い、そこで得た情報をチーム全体で活用できる状態になりました。
補足 別チームのPMも似たようなことを試行錯誤しているようです。こちらもぜひ読んでください: プロダクト開発を加速させる ー ビルドトラップの向こう側へ｜migi
商談獲得のボトルネックに飛び込む
ここまでのボトルネックが軽減されて実際に使っていただいた数社から高い評価を得られると、次は「価値の確からしさを、より多くのお客様で検証する」フェーズに入ります。ただ、狙っているセグメントで十分な数のお客様に触れてもらうには、手前の「顧客獲得」自体が足りていませんでした。顧客に価値が届くまでの全体を視野に入れたとき、顧客獲得はその一番元にあるボトルネックです。コーディングから始まった動きが、ここまで遠いところに辿り着きました。
展示会に乗り込む
新規プロダクトの顧客獲得には既に、既存顧客へのアプローチ、マーケメール、ハウスリストへの架電などの施策が動いていました。それでも理想としている商談獲得数には届いていませんでした。追加の打ち手として、既存サービスが出展する展示会で新規サービスも一緒に紹介させてもらうことになり、私もここにコミットすべく乗り込みました。
展示会に行くのは、商談獲得のためだけではありません。ここも一次情報の現場です。どんなサービスが世の中にあり、顧客がどんな課題を抱えて何に興味があるのかを大量にインプットできる場でもあります。エンジニアなどサービス側の人間が顧客獲得に関わりたい場合、展示会は最も良い機会だと考えています。
ただ「エンジニアが来ました」だけでは意味がありません。1戦力として活躍するため、事前にマーケの人に話を聞き、社内の展示会ドキュメントを読み込み、疑問点を解消した上で当日に臨みました。
行ってみてわかったこと
結果として複数件の商談を獲得できました。それに加えて
- どういう課題を抱えている顧客がこのサービスに興味を持つのか
- どういう機能の話をするとお客様が「使ってみたい」となるのか
を実感を持って理解できました。Salesからの「こういうことを言われているので、この機能が欲しい」という要望に対して背景から理解できるようになりました。
一方で、展示会ではカミナシのサービス全体での商談獲得という目標もあり、自分たちのプロダクトにマッチしない顧客には他のプロダクトの話をする必要があったり、かけた時間に対してプロダクトへのフィードバック量は顧客訪問ほどではありませんでした。展示会自体も技術でスケールさせづらく、エンジニアリングを活かすのも難しい領域です。
それでも行ったことで「ここはどの程度自分が入る価値があるのか」を判断できるようになりました。スケールしないところに自ら入ることの価値は、大きな成果が出たときだけにあるわけではありません。入った上で次のボトルネック選定の精度を上げられること自体が価値で、一度もやらずに選択肢から外すのは勿体ないです。
まとめ
目指していたのは冒頭で書いた2つでした。
- 何を作るかの精度を上げる
- 作ったものが顧客に届くまでの速度を上げる
サイクルの順序は計画して決めたわけではなく、目の前のボトルネックを一つ減らすと次のボトルネックが自然と見えてくる、という繰り返しでした。
エンジニアの価値は、コードの外にも広がっている
ヒアリングも商談も、エンジニア以外ができることです。しかしエンジニア自身がそこに入ったからこそ、顧客の課題やどんな機能がどんな顧客に響くかを実感として持てるようになり、その理解がプロダクトに還元されました。一次情報を持ったエンジニアが、他のロールと並んで意思決定に加わる。というところにエンジニアの価値が移りつつあると感じています。
作ることが簡単になった今、エンジニアの価値はコードの中だけでなく外にも広がっています。スケールしないことを自ら選んでボトルネックを見つけに行くことが、AI時代のエンジニアに求められるようになると考えています。
今後やりたいこと
人と人との情報共有は依然としてボトルネックになりやすい領域です。周辺業務や情報共有を技術でスケールさせましたが、まだ「人が情報を整理して共有する」構造は変わっていません。
今後取り組みたいのは、AIを軸にした情報設計です。Slack、顧客訪問記録、商談記録といった一次情報からAIがドキュメント（PRD等）を生成し、さらにそのドキュメントから元の一次情報にいつでも辿れる状態にする。情報の流れそのものを設計することで、情報共有のボトルネックを人の努力ではなく仕組みのレベルで解消したいと考えています。
参考書籍
宣伝
このような新規プロダクトを一緒に作ってくれる人を探しています。
