Whyを磨いて、小さく出す。AIとフル出社環境で最適解を導いた話

はじめに

はじめまして。RECERQAでCA（Client Adviser）をしている武田です。

RECERQAのCAは、いわゆるカスタマーサクセス（CS）だけを担う役割ではありません。導入や活用支援に加えて、必要があればPdMやPMMのように、お客様に価値を届けるためなら「なんでもやる」ポジションです。

今回は、私がPdM的な立場で新規機能の開発スコープをどのように決めたかをお話しします。

向き合っていたのは、RECERQA Scanの「重要だけれど抽象度が高いテーマ」でした。「絶対に外したくない」という思いが強いほど、機能は肥大化しやすくなります。どこをMVP（必要最小限の価値を提供できるプロダクト）に設定すべきか、私は悩んでいました。

結論から言うと、今回は「AI活用」と「フル出社」というRECERQAならではの環境を活かすことで、最適なスコープを見極めることができました。開発経験ゼロの私が、AIを壁打ち相手にしてWhy（なぜやるのか）を磨き、ローカルでプロトタイプを作り、エンジニアと即座に議論して納得のいく判断を下すまでのプロセスをご紹介します。

重要なテーマほど、気づくと話が大きくなる

重要なテーマに向き合うとき、頭の中にはすでに「こういう機能が必要そうだ」という完成形のイメージがあります。それ自体は自然なことです。

しかし、そのイメージから入るとどうしても「How（どう作るか）」が先行してしまいます。何を入れるか考えていくうちに「やっぱりこれも必要だ」と、どんどんスコープが広がってしまいました。

本来、先に整理すべきなのは「Why」です。誰の、どんな課題を解きたいのか。現在の状態（As-Is）はどうなっていて、どんな理想の状態（To-Be）を作りたいのか。そこが曖昧なまま機能の話を進めると、気づけば「あれやこれ」と要件が膨れ上がってしまいます。以前の自分も、まさにそうなりがちでした。

As-IsとTo-Beを往復すると、Whyが研ぎ澄まされる

そこで最初にやったのは、AIと壁打ちしながらAs-IsとTo-Beを整理し、そこに存在するギャップ（＝解くべき課題）を明確にすることでした。

このとき、AIには単に同意してもらうのではなく「優秀なUXデザイナー」という役割を与え、「本当にその機能が必要か？」を厳しくレビューしてもらうように依頼しました。実装したい機能はいったん横に置き、お客様の業務の詰まりはどこにあるのか、それが取り除かれたあとにどんな体験を提供できるのかを文章に書き出していきました。

この時間は、非常に効果的でした。自分では見えていたつもりでも、AIと壁打ちしながら言語化することで、課題の輪郭がよりはっきりし、ぼんやりしていたものがソリッドになっていく感覚がありました。

結果として、解くべき課題にピンポイントで対応する「MVP案」と、よりしなやかな体験を届ける「リッチ案」の2つを、高い解像度で比較できるようになりました。

プロトタイプに落とし込むと、MVPの価値が可視化される

次にやったのは、机上で考えるのをやめ「実際に動くものを作ってみる」ことでした。AIを使って、ローカル環境で動くプロトタイプをMVP案とリッチ案の両方で作成しました。

ここで検証したかったのは「MVPでも本当に課題が解けるのか？」という点です。

文章だけで仕様を詰めていると、同じ言葉を使っていても、頭に浮かんでいる画面や導線は人によって異なります。しかし、具体的なプロトタイプがあれば、その認識のズレは最小限に抑えられます。抽象論ではなく、実際の体験ベースで議論を進められるようになりました。疑似的にユーザー体験をなぞることで「MVPでもしっかり課題解決できる」という確信を持てたのは大きな収穫でした。「まずは小さく出す」という選択が、妥協ではなく、意味のある一手だと思えるようになったからです。

開発負荷まで確認し、自信を持って判断を下す

価値がありそうだと分かっても、それだけではスコープの判断には踏み切れません。実際にどれくらいの開発負荷があるのか、MVPを作ったあとにリッチ案へ移行する際、二重コストにならないかを見極める必要がありました。

そこで、プロトタイプを作る際に、AIにリポジトリの中身も確認してもらいました。技術的なハードルや差分、MVPの開発資産をどこまで転用できそうかを壁打ちしたのです。

その結果、MVPで作る資産の多くがリッチ案でも活用できることが判明しました。MVPは一時しのぎではなく、次の開発につながる「強固な土台」になることが分かったのです。さらに、最初からリッチ案を作るよりも、段階を踏んだほうが結果的に1週間ほど工期を短縮できそうだというフィードバックも得られました。

ここまで見えたことで「まずMVPで出し、その延長線上でリッチ案を進める」という方針に確信が持てました。その足ですぐ隣にいるエンジニアと議論を交わし、チーム全体で素早く合意形成しました。

AI活用と「すぐ議論できる環境」の相乗効果

今回のプロセスを振り返ると、AIを使ったこと以上に「それを当たり前に業務に組み込める環境」が大きかったと感じます。

日常的にAIを使っていると、思考が曖昧な段階でも「まず壁打ちしてみる」「具体化してみる」という初動が自然に生まれます。特別なツールではなく、思考を前に進めるための手段としてAIが機能しているからこそ、短いサイクルで論点を磨けました。

さらに、RECERQAの「フル出社」という環境がスピードを後押ししてくれました。論点が固まったら、その場で隣のエンジニアに声をかけ、プロトタイプを見せながら即座に認識をすり合わせることができる。

「AIで論点を具体化するスピード」と「対面ですぐに議論が始まるスピード」。この2つが噛み合うことで、進行が速くなるだけでなく、認識のギャップといったコミュニケーションコストも最小化できました。

おわりに

これまで私は、CSやPMとしてお客様の「課題を聞くこと」には自信がありましたが、「どう解決するか（How）を考えること」には苦手意識がありました。

しかし今回、抽象度の高いテーマに対しても、AIを活用することで「小さく、最短距離で最適解にたどり着ける」という大きな手応えを掴みました。

非エンジニアの自分でも、解くべき課題を具体化し、動くMVPを作る。さらに実装コストまでAIと予測したうえで、エンジニアに「これ、どうか？」とスピーディに相談し、共通言語で認識を合わせる。この一連のスピード感は、私にとって初めての経験でした。

以前の私は「丁寧に考えるほど、大きなスコープでなければ機能しないのでは」と不安になりがちでした。でも今は違います。「まずWhyを磨き、小さく出し、学びながら広げる」。この進め方こそが、結果的にお客様へ最速で価値を届ける手段です。