はじめに
先日、レッドジャーニー主催のオンラインイベント「AI駆動開発のその先へ」に参加しました。少し遅れての参加になってしまいましたが、前回の「AI駆動開発 × アジャイル開発」の続編にあたるイベントです。
スピーカーは引き続きレッドジャーニーの田中基淳さん。今回のテーマは 「速くつくれるようになった後、何をつくるかをどう決めるか」。仮説検証とプロダクトマネジメントに焦点を当てた内容でした。
私はContractSのFDE（Field Development Engineering）チームに所属しています。前回のレポートでは「開発が速くなるとバックログが枯渇する」という指摘に強く共感したことを書きました。今回はまさにその続きで、枯渇した先で何をすべきか、その道筋が示されたセッションでした。
そして正直、今回は少し耳が痛い話でもありました。「速くなった余力を、自分はちゃんと価値に変えられているんだっけ？」と問い直されるような時間だったんですよね。学びと、自分なりに考えたことを共有します。
速くつくれても、正しいものをつくれているとは限らない
セッションの核心は、とても明快でした。
AI駆動開発で「つくる速度」が上がっても、何をつくるべきか（価値検証）のサイクルが回らないと、価値提供は早くならない。
これは前回の「バックログ枯渇」を、さらに一段掘り下げた指摘だと思います。バックログが足りないのは表層の症状でしかなくて、根っこにあるのは、そもそも「顧客に本当に価値が届いているか」を確かめられていない、ということなんですよね。速くつくれるようになったぶん、間違ったものを高速に積み上げてしまうリスクすらあるわけです。
FDEの文脈で考えると、機能を速く出せるようになったことで「出荷したから完了」というマインドに陥りやすい。でも本来、リリースは仮説検証の開始地点であって、終了地点ではない。ここの意識を切り替えないといけないな、と改めて感じました。
仮説検証は、螺旋状に解像度を上げていく
田中さんが提示した仮説検証サイクルの考え方は、とてもシンプルでした。
- 仮説を立てる — 顧客の課題は何か、どう解けば価値になるかを言語化する
- 検証する — インタビュー、プロトタイプ、ABテストなど、仮説を確かめる最小限の手段を選ぶ
- 学びを得る — 成功・失敗の理由を分析し、次の仮説につなげる
大事なのは「完成品をつくること」が目的ではなくて、「仮説を確かめるための情報を得ること」が目的だという点かなと思います。検証の手段はいくらでもあるので、そのときどきの状況に合わせて選べばいい。
うまくいかなかった場合の切り分けも整理されていて、「課題の理解違い」「課題の深刻度が低い」「解決策が課題にマッチしていない」など、どこで外しているかを見立てる視点が示されていました。うまくいった・いかなかったという結果よりも、自分たちが立てた仮説はどうだったか、それはなぜかを掘り下げることが大事なんじゃないか、と思いました。
構想を「検証できる形」に変える道具立て
セッションでは、実践的なツールもいくつか紹介されました。
- インセプションデッキ — プロダクトの目的・ミッションをチームで言語化し、共通認識をつくる
- 仮説キャンバス — 誰の・どういう課題を・なぜ解くかを構造化する
- 検証キャンバス — その仮説をどう検証するかの計画を立てる
印象的だったのは、これらの叩き台をAIで作成して、チームで壁打ち・ブラッシュアップするスタイルが有効だ、という話です。AIは叩き台を速くつくれますが、仮説の妥当性判断やユーザーインタビューといった「現実への接触」は人間が担う。つくる部分だけじゃなく、壁打ち・ブラッシュアップにもAIを活かすことで、ここもスピードアップできそうだなと思いました。
FDEに持ち帰って、いちばん刺さったこと
ここからは、セッションを自分の現場に引き寄せて考えたことです。FDEは一般的なプロダクトチームと違って、複数の顧客を抱えています。それぞれの顧客環境をひとつの「プロダクト」と捉えると、私たちは複数のプロダクトに対して同時に仮説検証を回さないといけない立場にあるんですよね。そのうえで、特に刺さった（そして刺さりすぎた）4つを書きます。
1. マルチタスクは、個人ではなくチームで向き合う課題
前回、田中さんの「開発が速くなると人間がボトルネックになる」という言葉に共感しました。今回あらためて考えたのは、そのボトルネックは個人の頑張りで超えるものというより、チームで向き合う課題なんじゃないか、ということです。
FDEは複数の顧客を抱えていて、顧客ごとに仮説検証サイクルが並行で走ります。顧客Aさんと顧客Bさんは業種も規模も契約業務のフローも違うので、どうしてもマルチタスクになってしまう。マルチタスクは効率が悪いと証明されていますし、集中して取り組めるように工夫しているつもりなんですが、なかなかうまく入れていないのが正直なところです。
ただ、これを「一人ひとりがもっと集中すればいい」で片づけると、たぶん解けないんですよね。かといって「顧客ごとに担当を固定する」のも違う気がしています。それだと属人化が進んでしまう。私たちは、矢面に立つ人はいるとしても、あくまで 「チームで成す」 という考え方で課題に向き合うことにしています。だからこそ、顧客の状況をどうチームで共有するか、集中できる時間をどう守るか、属人化させずにチームとして向き合える形をどうつくるか——このあたりを仕組みとして設計するのは、個人というよりチームやマネジメントの仕事だと思います。AIで実装が速くなって生まれた余力も、その段取りがないと、結局は顧客間の切り替えで溶けていってしまう。セッションを聞きながら「これ、かなり大変だぞ」と改めて思いました。この難しさを、属人化に頼らずチームとしてどう仕組みで解くかが、次に考えるべきことなのかなと思っています。
2. 信頼関係という土台がないと、提案は刺さらない
もうひとつの難しさは、顧客との目線合わせです。「将来的にはこうなったほうがきっといい」という方向性が見えていても、顧客自身がまだそこに目を向けていないことがある。そのとき、どうやって気づいてもらうか。
ここについては、やはり信頼関係かなと思っています。正しい提案をすれば動いてもらえる、というわけでもないんですよね。信頼関係が構築できて初めて、もう一歩踏み込んだご提案ができるんじゃないか。いまはそう感じています。これは、以前スクラムマスター道場のレポートで書いた「介入は解決策からではなく違和感から始める」という話と、実は同じ構造なのかなと思っていて。結局は順番の問題なんですよね。
じゃあ信頼関係をどう築くか。私が大事にしているのは、伴走の積み重ねです。ひとつひとつ丁寧に顧客に寄り添う。そのうえで、同じものを見るために現状を見える化する。見える化ができると、ペインの認識が揃ってくる。認識が揃って初めて「じゃあ、このペインを解消するためにどんな提案ができるか」という話ができるし、提案したら終わりじゃなくて、そのペインが解消されたかを、体感だけじゃなく数値でも見えるようにしていく。
書いていて気づいたんですが、この信頼構築のプロセスって、田中さんの仮説検証サイクルとかなり近いんですよね。見える化＝仮説の可視化、認識合わせ＝課題仮説の握り直し、提案＝解決仮説、効果の数値化＝検証。顧客との信頼を築くことと、仮説検証を回すことは、案外地続きなのかもしれないな、と思いました。
3. リリースは、検証の開始地点
機能を出すことがゴールじゃなくて、出した後に「本当に課題が解けたか」を確認するサイクルを回す。利用状況のモニタリング、顧客へのヒアリング、データ分析——これらを、気合いじゃなくて仕組みとして組み込んでいきたい。2で書いた「数値で見える化する」も、まさにここに直結する話です。
4. AIの効かせどころを分ける
最後に、AIとの付き合い方です。役割をこう切り分けたいなと考えています。
- AIが担う：叩き台の作成、壁打ち、仮説の仮打ち、実装
- 人間が担う：仮説の妥当性判断、顧客との対話、責任の引き受け、学びの言語化
この切り分けを意識しておくと、AIに頼りすぎるのも、逆に活かしきれないのも避けられるんじゃないかなと思います。顧客との信頼関係を築く「現実への接触」は、最後まで人間の仕事ですね。
おわりに
前回のイベントで「速くなった先に何があるか」という問いを持ち帰り、今回はその答えの1つが示されました。
つくる速さで競う時代は、静かに終わりに近づいている。
この言葉が刺さります。速くつくれることは前提条件になりつつあって、差がつくのは 「何をつくるか」の見立てと検証の精度。そしてFDEにとっては、その精度が顧客との信頼関係の上に成り立っているんじゃないか——今回いちばん腹落ちしたのは、この点でした。
持ち帰った次の一手は、まず インセプションデッキから試してみることです。仮説キャンバスも検証キャンバスも、恥ずかしながらまだ自分のチームでは試せていません。だからこそ、「なぜつくるか」をチームで言語化する第一歩として、AIで叩き台をつくって、チームで壁打ちするところから始めてみようと思います。複数顧客を抱えるFDEだからこそ、顧客ごとに仮説を立てて優先順位をつける習慣を、仕組みとして根づかせたい。そして何より、チームが複数顧客のマルチタスクに飲み込まれず、「何をつくるべきか」に集中できる状態を、どう仕組みでつくるか。まずはそこから手をつけたいですね。
次回（第3回）は組織運営・経営がテーマで、森さんとのパネルディスカッション形式とのこと。「つくる → 何をつくるか → 組織としてどう回すか」と抽象度が上がっていく構成が、いまから楽しみです。
