段階導入を検討する企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、全体像を描いた上で、止められない業務から優先順位を決めることを重視して進め方を整理します。
この記事では、基幹システム再構築を一度に行わず段階的に進める場合の、ロードマップの作り方を整理します。投資を分散したい経営層と、業務を止めずに刷新を進めたい情報システム担当者の双方が、同じ地図を描くための内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
段階導入の肝は「分け方」——切る場所を間違えると高くつく
段階導入は投資とリスクを分散できる優れた進め方ですが、業務の切れ目を無視した分け方をすると、段階のあいだを埋める一時的な連携の開発が膨らみ、かえって総費用が増えます。受注と在庫、請求と債権のように密接に結びついた業務は同じ段階にまとめ、比較的独立した業務（帳票、マスタ管理、周辺のExcel業務など）を先行または後続に切り出すのが基本です。分け方の巧拙が、段階導入の成否そのものと言えます。
最初に全体像、次に順番——順番だけ決めるのは危険
段階導入というと「まずどこからやるか」の議論になりがちですが、先に決めるべきは完成形の全体像です。最終的にどの業務がどうつながるのか、データはどこで一元化されるのかという到達点を描いてから、そこへ至る順番を決める。この順序を守らないと、各段階が場当たりの積み木になり、後の段階で作り直しが発生します。全体像は精密な設計書である必要はなく、業務とデータのつながりを一枚で示す地図があれば十分です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
段階導入でよくある失敗は、第一段階の成功の後に熱が冷め、続きが宙に浮くことです。予算や担当者が変わり、一時しのぎのはずだった新旧連携が恒久設備になってしまう。これを防ぐには、各段階の完了時に次段階の判断を行う場を最初から計画に組み込み、経営層の合意として文書化しておくことが有効です。
また、段階のあいだの「つなぎの連携」を軽く見積もる失敗も多発します。旧システムと新システムが共存する期間のデータ連携は、使い捨てになると分かっていても品質を落とせない厄介な開発です。つなぎのコストを含めて段階案と一括案を比較しないと、判断を誤ります。
さらに、全段階を細かく計画しすぎるのも考えものです。二年先の業務や組織は変わり得るため、直近の段階は詳細に、先の段階は方針レベルにとどめ、段階の完了ごとに見直す「粗密をつけた計画」が現実に耐えます。
自社で確認できるチェックポイント
ロードマップづくりに着手する前に、次の点を確認しておくと、分け方と順番の議論が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
段階導入ならではの棚卸しポイント
基本のチェックリストに加えて、業務間のデータのつながり（何がどこへ流れているか）、止められない業務と止めても影響の小さい業務の区分、保守期限などの外部制約がある領域、そして各年度に投じられる予算の目安を確認してください。特に外部制約は順番を決める最大の要因で、サーバーやソフトの期限がある領域は自動的に先行候補になります。予算の年度枠が明確なら、段階の大きさをそれに合わせて設計でき、稟議も通しやすくなります。
棚卸しでは、社内の推進体制が各段階を支え続けられるかも確認してください。段階導入は数年にわたる取り組みになるため、担当者一人の熱意に依存した体制では途中の異動や退職で計画が漂流します。役割を複数人で分担し、経営層に定期報告する場を設けることが、計画を組織のものにする条件です。
延命・部分改善で対応できるケース
段階導入の第一歩は、大きな開発である必要はありません。次のような着手の仕方が、リスクを抑えつつ全体を前に進めます。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、現行調査とマスタ整備、帳票の統廃合といった「どの構築方式でも無駄にならない作業」を第一段階に置く方法です。数百万円規模で足場を固めながら、その過程で得た情報で後続段階の見積精度が上がるため、投資判断の質も同時に向上します。
また、効果が数字で見えやすい業務（入力工数の大きい帳票やCSV連携の自動化など)を初期段階に含めると、社内に「変わる実感」が生まれ、後続段階への協力と予算の追い風になります。最初の成功体験の設計は、技術計画と同じくらい重要です。
費用と期間の目安としては、全体像づくりと第一段階の計画策定で数十万〜数百万円・1〜3か月、各段階はそれぞれ数百万〜数千万円・半年〜1年程度を一つの単位とし、全体では2〜4年をかける形が中堅企業では現実的です。一括構築に比べて総額は1〜2割増えることもありますが、失敗時の損失上限を各段階の規模に抑えられることが、段階導入の最大の経済的価値です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
段階の中身は、構築方式との組み合わせで決まります。方式別のロードマップへの織り込み方は次のとおりです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージを核にする場合は、パッケージ本体の導入を一つの段階に据え、その前段にマスタ整備と業務標準化、後段に周辺の個別対応を配置する三段構成が定石です。パッケージ導入と業務変更を同じ段階に詰め込みすぎないことが、消化不良を防ぎます。
周辺開発で補うケース
周辺開発を活用する場合は、現行基幹を当面残す前提で、負担の大きい周辺業務から順に切り出して開発し、最後に中核を刷新する「外から内へ」の順番が取れます。現場の実感を積み上げながら進められる、合意形成に強い進め方です。
スクラッチ再構築が向くケース
スクラッチで全面刷新する場合も、設計は全体で行い、稼働は業務単位・拠点単位で分ける段階リリースが可能です。設計の一貫性と導入リスクの分散を両立できる反面、共存期間の連携設計が最も重要になります。
マクティズムの見解
マクティズムの見解として、基幹システム再構築の段階導入ロードマップの作り方では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、全体像を描いた上で、止められない業務から優先順位を決めることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
ロードマップの相談で私たちが最も時間をかけるのは、実は分け方の検討です。開発の都合ではなく業務の切れ目で分けること、そして各段階が単独でも投資に見合う効果を持つように設計すること。この二つを守ったロードマップは、途中で経営環境が変わっても組み替えが利きます。計画は完璧さより、変化に耐える柔らかさが大切だと考えています。
相談前に準備しておく情報
段階導入の相談では、対象業務の全体像が分かる簡単な図やメモ、外部制約（保守期限など）のある領域、年度予算の目安、社内で優先したい課題の順位感が分かると、初回からロードマップの骨子を一緒に描けます。整った資料でなくても、ホワイトボードの写真程度で十分です。
実務では、現行調査で業務とデータのつながりを一枚の地図にし、開発前診断で段階の切れ目とつなぎのコストを見積もったうえで、経営の投資計画と重ねたロードマップに仕上げる流れをおすすめしています。
よくできたロードマップは、システム部門の計画書であると同時に、経営の投資物語になります。今年ここまで、来年ここまでと到達点が語れる計画は、社内の期待と協力を集め、プロジェクトを完走させる推進力そのものになります。
作成は、全体像の地図、段階の切れ目の設計、第一段階の詳細化、の順で進めます。第一段階が動き出したら、その学びで第二段階を具体化する——この繰り返しがロードマップを生きた計画に保ちます。
ロードマップには、各段階の効果を測る指標も書き込んでおきましょう。入力時間の削減、締めの早期化、残業の減少など、段階ごとに「何がどれだけ良くなったら成功か」を先に決めておけば、次段階の投資判断が感覚ではなく実績に基づいて行えます。測れる計画は、続けられる計画です。
完成したロードマップは、経営会議で正式に承認を得て、年度計画や予算編成の文書と紐づけておくことをおすすめします。組織の公式な計画に位置づけられているかどうかが、担当者が交代しても続く計画になるかの分かれ目です。
そして、ロードマップは年に一度は見直してください。事業の変化や第一段階の学びを反映して描き直すことは、計画の失敗ではなく、計画が生きている証拠です。
また、各段階の谷間には現場の休息と定着の期間を意図的に置いてください。導入が連続すると、現場は変化に慣れる前に次の変化を迎え、疲弊が協力の枯渇に変わります。計画に余白を持たせることも、完走のための立派な設計です。
地図と順番と余白。この三つがそろったロードマップなら、数年がかりの刷新も着実に完走できます。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。段階導入の場合、業務の全体像と優先課題の順位感が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。現行調査やマスタ整備といった小さな第一段階から始め、続きは結果を見て判断する形が基本です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。段階ごとにパッケージと個別開発を使い分ける組み合わせも含めて、一緒に比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。第一段階として数百万円規模の改善から着手し、効果を確認して次へ進む形に対応しています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。まず全体像を伺い、どこで区切るのが自社にとって自然かから一緒に整理します。
