並行開発の衝突は、編集ルールより設計で減らす

しろまえ殿は、複数のAIエージェントが同じアプリを並行して改修する現場で、ファイル競合を注意喚起だけでは防げないと判断した。 結論は、担当者の編集対象を分けるだけでなく、横断的な機能を集約する設計へ変えることだった。

競合は作業の速さではなく境界から生まれた

ある機能では、複数の画面にある通信処理へ同じ変更を加える必要があった。 しかし画面ごとに担当者が分かれていたため、同じファイルを複数人が触る構図になった。

そこで、しろまえ殿は先に変更対象を数えた。 呼び出し箇所を一つずつ直す方法では、編集範囲が広がる。 担当者同士の境界も曖昧になる。

採用したのは、横断的な処理を新しい集約モジュールへ寄せる方法だった。 既存の呼び出し側は触らず、入口に一度だけ読み込ませる。 この小さな薄い層をshim（既存処理の前に差し込む適応層）として使うと、各画面の担当者は自分のファイルに専念できる。

たとえば、店内の全てのレジに同じ案内板を貼る代わりに、入口に一枚の案内板を置くようなものだ。 案内の内容を変えるとき、レジを一台ずつ止める必要がなくなる。

一つだけ残る共有点を先に扱う

集約方式でも、入口ファイルの読み込み部分は共有点として残った。 ここを「各自が好きなタイミングで編集する場所」にすると、競合は別の形で再発する。

そこで、共有点には二つのルールを置いた。 一つは追記を基本とし、他担当の行を削除・置換しないこと。 もう一つは、最初の変更を確定してから次の担当が追記することだ。

どうしても共有ファイルを変更するなら、担当範囲を宣言してから編集する。 確定前の作業ツリーを別担当が取り込まないよう、作業順も合意する。

さらに、ラッパー（既存関数を包んで挙動を追加する処理）を重ねる場合は、合成順を実ファイルで確認する。 片方が消えていないか。 同じ処理が二重になっていないか。 担当者の報告だけでなく、確定後の実体を見ることが重要だった。

契約を先に置けば待ち時間も減る

フロントエンドとバックエンドを別担当にすると、片方の完成待ちが発生しやすい。 この問題には、先にAPI契約（要求と応答の形式を決めた取り決め）を固定する方法が効いた。

画面側は契約に合わせてモック（本物の代わりに使うテスト用データ）で先行する。 実データ特有の項目が届いたら自動的に実経路へ切り替える。 ただし、契約書を書いただけで確定扱いにはしない。 ステータスコード、応答のキー、送信形式を実際のHTTP応答でも確認する。

並行編集下の動作確認では、共有中の開発サーバーをそのまま使わない。 作業ツリーを隔離したスナップショットにし、別ポートで検証する。 他担当の自動リロードが検証結果へ混ざるのを防げる。

発注前の短い点検が効く

しろまえ殿の現場では、次の順序を作業開始前の点検にした。

1. 担当ごとの編集ファイル集合を並べ、重なりを探す。 2. 重なりがあれば、集約モジュールと入口一箇所への導入に置き換えられないか考える。 3. 共有点が残るなら、追記範囲と確定順を決める。 4. API契約を実通信で確認し、モックから実データへ切り替わる条件を決める。 5. 確定後は、実ファイルと隔離環境で合成順・実操作・送信内容を検証する。

並行開発の品質は、人数を増やすだけでは上がらない。 衝突しにくい境界を先に設計し、共有点を少なくする。 そのうえで、残った一点だけを順序管理する。

この考え方なら、担当者が増えても作業を止めずに済む。しろまえ殿の現場で、設計がそのまま進行管理の道具になった瞬間だった。