このユニットの結論
大勢の人が同じプログラムを同時に変えると、変更どうしがぶつかり、誰かの変更が消えたり、組み合わせたときに動かなくなったりします。
作業を小さく分け、作業ごとに別の写しで変更し、決まった手順で1つずつ取り込み、取り込む前に別の人が確かめる。この仕組みがあって初めて、大勢でも安全に開発を進められます。
1. 何の話か
このユニットは、大勢で同じプログラムを変更するときの進め方の話です。
大規模な開発では、多くの人が同じプログラムの集まり（ソースコード）を、同じ時期に少しずつ変えていきます。題名の「100人」は、大勢で同時に作業する状態のたとえです（アステリア案件の規模は、下の CASE FACT のとおり約120人規模のプロジェクトです）。
経理にたとえると、1つの表計算のファイルを大勢で同時に開き、それぞれが直して上書き保存している状態です。
2. なぜ必要か
進め方を決めずに大勢で変更すると、
- あとから保存した人の変更で、先に保存した人の変更が消える
- それぞれの変更は正しくても、組み合わせると動かない
- 何が、いつ、誰の変更で変わったのか分からない
- 1人の作りかけの変更で、全員の作業が止まる
ということが起きます。人数が増えるほど、こうした事故は起きやすくなります。
3. このユニットで分かること
- 大勢で変更するときに使う仕組みと、その用語
- 変更のぶつかりを減らす作業の分け方
- 変更を本流に取り込むまでの手順と、レビューの位置
- AIに任せてよいことと、人間が決めること
4. 基本の仕組み
一般的には、変更の履歴を残すバージョン管理という仕組みを使います（よく使われる道具に Git があります）。
| 用語 | 意味 | たとえ |
|---|---|---|
| バージョン管理 | 誰が、いつ、何を変えたかの履歴を残す仕組み | 文書の改訂履歴 |
| 本流 | みんなで共有する、正式なプログラムの状態 | 原本 |
| ブランチ（作業用の写し） | 本流から分けて、自分の作業をするための写し | 原本をコピーした下書き |
| 取り込み（マージ） | 写しで行った変更を、本流に反映すること | 下書きの修正を原本に反映 |
| 競合（コンフリクト） | 同じ箇所を2人が別々に変え、自動では合わせられない状態 | 2人が同じ段落を別々に直した |
| 取り込み依頼 | 取り込む前に、別の人に確かめてもらう依頼 | 決裁の回付 |
写しで作業するので、作りかけの変更が本流に入らず、ほかの人の作業を止めません。
5. ぶつかりを減らす作業の分け方
ぶつかり（競合）をゼロにすることはできません。減らし、早く見つけることを目指します。
- 作業を小さくする：1つの依頼に1つの目的。変更が小さいほど、ぶつかる箇所も確かめる量も減る
- 写しを長く離しておかない：本流から離れている期間が長いほど、戻すときのぶつかりが大きくなる。こまめに取り込む
- 同じ場所を同時に変える作業を、事前に分かるようにする：作業の一覧と担当の割り当てで、重なりに気づく
- チームの担当範囲を決める：ただし、境目の変更は残るので、境目の相談の窓口も決めておく
6. 取り込みまでの手順（一般的な例）
- 本流から、作業用の写しを作る
- 写しで変更し、自分で確かめる
- 自動テストで確かめる（09-04 自動テストと自動配布）
- 取り込み依頼を出し、別の人が変更の差分をレビューする（09-02 コードレビューは何を見るのか）
- 本流に取り込む
- 取り込んだあとの本流が動くことを確かめる
手順を人によって変えないことが大切です。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の開発に関係する記載
- 約120人規模のプロジェクト
- マルチベンダー
- Vendor A / ネクサスシステムズ — 新基幹アプリケーション
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- システムに SYS-09 開発・CI/CD基盤がある
- 成果物に DEV-001 Git・ブランチ運用方針、DEV-002 開発・レビュー標準がある
アステリア案件で、何人が同時にプログラムを変更したか、チームの分け方、写しの作り方と取り込みの規則、レビューの規則は、正本に記載がありません。未確定
7. THINK — 「自分の変更のほうが新しいので」
取り込もうとしたところ、競合が出ました。締め切りが迫っていた担当者は、「自分の変更のほうが新しいので、自分の方を残す」を選んで取り込みました。
問題
この進め方でよいでしょうか。
判断例を開く
判断
よくありません。
確認すること:
- 消えた側の変更は、何のための変更だったか
- 相手の担当者と話したか
- 両方の目的を満たす形に合わせられないか
- 合わせたあとの変更を、テストとレビューで確かめたか
競合は、「どちらが新しいか」ではなく、両方の変更の目的を確かめて解きます。
8. よくある失敗
- 作業用の写しを長く放置し、最後にまとめて取り込もうとする
- 競合を、中身を見ずに片方の変更で上書きして解く
- 取り込み依頼を出さずに、本流へ直接変更する
- 取り込んだあとに本流を確かめず、全員の作業が止まる
- 1つの依頼に複数の目的を詰め込み、差分が大きくなる
9. 成果物との接続
- DEV-002 開発・レビュー標準：変更の単位、取り込み依頼の出し方、レビューの進め方を決める
- DEV-001 Git・ブランチ運用方針：写しの作り方と取り込みの規則を決める方針
10. AI WORKFLOW — 作業の重なりを洗い出させる
AIは、作業中の変更の一覧から、ぶつかりそうな組を探す下書きに役立ちます。
指示例:
「次の作業中の依頼の一覧（依頼ごとに変更しているファイルの一覧つき）を見て、同じファイルを変更している依頼の組を挙げてください。どちらを優先するか、どう合わせるかは提案しないでください。」
11. REVIEW — AIの洗い出しを確認する
- AIが挙げた組を、実際の変更の一覧で確かめたか
- 同じファイルでなくても、関係する変更（ある画面と、その画面が使うデータの定義など）が漏れていないか
- 競合の解き方を、AIの案のまま採用していないか
12. 人間が判断すること
- 作業の分け方と、担当の割り当て
- 競合を解くとき、どちらの目的を優先するか（業務の判断が必要なときは業務の担当に確かめる）
- 取り込み依頼を承認するか
- 取り込みの規則に例外を認めるか
13. 判断演習
あなたは開発チームのリーダーです。別のチームと、同じ画面の別の機能を、同じ時期に変更することが分かりました。
ぶつかりを減らすために、作業を始める前に相手のチームと決めておくことを3つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
大勢で変更するときは、小さく分け、写しで作業し、決まった手順で1つずつ取り込み、取り込む前に別の人が確かめる。
競合は、どちらが新しいかではなく、両方の目的を確かめて解きます。