誰が「作った」と言えるのか——AIネイティブ時代、オーナーシップは四つに分解される

オーナーシップは、アジャイルの土台だった

自己組織化チーム、集団的コードオーナーシップ、プロダクトオーナーという単一の意思決定者—— アジャイルという考え方は、その多くが「誰が何を所有しているか」という設計の上に成り立っています。 前回の記事で描いたような、 実装の大半をAIエージェントが担うチームでは、 この「オーナーシップ」という土台そのものが揺さぶられます。

ただし、オーナーシップは消えてなくなるわけではありません。 むしろ四つの層に分解され、それぞれ別の場所へ移動している、 と考えるとこの変化が理解しやすくなります。

層①：コードのオーナーシップ——「書いた人」がいなくなる

XP（エクストリーム・プログラミング）は「集団的コードオーナーシップ」を理想に掲げました。 誰でもどのコードにも触れる、属人化を避ける、という考え方です。 しかし実態としては、「書いた本人が一番詳しい」という自然な重力が常に働いていました。 集団所有を掲げていても、事実上の担当者は存在していたのです。

AIが実装の大半を担うようになると、この重力そのものが消えます。 「書いた人」がそもそも人間ではないため、 誰も他の人より詳しくない状態がデフォルトになるのです。

一見すると、これは集団的オーナーシップの完成形に見えます。 しかしそれは危険な形での完成です。 全員が所有している状態と、誰も所有していない状態は、紙一重だからです。

だからこそ、オーナーシップの対象そのものがずれていく必要があります。 守るべきは「このコードを書いた記憶」ではありません。

• なぜこの設計にしたかという判断
• この領域の仕様と制約の理解
• 品質を保証する検証の網

つまりコードオーナーシップは、判断とコンテキストのオーナーシップに置き換わります。 リポジトリのCODEOWNERSが指すのは、もはや「このファイルを書いた人」ではありません。 「この領域の設計判断に責任を持ち、エージェントに渡すコンテキストを維持する人」です。

層②：成果へのオーナーシップ——「自分がやった」と言えるか

もっと繊細なのは、心理的な層です。 アジャイルが機能してきた理由の一つは、 自己組織化チームが「自分たちで決めて、自分たちで作った」という当事者意識を持てたことでした。 動くソフトウェアをスプリントレビューで見せる瞬間の誇りが、チームのエンジンだったのです。

実装をAIが担うと、「自分が作った」という感覚は薄まりえます。 これを放置すると、レビュー疲れと当事者意識の希薄化が同時に進み、 「AIが作ったものを流し見て承認する人」が生まれます。 これはオーナーシップの死です。

理想的な適応は、誇りの対象を移すことです。

「このコードを書いた」から、「この問題を解いた」「この判断をした」 「このユーザーの体験を変えた」へ。

実は、職人的な誇りがコードの行そのものにあったこと自体、 手段への愛着だったとも言えます。 ただしこの移行は自然には起きません。 成果の帰属をチームの語りとして、意識的に作り直す必要があります。 レビューやデモで「誰の判断が効いたか」を明示的に語る文化がなければ、 貢献は静かに不可視化されます。

層③：プロダクトオーナーシップ——POの独占が崩れる

スクラムのプロダクトオーナー（PO）は、 「何を作るかを決める単一の責任者」として設計されてきました。 この設計が成立していたのは、実装が高価で、優先順位づけが希少資源の配分問題 だったからです。

しかし並行して複数案を作れる世界では、 「一人が順番を決める」ことの価値そのものが下がります。 代わりに重要になるのは、 「何を検証するか」「どの結果を採用するか」という判断です。

すると起きるのは、プロダクトオーナーシップの分散です。 開発者もエージェントに指示を出す時点で、無数のマイクロなプロダクト判断をしています。 POがすべての判断を独占するのは、物理的に不可能になります。

だからPOの役割は変わります。 「個別の判断を下す人」から、「判断基準を設計し、 チーム全体が良い判断をできる状態に責任を持つ人」へ。 意思決定のオーナーから、意思決定システムのオーナーへの転換です。

層④：責任（アカウンタビリティ）——ここだけは移せない

最後に、法的・倫理的な責任の層です。 ここが最も重要で、最も変わらない部分です。

AIは責任を負えません。 本番で事故が起きたとき、「エージェントが書いたので」は説明として成立しません。 したがって、実装が誰の手によるものであれ、 出荷したものへの責任は、人間とチームに残り続けます。

これは、オーナーシップの再定義の核心です。 AI時代のオーナーシップとは、「自分が作ったものへの権利」ではなく、 「自分が理解しきっていないものに責任を持つ覚悟と、それを安全にするための投資」 になります。だからこそ、検証の網、観測性、可逆性（すぐ戻せること）への投資が、 オーナーシップの実践そのものになります。

前々回の記事で書いた 「テストが人間の意図とAIの実行をつなぐ契約書になる」という話は、 実はこの層の話でもありました。 理解による所有から、検証による所有へ。 何が書かれているかを全部読んで理解しているから所有できるのではなく、 何が起きても検知でき、戻せる仕組みを持っているから所有できる、という発想の転換です。

四つの移動、まとめて見る

危険なのは、この移動を「設計しない」こと

ここまでの四つの移動は、放っておいても自然に起きるものではありません。 意識的に設計しなければ、次のようなチームが静かに生まれます。

誰も所有していないが、誰も気づいていないチーム。

CODEOWNERSは形だけ残っているが誰も判断に責任を持っていない。 スプリントレビューは開かれているが、誰も「自分の判断」として語らない。 POは存在するが、判断基準を設計せず個別承認だけをこなしている。 本番障害が起きても、「エージェントが書いたので」という空気が漂う。 これらはすべて、四つの移動のどれか一つが起きなかった結果です。

おわりに

アジャイルにおけるオーナーシップは、もともと 「コードの行を書いたかどうか」という単純な話ではありませんでした。 自分たちで決め、自分たちで作り、自分たちで結果に向き合う—— その全体を指す言葉でした。

AIが実装の大半を担う時代は、その言葉の中身を分解して見せてくれます。 コードは書けなくても、判断はできる。 実装しなくても、問題は解ける。 すべてを決めなくても、良い判断が生まれる仕組みは設計できる。 そして、理解しきれていなくても、責任を持つことはできる——検証と可逆性を備えていれば。

オーナーシップは消えるのではありません。 どこに置き直すかを、チーム自身が意識的に決める必要があるだけです。