この記事は enechain Advent Calendar 2023 の4日目の記事です。 本日はenechainのProduct ManagementとDesign Deskを統括しているProduct Managerの大橋が担当します。
※私自身のキャリアやenechain自体の詳細は詳細はこちらの記事で詳しく記載されているので、興味がある方はご覧ください。
はじめに
この記事では2022年9月にenechainの一人目Product Managerとして入社した私が、これまでの1年強で直面してきた課題とその課題にどう向き合い解決してきたかといったことをまとめています。
今組織内で一人で悩んでいたり、これから一人目PdMとして新天地に行こうとしている人や、なかなか経営陣やCEOからプロダクトチームにプロダクトの意思決定が移譲できない悩みがある人に読んでほしい内容となっています。
一人目Product Managerが直面したこと
私が直面してきたことは大きくわけて3つあります
（本当は50個くらいは余裕であると思うんですが、今回の記事で触れるのはあくまで一人目PdM特有かな？と思った3点に絞ってみます）
- 「Product Managerって何する人？」知名度0のPdMという存在！
- 「どっちの案がいいか、来週の定例(7日後)で決めてもらおう」意思決定スピードの課題！
- 「え、自分の担当projectが5個！？」PdM組織のスケール課題！
①「Product Managerって何する人？」
※入社初日に投稿した挨拶文「Product Managerという職種」という言い方からも社内の認知の低さを自覚している様子がうかがえる
多くの一人目PdMがまず直面するのは「そもそもProduct Managerって何する人？」という社内から悪気なく聞かれる質問に答えることから、かと思います。
enechainに一人目PdMとして入社した自分も例に漏れず、特にビジネス職の方たちから多く聞かれましたし、開発チームの中でもこれまでPdMがいた組織で開発したことないというメンバーもいたので、様々な人から聞かれ、衝撃が大きかったことを覚えています。
そんな時に口頭で「PdMとは〜〜〜」みたいに語っても正直全然理解はされないし、結局企画をする人？みたいな合っているような合ってないような微妙なラインの理解しかされないと思います。
個人的にはProduct Managerは「会社の事業上の課題を、あらゆる手段を駆使して（主にプロダクトやテクノロジーの力を用いて）解決に導く人」だと思っています。特にPdMとして一人目で入社するような規模の会社ではその傾向が顕著なのではないでしょうか（大きな規模の会社なら最近はPdMの中でも役割は細分化されてきていますが）。
enechainはeSquareという電力の卸取引のマーケットプレイスを運営しています。eSquareはお客様が使う機能だけでなく、取引所の運営や、約定後のオペレーションを行う社内向けのサービスとしても機能しなければなりません。
私が入社した当時のenechainでは
ビジネス）「業務効率化の観点でいろいろ改善してほしい点はあるけど、Techは対応してくれない…」
開発チーム）「経営からの要望を詳細化して、開発することで手一杯。社内効率化まで手が回らない…」
といった双方に課題感がありました。結果としてビジネスと開発チームの距離感が遠く、お互いに何をやっているかわからないという、一丸で進んでいくには障壁となる大きな課題が存在していました。
上記の課題解決のために対して以下の行動を行いました。
- ビジネスチーム社員の隣の席に座り、一日の流れを学ぶ、業務見学会を実施
- 日頃の業務で気がついた点や改善したいことを気軽に投稿できるSlack窓口を作成
- 要望に対してはいつ頃Releaseできるかを逐一共有（すぐに対応できない場合もその理由説明を尽くす）
- ビジネス側の業務のお困りごとや効率化を行う専門開発チームを組成（メインプロジェクトと開発のラインを明確に分ける。基本的に一生手は空かないものなので）
- RICEスコアを用い開発効率が良く（一週間くらいで開発可能な）、事業上のインパクトの大きい施策の実施件数をKPIにした体制を構築（Release頻度の向上）
- ビジネスメンバーと定例を実施し、直接エンジニアもいる場でお困りごとの詳細、非効率な部分を把握する場を設定（課題を肌感覚で理解する）
- 上記定例の場でエンジニアが1週間分の開発した成果物をデモし、実現イメージに齟齬がでないようにする。また、デモを見てみんなで盛り上がる
上記を段階別に行った結果、現場の課題に根付いた機能が続々と開発チームからReleaseされることになり、ビジネス側満足度も高まり、「とりあえずあのPdMの人に相談したらなんとかしてくれる！」といった雰囲気ができてきました。また開発チームもこれまではなかなか実感を持って利用者からの感謝が感じられなかったのが、自分たちが送り出した機能によって、社内から大きな感謝を表されるようになり、モチベーションが上がり、これまで以上に課題に対しての感度が高くなっていきました。ビジネス、開発チーム双方にとって、PdMがいるとちょっと会社が良くなった！という経験をしてもらうことができた事例です。
※該当のチームのReleaseが毎週立て続いていることに対して代表の野澤のコメント
この例から言えることとしては、まずは目に見えて皆が抱えている課題を解決することで、「Product Managerがいることで、会社が回るようになるんだ」という実例を見せることが大事だということです。enechainの場合は上記のような課題でしたが、上記に関わらず自分ができることでimpactが大きい課題を選定し、全社に対して、「PdMがいると助かる！」というイメージをまず持ってもらい、PdMというロールを認めてもらうという姿勢が必要かと思います。
上記の取り組みはサブプロジェクト的に行っていたのですが、現場の満足感が高まったり、実際の業務効率化で成果が出たのはもちろん、社内でのPdMの認知拡大、意義の理解という点でも非常に役に立ったなと思いました。
結果的に今のenechainではPdMが6人という規模にまで拡大しており、全社的に必要性や意義が理解されてきているのかなと思います！（組織の拡大話は後段に譲る）
②「どっちの案がいいか、来週の定例（7日後）で決めてもらおう」
私が入社前のenechainでも、多くの初期スタートアップと同じように、創業CEOがプロダクトの意思決定を行っており、その要求をエンジニアが実現するという形を取っていました。 私が入社して初めて参加したプロダクト定例の場では、エンジニアから箇条書きでかなり細かい挙動やボタン等まで「AとBどちがいいですか？」という質問が列挙されたリストに対して意思決定者であるCEOが上から順に答える形で実施されていました。
また、enechainは電力の卸売取引という特殊な領域でビジネスをしており、かなり長い経験と業界特有の深い解像度を必要とされます。したがって、エンジニア側ではなかなか意思決定をすることが難しいという背景も相まって、ある種降りてきた要求を実現するということがプロダクトチームの主な役割でした。
例えばその定例の開催直後に開発について悩むポイントや、どちらかの決めが必要な場面があっても、次の定例でCEOの判断を仰ぐという状態になり、結果的にプロダクトの意思決定が世間一般のスタートアップよりも相対的に遅くなっていたように思います。また開発しているエンジニアもその決めが現場で行えないことにより開発が思うような速度で進まなかったり、自分たちの意思をプロダクトに反映させる機会が減っており、一定のフラストレーションを溜めていたようにも感じました。
もちろん創業初期にCEOがProductの側面もカヴァーすることは多いでしょうし、創業から時間が経過してもプロダクトのコアな世界観、絶対に外してはいけないことなどはCEOといった事業側のPOを含めて意思決定していくこともあると思います。しかし、当時でもCEOは多忙を極め、なかなかカジュアルにいつでも相談できる状態ではなかったので、当時の私としては早くこの決めの部分をCEOから引き継げるようにならなくてはと意気込んだのを覚えています。
意思決定の役割をCEOから引き継ぐというのは、ただ今日から引き継ぎます！と言って済むものではありません。ここまで手塩にかけて育ててきたプロダクトの意思決定を引き継ぐ側の立場に立った時に以下の点が気になると思いました。
- 要所や適切なタイミングで相談やヒアリングをしにきてくれるか？
- AかBを選ぶ基準が論理的で自分（CEO）の中のセオリーと大きなズレがないか？
- 業界特有の知見なども思い込みではなく、適切に把握して理解を進めているか？
1つ目は、やはり、自分が全く関与しなくなり、重要なポイントも知らぬところで決まっていて、それが自分として絶対に選ばない選択肢だと後から気がついたりするのは一番避けたいことです。 そのために釈迦に説法ではありますが、報告、連絡、相談のホウレンソウをしっかりと意識することが必要です。最初は頻度高めに行うことで、引き継ぐ側が欲している適切なタイミングを図ることができますし、重要なポイントでは自分も意見を反映させることができるという安心感に繋がります。
2つ目について、まずそもそもPdM等が行うプロダクトにおいての意思決定では、ほとんどの場合一定水準以上の人であればそこまで結論が変わらない意思決定をしていると個人的には思っています（いつも特別な意思決定をしているわけではないという意）。 ただし、この一定水準以上のというところが大事で、同じ事象を見た時に、論理的に、もしくは顧客を想像したときに、「この件なら、さすがにAを選ぶよねー」といったある種のセオリーを引き継ぐ側と引き継がれる側とで共有していることが重要です。 そのためにも引き継がれる側は相手の意見を伺う際に、「私は〜〜という理由でAかなと思うんですが」というように、先に自分のスタンスを理由と共に常に伝えることが必須です。そうすることで引き継ぐ側としては、相手の思考パターンがわかり、自分と相違がなければ安心して意思決定を引き継げますし、もし結果に相違あったとしても、プロセスのどこに修正が必要か把握することが容易で結果的に引き継ぎも早く終わるでしょう。
3つ目は、いきなりCEOとの知識差を無くせという意味ではなく、日を追う事に業界の知識、用語、概念、パワーバランスといった情報を適切に吸収していっているなと感じさせることが重要です。実際にアンラーニング力とでも言うのかもしれませんが、興味を持って取り扱っている業界のことを知ろうとする人か、そうでないかで引き継ぐ側の気持ちは大きく左右されることと思います。その姿勢があれば、1つ1つ解くべき課題に当たった時に周辺の知識を増やしながら解決していってくれるだろうと思うことができ、これまた信頼感につながっていきます。思い違いや、そもそも理解が遅い、理解する気がない…という状態では、なかなか任せることはできません。
※また、企画プロセスの見通しをよくするためにワークルールも策定し共有していた。これによりどこでチェックを入れることができるか？などが明確になり安心感にも繋がる
上記のようなことを意識し、初期はCEOとの1on1なども意識的に増やしてもらうなどして対話の時間を多く取り、引き継ぐ側のCEOも安心して任せられるように意識しました。 結果として、比較的短期間でプロダクトの意思決定について多くの部分をプロダクトチーム内で完結させることができるようになり、開発速度が上がり、以前よりもプロダクトやユーザー体験をチームメンバーが自分ごと化して考えられるようになってきたように思います。
③「え、自分の担当projectが5個！？」
そんなこんなで、徐々にPdMという職種への理解も深まり、開発もプロダクトチームを主体としてサイクルが回るようになってきた頃、会社の事業自体も大きく成長していきました。会社の成長とともにプロダクトの数も増加し、また既存プロダクトの中でも大規模な新規機能等の開発が必要とされてきて、加速度的にプロジェクトが増加してきていました。
気がつけば私一人が抱えるプロジェクトが4つ、5つあるといった状態も珍しくなくなり、Product Management組織の拡大を真剣に検討しなくてはいけないフェーズでした。
ここでも一人目のPdMに課される役割は大きいと思っています。
昨今多くの企業でProduct Managerを募集していますが、Job Description上でProduct Managerと書かれていても、10社あれば10社で欲しているProduct Manager像はきっと異なります。
開発管理に重きをおいてほしい企業もあれば、どちらかといえば社内のステークホルダーの調整事に比重をおく企業もあります。また、規模の小さな会社では、BizDevのような役割を担うProduct Managerもいます。本当のプロダクトマネージャーの職域はこうだ！と言うつもりはありません。私の定義で言えばそれぞれが事業の成功のためになんでもやるという意味でPdMとしての正解だと思うからです。
ただし、組織を拡大する際に、候補者の方のWillと異なることを押し付けてしまうことになったり、また自社が求める像に合致しない採用をしてしまってお互いにミスマッチになることを避けなくてはなりません。
これまで過ごしてきた一人PdMの時代を振り返り、自社が求めるProduct Manager像は何か？自社のPdMとして絶対に外してはいけないことは何か？を突き詰めて、ベースとなる経験やスキルの基準を定めていくことが重要です。そのベースの基準が揃ったうえで、各個人個人の強みや特殊な経験が多様に発揮し合える組織であればそれがBestな組織だと思っています。
弊社enechainの場合は、複雑で難しい知識（電力業界×トレーディングの世界）を要する業界のサービスを運営しており、「プロダクトチーム内だけで何もかも決めれる」、とか、「開発だけしていれば世の中に広がる」、というようなプロダクトを運営しているわけではありません。 そもそも、なかなか想像がつかない業界、常識の中で開発を進めていくには、社内にいる業界の先人たち、エキスパートであるビジネス側の人間と協働することが不可欠です。
そのような理由から以下の点は他の企業よりも重要視していました
- アンラーニングすることを厭わないか？（興味を持ってニッチな電力トレードの世界を学べるか？）
- 過去にそのような未知の環境に飛び込んで強烈なアンラーニングした経験があり、その方法に再現性はあるか？を問う
- 異なる職種（ビジネス側）の人とも、背景を慮りつつ、遠慮せず対話を行うことができるか？
- 選考プロセス中にビジネス側のPOとの面接を設定し事業についてディスカッションしてもらい、ビジネス側社員から評価してもらう。短時間で相手のことや事業構造を理解し、鋭い質問や議論ができるか？を問う
選考中には「ユーザー中心のものづくりの考え方ができるか？」「これまでの成功体験を抽象化して再現性があるものにできているか」等のPdMとして当然のスキルは見ますが、上記2つはenechainとして特に重要視して、複数の目で多角的な質問から明らかにしようとしています。
一人目PdMが苦労しながらも蓄積してきたノウハウや、感じたことの抽象度を上げて、この組織で貢献できるProduct Managerとは？を定義し、さらにそれを見極められるような選考設計をすることでミスマッチを可能な限り抑えた組織拡大が行えるのではないでしょうか？
今や6人となったenechainのProduct Management組織でも、PdM個々が各Projectの中でビジネス側と喧々諤々の対話を繰り返しながら、その上で皆が素敵な個性を発揮してくれています。
さいごに
ここまで私自身が直面してきた課題について、どのように解決に動いたかを交えて書き記してきました。全く同じ状況とは言わないまでも、似たようなことがあるとか、これから1人目Product Mnagerとして新しい環境に飛び込むといった人々の元に届いていたら嬉しいです。
この記事を書いていて、たくさん課題があったなと思い出しました。当時はなかなか理解されないもどかしさや、解くべき課題の多さに悩んだり、不安になって焦っていたりもしたかもしれません。でも、今思い返すとそれは全然つらい思い出じゃなくて、深い満足感とやりがいに満ちていました。今課題があっても、それに対して全力で向き合って行動してきた経験はProduct Managerとしての引き出しになっていくし、今後対応できるキャパシティを広げてくれているんだなと、改めて感じました。
Product Managerは楽しい！
一人目PdM万歳＼(^o^)／
enechain現在募集中の職種は以下から確認できます！
