SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

デブサミ2026の初日をProductZineとコラボで開催。

Developers Summit 2026 「Dev x PM Day」

Developers Summit 2026 「Dev x PM Day」

「Product Management Summit」レポート

AI時代、誰がプロダクトの成果を引き受けるのか? ログラス広瀬丈氏が提唱する「責任」起点の組織論

「Product Management Summit」レポート

 生成AIの急速な普及は、ソフトウェア開発のプロセスを劇的に変えつつある。リサーチから実装まで、あらゆる工程でAIが支援を行う現代において、プロダクトマネージャーという職種にはどのような変化が求められているのだろうか。2026年4月28日に開催された「Product Management Summit」において、株式会社ログラスの広瀬丈氏は、単なる「職種の要不要」ではなく、プロダクトや事業を前に進める「責任」のあり方を問い直す必要があると語った。マネーフォワードで国内最大級のプロダクトマネジメント組織を率いた経験を持ち、現在はログラスで組織戦略を担う同氏が、AI時代のプロダクト開発において「誰が、何の責任を持つべきか」という本質的な問いへの解を提示する。

(写真提供:ファインディ株式会社)

AIによる「プロダクトマネジメントの民主化」と集約される責任

 AIがもたらした最大の変化は、職種間の境界があいまいになったことである。これまで、課題発見や要件整理はプロダクトマネージャー、体験設計やプロトタイピングはデザイナー、技術設計や実装はエンジニアといったように、プロセスごとに各職種の明確な「得意領域」が存在していた。

 しかし現在、AIの支援によってその前提は崩れつつある。ユーザー調査やログ分析の要約をAIが行い、自然言語から仕様のドラフトが生成され、ノーコードやコード生成によってプロトタイプや実装のハードルが劇的に下がった。つまり、全職種が一定レベルでプロダクト開発の全工程に関与できるようになっているのだ。広瀬氏はこの現象を、ある意味での「プロダクトマネジメントの民主化」であると表現する。

株式会社ログラスでProduct Chief of Staffを務める広瀬丈(ひろせ・じょう)氏
株式会社ログラスでProduct Chief of Staffを務める広瀬丈(ひろせ・じょう)氏

 「これまではプロダクトマネージャーだけが担っていたような思考やプロセスに、デザイナーも、エンジニアも、ビジネス側のメンバーも、より深く関われるようになる。だからこそ、プロダクトマネジメントの考え方は、むしろ全職種にとって重要になると思っています」

 一方で、ここで見落としてはならない注意点がある。それは、「プロセスの参加が広がること」と「意思決定や成果責任を分散できること」は別物であるという点だ。

 例えば優先順位づけやリリースの判断において、AIはリスクの洗い出しや影響範囲の整理を強力にアシストしてくれる。しかし、そのリスクを最後に引き受けて「出す」のか「止める」のかを判断するのは、人間でなければならない。「AIが言ったから」「みんなで議論して決めたから」では、事業成果に対する説明責任は果たせない。

 つまり、AI時代ではプロダクト作りのプロセスへの参加は広がるが、意思決定と成果責任はむしろ責任者に「集約」されていく。これが、組織を再設計する上での最も重要な大前提となる。

ログラスが「責任の所在」を突き詰める理由──管理会計ドメインの非決定性

 なぜログラスは、これほどまでに「責任の所在」を強く意識しているのだろうか。その理由は、同社が主戦場とする「管理会計」というドメインの特殊性に起因している。

 企業の経営判断を支える管理会計は、株主や税務署への報告を目的とする「制度会計」とは性質が大きく異なる。制度会計には会計基準や法律、監査といった「外部の強い正解」が存在し、それにどう正しく準拠するかが問われる。しかし、管理会計には外部に唯一の正解が存在しない。

 「どこで儲かっているのかを見るために商品別・顧客別・部門別のどれを軸にするか。売上、粗利、LTV(顧客生涯価値)、CAC(顧客獲得単価)の何をKPIとするか。これらは企業ごとの経営意思や戦略によって変わる、自由で『非決定的な問い』です。一方で、粗利には何を含み、共通コストをどう配賦するかという算出ロジックは、誰が見ても同じ数字になるよう絶対にズレてはいけない『決定的』なものでなければなりません」

管理会計における「問い(非決定的)」と「計算(決定的)」の対比
管理会計における「問い(非決定的)」と「計算(決定的)」の対比

 「正解にどう到達するか」が問われる世界ではなく、「何を正解とするか」を自分たちで決める世界。こうしたドメインにおいて、「この画面はこの人」「この機能はこの人」と細かく責任を分割しすぎると、プロダクト全体を通した一貫性が失われてしまう。

 「『この顧客にどんな見方を提示すべきか』『どこまで標準化し、どこから個社性を許容するか』という問いに対し、誰かが最後に責任を引き受ける必要がある。だからこそ私たちは、職種名の定義から始めるのではなく、『正解が決まっていないプロダクトにおいて、誰かが最後に引き受けなければならない責任とは何か』という問いから考えたのです」

「プロダクト開発責任者」が担うべき4つの成果責任

 ログラスが導き出した答えは、単に仕様の最終判断を下す人間ではなく、チームを牽引する「プロダクト開発責任者」という役割を明確に置くことだった。同氏はこれを「仕様の責任者ではなく、戦略・実行・結果・成果の責任者」と定義している。

 具体的には、以下の4つの責務を一体で引き受けるリーダーを指す。

  1. 戦略(Strategy):何を目指し、何を作り、何を作らないか。どこまでを汎用化するかというロードマップとKPI/OKRの設計に責任を持つ
  2. 価値(Value):何を顧客価値とし、何を事業価値とみなすか。(プロダクト)ディスカバリーを通じて課題を見極め、プロダクトの一貫性を守り抜く
  3. 実行(Delivery):どういう体制・進め方で実行するか。品質と速度を両立させ、エスカレーション対応まで含めた(プロダクト)デリバリーに責任を持つ
  4. チームと成果責任(Team):何を成果とみなすか。評価、採用、育成、リソース配分を含め、チームが継続的に機能し成果を出せる状態を作る
ログラスが定義するプロダクト開発責任者の4つの責任単位
ログラスが定義するプロダクト開発責任者の4つの責任単位

 実際にログラスでは、全領域や特定プロダクトごとにこの「プロダクト開発責任者」が配置されている。

 「私たちはこの役割を、プロダクトマネージャー職種に限定しているわけではありません。エンジニアでも、デザイナーでも構わない。ただし、プロダクトマネジメントは『必修科目』です。顧客課題を見極め、事業価値と顧客価値を両立させることができなければ、プロダクトの成果責任は引き受けられないからです」

スーパーマンは不要。3つの設計で「認知負荷」を削減する

 戦略から実行、そしてチームの採用・評価までを見る責任者。そう聞くと「そんな4つ全部を持てるスーパーマンなんていない」という当然の疑問が湧く。広瀬氏も「そんな人はなかなかいません」と認めた上で、重要なのは「責任を持つこと(Accountable)」と「全部を自分でやること(Responsible)」を明確に分けることだと強調する。

 「責任を持つとは、実行をすべて自分1人で担うことではありません。実行は分担していいし、むしろ分担すべきです。ただし、最終的な説明責任を持ち、うまくいかなかったときに誰の責任かをあいまいにせず、最後までオーナーシップを持って前に進める。それが責任者の役割です」

(※参考:ログラス社内における実際の責任分界(RACIチャート)の詳細は、広瀬氏のnote記事で公開されている)

 この広範な役割を、個人の努力や優秀さだけで成立させることは不可能に近い。そこでログラスでは、責任者を成立させるための「3つの設計」を導入している。

 1つ目は、プロセスではなく成果責任で扱い、高い判断力を持つ人材に委ねる「責任の設計」。2つ目は、A案・B案・C案のどれを選ぶべきかといった強度の高い意思決定を意図的に積ませる「機会と任用の設計」。そして3つ目が、今回広瀬氏が最も強調した「組織の設計」である。

 「広い責任範囲を個人の努力だけで背負わせると、必ず認知負荷が高くなります。だからこそ、責任者の認知負荷を下げるための『組織の横断機能』が必要です。横断機能は責任を代替したり承認したりする偉い人たちではなく、責任者に『バフ(魔法)』をかける存在なのです」

 具体的には、以下のような機能が責任者の抱える複雑性を引き取っていく。

組織の認知負荷を下げる横断機能の例
横断機能 引き取る複雑性 責任者にとっての価値
共通技術基盤 認証、権限、共通アーキテクチャ、マルチプロダクトでの再利用設計 毎回ゼロから技術設計を考えなくてよい
データ/AI基盤 データ取得、整形、分析補助、AI活用(Agent/MCP/API)の基盤整備 分析・判断補助の質と速度が上がる
デザインシステム UIルール、コンポーネント、マルチプロダクトの統一的な体験設計 体験設計の負荷を下げられる
セキュリティ・ガバナンス リスク評価、統制、準拠判断 同じ不安や確認作業を各チームが繰り返さなくて済む
人事・組織設計 評価、配置、採用、役割設計の属人化 人の意思決定を1人で抱え込まなくて済む
横断機能は責任者を「代替」するのではなく、認知負荷を削る「バフ」として機能する
横断機能は責任者を「代替」するのではなく、認知負荷を削る「バフ」として機能する

 「大事なのは、責任をプロダクト責任者から奪わないことです。責任は集中させる。複雑性は分離する。これが、AI時代のプロダクト組織において極めて重要な設計思想になります」

次のページ
ドメインの複雑性に応じた組織構造の選択

この記事は参考になりましたか?

「Product Management Summit」レポート連載記事一覧

もっと読む

この記事の著者

斉木 崇(編集部)(サイキ タカシ)

株式会社翔泳社 ProductZine編集長。 1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテック...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

ProductZine(プロダクトジン)
https://productzine.jp/article/detail/4274 2026/05/14 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング