知識ギャップに負けないPMの意思決定術　専門領域で信頼を獲得する「3つのフェーズ」 [1/2]

toCから、電力卸取引のバーティカル領域へ

坂田太駿氏：よろしくお願いします。株式会社enechainの坂田と申します。最初に、自己紹介をさせていただきます。新卒以降、グリー、エウレカ、メルカリなど、toCのサービスを中心にプロダクトマネージャーをやってきました。そして現在は、2024年からenechainに入り、電力卸取引というかなり専門的な領域に飛び込んで、今プロダクトマネージャーをやっております。



本日は、私がプロダクトマネージャーとして、仕様やロードマップなどさまざまな意思決定をするに当たって、知識のギャップに苦しみながら、どのように取り組んで知識の非対称性を乗り越えて、信頼を獲得したり意思決定をできるようになったかというのをお話できればと思います。

知識の非対称性で起きる問題は「3つのフェーズ」に分かれる

この圧倒的な知識の非対称性みたいなものには、3つのフェーズがありました。まずぶつかったのは、「知識のギャップがあり過ぎて、そもそも議論ができない」というレベル感のもの。その先は、「議論はできるんだけれども、詳細をうまく擦り合わせられない」。最後は、「擦り合ったはずの内容が、実はぜんぜん違っていた」。

こんな感じのフェーズで、知識ギャップによる問題が発生しました。本日は、こんな難しい状況からどういうふうに意思決定できるようになったかを、具体的な事例を交えてお話しできればなと思っています。



知識ギャップを埋めるみたいなものは、enechainのようなバーティカルなサービスだけではなくて、例えば新規のプロジェクトにアサインされた時とか、転職されてぜんぜん違う環境に行った時とかにも使えるんじゃないかなと思いますので、toCのプロダクトマネージャーをやっている方は、ぜひそんなイメージを持って聞いていただければなと思っております。

enechainが挑む「電力卸取引」の世界

今回は意思決定についてお話しするので、どういう意思決定をイメージしたかというのをまず共有させていただければと思います。知識の非対称性があって、不確実性が高く、正解がないという状況下なので、一本ゴールに向けた道を決めるという意思決定ではなく、動き出せる方向性をなるべく早く作って、都度修正できる状態を目指しながらやっていきました。



このタイミングではありますが、知識の非対称性が背景になっているenechainという会社が、どういうことをやっているのかというのをご理解いただいて、「こういう難しいことを理解しようとしていたんだな」みたいなのを想像していただければなと思っております。

ここに書いてあるように、enechainは電力の卸取引のマーケットプレイスというサービスを中心に、電力業界向けのサービスを複数展開しております。すごく簡単に言うと、電力の価格は（スライドの）左のグラフみたいに、毎日乱高下します。



それがあまりにも大きいと、巡り巡って、我々一般消費者の電気代にも大きな影響が出ちゃったりするので、事業者さまにヘッジ取引の機会を提供することで、価格が安定するように、というサービスの提供をしております。

今の説明で、なんとなーくやっていることがわかった方もいるかもしれませんが、おそらくあまりピンと来ていない方のほうが多いかなと思います。こういうかなり専門知識が必要な状況で、業界未経験のプロダクトマネージャーがどんな感じで戦ってきたのかを、フェーズに沿ってお話しします。

フェーズ1：知識ギャップが大きすぎて「議論ができない」

1つ目、「知識ギャップがあり過ぎて議論ができない」フェーズです。（スライドを示して）まずちょっとこちらをご覧いただければと思います。これは仕様の概念の説明文のほんの一部なんですが、あまりわからないと思うんですね。自分もプロジェクトに入った時には、単語もわからないし、何をしたいのかもまったくわからないという状況からのスタートでした。



こういったフェーズにおいては、知識もないですし、もちろん信頼もこのプロジェクトにおいてはない。なので、仕様を決めようとしても、プロダクトマネージャーとして意思決定できる決定余地がほぼほぼない状態でした。

解決策はシンプル：理解のために「徹底的に時間を使う」

ここをどういうふうに解決したかというところですが、理解のために徹底的に時間を使っていったというのが、このフェーズでやったことです。

このフェーズでは、わかっていないものをわかったと思い込むという進め方が、一番危険だと思っています。なのでこのフェーズのKPIを自分の中で「会話する時間」というかたちで設定をして、恥ずかしがらずに図々しく、エキスパートの時間を取って教わるということをやっていきました。

今だと、AIに聞いて複雑な用語を解説してもらったりできるのですが、その用語の使われているコンテキストが違ったり、「このケースにおいてはこういう見方をしなければいけない」みたいなの点で、AIは100パーセント信じられるものではありません。

やはりきちんとエキスパートの時間をもらって確認をする。理解をした自分を見せて、信頼を獲得するというのが、このタイミングでやったことです。

学びをシェアし「ユビキタス言語」を整理して、貢献の糸口をつくる

あとは、②に書いてあるように、この理解をできるだけ周りにシェアしながら、貢献できる余地を探していく。例えばユビキタス言語をきちんと整理していくみたいな感じです。ここで貢献することで、信頼感が増えてくるというかたちを目指しました。



なので、このフェーズでは、信頼に関してはゼロイチの構築のフェーズとして、「信頼を獲得する」を目標に、教わる対話をチームの中で積極的に作っていきました。意思決定は、焦らず自分の限界をきちんと見極めて、知識と信頼の獲得をしながら基盤を整えるという気持ちで取り組んでいきました。

フェーズ2：議論はできるのに「詳細が擦り合わない」

議論ができるようになってきて、その先で苦しんできたのは、「議論はできるんだけれども、詳細がうまく擦り合わない」という問題の発生です。

例えばこのスライドのように、「書類の処理フローって、作成をして、承認・棄却ができればいいんですよね」みたいなのは理解が深まったので確認できるし、「理解は合っていますよ。ログが残ればOKです」みたいな感じで、仕様の策定を進めてるんですが「でも、棄却されるパターンってぜんぜん違うものもあるけれども、この値だけ直したい時って、複製ができるんでしたっけ？」みたいに言われて、「そういうユースケースもあるんだな」みたいなことが多々起こりました。これは今言ったような、ある種隠れたユースケースがポロポロ出てくる状態でした。



先ほどの場合、抽象的な「棄却」という言葉では、概念的に理解して合意できていたとしても、具体的な挙動に落とし込んだ時にズレが発生するということが起きています。なので、このフェーズでは、具体と抽象の中間になるものをきちんと作って整理することで、エキスパートの中にある暗黙知を引き出すみたいなことをやっていきました。