このユニットの結論
一度に全部を切り替える方法と、分けて切り替える方法には、それぞれ別の難しさがあります。
分けて切り替えると、一回あたりの失敗の影響は小さくなりますが、古いシステムと新しいシステムが同時に動く期間が生まれ、その間のデータの整合と連携の設計が必要になります。どちらを選ぶかは、戻せる単位と、同時に動く期間の苦労を比べて決めます。
1. 何の話か
このユニットは、本番の切り替えを、一度に行うか、分けて行うかの話です。
12-01 本番切替計画とは何か で、切り替えの計画に何を書くかを学びました。このユニットは、その計画の最初の分岐である「切り替えの単位」を考えます。世界で共有されている考え方では、一度に行う方法を「ビッグバン」、分けて行う方法を「段階移行」と呼びます。
2. なぜ必要か
切り替えの単位を考えずに決めると、
- 一度に全部を切り替え、失敗したときに戻す範囲も全部になり、戻せない
- 分けて切り替えたが、古いシステムと新しいシステムの間のデータの受け渡しを設計しておらず、二重に入力する期間が長引く
- 分けた単位が業務の流れと合っておらず、1 つの業務が古いシステムと新しいシステムをまたぐ
- 段階ごとの切り替えが長引き、同時に動く期間の運用の負担で現場が疲弊する
ということが起きます。
3. このユニットで分かること
- 一度に行う方法と、分けて行う方法の違い
- 分け方の種類
- 同時に動く期間に設計するもの
4. 一度に行うか、分けて行うか
| 観点 | 一度に全部（一般的な例） | 分けて切り替え（一般的な例） |
|---|---|---|
| 一回の失敗の影響 | 全業務に及ぶ | 切り替えた単位に限られる |
| 戻す単位 | 全部を戻す。戻せる時間に限りがある | 単位ごとに戻せる |
| 同時に動く期間 | ない（短い並行確認はある） | ある。数週間から数か月 |
| 古いシステムと新しいシステムの間の連携 | 不要 | 必要。期間限定の連携を作る |
| データの整合 | 切り替えの瞬間だけ | 期間中ずっと保つ必要がある |
| 現場の負担 | 切り替え前後に集中 | 期間中、2 つの仕組みを使い分ける |
| 向いている場合 | システムが密に結びつき、分けられない。戻せる時間に余裕がある | 拠点や業務で分けられる。一回の失敗が許されない |
5. 分け方と、同時に動く期間の設計
分け方には、拠点や部門で分ける（ある拠点から先に）、業務で分ける（受注の業務から先に、請求は後で）、データの種類で分ける（マスターを先に、取引を後で）、利用者の割合で分ける（一部の利用者から先に）があります。分ける線は、業務の流れをまたがない場所に引きます。1 つの業務が古いシステムと新しいシステムをまたぐと、担当者が 2 つの画面を行き来し、データが二重になります。
同時に動く期間には、次を設計します。
- 古いシステムと新しいシステムの間の、期間限定の連携（どちらが正本か、どの向きに流すか）
- 期間中の運用（どの業務はどちらで行うか。問い合わせはどこへ）
- 期間中に切り替え済みの単位で問題が起きたときの、戻し方（戻すと、連携も戻す必要がある）
- 期間の終わりの条件（何が確かめられたら次の単位へ進むか）
分け方と期間の設計は CUT-001 本番切替計画書 に書き、段階ごとのリハーサルの結果を CUT-004 本番切替リハーサル結果 に残します。段階的に出す考え方は、開発の配布でも使います（09-07 本番へ段階的にどう出すか）。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の切り替えに関する記載
- M18 本番稼働、M21 初期安定化完了
- システム 11。約36本のシステム連携。データ正本は、顧客・契約が営業管理システム、案件・案件予算・案件原価・請求が新基幹、正式な会計残高・仕訳が FIN-CORE
- 成果物に CUT-001 本番切替計画書、CUT-003 切り戻し計画書、CUT-004 本番切替リハーサル結果 がある
- P-011 山下 恵 — 本番移行・運用リーダー
- 本番移行承認は、AIへ最終委任しない事項
アステリア案件の切り替えが一度に行われたか、分けて行われたか、同時に動く期間があったかは、正本に記録がありません。記録なし
6. THINK — 「分けると面倒なので、一度に切り替えたい」
切り替えの計画の議論で、開発側の責任者が次のように言いました。
「分けて切り替えると、古いシステムとの連携を作る必要があり、工数がかかります。一度に全部切り替えるほうが、作るものが少なくて済みます。」
問題
「作るものが少ない」を理由に、一度に切り替えてよいでしょうか。
判断例を開く
判断
作るものの量は、判断の材料の 1 つにすぎません。比べるべきは、失敗したときに戻せるかです。
確認すること:
- 一度に切り替えて失敗したとき、全部を戻す時間は、業務が止められる時間の中に収まるか（12-03 失敗したら元に戻せるか）
- 戻せないなら、一度に切り替えるという選択は「失敗が許されない」選択になる。その覚悟を、業務部門と経営層が共有しているか
- 分ける場合、業務の流れをまたがない線が引けるか。引けないなら、分ける利点は小さい
- 期間限定の連携の工数と、全部を戻せないときの業務の損害を、同じ土俵で比べたか
- 一度に切り替える場合でも、利用者の割合で分ける（一部の利用者から先に）など、影響を限る方法はないか
「作るものが少ない」は開発側の都合です。「失敗したときに業務がどうなるか」は、会社全体の都合です。後者で決めます。
7. よくある失敗
- 「作るものが少ない」だけで一度に切り替え、戻せないまま失敗に直面する
- 分けたが、業務の流れをまたぐ線で分け、二重入力が常態化する
- 同時に動く期間の連携と運用を設計せず、期間が長引いて現場が疲弊する
- 次の単位へ進む条件を決めず、問題を抱えたまま進む
8. 成果物との接続
- CUT-001 本番切替計画書：切り替えの単位、分け方、同時に動く期間の設計、次の単位へ進む条件
- CUT-004 本番切替リハーサル結果：段階ごとのリハーサルで、期間限定の連携と戻し方が機能したか
9. AI WORKFLOW — 分ける線の候補を整理させる
AIは、業務の流れと連携の一覧から、業務の流れをまたがない分け方の候補を整理する下書きに役立ちます。
指示例:
「次の業務の流れ（業務ごとに使うシステムと、業務の間のデータの受け渡し）と連携の一覧から、拠点・業務・データの種類のそれぞれで分けた場合に、1 つの業務が古いシステムと新しいシステムをまたぐ箇所を一覧にしてください。どの分け方がよいかの評価はしないでください。」
10. REVIEW — AIの整理を確認する
- AIが「またぐ」とした箇所が、実際の業務の流れと合っているか（業務部門に確かめたか）
- 一覧にない「またぎ」（文書に書かれていない手作業の受け渡し）を人が補ったか
- 業務の流れと連携の情報を AI に渡してよいかを事前に確かめたか
11. 人間が判断すること
- 一度に切り替えるか、分けるか。分けるなら、どの線で
- 同時に動く期間をどれだけ許すか
- 次の単位へ進む条件と、進むかどうか
本番移行承認、Go / No-Go は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「3 つの拠点で使う受注と請求のシステム」を切り替えるとします。
拠点で分ける場合と、業務（受注を先に、請求を後に）で分ける場合のそれぞれについて、同時に動く期間に必要になる連携を 1 つずつ書き、業務の流れをまたぐ箇所がないかを書いてください。そのうえで、どちらを選ぶか、理由とともに書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
切り替えの単位は、戻せる単位で決める。分けるなら、業務の流れをまたがない線で分け、同時に動く期間の連携・運用・戻し方・終わりの条件を設計する。