システムの「スパゲッティー化」とは？SAPで対応すべき日本型システムの課題

はじめに

日本企業のシステムに関する課題としてよくあるのが「サイロ化」です。

サイロ化は業務俗人化や情報連携の障害になるなど、さまざまな弊害の温床とされています。

しかし、実際にはサイロ化よりも「スパゲッティー化」が問題とされる見方もあります。

DXへ向けてSAP S/4 HANAに移行するケースでも、スパゲッティー化が問題とされることが多いようです。

今回は、システムのスパゲッティー化を通して、日本型システムの課題を整理していきます。

 

 

 

1.システムの「サイロ化」と「スパゲッティー化」とは

まず、サイロ化とスパゲッティー化についておさらいしておきましょう。

 

システムのサイロ化とスパゲティ化は、日本企業における情報システムの設計と運用で「壁」になりやすい事象です。

いずれも組織の効率性、柔軟性、そしてイノベーションの能力に深刻な影響を及ぼす可能性があります。

 

 

1-1.システムのサイロ化とは

システムのサイロ化とは、組織内の異なる部門やチームが情報やリソースを共有しない状態を指します。

つまり、部門・部署ごとにシステムが独立しており、さらに独立したシステムが長年にわたって改修・機能追加された結果、横の連携が全く取れなくなった状態です。

 

この現象は、組織が成長とともに自然発生的に生じることが多く、部門間でのコミュニケーションの欠如や協力の不足が原因で発生します。

日本では、企業の垂直統合が強く、部門間の壁が高いため、サイロ化は特に深刻な問題となりがちです。

 

サイロ化の結果として、データの重複や非効率なリソースの利用、意思決定の遅延などが生じ、組織全体のアジリティ（機敏性）が低下します。

特に日本の伝統的な企業文化では、部門間の競争が協力よりも優先される場合があり、これがサイロ化をさらに強化しています。

 

 

1-2.システムのスパゲッティー化とは

これに対してスパゲティ化は、情報システムが複雑で非構造的に絡み合った状態を指します。

単にシステムの数が増えたり、機能が増えたりして整理が難しくなっている状態ではなく、それぞれが「密結合」な状態に陥っているわけです。

 

密結合とは、端的に言えば「システム同士が境界線のあいまいな状態で密接しており、処理についても相互依存の関係にある様子」を指します。

 

密結合は「処理が高速になる」「複雑な業務プロセスを一枚岩のように構成し、堅牢性を高める」といったメリットがあります。

その反面、小さな変更や改修が広い範囲に影響を及ぼし、さらにその範囲が特定しづらいというリスクも孕んでいるわけです。

 

スパゲッティー化が起こると、システムの一部を変更することが困難で、新たな技術の導入や既存システムの更新が極めて難しくなります。

日本の企業では、長年にわたり蓄積されたレガシーシステムが多く、これがスパゲティ化の一因となっています。

 

 

1-3.ハイリスクなのは「スパゲッティー化」

SAPに限らずエンタープライズITの分野では「サイロ化」が問題にされがちです。

確かにサイロ化は情報連携やそれに伴う新たな知見の獲得、部門を横断したビジネスプロセスの合理化などを阻む大きな障壁になるでしょう。

しかし、見方を変えれば「成熟したシステム同士をつなぐだけ」で解決してしまうことも多々あります。

 

部門・部署ごとに独立性が高まっているということは、裏を返せば「特定の業務領域においては自己完結できる」ということに他なりません。

他の業務領域とは連携できなくとも、そのシステムだけに限定すれば、改修や機能追加はやりやすいわけです。

 

一方、スパゲッティー化にはこの独立性がほとんど残されていないことが多いです。

名称としてはシステムA、システムBと独立していても、蓋を開けるとそれぞれが相互に依存しあっていて、実質的にひとつのシステムと化していることがあります。

 

こうなると、ある機能をシステムAに追加しようとしたとき、システムB、システムCにも影響が及ぶことは必須であり、業務遅滞は避けられなくなるでしょう。

 

さらに新システムへ移行する場合でも、上流工程に要する工数が膨大になり、プロジェクトが肥大化しがちというデメリットがあります。

スパゲッティー化したシステムの多くは、「つぎはぎ方式」で機能を重ねられており、機能を構成する要素同士が複雑に絡み合っているからです。

SAP ERPでも、ある汎用モジュールがさまざまなアドオンでコールされていて、軽微な改修を行うだけでも膨大なテスト工数がかかることがあります。

この状態をさらに深刻化したものが、スパゲッティー化の弊害と言えるわけです。

 

 

 

2.スパゲッティー化が解決できない理由

ここまでハイリスクなスパゲッティー化ですが、なぜ解決できないのでしょうか。

その理由として以下2つがあると考えています。

 

 

2-1.システム化する業務が多すぎる

しかし日本企業は例外処理も含めてきめ細やかにシステムへ落とし込んでいくため、密結合状態に陥りやすいのです。

例えば欧米企業の場合、システム化では例外的な処理を対象外とすることが多く、利用頻度が多いもののみをシステムへ置き換えていきます。（あくまでも傾向です）

 

「めったに発生しない業務や、重要度の低い業務は全て切り落とす」という考えが根付いています。

そのため、システムに業務を合わせることが日本よりも容易なのです。

 

 

2-2.「設計段階からシステムを知るもの」が誰もいない

日本企業は顧客の要望にしっかり応えるために、さまざまな業務要件を盛り込もうとします。

その結果、あらゆる業務に対応できる万能型のシステムを作ろうとするわけです。

しかし、万能型のシステムを作るには高度な設計力が必要ですよね。

設計・開発した人員が永遠に在籍できればよいのですが、得てしてこうしたシステムは外注によって作られており、設計段階からシステムの全容を把握している人間が社内に存在しないこともあるのです。

 

一方、使う側は普段目にしている機能が使いやすいか、業務にフィットしているかのみを基準として改修要望を挙げてきます。

こうした要望を何とか汲み上げ、システムに反映していくものの、上記の理由からどうしても影響調査がなおざりになり、場当たり的な改修が続きます。

その結果、大がかりなシステム改修やパッケージへの移行といったイベントが起こると、再設計に時間がかかり、業務自体が麻痺してしまうのです。

 

 

 

3.顧客に「痛み」をどう理解してもらうか

スパゲッティー化したシステムを拡張性の高い新システムに置き換えるには、

・「システムを徹底的に解きほぐすこと」

・「解きほぐした要素を再度組み上げ、新しいシステムに適合させること」

の2つが必要です。

 

しかし、この2つには多大な痛みが伴います。

SAP ERP業界でも「業務の停止は絶対に避けたい」「今までと同じ使い勝手であることは必須」といった要件を突き付けられることが多いでしょう。

これらは厳しい要求のようにも感じますが、実際には顧客の「痛みに対する恐れ」なのです。

実際にスパゲッティー化したシステムを新環境として再構築する場合には、痛みは回避できません。

必ず何らかのリスクが顕在化します。

しかし、このリスクを飲み込んでもらうことが新しいシステムへの第一歩であり、ERPコンサルタントとしての腕の見せ所と言えるでしょう。

 

とはいえ、単に「我慢しましょう」とは言えませんよね。

なので、魅力的な未来図を見せることで痛みへ向かう決心を固めてもらう必要があります。

 

例えば、

 

・SOA（サービス思考アーキテクチャ）のメリットを徹底的に整理してプレゼンする

・マイクロサービスをはじめとした疎結合なシステムのメリットを提示する

・選択データ移行などを活用した「中間システム」によってリスクを緩和する

 

といった方法論を説明することで、顧客が理解を示してくれるかもしれません。

こうした方法論は、実際に採用されることはないにしても「ここまで方法があるのなら、何とかなるかもしれない」という判断を後押しする材料になります。

 

したがって、ERPコンサルタントはできる限り多様な方法論に精通している必要があるのです。

 

 

 

まとめ

今回はサイロ化よりもハイリスクな「スパゲッティー化」について解説しながら、ERPコンサルタントの採るべき道を紹介してみました。

スパゲッティー化したシステムはERPコンサルタントの強敵であり、攻略しがいのあるテーマでもあります。

一度でもスパゲッティー化を新システムへ移行した経験があれば、コンサルタントとして大きく成長できるはずです。

SAP S/4 HANAへの移行も含め、さまざまな方法論を提示できるように自己研鑽を重ねていきたいですね。