LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

システム標準化・共通化とは何を指すか

システムの標準化・共通化とは、部門・拠点・グループ企業ごとに個別最適で構築されたシステムや業務ルールを、全社で共通の基盤・仕様・調達ルールに揃えていく取り組みを指します。単なるシステム統合とは異なり、基盤の共通化だけでなく調達方法や開発ルールの標準化まで含む点が特徴です。

経済産業省が2018年に公表した「DXレポート」は、部門ごとに個別最適で構築・改修が重ねられたシステムが老朽化・複雑化・ブラックボックス化し、経営・事業戦略上の足かせになっていると指摘しました^*1。同レポートは、こうした問題が解決されない場合、2025年以降に年間で12兆円に達する規模の経済損失が生じうると試算しています^*1。標準化・共通化は、この個別最適の積み重ねに歯止めをかけ、全社最適の基盤に組み替える取り組みにほかなりません。

標準化と共通化は近い意味で使われますが、厳密には役割が異なります。標準化は仕様・手順・ルールを統一する行為を指し、共通化は複数の部門・拠点で同じ基盤やシステムそのものを共有する行為を指します。両者は補完関係にあり、標準化されたルールがあって初めて共通基盤への集約が現実的になります。

多拠点展開やM&A（企業の合併・買収）を経てきた企業では、拠点ごと・買収先ごとに異なるシステムが並立しやすい状況にあります。IPAの「DX動向2025」は、日本企業の課題として「内向き・部分最適」から「外向き・全体最適」への転換を挙げています^*2。個別最適の積み重ねから全社最適への転換という視点は、システムの標準化・共通化を検討する出発点になるでしょう。

乱立が経営に及ぼす負荷——連携コストと意思決定の遅れ

システムが乱立した状態を放置すると、連携改修のコストと運用負荷が積み上がっていきます。個別最適で構築されたシステムは、後になって全社横断のデータ連携や意思決定の速度に影響を及ぼしやすいためです。

データ連携のたびに個別改修が発生する

部門・拠点ごとに異なるシステムが稼働していると、全社横断のデータ集計や新サービス連携のたびに、システムごとの個別改修が必要になります。改修の都度、仕様確認や連携テストの工数が発生し、結果として一つの施策にかかる期間とコストが膨らんでいきます。

保守契約とライセンスが分散しコストが見えにくくなる

拠点ごとに異なるベンダーとシステムを契約していると、保守契約・ライセンス費用・サポート窓口が分散します。全社でどれだけのIT費用が発生しているかを一元的に把握しづらくなり、コスト削減の余地があっても発見しにくい状態に陥りかねません。

経営判断に必要なデータが集まらない

経営層が全社横断の意思決定をする際、各拠点・部門のデータをシステムから集計する必要があります。システムが乱立していると、データ形式や集計単位が拠点ごとに異なり、経営会議に必要な資料を作るだけで多くの時間を要する事態になりがちです。IPAのDX動向2025が指摘する「内向き・部分最適」の状態は^*2、こうした経営判断の遅れという形で表面化しやすいと言えるでしょう。

標準化の対象領域を切り分ける——基盤・データ・調達・開発ルール

標準化・共通化を検討する際は、対象を一括りにせず、基盤・データ連携・調達・開発ルールという領域ごとに切り分けて整理する必要があります。領域によって難易度も進め方も異なるためです。

インフラ・基盤の標準化——サーバー環境とクラウド利用ルール

サーバー環境やクラウド利用のルールを標準化する領域です。拠点ごとに異なるクラウドベンダーやオンプレミス環境が混在していると、セキュリティ設定や監視体制も個別に維持することになります。まず基盤の標準仕様（採用するクラウドサービス・ネットワーク構成の型）を定める工程が土台になります。

データ連携の標準化——項目定義とAPI仕様の統一

システム間でやり取りするデータの項目定義やAPI（システム間でデータをやり取りする仕組み）の仕様を統一する領域です。データそのものの管理方針（マスタデータ管理やデータガバナンス）とは別軸の課題であり、システムがどのような形式でデータを受け渡すかという接続面のルールを指します。

調達の標準化——ベンダー選定基準と契約条件の統一

新規システムを導入する際のベンダー選定基準や契約条件を全社で統一する領域です。拠点ごとに個別の判断でベンダーを選定していると、後になって保守条件やセキュリティ水準にばらつきが生じかねません。調達の窓口や承認フローを一本化することで、条件のばらつきを抑えられます。

開発ルールの標準化——コーディング規約と運用手順

自社開発や委託開発を行う際のコーディング規約・テスト手順・運用手順を標準化する領域です。開発チームやベンダーが変わっても一定の品質を保てるようにする目的があり、属人化した開発体制からの脱却にもつながります。

共通基盤の考え方——全社最適と部門最適の線引き

標準化の対象を整理した後は、どこまでを全社共通基盤に集約し、どこまで部門・拠点の裁量に委ねるかを線引きする段階に入ります。すべてを一律に統一する必要はありません。

競争優位に直結しない業務（人事・経理・総務などのバックオフィス業務）は共通化の効果が出やすい領域です。IPAのDX動向2025が示す全体最適の視点は^*2、こうした非競争領域を共通基盤に集約し、事業部門ごとの独自性が求められる領域には個別の裁量を残すという役割分担に通じます。

一方で、事業部門ごとに競争力を左右する業務システムまで無理に共通化すると、事業特性に合わせた迅速な改修ができなくなるおそれがあります。共通化の対象は「複数部門で共通する業務か」「頻繁な独自改修が必要な業務か」という2つの軸で判断すると、線引きの基準が明確になるでしょう。

共通基盤を設計する際は、将来の拠点追加やM&Aによる統合も見据えておく必要があります。新しい拠点や買収先のシステムを後から共通基盤に組み込む前提を持たずに設計すると、拡張のたびに個別対応が発生し、標準化の効果が薄れてしまいます。

標準化を進める段階——現状把握から定着まで

標準化・共通化は一度の施策で完結するものではなく、現状把握から定着まで段階を踏んで進める取り組みです。段階を飛ばすと、現場の実態に合わない標準が押し付けられ、形骸化しやすくなります。

実態把握——シャドーITを含めた棚卸し

まず全社・全拠点のシステムを棚卸しし、情報システム部門が把握していないシステム（シャドーIT）がないかを確認します。部門が独自に契約したクラウドサービスや、退職者が個人で構築した簡易システムが放置されているケースもあるため、ヒアリングと利用ログの両面から実態を洗い出す工程が欠かせません。

優先順位付け——影響範囲とコストで評価する

棚卸しの結果をもとに、どのシステムから標準化に着手するかを決めます。利用部門数・年間の保守コスト・老朽化の度合いといった観点で評価し、影響範囲が広く改善効果の大きいシステムから優先的に着手すると、初期段階で成果を示しやすくなります。

段階移行——並行稼働期間を設けて切り替える

標準化した基盤への移行は、一斉切り替えではなく段階的に進めるのが実務上の型です。旧システムと新基盤を一定期間並行稼働させ、データ移行やユーザーの習熟状況を確認しながら切り替える運用にすると、業務停止のリスクを抑えられます。

定着——ルールを維持する体制を組み込む

標準を定めても、運用を担う体制がなければ時間の経過とともに個別対応が再び増えていきます。新規システム導入時に標準ルールへの適合を確認する審査体制や、定期的な棚卸しの仕組みを組み込むことで、標準化した状態を維持しやすくなります。

現場の抵抗への対応と外部知見の活用

標準化・共通化は、現場に業務プロセスの変更を求める取り組みであるため、抵抗が生じやすい施策です。抵抗の背景を理解した上で対応する必要があります。

現場が抵抗する背景——使い慣れたシステムからの移行負荷

現場の担当者にとって、使い慣れたシステムを新しい共通基盤に切り替えることは、一時的な業務効率の低下や習熟の負担を伴います。過去に個別最適で構築したシステムほど、その部門固有の業務フローに合わせて作り込まれているため、標準仕様への移行で「今までできていたことができなくなる」という不満が出やすくなります。

対応の型——早期の説明と現場代表者の巻き込み

抵抗を軽減するには、標準化の目的とスケジュールを早い段階で現場に説明し、各部門から代表者を選出して仕様検討に巻き込む進め方が有効です。現場の意見を反映する機会を設けることで、一方的に決められた標準という印象を和らげられます。

内製で進める場合に必要な体制

標準化を内製で進めるには、全社のシステム構成を把握するアーキテクト人材、各部門との調整を担うプロジェクトマネージャー、そして基盤構築を担うエンジニアという複数の役割が必要になります。これらを情報システム部門の少人数だけで兼務すると、通常業務と並行しての推進が難しくなりやすいのが実情です。

外部パートナー活用の判断軸

複数拠点の現状把握や、全社共通基盤の設計・構築を内製だけで担うのが難しい場合、外部パートナーの活用が選択肢になります。標準化を誤ると、共通基盤への移行後にかえって業務が回らなくなり、後戻りの改修コストが発生するリスクがあるためです。自社に知見を蓄積したい領域は内製で担い、複数企業の標準化を見てきた知見が必要な設計・移行の初期段階は外部に相談するという役割分担が現実的な進め方の一つになります。

まとめ：システム標準化・共通化を進める3つの判断軸

本稿では、部門・拠点でシステムが乱立する課題に対し、標準化・共通化を経営視点で進める方法を整理しました。要点を3つに集約すると次の通りです。第一に、乱立を放置すると連携改修のコストと経営判断の遅れという形で負荷が積み上がることです。第二に、標準化の対象は基盤・データ連携・調達・開発ルールに切り分け、共通化する範囲と部門裁量を残す範囲を線引きして進める必要があります。第三に、現状把握から定着までの段階を踏み、現場の抵抗を前提に説明と巻き込みを行いながら、必要に応じて外部知見を活用することが実効性を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～（サマリー）」https://www.meti.go.jp/policy/it_policy/dx/DX_report_summary.pdf（2018年）
2. *2　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html（2025年）

Tweet