「この Excel、誰も全部は分かっていません」。移行の相談で最初に出てくるのはたいていこの一言です。よくある形を挙げると、受注台帳が1ファイルあり、そこから枝分かれした部門別のコピーが数本、金額を集計する別ブックが1つ、何年も前に外注した基幹システムが横にあって、担当者が毎月そこから CSV を落として Excel に貼っている。構成は会社ごとに違いますが、動いてはいる、ただ直せる人がいない、という状態は共通しています。移すときに日程が延びる理由の多くは、技術よりも、何を持っていき、何を捨て、いつ旧手順を止めるかが決まらないことのほうにあります。
この記事が扱うのは、移行そのものの進め方です。FDE（Forward Deployed Engineer）という職種の定義はハブ記事に、着任から本番投入までの週次の進め方は90日ロードマップに、FDE が帰った後の運用は引き継ぎの記事に書きました。ここで書くのは、その途中に挟まる5つの作業——棚卸し、データ移行の設計、試し移行と突き合わせ、並行稼働、切替判断と旧手順の停止——と、この進め方が向く条件です。IPA の「システム再構築を成功に導くユーザガイド 第2版」と Microsoft・サイボウズの公式ドキュメントを土台にし、当社が経理 AX・kintone・案件管理システムの刷新・Claude 導入で本番稼働まで伴走した経験を一般化して並べます。
最初にやるのは、現物ごとに利用目的と保存の要件を確かめ、移す・読み取り専用で保管する・捨てるに振り分けること。IPA のガイドも「移行対象は絞った方がよい」と書いています。次に、切替の単位（一括か段階か）とデータの反映方法（差分が要るか）、そして旧新の出力を突き合わせるテストの完了基準を、着手前に数字で決める。並行稼働は現場の二重入力を増やすので、期間と終了条件をセットで置く。切替は決めた基準を満たしたかどうかで経営が判断し、旧手順は日付を決めて権限ごと止める。
この記事の要約
移行が止まる原因の一つは、「何を捨てるか」が決まらないこと
移行の相談で最初に渡される資料は、たいてい新しい仕組みの構想です。ところが着手すると、時間の大半は旧側の調査に消えます。IPA のガイドは、作業の流れの先頭に資産棚卸を置き、「正確かつ確実な資産棚卸の実施（後続作業ボリュームに大きく影響）」「移行対象・移行範囲を明確にFIXすること」と書いています。棚卸しの精度が、その後の作業量をそのまま決める。現行の仕様が読めない、文字コードが合わないといった技術側の確認も同じ時期に要りますが、こちらは調べれば答えが出ます。棚卸しの結果待ちにせず並行して進めます。
棚卸しの対象は、基幹システムのテーブルだけではありません。Excel の台帳、派生したコピー、Access のファイル、共有フォルダの申請書、紙の伝票、担当者のメールの中の依頼。これを1枚の表にします。当社が最初の週に作るのは、次の6列です。
| 列 | 書くこと | この列が無いと起きること |
|---|---|---|
| 現物の名前と置き場所 | ファイル名・パス・システム名。「受注管理.xlsx（営業部長のPC）」まで具体に書く | 同名の別ファイルが後から出てきて、どちらが正しいか分からなくなる |
| 誰が作り、誰が使うか | 入力する人・見る人・承認する人を役割と人数で書く | 権限を設計できない。使っていた人が知らないうちに使えなくなる |
| 更新の頻度と件数 | 日次か月次か。月あたり何行増えるか | 切替の単位も、差分の反映が要るかどうかも決められない。停止できる時間帯も読めない |
| どこから来て、どこへ行くか | 手入力か、別システムからの CSV か。出力先の帳票と提出先 | 前後がつながらず、旧ファイルだけが生き残る |
| 残す理由 | 法令・監査・実務のどれで必要か。参照だけか、更新もあるか | 捨てる判断ができず全件移行になる |
| 移行後の扱い | 移す／読み取り専用で保管する／捨てる、の3択と、決めた日付 | 旧手順が止まらない。二重入力が恒久化する |
6列目の3択が、この表の目的です。ただし先に埋めるのは5列目の「残す理由」です。何に使っているか、法令や監査で保存が要るか、他のファイルから参照されていないか。ここを確かめる前に「捨てる」に丸を付けると、後から必要だったと分かっても戻せません。IPA のガイドは確認観点の1番目に「移行対象の整理」を置き、「全部移行すると作業量が増え、時間がかかる。コスト増にもつながるので移行対象は絞った方がよい」と書き、例として「稼動期間で3年以上前のデータ、トランザクションデータは捨てるなど」の方針を決めることを挙げています。過去データを全部持っていくかは技術ではなく方針の問題で、決めるのは経営です。
多くの過去データは、更新の必要がなく参照できれば足ります。旧ファイルを読み取り専用にして共有フォルダに1か所だけ残し、新しい仕組みには直近の期間分だけ入れる。移行の作業量も突き合わせの対象も減ります。「捨てる」が怖いなら、まず「読み取り専用で保管する」に倒せばいい。
棚卸しで必ず出るのが、現行の仕様が分からない箇所です。IPA のガイドは「現新不一致が発生した場合、現行の仕様が分からないと不一致の原因解析が難航し、テストの遅延につながる」と書いています。当社は、読めない計算式を見つけてもその場で解読せず、まず「この列は誰が何に使っているか」を使う人に聞く。使われていない列なら、解読せずに落とせます。FDE の失敗パターン10に書いた「現行機能をすべて再現しようとして終わらない」は、ここで捨てる判断をしないと起きます。
Excel 台帳の限界は行数ではない——公式仕様で線を引く
「Excel が重いので何とかしたい」という相談で、行数の上限に触れている例はそれほど多くありません。Microsoft の公式ドキュメントによれば、ワークシートは 1,048,576 行・16,384 列、1セルに 32,767 文字まで入ります（Excel の仕様と制限）。数万行の受注台帳がこの上限に届くことはまずない。次の表は、症状ごとに公式ドキュメントで確認できること、いまのやり方の手直しで収まる条件、移行を検討する条件を分けたものです。
| 現場で出る症状 | 公式ドキュメントで確認できること | いまのやり方の手直しで収まる条件 | 移行を検討する条件 |
|---|---|---|---|
| 同時に開くと「読み取り専用」になる | 共同編集には Microsoft 365 のサブスクリプションと xlsx・xlsm・xlsb 形式が必要で、ファイルは OneDrive、OneDrive for Business、SharePoint Online に置く必要がある。SharePoint のオンプレミス環境は対象外 | この置き場所と形式に移せる。同時に触るのが数人で、行の取り合いが起きない | 共有サーバから動かせない。誰がいつどの行を直したかを記録に残す必要がある |
| オフラインで直した内容が消えたように見える | OneDrive の同期では、オフラインでの変更は「コンピューターがオンラインに戻るまでマージされない」 | 入力をブラウザ側に寄せ、手元のファイルを正本にしない運用にできる | 外出先の入力が業務の中心で、同期の前後で値が変わると困る |
| 金額の合計が1円ずれる | 計算の有効桁数は15桁。ただし、ずれは丸めの位置や集計の順番から生じることも多く、桁数だけで説明はつかない | 丸めの規則を1か所に決め、式を揃えれば収まることがある | 丸めの規則が部門ごとに違い、全体を直せる人がいない |
| 計算式が誰にも直せない | 数式は 8,192 文字、関数のネストは64段階まで入る。上限に届かなくても読めなくなる | 式の判断を一覧表に外出しし、式は参照だけにできる | 式の意味を説明できる人が社内にいない |
3列目に当てはまるなら、移行しないほうが早い。移行を選ぶなら、移行先で満たすべきことを仕様の言葉で書きます。「重いから移す」では要件になりませんが、「4人が同時に入力し、誰がいつ直したかを残す必要がある」なら要件になる。
移行先の側にも公式に確認できる制限があります。kintone にファイルから一括登録する場合、xlsx 形式は最大 1MB・1,000 行、CSV・TXT・TSV 形式は最大 100MB・10万行、対応付けできるのは 1,000 列目までです（レコード登録・上書き用のファイルを準備する）。日本語版の Excel で作ったファイルは Shift-JIS になるため文字化けする場合があり、UTF-8 での保存が案内されています。Microsoft Dataverse では、エクスポートに12分の時間制限があり、超えると失敗するのでデータを分けるよう書かれています（Dataverse のインポートとエクスポート）。
この数字は、投入の手段とセットで意味を持ちます。kintone にファイルから入れるなら CSV で10万行が一区切りで、超えるなら分割の単位と順番を先に決める。API や連携ツールなら分割せずに入る場合もあるので、行数だけで決めず、手段と件数を一組で確認します。移行方法の検討を製品選定の後ろに置かないのは、このためです。
データ移行の設計——IPA の6観点を、Excel 台帳の移行に当てはめる
IPA の「システム再構築を成功に導くユーザガイド 第2版」は、データ移行で問題が起こりやすい観点を6つ挙げています（IPA の発行案内、本文はガイド本体の PDF）。大企業向けの資料ですが、この6つは Excel 台帳を kintone や Dataverse へ移す規模でも使えます。当社は「誰が決めるか」の列を足しています。
| IPA の観点 | ガイドの確認事項 | Excel 台帳の移行での当てはめ | 決める人 |
|---|---|---|---|
| 移行対象の整理 | 「移行対象は絞った方がよい」。送る範囲の方針を明確にする | 何年分を移すか。締め済みの期間は読み取り専用の保管へ回す | 経営＋現場 |
| レイアウトの確認 | 「移行対象のファイルや DB データのレイアウトを確認する」。ユーザ企業とベンダ企業双方で確認する | 列名・型・桁・必須の有無を1行1列で表にする。結合セルと非表示行を先に潰す | FDE ＋ Echo 役 |
| データクレンジングの実施 | 「想定外の値が含まれる恐れがあるため、データクレンジングを実施する」。役割分担を明確にする | 取引先名の表記ゆれ、全角半角、空欄、日付の文字列混在 | 現場（値の正誤）＋ FDE（検出） |
| 文字コードのマッピング | 外字や同じフォントフェイスが移行先に無い場合、フォントフェイスと用語の意味のどちらを優先するか調整する | 旧字体の取引先名、丸数字、機種依存文字の扱い | 現場（表記の正）＋情シス |
| 移行方法の確認 | 「一括移行／段階移行／差分移行などの移行方法を選定する」。データ転送方式も検討する | 止められる時間帯から切替の単位を選び、その後も旧側に入力が続くなら差分の反映を足す。ファイルから入れるなら分割の単位も決める | 情シス＋ FDE |
| 移行実施結果の確認 | 「チェックツールなどを用いてデータ移行の実施結果が正しいかを確認する」。確認方法を双方で合意する | 件数・合計金額・キーの重複を機械で突き合わせ、目視は例外だけ | FDE＋ Echo 役 |
4列目を足したのは、移行が「作業」ではなく「判断の連続」だからです。表記ゆれをどちらに寄せるかは FDE には決められず、突き合わせの自動化は現場に決めさせるべきではない。分担が曖昧なまま進むと、移行の最後で「この取引先名、どっちが正しいんですか」という質問がたまります。
キーの設計は、移行の前に決める項目のなかでいちばん後戻りが効きません。Dataverse の公式ドキュメントは、主キーが GUID であることと、外部ソースのデータを統合するときは代替キーを定義できることを書いています。kintone は、更新キーとして「レコード番号や受注番号など、同じアプリ内でほかのレコードと値が重複しないフィールド」を指定する仕様です（登録・上書きのポイント）。社内の伝票番号を更新キーにするのか、移行時に採番し直すのか。決めずに1回目の移行を流すと、2回目の差分投入で重複が出ます。
移行の計画は、開発と並行して早く立てます。IPA のガイドは、準備に時間がかかること、テストで実データを使うこと（「試験工程で現行踏襲を確認するためにはサンプルデータではなく、実際の業務データでテストを実施すべきである」）、そして「データ移行による問題は開発の終盤で顕在化するため、解消期間も計画に盛り込むべきである」ことを挙げています。90日ロードマップで移行の準備を第2〜4週に置いているのは、この3つを守るためです。
試し移行と突き合わせ——本番の前に、どこまで一致を確認するか
本番の移行を一発勝負にしない。IPA のガイドは本移行の前にパイロット移行を置くことを勧め、「その結果を移行方式設計書および移行ツールなどに反映することで、次工程である本移行作業において、リスクの低減を図ることができ」るとしています。取り組みは、移行観点を網羅する資産を選ぶことと、結果を現行と比較して設計書とツールを直すことの2点です。
当社がやっているのは、これを1日単位に縮めた版です。棚卸し表から代表的な件を選び——当社の目安は10〜30件です——移行先に実際に入れて、旧側の画面と並べて見せる。優先するのは、普通の件ではなく面倒な件です。金額がマイナスの返品、取引先名に旧字体が入っている件、備考欄に改行が入っている件、担当者が途中で変わった件。ただしこれは代表例の確認であって、網羅ではありません。ふつうの件が正しく入るかの確認、項目ごとに全件を機械で照合する作業、全量を入れたときの処理時間の確認は、別に置きます。試し移行は、移行後の画面を現場が初めて見る場でもあります。「この列、いつも右端で見ているので左に来ると分かりません」という指摘は設計書の段階では出ません。
突き合わせで最も多い失敗は、終われないことです。IPA のガイドは現新比較テストについて、「完了基準が曖昧なままであると、完了の判断をすることができず、テストを際限なく実施することとなり、いつまでも完了できない事態に陥る場合がある」と書き、「ユーザは業務継続性を担保できる要件を定量的な基準として定めた上で、テスト実施前に完了基準を明確に決めて各ステークホルダと合意しておく必要がある」としています。あわせて、このテストは「設計仕様に基づいた全ルートテストではないため、網羅性に注意」とも書かれています。
だから当社は、突き合わせを始める前に完了の条件を書き出します。件数が一致すること、合計金額が一致すること、キーの重複が0件であること、差分の残りに「移行先が正しい」「旧が正しいので直す」「業務上どちらでもよい」のいずれかが付いていること。ここまでは分類にすぎないので、2つ足します。「旧が正しいので直す」に分けた件は修正まで終え、もう一度突き合わせて一致すること。「業務上どちらでもよい」として残す差分は、件数と内容を一覧にし、その業務の責任者が名前を書いて承認すること。この6つが揃った時点で終わり、と先に合意する。合格の基準を先に決める考え方は成果物と検収の記事と同じで、移行では突き合わせの対象と件数がその中身になります。
並行稼働——期間と、二重入力を終える条件をセットで置く
並行稼働は、IPA のガイドではリリース後のリスク対策として挙げられています。内容は「一定期間、現行システムと新システムの両方で同一オペレーションを実施し、故障を洗い出す」。注意点は2つで、「利用部門の負担が増加するため、利用部門がどれほど並行稼働を許容可能か要確認」、そして「現行システムの EOL、EOS の期限内で実施可能か要確認」。
1つ目が実務ではいちばん重い。並行稼働の期間、現場は同じ内容を2回入力します。移行のための作業であって、現場の仕事が増えるだけです。だから当社は、始める前に次の5点を決めます。
| 決めること | 置き方の例 | 決めないと起きること |
|---|---|---|
| 二重にする範囲 | 新規の入力だけを二重にし、参照と集計は新側だけで見る | 現場の残業が増え、片方が入力されなくなる |
| 期間 | 当社の目安は、月次の業務なら締めを1回通す1か月、日次の業務なら2〜3週間。いずれも旧システムの保守期限より内側に収める | 「安定するまで」と書かれ、期限のないまま続く |
| 毎日見る数字 | 件数の差、金額の差、新側だけで出たエラーの件数を1画面で見る | 差が出ていることに月末まで気づかない |
| 終わる条件 | 当社が置くのは、直近2週間で件数と金額の差が0件、業務が止まる不具合が0件、現場の主担当が新側だけで1日回せた、の3つ | 止める理由を誰も言い出せず、二重入力が恒久化する |
| 止まったときの手順 | 誰に連絡し、その日の業務をどう回すか。旧側に戻すのか、紙で受けて翌日入れるのか | 不具合が出た日に現場が止まる |
「毎日見る数字」は、並行稼働を早く終わらせる仕掛けでもあります。差が0件で並ぶ日が続けば止める判断がしやすく、毎日差が出ているなら、原因が消えるまで期間の話をしても仕方ない。経理の月次を FDE 方式で本番化する記事で書いた「本番の締めを1回通す」も同じ考え方です。
並行稼働をやらない選択もあります。件数が少なく、間違えても当日中に直せる業務なら、二重入力の負担のほうが大きい。その場合は、切替日の前後1週間だけ旧側を読み取り可能な状態で残し、疑問が出たときに見に行けるようにする。当社の目安は日次の入力がおおむね20件を下回る業務ですが、件数そのものより「間違いに当日中に気づいて直せるか」で判断しています。
切替の判断と、旧手順の止め方
IPA のガイドは移行方法として一括移行・段階移行・差分移行を挙げています。この3つは横並びの選択肢ではありません。一括と段階は業務を切り替える単位の話、差分はデータをどう反映するかの話で、段階で切り替えながら差分を反映する組み合わせもあります。当社は二段階で決めています。
| 決める順番 | 選択肢 | 選ぶ基準 | 決めておくこと |
|---|---|---|---|
| ① 切替の単位 | 一括／段階 | 旧側を止められる時間がまとまって取れるか。部門や商品カテゴリで切り分けられるか | 一括なら止める時間帯と、時間内に終わらなかったときに旧側へ戻す手順。段階なら切る単位と順番、移行済みと未移行が混ざる期間の集計をどちらで出すか |
| ② データの反映方法 | 初回の投入だけ／差分の反映も行う | 投入の後も旧側に入力が続くか。段階で切る場合は、切替が終わるまで旧側が動き続ける | 差分を取るキーと時刻。二重に入る件をどう弾くか。差分の投入頻度 |
切替の可否を決めるのは経営で、材料を作るのが FDE です。持っていくのは4つ。突き合わせの結果（件数・金額・残った差分の分類）、並行稼働で毎日見ていた数字の推移、現場の主担当が新側だけで回した記録、止まったときの手順が書かれているかどうか。この4つが揃っていれば、会議の時間を判断そのものに使えます。揃っていないと、「もう少し様子を見よう」が繰り返される。
揃った日に決めるのは、切替日ではなく旧手順を止める日です。切替日は新側を使い始める日、停止日は旧側に入力できなくする日。2つを分けるのは、切替の後に業務が止まる不具合が出たときに、旧側へ戻す余地を残すためです。ただし「分けておけば戻せる」は、次の4点を書いていない限り成り立ちません。
| 書くこと | 書き方の例 |
|---|---|
| この期間の正本はどちらか | 切替日から停止日までの正本は新側。旧側は参照と非常時の受け皿とし、両方に値がある場合は新側を正とする |
| 戻すときの手順 | 切替日以降に新側だけへ入った分を CSV で書き出し、旧側の様式に直して入れ直す。誰がやり、何時間かかるかまで書く |
| 戻せる期限 | 切替日から◯営業日まで。件数が増えて入れ直しが現実的でなくなる前に切る。期限を過ぎたら戻さず、新側で直す |
| 戻す判断をする人 | 現場ではなく、切替を決めた経営。連絡先と、その人が不在のときの代理を書く |
件数が少なく当日中に直せる業務なら、2つを同じ日にして戻り道を作らない選び方もあります。どちらにしても、停止日を決めないと旧側が生き続け、二重入力が終わりません。90日ロードマップで第11週末に「旧手順をいつ止めるか」の判断を置いているのは、この日付を宙に浮かせないためです。
旧手順の止め方は、お願いではなく設定で行います。旧ファイルを共有フォルダごと読み取り専用にして書き込みの権限を落とす。旧システムの入力画面へのアクセス権を情シスの管理者だけに絞る。旧ファイルの先頭行に「◯年◯月◯日で入力を終了。以降は新しい仕組みへ」と書き、移行先を明記する。3つ目は地味ですが、後から検索でこのファイルを見つけた人が誤って使うのを防ぎます。
読み取り専用で残した旧データをいつまで置くかは、停止のときに初めて考えるのでは遅い。棚卸し表の「残す理由」に書いた保存の要件を、停止の作業で保管場所と削除の予定日として書き下します。期間は業種と書類で変わるため、当社は「何年」と決め打ちせず、書類ごとに社内規程と顧問の助言で決めてもらいます。
IPA のガイドは、再構築の最後に「新システム稼動後の再レガシー化を防止するような取り組みを検討することも重要である」と書いています。移した先がまた「誰も分からない仕組み」になるかは、直せる人が社内にいるかで決まる。移行の最後の作業は、切替ではなく引き継ぎです。運用手順・障害時の手順・権限表・変更のやり方・判断ログの5点をどう渡すかは引き継ぎの記事に、運用開始後も直し続ける道具の扱いはkintone×AI の記事に書きました。
この進め方が向く条件——AI が案を出し、人が承認する
5工程のうち、当社が AI に任せているのは案づくりと検出です。Excel の列名・型・空欄率を機械で読んで棚卸し表の下書きを作る、移行先の項目定義の案を出す、表記ゆれや文字化けの候補を洗い出す、突き合わせの処理を書く、差分に分類の一次案を付ける。
人が決めるのは、その先です。どの列を落とすか、どちらの表記が正しいか、残った差分を許容するか、切替してよいか。AI が出したものは、業務の担当者が画面で見て承認するまでは案のままで、本番データには入れません。承認した人と日付は、差分の一覧に残します。
FDE（Forward Deployed Engineer）は、この案づくりと現場での確認を、社内に入って毎日回す役です。成立の条件は、顧客側に Echo 役——FDE と一緒に画面を見て、その場で「この列は要らない」「この表記が正しい」と答えを出せる担当者——を1人立てられること。Echo 役がいないと、案の承認が週次の会議待ちになり、工程が止まります。
| 進め方 | 向いている条件 | 気をつけること |
|---|---|---|
| 社内でやる | 現行の仕様を説明できる人がいて、その人に移行の時間を割ける。移行先の製品を触れる担当も社内にいる | 通常業務との兼務になり、締めや繁忙期に手が止まる |
| 要件を固めて外部へ委託する | 移す範囲と現行の仕様が文書で確定していて、期間中に変わらない | 棚卸しの途中で範囲が変わると、変更の手続きに時間がかかる |
| FDE 方式で外部と一緒にやる | 現行の仕様が文書になっておらず、移す範囲を決めながら進めるしかない。決められる人が社内にいる | 顧客側の時間を毎週使う。Echo 役を立てられないと成立しない |
最初の打ち合わせに持ってきていただくのは3つです。いま使っている Excel 台帳の現物（加工しないもの）、旧システムから出せる CSV の見本1か月分、誰が入力して誰が承認しているかが分かる担当者の一覧。これで初回に棚卸し表の1行目が埋まります。費用を比べるときは、開発の金額だけでなく、並行稼働で現場が使う時間と、切替後に社内で直せる範囲を同じ表に並べてください。
まとめ
この記事を読んだ後にやることは1つです。移行したい業務を1つ選び、その主担当と2人で棚卸し表の6列を埋める。全業務を一度に洗い出そうとすると終わらないので、受注台帳なら受注台帳だけ、経費精算なら経費精算だけに絞ってください。埋め終わった時点で、移行の作業量と、経営が決めるべきこと（何年分を移すか、いつ旧手順を止めるか）が両方見えます。
表が埋まらない列があれば、そこが最初の論点です。「残す理由」が書けないなら使っていない可能性があり、「誰が承認するか」が書けないなら、移行の前に責任の所在を決める必要があります。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
Excel 台帳と旧システムの移行を、棚卸しから切替まで一緒にやります
現物の棚卸し表づくり、移行対象の絞り込み、キーと文字コードの設計、試し移行と突き合わせの完了基準、並行稼働の期間と終了条件、切替日と旧手順の停止日の決め方まで、貴社の業務と既存システムに合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、いま手元にある Excel 台帳を並べるところから始められます。