基幹システム開発の進め方｜現役情シスが経験した製造・データ移行・テスト
「設計までは順調だったのに、開発の後半で何を確認すればいいのか分からない。」
システム開発で、そんな悩みを抱えていませんか？
製造・データ移行・テストは、設計したシステムを実際に動く形にし、本番に向けて品質と現行データを整える工程です。
ここでつまずくと、次のようなトラブルにつながります。
- 移行したデータが使い物にならず、業務が止まる
- テストで不具合が出続け、稼働日が後ろ倒しになる
- 検証フェーズで仕様の認識違いが見つかり、想定外の手戻りが発生する
今回の記事では、私が会計システムの入替で経験した製造・データ移行・テストの3工程をお伝えします。
前回のキックオフ〜詳細設計編の続きです。
現場でつまずいた点と切り抜け方をお伝えするので、ぜひ最後までご覧ください。
目次
1. 製造〜テストの全体像と今回扱う範囲
システム開発は、調達で決めた方針を、動くシステムへ作り上げる工程です。
全体像は前回お伝えしたとおり、大きく8つの工程に分かれます。
- キックオフ
- 要件定義
- 概要設計（基本設計）
- 詳細設計
- 製造
- データ移行
- テスト（単体・結合・総合）
- 本稼働
前回は、前半の4工程（キックオフ・要件定義・概要設計・詳細設計）をお伝えしました。
今回は、その後の製造・データ移行・テストに絞ってお伝えします。
2. 工程⑤｜製造フェーズ
製造とは、詳細設計で固めた仕様をもとに、実際にプログラムを作り込む工程です。
2-1. 製造でやったこと
製造は、ベンダー社内の作業が中心です。
発注者（情シス）が手を動かす場面は、ほとんどありません。
ベンダーから来る仕様確認に答えるのが、おもな仕事になります。
それぞれの役割を整理すると、次のようになります。
| 立場 | 製造期の主な動き |
|---|---|
| ベンダー | 詳細設計をもとにプログラムを作り込む／単体テストを進める |
| 発注者（情シス） | 仕様確認の回答／進捗管理／後工程（移行・テスト）の準備 |
2-2. 「待ち」の裏で並走管理が始まる
ただし、ただ待っていればよいわけではありません。
製造期は、いくつかの工程が同時に動き出す「並走」の時期でもあります。
現場メモ
私のプロジェクトで並走していたのは、次の2つです。
- 一部機能の先行稼働：予算編成の領域だけが先に進み、ほかより早く製造・単体テストに入った
- データ移行：詳細設計のころから、現行データの解析を並行で進めていた
フェーズが並走すると、タスクやスケジュールが煩雑になり見えづらくなります。
対策としてはWBS（詳しくは後述）を作成し、自分の手元で一元管理できるように工夫しました。
3. 工程⑥｜データ移行
データ移行とは、現行（旧）システムのデータを、新システムで使える形に移し替える工程です。
3-1. データ移行でやったこと
データ移行と聞くと、データを新システムへ流し込む作業を思い浮かべるかもしれません。
しかし実際にやったことの中心は、移行する前の「現行データの解析」でした。
現行システムは、数十年にわたって使われてきたものであり、解析では以下の壁にぶつかりました。
- データ項目の量が、とにかく多い
- どのデータが現役で、どのデータが使われていないのか分からない
- 同じ業者が複数の表記で登録され、どれが本物か分からない
たとえば取引先の業者名は、同一業者でも「株式会社○○商事」と「㈱○○商事」が混在する状態です。
どちらが実際に使われているデータか判断がつきません。
3-2. 突破口は「1件ずつ総当たり」
解析の解決策は、データ項目をひとつずつ地道に確認することでした。
システム上で実際にデータを呼び出し、どれが現役なのかを見極めます。
たとえば取引先は約3,000社ありますが、そのうち100社ほどを呼び出して使われている項目を確認しました。
業者名の表記ゆれも同じ要領で整理し、この解析だけで約2週間かかりました。
| 起きていた問題 | 対応 |
|---|---|
| 同じ業者の重複登録（例：「株式会社○○商事」と「㈱○○商事」） | 実際に取引のある表記に寄せる |
| 使っていないデータ項目が多い | 利用実績を確認し、移行対象から外す |
手こずったのは、業者名だけではありません。
- 和暦と西暦が混在
- 勘定科目や部門などの一致しないコード体系
- 外字や旧字、全角と半角が入り混じった文字
これらも一つずつ拾い出し、新システムに合う形へ直していきました。
現場メモ
この解析に手間取った理由のひとつに、ベンダーを入れ替えた事情があります。
現行システムは旧ベンダーが作ったもので、新しいベンダーは中身を知りません。
かといって、契約の切れる旧ベンダーに、データ移行の詳細を聞くのは気が引けるものです。
システムを熟知したベンダーに頼れない中での移行は、地道な手作業に頼るほかありませんでした。
4. 工程⑦｜テスト
テストとは、作り上げたシステムが、仕様どおりに正しく動くかを確認する工程です。
4-1. テストでやったこと
テストは段階を追って進みます。
- 単体テスト：プログラム1つずつの動作確認（ベンダー社内が中心）
- 結合テスト：機能をつないだ動作確認（ベンダー社内が中心）
- 総合テスト：業務の流れに沿って、システム全体が正しく動くか確認
- 連携テスト：他システムとのデータのやり取りの確認
単体・結合テストは、ベンダー社内でほぼ完結します。
発注者（情シス）が関わるのは、総合テストと連携テストからです。
総合テストでは、実際の業務の流れに沿って動作を確認します。
連携テストでは、連携システムを使って実際にデータのやり取りが上手くいくか確認します。
ちなみにテストの後に「検証」という工程が控えていますが、テストとは以下の違いがあります。
テスト：「仕様どおり動くか」をベンダーが見る
検証：「要望どおり使えるか」を発注者（社内ユーザー）が見る
検証については、次回の記事で詳しくお伝えします。
4-2. テスト工程で発覚した失敗
テスト工程で、私は大きな失敗に気づかされました。
テスト工程の課題管理とスケジュール管理をベンダー任せにし、開発の遅れに気づけなかったのです。
テストの段階に入ると、各開発のリスケがやたらと多く、違和感のある対応が目立つようになりました。
しつこく問いただしてみると、電子決裁との連携部分が大幅に遅れる見込みだと分かったのです。
それまでも進捗は何度も聞いていましたが、「ちょっと確認しますね」と、やんわりはぐらかされていました。
現場メモ（失敗）
はぐらかされ始めたら、黄色信号です。
「確認します」が続くなど違和感がある対応をされるときは、何かトラブルが起きている可能性があります。
進捗はベンダーに任せきりにせず、私の方でも数字で握るべきでした。
この電子決裁の遅れがどうなったかは、検証・本稼働を扱う次回で詳しくお伝えします。
5. 製造〜テストで工夫したこと
ここまでの3工程で、私が意識した工夫を2つ紹介します。
5-1. 「待ち」の時間に、後半の準備を前倒しした
製造期は、発注者にとって手が空きやすい時期です。
私はこの時間を使って、開発後半に必要な準備を、前倒しで進めました。
たとえば、次のようなものです。
- 現行データの解析
- テストや検証で確認する項目の洗い出し
- 研修やマニュアルのたたき台づくり
このような準備を前倒したことで、本番直前の負担が軽くなりました。
5-2. 増え続けるタスクをWBSで一元管理した
開発の後半に入ると、情シスのタスクが一気に増えます。
- 研修準備（社内向けの操作研修）
- 検証準備（担当範囲の割り振りや手順づくり）
- マスタ設計・登録
- マニュアル作成
- 社内の各種手続き（決裁・契約・通知など）
これらが同時並行で押し寄せ、完全なマルチタスク状態になります。
対策として私は、WBSを作って乗り切りました。
WBSとは、プロジェクトの作業を細かい単位に分解し、一覧にして管理する手法です。
ひとつひとつの作業に「担当」「開始日」「期限」「進捗」をひも付け、全体を一枚で見渡せるようにします。
私はこの表に「いつ・何を・どこまで終わったか」を書き込み、タスクの抜け漏れとスケジュールの遅れを防ぎました。
まとめ
製造・データ移行・テストの3工程で得た教訓は、おもに次の2つです。
- データ移行は、「現行データの解析」が大変
- 進捗はベンダー任せにせず、自分でも数字で握る
一番こたえたのは、長年ためこまれた現行データから、現役のものを見極めていくデータ移行の解析でした。
そして一番の反省は、開発の遅れにすぐ気づけなかったことです。
次回は、検証・本稼働をお伝えします。
ここまで積み上げてきたものが、いよいよ本番を迎えます。
そこで起きた苦労も、包み隠さず書きますので、お楽しみに。