- はじめに
- eSquare Live構想のはじまり
- eSquare Liveを実際に立ち上げ開始！次々出現する強敵
- 第一の敵！「いつまでもフワフワ」登場。
- 第二の敵！「覆りまくる意思決定」登場。
- 第三の敵！「知らず知らずに複雑化」登場。
- さいごに
はじめに
こんにちは、enechainプロダクト企画部部長の大橋です。プロダクト企画部は、デザインやプロダクトマネジメント、PoCをツールで推進する部署といった、プロダクト開発における企画よりのチームで構成されており、私自身もProduct Managerとしてプロダクトを担当しています。
今回の記事では、2024年10月9日にリリースされた電力卸取引のオンラインマーケットプレイス「eSquare Live」プロジェクトについて、立ち上げ時からPdMとしてリードしてきて、学んだこと、他のプロダクトの立ち上げ時でも活かせるようなエッセンスを抽出すべく、筆を取りました。
eSquare Liveは、現物から先物まであらゆる商品を、板画面上でリアルタイムで取引できるプラットフォームです。プロダクト開発の裏話やグッドデザイン賞をとったUIについて、またリリース直前期で社内外の声を集めた話は、他のメンバーの記事をぜひご覧ください。
eSquare Live構想のはじまり
enechainはみなさんが当たり前のように日常で使う（当たり前すぎて使うという感覚すらないかもしれない）「電力」の卸取引の仲介をしている会社です。
詳しくはenechainのカンパニーDeckを見てほしいのですが、この市場は2016年の電力小売自由化によって生まれ、かつものすごく大きな金額、量（世界的にみても日本の電力消費量は中国、アメリカ、インドに次いで第4位）の取引が日々行われているExcitingなマーケットです。
これまでenechainは、その取引の間に入って、Broking（いわゆる仲介）を主に電話やチャットを使って人力で行っていました。しかし、このeSquare Liveというプロダクトは、そのようなある種マニュアルな作業を全て、株式や、その他のコモディティのようにスクリーン（板）で自動マッチングさせ、成約させていくという、壮大なプロジェクトです。
実は私が入社した2年半ほど前でも、この構想自体はすでに社内に存在していましたが、当時のタイミングではスキームや、事業の進捗から見ても「このタイミングではない」と見送られてきていたプロジェクトでした。
eSquare Liveを実際に立ち上げ開始！次々出現する強敵
ようやく、様々なシステム投資、チーム組成、事業的な準備の完了などの必要条件が揃い、満を持してこのプロジェクトが実際に始動したのが、2023年10月。ビジネス側メンバーと共に、仕様策定、デザインなどが始まりました（開発が実際に始まったのは12月の中旬頃から）。
今でこそ、実際にプロダクトがローンチされ、運用に乗ってきていますが、このリリースまでに要した1年ほどの時間は、苦難に次ぐ苦難で、本当にリリースができるのか？これはそもそも成立するのか？と、次々とマップ上に強敵が現れるハードモードなRPGのようなもので、何度そのコントローラーを放り投げてやろうかと思ったことでしょう。
ここからはProduct Managementの観点から特徴的だった強敵（課題）の紹介と、その強敵にどんな武器（解決策）を持って対抗していったかをPick Upしていきたいと思います！
全く同じ場面はないかもしれませんが、同じように、これから未知の強敵に挑む他のプレイヤーの皆様のためになれば幸いです！
第一の敵！「いつまでもフワフワ」登場。
まず出現した強敵が、仕様を詰める段階で、誰の頭にも最終的に成立している像が浮かばなかったが故に、いつまでもフワフワした状態が続くという問題でした。
我々が作ろうとしていたマーケットプレイスは、以下の点のかけ合わせで非常にユニークな存在でした（＝完全に参考になるようなマーケットプレイスは世界を見ても存在しなかった）。
- 現物（Physical）も先物（Future）も同じ板上で取引可能
- 様々なエリアやデリバリー期間が存在し複雑な商品構成（日本電力）を対象としたものである
したがって、enechainにいるエキスパートたちでさえも、意見がまとまらず、抽象論からなかなか具体に議論を進めることが難しかったことを覚えています。
ここで担当PdMとして「迫る開発開始の期限」と、「なかなか決まらない要件」という困難な状況をドライブするために、課題を可能な限り小さくして、その1個1個を”決めていく”ことを目指し、議論をファシリテートしていきました。
そうなると漠然と全体感で「どうしたらいいかわからない…」という状態だったものが、「ここがこうならないといけないということは、後続のここはこうなるのか！」といったように芋づる式に全体感の合意形成へとつながっていったような印象がありました。
セオリーとしては「全体感を決めてから細部へ」というのが正しいかもしれません。
しかし、その状態でフワフワとした状態が続くのであれば、手始めにワークフローの一部を切り取って具体化してみることで、後続や前段のワークフローにも前提となる制限事項が生まれ、逆に全体感の議論が進みやすくなるのかもしれません。こと今回のように前例の無い複雑なシステムの場合は、その傾向があるのかもれないと、自分も学びがありました。
第二の敵！「覆りまくる意思決定」登場。
これも第一の敵と重なる部分があるのですが、どうしても仕様策定期間が長期間にならざるを得ないプロジェクトだったので、当初に決めた意思決定が後から覆り、抜本的な要件変更をせざるを得ないことが多々ありました。 これはPdMの力不足ももちろんあるのですが、enechainが開発しているプロダクトは軒並み高度な業界知見（日本電力市場の構造・制度、顧客各社の業務、金融商品トレーディングの知識・経験）がないと、意思決定できないことが大半を占めています（※プロダクトサイドだけで決められる意思決定は少ない）。
なかなか複雑な業界かつ、業界歴数十年のExpertでないと電力トレードについての肌感をつかみづらいことが多々ある我々のビジネス特性上、当初はこの問題が度々発生してしまい、特にエンジニアメンバーには負担をかけてしまったと思います。
また、長期間（3,4ヶ月）にわたった仕様策定、要求整理のためもあって、過去にどういう経緯で、誰が、なぜこの意思決定をしたかということがわからなくなっていて、再度議論した結果意思決定が変わることもありました。
上記の要因で出現した「覆りまくる意思決定」という強敵を倒すために主に以下の2つのアクションを実施しました。
- Biz⇔Tech 意思決定DBの作成
- 本プロジェクトにおいてどのような課題（意思決定が必要だったもの）に対して、誰がどのように回答してその意思決定へとなったかを一覧で確認できるDBの作成（エンジニアでいうADRに近いかも）。
- 証跡を残すというよりは、後から立ち返ることができるためのもの（プロジェクトに途中からジョインした仲間もなぜその意思決定がされたかわかる）として運用しました。
- 全員が集まる定例で意思決定をつぶさに共有
- 意思決定について逐一プロジェクト定例（毎週開催のBiz⇔Techの全ステークホルダーが集まる会議）で全体共有を行い、その場であらゆる方面からFBを行う。
- 狭いコミュニティの中だけで決めない（一定以上の意思決定においては、Ops観点、営業観点、システム観点、事業開発観点での指摘をいれる）
もちろん、意思決定当時はわからなかった、新しい事実が今になってわかり、意思決定が覆ることはあってしかるべきだと思います。 ただし、意思決定当時から何も状況や事実が変わってないのに、意思決定だけが変わるのは、プロセスや仕組みに問題があることが多いでしょう。
完全にこの敵が息絶えたかと言われると私自身まだ胸を張って言えない部分もありますが、少なくとも以前のように一度決めた意思決定が覆りまくる状況は脱したのではないかと思います。
※「プロダクトだけで決められない、解決できない」くらいの構造的にも業界的にも難易度が高いビジネスに挑戦しているという側面がおもしろい、かつ、解決した際の社会インパクトが半端ではない、という風に思ってくれる方にはenechainは非常にExcitingな環境だと思います！
第三の敵！「知らず知らずに複雑化」登場。
enechainは本当の意味でのグローバルTech Companyを目指しています。我々が定義するTech Companyの定義を社内で10の言葉で言語化していて、その定義の3つ目は以下の通りです。
※Tech Companyの定義の意義や策定方法はこの記事に譲る
Insanely Simple enechainは、複雑化への引力に屈することなく、極限までのシンプルさを追求します。
しかし、本プロジェクトでは知らず知らずのうちに、この定義を無視した、複雑化への一途を辿っていたのです。
これまでも繰り返してきた、本プロジェクトの前例のなさ、そもそものプロセスや商品設計の複雑さゆえに、愚直にプロダクトの実現可能性を上げるためにしてきた意思決定や仕様のFIXはどれも、「こうしないとこれが実現できないからやるしかない〜」といったものが多く、次第にプロダクトは肥大化してきて、それはそれは巨大な怪獣のような混沌とした複雑さの塊のようなものに育っていたのです。
そしてこれまでのマニュアルな成約体験から、全て自動での体験を提供するというお題目の元、なんでもかんでも顧客に対しての操作、システム上で完結する設定を意識しすぎていた節もあり、このような結果を招いたとも思います。
例えば以下のようなものがありました。
- 発生頻度が低く、起こったとしてもOpsが手動で行う対応の工数が低いもの
- 精度を突き詰めることはできるが、妥協した結果と顧客が受け取るアウトプットに大きな差が出ないもの
- 顧客に任せることもできるが、ややこしい設定が故ミスが多発しそう、かつ誤った場合に他社にも迷惑がかかるもの
- 実施すれば多少顧客の利便性は高まるが、実装上はかなり複雑度と工数が増すもの
- etc…
最終的には、複雑さを含めたデメリットと、それによって得られるメリットのバランスでしかないと思いますが、無理にそのケースのために顧客やシステムに対して複雑さを強いるのではなく、こちらが時と場合によっては手動で代替する、または、極端な厳密性を求めない（あえて妥協する）といったことで、顧客やシステム、UIに複雑さを転嫁しないように努めました。
さいごに
本当はもっとたくさん、ここに書けないような困難もあったと思うのですが、なんとかその強敵たちを倒して（ときには全力で強敵から逃げたりして）、2024年10月9日にサービスローンチを迎えることができました。
このプラットフォームで初めてマッチングが行われ、初成約が発生した時、めちゃくちゃ大変だったRPGをクリアしてエンドロールを見た時のような、なんとも言えない感動を覚えました。
※初約定を喜び、皆でHigh Five！
ただし、これはまだナンバリングの1をクリアしたに過ぎません。
すぐに、「プロダクトマネジメント物語Ⅱ ~プロダクトGrowthへの挑戦~」が発売されますし、さらに強力になった敵が次々と登場するでしょう。プロダクト開発とは終わりのない冒険そのものなのかもしれません。しかし、我々ができることは、その都度、背中を預けられるパーティーメンバーを頼り、新しい武器や防具を得て、会社の夢の実現のために進み続けていくことのみです！
ぜひ、それぞれの、自分たちだけの物語を、楽しんで冒険していきましょう！
そして、もしenechainというパーティーで冒険してみたい人、興味がある人がいればぜひお話しましょう！
