非エンジニアPdMがバイブコーディングやってみたら、“やらない判断”が爆速になった話
はじめに
ひなつです！
自分が所属するチームは、エンジニアがフルタイム1人とパートタイム1人。正直、やりたいことを全部実現するにはエンジニアリングリソースが足りていません。
エンジニアは常に最重要なことに取り組んでくれているため、「ユーザー価値につながる可能性があると思うけど、実際に作ってみなければ検証できない類の機能」の開発を無邪気に依頼するのは気が引けちゃうんですよね・・。
なので「思いついたアイデアを、自分でその場で形にして検証できたらいいのにな」とずっと思っていました。
そんな時、友人にバイブコーディングのやり方を教えてもらったことで「自分でプロトタイピングから検証までできてしまうのでは？」と思い、トライアルをしてみました。
今回は「非エンジニアがバイブコーディングで、開発に参加する試み」のお話です。
対象読者
・自分でプロトタイピングから検証まで完結させたいPdM
・バイブコーディングやってみたいけど腰が重いなぁと思っているPdM
・無茶ぶりしてくるPdMに、自ら価値の事前検証をしてもらいたいエンジニア
記事を読むメリット
非エンジニアがバイブコーディングで開発に貢献するステップや現実的な方法がわかると思います。
結論
・非エンジニアでも、既存プロダクトのコードにバイブコーディングで機能追加〜価値検証が可能
・DBのスキーマをいじるなど「やってはいけない操作」を回避する工夫はエンジニアと事前設計しておくとよい
・デザインを気にすると時間が溶けるため、気にしない方がいい
・本番環境にそのまま適用はできないが、価値検証が完了した状態でエンジニアに渡すことで全体の開発効率がUP
さて、本文に入っていきます。
バイブコーディングデーの誕生
まずは、週に1回、チームで貸し会議室に集まって「バイブコーディングデー」を実施することにしました。
普段はフルリモートで働いてますが、慣れないことをやる時は、細切れではなくまとまった時間をとってやった方が軌道に乗るのが早いため、エンジニアにお願いして実施をしました。
エンジニアと隣同士で座って自分はバイブコーディングを進め、わからないことがあればすぐ質問できるようにしました。エンジニアとしても、中長期で開発リソースが増えると嬉しいということで、快く手伝ってくれました。
結果的に、環境構築からプロトタイピングまでを1日目で一通り実施することができました。
どうやって進めたか
今回使ったツールはこんな感じです。
- Claude Code + Visual Studio Code → コード生成をお願いする
- ChatGPT → 要件定義の相談役
- Vercelのプレビュー環境 → 本番にマージせず機能を試せる
流れとしては、
- ChatGPTに壁打ちして要件をまとめる
- Claude Codeでバイブコーディング
- プレビュー環境で動かす
- ユーザーテスト
- 良ければエンジニアに渡す／ダメなら「やらない」と決める
シンプルですが、これで非エンジニアだけでプロトタイピング〜価値検証までを行うことができました。
本番環境にマージせずにプレビュー環境で試せるため、基本的に好きにコードをいじったりミスをしても迷惑をかけないような設計で始めました。
非エンジニアが開発に参加するための仕組みは以下の記事を参照してください↓
自分でやってみて気づいたこと
1. PdMが“やらない判断”を爆速でできるようになる
初めてバイブコーディングで作ったプロトタイプを通して分かったのは、「これ、ユーザーの価値に繋げるまで、想像以上に細かい調整が必要で、一度取り組むと時間が溶けていく機能だな…」ということ。
結果、エンジニアに依頼する前に「今はやめよう」と判断ができました。
無駄にエンジニア工数を使わなくて済むし、意思決定が軽くなりました。
2. 危険な操作を避ける工夫が必要
データベースのスキーマ変更のように、プロダクトの設計や他のコードに影響を与えかねないリスキーな操作が行われようとしていても、非エンジニアだと気付きづらく、正直怖いです。
自分は遥か昔エンジニアをやっていたのでなんとなく「これは危ないな」と判断できたけど、完全に知識ゼロだと見極めは難しいと思います。
今回は、Redisのような揮発性メモリを使って代替することで、安全に検証できるようにしました。
完全にプログラミング知識がない場合は、事前にエンジニアと「やってはいけない操作リスト」を作り、Claude Codeに事前にまたは都度伝えておくとより安全かもしれません。
3. デザインは気にしない
AIが生成するUIって、プロダクトの既存のトーンと合わないんですよね。
0→80くらいまではやってくれるけど、80→100の調整をしようとすると時間が溶けて本末転倒。
なので割り切って、機能検証に最低限必要なUIだけを作ることにしました。
見た目より「動くかどうか」「ユーザー価値があるかどうか」にフォーカスすることで、スピーディーな検証をすることができました。
エンジニアと非エンジニア、双方にメリットがある
バイブコーディングをやってみて思ったのは、双方にメリットがあるということ。
-
非エンジニアのメリット
- 自分のアイデアをすぐ形にできる
- 事前検証できたものをエンジニアに渡せるため、不確実性が減る
-
エンジニアのメリット
- 無駄な工数を取られなくなる
- 危険な操作を回避しているので安心して任せられる
- 本当に価値がありそうな機能だけに取り組める
結果として、チーム全体として良い開発スタイルを築けてきています。
まとめ
非エンジニアでも「アイデア → 価値検証」までを爆速で進められる。
小さなチームや、短い時間で成果を出したいチームにはすごく相性がいいと感じました。
Claude CodeにGemini CLIを呼び出させて相互レビューさせながらコーディングをする方法もあるらしいので、今後挑戦してみようと思います。
Discussion