システム統合になぜ業務分析が必要なのか？――作業の理由とITガバナンス：戦う現場に贈る分散システム構築−情報部門編（3）（2/2 ページ）

[岩崎浩文，豆蔵 BS事業部]

分散システム構築時における業務分析のもう1つの理由

　さて、前ページの内容は、分散システム構築においてのみ実施されるわけではなく、普通の業務システム開発でもある意味当然に行われるものである。それで本連載の趣旨に沿う、もう1つの深い存在理由の説明を外すわけにはいかない。

　分散システム構築、特に「SOA」について身もふたもない言い方をすれば、既存システムの統合によるコスト削減という狙いが強固に存在する。全社規模で大規模な統合を行いコストを削減しよう、あわよくば重複する機能やシステムは廃止しよう??というのがSOA型アプローチの代表的な目標である。

　このコスト削減を意識したシステム統合を実現するに当たっては、やはり明確な方法を使って、業務からのトップダウンで設計を進めなければならない。もともと、SOAという概念はEA（Enterprise Architecture）から導出されてきたという経緯もあり、この「トップダウン型」というキーワードが外せない。

図2　Enterprise Architecture

　EAのアプローチは、政策・業務体系（Business Architecture＝ビジネスアーキテクチャ）が業務システムを統治するモデルを採用しており、コストダウンやその延長にあるシステム統合は、業務ニーズからブレークダウンされ、つながったものとして構築される必要がある（そうでないと統治されていることにはならないといえよう）。

　つまり、「なぜ業務分析を行うのか」という問いに対するもう1つの（より深い）答えが「業務ニーズからシステム化要求を導き出すため」ということになる。EAというアプローチが前提としているシステム化範囲は、ある単一のシステムではなく、企業を支えるエンタープライズ・システム全体である点に注意すべきである。これこそ複数のシステムを統合する“分散システム”というとらえ方のポイントとなるのだ。

　ちなみにこのEAは一時期、業務改革の分野で「猫もしゃくしも」の勢いで話題に上った時期があるが、その喧噪（けんそう）も現在は一段落して、現在は落ち着いた適用が大企業を中心に浸透しつつある。このアプローチの延長にSOA型の分散システムという具体的ソリューションが存在するわけで、それゆえに分散システム構築と業務分析は切っても切り離せない関係にあるのだと考えると理解が早いのではないだろうか。また、前回に少し触れたトレーサビリティはここに相当する部分と考えればよいだろう。つまり、業務?システム‐実装がつながりを持つ構造体として構想されるというわけだ。

---

　次回以降、どの成果物（図）が分散システム設計にどう具体的に結び付くのか??という点については、さらに一歩踏み込んで解説していきたい。業務分析を乗り越えて次に進もうとする豆成くんに、新たな問題が襲い掛かる予定だ。

筆者プロフィール

岩崎 浩文（いわさき ひろふみ）

株式会社豆蔵 BS事業部。ITコンサルティング会社にて商用フレームワーク設計・構築およびITアーキテクトとして多数の企業システム設計・構築に携わる。その後、サーバ製品ベンダにてSOAコンサルタントを担当したのち、2005年より現職。現在、方法論「enThology」（エンソロジー）の策定とSOA型システム設計支援の主任担当として多くの現場へ支援を行っている。

株式会社豆蔵

「戦う現場に贈る分散システム構築」バックナンバー

• 既存システムという制約とアーキテクチャ――どうつなぎ、うまく再利用するか
• システムアーキテクチャとSOA製品選定――分散するシステムをつなぐ製品について
• 悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために
• これから始めるサービス指向型設計――単独システムとは違う世界へようこそ
• その分散システムは、正しく作られているか？――開発後の検証・受け入れを考えよう
• ここが核心！ 各サービスの抽出とサービス統合――SOAサービスの切り出し方とその統合方法
• 理想像と現実のフィット＆ギャップを知る――業務分析の成果をシステム統合に活かす
• システム統合になぜ業務分析が必要なのか？――作業の理由とITガバナンス
• システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について
• 緊急課題！ 点在する複数のシステムを統合連携せよ――問題山積！ 乱立する情報システムの解法とは？