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

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

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

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

この四つの層を、一つの架空のシナリオで追ってみます。 ある朝、決済処理に軽微なバグが見つかった。 深夜にAIエージェントが実装したPRの一つに紛れていたものだ。 この一文が、四つの層それぞれで違う問いを突きつけます。

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

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

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

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

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

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

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

# CODEOWNERS

# 以前：このファイルを最後に書いた（＝一番詳しい）人を指す
# src/payments/  @suzuki

# これから：この領域の設計判断に責任を持ち、
# エージェントに渡す仕様・制約のコンテキストを維持する人を指す
src/payments/  @suzuki  # 決済ドメインの判断責任者。仕様書 docs/payments/*.md の保守者でもある

冒頭のシナリオに戻ると、決済処理のバグが見つかったとき、 最初に呼ばれるべきなのは「そのコードを書いた人」ではありません。 「なぜその設計にしたのかを説明でき、修正の妥当性を判断できる人」—— CODEOWNERSが指し示すべきは、この人物です。

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

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

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

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

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

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

これは人事評価にも波及します。 「コミット数」「実装した機能数」のようにコードの生産量を測る評価軸は、 実装がAIによってほぼ無限に生成できる世界では意味を失います。 代わりに評価すべきは、どの判断が効いたか、どの問題設定が的確だったか という、これまで測定してこなかった種類の貢献です。 冒頭のシナリオで言えば、バグを生んだPRを最終承認したのは誰か、 その判断はどんな記録として残っているか——それ自体が、 評価制度が追いつけているかどうかの試金石になります。

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

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

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

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

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

決済バグのシナリオで言えば、POが個別に「この修正でいいか」を毎回承認するのではなく、 「決済処理においてはこの水準のテストカバレッジと、この承認フローを必須とする」 という判断基準そのものを設計しておく——それが分散した状況でも機能する、 POの新しい仕事です。

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

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

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

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

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

この「安全にするための投資」は、具体的には三つに分解できます。

• 検証の網（テスト）：意図からズレた実装を、リリース前に機械的に検知する
• 観測性（モニタリング）：意図からズレた挙動を、本番で即座に検知する
• 可逆性（ロールバック可能性）：検知した後、被害を広げる前にすぐ戻せる

決済バグのシナリオが本当に恐ろしいのは、「AIが書いたコードだから」ではありません。 この三つのどれかが欠けていて、誰も気づけなかった、あるいは気づいても戻せなかった としたら、それこそが所有の失敗です。

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

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

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

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

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

自己診断のための4つの問い

自分たちのチームで四つの移動がどこまで起きているか、 次の問いに具体的な人の名前や仕組みで答えられるかどうかで確認できます。

• コード：この領域の設計判断に責任を持ち、コンテキストを維持しているのは誰か
• 成果：直近のレビューやデモで、「誰の判断が効いたか」を語る場面はあったか
• プロダクト：POが個別承認ではなく、判断基準そのものを設計した場面は最近あったか
• 責任：検証の網・観測性・可逆性のうち、最も手薄なのはどれか

おわりに

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

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

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