arclamp.jp アークランプ

　図解コーチングマネジメントとかもしもウサギにコーチがいたらで有名な伊藤守さんが良く引用しているので知った清水博さん。場と共創が有名なのですが、分厚いので後回しにして場の思想を読みました。哲学書なので、ちょっと読みにくいところもあるのですが本質としては非常に良いところを指摘していて面白いです。

場とは何か？
　さて、場とは何か？ですが、僕も理解しきっていません。本の途中には「人生とは即興劇の舞台と役者」という例えが出てくるので、これを使って簡単に説明をします。
　即興劇の役者は、自分が演じるということに加えて、舞台上での自分の立場や役割を考えながら他者との関係の中で自分を位置づけます。全体の中の自分という見方と、自分自身という2つの立場があるのです。
　ですから、劇は役者がいれば成り立つというものではなくて、役者同士の関係や舞台進行によって変わってきます。場とは、この舞台に近いものです。人生は即興劇である、というのは面白い指摘です。舞台を会社、家庭、あるいはコミュニティとして考えれば、僕らは様々な舞台で演じ続けている役者です（本当は観客や劇場という説明も必要なのですが、詳しくは本で）。

　一方で科学的なアプローチというものはビルディング・ブロック、積み上げ式です。1+1=2というのが数学の基本です。しかし、場という考え方が持ち込まれると、1+1の答えは、1と1の関係によって変わってくるということになります。

SOAと場
　さて、いつものようにシステムと場という妄想に至ります（ｗ。DIやSOAには、この場の思想に近いものがある気がします。清水さんの言葉を引用します。

箱庭の場合には、次々に縮小して「世界」を定義することによって、「全体」という概念を次々とトップダウン的に定義していくことが可能になる。＜中略＞

全体とは、その内部に砂地すなわち場を含み、その場に部品（個物）を位置づけることができるもの（世界）のことをいうのである。もしもこのように1つの「世界」をそれより多くの小さい部分的世界から構築していくことができれば、そしてそのような構築を次々と続けることができれば、それは生命的構築ということができる。

ブロック構造物では1個の部品を新しい形のものに取り替えようとすると、全体の構造が崩壊する可能性がある。それは部品と部品が論理的関係によって厳密につながっているからである。そこで構造物を全体を分解して、直接的には関係ない多くの部品も取り替えなければならないことになるからたいへんに手間のかかる作業になる。場合によっては構造を根本からつくり替えることが必要になる。これに対して箱庭構造物では部品のあいだに補完的関係があり、１つの構造物を取り替えても全体の構造が全面的に崩壊する可能性はほとんどない。箱庭では、部品の変化が小さな領域の変化で済むことが多いから、絶えず全体との調和を考えながら部分の作業を進めることができる。またこのために絶えず変化をしていくことができるのである。

　前半部分の世界をコンテナ、部品をコンポーネントと読みかえればよいです。そして後半で示唆されている「絶えず変化をしていくことができる」というのがDIやSOAの目指すところです。

　僕が重視しているのはコンテナという発想です。DIコンテナは「コンポーネント同士の関係を管理している」といわれているのはご存知でしょう。
　階層化されたコンテナという点では、コンテナ内のコンポーネントが、より小さなコンテナであるというようなアイデアは実装可能です。JavaOne Tokyoで実装を提示しましたが、SpringFrameworkの中に、SpringFrameworkをコンポーネントとしてデプロイすることが可能です。

　一方、BEPLBPELやESBには感覚的に不満があります。BPELやESBでも階層は実現できるのですが、なんというか開かれすぎていて、繋ぐという行為でしかなく、それぞれの個体への責任を放棄しているように思うのです。関係を管理するというよりも、単に繋いでいるだけというか。だから接続点だけをモニタリングするようになってしまい、非常に緩やかな管理ができるのが、緩すぎる気がしてしまうのです。結局EDIの延長に過ぎないと感じるのはその点です（BEPLBPELは別の理由でも微妙なのですが、またの機会に）。

　これに対してDIではコンテナというアイデアがあり、コンテナ内のコンポーネントは全て管理されていますからAOPのような発想が生まれます。BEPLBPELやESBに比べて密に管理が行なえ、旧来の緊密構造よりも疎になっています。

　ただし現状のDIだけでは力不足です。小さなアプリケーションなら良いのですが、本格的なエンタープライズアプリケーションを考えると、もっとSOA的な要素を取り入れていかなくてはいけません。僕がSpringFrameworkを使ったJBI実装であるServiceMixが好きだったり、DIのようなSOAであるSCAが気になるなのは、コンテナという発想が明確に存在し、その上での階層化（モジュール化）が考えられている点です。
　DIとSOAは似ているという主張は何度もしていますが、もっと融合が必要です（もちろんWeb2.0も;-）。

　ちなみにですが、スクリプト言語に注目しているのは、こうしたコンポーネントの組み合わせ、つまり個体同士の関係において、動的で少し複雑なものはスクリプト言語の方が表現しやすいだろうというアイデアがあるからです。XMLは静的な関係には向きますが、条件判定や例外処理を含む場合には向いていません（BEPLBPELが微妙だと思う理由です）。
　SpringFrameworkもスクリプト言語対応を始めており、この領域は注目に値すると感じています。

場の思想は開発手法まで変える
　こうした世界の階層化というのは、開発手法にも多くの影響を与えると感じています。それは階層化されたアプリケーションを開発するチームそのものが、階層化された"場"的な組織になると考えられるからです。
　旧来の開発で問題なのは、ある一定上の人数になる複雑な組織になるとマネージメントもコントロールも効かなくなってしまう点です。であれば、マネージメントできるレベルまで組織を分割すればよい。

　SOA、DI的なアプリケーションであれば、そのアーキテクチャにあわせた組織を構成することも可能になるはずです。

　現状では、複雑なものを管理するために開発ツールの整備が進んでいるように感じます。数百人で情報を共有できるように、設定をダイアグラム化し、レジストリを用意しています。しかし、そうではなくてアーキテクチャを見直し、顔が見える範囲で情報が共有できれば、世界の階層化で問題が解決するようにした方が実現性が高い気がしています。

　「モノシリックで複雑なものをいかに管理するか」ということではなく「いかに物事を複雑にしないで分割するか」という逆の発想が必要なのです。先日のTOYOTAの方が「問題はマクロで捉え、発見したらミクロに探る」ということをいわれていましたが、その通りだと思います。
　SOAは開発手法である、と僕が思うのはこういう理由からです。

　どうもシステム寄りな話ばかりしてしまいましたが、本には人生にまつわる様々な示唆が盛り込まれています。最終的には世界が直面している問題に対して、場という考え方が重要であるというところまで語られています。ちょっと難しいのをこらえれば、面白いと思います。

場の思想 清水 博 東京大学出版会 2003-07 by G-Tools