実録：PMを組織化する、6ヶ月間のプラクティス
こんにちは、かこもえ（@kakomoe3）です。
株式会社カミナシ🐐でPM（プロダクトマネージャー）をしています。
📖 このnoteはなに？ 📖
私がカミナシに入社して6ヶ月、7月にPMチームができて3ヶ月経ちました🙌
その6ヶ月間の実録として、PMチームを組織化する過程での課題と取り組みについて書きたいと思います💪
📖 誰のためのnote？ 📖
・1人目PMや、これからPMチームを組織化していきたいと思っている人
・カミナシのPMって何やってるの？気になる！という人
・加古は最近元気かなと心配してくれている人
PMチームが7月にできました
私は2022年4月にカミナシに入社をしたのですが、当時カミナシの専任PMはおらず、CSチームのリーダーがPMを兼務していました。
さすがに兼務は厳しい！ということで私が採用されたのですが、PM、ないしそれに準じる組織がないところに入社をした形になります。
それから半年、PMチームも立ち上がり一定組織化が進んできたので、振り返りも兼ねてやってきたことを書きたいと思います。
個々に気づきや学びもあったので、ニーズがあれば、最近知った #地味PM タグでもつけて（そう、とっても地味な活動をしておりました）、深掘り記事もかけるといいなと思っています。
課題調査
私が入社したタイミングは社員数が50名ほどで、1年前と比較すると倍以上に増えていました。
組織化が進むと、個対個のコミュニケーションが徐々に組織対組織（多対多）になっていきます。
PMチーム組成においては、そういった状況を踏まえ、暗黙知を形式知にし、透明性を上げるということを意識すべきではないかと考えていました。
そこでまずは現状を把握するため、CSやプロダクト開発メンバーにヒアリングを実施しました。
収集した課題をざっと分類すると、以下のようになりました。
これらのほとんどは、今までの組織にクリティカルな課題があったというよりは、個対個の関係から組織化が進んだ結果、課題として認識されてきたものだと捉えています。
プロダクトビジョン・戦略・ロードマップの不在・不認知
役割・責任範囲の曖昧さ
不明瞭な開発プロセス
ドキュメンテーションが散発的にしかなく情報に辿り着けない
同期的コミュニケーションの多さによるコミュニケーション負荷
多すぎる利用ツール
要求管理・開発優先度決定軸が曖昧
その他（プロダクト品質、デリバリースピード）
この中で8については現在も継続的にプロダクトチーム全体で取り組みをしているため、6ヶ月で一定のアウトプットにつながった1〜7について、どういうことをしてきたか書こうと思います。
これからPMの組織を立ち上げるよ！という人（少ないw）の参考になるとよいなと思っています。
1. プロダクトビジョン・戦略・ロードマップの不在・不認知
🍎 ロードマップの見える化
まずは今進んでいる案件の見える化を進めました。
今まさに開発中のものや、着手したが何かの理由で止まっているものなど、それぞれの開発状況も誰かに聞かねば分からない状態だったので、まずはMiroを活用し開発アイテムの見える化をしました。
見える化した上で、特に〜3ヶ月くらいの短期で優先度高く開発するアイテムをプロットしていくようにしています。
ロードマップの精度を検証するために、CS、PM、EMで4週間（2sprint）ごとに新しいバージョンを作るようにしています。
まだまだ精度が低いのが課題ですが、精度が低いということが分かったことが第一歩目なのかなと思っています。
🍎 プロダクトビジョンと戦略の策定
個からチームになったこともあり、改めて私たちが、誰にどういう価値を届けるのかの言語化と共通認識を持つ必要性を感じ、PMチームメンバー中心にさまざまなものを言語化していきました。
N=1分析
ターゲット/ペルソナの設定
カスタマーサクセスサイクル（勝手に名付けた）の策定
バリュープロポジションの策定
プロダクト戦略策定（〜1年）
プロダクトビジョンの策定（〜1年）
今後の議論の土台にするものになるので、時間をかけて完璧なものを作るというよりは、スピード優先でブラッシュアップの余地を持たせたものをつくっています。
Miroに情報を収集して検討を深めていきました。
SaaSは事業戦略とプロダクト戦略が切っても切り離せないものなので、プロダクトチームだけでプロダクト戦略を決めきることはできません。あくまで起点であり、今後より精度を高めていきたいと思っています。
2. 役割・責任範囲の曖昧さ
🍎 PMチームの役割の定義
PM（チーム）がどういう役割を持つのかは、7月に組織が立ち上がったため定義をする必要がありました。
特に直近はPMとデザイナーとの役割分担が曖昧になりつつあり、一部でコンフリクトが発生しそうになっていました。
現在のカミナシは、細かく職能を分けて（PM, UXデザイナー, UXリサーチャーなど）役割を分担できるような組織規模ではありません。
そのため、（お互いオーバーラップする前提で）チーム単位で主として担う役割を、UXの5段階モデルを活用して明示するようにしました。
少し話はそれますが、以下の記事でCTOのトリさんが「カミナシのエンジニアはまずHowの部分についてプロフェッショナルになろう」という話をしています。
対してPMチームは「Why」のプロ集団、デザインチームは「What」のプロ集団として、互いに背中を預けつつ、染み出しあいながらよいプロダクトを作っていける組織にしていきたいと考えています。
3. 不明瞭な開発プロセス / 6. 多すぎる利用ツール
🍎 開発プロセスの可視化とルールの策定、ツール（Jira）の導入
当時カミナシでは、
VOCの収集：Productboard
問い合わせや不具合情報：Notion
各チームのタスク管理：Asana
ソースコード管理：github
バックログ管理：Zenhub（github内）
というかたちでチームや用途毎にいろんなツールに情報が散在していました。
これは歴史的経緯ではあるものの、
PMがすべてのバックログアイテムを1つのテーブルに乗せて優先度をつけられるようにしたい
VOCを収集・分析 → バックログアイテム化 → 開発 → リリース → VOCを起票したCS担当者に通知されVOCをクローズ
というサイクルを作りたいオンコールの仕組みをつくりたい（「5. 同期的コミュニケーションの多さによるコミュニケーション負荷」の課題を解決することができる）
という要求を満たせそうなJiraにすべて情報を集約し、適宜自動化ルールを作ってできるだけ小コストでプロセスの運用ができるようにしました。
めっちゃ自動化しました。
Jiraの導入を進める中で、改めて開発プロセスと、各プロセスにおける業務フローのルールの策定も実施しました。
特にSaaSの場合はビジネスチームとプロダクトチームの連携が重要ですが、ビジネスチームは普段利用しているSlackを活用してフィードバックを送れるようにするなど、できる限り気軽に投稿してもらえるような仕組みにしています。
4. ドキュメンテーションが散発的にしかなく情報に辿り着けない
🍎 ドキュメントの集約と型化
ドキュメンテーションについてはまだまだできていない部分も多いのですが、特にPMはWhyについて説明責任があり、客観的に納得感のあるドキュメントを書けるべきだと考えています。
今までのカミナシは人によって水準がバラバラだったり、ドキュメントがあったりなかったり、あってもどこにあるかわからないなどの課題がありました。
バックログアイテム毎にWhy, What, Howに関する説明を一箇所に集約
個々のドキュメントの目的に応じたテンプレートを作成してドキュメントそのもののハードルを下げる
相互レビューで品質を上げる
といったことを進めており、息を吸うようにドキュメンテーションされる文化にしていきたいと思っています。
こんな感じで整理しており、【issue名】のところにWhyの詳細を記述するようにしています。
5. 同期的コミュニケーションの多さによるコミュニケーション負荷
🍎 オンコールの導入
これは主にエンジニアリングチーム主導で進めていたものになります。
元々カミナシはお客様からの質問をCSチームが受け、slackでエンジニアをメンションして調査依頼をするワークフローでした。
これにより緊急度の高いものから低いものまで全てメンションされてしまうため、エンジニアが都度作業を止めることで生産性を落としていました。
ここについては、Jiraの兄弟プロダクトであるOpsgenieを導入することで同期的なコミュニケーションを減らすようにしています。
7. 要求管理・開発優先度決定軸が曖昧
🍎 バックログアイテムの優先度の付け方を決める
バックログアイテムの優先度の付け方は永遠の課題ですが、今回はRICEというフレームワークをカミナシ用にカスタマイズして使うようにしました。
RICEを実務で使うのは初めてでしたが、割り算を用いるため最終ポイントがかぶりにくいというのが一番の利点だと感じました。
（優先度一番高いアイテムが複数生み出されるというのは優先度策定あるあるが一定回避されるというw）
負債解消関連のアイテムにポイントがつけづらいといった課題もあったので、ここも今後試行錯誤していきたいと思っています。
【番外編その1】PMチームが組織に受け入れられるために
🍎 プロダクトレター
収集した課題の中には明確に出てこなかったのですが、ビジネスチームと話していると、カミナシのサービスチームが何を考えているのかわからないという声も多く、組織の拡大による弊害を感じました。
また、PMチームが何をするチームなのか知ってもらい、頼ってもらえるようになるためにも、まずはインターナルコミュニケーションの量を増やすことにしました。
上記で記載した取り組みについても、プロダクトレターとして発信することで普段関わりのないメンバーに知ってもらうことができますし、参考資料として掲載することで新しく来た社員のオンボーディングコストの低下にも寄与できると考えています。
半ば勢いで勝手に始めたのですが、結果、PMだけでなく、デザイナーやエンジニアも一緒にコンテンツを作り上げていくことで、約3ヶ月で25通もの発信をすることができました。
特にエンジニアメンバーの発信は私も読んでいてとても楽しく、社内でも非常に人気のあるコンテンツになりました🧑💻
振り返りのアンケートをとったところプロダクトやサービスチームの理解、モメンタムの醸成につながっているようでよかったです。
もらった声の一部
・やめないで！！！ください！！！！
・どういう顧客にヒアリングしているのか、その中でどこを重点的に狙おうとしているのかの背景が伺える
・エンジニアサイドの目線がわかりとても営業の時に自信を持って話せます。今全力で取り組んでるんです！と
・レターが出ただけでテンション上がるので、これからも続けてほしいです！
・こういう活動がないと理解と実態が乖離していくのでとても助かります！
一方で、週2ペースの発信はややお腹いっぱいで見きれないよー！という声も複数あったので、今後はもう少し頻度を落としつつ継続していきたいなと思っています。
【番外編その2】今後チームに人を受け入れるために
🍎 オンボーディングドキュメント
以前オンボーディングされる側の心構えnoteを書いたのですが…
社内に入るとオンボーディングをする側になるので、いつまた過去の私が来てもよいようにオンボーディングドキュメントをつくりました。
notionのDBを複製して、チェックリストとして活用できるようにしています🗒
こういう情報が集まってたら私も爆速で立ち上がっていたのに…！！！というのをまとめたので、これでもっとチームの人数が増えても大丈夫（なはず）💪
やりつづけることに意味がある
今回PMチームを組織化するにあたって色々と取り組んできましたが、やはりPMという職種柄多数の部門を巻き込む必要のあるものが多いので、組織が大きくなりきる前に多少着手できたのはよかったなと感じています。
一方で、まだまだできていないことの方が多いですし、組織が急速に拡大しているため今回の取り組みもすぐに陳腐化してしまいます（というかすでに陳腐化しているものもあるw）。
個人も組織も変化が止まると死に至るだけなので、こういう活動は大半が地味ですがずっとやり続けられる、地力のあるチームにしていきたいなと思っています。
少しでも参考になるアクションがあれば嬉しいです。
最後にスキ♡をポチっと押してくれると励みになります🐐
みなさまよろしくお願いします🙇♀️
–
🔈カミナシはPMをめっちゃ募集しています🔈
カミナシのPM組織はまだ立ち上がったばかりです。ほぼ0→1です！一緒に3,900万人の仕事を楽しくしませんか？
YOUTRUSTの募集はこちら
Meetyも色々あけてみてますー☕️
今回実施した取り組みについてもあくまで『プラクティス』であり、『ベストプラクティス』ではないと思っています。
もっとよい方法があるよ！うちはこうしてる！みたいな話をしたいな〜と思っているので、カミナシ興味ない方もお待ちしています〜👋
この記事が気に入ったらサポートをしてみませんか？