鴻池運輸のクラウド移行に学ぶ──サイロ化を断ち切る設計思想と“全体最適”を実現するフルスクラッチ開発の考え方

多くの企業がDX推進に乗り出す中で、業務システムの“サイロ化”が深刻な課題となっています。部門ごとに異なるシステムを導入した結果、データが連携せず、全体最適から遠ざかってしまう。鴻池運輸もかつてはこの問題を抱えていましたが、クラウド移行を機にIT基盤を統合し、組織横断の仕組みづくりを進めました。

本コラムでは、サイロ化の何が問題なのか、なぜフルスクラッチ開発が有効なのか、そして“全体最適”を実現するための設計思想を解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】鴻池運輸、4年で業務システムの9割をAWSへ移行──「虎の穴」で人材育成とゼロトラスト基盤を整備

鴻池運輸は2018年から4年間で業務システムの約9割をAWSに移行し、クラウドファーストを実現した。サイロ化したIT基盤やベンダー依存を解消するため、クラウドリフト方式で段階的に移行。並行してゼロトラスト型のセキュリティーを導入し、ZscalerやOktaなどを活用してリモート環境でも安全に業務ができる仕組みを整備した。さらに、ITベンダーNSDと共同設立した「コウノイケITソリューションズ」で社員を実務教育し、専門人材を育成。経営層の理解を得ながら、コスト削減よりもガバナンス強化とIT人材育成を重視し、内製開発への基盤を築いた。

出典：日経クロステック／日経コンピュータ「鴻池運輸が業務システムの9割をクラウド移行、4年をかけた成果」2023年5月24日公開

サイロ化がもたらす「見えない非効率」

企業の情報システムは、事業や組織の成長とともに複雑化します。
営業、経理、物流、製造、人事──各部門がそれぞれの目的でシステムを導入していくうちに、気づけば“島”が点在するような状態に。これが「サイロ化」です。

サイロ化が進むと、次のような課題が発生します。

• データが部門ごとに閉じ、全社的な分析ができない
• 部門間で同じ情報を二重入力しており、手間とミスが増える
• システムの仕様がバラバラで、メンテナンスコストが高騰する
• どのデータが正なのかが分からず、経営判断が遅れる

一見するとそれぞれのシステムは正常に動いていますが、全体で見ると“非効率の集合体”になっているのです。この構造を断ち切らない限り、DXは部分最適のまま止まってしまいます。

サイロ化の根本原因は「構築の都度発想」

サイロ化は偶然に起こるものではありません。
多くの場合、その背景には「都度構築」という発想があります。

新しい部門が生まれるたびに、課題に応じてシステム開発会社へ個別に依頼し、独立したシステムを立ち上げる。短期的には効率的に見えますが、長期的には管理が複雑化し、統一的な設計思想が欠落します。結果として、似たような機能を持つシステムが複数存在し、データの整合性も失われていきます。

鴻池運輸でも、会計・情報系・ファイルサーバーなどがそれぞれ異なるデータセンターで運用され、閉域網やツールがバラバラという状況に陥っていました。このような状態を解消するには、“その場しのぎの構築”ではなく、“全体構造からの再設計”が必要です。

全体最適のカギは「共通基盤」と「データモデル」

全社的な最適化を実現するには、システムを統合する「共通基盤」の設計が不可欠です。それは単なるサーバーやクラウド環境の共有ではなく、データの扱い方を統一することを意味します。

たとえば、顧客情報を扱う際に、営業部では「得意先コード」、経理部では「取引先ID」、物流部では「出荷先番号」といった異なる形式を使っていれば、同じ顧客を同一データとして扱うことはできません。共通基盤の構築とは、こうした定義の差を整理し、部門をまたいでも通用する“共通言語”をシステムに実装することなのです。

フルスクラッチ開発は、この“共通言語化”を最も柔軟に実現できる手法です。既存パッケージでは対応できない業務間のつながりを設計段階から取り込み、将来的な拡張にも対応できます。

“全体最適”を支えるフルスクラッチ開発の設計思想

全体最適を目指す設計において重要なのは、「機能単位」ではなく「データ単位」でシステムを考えることです。つまり、「何を管理するか」よりも「その情報がどこから生まれ、どこへ流れるか」を設計する視点です。

フルスクラッチ開発では、要件定義の段階で業務のつながりを可視化し、データの流れを部門横断で整理します。この工程こそが、属人化を防ぎ、全体の整合性を保つ鍵になります。

また、フルスクラッチ開発はAPI連携やモジュール化に柔軟に対応できるため、「全体の統一性」と「個別の拡張性」を両立できます。新しい業務やサービスが追加されても、既存の仕組みに大きな影響を与えずに組み込むことが可能です。

属人化を防ぐ“透明な構造”のつくり方

サイロ化と並んで課題となるのが、特定の担当者に依存した属人化です。業務フローやデータ構造が担当者の頭の中にしか存在しない状態では、組織としての再現性が失われます。

これを防ぐには、設計段階から「透明性」を意識した構造をつくる必要があります。
具体的には、以下のような取り組みが有効です。

• データフローをドキュメント化し、更新履歴を残す
• コードや設定を可視化できるリポジトリ管理を導入する
• 業務ルールをシステム仕様に反映し、暗黙知を形式知化する

これにより、開発者が変わっても運用が止まらない仕組みが実現します。属人化の解消は、システムの安定稼働だけでなく、継続的な改善サイクルの確立にもつながります。

将来を見据えた「拡張性設計」という発想

全体最適のもう一つのポイントは、「未来の変化を前提に設計すること」です。市場環境や業務プロセスは常に変化します。そのたびにシステムを作り直していては、時間もコストも浪費してしまいます。

フルスクラッチ開発では、初期段階から拡張性を見越した構造を設計できます。例えば、モジュール単位で独立性を持たせることで、必要な部分だけを改修・追加できるようにする。データベース設計を汎用的にして、将来的な連携先の追加にも対応できるようにしておく。

こうした「柔軟に変化できる仕組み」を持つことこそが、長期的な全体最適を実現する鍵です。

システム開発会社との協働で“全社視点”を持つ

サイロ化を解消するためには、単一部門ではなく「全社最適」の視点を持つことが欠かせません。しかし、社内だけで全体設計を完結させるのは難しいのが現実です。ここで重要になるのが、フルスクラッチ開発に精通したシステム開発会社との協働です。

外部の視点を取り入れることで、業務の前提や既存システムの構造的な問題を客観的に洗い出すことができます。社内では当たり前だと思っていた業務フローも、外部から見れば非効率の温床である場合もあります。この“第三者の眼”を活かすことで、より精度の高い全体最適設計が可能になります。

鴻池運輸の事例に見る「全体最適への移行プロセス」

鴻池運輸は、クラウド移行を進める中でサイロ化を抜本的に見直しました。オンプレミス環境で分断されていた会計・情報系・ファイルサーバーを統合し、AWS上で共通基盤を構築しました。セキュリティ対策をゼロトラストモデルに統一するなど、ITインフラ全体を再設計しました。

このプロセスでは、単なる技術移行ではなく、組織の情報構造を再定義する取り組みが行われています。つまり、クラウド化は目的ではなく、「全体最適を実現するための手段」だったのです。こうした“構造から変える設計思想”こそが、サイロ化を断ち切る本質といえます。

まとめ

サイロ化を断ち切るには、技術やツールの導入ではなく、まず「全体を見通す設計思想」が必要です。フルスクラッチ開発は、その思想を具体的な形に落とし込むための最適な手段です。共通基盤とデータモデルを整備し、属人化を防ぎ、将来の変化に対応できる柔軟な構造を持つこと。その積み重ねが、組織全体の効率性と意思決定の質を大きく変えていきます。

DXの本質は“部分の最適化”ではなく、“全体がつながる仕組み”の再構築にあります。サイロ化を超える設計思想を持つことが、企業システムに求められる条件なのです。

サイロ化を断ち切り、全体最適を実現するには、単にシステムを統合するだけでなく、業務構造そのものを理解した上で再設計できる開発パートナーが欠かせません。

フレシット株式会社は、部門間のデータ連携や共通基盤設計など、業務横断の課題整理から伴走するフルスクラッチ（オーダーメイド）開発を強みとしています。既存システムの制約を超え、将来の拡張まで見据えた最適な設計をゼロから描く。複雑な業務構造を“つなげる”仕組みを求める企業さまに、最もフィットする開発パートナーです。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら