プロダクトの成功に対して大きな責任を担う「プロダクトマネージャー （PdM）」という存在。しかし、優秀なPdMは引く手数多の状況にあり、各社がその採用、育成に苦戦している状態だ。

弁護士ドットコム株式会社 が2015年より展開する、契約マネジメントプラットフォーム「クラウドサイン」。同事業を製品の観点からけん引するのが、プロダクトマネジメントグループだ。

GMとして同グループを率いる開（ひらき） 祐貴さんは、入社時はPdMのプレイヤーとしてジョインしプロダクトをリードしていたが、直近1年ほどは、より社会の期待に応えられるサービスを作るため、製品開発プロセスの可視化や、PdM育成のステップ構築を中心に、PdMのパフォーマンスを最大化させるための組織づくりに取り組んできたという。

現在ではプロダクトマネジメントグループを、仮説検証を主体的に推進する「ディスカバリーチーム」と、アジャイル開発におけるPOを務める「デリバリーチーム」に分け、各自の強みや志向に合わせて専門性を強化できるプロセスを構築。入社後にまずはデリバリーチームに配属することにより、PdMとしてのスキルアップを目指す仕組みを確立している。

加えて開さんは「PdMはあらゆるステークホルダーに挟まれ、とても孤独になりやすい職種。だからこそ、PdM同士の横のつながりやコミュニケーションも重要」と話す。

実際にグループ内でのデイリーミーティング等を実施するなど、一人ひとりが「プロダクトや組織の全体感」を養いながら、情報のシンクと組織の学びを最大化することにつなげているそうだ。

今回は開さんに、クラウドサインの製品開発プロセスの全貌から、PdMが担う役割や育成を含む組織づくりについてお伺いした。

「Rule Re:Maker」として、社会の「ふつう」を再定義していく

僕はクラウドサイン事業本部で、製品企画を担うプロダクトマネジメントグループのGMをしています。入社は2020年5月で、クラウドサインでは当時5人目のプロダクトマネージャー（以下、PdM）でした。

クラウドサインは、契約の締結から管理までをデジタルで完結させる契約マネジメントプラットフォームです。現在、サービスを支える組織は、プロダクト開発、マーケティング、セールス、カスタマーサクセス、アライアンスなど、さまざまなミッションを持った部門で構成されていて、僕はプロダクト部門に所属しています。

そして、その中でもPdMが特に一緒に仕事をすることが多いのがデザイナー、エンジニア、SRE、CRE、QAやPMMなどのチームです。

▼プロダクト部門の組織構成（同社提供）

実際に開発をする際には、デザイナー、エンジニア、PdM数名ずつから組成されるLane（レーン）と呼ばれるスクラムチームで開発を進めます。

Laneのメンバーは基本的には固定されており、四半期や半期、長い場合は年間を通して一緒に動くことで、Laneの練度やメンバー同士の信頼関係を上げることを意図しています。

そしてプロダクト開発において大切にしているのが、クラウドサインとして掲げているミッション・ビジョン・バリューです。

▼クラウドサイン事業本部のMVV（同社提供）

中でも、ミッションである「Rule Re:Maker」は一番大きい存在です。社会の「ふつう」を再定義して、世の中をもっとシンプルにするために、クラウドサインが課題解決を行えているだろうか、という問いは、実際に会話の中でも出てくることが多いですね。

クラウドサインにおける製品開発プロセスの全体像とは…

クラウドサインの製品開発プロセスの全体像は、このようなフローになっています。

▼クラウドサインの製品開発プロセス（同社提供）

まずは、製品開発の前提として事業戦略があります。市場における優位性を獲得するために、何をやるのか・やらないのか、ということですね。

続いて製品戦略は、製品としてその時点で強化するポイントや、優先的に開発しないことを決めるものです。セキュリティ観点や技術トレンド、競合プロダクトの状況などを加味しながら、その時点で何を製品として重視するのかを定めた上で、次のプロセスであるエピックリストに入っていきます。

エピックリストは、一般的な言い方でいうロードマップに近いイメージです。「どの順番でお客様の課題を解決していくか」という優先順位を表したリストです。

このエピックリストの上位にある課題から一つずつ、PdMが仮説を検証していきます。もう少し詳しく言うと、ここではまず「誰のどんな課題をどう解決するのか」について、仮説を立案します。

その中で、解像度が低い部分についてはユーザーヒアリングや分析といった検証を行いながら、課題の深掘りと構造を見極め、さらにその課題に対するソリューションや狙う市場、顧客ペルソナ、初期リリース時点の機能スコープを定めていきます。

そして、ユーザーストーリーマッピングから初期スコープを切った、ユーザーストーリーリストをもって、アジャイル開発へと進んでいきます。

アジャイル開発は、仮説検証プロセス担当のPdMからアジャイル開発プロセス担当のPdMが、ユーザーストーリーリストを受け取るところからスタートします。そのPdMは、Laneのプロダクトオーナーとして、ユーザーストーリーリストをプロダクトバックログに転換し、アジャイル開発を推進していきます。

そして、無事にデリバリーが完了したら、リリース後の検証を経て、またエピックリストに新しい課題として戻っていく…というサイクルになります。実際には、ここまでかっちりしているわけではなく、もう少しグラデーションがありますが、基本的にはこのプロセスに沿って開発しています。

結果的に、このようにプロセスを可視化したことは、PdMやエンジニア、デザイナーはもちろん、セールスやCSから見ても良かったと思います。彼らも当然、プロダクトが作られていくプロセスにはとても興味を持っていますから。

3ヶ月後、半年後、1年後、お客様に対して、クラウドサインがどう進化していくのかを透明化していくためにも、大事なことだったと考えています。

市況の変化で「ディレクター」ではなく「PdM」が必要になった

実はプロダクトマネジメントグループは、僕が入社した頃は正確には「ディレクター」という調整役的な役割だったんです。2021年に今の名称に変わったのですが、その大きな背景は、市況の変化により組織として求められる役割が変わったことです。

具体的には、コロナ禍になったこともあり、エンタープライズや行政のお客様を中心に本気でクラウドサインを導入したい、場合によっては一部署だけでなく全社導入をしたいというお客様も増え、ユーザーの課題が当初の想定からガラッと変わりました。

ただし、我々が新しいユーザー層の課題を本当に熟知していたかというと、そうとは言えない状態でした。

ですので、よりユーザーのことを知った上で、イチから仮説を立てて検証する必要があった。そうなると、どちらかと言えば調整役を担うことが多いディレクターではなく、プロダクトの方向性を仮説検証しながら示すPdMとしての役割が必要になったんです。

加えて、一口にPdMと言っても、やはり仮説検証が得意な人と、アジャイル開発プロセスが得意な人、戦略やロードマップの策定、製品の全体観をみるのが得意な人という違いがあります。そこで、グループ内でさらに「ディスカバリー」と「デリバリー」の2チームに分けて役割分担をすることで、専門化をしていきました。

ディスカバリーは、仮説検証を主体的に推進する役割を担うチームです。プロダクトやマーケット、ドメインや技術トレンドの理解はもちろんのこと、ロジカルシンキングや仮説立案、発想力、プレゼン能力といった、ビジネス的な力が必要になる役割だと考えています

一方でデリバリーは、アジャイル開発のプロセスにおいて、各レーンのPOの役割を担うチームです。エンジニアやデザイナーと協働することも多いので、彼らをリスペクトしながら、うまくパフォーマンスの最大化を支援していくスキルが必要になります。

また、プロダクトバックログの詳細を詰めていく必要があるので、ある程度はWebに関する技術を理解していることも必要です。

このようにチームを役割ごとに分けることが、PdMの育成にも繋がっていきました。

ユーザードメインの理解を深めながら、PdMとしてのスキルを高めていく

現在のプロダクトマネジメントグループでは、もともとはエンジニアだった人や、SIerのPMをしていた人、SaaSスタートアップで事業開発をしていた人、マーケティングオートメーションツールのカスタマーサクセスをしていた人など、さまざまなメンバーが活躍しています。

こうした多様なメンバーに活躍してもらうための大前提としては、まずアサインする業務を工夫しています。先ほどのチーム分けで言うと、デリバリーチームでアジャイル開発のPO、もしくはサブPOからスタートしてもらっているんですね。

仮説検証の段階では、ゼロベースのWhyの設計が求められますが、アジャイル開発プロセスではある程度確からしい方向性があった上でモノを作っていくことができます。そのため、プロダクトやお客様の課題への解像度が、仮説検証のプロセスほどは高くなくても十分に活躍できるんです。

アジャイル開発の経験を通じて、プロダクトとお客様の課題の理解や、共に動くエンジニアやデザイナーの特性をつかんでいきます。そして、徐々に仮説検証やエピックリスト、製品戦略…へと役割を広げながらPdMとしての経験を積んでスキルを高めていく形にしています。

以前はこうしたやり方ではなく、タスクフォースのような形で都度チームを組成していました。ですが、プロジェクト開始の段階では、何を作るかも不明確な状態であることが多いですよね。

その状況で、エンジニアやデザイナーが何を作ればよいのか？ またその作ったものが本当に使われるのか？ といった点は、多くの場合は不確実性が高い状態でした。

加えて、このやり方ではタスクごとにチームが作られ、都度解散するので、一人ひとりの強み弱み、大切にしている価値観、蓄積してきた人間関係や信頼を次に活かす…ということができなくて。

こうした課題を解決するために、製品開発のプロセスを整備しつつ、フェーズごとのPdMの適性を見極めながら、育成プロセスを構築していきました。

そしてもう一つ、育成という意味合いでポイントかなと思っているのが、プロダクトマネジメントグループ内でのコミュニケーションと、横のつながりの強化です。

というのも、PdMって、あらゆる方面からのステークホルダーに挟まれてとても孤立化しやすい職種だと思っていて。精神的にも大変ですし、スクラムチームの中でも、常に前向きにチームをリードしなければいけないシーンもあります。

そこでプロダクトマネジメントグループでは、デイリーで30分のミーティングを実施しています。そこでは、エピックリストにあるAという課題を仮説検証している人や、アジャイル開発のBレーンのPOの人など、それぞれの視点から見えている情報を共有しています。

それによって、誰もが自分の担当領域以外のところで何が起きていて、他のPdMは何に課題を持っているかという情報に触れ続けることで、製品全体を見る力を少しずつ養っていけるようにしています。

またこのミーティングは、各メンバーが課題に感じていること、迷っていることを相談する場でもあります。

PdMはスピーディに意思決定をしなければいけないことが多いですが、「果たしてこれでよかったんだろうか」「◯◯さんだったらどうするだろう」といったことを話すことで、組織の学びを最大化し、経験値の浅いメンバーの成長にもつなげています。

国民的サービスを目指し、プロダクトマネジメントをより進化させる

これまでを振り返ると、プロダクトマネジメント組織を作るにあたっては、やはり「Why」の部分、特にその時点でのやる or やらないや優先度の上げ下げに関する意思決定や意図などを、随時ドキュメント化しておくことがポイントだと思います。

というのも、プロダクトのWhyはあっても、それがCEOだったり、誰かの頭の中にしかない、というケースも多いのかなと。まずはそれをしっかり愚直にドキュメント化していって、誰もがアクセスできる状態にしていくことが、最初はとても重要だと思います。

もう一つのポイントとしては、Whyを設計した上で、それが社内やお客様と認識のズレがないか、合意をきちんと取っていくことです。

PdM主導で独りよがりにWhyを可視化していったとしても、それが実際のお客様の課題と全くずれているケースもありますから。そこは、きちんとセールスやカスタマーサクセス、パートナーセールスなどのステークホルダーを巻き込んでいくことが大事だと思っています。

PdMの役割も、事業や組織のフェーズに応じてもちろん変わってくると思います。例えば人数が増えていくと、当然ですがどうしてもピープルマネジメントを担うリーダーが必要になりますよね。

加えて、プロダクトが大きくなっていくと、全体を俯瞰して見られるような、ある種、専門性の高いPdMが必要になってきます。

弊社でもPdMはどんどん育ってきていますが、まだ僕が戦略部分を見ながらピープルマネジメントをしている状態なので、これからどんどん任せていきたいと思っています。

また、まだまだLane（スクラムチーム）は増え続けますし、組織の中にも空きポストがたくさんあるので、メンバーも増やしていきたいですね。

現状は、仮説検証とアジャイル開発に主にメンバーを張っているのですが、製品戦略とエピックリストの部分、製品全体をみる役割などもっと様々な役割のPdMが必要で。ここは、現状では仮説検証をやっているメンバーの次のステップでもあると思っています。

事業としては、事業責任者の橘がよく言う言葉でもあるのですが、クラウドサインを「国民的サービス」にしていくことを目指しています。エンタープライズ企業や自治体はもちろんのこと、中小企業も含めて日本中400万社の企業の皆様に使っていただくプロダクトにしていきたいんですね。

そのためには、この1、2年で「電子契約といえばクラウドサインなんだ」ということを、より一層市場に示していくと共に、誰でも安心安全に使えるシンプルなプロダクトを作っていくことが、とても大切だと思っています。（了）