こんにちは、セーフィーのたかぎです。 このたび、2026年4月28日（火）に丸の内で開催されるProduct Management Summit（主催：ファインディ株式会社）に、スポンサーとして参加します。 登壇・ブース出展・ノベルティ配布を予定していますので、本記事でご紹介します。 スポンサーする理由 セーフィーは、クラウド録画型映像プラットフォームを提供する企業として、日々膨大な映像データを活用してお客様の課題と向き合っています。 あらゆる現場の業務を映像とAIで変革していく中で、「AI時代にプロダクトとしてどう競争優位を築くか」は、まさに私たちが日々向き合っているテーマです。

はじめに 開発部と事業部では、見ているものが少し違う 開発観点だけで判断を閉じると、議論が進みにくくなる 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき 要望をそのまま受け取らず、課題として整理する 「やるか・やらないか」ではなく、スコープを分ける 仕様だけでなく、届け方まで含めて考える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @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が整理役として価値を出せる場面です。 これからも、こうした違いを前向きに捉えながら、議論を進めやすい形に整えていきたいと思っています。

お疲れ様です、エンジニアリングマネージャーの芦川です。 最近私の身に起きた「 奇跡のような時間 」 のお話をさせてください。 実は、有志のメンバー数名で 「 プロダクトマネージャーのしごと 」 という本の輪読会をやっていました。数ヶ月にわたる全16章の旅をようやく終えたのですが、これがもう、私のこれまでの社会人生活の中でも類を見ないほど、最高に濃密な時間でした。 何がそんなに凄かったのか。 一言で言うと、 「 斜めのつながり 」が起こした化学反応 です。 同じチームの人はほぼいない。上司・部下の関係もほぼない。 部署も年次も役割もバラバラなメンバーが、いわば「斜めの線」でつながって集まった、非公式な秘密の場所。そこで起きたことを、自分たちのふりかえり（KPT）の結果を交えながら、生々しく記録しておこうと思います。 きっかけは、忘年会の「ちょっとした立ち話」 そもそも、なぜこの会が始まったのか。 きっかけは、私自身のちょっとした「悩み」でした。 マネージャー同士で仕事をしていると、「もっと目線を合わせる必要があるな」と感じる場面が多々あります。だったら、何かひとつ同じ本でも一緒に読んでみて、共通言語を作ってみたらどうだろう？と考えました。 ちょうど私自身がプロダクトマネジメントを学習したいと思っていたタイミングで、「これをビジネス側のマネージャーと一緒に読んでみたいな」と思い立ちました。 そんな話を忘年会の席などで周囲にポロッとしてみたところ、 「あ、それなら私もやりたい」「自分も興味あります」 という声が予想以上に上がり、気づけば部署も役職も飛び越えた、今の面白いメンバーが集まっていました。 そもそも、何をやっていたのか？ 読んだ本は、オライリー・ジャパンの 「 プロダクトマネージャーのしごと 第2版 」 です。 プロダクトマネジメントの本質は「ビジネスと顧客の間の価値交換の管理人」であること。中身はスキルや手法もありましたが、それ以上に「どういう姿勢で人と向き合うか」という、ものすごく人間くさいことが書かれている本でした。 これを、毎週1章ずつ各自が非同期で読み進めてオフラインの場で感想をぶつけ合う。 ただそれだけのことなのですが、回を重ねるごとに、私たちの会話は本の内容を超えて、自分たちの「キャリア」や「組織のリアルな悩み」へと深く潜り込んでいきました。 輪読会を「ふりかえり」してみた 全章を終えた後、私たちはいつものようにKPT形式でこの会をふりかえりました。 そこに出た言葉が、この会の熱量を何よりも物語っています。 【KEEP】この会が最高だった理由 まず、全員が口を揃えて言ったのが 圧倒的な心理的安全性の高さ です。 「意見に対して否定されることがないので、心理的安定があった」（企画 管理職 井田さん） 「自分にはない視野を聞けた。キャリア相談もできて、自分が見えていたこともあった気がした」（企画 メンバー 安孫子さん） 業務上の利害関係がない「斜めの関係」だからこそ、普段の会議では絶対に言えないような「実はあそこ、失敗だと思ってます」とか「今のキャリアに悩んでるんです」という本音がポロポロと出てくる。 否定されない、マウントを取られない。そんな「聖域」のような場所になっていました。 次に、多角的な視点。 「自分とは違う立場の人から、違う意見を聞けて気づきやヒントをもらえた。納得感や共感がさらに生まれた」（企画 管理職 矢野さん） 矢野さんが言うように、エンジニアの視点、企画の視点、ビジネス側の視点。それぞれの「正義」や「制約」を知ることで、「あ、あの部署があの時あんな動きをしていたのは、こういう背景があったのか！」と、パズルが解けるような納得感が何度も訪れました。 吉田さんも、この多様性を評価してくれました。 「役職・部署・年次の異なるメンバーが集まったこと」（企画 プロダクトオーナー 吉田さん） この「バラバラさ」こそが、議論を立体的にしてくれた最大の要因でした。 泥臭く、人間臭かった「感想戦」のエピソード KPTのデータだけじゃ伝わらない、実際のやり取りの中で私の心に深く刺さったシーンを紹介させてください。 企画 管理職 井田さんの「型」への深い洞察 井田さんは、いつも一歩引いたところから、本質をズバッと突いてくれました。アジャイルやフレームワークの話になったとき、井田さんがボソッと言ったこの言葉が忘れられません。 「サッカーも茶道もアジャイルも一緒だな。ごく当たり前なことなんだけど、とっかかりとしてなにか型を用意したに過ぎないんだな！」 手法（アジャイル）を「目的」にするんじゃなくて、より良い仕事をするための「型」として捉える。この 井田語録 は、ツールに溺れそうになる私たちの目を何度も覚ましてくれました。 企画 管理職 矢野さんの「他部署へのリスペクト」 現場の最前線で戦ってきた矢野さんは、誰よりも「相手への想像力」の大切さを語ってくれました。 「開発の制約があることを想像しながらも、無視して『早く成果を出せ』と振る舞ってきたことがあった。反省。お互いの制約を理解しないと議論は噛み合わないし、そこを埋めるのが会社の成長に直結するんだ」 ベテランの矢野さんが、若手の前で「反省です」とさらっと言える。この潔さと素直さが、この会の空気をどれだけ温かくしてくれたか計り知れません。 企画 メンバー 安孫子さんが見つけた「自分の居場所」 安孫子さんにとって、この会は単なる勉強会以上の場所になっていたようです。 「年上の人とも、本という共通のツールがあることで対等に話を進めることができた。自分のこれからのキャリアについても相談ができて、自分だから見えていたこともあるんだと自信が持てたのが本当に良かった」 上司ではないけれど、経験豊富な先輩たち。そんな「斜めの先輩」にキャリアの悩みを打ち明け、認められた経験。彼女がこの会を通じて少しずつ自信をつけていく様子を見ていて、私も本当に嬉しくなりました。 企画 プロダクトオーナー 吉田さんの「対話への意志」 吉田さんは、本の中の抽象的な言葉を、いつも私たちの現場の課題に接続してくれました。 「『心地悪さは明確さの欠如の兆候』というフレーズが刺さった。放置すると将来の感情的対立や大きな障害になるから、恐れずに表面化させて、その都度対話することが必要なんだ」 「なんとなく気まずいから言わない」を卒業して、良いプロダクトのために「心地悪い会話」をする勇気。吉田さんの鋭い指摘は、いつも私たちに背筋を伸ばさせてくれました。 企画 メンバー 岡田さんが見つけた「改善の第一歩」 岡田さんは、日々の多忙な業務の中でも、いかにチームを良くしていくかを真摯に考えていました。 「大きなタスクはできるだけ分割して方向性を微調整できるようにする。また、お客様と同じ手順でサービスに触れることで、自分たちが本当に取り組むべき優先順位が見えてくる」 理想論だけで終わらせず、具体的にどう動くか。その一歩を自分なりに定義する岡田さんの姿勢は、メンバーにとっても大きな刺激になりました。 奇跡の時間の正体：なぜ「開発MTG」が楽しくなったのか？ ふりかえりのメモの中に、こんな一節がありました。 「読んだ自分の中で変化があったこと。開発とのMTGがたのしくなった。人の理解がちょっとできた」 これ、私も全く同じなんです。なぜ、たかが読書会でMTGが楽しくなるのか。 それは、この会を通じて 相手の背景にある制約や意図に好奇心を持つ訓練 ができたからです。 これまでは「なんで開発はこんなに時間がかかるんだ？」と不満に思っていたことが、「ああ、彼らには彼らの技術的な制約や、守るべき品質があるんだな」と想像できるようになった。 相手を「説得すべき対象」ではなく「共に航海するパートナー」として見られるようになった。 私はエンジニアですが、逆に企画の方に対してもこう強く思うようになりました。 これは、スキル以前の「人間としてのスタンス」の変化なのだと思います。 結びに：この集まりに名前をつけるなら 最後の感想戦で、私たちはこの集まりをこう呼びました。 上下左右輪読 奇跡の時間 役職（上下）、部署（左右）を超えて、斜めに繋がったメンバー。 秘密のDMグループという「非公式な場」で、誰にも否定されずに自分の経験を語り、仲間のキャリアを応援し、共に学習する。 これって、効率化ばかり求められる今の組織の中で、一見すると「無駄な時間」に見えるかもしれません。でも、本の中にあったように 「 無関心は反対よりももっと危険 」 です。 この輪読会に集まったのは、無関心ではいられなかった、熱い想いを持った「当事者」たちでした。 もし、皆さんの周りに閉塞感があるなら、ぜひ部署をまたいだ「斜めのつながり」を作ってみてください。一冊の本をダシにして、本音で語り合ってみてください。 そこには、どんなベストプラクティスよりも価値のある、 働くことをちょっと豊かにしてくれる奇跡 が待っているはずです。 一緒に走ってくれた井田さん、矢野さん、吉田さん、安孫子さん、岡田さん。 皆さんと過ごした時間は、マジで財産です。 「 未完成なものを素晴らしいものにするには、あなたの助けが必要です 」 本の中にあったこの言葉通り、皆さんの助けがあったからこそ、この輪読会は最高の「プロダクト」になりました。 本当に、ありがとうございました！ また次の「奇跡」を、みんなで探しに行きましょう。