» 【144号】 サービスとは何か

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【144号】 サービスとは何か

■SOAの目的
SOAプロジェクトにおいて最も重要な課題は、サービスの列挙だと言われま
す。このためにはサービスとは何かが、はっきりしなければなりませんが、人
によって説明が違い、議論がかみ合いにくくなっています。これは「SOA技
術は未完成」の証左と言えるでしょう。

そこでまず目的から考えて見ます。
どうも目的は、「脱SILO」と「AGILE対応」の2つが主なものと言え
るようです。
前者は、「個別アプリは、パッケージ、SaaS、レガシーでともかく間に合っ
ているから、これらを連携運用する、それもP2P(Peer to Peer)でなく
Hub & Spokeの通信場経由行う」と言うものです。この場合、アプリ内のロー
レベルでなく、アプリ間のハイレベルでのメッセージ/サービスが問題になり
ます。
後者は、「変化するユーザ要件に即応できるよう、システムを独立性の高い部
品から構成しよう、その準備としてシステムを機能名でなく、より具体的にサー
ビス−データとしての製品−を列挙して規定しよう」というものと思われます。
この場合は、個別アプリですら時間的に難しかった部品化を、アプリ横断に展
開しないよう注意が必要です。そのため造り屋だけで解決できる部品化のテー
マは、SOAの後のテーマとして分離すべきと、私は考えます。
注)ERPありきで、ERP主体にSOAを考える造り屋のSOAでは、脱SILO
(孤島システム)ではなく、構成モジュールとサービスの対応付けに焦点がある
など、かなり重点が異なって来ますので誤解なきよう、注意が必要です。

■サービスとは
サービスはアプリケーションに対するユーザの情報要求ですが、これを出力す
るためには素材データの入力が必要になります。たとえば生産指図出力に先立っ
て生産計画データの入力が必要になります。そこでアプリケーションを規定す
るためのサービスとして、いわば表方の出力とともに裏方の入力(表方のため
の準備作業)を含めます。
次の表はa発注、b生産、c出荷、d請求に対してこれを適用したものです。
              a       b       c        d
 (1) 実態出力: 原料在庫  製品在庫  受注    検収状況
 (2) 計画判断: 購買計画  生産計画  引当    請求計画
 (3) 指図出力: 発注     生産指図  出荷指図  請求書発行
 (4) 実行観測: 入庫・検収  完成    受入・検収  入金
表の(1)、(3)は表方の出力サービスですが、(4)、(2)はこれに先立つ裏方の入
力サービスになります。
このような業務フローを形成するサービスのほか、単純な参照ニーズに応える
サービスがあります。顧客のアドレスや取引実績を検索するとか、商品の仕様
や価格を参照するなどです。たとえば、ソニーや松下は、部品メーカから部品
仕様を取り寄せて自社のリソースDBを作っていますが、アクセス頻度の高い
もの以外はSOAにより部品メーカのDBに直接アクセスするのが本来のあり
方だと思われます。

■サービスのハイレベルとローレベル
SOAプロジェクトは、一般にSILOの解消を目的に企画され、スコープは
従来の個別アプリプロジェクトの10倍以上の大きさになります。6ヶ月程度
でかなりの範囲について成果の実感を出さなければならないなど、時間・工数
との戦いが鍵になりますので、アプリ間に焦点を絞ったハイレベルサービスの
識別が必要になると考えます。
一般にはアプリ内の工程にかかわるサービス、たとえば、購買計画伺い、承認、
生産工程内作業指図、報告、ピッキング指図、配送指図、などがローレベルに
なりますが、このほか時間差の小さい検収前の受入、引当後の出荷指図なども
ローレベルとすることができると考えます。

■EDHの確定
こうしてアプリ間のサービスを絞り込み、これを素材にデータモデリングを行って、
アプリ間通信場EDH(Enterprise Data Hub)を確定することができれば、
同時に共用性の高いリソースデータ(MDM)が用意でき、また以後の保守の
大部分は、話の通じやすい関係者で迅速に対応できるアプリ内の問題になって、
成功するSOAとなると思われます。確認はまだですが、大括りのアプリ間
EDHの構造はかなり安定しており、業種対応のテンプレートの用意も可能と
考えています。
注)EDHは実装独立の通信場で、実ストレージを持つか否かは実装上の問題
とします。
ただしこの場合、アプリケーションのスコープを如何に設定するかは、問題に
なります。大きすぎたり、小さすぎたり、またグローバル化/M&Aなどによっ
て不統一なスコープが存在する場合、これを如何に調整すべきかは、必ずしも
容易ではありません。これはEDHの設計・標準化の難しさに影響します。

■サービスと部品は別物
まだ多くの人の認める定説とはなっていませんが、私はサービスの集合がアプ
リケーションを規定するものと考えています。それはエンティティごとの属性
値の集合がデータベースを規定するのと同じだと思います。そしてこのとき、
ユーザから見えるサービスと、実装屋の見るシステム構成部品とは別物として
認識すべきと考えます。
アナロジーになりますが、レストランでカレーライスとカツカレーがメニュー
として示されたとき、顧客は2つのサービスを認識します。カツカレーはカツ
とカレーライスから作られるとしても、顧客としてはカツを認識する必要はあ
りません。造り屋の目線になる必要はなく、顧客の目線でレストランを規定す
ればよいと考えるからです。こうして個人差の出やすい粒度の問題を避けるべ
きだと考えます。
注)以上の解釈は、これまでの主流のSOAの解釈と若干違っているかもしれ
ません。その理由は、(1)造り屋だけで対応できるプロセス部品を除外して、
ユーザ目線でユーザと造り屋の係わるインターフェースだけをサービスと考え
る、(2)フェデレーションアーキテクチャを前提にアプリ内でなく、アプリ間
に焦点を当てている、ためかと思われます。これまで注目されることの少なかっ
た、アプリ間インターフェース仕様を確定させることによって、大部分のビジ
ネスニーズやITの変化が、個別システム内で対応できるようになるはず、と
考えるからです。この課題は、弱体化したとは言え、ユーザ企業の死守すべき
ガバナンスの最後の砦にしなければならない、と考えます。