この記事の要約
- 生成AIの普及で「つくるコスト」が劇的に下がり、プロダクト開発が爆速化する
- 「勝手にやる→後で報告」で一気にイノベーションを起こすアプローチが有効になりつつある
- PdMはコーディング能力以上に「顧客課題の軸を守る」「実験の評価指標を設定」役に徹すると良い
“つくるコスト”が下がった今、なぜ“勝手にやる”が注目されるのか
生成AIの登場によって、従来なら数週間かかった機能試作やUIデザインが数日や数時間で形にできるようになりました。LLMが”それなりに”動くモックアップやサンプルコードを生成してくれます。ちょっと前までなら「一度稟議を回して、開発メンバーとレビューして…」という工程が必要だったのに、もはやそれをすっ飛ばして実物ができてしまうわけです。
僕も「とりあえず作る」「まず作る」「作りながら考える」スタンスにここ数ヶ月はトライしてみています（実験として）。僕のような文系バックグラウンドのPdMでも、生成AIが助けてくれるからこそプロダクトを自らいじれるようになり、「待ってられない、作っちゃう」空気感が漂います。
そこで“勝手にやっちゃう”アプローチを僕は大事にしたいなー、と思っています。大きな承認を待たずに先に動いてしまい、あとから周囲に報告や謝罪をするイメージ。
“勝手にやる”ことで得られる圧倒的なスピードと自由
このスタンスには以下のようなメリットがあります。
- 速い検証サイクル: すぐ作って、すぐユーザーに試せる。仮説の良し悪しを早期に把握できる
- 打席数を増やせる: ダメ元でも量を打ってみると、思わぬ大ヒット施策が見つかる
- チームメンバーに余計な忖度がない: 「これやりたいんだけど、いいですか？」とぐずぐずするより、先に作って成果を見せる方が議論も早い
特に文系PdMが多い組織でも、画像生成AIやチャット生成AIを使えば、ある程度のUI素材やコードを出せます。複雑なバックエンドロジックまではカバーしきれないにしても、フロント側のモックやユーザー体験を具体化するところまでは、個人レベルでサクッと進められるようになりました。そうなると「人に聞く前にやってしまえ」という発想が自然に生まれるのです。
ただし、勝手にやるだけだと全体の整合が取れなくなるリスクもあります。そこは後述するように、PdMが「どこまで自由にやっていいのか」最低限のガイドラインを示すことが大切になります。
PdMの本当の役割：コーディングよりも“方向づけ”と“後で報告”を許容する仕組み
「PdMこそコードを書けた方がいいよね」という意見を耳にすることがあります。もちろん、コードを書けるPdMは強い側面もあるでしょう。しかし、生成AIがコードを書くコストを大幅に下げた今は、PdMがわざわざプログラミングスキルを身につけなくても“作る”ところは何とかなる可能性が高いです。
ではPdMは何をするのか。僕が考えるのは、以下の2点です。
- ① 顧客課題に合っているかどうかを見極める“軸”を提示
作るのは簡単でも、何を作るべきか、そこがブレるとユーザーの求める価値にはつながりません。なのでPdMは「うちのプロダクトは○○の課題を解決するために存在している」「そこから外れてない？」という軸をチームに示し続けます。 - ② 後付けで報告や謝罪が来たときに、成果とリスクを判断する仕組みをデザイン
「こんな機能のデモ作っちゃいました！」とメンバーが言ってきたときに（or 自分で作ってみたときに）、PdMが「じゃあどう評価する？」を指標立てで決める。たとえば“1週間でユーザー利用率が10％伸びるか試そう”といった形です。いい感じに数字が動いたら正式リリース、ダメなら撤退といったルールがあると、結果的に組織として短サイクル開発が回りやすくなります。
その意味で、PdMの価値は「コードを書かないなら何もしない」ではなく、“勝手にやる文化”をスムーズに機能させる監督者や審判のような立ち位置です。生成AIの進化で、PdMは調整屋というよりも価値の方向づけと検証結果の判断役に集中した方がいいかもしれません。
後で報告・謝罪するだけでOK？ 実際の流れイメージ
「勝手にやる→後で報告」という流れは、一見すると秩序がないように見えますが、意外とシンプルに回せると感じています。流れは下記のとおりです。
| ステップ | やること |
|---|---|
| 1. 誰かが勝手に作る | 生成AIや自分のスキルで小規模機能を試作。UIモックやプロトタイプを素早く整備 |
| 2. チーム内でこっそりテスト | 開発環境や友人・一部ユーザーに見せてフィードバックを得る。「これ面白いかも」程度の軽い感想でも良い |
| 3. PdMに後付けで報告 | 「こういう機能を作っちゃいました。ユーザーの反応は○○でした」とか「失敗したので廃棄します」の連絡 |
| 4. 継続 or 廃案の判断 | PdMは事前に決めていた指標を見て、次のステップに進むか、ここで停止するかを判断 |
あえて最初の承認をなくすことで、スピードが圧倒的に上がります。やってみた結果に対してPdMが数字やユーザーの声を見て「ああ、良さそうだね」と言えばOKですし、ダメなら終了。たまに怒られるかもしれませんが、作るコストが下がった今の時代だと、怒られるよりも先に結果を出した方が得だと感じることが多いです。
“勝手にやる”だけでは危険：顧客課題の軸を忘れない方法
とはいえ、「何でもやれ」となると本当に無秩序になりかねません。顧客が求めているものと全く違う機能が量産されると、プロダクト全体のUXが崩壊します。そこで僕が推奨するのは“課題の1行宣言”です。これは、「うちのプロダクトはこれを解決するために存在している」というミッションを短文で共有するやり方です。
- 例：「HR領域で採用担当の候補者対応の効率を1/10にすること」
- 例：メモアプリなら「ユーザーがメモを二度と探さなくて済む状態を作ること」
どんな勝手な機能アイデアでも「これ、課題の1行宣言と繋がるよね？」と一瞬振り返れる仕組みにするだけで、闇雲な発想が減ります。もちろん完全には防げないですが、PdMがこの1行宣言を何度も口に出して言うことで、メンバーも自然と「これ意外と関係ないかも…」と気づくようになります。
小さくPDCAを回し、Planは最小限でいい時代
従来のPDCAでは、Planに時間をかける傾向がありました。綿密な要件定義、ステークホルダーとの調整、詳細な仕様書作り…確かに開発コストが高い時代ならリスクを下げるための入念な準備が必要だったわけです。
でも今は違います。Planを簡略化して少し試作(Do)してみる方が結果的に早いことが多いです。ユーザーインタビューやアンケートをする時間も必要ですが、そこも「試作したものを見せながら話を聞く」方がユーザーの具体的なリアクションを得やすい傾向があります。実物があれば議論が進みやすいんですよね。
たとえば以下の記事では、ユーザーに直接プロトタイプを見せてフィードバックを収集する方法を紹介しています。少しでも参考になるかもしれません。
プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips
僕自身も、Planを作り込みすぎて「実際に触ってみると全然違うじゃん…」と気づくケースをたくさん経験しました。生成AIの普及によって、Planを最小限にすることのメリットはより大きくなると感じます。
実践上のピットフォールと対策：やりすぎるとカオスになるのは事実
「どんどん作れ、後で報告」という開発フローに移行すると、以下のような問題も起こりやすいです。
- プロダクトの一貫性が崩れる: 各メンバーが独自のUIやロジックを作り、統合に苦労する
- 重複投資: 同じような機能を複数人が別々に開発していた、みたいな無駄が生まれる
- 品質担保が甘くなる: テストを省いてしまい、ユーザーにバグを見せてしまう恐れ
ここでPdMの出番です。具体的には以下を意識すると混乱を抑えられます。
- ① 短い共有サイクル
チーム全体で週1のデモ会などをやり、今週何を作ったかざっくり見せ合う。重複や衝突に気づけるし、良いアイデアをチームが取り込みやすいです。 - ② デザインやUXのガイドライン設定
あらかじめ「色やフォントはこう」「ボタン配置はこう」と簡単なルールを決める。大きく外れなければカオス化を最小限にできます。 - ③ リリース基準の明文化
小規模なPoCなら勝手にOK。でも本番リリースはバグチェックやユーザー検証の結果をPdMに報告しないとNG、など最低限のゲートを敷く。
要するに自由度は高くても、事故が起こる前にPdMが軽く方向修正する仕組みがあれば問題ないという感じです。勝手にやるのと無秩序は違う、というのは大切なポイントです。
やりたきゃやれ、後で謝るぐらいの勢いがちょうどいい
生成AIで一気に“つくるコスト”が下がった今、PdMがやるべきことは「誰かが先走って作った機能」に後から冷静にジャッジを下せるフレームワークを作ることだと思います。本人が「すみません、勝手に作っちゃいました」というぐらい軽やかに動ける雰囲気こそ、イノベーションの土壌になるのではないでしょうか。
許可よりも結果を先に見せられた方が、ビジネス的にも説得しやすいのが現実です。特に今のように開発速度を上げるためのツールが充実している時代、「やってみなきゃ分からない」施策をすべて事前承認していたら進むものも進まない気がします。
逆に言えば、PdMはコードを書かずとも「ここだけは守ってほしい」という顧客課題の軸を示し、実際に作られた試作品の結果を見て「これはアリ」「これはナシ」を判断する。立場的には責任ある審査員のような役割も求められるわけです。僕自身も最近は、とりあえずv0とかでプロトを作ってユーザーに見せて、後で他の人に共有する、とかをやってます。
こうした高速開発がさらに加速すれば、新機能を一気に試す量と質が格段に上がるはずです。もちろんいろいろ問題は出てくるでしょうが、従来の「まず稟議、慎重に計画」スタイルと比べれば、明らかにスピード感が違う。顧客の心を掴むために回数をこなして当たりを引くなら、やっぱり後から報告ぐらいがちょうどいい──と僕は思ってます。
今日から実践できるアクション
- 1. “勝手に作る”提案をチームにしてみる
ちょっと気になる機能やUI案があれば、誰でもポンと作ってみていいよ、と一度宣言してみる。初めは戸惑うかもしれないが、意外と動きが変わる。 - 2. 短い共有サイクルを設ける
週1や隔週ぐらいのペースで「最近こんなの試作してみた」というデモ会やSlackでの共有タイムを作る。自然とナレッジ交換が活性化する。 - 3. ミニKPIを設定して実験を回す
勝手に作って放置だと意味がないので、「ユーザーに触らせてみて1週間でUU数がどれくらい増えたか」「離脱率が下がったか」といった簡易指標を用意して判断する。 - 4. “課題の1行宣言”を全員で共有
何のために存在するプロダクトか、シンプルな文言を掲げる。勝手にやる行為がその宣言と繋がっているかを各自チェックできるようにする。
Q&A
- Q1: 何でもかんでも勝手にやっては品質が落ちそうですが、大丈夫でしょうか？
- 大丈夫なわけではありません。最終リリースの前には最低限のレビューやテストを通すなど、PdMが品質の最終責任を持つ仕組みが必要です。ただ、それは「まず試作してみる」こととは別のフェーズなので、そこは区別して考えると良いです。そして、「勝手に作る」というアプローチ自体がそれがちゃんとワークするのかの実験と僕はとらえています。
- Q2: PdMがコーディングできないと、やっぱり不利にはなりませんか？
- 生成AIの普及が進み、コード作成自体はハードルが下がっています。PdMの強みは「顧客課題の把握」と「成果物の評価基準設計」といった点に移りつつあるため、コーディングスキルはあれば便利ですが絶対必須とはいえないです。
- Q3: “後で怒られるより先に作れ”はリスクが大きいように感じます。
- リスクをゼロにはできませんが、小規模PoCや限定公開など、影響範囲を絞って実験すれば被害は最小限に留まります。実際に成功した例を踏まえると、事前承認に時間をかけるより、先に作ってしまう方が得られる学びが圧倒的に多いです。あと、多分銀行とかだと「先に作る」範囲はだいぶ限定されるとは思いますね。
- Q4: なんでそれが今できるようになったの？前から“勝手にやる”人はいたのでは？
- もちろん前から独断で開発しちゃう人はいましたが、開発コストが高かった時代には失敗したときの損失が大きすぎました。生成AIの登場で、試作のハードルが一気に下がった今こそ、このアプローチのメリットが相対的に大きくなったといえます。
参考情報
- Ries, E. (2011). The Lean Startup. Crown Business. (小さく作って早く検証する理念を提唱)
- Stanford HCI Group (2019). Rapid prototyping and user feedback experiments.
- プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips（具体的なプロトタイプ活用例）
コメント