見出し画像

結果を出すプロダクト開発体制の試行錯誤と、プロダクトマネージャー組織の責務とスキル定義

板倉美奈/PdM

ランサーズ株式会社でlancers.jpの事業部長をしている板倉(@idemii)です。

この記事はランサーズ Advent Calendar 2021 21日目の投稿です。昨日は @ktplatoさんの コードリーディングのススメとTips風 〜CakePHP4の例を添えて〜 でした。

こんな人に読んでもらいたい
・これから組織拡大しようとしているプロダクトオーナー
・プロダクトマネージャーに任命されたが身に付けるスキルに悩んでいる人

こんなことが書かれています
・事業部門のプロダクト開発体制４種類について、事業/品質/チームビルディング観点での失敗と成功
・プロダクト開発体制における責務範囲の決め方
・プロダクトマネージャーに必要なケーパビリティとスキル定義

はじめに

お久しぶりです。昨年のAdvent calendarから、1年ぶりの投稿です。
この1年は事業部長として、事業推進中心にビジネスオーナーとしての仕事が多く仕事内容はシフトしています。顧客や事業課題に向き合うかたわら、PdMが属する企画チームのマネージャーとして「結果を出す」組織をどう作るかについても、悩んでいる毎日です。

そんな中で、1人だったPdMが4人になり、いろんな課題に遭遇してきました。
試行錯誤を紹介する事で、これから組織を作る人、同じ壁にぶち当たっている人がいたら何かのヒントになれば幸いです！

事業部門のプロダクト開発体制変遷と課題

VPoE/開発部 部長の倉林の記事「ランサーズのエンジニア組織のこれまでとこれから。エンジニア組織における10人、30人、50人の壁。」に書かれている通り、2017年以降エンジニアの部署を開発部門と事業部門に分けることにしました。
私からは 、2018年以降の事業部門の体制変遷を一気に振り返り、特徴と課題についても合わせて紹介します。

2018年　エンジニア主体超グロースハック時代

2018年のプロダクト組織ではディレクター/プロダクトマネージャー単体責務の人が事業部門におらず、ディレクターは新規事業に配置されていました。
ユーザー目線で企画ができる「サービスリード」と呼ばれるエンジニアが多く、エンジニアが自ら企画を出して開発をするというパワフルな時代です。私はWebディレクションの業務を中心としたマーケターでした。SEOの内部対策/アクティベーション最大化の役割でプロダクト側にお邪魔していました。

■この体制の特徴と課題
 [ビジネス] 小粒な改善系の施策が多く、事業成長インパクトが少なかった
[品質] 短期間でのスピードリリースで、仕様品質が甘くリリース後にバグ修正も多かった
[チームビルディング] 職種の垣根なく意見が活発で良い雰囲気だった

エンジニアがペルソナを設定し、調査と顧客課題を活発に議論していたslack

2019年　チーム固定でプロジェクト付与時代

2019年は私がマーケティング部から異動し、プロダクトマネージャーとなりました。
２名のプロダクトマネージャーが課題設定のための分析、ユーザー調査に時間をかけることができ、より精度高い施策を打つことができるようになりました。
過去記事で紹介した仕事ランク(AI判定)の施策もこの時期で、大きなポジショニングの変化を生み生み出すことができています。

個人を振り返ると、まだリスクサイドの設計は下手で顧客からお問い合わせが殺到！といったことも経験しました。

■この体制の特徴と課題
 [ビジネス] 中期と短期施策バランスよく仮説検証、事業成長インパクトが出た
[品質]属人的に品質担保はできていたが、短納期の施策はよくプロダクトオーナーから指摘があった
[チームビルディング] 各人の責務範囲が明確化し、建設的に求め合えた

2020年　ウォーターフォール時代

この頃から品質やスコープが最重要課題となりました。
スピード速く仮説検証し成長を追い求めるあまり、一部スコープしか対応していないことも多かったです。追って顧客から問い合わせが入りバグ対応の差し込みで計画が崩れたり、技術負債が溜まり開発工数が大きくなったりしていました。
みんな大好き@t_wadaさんの「品質を犠牲にすれば長期的には致命傷になる」をまさに体現している状態です。

そこで、「ちゃんと作ろう」を合言葉に、具体的には以下の取り組みをしていました。

  • 「ウォークスルー」と呼ぶデモ会を開発知識有識者に向けて行う

  • 致命的な負債は、リファクタリングプロジェクトを立ち上げて解消する

  • プロジェクト内でプチリファクタをしながらコードを綺麗にしていく

また事業観点で、大きな仮説検証をする必要も出てきました。ここでも「ちゃんと作ろう」を合言葉に、企画と開発の距離を置いて四半期前までに事前に企画が済んでいる原則になりました。

楽観/悲観での事業計画を立てて複数シナリオでリスク対処設計や長期計画をたてるビジネス検討をしてから開発開始します。
工期が長くかかるため後戻りの難易度も高いので、市場に出して仮説検証をするのではなく、BtoBでよくある手法で事前に顧客へ提案資料を見せて有用性を確認したりをよく実施していました。

とはいえ以下の通り実際に売りにいくと突然手のひらを返されることもあり、まだまだ方法は悩ましい限りですね・・・


■この体制の特徴と課題
 [ビジネス] 中期振り返ると、事業成長インパクトあり。即時P/L影響は出ずやや不安な時を過ごす
[品質]バグや障害が減った。一方でプロジェクトが終わると解散するため「作りっぱなし」問題
[チームビルディング]受託っぽいという意見。責務範囲はより明確だが生産に集中するため結果に向き合う人が少なくなる

2021年　イシューによるミッション時代

2020年の中盤から経営戦略によりプロダクトに投資する流れとなり人員が増えました。エンジニアも増えますし、現時点でプロダクトマネージャーも私を除いて4名となりました。めでたい！
一方で、指示を求められたり質問が多くなり私が組織拡大のボトルネックになってしまうという危機感。
4名のプロダクトマネージャーに意思決定の権限委譲を行わなければいけない、lancers.jpという巨大ワンプロダクトで責任範囲を分割する必要が出てきました。

事業成長の大課題を分解し、3つのイシューを定義し解決策立案や実行の意思決定の裁量を渡しました。
ちなみにイシューの例としては、「適正なマッチングに課題があるからそれを解消しよう」といったものです。（詳細内容については企業秘密！）

また、結果に対するコミットや「作りっぱなし」ではなく、生産したものを長期的にメンテナンスするべき。
という開発マネージャーからの提案で、企画と開発の距離を近くし、チームを固定化することで安定的に同じミッションに向かうという体制となりました。

■この体制の特徴と課題
 [ビジネス] 即時P/L影響は出ず不安な時を過ごす
[品質]技術負債仕様負債を解消できた。解散しないのでバグ解消もしやすい
[チームビルディング] 前年ウォーターフォールからの反動でみんなで一緒に考えることを重視しがち。責務範囲が曖昧になり少し効率が悪くなる

PdM拡大組織で結果を出すためのチャレンジ

組織を拡大していく上で、仮説検証の数は増え様々なことにトライできるようになりました。一方で課題もらいくつか浮き彫りになりました。

  1. チームとして距離が近くなると、意見が活発になるが責任範囲が曖昧になる

  2. PdMのケーパビリティとしてどうキャリアアップするか不明確

  3. 仕事の受発注という事業ドメインの難易度の高さと、市場環境の厳しさのため、複雑度が高い課題解決が必要

そもそもプロダクトマネージャー自体がやること多過ぎて大変だというのに、コロナ渦でリモートの業務スタイルや複雑度が高い事業のため苦悩していた1年でした。
ここからは格好良いことばかりではなく、どちらかというとチャレンジしている途中の内容ですが紹介します。

チャレンジ1.PdMとエンジニアの責務範囲ルールの設定

■課題
「チームとして距離が近くなり責任範囲が曖昧になる」

エンジニアも結果にコミットする体制にしたことで、全員で課題や施策について考える時間が増えました。ある意味とても良い事ですが、要件検討時間が増えて開発に時間が避けないという声が増えてきました。

企業によってエンジニアの守備範囲、プロダクトマネージャーの守備範囲は大きく異なります。

前職や過去経験から「ここまでやってくれるだろう」という忖度やお見合いが発生し、気付いたら誰も実施しておらず漏れて遅延、上流工程が曖昧でコンセンサスが取れないという状況が発生しました。

■解決策
責務範囲のサンプルを明示し、以下ルールを定めました。

  • チーム人員の追加変更があった場合には「必ず責務範囲を話し合うこと」

  • 組織全体で責務範囲の固定はしない。スキル多様性の採用をしているので、紋切り型に同一を目指さない

キックオフ時に議論をするためのサンプル

このツールを使って議論することにより、漏れがなくなり、適切にマネージャーに不足ケーパビリティに対する要求も上がってくるようになりました。

責務範囲については、複数企業の勉強会や多くのPdMと話しましたがどの会社も異なります。
プロダクトマネージャーの採用面談で多くの方とお話ししましたが、プロダクトマネージャーという言葉が一人歩きしており弊社業務にFITしないケースも多かったです。

ここからは個人的な余談ですが、責務範囲を決定する要素は以下の３つの変数があると感じています。

  • 価値検証のスタイル（スピード/ビジネス検討精度)

  • 製品の品質に対する厳しさ(企業マインド+ビジネスモデル）

  • 上記でプロセス有無決定後の、メンバー相互のスキルの守備範囲

極端なことをいうと、toCでアイディアをどんどん出してA/Bテストしていこう！というサービスとtoBで顧客に専属営業が付いている高額SaaSでは求められるプロセスも違うという話です。

チャレンジ2.PdMテクニカルスキルの定義

■課題
「PdMのケーパビリティとしてどうキャリアアップするか不明確」

プロダクトマネージャー未経験のメンバーも入るに伴い、「企画」というものの範囲が広く何をして良いかわからなくなります。
アイディア出すだけが企画ではない、では一体どんな業務をすれば精度の高い企画に近づくのか？何を学べば良いのか？を伝える難しさを感じていました。

ここでよく登場するのがプロダクトマネジメントトライアングルです。
最も有名なプロダクトマネジメントトライアングルは「言い値」というか雰囲気でマッピングできてしまうため、どのくらいのレベルで習得しているかがわからないという課題があり未経験メンバーに適切なフィードバックができないという課題もありました。

■解決策

そこで参考にしたのが、オカダヤスヒロさんのPM Skill HEXです。

https://note.com/diskdusk/n/nfbefe8d9e762

うちの会社なりにアレンジして、以下のようなスケールで習熟度合いも図れるうようにしました。

1.プロジェクトマネジメントディレクションのスキル
4.グロースハックマーケティングのスキル

ところが、ここで問題が発生します。
エンジニア出身の上司（役員）が、開発実装も企画もビジネス観点の事業管理や事業シミュレーションも全てカバーしていました。私もどちらかというと手を動かしてなんでもやるタイプです。組織が小さいうちはどうしてもスーパーマン、悪く言えば器用貧乏なタイプが重宝されるというのは事実です。

一方で採用していて感じたのはそんなスーパーマン、採用市場にほとんど居ない。それに気付くのに約1年くらいかかりました。
チャレンジ3に続きます。

スーパーマンである上司のテクニカルスキル。広い！

チャレンジ3.ソフトスキル、PdMのコンピテンシー定義

■課題
「仕事の受発注という事業ドメインの難易度の高さと、市場環境の厳しさのため、複雑度が高い課題解決が必要」

Yusuke Hisatsuさんの「システム思考とプロダクトマネジメント」によると、プロダクトマネジメントは社会、マーケット、ユーザー、自分、事業、組織、人と7つの複雑系に向き合っています。
それぞれの「複雑系」には複数の課題と因果があり超大量です。

・複雑系は再現性が低いため、フレームワークを使えば必ず成功するわけではない
・特に対峙する複雑系に対する解像度が荒いと表面的な対処療法になりやすい

Yusuke Hisatsu「システム思考とプロダクトマネジメント」

メンバーの企画に対して毎度ひろゆきばりに「それって思いつきですよね？」と指摘しているうちに、対処療法ではない型化されていないレベルの課題設定が必要。
手法はいろいろあれど、所謂ビジネスマンの基本動作であるソフトスキル≒ビジネススキルが過去の活躍人材には共通して備わっていることに気づきます。

■解決策

活躍人材と相関があるスキルの明示、さらにそのスキルの源泉となるコンピテンシーリスト（仮）を作りました。

プロダクトマネージャー コンピテンシーリスト

作成プロセスは以下です。

  1. PdM問わず自社で活躍人材の共通スキルを経営陣から聞く（青色スキル）

  2. 他企業の事例を参考に評価定義を聞く（黄色スキル）

  3. プロダクト部門役員とPdM活躍人材行動≒コンピテンシーについて議論する

なお、2の大分類やスキルはHiroki Noguchさんの「PMスキル・評価制度を導入し、アウトカムを生み出すプロダクトマネジメント集団へ進化する道のりの共有」をかなり参考にさせてもらいました。

その他いろんな会社の方に根掘り葉掘り「どう評価するのか」「どんな業務なのか」をかなり質問させていただきました。ありがとうございました。

■閑話休題
では、テクニカルスキルは必要ないか？でいうと企画チーム組成時に必要です。
プロダクトマネージャー同士のバックグラウンドで、この凹凸の尖っている部分を補い合う必要があると思います。
エンジニア出身だけで構成されたPdMチームは弱いし、マーケター出身だけで構成されたPdMチームでも弱い。PdMとしてスキル補完し合うことで最強の組織になります。

理想のチームの例


今後の予定

他にも細かいところですが、「結果を出す」組織になるためにどうすれば良いか試行錯誤しています。

  • 重複作業が発生しているため、「Dev-Ops」ならぬ「企画-Ops」って必要では？

    • データの民主化を進めるためにダッシュボードを整備したり

    • バックログ未満のユーザーボイスをどうGoToMarket部門と共有するか考えたり

    • バックログを責務範囲分解して整理することにトライしてみたり

  • スピードをもう少し出すために、来年度の責任範囲の分解方法を考えたり

  • もう少し委譲権限を狭くしたらどうなるか考えてみたり

まだまだチャレンジは続きます・・・。他の会社でもPhaseによりスタイルを変えて試行錯誤している会社が多かったので、きっとプロダクトマネージャーという仕事は難しいのだとやっぱり思います。

これらのツールもまだ自社内では逐次アップデートしていこうと思いますし、ぜひ他の会社の事例も聞いてみたいと思っています！

よかったら、情報交換からでもお話ししたいです！
エンジニアも募集中です！




#プロダクトマネージャー#PdM#プロダクトマネジメント#アドベントカレンダー#プロダクトオーナー

この記事が気に入ったらサポートをしてみませんか？