SOAのカギを握るBPEL：新たな潮流（4/4 ページ）

今回は、SOAによるシステム構築でカギになるBPELについて紹介する。（特集：顧客満足度ナンバーワンSEの条件）

[清水敏正（日本アイ・ビー・エム），ITmedia]

　BPELは、このように業務処理そのものを記述し、実行させることを意図しているが、トプダウンでのSOAの実施に欠かせない、業務処理そのものを記述することが、実は日本人がいままで苦手にしてきたのではと危惧している。

　昔、マクドナルドが日本に進出してきた頃の話になるが、われわれはマクドナルドの店舗内の業務を事細かく書いた「マニュアル」の存在に驚いたものである。なにしろ、マニュアルに書かれた通りにすれば、アルバイトの学生がたちまち独特な味付けのハンバーガーを作れるし、どこのお店に行っても同じ応対、同じ雰囲気で安心して買うのである。

　その後アメリカの文化はどっぷりと日本に浸透してきたが、日本企業において、すべての日常業務をきっちりと記述している企業はどれだけ存在するのであろうか。

　IT部門が、ある業務をIT化する時には、いわゆるエンドユーザーに話を聞き、要件を定義書にまとめ、システム化するのに必要な情報はすべて文書化され、そしてプログラム開発につなげられる。

　問題は、そうする以前には業務手順書などが存在していないことである。もちろん、しっかりとしている企業もあると理解しているが、私には、日本人の特性がマニュアル通りに働く、働かされることを拒むのではないかと思えてしまう。

　先輩から後輩への現場での職務訓練と経験蓄積、人間性・個性の発揮を職場にも求めることによって、働き甲斐のある職場を追求する。また、経営者側も、あいまいな部分を残しておいたほうがスムーズに社内が動くと思っている節が少しはないであろうか。

　仕事の流れ、やり方、関係する人たち、役割、それらをIT部門とともに文書化してゆく作業は、容易ではないが、SOAを迎える時代では、特殊な先進的な企業と呼ばれる人たちだけのものではない。コンサルタントを雇える企業だけが業務分析や業務改革を全社的に行うのでなく、IT部門とエンドユーザー部門が共同で、理想的にシステム化されているか否かを問わず、業務処理の流れを文書化することが重要だと思う。

　しかも、PowerPointなどの「お絵描きツール」でなく、Machine ReadableなBPELで書けるか否かが重要である。日本の企業の仕事のやり方は米国とは違うと言う人がいるが、部分的には事実として、BPELで書けるようにすることが世界の流れだ。もし、日本の企業にユニークさが存在するならば、BPELの仕様策定に日本人の参画も必要かもしれない。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

清水敏正（技術理事 / IBM Distinguished Engineer）

メインフレームOS、分散処理、SNA 、ネットワーキング、LANなど、さまざまな製品テクノロジーの普及・技術支援を担当。1991年から5年間テキサスに駐在し、全世界向けの技術書籍とワークショップを提供。帰国後は、Webアプリケーションサーバの普及に注力し、多くの顧客企業のミッションクリティカルなシステム構築にITアーキテクトとして携わる。日本の顧客企業に受け入れられる製品技術の開発と提供が信条。海外の開発部門と一体となり、アプリケーション構築の最適プラットフォームとしてのアプリケーションサーバを追求中。 現在SOAを広めるために鋭意活動中。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***