こんにちは、su（@yugawala）です。
atama plusという教育×AIの会社でエンジニアをしています。プロダクトチームで開発をする傍ら、AIX推進室という部署で全社AI活用の推進も行っています。
AIを活用した開発、してますか？ してますね！
この記事では僕がチームで開発をしていくうえで行った取り組み・学びを紹介します。
顧客エキスパート × Vibe Coding
プロダクト開発において、「顧客に受け入れられるものを作る」ことはとても重要かつ難しい課題の1つです。
我々エンジニアもヒアリングに行ったりユーザーテストを行ったりしますが、やはり一番顧客のことを知っているのは、日々顧客と対峙しているメンバーです。営業やカスタマーサクセス、あるいはプロダクトマネージャーといった人々、いわば「顧客エキスパート」たちです。
彼らからフィードバックをもらい、プロダクトメンバーが要件をあぶり出して開発するというフローが行われることは少なくないと思いますが、この「伝言ゲーム」には限界があります。
- 熱量や微細なニュアンスがこぼれ落ちる
- 課題の本質を引き出しきれない
- →気づいたら「顧客が使えるもの」から乖離してしまう
ここで Vibe Coding が有効です。
もし、一番顧客を知っている彼ら自身に、動くプロトタイプを作ってもらうことができれば、プロダクトに顧客価値をもっとダイレクトに込めることができそうです。
実際に、営業職の顧客エキスパートにVibe Codingでプロトタイプを作ってもらい、それをもとに作るべき機能を定義していくという取り組みを行ってみました。私はそれを提案し、エンジニアとして後ろからサポートする役割に回りました。
結果として、私がヒアリングして作るよりも速く、顧客の課題に深く刺さるプロダクトが生まれました。自分が間に入って伝言ゲームをしていた場合の機会損失を考えると、恐ろしさすら感じるほどでした。
今回の取り組みで一緒に動いた顧客エキスパートはエンジニア経験がありませんでした。そのため、Vibe Codingを始めるには伴走する必要がありました。泥臭めに試行錯誤してみました。
今回は、非エンジニアをVibe Coding沼に沈め、プロダクトに顧客価値を乗せていく過程で経験した「泥」3つとそこでの取り組みを紹介します。参考になれば幸いです。
泥（1） やる気の火が消える
1つ目の泥は、「簡単にやる気の火が消えてしまう」ことです。
Vibe Codingを始めるにあたり、最初は最小限のレクチャーで済むと考え、概念説明を省いて環境構築と数個のコマンドだけを教えました。
しかし、それでも最初としてはハードルが高すぎました。環境構築のトラブルシュートを含めて動くようになるまでに2時間かかり、終わった頃には相手の目は死んでいました。「やってみたい！」という火は消えかけ、なかなか次につながりませんでした。
対策1：小さなゴールの積み重ね
この経験から、伴奏するうえでは 「ステップを細かく砕いて、小さなゴールを積み重ねていく」 ことが重要だと対策ました。
- 環境構築はずっと後回し：まずはブラウザだけで完結するv0のようなツールを使い、「AIに指示したら動くものができた！」という成功体験を味わってもらいます。
- 欲求が高まってから道具を渡す：「もっと自分でもやってみたい！」という欲求が出てきて初めて、次の道具を少しだけ渡します。
- できる限り難しい概念は隠蔽する：初めにスキップしても作業が進むような、Gitの概念のレクチャーなどはしません。コンフリクトが起きたら、エンジニアが裏でこっそり直します。
対策2：周りの環境の力
また、「周りの環境の力」 も重要です。「隣の席のPdMが楽しそうにコードを書いている」「SlackでDevinが動いている」といった空気感を作ることで、「自分にもできるかも」と背中を押すことができます。
対策3：強い動機
そして何より大事なのが、強くて消えない火種である、「強烈な動機」を見つけることです。
「AIで色々作れるんでしょ？ 面白そう！」だけでは弱く、「明日の商談でお客さんを驚かせたい」「これを動かせたら明日のアポで勝てるかもしれない」といった切実な欲求が必要です。この火種があれば、多少のトラブルがあっても食らいついてきてくれます。
泥（2） コード崩壊と戦う保守
2つ目の泥は、「コード崩壊と戦う保守」です。
現時点でのAIの水準&エンジニアが介入しない環境では、非エンジニアがAIを使ってノールックコーディングを行えば、当然コードは秒で汚くなります。激しいハードコーディング、重複する型定義、謎の依存関係などが発生します。
しかし、最初の期間はやる気の火を消したくないので、彼らに「コーディングルールを守ってください」と言ったり、構造のレクチャーを始めたりするのは避けます。パンクさせたくはありません。
対策1：エンジニアが裏で泥臭く支えるのもあり
まず割り切って頑張るのもありかなと思っています。汚くなったそばからエンジニアがリファクタリングします。エンジニアとしては耐え難い瞬間もあるかもしれませんが、目的（顧客価値の創出）のために割り切ります。
対策2：仕組みで解決する
もはや鉄板だと思いますが、下記は有効でした。
- AIルール整備：落とし穴のパターンが見えたら、AIへの指示（Cursor Rulesなど）にルールを追加していきます。
- 自動テスト：すでにできていて用意に変更したくない部分については、自動テストを整備して走らせるようにして守ります。AIルールに追加して、AIにテストを任意のタイミングで走らせられるようにするのもよかったです。
泥（3） スケジュールの泥
3つ目は、「スケジュールの泥」です。
Vibe Coderが立ち上がり、成果を出すまでには、手厚いサポートが必要です。サポートするエンジニアも、挑戦する当人も、立ち上がるまでには時間的コストを払うことになります。
対策：余白または覚悟を持つ
基本的/理想的にはタスクに対してスケジュールの余白をもたせておき、突発的なトラブルへ対応できるようにするのがよいと思います。
もしくは、この期間は突発的なことがあってもパワーで耐えるぞという覚悟を持つことも現実的にはよいでしょう。
苦労 < 顧客価値・事業貢献
ここまで書いたように、試行錯誤しながら非エンジニアのVibe Codingをサポートしてきましたが、やってよかったと心から思っています。
私たちエンジニアと当人が払う苦労のコストよりも、顧客感覚を持っているメンバーが生み出す機能から得られる顧客価値・事業貢献の方が大きいと感じているためです。
Vibe Codingで顧客エキスパート自身がプロトタイピングすることは非常に有効です。それを実現するためには、各種ツール群だけでなく エンジニアが工夫を凝らして泥臭くサポートする覚悟 も重要です。
ぜひ皆さんも、一緒に泥へ飛びこんでみましょう！
Discussion