2006年、東京の会社を辞めて山形に戻り、市役所に行った時のこと。目的は、転入届けと、国民年金、国民健康保険の加入。・・・ジミな話でスミマセンね。

私は、転入届け用紙を書いて、３番窓口に提出しました。
しばらく待つと、

といわれたので、そのとおりに。そしてまたしばらく待つと、
と。・・・ああ、これってSOAだなぁ・・。と感じてしまった、職業病のワタシ。

私は、転入届けの用紙を書いて、窓口に提出して、呼ばれるのを待ってました。窓口の向こうで、職員がいろいろやっていたようですが、何をしているのかは知りません。でも、転入手続きは無事に終わりました。これがSOAです。

次に国民年金加入用紙と窓口を教えてもらって、歩いていって、提出しました。その次の国民健康保険も、同じようにしました。次になにをすればいいのかを教えてくれたので、悩まずに行動できました。これがBPM（ビジネスプロセスマネージメント）です。

窓口の向こうでは、それぞれの担当職員が、パソコンに入力したり、コピーをとったり、他の職員に書類を渡したりしているようです。これがEAI（アプリケーション統合）です。

私が「おいおまえら、市民をたらい回しに歩かせるんじゃねえよ！窓口の奴ら、おれの前に並べ！」と言ったとします。窓口担当の人たちが渋々わたしの前に並びました。これがポータルです。

こういう風に、市民にわかりやすく窓口を並べて、提出書類を決め、次になにをすればいいのか誘導する。このしくみを設計することが、EA（エンタープライズアーキテクチャ）です。

窓口に行って一通り手続きが終わるのには、全部で３０分くらいかかります。これをコンピューターが自動的にやって、数秒で終わらせるようにする。そのために、SOA製品があります。

大企業ほど、部門が分かれていて、それぞれの部門には窓口があります。それぞれの窓口は、たいてい「用紙に必要事項を記入して提出してくれ」などと、会話を単純化しているはずです。こういうことができてない企業は、まずSOA製品を買ってもムダです。

上司が部下に仕事をさせる場合、おそらく口頭で「この仕事をこんな風にしといてくれ」と、アバウトな会話で作業依頼をしていることが多いでしょう。
それが成り立つのは、上司と部下の信頼関係や過去の実績があるからです。この二人は、お互いに換えが利かない存在です。こういう「人間くさい会話が大切」な業務は、SOAにはなりません。
これをもっと形式ばったフォーマットで伝えることができて「部下は誰でもいい」という境地に達すれば、SOAになり得ます。

BPMも同じです。仕事を受注するための根回しや寝技といった行動は、BPMになり得ません。BPMを導入するためには、明確な「受注条件」が必要なのです。

つまり、SOAを導入したければ、人間臭いところをもっと機械的にできないか？を一生懸命考えなければなりません。

と達観できる人、俯瞰できる人がいなければ、成功しません。だからSOAには、社長や役員の意思決定が必要なのです。

SOA製品を買う前、プロジェクトを開始する前に、じっくり考えてください。コレを考えずに進めても、何も良いことはありません。