要件を固めても手戻りは起きる──実装フェーズで失敗しないための導入設計
前回の記事「IT導入前に決めておきたい要件整理の型」では、目的・制約・関係者・評価基準を揃える要件整理の進め方を解説しました。本記事はその次の段階、要件が固まった後の実装フェーズで手戻り・トラブルを防ぐ設計を扱います。
導入プロジェクトの失敗は、要件の不備だけが原因ではありません。要件が妥当でも、実装の進め方──環境の分け方、テストの設計、データ移行、切替方式──が雑だと、本番直前や稼働直後に問題が噴出します。そして実装フェーズの問題は、発見が遅いほど修正コストが跳ね上がります。
1. 環境を分ける──「本番で試す」を構造的に禁止する
最初に決めるのは環境構成です。最低限、次の分離が必要です。
| 環境 | 用途 | 触ってよい人 |
|---|---|---|
| 開発 | 作る・壊す | 開発担当 |
| 検証（ステージング） | 本番相当の設定・データでテストする | 開発担当＋業務側テスト担当 |
| 本番 | 実業務で使う | 利用者。変更は承認手続き経由のみ |
小規模導入では「本番しかない」構成で進めてしまうケースが目立ちます。SaaS導入でも、テスト用のサンドボックスや別テナント・別サイトを用意できることが多く、ベンダー選定時の確認項目に含めるべきです。
判断軸: 「設定変更を本番で直接試したことがあるか」。 一度でもあるなら、環境分離ができていない兆候です。本番直接変更は、うまくいっている間は速く見えますが、失敗した瞬間に業務停止と信頼喪失がセットで来ます。
あわせて、誰がいつ何を変更したかの記録（変更管理）を運用に組み込みます。高度なツールは不要で、変更内容・実施者・日時・承認者を残す台帳で足ります。トラブル時に「直前に何を変えたか」が分かるかどうかで、復旧時間は桁で変わります。
2. テストは「業務側が合格を判定する」工程として設計する
実装フェーズで最も軽視されがちなのがテスト設計です。よくある失敗は次の2つです。
失敗1: テストがベンダー任せ
ベンダーのテストは「仕様通りに動くか」の確認であり、「業務が回るか」の確認ではありません。仕様自体の解釈ズレはベンダーテストでは見つかりません。業務側が実データに近いケースで操作する受け入れテスト（UAT）を、独立した工程として計画に入れます。
失敗2: 正常系しか試さない
テストで「ちゃんと動いた」の大半は正常系です。本番で問題を起こすのは例外系です。
- 入力ミス・空欄・想定外の文字（旧字体、機種依存文字、全角半角混在）
- 月末・年度末・締め処理など、特定タイミングでしか発生しない処理
- 権限のない人が触ったときの挙動
- 件数が多いときの性能（テストは10件、本番は10万件、で起きる問題)
判断軸: テストケースに「わざと失敗させる項目」が含まれているか。 含まれていなければ、それはテストではなくデモです。
UATの合格基準は事前に文書化します。「なんとなく良さそう」で本番に進むと、稼働後の不具合のたびに「これは瑕疵か要望か」の不毛な議論が発生します。要件整理の段階で定めた評価基準を、ここで合否判定に接続するわけです。
3. データ移行──プロジェクト最大の地雷原
新システムへの移行で最も事故が多いのはデータ移行です。理由は単純で、既存データは想定より必ず汚いからです。重複顧客、廃止済みコード、手入力の表記ゆれ。移行プログラムは綺麗なデータを前提に書かれ、本番データを流した瞬間にエラーの山が出ます。
対策は工程の前倒しです。
- 実データでの移行リハーサルを最低2回計画する（1回目でデータの汚れを洗い出し、クレンジングして2回目で検証）
- 移行後の件数・金額の突合を合格条件にする（「移行しました」ではなく「旧と新で合計が一致しました」まで)
- クレンジングの判断（どの重複を残すか等）は業務側の仕事として割り当てる。ベンダーには判断できない
移行リハーサルを省略した一発勝負の移行は、切替延期の最大原因です。
4. 切替方式──一斉切替を選ぶ前に考えること
最後が切替（カットオーバー）方式です。
| 方式 | 内容 | 向くケース | リスク |
|---|---|---|---|
| 一斉切替 | 旧を止め、新に全面移行 | 並行稼働が物理的に不可能な場合 | 失敗時の影響が全業務に及ぶ |
| 並行稼働 | 一定期間、新旧両方を動かし結果を突合 | 数値の正確性が重要な業務（会計・在庫等） | 二重入力の負荷 |
| 段階移行 | 部門・拠点・機能単位で順次切替 | 拠点や部門が複数ある場合 | 移行期間中の新旧連携の設計が必要 |
一斉切替は計画上は最も「きれい」に見えますが、戻り道がありません。切替判定会議（Go/No-Go）の基準と、失敗時の切り戻し手順を事前に文書化していない一斉切替は、計画ではなく賭けです。
判断軸はこうです: 「切替に失敗したら、翌営業日の業務はどうやって回すのか」に即答できるか。できなければ、方式か準備のどちらかが不足しています。
5. 稼働直後の体制──導入の成否は最初の1か月で決まる
本番稼働はゴールではありません。稼働直後は問い合わせと不具合報告が集中する期間であり、ここの対応が悪いと現場は旧運用（Excel等）に静かに戻ります。こうなると、システムは動いているのに使われない「導入失敗」が完成します。
- 稼働後2〜4週間は問い合わせ窓口と即応体制を明示的に設ける
- 不具合と要望を分けて記録し、対応優先度を業務側と合意する
- 利用状況（ログイン率・主要機能の利用件数）を実測し、使われていない部門には理由をヒアリングする
まとめ
- 開発・検証・本番の環境分離と変更記録は、規模を問わず最低限の構え
- テストは業務側が例外系を含めて合否判定する工程。正常系だけのテストはデモにすぎない
- データ移行はリハーサル2回＋件数・金額突合を前提に計画する。クレンジング判断は業務側の仕事
- 切替方式は切り戻し手順とGo/No-Go基準まで含めて初めて「計画」になる
- 稼働後1か月の体制までがプロジェクトの範囲。定着確認なしの稼働は導入失敗の温床
導入プロジェクトの実装計画レビュー、移行・切替設計についてのご相談は、お問い合わせフォームからご連絡ください。