コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します!

意思決定の透明性を高め、全社で共有するプロダクトロードマップへ

この記事は、コドモンAdvent Calendar 2024 18日目の記事です。

こんにちは!コドモンでプロダクトマネージャー(以降PdM)をやっている重山です。 2024年4月にコドモンに入社し、あっという間に8ヶ月が経とうとしています。

今回はアドベントカレンダーに参加ということで、直近のプロダクト開発部としての取り組みについてまとめてみたいと思います。

こんな人に向けて書きました

  • SaaS企業にて開発組織拡大に伴う課題を感じている方
  • プロダクト開発部と他部署とのコミュニケーションで悩んでいる方
  • コドモンのプロダクト開発に興味がある方

はじめに

皆さんの開発組織においてプロダクトロードマップはどのように運用されていますか?

コドモンではメインのICT事業において40以上の機能を展開しており、PdM、エンジニア、デザイナー合計90名以上でプロダクト開発に取り組んでいます。

マルチプロダクトを提供する組織において、事業として優先順位が高い機能開発を行いながら、様々な要因による差し込みや入れ替えを行っていくのは難易度が高く、各社運用に苦労されているのではないでしょうか。

見えてきた組織課題

入社後、私はある領域の機能開発の優先順位を決めるため、弊社においてセールスの役割を担う、普及推進グループ担当者に話を聞いて回っていました。

その中で「なぜこの機能の改善が進まないのか」「いつの間にかロードマップから消えているものがあって理由がわからない」などの声を多く聞きました。

開発チームの意思決定の背景や意図が、他部署のメンバーまで浸透しきっていなかったのです。

さらに各機能を担当してくれていたPdMや関係部署に話を聞いてみたところ、明確に課題が見えてきました。

1. 意思決定の背景を伝える場所がない

これまで各機能を担当するPdMがセールスやサポート、サクセスなどビジネスチームからの要望をそれぞれ集約し、各機能のバックログに追加してくれていました。 一方で、それらの意思決定の経緯は各機能チームから個別に他部署に連携が必要で、情報がどこまで伝わっているか誰も把握できていない状況です。

2. プロダクトロードマップ策定に必要なステップが伝わっていない

開発案件をロードマップに入れるためには、複数のステップが必要です。

  • 課題の探索・特定
  • 要求定義
  • 要件定義
  • 概算見積もり

開発部における意思決定のフロー、特にロードマップ策定に必要なアクションを周知できていないことで、課題探索時に関係部署にヒアリングを実施したタイミングで「この案件はロードマップに追加されるんだ」という誤認を与えてしまうということもありました。

他にも開発体制やプロダクトバックログの運用に関して様々課題はありましたが、まずはこの2点を改善するべく打ち手を考えました。

まずは2つのアプローチで改善を目指す

開発部のメンバーは、日々難易度の高い意思決定をしつつ開発に真摯に取り組んでくれています。意思決定の背景が伝わっていないことで期待値がずれてしまうことはとても勿体無いことです。そこで、関係者に相談しながら以下3つのアクションを取りました。

1.各チームのやりたいことを集約、案件を一覧化

これまで、経営陣と開発組織で大筋の合意を形成した後は、各チームで機能単位でプロダクトバックログを作成してくれていました。 各チームに裁量がある状態な一方で、事業としてどこにどれだけのリソースを割いているのかを把握しづらく他部署にも共有する場がない状態でした。

そこで開発案件を全てのチームから集約(エントリー)し、全ての案件に対して開発工数・来期やる理由・事業インパクト等を明確にした上で一覧化をしました。

entryflow
会議体の変更

2.他部署の視点が入った会議体で案件の優先順位決め

次に、集約した開発案件のうち「絶対に来期やらなければならないもの」「できればやりたいもの」を分類。 開発工数を全て見積もった上で、セールス・サポート・サクセス・開発部と全ての部署の意思決定者が入った会議体で、開発案件の共有・優先順位の意思決定を実施しました。 これにより、意思決定に複数の観点を入れられるようになります。

案件の優先順位づけ

3.全社向けのロードマップ共有会の実施

1,2で実施した内容を全社に共有する会を設定し、ロードマップを運用する目的や優先順位の背景を改めて説明しました。 特に「絶対に来期やらなければならないもの」いわゆるMUST案件の選定軸はこれまで開発部から明確に共有するタイミングがなかったので、開発部以外のメンバーにも納得感を持ってもらえるよう意識して明示しました。

初めての取り組みだったので、参加してくれた皆さんがどのような反応をしてくれるかとても不安でしたが、優先順位の背景について理解できた、次回も参加したいという声をたくさんもらうことができました。

気軽に参加してもらえるようスレッドで質問を受け付け

大事なのは振り返り

もちろん、やりっぱなしでは終わりません。PdMチームのメンバーと一緒にアンケート結果を分類し課題を抽出、次回に活かせるよう改善サイクルを回していきます。今回、振り返りをする中で、3つの気づきがありました。

アンケート結果から振り返り

納得感を持って顧客に説明してもらう重要性

アンケート結果の中で、顧客やチームメンバーに対してご自身が納得した状態で共有したいというコメントが複数見られました。 言われたことをそのまま伝えるのではなく、自分の考えとして咀嚼した上で伝えたい。このような思いを持ったメンバーがたくさんいるのはとても心強いことです。

まずは開発部から、各チームに背景や思いを伝えたいという目的で動き始めましたが、私たちが伝えた人の先にいる人にも、きちんと意図を伝えられるかを意識する必要があります。 また、コドモンは組織拡大の真っ只中にあることで、この意思伝達の難易度が上がりつつあるということも改めて意識することができました。

期待値を超えていくことの難しさ

「次回も参加したいか」という問いに対して多くの方が「ぜひ参加したい」と回答してくれました。おそらく初回よりも期待値が上がってくると思いますし、内容に対してもシビアな指摘をもらうことが増えてくると思います。 なぜその優先度になったのか共通認識を持てるように、判断軸に関しては精度をあげていく必要がありますし、顧客に問われた時コドモンに所属するすべてのメンバーがその意思決定の背景を正しく伝えられるようになることが当面のゴールだと考えています。

身近な人にこそ気を配る必要性

これは個人的な反省でもありますが、同じPdMチームに対してなぜこの取り組みを進めているか、導入するとどのようなメリットがあるかなど説明が足りておらず、チームに一部混乱を招いてしまいました。 メンバーから率直にフィードバックしてもらえたことで気づくことができ、本当に感謝しています。 伝わっているだろうと過信せず、身近なメンバーにも継続的に意思を伝えていくことを忘れないようにしたいです。

コドモンにおいて、プロダクトロードマップは単なる開発計画ではなく、「いつ、どのような価値を提供できるか」を社内関係者で認識を合わせ、プロダクトに対する期待値を揃えるための重要なツールです。 このツールを活用し、持続的にユーザーの方へ価値を提供し続ける組織でありたいと考えています。

さいごに

コドモンはプロダクト、組織両面においてまだまだ発展途上な状態です。そのような環境を楽しみながら、私たちと一緒に事業を育てていってくれるPdMを募集しています!