ビジネスとシステムとの大きな溝

企業においてシステムのもたらす価値は誰もが認めるところとなり、システムへの期待も高まってきた。システムの投資対効果を把握しようと試みたことや、ビジネスプロセスマネジメント(BPM)に対する期待が物語っている。IT業界でこれまで作られてきた3文字用語とは違って、BPMは実を伴う予感があった。BPMが本当に全ての解決策となるのかどうかはわかるには、まだまだ時間がかかるということなのであろうか。

『「ビジネスとITが出合う場所」のために何が必要か?』(著:ポール・ハーモン、訳:吉川 昌澄)では、以下のように述べている。
(以下、引用)
 多くの場合、ビジネスサイドの人々がビジネスプロセスの改良に注目し、ITサイドの人々はビジネスプロセスを支援するように構成されるべきだという考え方は、共通の合流場所に向けた重要な転換のように見える。その議論以降、ITサイドは一切、テクノロジの目的のためにテクノロジを売り込もうとはしなくなった。ITはビジネスプロセスを改善できるテクノロジを推奨するようになった。同じように、ビジネスの人々は、ITを微に入り細にわたって管理しようとはしなくなった。その代わりに、特定のビジネスプロセスを支え実現するためにITがどう使われているかを評価することに注目するようになった。いい換えれば、両者は、ビジネスにとって重要なプロセスについて話し合い、それを改善するために協力して働くようになったのだ。
 しかしながら、私たちは懸念を持っている。というのは、すでに多くの組織がプロセスレベルに着目することで合意したかのように見えるが、ビジネスとITの双方がチームに何をもたらせば成功につながるかを、厳密に考えている組織はごくわずかであるということだ。私たちが顧客と話す中でしばしば出合うのは、何がプロセスなのか、それをどう分析すればよいのか、そしてどう支援すればよいか、そんなことは誰でも知っているという甘い思い込みである。もちろん現実には、ビジネスサイドとITサイドの人々は往々にして、プロセスの性質に関して似ても似つかない考えを持っているものだ。
 従って、われわれは共通言語を必要とするだけでなく、共通の分析レベルについて合意しなければならない。正しいアプローチは、ビジネスとITの両者が、自分がかかわるプロセスを特定できて、それらがどのようにかかわっているかを理解できるように、ビジネスプロセスの階層構造を定義できるビジネスプロセスアーキテクチャを開発することだと考えるかもしれない。しかし、このもっともなゴールは、しばしばフラストレーションの原因になる。それはEA(Enterprise Architecture)を開発するために米国政府が行ってきた努力を見てきた人であれば分かるだろう。シニア・ビジネスマネージャにはとうてい理解し切れない膨大な詳細情報に埋もれて、大きな絵(大局)を見失ってしまうことがしばしば起こる。ITの人たちは何でもかんでも膨大なザックマンの“整理棚”(訳注:ザックマン・フレームワークのこと)に仕分けして、しまい込むことにとらわれる。共通の議論の土台を提供する高いレベルの全体像は、データベース編成の努力に終わってしまい、結局、ITチームだけにメリットがあり、ITチームだけが理解できるものとなってしまうのだ。
 近年、共通言語のアイデアの整備に取り組む人々は、組織におけるビジネスプロセスの階層のハイレベルの概観を与えるビジネスプロセスアーキテクチャ(Business Process Architecture)と、エンタープライズアーキテクチャ(Enterprise Architecture)とを区別すべきだと唱えている。なぜなら、EAはBPAを含んでいるかもしれないが、往々にして組織のITリソースを識別し構成するためだけに用いられる手法であるからだ。
(以上、引用)

日本の中央省庁で、EAの導入の検討を行っていた時にも議論された問題である。ザックマンフレームワークをフルセットで導入することは投資対効果を考えると現実的ではないので、フレームワークのカスタマイズが行われた。中央省庁の情報システムの最大の問題点は職員がシステムではなくて、業務自身もきちんと把握していないことであるという認識から、ビジネスプロセスはビジネスサイドの観点から作られることになった。多くのシステムサイドの人間からは、それではビジネスプロセスがシステム開発の設計書にはならないと疑問を唱えたが、目的はシステムの可視化ではなく、業務の可視化であったわけなのだから、問題はなかった。大きな間違いが起きてしまったのは、そもそもの目的が共有されないうちに、EAの導入フレームワークとなる業務・システム最適化ガイドラインが作成され、最適化計画の業務流れ図は、システムサイドの人間がシステムの流れ図を作成してしまったことにある。特に行政におけるビジネスプロセスは法令や制度で規定されているにもかかわらず、法令・制度がビジネスプロセスにマッピングされていないことが大きな問題である。ほとんどの最適化計画は業務担当者へのヒアリングとシステムの基本設計書や操作手順書を見て作成されてしまった。

BPMが期待通りに役立てるかどうかは、ビジネスサイドとシステムサイドの人間が共通認識できるビジネスプロセスのレベルを設定できるかどうかにかかっている。現実的な解として、操作画面単位でビジネスプロセスのレベルを設定することが、双方の人間にとってもっともわかりやすいはずである。現在のシステムのほとんどはプログラムを機能単位で実装しているために、操作画面も機能を操作する画面となっている。ビジネスプロセスは操作画面を呼び出す人間の頭の中に隠されている。すなわち、現在のシステムにはビジネスプロセスは組み込まれていないと言ってしまったほうがいいかもしれない。ワークフローシステムをベースに構築されたシステムが皆無であることがこのことを物語っている。

システムサイドで語られているBPMのプロセスやSOAで取り扱うサービスはあくまでもシステサイドのレベルの話である。