PdMが実践する論点整理術：開発部と事業部の判断軸の違いをどうつなぐか

はじめに

楽楽勤怠のプロダクトマネジメントをしている @k0First です。

PdMとして仕事をしていると、開発部と事業部の相談MTGで、同じテーマについて話しているはずなのに、少し議論が噛み合わないと感じることがあります。

もちろん、どちらかが間違っているわけではありません。
ただ、議論がうまく前に進まないときは、見ている論点や重視している判断軸が少しずれていることが多いように思います。

そこで、開発部と事業部の相談MTGで扱ってきた相談ごとと、その顛末をまとめたシートをもとに、ChatGPTで内容を整理・分析してみました。
どんな相談があり、最終的にどう着地したのかを振り返りながら、開発部と事業部がそれぞれどのような観点で判断しているのかを見える化した、というイメージです。

その整理を通して見えてきたのが、開発部と事業部では、同じテーマを見ていても重視するポイントが少し違うということでした。
そして、その違いを前提に論点を整理できると、議論はかなり進めやすくなります。

この記事では、シートの分析から見えてきた「開発部と事業部の判断軸の違い」と、そこからPdMとして意識したい論点整理のポイントをまとめます。

開発部と事業部では、見ているものが少し違う

相談内容とその顛末を見返してみると、開発部と事業部では、意思決定の際に重視している観点に違いがありました。

観点	開発部	事業部
基本スタンス	安全に実現できるか	顧客・事業に価値があるか
まず見ること	実装難易度、保守性、既存仕様との整合	顧客影響、売上影響、現場運用への効果
重視するリスク	不具合、性能悪化、複雑化、運用事故	顧客混乱、失注、問い合わせ増、周知漏れ
優先順位の付け方	工数対効果、スコープ分割、MVP化	顧客影響度、案件重要度、Must/Better判断
仕様判断の軸	一貫性があるか、例外を増やさないか	現場で説明・運用できるか、売れるか

こうして並べてみると、開発部は 実現性・整合性・保守性 を、事業部は 顧客価値・事業インパクト・運用性 を重視していることがわかります。

これは、どちらが正しいという話ではありません。
役割が違えば、自然と重視するものも変わります。
むしろ、この違いがあるからこそ、プロダクトにとって健全な議論ができるとも言えます。

一方で、この違いが言語化されていないまま話し始めると、「なんとなく話が噛み合わない」という感覚だけが残りやすくなります。
PdMとしては、この違いを整理して、議論しやすい形に変換することに価値があると感じています。

開発観点だけで判断を閉じると、議論が進みにくくなる

楽楽勤怠のPdMは開発の近くで仕事をすることが多いため、自然と「安全に作れるか」「既存仕様と矛盾しないか」「保守で困らないか」といった観点で考えやすくなります。
これはとても大事な視点ですし、プロダクトを継続的に育てていくためには欠かせません。

ただ、それだけで判断を閉じてしまうと、事業部が見ている価値が議論から抜け落ちやすくなります。

たとえば、事業部は次のようなことを見ています。

• 顧客にとって本当に重要か
• 売上や受注、失注防止にどれくらい効くか
• 現場で説明しやすいか
• 運用負荷を下げられるか
• 周知や移行で混乱が起きないか

この観点をどう議論に乗せるかは、PdMの役割のひとつです。
開発部の観点を理解したうえで、事業部が見ている価値も議論の土台に置く。
このひと手間があるだけで、意思決定の納得感はかなり変わります。

議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき

シートを見返していて特に多かったのが、必要性と実現性が同時に話されているケースでした。

たとえば、事業部は「顧客に必要だからやりたい」と話しているのに対して、開発部は「そのやり方だと複雑になる」「保守が厳しい」と返す、という場面です。

表面的には反対意見のように見えますが、実際には別の論点を話しているだけ、ということが少なくありません。

そのため、PdMとしては少なくとも次の2つを分けて整理しておくと、議論を前に進めやすくなります。

論点	主な内容
必要性	顧客影響、事業インパクト、売上影響、運用改善効果
実現性	実装難易度、既存仕様との整合、保守性、性能・障害リスク

この整理があるだけで、

• 必要性は高いが、この形だと実現性が低い
• 実現はできるが、そこまで強い必要性はない

といった形で話しやすくなります。

PdMとしては、答えを急いで出すことよりも、まず論点を揃えることのほうが大事だと感じています。

要望をそのまま受け取らず、課題として整理する

相談ごとは、要望や仕様案の形で入ってくることが多いです。
ただ、開発側が本当に知りたいのは「何を作るか」だけではなく、「何を解決したいのか」です。

そのため、PdMとしては要望をそのまま受け渡すのではなく、まず次のような形で整理してから議論に持ち込むようにしています。

• 誰が困っているのか
• 何に困っているのか
• 今はどう回避しているのか
• Mustなのか、Betterなのか
• 実現できた場合に何が改善するのか

このひと手間があるだけで、開発部は「では別の実現方法もありそうだ」と考えやすくなります。
要望を課題に翻訳することは、PdMが価値を出しやすいポイントのひとつです。

「やるか・やらないか」ではなく、スコープを分ける

シートを見返していて、議論が前に進んでいた相談ほど、「全部やるかどうか」ではなく、「どこまでを1stでやるか」が整理されていました。

たとえば、こんな分け方です。

• 1stリリースで必須のもの
• あると望ましいが後続でもよいもの
• 当面は運用回避でしのげるもの
• 今回はやらないが、将来の検討対象として残すもの

この分解があると、開発部にとっては現実的に考えやすくなりますし、事業部にとっても「全部ダメだった」ではなく「何なら今できるか」で話せるようになります。

PdMとしては、この着地点を一緒に探していくことに大きな価値があると思っています。

仕様だけでなく、届け方まで含めて考える

相談の顛末を見ていると、仕様としては成立していても、実際にリリースして現場で回るかまで含めると判断が変わるケースがありました。

たとえば、次のような観点です。

• 顧客への説明は難しくないか
• FAQやマニュアル改修は大きくないか
• CSや導入支援の案内負荷は高くないか
• UI変更による混乱はないか
• リリース時期と周知時期は噛み合っているか

「作れること」と「ちゃんと届けられること」は別です。
PdMとしては、この後者まで視野に入れて論点を整理することが、よりよい意思決定につながると考えています。

まとめ

開発部と事業部の相談MTGで扱ってきた相談ごとと顛末を整理してみると、開発部は実現性・整合性・保守性を重視し、事業部は顧客価値・事業インパクト・運用性を重視していることが見えてきました。

PdMとして重要なのは、開発観点だけで判断を閉じないことです。
実現性・整合性・保守性をベースにしながら、事業部ならどう見るかも踏まえて論点を整理することで、議論は前に進めやすくなります。

特に、実務の中では次の4つを意識しています。

• 要望を課題として整理する
• 必要性と実現性を分けて考える
• スコープを分けて提案する
• 判断材料を揃えて議論に持ち込む

開発部と事業部のあいだで少し噛み合わなさを感じたときこそ、PdMが整理役として価値を出せる場面です。
これからも、こうした違いを前向きに捉えながら、議論を進めやすい形に整えていきたいと思っています。