プラクティス名（別名）
ソースコードの共同所有 （コードの共有、Shared Code、Collective Ownership）
プラクティスの目的・狙い
- チームの誰でも、いつでも、どのコードでも、修正できるようにする
- チーム全員でコードの品質を担保する
- 属人化の防止
どんな時に使うか
- 他のコードにも影響する修正を行う際、調整や待ち時間が発生し、スムーズにこなせない時
- メンバーのコーディングスタイルの違いやコード品質の差が大きい時
実施手順
- ベースのマインドセットとしてチームの共同責任についてDEV全員が合意する
- コードの取り扱いに関する運用ルールを定める（半日以内にコミットする、など）
- コード毎に担当を割り当てるようなことはしない
- 限られた人だけが許可/承認するような手順も極力無くす
コードの共有はCI（継続的インテグレーション）、トランクベース開発といったプラクティスを実践するための前提概念でもあり、その結果、最終的に到達する理想の状態ともいえる。ペアプロやモブプロを行うことで「私のコード」という意識を低減させることができる。
アレンジ例
- コードレビューをしていて、そもそも読みづらい箇所はリファクタリングする
アンチパターン
- テストもしてない修正コードを無責任にコミットする、またそれに対して誰も何も言わない
- 暗に「私のコードに触れるな」というオーラを出す
- 職人的な個人技に依存するコード（カウボーイコーディング）
参考情報
こぼれ話（私的コメント）
コーディングスタイルにこだわりがあるベテランほど「私の芸術的なコードが、無知な新人に汚された」という心理に陥りやすいもの。でもこれは逆に考えると教育のチャンスであり、何故そういった書き方をしない方がいいのかを伝えるきっかけになります。また、結局システム全体の品質はチーム全員のコード品質の総和でしかない、という当たり前の事実を思い出させてくれたりもします。このプラクティスによって真に共同所有されるのはソースコードではなく、「チームの責任」かもしれません。