現在、企業が抱えるITシステムは、サービスの多様化、技術革新、セキュリティ対応等の社会的な要求の増加に伴い、年々複雑化する傾向にある。今回は、ITシステムを構成する一つの概念である「サブシステム」の功罪をテーマとした。
システムは複雑化していく
サブシステムの意味を改めて調べてみると、“大きなシステムの一部を構成する、より小さな単位のシステムのこと”、といった定義が一般的なようだ。
筆者は複数の次世代基幹システムの一斉更改プロジェクトを経験しているが、巨額な資金を投入してシステムを再構築するプロジェクトはまれで、一般的に、そう頻繁に行われるものではない。基幹系のEOS (End Of Service) 到来を契機に、周辺システムまで網羅的に見直すことも検討のテーマに掲げられるものの、時間も人も足りずそこまでやり切れないのが普通だ。結局のところ、事業や業務が変化するスピードに追従する要求に対して、過去（極端な場合10年以上前）の設計思想をベースに構成された資源の上に局所的に上乗せした「後付けのサブシステム」で補うことで凌ぎ、ITシステムが構造的に追従できずに複雑化するサイクルを繰り返すことになるのだ。
「後付けのサブシステム」は悩みの種
この「後付けのサブシステム」が積み重なった状態が厄介だ。その時は凌いでも、全体で見ると、サブシステムの数が増えることで複雑化の度合いが乗数的に増加し、実は贅肉が多くなっていることに気づかない。その贅肉は、最後はコストに現れる。たとえば、単なる1部門内のパッケージ・システムだったものが、評判が良かったために大幅にカスタマイズを施して全社システムに格上げされた場合、そのサブシステムはカスタマイズ要求が多いため、高額な保守費が常態化することが多い。後からそのサブシステムを止めたくても、社内の反対勢力に押されてうまくいかないケースもあった。
このようなシステムを含むサブシステム群を一覧化し、総ランニングコストを積み上げ、10年で数百億という試算結果に遭遇したこともあった。こうした実態が感覚的に分かっているものの、どこから手を着ければよいのかわからず、大きな悩みとなっている経営者は実は多いと想像できる。
後付けサブシステムの特徴を整理すると、次表のようになる。
これらの特徴から、サブシステムの導入自体は悪いことではないが、よくよく紐解くと、その周辺に無駄を生み、莫大なコストに化けている可能性がある、といえる。
身軽にすることが第一歩
では、どのような手を打つべきか。
結論から述べると、現行のサブシステムが生むサービスの価値を明確に定義し、適切な投資判断が実行できる状態を作ることが理想だ。まず、現行のサブシステムの実態を明らかにし、現行システムを身軽にすることから始めると良い。
そのステップを一部ご紹介したい。
- ①全システムを棚下ろす
- ②第三者が客観的に判断できるIT重要度／投資判断指標を定義する
- ③現行で不要なシステムを排除する
- ④新規で不急なシステム（および機能）の導入を牽制する
この中で最もパワーを使うステップは、実は①の全システムの棚卸しである。システムに紐づく情報を集約し、「システム一覧」を整理する活動だが、作業は難儀を極めることが多い。その理由は、契約書、稟議書、運用・コスト管理文書などに記載されているシステム名称、調達先ベンダ、組織名称など、いわゆる社内の基本情報がバラバラに管理されているからだ。これを整理するには業務知識に基づく個別精査が必要である。DBや基盤周辺の知識も必要であるため、単なる一次的な棚卸しで終わらせず、今後の統制されたIT管理を目指し、全社で協力して遂行すべきプロセスである。①の結果をベースにすることで、初めて②の投資判断指標が明確に定義できる。サブシステムを横並びで比較することで、『このサブシステムへの投資は事務作業の効率化なので、コスト競争力＝ゼロと割り切り、一切投資は認めない』、という判断ができるようになるだろう。
黙っていても、現行のシステムは老朽化し、いつかEOS (End Of Service) が到来する。ここで意識すべきは、再構築を決めてから現行システム精査に着手していては遅いということだ。膨大な時間・コスト・体力がまとめて必要になり、時間切れ、予算切れ、体力切れのリスクが高い。ピンと来た方は、早めに実行に移されることをお勧めする。