PR

 システムを業務ニーズに合わせるには,システムも業務も可視化できる状態になっていなければならない。BPMツールなどを用いれば,システムのワークフローを可視化でき,フローの稼働状況をモニタリングすることも可能である。

範囲を絞ってモデリング

 すべてのシステムに対して,BPMツールを使えばよい,というものではない。業務によっては単体で完結するものもある。清水建設は,全社の業務を2つのタイプに分けた(図5)。一つは,同社のビジネスの根幹となる顧客とのやりとりを中心とした業務で,業務そのものが連携しているもの。もう一つは,人事や財務会計など業務部門とデータのやりとりはあっても,基本的には,その管理部門内で業務は閉じているもの,である。

図5●清水建設のSOAに対する考え方
全社的にSOAの考え方を導入するのではなく,まず同社のビジネス中心となる顧客にかかわる部分に,ビジネス・プロセス・モデリングの考え方を全面的に導入している

 「業務フローが発生するところは,ビジネス・プロセスに柔軟性が必要だ。しかし単体で閉じているものは,必要なデータさえあれば業務ができる」(清水建設 情報システム部 課長 安井昌男氏)。そこで,前者は,業務フローに携わる人間と,システムに携わる人間がお互い理解し合いながらビジネス・プロセスのモデリングを行う。後者は,データ連携を自動化するなどで業務を効率化することにした。

課題は山積み

 単純にシステム間連携ツールを導入したり,ビジネス・プロセスのモデリングを行ったりするだけで,簡単にSOAを実現することはできない。

 例えば,標準化が進められているBPMNやBPELにもビジネス・プロセスのモデリングやワークフローを描くGUIツールがあるが,「BPELでのワークフローの設計はまだプログラミングのようで,新しいビジネス・プロセスを考える上で業務部門の人には使いにくい」(清水建設 安井氏)。同社では,業務に詳しい現場の人も使えるLFD(Lane Flow Diagram)を利用し業務フローとシステムのマッピングを行い,新しいビジネス・プロセスを模索している(図6)。

図6●清水建設の考案したLFDのサンプル例
システム担当者だけでなく,業務に詳しい現場の人も使えるビジネス・モデリングの手法を考案した

 BPELを使ったワークフローの開発については,「既存のJava統合開発環境(Oracle JDeveloper)にプラグインする形で,違和感なくモデリングできるようにしていく」(日本オラクル マーケティング本部 システム製品マーケティンググループ 担当シニアマネジャー 西脇資哲氏)など,開発ツールでも工夫していくようだ。

 このほか技術面での課題も多い。 代表的な問題として,(1)サービスの粒度や抽象度に関する問題と,(2)サービスやハブの信頼性に関する問題などがある(図7)。

図7●SOAの抱える技術面での課題
さまざまな課題があり,SOA型のシステムにするためのレファレンス・モデルが少ない
[画像のクリックで拡大表示]

 (1)は「これまで消費税計算などいかにソフトウエア部品として再利用できるかという実装ありきで考えていた。サービス単位で考えるにはオブジェクト指向など基本が分かった上で初めて,粒度や抽象度を揃えることができる」(清水建設 情報システム部 野田伊佐夫氏)。サービスの粒度が揃わなければ,業務フローの一端を担えない。

 一つの目安として,SAPジャパンの考え方がある。「mySAP ERPなどのモジュールはサービスの粒の1つとして考えられる」(ソリューション統括本部 ソリューションマーケティング本部 本部長 三村真宗氏)。

 (2)は,ハードウエアを二重化するだけでなく,サービスを中継するハブ上の流れを把握しておかなければならない。そうしておかないと,何らかの障害が発生した場合,どのサービスが落ちるとどこまで影響が及ぶかが分からないからだ。特に,再利用しやすいサービスを切り出すことができた場合,そのサービスはいくつものサービスから呼び出される可能性がある。