AI・IT経営ケース 2026-09-15

AI・IT経営ケース｜AI活用・IT戦略・セキュリティの実践事例 IT

AI・IT経営ケース 2026-09-15

今週はITテーマ：50年使った基幹システムを、なぜ「そのまま再現」しなかったのか

今回は、大日本土木が50年稼働したメインフレームをSaaS型ERPへ刷新した事例を取り上げます。

ケースの事実

大日本土木では、長年の部分最適の積み重ねにより基幹システムが複雑化・ブラックボックス化していました。さらに、全国の支店ごとに業務フローが少しずつ異なり、異動すると同じ仕事でも手順を覚え直す必要がありました。

原価管理システムやグループウェアから出力したデータを手作業で転送・更新する作業や、紙帳票を介して再度基幹システムへ入力する二重入力も発生していました。その結果、最新実績は月次データを集約してからでなければ把握しにくい状態でした。

同社は基幹システム刷新にあたり、従来業務をそのまま新システムへ作り込むのではなく、NECの建設業向けSaaS型ERP「建設クラウド」を採用し、業務をシステム標準へ合わせる「Fit to Standard」を選択しました。

特に重要なのは、過去にカスタマイズを重ねた結果、法改正などへの対応に時間と費用がかかった経験から、原則としてノンカスタマイズで導入する方針を決めた点です。

2024年11月の本稼働後は、支店別の会計処理・実績管理をリアルタイムで把握できるようになり、データの二重入力も解消。NECが2026年2月に公表した導入事例では、決算処理工数が導入前比で約50％削減されたとされています。また、業務標準化によって内部統制の強化にもつながったと報告されています。

一方で、同社独自の会計処理など、単純に標準へ寄せにくい領域もありました。これらは、業務要件を確認しながらデータ移行方法やパラメータ設定などで対応しています。

ここで考えてみましょう

問1
各拠点から「この業務だけは特殊なので残したい」という要望が多数出た場合、どの業務を標準化し、どの業務を例外として残すべきでしょうか。判断するときに、現場へのヒアリング以外に何を確認しますか。

問2
決算処理時間が50％短縮されたとして、それだけでERP刷新を成功と評価してよいでしょうか。経営基盤の改善として評価するなら、その後どのような業務指標・経営指標を追いますか。

解説

この事例のポイントは、「古いシステムを新しいシステムへ交換したこと」ではありません。

より重要なのは、システム更新をきっかけに、長年積み重なった業務上の例外を整理し、会社として共通の業務プロセスを再設計したことです。

1．「現行業務を再現する」が最適とは限らない

基幹システム刷新では、各部門から「現在と同じように使えるようにしてほしい」という要望が出やすくなります。しかし、その要望をすべて実装すると、古いシステムで生じていた複雑さを新しいシステムへ移植するだけになる可能性があります。

例外業務を残すかどうかは、少なくとも次の観点で判断できます。

  • 法令・会計・契約上、本当に必要か
  • 顧客への提供価値や競争力に直結しているか
  • リスク管理・内部統制上必要か
  • 単に「以前からそうしている」という理由だけではないか

競争力や法令対応に関係しない独自処理であれば、システムをカスタマイズするより、業務を標準へ合わせた方が長期的な保守性や人員配置の柔軟性は高くなります。

2．IT投資の成果は「作業時間」だけでは測れない

決算処理工数50％削減は分かりやすい成果ですが、ERPの本来の価値は、経営判断に必要な情報が早く、同じ定義で、継続的に取得できることにもあります。

例えば、その後に確認したいのは次のような変化です。

  • 工事・案件別の採算悪化を何日早く発見できるようになったか
  • 支店間で同じデータ・同じ定義を使えるようになったか
  • Excelや個人管理表などの「ERP外管理」が減っているか
  • 担当者異動時の引継ぎ・教育期間が短縮されたか
  • 法改正や制度変更へのシステム対応期間が短くなったか
  • 月次予測と実績との差異が縮小しているか

こうした指標まで追うことで、単なる「IT部門のシステム更新」から「経営基盤の改善」へ評価軸を広げられます。

3．Fit to Standardにも注意点がある

Fit to Standardは、「現場の事情を無視してすべて標準へ合わせる」という意味ではありません。

実際、大日本土木の事例でも独自性の高い会計処理が存在し、データ移行方法などを工夫して対応しています。

重要なのは、例外をゼロにすることではなく、例外を残す理由を明確にし、例外が際限なく増えない仕組みを作ることです。

実務では、標準から外れる要望について「なぜ必要なのか」「誰が承認するのか」「将来の保守コストはどうなるか」を整理する例外管理が有効です。

4．クラウド化後にも経営上のリスクは残る

SaaS型ERPへ移行すると基盤更新や法改正対応の負荷は軽減できますが、別の論点も発生します。

外部システムとの連携停止、データ移行品質、クラウド障害時の業務継続、ベンダー依存、料金体系変更などです。

そのため、導入時には「正常時に効率化できるか」だけでなく、障害時の代替業務、データバックアップ、外部連携一覧、復旧優先順位なども経営側で確認しておく必要があります。

今回の実務上の学び

ERP刷新では、製品選定より先に「現在の業務をどこまで残すのか」を決めることが重要です。

特に長期間利用してきた基幹システムでは、システムの複雑さと業務の複雑さが一体化していることがあります。その状態で機能をそのまま移行すると、新システムでも同じ問題を抱える可能性があります。

一方、標準化を目的化するのも危険です。企業固有の競争力につながる業務まで削る必要はありません。

「標準化すべき業務」と「差別化のため残す業務」を分けることが、IT投資判断の中心になります。

なお、公開資料では決算処理時間などの効果は示されていますが、導入投資額や投資回収期間などは確認できません。したがって、今回のケースではROIについての推測は行っていません。

参考情報

コメント

タイトルとURLをコピーしました