(写真提供:ファインディ株式会社)
AIによる「プロダクトマネジメントの民主化」と集約される責任
AIがもたらした最大の変化は、職種間の境界があいまいになったことである。これまで、課題発見や要件整理はプロダクトマネージャー、体験設計やプロトタイピングはデザイナー、技術設計や実装はエンジニアといったように、プロセスごとに各職種の明確な「得意領域」が存在していた。
しかし現在、AIの支援によってその前提は崩れつつある。ユーザー調査やログ分析の要約をAIが行い、自然言語から仕様のドラフトが生成され、ノーコードやコード生成によってプロトタイプや実装のハードルが劇的に下がった。つまり、全職種が一定レベルでプロダクト開発の全工程に関与できるようになっているのだ。広瀬氏はこの現象を、ある意味での「プロダクトマネジメントの民主化」であると表現する。
「これまではプロダクトマネージャーだけが担っていたような思考やプロセスに、デザイナーも、エンジニアも、ビジネス側のメンバーも、より深く関われるようになる。だからこそ、プロダクトマネジメントの考え方は、むしろ全職種にとって重要になると思っています」
一方で、ここで見落としてはならない注意点がある。それは、「プロセスの参加が広がること」と「意思決定や成果責任を分散できること」は別物であるという点だ。
例えば優先順位づけやリリースの判断において、AIはリスクの洗い出しや影響範囲の整理を強力にアシストしてくれる。しかし、そのリスクを最後に引き受けて「出す」のか「止める」のかを判断するのは、人間でなければならない。「AIが言ったから」「みんなで議論して決めたから」では、事業成果に対する説明責任は果たせない。
つまり、AI時代ではプロダクト作りのプロセスへの参加は広がるが、意思決定と成果責任はむしろ責任者に「集約」されていく。これが、組織を再設計する上での最も重要な大前提となる。
ログラスが「責任の所在」を突き詰める理由──管理会計ドメインの非決定性
なぜログラスは、これほどまでに「責任の所在」を強く意識しているのだろうか。その理由は、同社が主戦場とする「管理会計」というドメインの特殊性に起因している。
企業の経営判断を支える管理会計は、株主や税務署への報告を目的とする「制度会計」とは性質が大きく異なる。制度会計には会計基準や法律、監査といった「外部の強い正解」が存在し、それにどう正しく準拠するかが問われる。しかし、管理会計には外部に唯一の正解が存在しない。
「どこで儲かっているのかを見るために商品別・顧客別・部門別のどれを軸にするか。売上、粗利、LTV(顧客生涯価値)、CAC(顧客獲得単価)の何をKPIとするか。これらは企業ごとの経営意思や戦略によって変わる、自由で『非決定的な問い』です。一方で、粗利には何を含み、共通コストをどう配賦するかという算出ロジックは、誰が見ても同じ数字になるよう絶対にズレてはいけない『決定的』なものでなければなりません」
「正解にどう到達するか」が問われる世界ではなく、「何を正解とするか」を自分たちで決める世界。こうしたドメインにおいて、「この画面はこの人」「この機能はこの人」と細かく責任を分割しすぎると、プロダクト全体を通した一貫性が失われてしまう。
「『この顧客にどんな見方を提示すべきか』『どこまで標準化し、どこから個社性を許容するか』という問いに対し、誰かが最後に責任を引き受ける必要がある。だからこそ私たちは、職種名の定義から始めるのではなく、『正解が決まっていないプロダクトにおいて、誰かが最後に引き受けなければならない責任とは何か』という問いから考えたのです」
「プロダクト開発責任者」が担うべき4つの成果責任
ログラスが導き出した答えは、単に仕様の最終判断を下す人間ではなく、チームを牽引する「プロダクト開発責任者」という役割を明確に置くことだった。同氏はこれを「仕様の責任者ではなく、戦略・実行・結果・成果の責任者」と定義している。
具体的には、以下の4つの責務を一体で引き受けるリーダーを指す。
- 戦略(Strategy):何を目指し、何を作り、何を作らないか。どこまでを汎用化するかというロードマップとKPI/OKRの設計に責任を持つ
- 価値(Value):何を顧客価値とし、何を事業価値とみなすか。(プロダクト)ディスカバリーを通じて課題を見極め、プロダクトの一貫性を守り抜く
- 実行(Delivery):どういう体制・進め方で実行するか。品質と速度を両立させ、エスカレーション対応まで含めた(プロダクト)デリバリーに責任を持つ
- チームと成果責任(Team):何を成果とみなすか。評価、採用、育成、リソース配分を含め、チームが継続的に機能し成果を出せる状態を作る
実際にログラスでは、全領域や特定プロダクトごとにこの「プロダクト開発責任者」が配置されている。
「私たちはこの役割を、プロダクトマネージャー職種に限定しているわけではありません。エンジニアでも、デザイナーでも構わない。ただし、プロダクトマネジメントは『必修科目』です。顧客課題を見極め、事業価値と顧客価値を両立させることができなければ、プロダクトの成果責任は引き受けられないからです」
スーパーマンは不要。3つの設計で「認知負荷」を削減する
戦略から実行、そしてチームの採用・評価までを見る責任者。そう聞くと「そんな4つ全部を持てるスーパーマンなんていない」という当然の疑問が湧く。広瀬氏も「そんな人はなかなかいません」と認めた上で、重要なのは「責任を持つこと(Accountable)」と「全部を自分でやること(Responsible)」を明確に分けることだと強調する。
「責任を持つとは、実行をすべて自分1人で担うことではありません。実行は分担していいし、むしろ分担すべきです。ただし、最終的な説明責任を持ち、うまくいかなかったときに誰の責任かをあいまいにせず、最後までオーナーシップを持って前に進める。それが責任者の役割です」
(※参考:ログラス社内における実際の責任分界(RACIチャート)の詳細は、広瀬氏のnote記事で公開されている)
この広範な役割を、個人の努力や優秀さだけで成立させることは不可能に近い。そこでログラスでは、責任者を成立させるための「3つの設計」を導入している。
1つ目は、プロセスではなく成果責任で扱い、高い判断力を持つ人材に委ねる「責任の設計」。2つ目は、A案・B案・C案のどれを選ぶべきかといった強度の高い意思決定を意図的に積ませる「機会と任用の設計」。そして3つ目が、今回広瀬氏が最も強調した「組織の設計」である。
「広い責任範囲を個人の努力だけで背負わせると、必ず認知負荷が高くなります。だからこそ、責任者の認知負荷を下げるための『組織の横断機能』が必要です。横断機能は責任を代替したり承認したりする偉い人たちではなく、責任者に『バフ(魔法)』をかける存在なのです」
具体的には、以下のような機能が責任者の抱える複雑性を引き取っていく。
| 横断機能 | 引き取る複雑性 | 責任者にとっての価値 |
|---|---|---|
| 共通技術基盤 | 認証、権限、共通アーキテクチャ、マルチプロダクトでの再利用設計 | 毎回ゼロから技術設計を考えなくてよい |
| データ/AI基盤 | データ取得、整形、分析補助、AI活用(Agent/MCP/API)の基盤整備 | 分析・判断補助の質と速度が上がる |
| デザインシステム | UIルール、コンポーネント、マルチプロダクトの統一的な体験設計 | 体験設計の負荷を下げられる |
| セキュリティ・ガバナンス | リスク評価、統制、準拠判断 | 同じ不安や確認作業を各チームが繰り返さなくて済む |
| 人事・組織設計 | 評価、配置、採用、役割設計の属人化 | 人の意思決定を1人で抱え込まなくて済む |
「大事なのは、責任をプロダクト責任者から奪わないことです。責任は集中させる。複雑性は分離する。これが、AI時代のプロダクト組織において極めて重要な設計思想になります」
