全部入りの基幹システムの次へ。「本体は標準、違いは外で作る」刷新の決め方

かつて「すべてを1つのシステムにまとめる」ことは、基幹システムの理想でした。 いま、その全部入りの基幹システムが、クラウドのサービスやAIとつながるときの足かせになっています。 何を標準のまま使い、何を自社で作るのか。基幹システムを刷新するときの決め方を、事例とあわせて整理します。

なぜ今、「全部入り」の基幹システムが足かせになるのか

基幹システムを1つにまとめる考え方は、もともと理にかなったものでした。 部門ごとにバラバラだったマスターをそろえ、経営がデータを横断して見られるようにする。そのための道具です。

ところが、長年の改修で巨大になり、古くなった結果、バージョンアップも作り替えも難しく、費用もかさむようになりました。 新しいクラウドのサービスを足したい、AIにデータを使わせたいと思っても、全部入りのシステムがそれを阻みます。 問題は「まとめたこと」ではなく、古くて大きくなりすぎたことです。

とはいえ、基幹システムが要らなくなったわけではありません。 販売・調達・会計・固定資産のように、ある程度の業務のまとまりで区切り、それぞれをつないでいく。 ただし細かく分けすぎると、発注と検収が別のシステムになって進捗を追えなくなるように、かえって扱いにくくなります。 区切りながら、まとめるのが現実的な答えです。

「標準に業務を合わせる」が掛け声倒れになる理由

パッケージの標準機能に業務を合わせる「Fit to Standard」は、正しい考え方です。 ただ、昔から言われてきたわりに、実現できている会社は多くありません。

• 海外発の「標準」が、日本の商習慣・法定の帳票・稟議の流れに合わない
• 法改正（会計基準の変更や請求書の制度など）への対応が、自社の時期に間に合わない
• 無理に合わせた結果、標準の外側でExcelの管理が増える

最後の状態は「標準に合わせ疲れ」とでも言うべきものです。 システムの中は標準どおりでも、業務の実態は周りのExcelで回っている。 ある調査では、一般的な経理担当者は、約15のシステム、100のExcel、80のマニュアルを使って仕事をしているといいます。 基幹システムを入れ替えても、周辺の仕組みは必ず残るという前提で考える必要があります。

発想の転換：本体は小さく、標準のまま保つ

標準に合わせる目的は、業務を我慢させることではありません。 本体を作り込まないことです。 本体を標準のまま軽く保っておけば、クラウドの継続的な更新、制度への対応、新しいAIの機能を、すぐに取り込めます。

反対に、本体に追加開発を重ねると「母屋より離れのほうが大きい家」になります。 改修のたびに追加部分の確認が必要になり、費用は増え、中身を知る人は限られ、誰も触れないブラックボックスになっていきます。

自社に合わない部分は、本体の外で吸収します。 家にたとえるなら、構造体には手を入れず、家具や間仕切りで暮らし方に合わせるイメージです。

何を標準にし、何を作るか：4つの仕分け

本体の外で何を作るかを決めるには、まず業務とシステムを仕分けます。 出発点は技術ではなく、その業務を伸ばすのか、安定して維持するのかという事業の方針です。

• 標準に合わせる（非競争領域）：給与・会計・購買のように、競争力に直結しない業務。パッケージやクラウドのサービスに業務を合わせる
• 作り込む（競争領域）：顧客の体験や、商品・サービスの強みに直結する業務。人と投資を集中させる
• 凍結する：重要だが変える必要の小さい仕組み。費用を抑えて維持し、将来の置き換えを検討する
• 捨てる：使われていない機能や帳票。移行の前にやめて、全体を軽くする

ある証券会社は、バックオフィスのシステムを一度に作り直すのではなく、この仕分けで進めました。 競争力の中核は作り直し、重要だが優先度の下がる部分はAIによるプログラムの変換で移し、残りは凍結か廃止にしています。 検討開始から約4年で稼働にこぎつけました。

違いの作り方：専門サービス・周辺開発・連携の役割分担

本体の外で違いを作る手段は、主に3つです。

• 専門のクラウドサービス：経費精算・請求書・固定資産など、その分野に特化したサービスを組み合わせる。導入は速く運用も軽いが、自社だけの要望には応えにくい
• 周辺の開発：自社独自の入力画面・チェック・承認の流れを、本体の外に作る。プログラムを書かずに作れるローコードの道具を使うと、属人化しにくく保守もしやすい
• 連携の層：本体と周辺をつなぐ部分を1か所に集め、形式や文字コードの変換、処理の順番の制御をまとめて受け持つ

ある製薬会社では、基幹システムを入れたあと、入力画面と経費精算の承認の流れが自社の業務に合いませんでした。 本体を改修するかわりに、入力を助けてチェックする画面と承認の流れを外側に作り、基幹システムに渡す前にデータの精度を上げています。 夜間の連携で自動的に本体へ反映し、その後は取引先へのデータ配信などにも広げました。

ここで注意したいのは、周辺の仕組みごとに個別に連携を作り込まないことです。 周辺が増えるたびに線が増え、結局は全部入りのシステムと同じ複雑さに戻ってしまいます。 連携の層は、変化を吸収するための層として設計します。

事例：ある銀行の会計システム刷新

ある銀行は、数年かけて社内のシステムを段階的に見直してきました。 まず情報システム部門が主導して個別の改善を進め、次に認証・承認の流れ・会計システムへと広げ、最後に投資の回収とAIの活用に進むという3段階です。

刷新の前は、部門ごとの個別システムやExcelのマクロ、RPAを積み重ねて、会計の仕訳を作っていました。 業務が増えるほど負荷が増える構造で、担当者にしか分からない部分も多くありました。 個別のシステムを延命する案もありましたが、構造が残るため、全体を作り替えることを選んでいます。

• 方針：クラウドの会計システムは改修が難しいため、「標準に合わせる」を全社の第一方針にした
• 構成：経費精算や請求書などは専門のサービスを組み合わせ、中間に連携の層を置いた
• 効果：会計システムとの連携は19本。開発の工数は、すべて自前で作る場合に比べて約3割減った
• 想定外：複数の開発会社が関わる結合テストで、連携の仕様の認識違いによる不具合が多発した。連携の層で吸収できたため、短期間で立て直せた

連携の仕組みを選ぶときは、機能の差は小さく、決め手は自社で運用できるか、費用、支援体制だったといいます。 今後は、この連携の層をデータの分析やAIの活用の中心にも広げていく計画です。

刷新を前に進める組織づくり

古いシステムは、古い機械のように入れ替えれば済むものではありません。 継ぎ足しの開発、ITを維持費としか見ない経営、業務部門と情報システム部門の分断、開発会社への丸投げ、詳しい人が保守に張り付いて動けないこと。 こうした構造が絡み合って生まれたものです。 技術を置き換えるだけでは、同じことがまた起こります。

• リスクを数字にする：維持費の差、障害が起きたときの影響、詳しい人が辞めたときの影響、逃している事業の機会を、経営から現場まで同じ数字で共有する
• 反対する人を味方にする：利用者から見た操作をできるだけ変えないなど、現場の負担を下げる工夫で協力を得る
• プロジェクトを魅力的にする：地味な刷新でも、新しい技術を使い、有志を募り、若手が自慢したくなる取り組みとして打ち出す
• データの活用を刷新の完了まで待たない：刷新とデータの整備を別の予定で進め、データの所在と意味を先に明らかにしておく
• 時間を見込む：企画・計画・合意づくりには時間がかかる。他社の事例はそのまま真似せず、自社の事情で考え抜く

「何もしない」という選択も、経営がリスクを理解したうえで決めるのであれば、ありえます。 ただし、それを何十年も続けられる会社はほとんどありません。

まとめ：基幹システムの刷新を考える前の確認リスト

• 対象の業務を、伸ばすのか安定して維持するのか、事業の方針として決めているか
• 業務とシステムを、標準に合わせる・作り込む・凍結する・捨てるの4つに仕分けているか
• 本体は標準のまま保ち、追加開発を最小限にする方針を立てているか
• 自社に合わない部分を、専門サービスと周辺の開発で吸収する設計にしているか
• 連携を1か所の層に集め、周辺ごとの個別連携を作らないようにしているか
• 維持費・障害の影響・人材のリスクを数字にして、経営と共有しているか
• データの活用を、刷新の完了まで待たずに進める計画があるか

基幹システムで本当に怖いのは、古いことそのものではなく、変えたいときにすぐ変えられないことです。 本体は標準のまま軽く保ち、違いは外で作り、つなぎ目で変化を吸収する。 私たちは、何を標準にし、何を作るかの仕分けから、周辺の開発と連携の設計まで、現場と一緒に進めるお手伝いをしています。