Blog 一覧
Agile × AI #agile #ai #product-owner #decision-making #prioritization

プロダクトオーナーはもう「決める人」ではない——優先順位づけから判断基準の設計へ

実装コストがほぼゼロになった世界で、単一のプロダクトオーナーがバックログの優先順位を一つずつ決めるモデルは機能しなくなる。POの仕事が「決定」から「決定基準の設計」へ移る理由を掘り下げる。

単一の意思決定者モデルは、ある前提の上に立っていた

Ownershipの記事で、 プロダクトオーナー(PO)の役割変化に軽く触れました。 今回はその一点を、単独の章として掘り下げます。

スクラムのPOは、「何を作るかを決める単一の責任者」として設計されてきました。 この設計が長年うまく機能していたのは、 実装が高価で、優先順位づけが希少資源の配分問題だったからです。 限られた開発リソースをどこに投じるかを一人が決める—— それ自体が合理的な仕組みでした。

想像してみてください。 バックログに30件のアイテムが並んでいて、 開発チームが1スプリントでこなせるのはそのうち5件だけだとします。 この状況では、「どの5件を選ぶか」という判断そのものに、 高い希少価値がありました。POが1人でその判断を独占することは、 無駄なく資源を配分するための、理にかなった設計だったのです。

「両方作って比べる」が「先に決める」より速くなった

TDDの記事で書いたように、 実装コストがほぼ無料に近づいた世界では、 この前提そのものが崩れます。 A案とB案のどちらを先に作るべきかを会議室で議論するより、 両方作って、ユーザーの反応で比較する方が速いのです。 優先順位づけという行為の希少価値が、静かに下がっています。

AIは、すでに優先順位づけの内側に入り込んでいる

この変化は理論の話だけではありません。 実務でも、AIシステムが過去の機能パフォーマンス、 ユーザーエンゲージメント、サポートチケットの量、収益インパクトといった データを分析し、理由づきで優先順位の提案を生成する事例が すでに広がっています。

SAFeの世界で使われてきたWSJF(Weighted Shortest Job First、 Cost of Delayに基づく優先順位づけ)のような手法も、 かつては人間の見積もりに頼っていましたが、 今ではビジネス価値・技術的実現性・遅延コスト・想定ユーザーインパクトを 横断的に評価する「客観的な思考パートナー」としてAIを使う流れが生まれています。

ここで区別しておきたいのが、二種類の「AI時代のPO」です。 一つはAI-native PO——AIを組み込んだプロダクトそのものを 管理する役割。もう一つはAI-augmented PO—— 従来のプロダクトを、AIツールを使ってより良く管理する役割です。 本稿で扱っているのは後者、つまり 意思決定の道具としてAIを使うことで、PO自身の仕事の中身が変わる という話です。

では、POの仕事は消えるのか——「決定」から「決定基準の設計」へ

ここで早合点してはいけません。 優先順位づけの価値が下がったからといって、 PO自体が不要になるわけではありません。 変わるのは、POが直接手を下す作業のレイヤーです。

Ownershipの記事の 決済バグのシナリオで例えたように、 POが個別に「この変更でいいか」を毎回承認する代わりに、 「決済処理に関わる変更は、必ずこの水準のテストカバレッジと承認フローを通す」 という判断基準そのものを設計しておく。 それが、分散した並行開発の中でも機能する、POの新しい仕事です。

意思決定のオーナーから、意思決定システムのオーナーへ。 この転換は、開発者もエージェントに指示を出す時点で 無数のマイクロなプロダクト判断をしている以上、避けられません。 POがすべての判断を独占することは、もはや物理的に不可能だからです。

新しいPOの三つの仕事

  • 判断基準の設計:何を優先すべきかではなく、優先順位を「誰が・何を根拠に」決めてよいかの基準を設計する
  • 検証すべき仮説の選定:並行して作られた複数案のうち、どれを・どんな条件で検証するかを定義する
  • 基準そのものの改善:設計した判断基準が機能しているかを定期的に見直し、更新する

この変化は、ステークホルダーへの説明の仕方も変えます。 かつては「私がこう判断しました」という個人の裁量が説明の根拠でした。 これからは「この基準に照らして、A案がこの数値を、B案がこの数値を示したので、 A案を採用しました」という、基準と結果の組み合わせが説明の根拠になります。 POの発言の重心が、「私の判断」から「私が設計した仕組みが生んだ結果」へ移るのです。

危険な兆候:「AIが提案したから」で判断を放棄する

ここには新しい落とし穴もあります。 AIが理由づきで優先順位を提案してくれるようになると、 その提案をそのまま採用するだけの「意思決定の外注」が起こりえます。 これは、判断基準を設計する仕事を放棄し、 個別の推奨を追認するだけの存在に逆戻りすることを意味します。

たとえば、AIが「解約率のデータから見て、この機能を最優先にすべき」 と提案してきたとします。データそのものは正しくても、 そのデータが集計された期間にたまたま大口顧客が一社離脱していただけ、 というノイズかもしれません。 基準を設計する立場のPOであれば「このサンプルサイズで結論を出すのは早い」 と気づけます。しかし提案を追認するだけの立場では、 そのノイズに気づく機会そのものを失います。

AIの提案は、あくまで判断基準という土台の上で機能する入力の一つです。 その土台そのものを設計し、時に「このデータは今回のケースに当てはまらない」 と判断できることこそが、POに残された、そして重みを増す仕事です。

変化のまとめ

これまでのPO これからのPO
日々の仕事 バックログの項目を一つずつ優先順位づけする 優先順位づけの基準そのものを設計・更新する
意思決定の単位 個別の機能・ストーリー 並行して作られた複数案のうち、何を・どう検証するか
AIとの関係 存在しない、または補助ツール 理由づきの提案を出す入力源。ただし採用可否の最終判断は人間
失敗しやすいパターン 独断による優先順位づけ AIの提案をそのまま追認する「意思決定の外注」

自己診断のための問い

  • 直近のバックログ判断のうち、何割が「個別の機能への判断」で、何割が「判断基準の見直し」だったか
  • AIが提示した優先順位の根拠を、そのまま採用する前にどれだけ疑ったか
  • 並行して複数案を検証する仕組みは、会議での決め打ちより実際に速くなっているか

おわりに

優先順位づけという仕事の希少性が下がったことは、 POという役割の価値が下がったことを意味しません。 むしろ、個々の判断から一歩引いて、 チーム全体が良い判断をし続けられる仕組みそのものの設計者 になることで、POの仕事はより高い視座を要求されるようになっています。

Manifesto記事で 紹介したかんばん方式の比喩を借りるなら、 POはもはや一枚一枚のかんばんカードに目を通す人ではありません。 かんばんという仕組み自体——何を、どんな基準で、 いつ後工程に渡すべきかというルール——を設計する人です。 現場の裁量を奪わずに、全体としての一貫性を保つ。 それは、優先順位を独占していた頃よりも、 はるかに設計者としての力量が問われる仕事です。