基幹システムの入れ替え費用と期間は、今の仕組みの『書かれていない処理』の数で決まる｜見積もりの前に数える帳票・連携・独自の計算

基幹システム（販売管理・生産管理・会計など）の入れ替えや刷新にかかる費用と期間は、相場表の金額帯からは決まりません。どちらも入れ替えに要る作業の量（工数）で決まり、その工数を大きく動かすのが、今の仕組みが実際にしている処理の量です。なかでも効くのは、設計書に書かれていない独自の計算や例外の処理と、仕組みの外で人がしている手作業です。見積もりを頼まれた開発会社は、見えない部分を幅や予備として見込むことになるので、中身が分からないほど各社の金額は離れ、あとから追加の費用も出やすくなります。

骨格は公開データで確かめられます。JUAS（日本情報システム・ユーザー協会）が2025年4月に出した「ソフトウェア・メトリクス調査2025」ガイドブックでは、195件の分析で、工数だけで開発の総費用の違いの92%が説明できました（p.21）。期間も工数との関係で表され、標準的な期間（標準工期、か月）は、全体の工数（人月）の立方根に3.23を掛けた値です（232件、p.7。1人が1か月働く量が1人月。JUAS の例では125人月で16.15か月）。同じ JUAS の「企業IT動向調査報告書2026」では、工期が予定より遅れた割合が、10人月未満のプロジェクトの9.6%に対して、500人月以上では47.8%でした。前者は従来型の開発を中心としたプロジェクトの実績、後者は上場企業とそれに準じる企業の回答で、自社の案件の金額や月数にそのまま当てはめるものではありません。それでも、費用と期間の出発点が工数であり、工数が大きいほど予定どおりに進みにくいことは読み取れます。費用の骨格の読み方と、予算の上限を社内で決める順番は、「予算が決まっていないときのシステム開発費の考え方」にまとめました。

この記事では、入れ替えの見積もりの幅が広がる理由、見積もりの前に数えるものとその数え方、書かれていない処理の書き起こし方、数えた結果が見積もりのどの行に効くか、期間の目安と切り替えの日の決め方、製品に寄せる所・作る所・残してつなぐ所の分け方、見積もり依頼に添える1枚の中身を、この順に取り上げます。根拠には、JUAS の調査のほか、情報処理推進機構（IPA）がまとめたシステム再構築のガイド、経済産業省の委員会の報告を使いました。書き手の Aurant Technologies は特定の製品を売る立場になく、基幹システムの中身の書き出しから移し先の選び方までを手がけています。自社がその幅のどこに入るかは数えるまで分からないため、相場の金額表は載せていません。

見積もりの幅は、開発会社から見えない「今の仕組みの中身」の分だけ広がる

入れ替えの見積もりでは、開発会社は、手に入る材料から今の仕組みの処理を読み取って金額にします。材料は、設計書などの資料、渡されればソースコード、そして打ち合わせでの聞き取りです。IPA が2018年2月に出した「システム再構築を成功に導くユーザガイド 第2版」は、ここに食い違いが生まれやすいと指摘しています。発注する側は、いま動いている仕組みがそのまま引き継がれると考えるのに対して、開発会社は、資料とソースコードを拠り所にして「今どおり」を仕様に起こすからです（p.15）。

長く使ってきた仕組みでは、資料・ソースコード・動いている仕組みの三つがずれていきます。仕様を変えたときに関係する業務の資料までは直さなかった、障害の対応でソースコードだけを直した、といった積み重ねです。ガイドは、どれを正とするかを見極めないまま進めると、誤った「今どおり」ができあがるとしています（p.16）。ガイドには、設計書の半分以上が実際の仕組みと食い違っていて、試験の段階で機能の抜けや結果の不一致が相次いだ例や、資料では10秒を目標としていた処理が実際には1秒ほどで終わっていたため、資料に沿って作った新しい仕組みが現場から遅いと受け止められ、作り直しで稼働が延びた例が載っています（p.16〜17）。

見えない部分について、開発会社は幅や予備を見込むか、「今どおり」とする範囲を前提条件で区切るしかありません。同じガイドは、再構築の計画を立てる段階は不確かなことが多く、見積もりの精度が低くなりやすいとして、工程の区切りごとに見積もりを細かくし直すことと、不確かな所を先に試して確かめること（事前検証）を勧めています（p.122）。JUAS の企業IT動向調査でも、予算が予定を超えた要因に「想定以上の現行業務・システムの複雑さ」を挙げた企業が51.4%、工期が遅れた要因では48.8%あり、「計画時の考慮不足」と並んで上位でした（「企業IT動向調査報告書2026」 p.154〜155。予算の超過や工期の遅延があったと答えた上場企業などに、複数回答で聞いた結果です。入れ替えに限らず、システム開発全般についての設問です）。

発注する側にできるのは、見積もりの前に中身を見えるようにしておくことです。数えられるものを数え、書かれていない処理を書き起こしておけば、各社が同じ前提で見積もれるので、金額の違いを前提の違いとして読めます。「今どおり」をめぐる追加が後から出る余地も小さくなります。

見積もりの前に数える：画面・帳票・バッチ・連携先・マスタ・データ・手作業・使う人

数える連携先やデータの中に、.NET や PostgreSQL、PHP のような業務システムの部品の期限が近いものがないかも確かめます。期限と、開発会社に聞く順番は「業務システムの部品の期限」で解説しています。

数えるのは、今の仕組みが受け持っている仕事の単位です。IPA のガイドが今の仕組みを調べる材料に挙げているのは、運用と保守の記録、資料、ソースコードや画面・帳票の定義、外部との接続の定義で、それでも分からない所は、業務に詳しい人や実際に使っている人に聞いて埋めます（p.40）。調べた結果として得たい項目には、資産の規模、処理の方式、外部との接続、印字の位置を変えられない帳票の有無、運用の時間帯、データの容量と増え方などがあります（p.41〜42）。発注する側が数えるなら、次のように分けると、見積もりの行と結びつけやすくなります。

画面と帳票は、メニューと権限の設定、帳票の一覧から数え始め、部署ごとに誰がいつ使うかを横に書きます。帳票は、取引先が様式を決めているもの、専用の用紙に印字するもの、役所に出すものを分けておきます。ガイドも、印字の位置を今のまま引き継ぐ必要のある帳票があるかどうかを、手法にかかわらず引き継ぐ項目に挙げています（p.42）。

バッチ（夜間や月末に決まった時刻に自動で動く処理）は、スケジュールの登録から数え、動く順番とかかっている時間を控えます。締めの夜の処理が朝までに終わっている、といった時間の約束も「今どおり」の一部で、ガイドでも、今の実行スケジュールの中でバッチの処理が終わることが、引き継ぐ内容を決めておく対象の例に挙がっています（p.89）。

連携先は、データを受け渡す相手ごとに、何を、どちら向きに、どのくらいの頻度で、どの方法で受け渡すかを書きます。相手のシステムが形式や時刻を決めている連携は、こちらの都合では変えられないので、印を付けておきます。受注の仕組みで取引先ごとの違いが多いなら、その違いを型と例外に分けて数える方法を「受発注システムの開発費は、取引先と例外の数で決まる」に書きました。

マスタ（取引先・品目・単価など、取引のたびに参照する台帳）とデータは、種類ごとの件数に加えて、何年分を移すかを決めます。データを全部移すと作業も時間も費用も増えるので、ガイドは移す範囲を絞るよう勧め、稼働している期間のうち3年以上前のデータは移さない、といった範囲の決め方を例に挙げています（p.120）。経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」も、移行で問題が起きやすいのはデータの移行で、難しさはデータの質と量、管理の精度で大きく変わるとしています（本文 p.36）。

移さない年の分は、どこで見られるようにするかを一緒に決めます。法人税の決まりでは、帳簿と取引に関する書類は、原則として確定申告書の提出期限の翌日から7年間の保存が求められます（国税庁 タックスアンサー No.5930。欠損金が生じた事業年度などは10年間）。今の仕組みを参照のために残すのか、データを書き出して保管するのかは、経理の担当と税理士に確かめて決めます。

手作業は、仕組みの外で毎月繰り返している作業です。仕組みから出したデータを Excel で加工して帳票にする、入力の前に取引先からの注文を整える、出てきた帳票を手で直す。こうした作業を新しい仕組みに取り込むか、Excel に残すかで、見積もりが変わります。マクロが絡んでいて中身の分かる人がいない場合は、「作った人がいないExcelマクロの引き継ぎ方」の手順で、まず処理を日本語に起こします。

使う人は、部署ごとの人数と役割を数えます。聞き取りの相手、操作の説明を受ける人、並行稼働の間に新旧の両方へ入力する人の数になるからです。今の業務に詳しい人（ガイドの言う有識者）一人が受け持つ範囲が広すぎると、作業が集中して進みが止まる所になりうる、という注意もガイドにあります（p.100）。

どの種類でも、使われていないものには印を付けておきます。移す対象に残せば、その分だけ作る量と確かめる量が増えるからです。今のプログラムや設計を引き継いで移す手法（ガイドの言うリホスト・リライト）について、ガイドは、使われていないものを対象に残すと、すべての工程で余計な費用がかかり、試験でも正解の無い確かめをすることになるとしています（p.97）。一覧の列は、下の折りたたみにまとめました。

書かれていない処理は、プログラム・運用手順・実際のデータから書き起こす

作った人がいなくて、プログラムを読める人もいないときに、AI でソースコードから仕様書を起こす範囲と、人が確かめる範囲は「作った人がいない業務システムの仕様書をAIでソースコードから起こす」で解説しています。

数えた一覧の中で、見積もりの幅をとくに大きく左右するのが、書かれていない処理です。ここでは、資料に載っていないのに、今の業務がそれを当てにして回っている処理を指します。在りかは次の四つに分けられ、書き起こす材料もそれぞれ違います。

プログラムの中にある処理は、ソースコードが残っていれば文章に起こせます。資料が足りないときの補い方について、IPA のガイドの分け方は、処理の細かな設計はソースコードから起こし直し、業務の要件に近い部分は業務に詳しい人と使っている部門に聞いて起こし直す、というものです（p.99）。ソースコードを読み解く作業には生成AIが使え、経済産業省の総括レポートも、移行の生産性を高める技術として、生成AIなどによる古いコードの解析を挙げています（p.36）。私たちも、プログラムの処理を日本語の仕様に起こす作業に、生成AI（Claude Code）を使っています。生成AIに渡すものと書き起こさせる形は「作った人がいないExcelマクロの引き継ぎ方」に、IBM i（AS/400）の RPG に固有の注意は「IBM i（AS/400）7.3・7.4のサポート期限の後にやること」に書きました。

プログラムの外で決まっている処理もあります。取引先の区分や品目の種別を表すコードで計算が分かれている、単価や率が設定の表に置かれている、夜間の処理を決まった順番で動かすことで結果が合っている、といった処理です。マスタと設定の中身を書き出し、実際のデータにどの区分のコードが何件あるかを数えると、プログラムに書かれた分かれ道のうち、今も通っているものと、もう通らないものを分けられます。

仕組みの外で人がしている作業は、運用の手順書や引き継ぎのメモがあれば集め、無ければ、月末や期末の締めの日に担当者の作業を順に書き留めます。資料や聞き取りに出てこない確認や手直しは、実際の作業の中で見つかることが多いからです。

処理の速さや、帳票が出る時刻も、使う人が当てにしている「今どおり」です。ガイドは、再構築で業務を続けられるかを確かめる対象に、操作のしやすさ、帳票が出るまでの時間、レイアウト、性能、決まった時間の内に処理が終わることを挙げています（p.102）。今の処理時間の記録があれば控え、無ければ、いつまでに何が出ていれば困らないかを使う人に聞きます。

書き起こしたものは、使っている部門と一緒に、一つずつ引き継ぎ方を決めます。ガイドは、「今どおり」にするかどうかの扱いを三つの例で示しています。帳票の文字の書体のように業務への影響が小さいものは、引き継がない。バックアップの方式が変わるので手順を変える、のように、運用を変えれば受け止められるものは、運用を変える。顧客に渡す帳票のレイアウトのように、変えると業務が続かないものは、費用と時間をかけて引き継ぐ（p.89〜90）。誰にも理由が分からない処理は、誰がどう決めるかを先に決めておき、それでも決まらない所が残るなら、その所と、要件定義でどう解消するかを見積もりの依頼に書きます（p.87・p.116〜117）。

数えた結果は、要件定義・データ移行・テスト・並行稼働の行に効く

会計の仕組みを替える前に過去の実績と予算を移し、移した数字を社内で毎月使ってきた報告書と突き合わせて確かめる進め方の例は、導入事例「会計システムの移行支援」で紹介しています。

開発会社の見積もりは、要件定義（何をどう作るかを決める工程）、設計・開発、テスト、データ移行、切り替え、操作の説明といった工程の行に分かれます。一から作る場合は設計・開発の行が中心になりますが、入れ替えでは、ここまでに数えたものが、それ以外の行も大きく動かします。IPA のガイドは、再構築に特有の作業として、「今どおり」の中身を決める作業、今の資料やプログラムをどこまで使うかで生まれる作業、足りない資料と人を補う作業、工程ごとの品質の確かめ、決め方の手順を回す作業、データ移行の計画にある作業を挙げ、それぞれを見積もりに入れるよう書いています（p.91・p.97・p.101・p.115・p.118・p.121）。そのうえで、見積もりが想定より大幅に大きくなったら手法を見直すこともありうるとし、その判断は要件定義の工程までに行うよう求めています（p.122）。

データ移行の行は、作業の多くを発注する側が受け持つ行でもあります。ガイドによると、移す対象やレイアウトなど発注する側が確かめる点が多く、中身の整理（データクレンジング）も要るため、準備に時間がかかります。問題が出たときに直す期間も計画に入れ、実際の業務データで試験をするために、試験の前に移行を終えておきます（p.119〜121）。見積もりでは、整理を誰が受け持つか、移行の練習（リハーサル）を何回見込んでいるかを確かめます。

テストの行では、新旧に同じデータを入れて結果を比べる確かめ方（ガイドの言う現新比較テスト）が中心になります。どこまで一致したら終えるかという完了の基準を先に決めて合意しておかないと、テストがいつまでも終わらなくなることがあり、ガイドは現新比較でとくに起きやすいと注意しています（p.114）。1年分の業務を日ごとに回して新旧を確かめるなら、そのデータを1年前から用意しておく必要もあります（p.119）。連携先との試験は相手のシステムの日程に左右されます。計画の時には確保できる見込みだった接続先の日程が取れないと分かる場面は、ガイドでも、決め方の手順が要る課題の例に挙がっています（p.117）。

並行稼働は、一定の期間、新旧の両方で同じ作業をして不具合を洗い出すやり方です。ガイドは注意として、使う部門の負担が増えるのでどこまで受け止められるかを確かめること、今の仕組みの保守の期限の内に収まるかを確かめることを挙げています（p.115）。またぐ締めの回数と二重に入力する人数は、発注する側の人の時間として、見積もりの金額の外にも積み上がります。

見積もりを受け取ったら、行ごとの工数と、その行で前提にした数（画面の数、移す年数、比べる帳票の数など）を並べて出してもらいます。見積書を行ごとに読むときの質問は「システム開発の見積もりは妥当か」で扱っています。

期間は工数から目安を出し、切り替えの日は決算・繁忙期・締めから決める

期間の目安は、見積もりで工数が出てから確かめます。冒頭で触れた JUAS のガイドブックの関係式は、232件の実績から求めたもので、標準工期（か月）は全体の工数（人月）の立方根に3.23を掛けて出します。プロジェクトごとの期間の違いの9割は、この工数で説明できたとされています（p.7）。JUAS の例では、125人月のプロジェクトの標準工期は16.15か月です。実績の期間は標準工期の1.08倍という関係で、JUAS は標準工期より1割ほど余裕を持って計画するのが安全だとしています（p.12）。50人月未満のプロジェクトでは、56%が標準工期より長くかかっていました（p.8）。見積もりの期間を標準工期と並べて確かめる手順は「システム開発の見積もりは妥当か」に書きました。

このデータは、情報システムの開発・保守を続けてきた企業から JUAS がアンケートで集めたもので、JUAS はこれまでのデータの使える範囲を、主にウォーターフォール型の開発としています（p.4・p.6）。パッケージを設定して使う入れ替えや、画面を先に作りながら進める開発では、式から出る月数をそのまま予定に使えません。工数に比べて期間が短すぎないかを見る物差しとして使います。

規模と遅れの関係は、別の調査にも表れています。JUAS の「企業IT動向調査報告書2026」では、工期が「予定より遅延」と答えた割合が、10人月未満のプロジェクトで9.6%、10〜50人月未満で16.2%、50〜100人月未満で25.4%、100〜500人月未満で38.8%、500人月以上で47.8%と、規模が大きいほど高くなっていました（p.151、図表7-1-4）。

調査の期間は2025年9月5日〜10月24日で、対象は東証上場企業とそれに準じる企業の計4,500社です。IT部門長に回答を頼み、957社が答えました（有効回答率21.3%。報告書 p.ix）。規模の区分ごとの回答数は、小さい順に684・561・402・317・226件です。答えたのが上場企業などなので、中小企業での割合とは限りません。

入れ替えを一度に行うか、業務ごとに分けて順に切り替えるかを考えるときの材料になります。分ければ1回あたりの規模は小さくなりますが、切り替えの回数だけ並行稼働が増え、先に移した業務と残した業務の間でデータを受け渡す期間も生まれます。

工数から出る期間とは別に、切り替えの日は業務の暦で決まります。見積もりを頼む前に、社内で次の日付を並べておきます。

• 動かせない日：今の仕組みの保守やサポートの期限、機械やデータセンターの契約の終わり
• 避けたい時期：決算と期末の締め、棚卸し、繁忙期。新しい仕組みで初めて通す締めを、いちばん忙しい月に重ねない
• 並行稼働でまたぐ締め：月次の締めを少なくとも1回。期末や年1回の処理が今の仕組みにあるなら、それをいつ、どのデータで確かめるか
• 会計を替える場合の期首：期の途中で替えると、期首からのデータを移すか、期末まで旧の仕組みで締めを続けるかを決めることになる

並べた日付から逆に、並行稼働、実際の業務データでの試験、データ移行の練習、開発、要件定義（書き起こしを含む）を置くと、要件定義を始めなければならない時期が見えてきます。見積もりの期間がこの中に収まらないなら、最初に切り替える業務を絞ります。

パッケージに寄せる所、作る所、残してつなぐ所を、数えた一覧の上で分ける

一覧ができると、業務ごとに移し先を決められます。同じ会社の中でも、製品（パッケージやクラウドのサービス）に置き換えるのがよい業務、作るのがよい業務、今の仕組みに残して周りをつなぐのがよい業務が混ざっています。経済産業省の総括レポートは、移し先の仕組みを、標準的な仕様に寄せる部分と付加価値を作り込む部分に分けて考えるよう求めています。中堅・中小企業については、経営資源の制約が大きいことから、注文で一から作る開発ではなく、パッケージや SaaS への移行を原則にすることを求め、製品との差が大きい業務でも、手を加えるのは最小限で済む方法を探すよう書いています（p.34）。

製品に寄せるときに見積もりを動かすのは、「今どおり」にしたいという要望の数です。IPA のガイドは、設計が具体的になるにつれて、今と同じ運用にしたいという要望が現場から上がることはよくあり、その結果、製品に手を加える量が増えていきやすいとして、製品の標準の機能と今の業務を突き合わせる Fit&Gap（合う所と合わない所の見極め）と、使う部門への確認を、計画の段階で済ませておくよう勧めています（p.25）。手の加え方は、設定だけでほぼそのまま使う、製品が用意する機能で手を加える、外付けの機能を足す、の三つに分けられています（p.27）。

ガイドには、会計の製品を入れる際に、独自の財務帳票だけを追加で作り、ほかは業務を製品に合わせると決めたのに、使う側の試験の途中で画面での確認の手順も今どおりにしてほしいという要望が出て、画面の追加の開発が加わり、見込んでいた開発と維持の費用の縮小が実現できなかった例が載っています（p.26）。書き起こした一覧で「運用を変える」とした処理は、決める段階で使う部門と合意しておきます。経済産業省の総括レポートも、今の機能を守ることにこだわると、移行のときに多くのカスタマイズが要り、費用がかさむ要因になりうるとしています（p.26）。

作る業務では、書き起こした計算や例外がそのまま仕様の材料になり、今の仕組みが出した帳票とデータが、新しい仕組みの答え合わせの材料になります。残してつなぐ業務は、今の仕組みが安定して動いていて、困っているのが入力・集計・外とのつなぎに限られる場合に選べますが、保守の期限と、中身を分かる人がいない問題は残ります。同じガイドは、今の仕組みを作り直すときに業務の変更を同時に行うと、変更の影響がどこまで及ぶかを切り分けにくく、品質を確かめるのが難しくなるとして、作り直しを終えてから業務の変更を取り込む進め方を、もっとも安全で確実な方法としています（p.124〜126）。

どの移し先にするかで、5年間に払う総額も変わります。作り方ごとの総額の出し方と、使い始めてから直せる人の違いは「業務システムは買うか作るか」で比べています。

見積もりの依頼には、数えた結果と決めていない所を1枚にして添える

数えた結果は、見積もりの依頼に添える1枚の紙にします。依頼先が何社でも、渡す紙は同じにしておくと、届いた金額を同じ前提で並べられます。埋まらない欄は空白にせず「未定」「分からない」と書きます。そう書いた欄には、開発会社から質問が来るので、打ち合わせで何を聞かれるかも先に分かります。

頼み方も1枚に書き添えます。一つは、要件定義（今の仕組みの書き起こしを含む）を、開発と分けて見積もってもらうことです。IPA のガイドが勧める段階的な見積もりの形で、要件定義で分かった中身をもとに、開発の見積もりを取り直せます（p.122）。もう一つは、未定の欄を各社がどう置いたか（例外を何件と見込んだか、何年分を移す前提か）を見積もりに書いてもらうことです。前提が書いてあれば、金額の違いを前提の違いとして読めます。

今のシステムを作った会社や保守の会社に、どこまで協力してもらえるかも書いておきます。ソースコードや資料を出してもらえるか、新旧を比べるための旧の帳票とデータを誰が用意するか。IPA のガイドには、計画の時は発注する側で用意するつもりだった比べるためのデータが、実際には用意できないと分かる場面が、決め方の手順が要る課題の例として載っています（p.117）。

Aurant Technologies では、基幹システムの入れ替えの前に、今の仕組みの画面・帳票・計算を書き出し、業務ごとに移し先を選び、新旧の結果を突き合わせるまでを受け持っています。今の仕組みの棚卸しから始める進め方は、「基幹システムの刷新・レガシー移行の相談」で紹介しています。