システムは、プログラムが完成したらすぐ業務で使えるわけではありません。作ったものが要件通りに動くかを確認する「テスト」、既存データを新システムに移す「データ移行」、利用者が使えるようにする「操作教育」という、本番稼働に向けた作業が続きます。これらは本番化に欠かせないにもかかわらず、見積書では見落とされやすい費目です。
本記事は連載第7回として、テスト・移行・教育費を整理します。開発費が中心の見積では、これらが薄く見積もられていたり、別途扱いになっていたりすることがあります。本番で安定して使い始めるために、見積段階で確認しておきたい項目です。
まず結論
- システムは開発が終わっても、テスト、移行、教育が不足していると本番で使えません。
- 見積では、結合テスト、総合テスト、受入テスト支援、移行リハーサル、操作マニュアル、研修の有無を確認します。
- 本番稼働日から逆算し、発注側の受入テスト担当者と現場教育の時間を先に確保することが重要です。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| テスト | どの段階まで含むか | 単体・結合・総合・受入支援 |
| 移行 | リハーサルを行うか | 旧データの状態と移行回数 |
| 教育 | 利用者が使える状態にするか | マニュアル・研修・初期サポート |
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか？
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
この連載での位置づけ
- 前に読む記事：連載第6回：追加費用
- 次に読む記事：連載第8回：クラウド・API費
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
本番稼働までに必要な3つの作業
開発（実装）が終わってから本番稼働までの間に必要な作業を整理します。
| 作業 | 目的 | 見落とすと起きること |
|---|---|---|
| テスト | 要件通りに動くかを確認する | 本番で不具合が見つかり業務が止まる |
| データ移行 | 既存データを新システムへ移す | 移行作業が間に合わず稼働が遅れる |
| 操作教育 | 利用者が使えるようにする | 現場が使いこなせず定着しない |
いずれも、開発費とは別に工数がかかります。見積でこれらが含まれているか、別途かを確認することが、本番化のスケジュールと費用を読むうえで重要です。
テスト費の中身
「テスト」とひとことで言っても、いくつかの段階があります。
- 単体テスト：プログラム一つひとつが正しく動くかの確認（開発費に含まれることが多い）
- 結合テスト：機能をつないだときに正しく動くかの確認
- 総合テスト：システム全体として業務通りに動くかの確認
- 受入テスト（UAT）：発注側が、実際の業務に沿って確認するテスト
見積で確認したいのは、どの段階までが含まれているか、そして受入テストを発注側がどう進めるかです。受入テストは、発注側が主体となって「自社の業務で本当に使えるか」を確認する重要な工程です。ここを軽視すると、本番で初めて問題に気づくことになります。テストの位置づけは見積書の見方でも触れています。
データ移行費の中身
データ移行は、既存のExcelや旧システムにあるデータを、新システムで使える形に整えて移す作業です。次のような作業が含まれます。
- 移行対象のデータの洗い出し（どのデータを移すか）
- データの整形・クレンジング（表記ゆれや重複の整理）
- 移行用のプログラムの作成
- 移行リハーサル（本番前に試しに移行してみる）
- 本番移行と、移行結果の確認
とくに重要なのが「移行リハーサル」です。本番の移行を一発勝負で行うのではなく、事前に試して、データが正しく移るか・想定時間で終わるかを確認します。リハーサルが見積に含まれているかは、移行の安全性に関わる確認点です。データの状態によって工数が変わる点は、連載第6回の追加費用でも触れた通りです。
操作教育費の中身
どれだけ良いシステムでも、現場が使いこなせなければ業務は改善しません。操作教育は、利用者がシステムを使えるようにするための作業です。
- 操作マニュアルの作成
- 操作研修（説明会、ハンズオン）
- 稼働直後の問い合わせ対応（立ち上がり支援）
利用者の人数や役割が多いほど、教育の手間は増えます。マニュアルだけで足りるのか、研修まで必要かは、利用者のITへの慣れや業務の複雑さによります。教育費が見積に含まれているか、含まれない場合は社内の誰が担うのかを整理しておくとよいでしょう。
本番稼働までのスケジュールに余白を持つ
テスト・移行・教育は、開発が終わってから本番までの間に集中します。この期間を短く見積もると、受入テストで見つかった問題の修正や、移行のやり直しの時間が取れなくなります。本番稼働の希望日から逆算して、テストと修正、移行リハーサル、教育の期間に余白を持たせておくと、無理のない立ち上がりになります。とくに繁忙期に本番を重ねると、現場が新システムに慣れる余裕がなくなるため、稼働時期の選び方も合わせて検討したい点です。
並行稼働という移行の選び方
既存システムから新システムへ切り替える際、ある日を境に一斉に切り替える方法のほかに、一定期間は両方を動かす「並行稼働」という方法があります。並行稼働は、新システムに問題があっても既存システムに戻れる安心感がありますが、二重の運用負荷がかかります。一斉切り替えは負荷が小さい一方、切り替え当日にリスクが集中します。どちらを選ぶかで移行の作業量も変わるため、見積の前提として確認しておきたい点です。
発注前チェックリスト（テスト・移行・教育）
- テストがどの段階（結合・総合・受入）まで含まれているか分かるか
- 受入テストを、発注側がどう進めるかが共有されているか
- データ移行が見積に含まれているか、別途かが分かるか
- 移行リハーサルが含まれているか確認したか
- 移行対象のデータの状態（整形の要否）が見積に反映されているか
- 操作マニュアル・操作研修の有無と範囲が分かるか
- 稼働直後の問い合わせ対応（立ち上がり支援）の扱いが分かるか
- これらの作業を踏まえた本番稼働までのスケジュールが共有されているか
開発会社に確認する質問
- 「テストはどの段階まで実施し、受入テストはどう進めますか」
- 「データ移行は見積に含まれますか。移行リハーサルは行いますか」
- 「移行するデータの整形（クレンジング）は、どちらが担いますか」
- 「操作マニュアルや研修は含まれますか。利用者は何名を想定していますか」
- 「稼働直後の立ち上がり支援は、どの期間・どの範囲で対応されますか」
本番稼働までの作業を具体的に説明できる相手は、「作って終わり」ではなく定着まで見据えている傾向があります。
相談前に整理しておくとよい情報
- 移行したい既存データの種類・量・保存形式と、その整い具合
- システムを使う利用者の人数・役割・ITへの慣れ
- 本番稼働を希望する時期と、繁忙期など避けたい時期
- 受入テストに社内で割けるメンバーと期間
- マニュアル・研修に対する社内の期待水準
これらを整理しておくと、テスト・移行・教育の工数の前提が固まり、本番稼働までの計画を現実的に検討できます。
本番稼働前に置きたい判定基準
テスト・移行・教育費を判断するときは、「やったかどうか」ではなく「本番に進んでよい状態か」を基準にします。受入テストで重大不具合0件、業務影響のある不具合3件以下、移行リハーサル1回以上、主要利用者10名への操作説明完了、初週の問い合わせ窓口と対応時間を決める、といった形で判定基準を置くと、稼働判断が具体的になります。
この基準は案件ごとに変わりますが、見積段階で仮置きしておくことが重要です。基準がないまま本番日だけ決めると、移行当日に判断が集中します。逆に、テスト5日、移行リハーサル2回、操作研修1回などの前提を見積に入れておけば、費用とスケジュールを同時に読みやすくなります。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
また、教育費は削られやすい項目ですが、利用者が30名を超える場合や、複数拠点で使う場合は、初回研修だけでは足りないことがあります。録画マニュアル、FAQ、初月の問い合わせ対応を見積に含めるかを確認すると、定着までの費用を読みやすくなります。
実務では、見積書の1行だけで判断せず、議事録、提案書、契約書、メール回答を合わせて読みます。見積書に書かれていない前提でも、提案書に「別途」と書かれていれば追加対象になります。逆に、口頭で含むと言われた内容も、契約前に文書で残しておかないと、担当者変更後に確認が難しくなります。発注前の30分で前提を文書化するだけでも、後工程の手戻りは減らせます。
さらに、見積確認の結果は「採用する/しない」だけで終わらせず、未確認事項リストとして残します。未確認事項が5件以内なら契約前の確認で解消しやすいですが、10件以上残る場合は、見積比較より先に要件整理やRFP作成へ戻る判断も必要です。
この段階で判断に迷う場合は、発注ではなく見積レビューだけを先に行い、1週間以内に不足情報をそろえる進め方もあります。
契約前にこの確認を行うことで、発注後の調整を減らし、社内説明にも使える判断材料を残せます。
判断基準は、議事録と検収条件にも必ず反映します。
本番判定は責任者名まで残します。
必ず記録します。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. テストは開発会社に任せれば十分ですか。
A. 開発会社が行うテストに加えて、発注側が実際の業務で確認する受入テストが重要です。ここを行わないと、本番で初めて業務との食い違いに気づくことがあります。社内で受入テストを行う体制と期間を、あらかじめ用意しておくとよいです。
Q. データ移行で気をつけることは何ですか。
A. 既存データの状態によって手間が大きく変わります。表記ゆれや重複の整理（クレンジング）が必要だと工数が増えます。本番前に試す移行リハーサルが見積に含まれているかも、移行の安全性に関わる確認点です。
Q. 操作教育はどこまで必要ですか。
A. 利用者の人数やITへの慣れによります。マニュアルで足りる場合もあれば、研修が必要な場合もあります。稼働直後の問い合わせ対応まで含めて、誰が担うのかを整理しておくと、定着までの流れが見通せます。
まとめ
テスト・データ移行・操作教育は、本番稼働に不可欠でありながら、開発費中心の見積では見落とされやすい費目です。テストはどの段階まで含むか、移行はリハーサルを伴うか、教育はマニュアルと研修のどこまでを担うかを見積段階で確認することで、本番稼働の遅れや定着の失敗を抑えられます。次回は、リリース後に継続して発生する「クラウド費用・外部API費」の読み方を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。