第4回第一歩はプロセスの可視化

日経コンピュータ，田中　淳＝日経ソフトウエア

2007.05.08

SOA（サービス指向アーキテクチャ）に基づくシステムを実現するには、どこから着手すればよいか。第一歩を踏み出すユーザー企業に共通しているのは、ビジネス・プロセスを可視化すること。全社レベルで進める、特定の業務を対象にする、画面の移り変わりに着目するなど、進め方は各社各様だ。

日経コンピュータ2006年2月6日号の記事を原則としてそのまま掲載しています。執筆時の情報に基づいているため、社名や登場人物の肩書きを含め現在は状況が変わっている点がありますが、SaaSやEnterprise2.0の動向に興味のある方に有益な情報であることは変わりません。

　SOAに基づいて情報システムを実現したユーザー企業は、日本にはまだ存在しない。だが、その一歩目を踏み出した企業はすでにある（表1）。

表1●SOAに基づいて社内システムを見直している企業の例

　「ビジネスとITの一体化を進めるために、SOAは有効だと考えている」。こう話すのは、SOAに取り組む住友信託銀行でCIO（最高情報責任者）の役割を務める奥野博章常務。同行では商品の多様化などでシステムが複雑になり、新商品投入の際のシステム改変が困難になっていた。危機感を抱いたシステム部門は、ビジネスの変化をいち早く反映できるよう、SOAに基づくシステムに改変していく計画である。

　SOAに本気で取り組む姿勢を強調するのは、同行に限らない。各社はどのようにSOAに向けた一歩目を踏み出したのか。住友信託銀行、オリンパス、NTTコミュニケーションズ（NTTコム）、損害保険ジャパン（損保ジャパン）の取り組みを見ていこう。

住友信託銀行
利用部門を動かし全体像を把握

　業務と基幹システムの現状（As-Is）とそれらのあるべき姿（To-Be）をビジネス・プロセスとして可視化する。その上でTo-Beを目指し、徐々にシステムに改良を加える――。SOAに向けた第一歩として、EA（エンタープライズ・アーキテクチャ）に取り組んでいるのが住友信託銀行である。EAへの取り組みの過程で、SOAに基づいたシステム改変を進める方針だ。

　住友信託銀行が作成したビジネス・プロセスは2種類ある。1つは、全社の基幹業務の流れを俯瞰ふかんするための図。もう1つが、部門ごとのプロセスを示す図だ。

　まず2005年5月に、前者の図を作成した。「相対型与信」、「シンジケートローン」などの商品ごとに、申請や登録、リスク管理といった業務の流れを明記。さらに各業務をシステムで支援しているか、手作業かを記述した。この図はAs-Isを表したものだが、これとTo-Beを比べることで、目指すべきシステムの全体像と、何を変えていくべきかを把握できる。

　ビジネス・プロセスは利用部門が中心になって作成した。「システム部門が現場にヒアリングする形だと、システム部門の日常業務が滞ってしまう」（奥野常務）との判断からだ。

　その準備として、05年6月にシステム部門を再編成。ビジネス・プロセスを描くスキルを持つシステム要員を、八つの利用部門に配属させた。その上で各利用部門に対し、6カ月に一度のシステムの新規・改修案件の申請時には、As-IsとTo-Beのモデルを提出するよう義務付けた。ビジネス・プロセスがおのずとシステム部門に集まるようにする仕組みである。

　利用部門では、システム部門出身のメンバーが部門ごとのビジネス・プロセスの書き方を指導して作成する。その際には、UMLのアクティビティ図を使う。現状では、「利用部門が作成した図でビジネスの実態を正確に表しきれているかと言えば、まだ60点程度」（奥野常務）だが、以前よりも利用部門からの要求が明確になったなどのメリットが得られたという。

　現在は、06年稼働を目指した大型システムの刷新プロジェクトをSOAに基づいて進めている。俯瞰図で他のシステムとの機能の重複を確認しつつ、アクティビティ図を基に、どの既存システムをサービス化するかを定義した。「基幹業務なので、何のシステムかは公表できない」（奥野常務）としている。

オリンパス
プロセスを3段階で詳細化

　サービスはあらかじめ定義しておくこともできるし、業務の手順を決めてからそれに合わせて定義することも可能だ。オリンパスが05年に実施した修理業務支援システムの開発プロジェクトでは、後者の方針でサービスを決めていった。

　オリンパスが定義したのは、医療機器の修理に関する一連のビジネス・プロセスである。修理依頼の受付から修理費用の見積もり、納期回答、請求書の発行までがその範囲となる。

　これを3段階で詳細化し、ERPやCRMのパッケージが提供する機能（サービス）にマッピングした。まず第1段階で、「修理は『引取修理』や『出張修理』などのビジネス・プロセスに分類できる」などと、プロセス自体を分類。第2段階で、「引取修理は『着荷』、『見積もり』などの業務からなる」のように、各プロセスを構成する業務を記述する。第3段階では、「見積もりは『見積もり金額を計算する』、『見積書を作成する』という作業からなる」といった具合に、業務の遂行に必要な作業を規定する。

　こうして決めた「業務に遂行に必要な作業」は約600種類。このうちERPやCRMのパッケージにマッピングできたのは430種類である。残る170種類は手作業、または別途開発で実現したわけだが、「理想的なビジネス・プロセスになったし、今後の変更も容易になる」（北村正仁情報システム本部IT戦略推進室長）。

NTTコム
画面遷移をプロセスとして定義

　ビジネス・プロセスは、利用者が使う画面の遷移（移り変わり）の順序で表す――。NTTコムはこの考え方で、今秋を目標に一般消費者向け事業を支援する社内システムの刷新を進めている。「SOAの考え方は有効だが、自分たちでアレンジして使えばよいと考えている」と、日高健治コンシューマ＆オフィス事業部CRMシステム部長は語る。

　同社が画面にこだわるのは、新商品を相次ぎ投入した結果、システムの操作が複雑になっている問題を解決するためだ。経験5年以上のベテランなら、操作方法が変わっても習得にあまり苦労しない。だが、「経験3カ月未満の新人は『覚えることが多すぎて、ついていけない』との声を上げていた。他の企業と同様、離職率は新人のほうが高く、結果的にベテランに負担がかかっていた」（日高部長）。

　NTTコムが狙うのは、新人向け、ベテラン向けなど習熟度に応じて異なる画面を表示できるシステムを実現することだ。しかも、申し込み受付や請求書発行など40種類のサブシステムは、できる限り生かしたい。そのためにはSOAが最適と判断した。

　同社は06年秋にも、画面の遷移や画面間でのデータの受け渡しをつかさどるミドルウエアである画面制御基盤を開発する（図6）。ここで規定したビジネス・プロセスに基づいて、サービスを順に実行する。同社は画面遷移でビジネス・プロセスを表しているので、サービスを同社流に表現すれば「画面にデータを表示するための一連の処理」となる。