分散した業務システムを整理する方法
多くの企業では、部門ごとに異なるシステムやツールが独自に導入され、時間の経過とともに全体像が把握しにくくなっていく傾向があります。営業部門は営業支援ツールを、経理部門は会計システムを、製造部門は生産管理システムを、それぞれの必要性に応じて選定してきた結果、社内には似たような機能を持つシステムが複数存在し、データも各所に分散していることが少なくありません。こうした状態は、決して特定の担当者の判断ミスによって生まれるものではなく、事業の拡大や組織変更、担当者の交代といった自然な経緯の積み重ねによって形成されていきます。
フラグメンテーションが起きる典型的な要因
システムが分散していく背景には、いくつかの共通したパターンが見られます。ひとつは、部門ごとの意思決定が優先され、全社的な標準化が後回しにされてきたケースです。もうひとつは、M&Aや組織再編によって、異なる企業文化・異なるシステム基盤が一つの組織の中に混在するようになったケースです。さらに、短期的な課題解決のために個別のツールを次々と導入した結果、気づけば管理しきれないほどの数になっていた、という状況も珍しくありません。
まずは現状を可視化するインベントリから
分散した状態を整理する第一歩は、いきなり統合作業に着手することではなく、現在使われているシステムやツールを一覧化する「インベントリ」の作成です。どのシステムが、どの部門で、どのような目的で使われているのか。誰が管理者で、どのデータを保持しているのか。こうした情報を丁寧に洗い出すことで、はじめて全体像が見えてきます。この段階を省略して統合を進めてしまうと、後になって想定外の依存関係が見つかり、計画の手戻りが発生することが多くなります。
インベントリ作成の際には、利用頻度が低いシステムや、担当者しか把握していない仕組みが見落とされがちです。そのため、部門ヒアリングだけでなく、実際のログイン履歴やネットワークトラフィックなどの客観的なデータも合わせて確認することが望ましいとされています。
すべてを一度に変えようとしない
現状把握が終わった後も、すべてのシステムを一斉に統合しようとするのは現実的ではありません。業務への影響が大きいものと小さいもの、技術的な難易度が高いものと低いものを整理し、優先順位をつけて段階的に取り組んでいくアプローチが、多くの現場で有効とされています。優先順位づけの詳しい進め方についてはソリューションページのシステム統合の項目でも紹介していますので、あわせてご参照ください。
分散したシステムの整理は、一度きりのプロジェクトというよりも、継続的に取り組んでいく性質のものです。定期的に現状を見直し、新たに増えたツールや使われなくなった仕組みを把握し続けることが、長期的に扱いやすい環境を維持することにつながります。
長期運用を考えたシステム設計とは
システムを新たに構築したり刷新したりする際、多くの検討は「導入時点でどう動くか」に注目しがちです。しかし、実際にシステムが企業で使われる期間は数年から十数年に及ぶことも珍しくなく、導入直後の使いやすさだけでなく、長期的にどれだけ無理なく維持していけるかという視点が、同じくらい重要になります。長期運用を前提とした設計には、いくつかの共通する考え方があります。
保守性を左右するのは構造そのもの
長期的に維持しやすいシステムに共通しているのは、機能同士の結びつきが必要以上に密になっていない、という点です。ひとつの変更が想定外の範囲にまで影響を及ぼしてしまう構造は、初期の開発速度を上げる一方で、後になって変更のたびに慎重な調査と検証を強いられる原因になります。機能をある程度独立した単位に分割し、それぞれの役割と境界を明確にしておくモジュール型のアーキテクチャは、将来の変更や拡張のしやすさに直結します。この考え方は技術に対する考え方のページでも詳しく紹介しています。
ドキュメントは「あとで書く」ものではない
設計や実装の意図が記録として残されていないシステムは、担当者が異動や退職によって入れ替わった際に、途端に扱いにくいものになってしまいます。なぜその構成を選んだのか、どのような制約があったのか、といった背景情報は、システムの見た目や動作からは読み取れません。ドキュメントの整備は開発の後回しにされがちな作業ですが、長期運用を前提とするのであれば、設計の初期段階から並行して進めておくべき項目のひとつです。
将来の変更を前提に計画する
ビジネス環境や利用するサービスは、数年単位で変化していくものです。そのため、システム設計の段階では「今後どのような変更が起こり得るか」をある程度想定しておくことが望ましいとされています。例えば、将来的に別のクラウドサービスへ移行する可能性がある場合、特定のベンダーの仕様に強く依存した設計を避けておくことで、後の移行コストを抑えられます。こうした将来を見据えた設計判断は、サービス内容のページで紹介している運用支援とも関連する部分です。
長期運用を意識したシステム設計は、短期的な効率だけを見れば遠回りに感じられることもあります。しかし、数年単位でシステムを見たときには、保守性・文書化・変更への備えといった要素の積み重ねが、結果的に運用コストの安定や、担当者交代時の混乱の少なさとして表れてきます。
デジタルインフラを見直す際のチェックポイント
クラウドサービスの活用が広がり、社内システムの構成が複雑化していく中で、定期的に自社のデジタルインフラを見直すことの重要性が高まっています。見直しと聞くと大がかりな刷新をイメージされる方も多いのですが、実際には現状を正しく把握し、リスクの所在を確認するところから始まる、比較的地道な作業です。ここでは、インフラを見直す際に確認しておきたい観点をいくつか紹介します。
システムの可視性はどの程度確保されているか
まず確認したいのは、現在稼働しているシステムやサービスについて、どの程度の可視性が確保されているかという点です。どのサーバーやクラウドリソースが、どのような目的で使われているのか。誰が管理権限を持っているのか。こうした基本的な情報が組織内で共有されていない状態では、問題が発生した際の対応が遅れるだけでなく、無駄なコストが発生していることに気づきにくくなります。
監視の仕組みは十分に機能しているか
可視性の確保と並んで重要なのが、監視体制の実効性です。監視ツールを導入していても、実際にはアラートが多すぎて形骸化していたり、重要な指標が見落とされていたりするケースは少なくありません。何を、どのくらいの頻度で、誰が確認するのかを明確にしておくことが、監視の仕組みを実質的に機能させるための前提になります。
依存関係とリスクの所在を把握する
システム同士の依存関係が把握されていない場合、ひとつのシステムに変更を加えた際に、想定していなかった別のシステムへ影響が及ぶことがあります。特に、古くから稼働している基幹システムと、後から追加されたクラウドサービスとの間には、見えにくい依存関係が存在しがちです。こうした依存関係を整理する作業は、デジタルインフラ整備のソリューションでも重視している観点のひとつです。
デジタルインフラの見直しは、一度実施すれば終わりというものではなく、事業の変化やシステムの追加に合わせて継続的に行っていくことが望まれます。可視性、監視、依存関係の把握という基本的な観点を定期的に確認しておくことが、将来的なトラブルの予防と、落ち着いた運用体制の維持につながります。