複数の作業を同時に進めるとき、
何を分ければ壊れないか

当社が実際に確認した範囲です。分かれないものは、運用で決めるしかありません。

表は横にスクロールできます。

「分かれない」ものについては、ルールで守るのではなく、そもそも使わない形にできないかを先に検討しています。

当社で発生した重なりです。いずれも、統合の直前になって表面化しました。

1. 01

   別々の作業が、同じ一つのファイルを変更していた

   一方は表示の作り直し、もう一方は検索まわりの修正で、目的はまったく違いました。それでも同じファイルの同じ範囲に触れていたため、あとから統合の判断が必要になりました。早い段階で変更予定のファイルを突き合わせていれば、順番を入れ替えるだけで避けられた重なりです。

2. 02

   生成物の差分が、両方の作業に現れた

   掲載内容を変えると自動生成される一覧が、両方の変更に含まれていました。統合すると、片方の生成物がもう片方を上書きします。統合後に生成し直す、という手順を決めるまで気づきませんでした。

3. 03

   「動きました」がどの状態のものか分からなかった

   動作確認の報告と、実際に統合された内容が別の時点のものだった、ということがありました。以後は、確認したときの状態を特定できる形で残しています。

4. 04

   作業場所を分けたのに、依存の導入を忘れて止まった

   作業ディレクトリを新しく作ったとき、依存関係が入っていない状態で検証を始めてしまい、原因の切り分けに時間を使いました。作業場所を作ったら最初に導入する、という順番を固定しました。

並行作業を始めるときに、当社が先に踏んでいる順番です。

1. Step 01

   触る予定の範囲を先に書き出す

   変更する予定のファイルや領域を、作業を始める前に書き出します。ここで重なりが見つかれば、順番を入れ替えるだけで済みます。

2. Step 02

   作業場所を分けて、そこで完結させる

   作業ごとに別のディレクトリを用意し、その中だけで作業します。他の作業の場所には触れません。作業場所を作ったら、依存関係の導入まで済ませてから始めます。

3. Step 03

   共有される領域を使わない

   作業を一時的に退避させる共有領域は使わず、作業用の記録として残します。取り違えが起きたときに、どちらの変更か分からなくなるためです。

4. Step 04

   統合の順番を決める

   どの作業から先に統合するかを決めます。あとから入るほうが、先に入ったものに合わせて直す前提にしておくと、両方が同時に直そうとする状態を避けられます。

統合を始める前に、当社が必ず見ている項目です。

統合前に通していた検証は、統合後に必ずもう一度通します。統合そのものが変更だからです。