課題解決マシーン化を防ぐ - クラスターのプロダクトマネージャーチーム役務の再定義

はじめに

こんにちは、2023/05 にプロダクトマネージャーとしてクラスターにジョインした Smith です！
入社ブログを書こうと思ってサボってたらテックブログを書く機会を頂きました、因果応報！

この記事では掲題の通り、クラスターのプロダクトマネージャー組織についてお伝えしようと思います。
本記事を通じてクラスターのプロダクト開発のリアルな課題や、プロダクトマネージャーチームがどんなチームかについて少しでも伝われば幸いです。

はじめに
プロダクトマネージャーってなに？
「cluster」というプロダクトの複雑さ
どうしてこうなった？ - 増えていく複雑性
クラスターの PM - 個の力は強いが…
クラスターの PM の課題 - “チーム”になっているのか？
合宿 - 泥臭く対話してシンクロ率を高める
PM チームのコンセプト
クラスターの PM - これから
まとめ

プロダクトマネージャーってなに？

読者の皆様には釈迦に説法かもしれませんが、改めてプロダクトマネージャーとは何か？について概要を示します。
本記事を読み進める上での事前知識として、プロダクトマネージャー像のイメージが統一できればと思います。
※ 本記事ではこれ以降「プロダクトマネージャー」を「PM」と表記します。（タイプ数が多いからね！）

私にとって PM と言えば及川卓也さんというイメージがあるので、氏の書籍である「ソフトウェア・ファーストあらゆるビジネスを一変させる最強戦略」から PM についての説明書きを引用をさせて頂きます。
PM とはすなわちーー

ユーザーの求めるプロダクトの理想を追求する役割で、「ミニCEO」とも呼ばれます。ソフトウェアの仕様や設計を決めてエンジニアやデザイナーに開発方針を伝え、プロダクト開発を主導するだけでなく、継続的な成長にも責任を負います。

絵にするとこんな感じですね。

全社戦略あるいは事業戦略があり、その戦略実行のためにプロダクト作りに投資するぞ、という経営上あるいは事業上の決定がなされるわけです。
プロダクトを作るためには市場のニーズやペインを調査したり、そこに対するソリューションや発明を企画して開発する、開発したものがちゃんとユーザーのニーズを満たしているか観測して継続的に改善・運用していく・・・
プロダクトのビジョンを掲げ、それを実現するための大きな取り組みを統括するのがミニ CEO である PM です。
めちゃめちゃ大変そうだけど、その分楽しそうですね！

PM のアンチパターンとして陥りがちなのが、課題解決マシーンと化してしまうことです。
私の言葉で端的に表現すると、 “意思がない状態” です。

「cluster」というプロダクトの複雑さ

ではクラスターの PM は上述したような教科書的に完璧な PM なのでしょうか。

・・・

ちがう、ちがうのよ。
PM が完璧だと言うつもりはありませんが、clusterというプロダクトがとても複雑なんです。
とりあえず、clusterの Web サイトのアプリダウンロードページを見てみましょう。

「シンプルに対応プラットフォームが多い！」

Unity という強力なエンジンで共通化できる部分は多いものの、それぞれのプラットフォームに対して最適化をかけようとしたら、基本的には別物です。
わかりやすい例だとワールド外で閲覧するワールド一覧画面で、PC デスクトップ版とモバイル版でも大きな違いがあります。
ユーザー体験の最適化を追求すると、見た目だけでなく技術的にも全くの別物になってしまうんです。

モバイル版: アプリ内で Android/iOS ネイティブの UI フレームワークで構築
PC デスクトップ版: アプリ外で Web サイトとして構築

それぞれのプラットフォームで最適な体験を考え抜いて提供していく、という役割は非常にやりがいはあるものの、とにかく複雑なプロダクトです。
もう一回くらい言っておこうかな、とにかく複雑なプロダクトです。

どうしてこうなった？ - 増えていく複雑性

前提として、クラスターという会社はスタートアップです。
スタートアップといえば、世の中に提供したプロダクトがみんなの価値になっている状態、いわゆるプロダクト・マーケット・フィット（以下、PMF）している状態を目指すものですが、当然それは簡単なことではありません。
最初にリリースしたプロダクトがピタっと市場のニーズにハマることは奇跡に等しく、良くても提供価値とニーズのズレや機能の過不足という課題が生じます。
また、プロダクトの利用者の数が増えてくると、有り難いことにそれに比例してフィードバックも増えていきます。
このように PMF を果たしていない状況下では、今まで仮説を立てて開発して提供してきたユーザー価値の原石から、磨いてゆくものと方向性を変えていくものが常に混在することになります。
その結果、プロダクトの複雑性が時間とともに増していくのです。

プロダクトが難しいだけであればまだ良いのですが、業務においても常に新規開発を実行する必要があり、その裏側では運用業務も増え続ける、という状態に陥ります。

「やりたいこと、やらなければならないことがいっぱいあるのに手が回らない！」
「少し大きな事をするためにはそれを統括できる人が必要だ！」

この混迷の時期は非常に楽しいのですが、その反面で人手不足は常に生じます。
PM 採用は進みますが、その時々のプロダクト課題によっては火急の状況下に置かれることもあり、課題解決マシーンのようにとにかくあちらこちらからの出火を防いだり消火しなければならないことも少なくありません。

クラスターの PM - 個の力は強いが…

幸いにも PM チームにジョインしたメンバーは誰もが個の力が強く、スタンドプレーによるチームワークが自然と生まれる攻殻機動隊のようなチームでした。
加えて、どの PM メンバーがどのユーザー価値領域をカバーするかという役割分担がある程度明確になっていたため、チームワークが仕組みでカバーされている側面がありました。

早い流れで変わりゆくプロダクト状況では PM の業務を定型化したり言語化することが困難で、むしろ変化に強い有機的な動き方が必要です、そんな動き方への対応力が非常に高い奴らが揃い、それぞれの守備範囲が漏れなく被りなく割り当てられるチームトポロジーが機能していたのです。　
まさに PM の個の力を最大限発揮できる環境。

対比というわけではありませんが、ここで面白いのが、エンジニア組織は既にチームで開発する epic という開発フローを確立していたことです。

tech-blog.cluster.mu

私から見てもクラスターのエンジニア組織は自己組織化が進んでおり、自律的に連携をして課題解決をしていたり、エンジニア組織のバックボーンとなる文化が継承され続けていたりします。
そのように組織づくりを大きく委譲できているマネジメントも、とても胆力があるし信頼関係が築けているので、上から目線ですが普通に偉い。

クラスターの PM の課題 - “チーム”になっているのか？

さて、PM も今や 10人で、強めの課題解決を行い続けてプロダクトを前に進めることが定常的になっていました。
しかし、我々は果たして PM “チーム” なのでしょうか？

PM の誰もが同じ言葉、同じ目線でプロダクトの未来を語れるのか？
PM の誰もが同じプロダクト開発組織のあるべきを持っているのか？
PM の誰もが大上段の事業戦略を心得ており、正しい行動や意思決定ができるのだろうか？
クラスターの中で、我々の役割は何なのだろうか？

PM チームは課題解決能力や業務遂行能力は非常に高い反面、「PM チームとは？」とか「プロダクトとは？」という問いかけは長らく保留になっていました。
これは PMF を目指す上で意図的に保留にされてきた側面もあります。

プロダクト開発当初は言語化された情報として存在したプロダクト戦略も、激しいプロダクト状況の変化と共にメンテされなくなります。

気がつくと PM チームが課題を殴りに行く構図が常態化していました。

「これでは課題解決マシーンと変わらないのではないか？」

このようなフラストレーションは、もしかしたら PM チーム外にも抱かれていたかもしれません。
シンプルに、PM チームが組織社会化されていないという問題が立ちはだかります。
このままでは船頭多くして、船、チョモランマに登る羽目になる。

合宿 - 泥臭く対話してシンクロ率を高める

ということで、PM チームで合宿を開催しました。
やろうって思ったらササッとやれる機動力も PM チームの強いところです。（実際、めっちゃ忙しいタイミングで実施した）
直接おなじトピックについて対話して意思疎通する。泥臭い方法ですが、合宿はチーミングの王道です。
今課題に感じている “チーム” について、言葉としてコンセプトや行動指針を定める体験をチームで共有することで、効率よくメンバー間のシンクロ率を高めることができます。

今回の合宿のゴールは、全員で PM チームのチームコンセプトを決めて役務の再定義をすること。
課題の直接的な解決よりも、課題に正しく向き合えるチーミングを合宿の効果として捉えています。

clusterは有期のプロジェクトではありません、プロダクトです。
我々は組織として永続的にclusterというプロダクトの課題を解決し続けることが要求されます。
そのためには組織としてのケイパビリティを向上する必要がある、つまりチームの成長が必要です。
スタートアップというとマネジメントが疎かになりがちな印象がありますが、このように組織面をしっかり意識できているのはクラスターの良い所だと思っています。上から目線ですが普通に偉い。

そして、合宿で最終的に定められたチームコンセプトは以下のようなもの。

語呂がよく、すべての要素が短くワンフレーズにまとまっているので非常に通りが良いです。
毎朝復唱したくなりますね。（してません）
このままだとよくわからないのでちゃんと解説します。

PM チームのコンセプト

世界の中心で

clusterの大きなビジョンをチームで共有し、オーセンティック・リーダーシップを持ってしてプロダクト開発に関わるみんなをclusterという世界の中心で引っ張っていこう、という旨の指針です。
グローバルで通用するプロダクトを作るぞ！という意気込みもダブルミーニングで含まれています。

つくる！

徹底的にユーザー・ファーストな目線でプロダクトを作ろう、という主旨です。
clusterは UGC によってバーチャル空間が豊かになるという特性を持っているので、「つくる」というワードにはひときわ思い入れがあります。

伝える！

これまでちゃんとできていなかった、プロダクトのビジョンや戦略、マイルストーンなどの言語化と、言語化した情報を社内に向けて理解・浸透させていくぞ、という旨のものです。
自分たちの課題を内省し、コンセプトとして反映できるチームはシンプルに心強いです。

モテまくる！

合宿でもちょっと物議をかもした言葉選びですが、あえてこのまま採用しています。
ニッチではなく誰もが触れたくなるようなカッコいいプロダクトを作ろうという主旨ですが、それをモテまくると表現することでクラスターっぽい遊び心が反映できており、結果的にいい感じに収まっていると思います。きっと。

クラスターの PM - これから

人類の創造力を加速する
バーチャル経済圏のインフラをつくる

これはクラスターが掲げるミッション・ビジョンですが、見てお分かり頂けるように主語がデカく、作ろうとしているものもデカい。
こんなデカいことをやろうとしているからこそ、本来のクラスターの PM チーム役務の再定義が必要でした。
また、合宿を機にプロダクト戦略の言語化や業務フローの整備、職掌跨ぎの業務効率改善など、PM が主導で推進する取り組みも始まっています。
この組織効力感はハンパない！私自身、チームのメンバーとして僅かながら尽力させて頂けることに対しては、正直ワクワクしかないと思っています。