ここが核心！ 各サービスの抽出とサービス統合――SOAサービスの切り出し方とその統合方法：戦う現場に贈る分散システム構築−情報部門編（5）（2/2 ページ）

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

分析結果と既存システムとの溝を埋める技

　さて、前ページで蔵田が採り上げた概念モデル図は、業務分析を行った結果としての、業務フロー図などと並んで代表的な成果物の1つである。この図はいわゆる理想像としての既存（as-is）としての図である。これを基に将来像（to-be）を起こしていくのが定石となっている。

　この業務から導き出した理想像としての既存図を横目に見つつ、実際の既存システムをその成果物に当てはめて対比させた場合、必ずそこに乖離（かいり＝ギャップ）が発生している。例えば、業務的には3つのテーブル構造で足りるはずの情報構造部分が、実際には4つのシステムで十数個のテーブルから構成されている、などだ。

　業務分析から各既存システムを連携するための方式設計、つまり各サービスの抽出につながる道は、ここに隠されているのだ。

　冒頭で豆成くんが困り果てていたように、各サービスの割り出し方法は複数のパターンが想定され、業界内でもこれといった定式化された方法はない。そのためこれが正解というものもなく、設計までの道筋は1本ではない。

　ここでは一例として、筆者が方法論として策定し、実際に設計を行うときに実践している方法を、概念モデルを例にして紹介しよう。

「架空の単一システム」すなわち「分散システム」

　まず業務分析の結果として挙がってきた概念モデル図であるが、これは企業全体として必要となる情報の関連とその項目がある程度網羅されているもの、と見ることができる。これは一種の「架空の単一システム」であり、筆者らはこれを基づいて連携するシステムを「分散システム」（本連載のタイトルでもある）と呼んでいる。

　これと社内に点在するシステムの取り扱う情報、具体的にいえばそのシステム内部の情報構造――もっとダイレクトにいえば、そのシステムのE-R図とを照らし合わせてギャップを見出す作業を行う。

　各既存システムのE-R構造は、分析結果である「架空の単一システム」の一部分を構成する要素として候補に挙がる。A領域はXシステム、B領域はYシステム、という具合に、である。

図2　概念モデルと既存E-Rとのマッピング

　後はその「架空の単一システム」とどうやってつなげるのか、そのギャップをどう吸収するのか、という課題に絞られてくる。当然、「架空の単一システム」と「既存E-R構造」がそっくりそのまま、1対1に対応することは考えられない。必ず差がある。

　これを基に、その差を埋めるための全体を通してのポリシーの策定、および各情報の塊（entity）を実際のシステムに割り当てる作業、この結果と業務フロー情報を基本としたサービスの割り出し、そのためのシステム間連携のための具体的な方式設計、という風に順次タスクに落としていく作業となる。

　このような分析結果から演繹的に設計を導出する手法により、課題であったトレーサビリティを担保し、目的に叶ったシステム設計が実施できる事につながるわけである。

　もちろん、上記の内容だけでは、サービスを抽出するための根拠としてまだまだ不十分である。これらに業務フロー図や業務機能構造図をさらに重ねて利用し、抽出の精度を向上させる方策を採るべきである。

方法論を構築せよ

　さて、豆成くんはサービスの抽出方法について、散々悩んだ挙句に何とか正解を導き出しつつある。もしここで豆成くんのように、幸運にしてうまいやり方を思い付き、ある程度の成果を出すことができたのであれば、例えば社内標準のような形態で、そのやり方は整備し、標準化すべきだろう。誰もが同じような個所で悩んで独自のやり方を試行錯誤し、プロジェクトのたびにそれを繰り返すというのはあまりにも非効率に過ぎる。

　ただ本連載の主題のとおり、分散システムというのはこれまであまり多く語られることのなかった領域であるため、決定的に議論や実績が不足している。ここでうまくさまざまな方法を蓄積して方法論を構築し、具体的な活動や実績に結び付けることができた組織こそが、今後複雑化するITシステムを上手に制御していけるのではないだろうか？

　さて、次回は情報部門編の最終回。今後の方策が見えてきた豆成くんの、次なる課題を見ていく。

筆者プロフィール

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

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

株式会社豆蔵

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

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