中間成果物で「パターン」を分解し、認識を細かく合わせる
フェーズ1でやっていた勉強会だと、エキスパートが主体となってしゃべってくれるので、エキスパートの頭の中にメインとしてあるものはちゃんと出てくるのですが、イレギュラーなケースだったり、エキスパートが想像し切れなかった部分を、こういうたたき台を出すことによって、もう少し詳細に理解ができて擦り合わせができるようになる。下の「分岐に注目してレアケースを見落とさない」みたいなのも同様です。
実際にどんなことをやったかをちらっとお見せすると、(スライドの)左は1つの値に対して、どういうパターンがあるかをかなり細かく分けながら、「これで認識は合っていますか?」と擦り合わせました。先ほどあった、卸取引という取引の売り買いのパターンはこういうかたちで整理されていて、真ん中にあるように、「こういうパターンはやらないよね」みたいな詳細を擦り合わせました。
分岐・ステータスまで書き出し、齟齬を潰していく
あとは、業務フローの分岐やステータスはどういうものがあるのかみたいなのを、かなり細かく書き出して、認識の齟齬がないかを擦り合わせていくということをやっていきました。
抽象と具体の中間を作ることで、議論もできるし、よりその議論を深められるという意味で、チームの信頼がどんどん拡大できるフェーズかなと思っています。さっき作った中間生成物は、チーム内での認識が擦り合っていくためのツールになるので、後の工程の開発をする段階においてもかなり役立つようなものになっていきます。

対話は「教わる」から「整理する」へ、意思決定も前に進む
なので、対話としては、さっきの「教わる」から少し進歩して、「整理する」みたいなことをしっかりと擦り合わせていくフェーズに入ってきます。意思決定としては、さっきのような整理ができてくると、「こういうパターンが必要です」という仕様の策定もできます。
その中で、「これは相当レアケースなので、フェーズ1から落としましょう」みたいなプライオリティの決定もできてくるので、このあたりまで来ると、かなり意思決定としてもチームに貢献できる状態になってくるんじゃないかなと思います。

フェーズ3:擦り合わせたはずが「実は違っていた」
最後のフェーズ3のところは、「擦り合ったはずの内容がぜんぜん違っていた」という部分です。ここまで来るとドメイン関係なく、みなさんの開発でも起こるんじゃないかなと思います。すごく抽象的に言うと、「このパターンってないんだっけ?」みたいなのが出てきて、「それ、この間、図で整理したけどなかったですね」みたいなのが、擦り合わせをやっていても起き得ます。

我々のケースで言うと、あの整理をしたタイミングから、営業活動を通して少し要件が変わったものが反映されなかったから、パターンに漏れてしまったみたいなものがありました。擦り合わせを丁寧にやっていてもズレ得るというのは、けっこう後半で起きてくることかなと思います。
ここからはPRDのオーナーとして、ズレを指摘し修正する立場になる
これまでのフェーズとの大きな違いで言うと、今までは基本的に教わる立場だったのですが、このぐらいまで来ると、PRDを書くタスクをオーナーとして進めていて、場合によっては知識ギャップのズレを、自分から指摘したり修正していかなきゃいけなくなってくるので、信頼が崩れやすくなるフェーズかなと思っています。

なので、このフェーズにおいては、信頼を損なわないようなズレの解消の仕方がポイントになります。そのHowとして、「人ベースではなくて、成果物ベースで擦り合わせを行う」というところを意識しながらやっていきました。具体的には、成果物を定義して、チェックポイントを設ける感じです。
レビュータイミングを設計し、確度と品質を上げていく
今までのような、中間成果物を作っていて議論もするというところだと、けっこう参加者によって想像しているものが違ったりもしますし、レビューのクオリティがばらばらになってしまったりするんですが、このレビューのタイミングをしっかりと設けてアサインをすることで、「本当にこれでよいのか?」みたいなところの確度を高めていく。
あとは、けっこう精神的な部分なのですが、経験上、例えば進捗確認のミーティングの途中に、「あれ? ここの仕様ってここが漏れてない?」とか、Slack上で唐突に、「あれ? これってこういうパターンはないんでしたっけ?」みたいなものがあると、受け手としてはけっこうネガティブなサプライズになってしまう。
信頼維持フェーズでは、ズレの発見を“品質向上”につなげる
レビューのタイミングを明確に設けると、ズレを出すこと自体をポジティブに捉えやすいと思っているので、「ズレは出るものだよね」という前提に立って、そのズレをどう生むか、それをどう扱うかみたいなところをプロダクトマネージャーとしてコントロールしていくことが、すごく重要になるかなと思います。
ここに関しては、信頼はもう維持するフェーズに入ってきていているので、先ほどのように、どういうふうに信頼を損ねずにズレを発見して、プロダクトのクオリティを高めていくか。対話も、ズレをどう見つけるかというところをすごく工夫しながらやっていきます。
意思決定は「PMが決める」から「チームで納得度を上げる」へ
意思決定としては、最初に申し上げたように、プロダクトマネージャーがこうと決めるだけではなくて、このズレの発見を通じて、どういうふうにチームでブラッシュアップをして、納得度の高い意思決定をしていくかというのを実現するかたちになっております。
最後にまとめると、フェーズは3つのフェーズになっております。フェーズ1では、知識のギャップがあまりにも大きいので、会話時間にKPIを置いて、信頼の獲得に努める。そのために、きちんと教わる時間を取って、意思決定のための土台を築くというかたち。
2つ目のフェーズでは、整理の数をKPIにしながら信頼を拡大していって、得た知識や理解力から方向づけていったり、プライオリティを考えていったりというのを主体的にやっていくフェーズ。3番目のフェーズでは、ズレをきちんと発見して最後のクオリティを高めるために、信頼を維持しつつ、チームできちんと修正するという態勢を整えていくということをやっておりました。

正解がない領域ほど、ギャップを埋めて前に進めるPMの価値が高い
最後になりますが、今日話した内容というのは、ちゃんと図で整理したりしながら、必要であれば人から物を教わって、レビューをしましょうみたいな、ある種かなり当たり前の話ではあるのですが、我々のような専門性の高いバーティカルな領域においては、この泥臭い知識の擦り合わせがプロジェクトの命運をけっこう握るなと思っています。
逆に言うと、かなり大きな知識の非対称性がある場所は、まだ誰も正解を出せていない、かなり難易度の高い領域だなと思っていて、このギャップを埋めたり、カオスな状態でもプロジェクトを前に進められるスキルを持った人がプロダクトマネージャーで、そこに極めて高い価値があるんじゃないかなと思っています。
AIでも答えが出にくい場所に、人間PMの醍醐味がある
昨今のAIの発展によって、けっこう想像がつく、正解が見えているものを実際に開発するというところに関しては、かなりハードルが下がってきていると思いますが、今お話ししたような、一般論が通じないかなり業界に閉じた話とか、電力だけではなくて決済までやろうとすると、金融の知識も必要になってくるので。
そういった複雑な知識のかけ合わせみたいなところで、AIでも簡単には答えが出ないところに入ってくると、ここは人間のプロダクトマネージャーがかなり寄与する、1個大きな道なんじゃないかなと思っておりますし、個人的にはすごく醍醐味があるなと感じているところです。
我々はそういった領域に挑戦しています。こういう知識の非対称性を乗り越えてプロダクト開発をしていきたいなと思っているとか、「実際にけっこう同じようなことで困っているんだよな」みたいな方がいらっしゃれば、ぜひこの後、お話できればなと思っております。本日はありがとうございました。
(会場拍手)