システムを作り過ぎないこと、育つ環境を用意すること：実行可能な知識とソフトウェア（11）

作り過ぎているという問題には、2つの側面がある。1つは量の問題で、本来作らなくてもいいはずなのにいっぱい作り過ぎているということ。（本文より）

　アーキテクトとは形作る人のことなり、という話からこの連載は始まったのであった。アーキテクトはがんがん作るのが仕事なのだ。「こんなシステム を作りたいのだが……」という依頼を受けて、「いや、まぁ、やめときましょう。システムなんざ作ったってろくなことになりゃしねぇ。いまのままで十分、十分。そんな金があるんだったら、どうです。これからひとつインドへでも放浪の旅に……」などということはあまりない。「まぁ作ったっていいんですがねぇ。半年や1年でまともなものができると思ってもらっちゃあ困るんだ。システムってやつは10年、20年かかってようやく本物だ。ひとつどうです、それまで何もいわず俺のこの腕にぽーんと20億ばかり……」という話も寡聞にして聞かない。

　世の中はアジャイルだ、なんだとかまびすしい。アジャイル・プロセスとは別に急いで物を作る技術ではなかったはずだが、とにかく速く作るのが偉いという風潮がなきにしもあらずだ。その一方でスロー・フード、スロー・ライフなどという言葉もはやっていて、これはこれでしゃれたスロー・フード・レストランで優雅に飯を食うことと混同されているきらいがある。これからはスロー・プロセスだ、と豆蔵の羽生田さんはアジャイルプロセス協議会の設立記念セミナーで力説していたなぁ。もう2年近くの前の話だけれど。

　問題は作るのが速いか、遅いかということではない。いくらケント・ベックだって某大企業情報システム部門と同じものを同じやり方で作っていたら、やっぱり同じだけのコストと時間がかかるだろう。問題なのはむしろ作り過ぎていることなのだ。そしてやたら作っては、作りっぱなし、かっこいいシステム作っといたから後は保守部隊よろしくねー、なのだ。そしてそういうシステムは数年後には使われなくなってまた新しいシステム構築に励んでいるか、継ぎはぎだらけでにっちもさっちもいかないシステムをユーザーが（しなくていい）知恵と苦労で使いこなしているという事態に陥っているかだ。

　作り過ぎているという問題には、2つの側面がある。1つは量の問題で、本来作らなくてもいいはずなのにいっぱい作り過ぎているということ。どこかの国で使いもしない建物をむやみに建てまくっている問題と同じですね。これはもちろん永久に作り続けないと仕事がなくなってしまうという作り手側のビジネスモデルの問題でもあるのと同時に、新しいシステムを入れ続けないと何となく不安で仕方がない顧客側の問題でもあるかもしれない。

　もう1つは「作る」ということの意味の問題。建物を造るときも同じかもしれないけれど、われわれがシステムを作るときには「世界」あるいは「世界観」を問題にする。あるシステムを作るということは、1つの世界を作るということだ。その世界がどれほど素晴らしい「世界観」を基に作られているか。一神教の神が世界をつくるように、アーキテクトの「世界観」をシステムに吹き込むことができれば、アーキテクトは無上の喜びに満たされる、というような傾向があることも否めない。

　スクラッチから美しく作られた世界は素晴らしいが、その世界観が孤高のものであればあるほど、一部の熱狂的なファン以外には受け入れられない可能性も高い。何よりもシステムは常に開いている。ユーザーに対して、現実の世界に対して、ほかの数多くのシステムに対して。それらの1つ1つも自分自身の世界観を持っているのだ。孤高の世界観を持ったシステムは往々にして、外の世界の世界観とのあつれきによって崩壊していく……。

　例えばEJB（Enterprise Java Beans）というのは独自の世界観を持った1つのシステムだ（それが美しいか美しくないかは置いておくとして）。EJBが失敗だったと結論付けるのは早過ぎるとしても、少なくとも一般的にあまり好まれていないのは、EJBの持つ世界観を何重にも翻訳しないとわれわれの持つ世界観（ただのJava=POJO）と整合しなかったからかもしれない。

　また、世の中にはさまざまなモデリング方法論というものもある。例えば、たまたま手元にある、ピーター・コードの方法論（「Javaエンタープライズ・コンポーネント ― カラーUMLによるJavaモデリング」は、4種類のアーキタイプ（瞬間‐時間間隔、役割、説明、パーティ／場所／物）とそれらの組み合わせパターンに基づいてエンタープライズ・モデリングをしようというものだ。この考え方は なかなか素晴らしい。よくできている。たぶん、実効性もあるだろう。じゃあ、自分がエンタープライズ・システムを作るときにこの方法論に基づいて作るかといえば、そんなことはない。コードの方法（やその他いろいろな方法論）を横目で見つつも、やはり独自の方法でモデリングしているのだ。クライアントの顔や開発メンバーの顔を思い浮かべながら、開発ツールやフレームワークのマニュアルを思い出しながら……。

　その一方で、オブジェクト指向というのもやはり20年前には孤高の世界観であった。「美しいかもしれないけど、使えないね」「単なる遊びじゃないの」「理想でシステムは作れないから」などといわれていたものだ。しかしいまや「オブジェクト」という言葉はあまりにも当たり前のものになってしまった（それが本当の「オブジェクト」を指しているかどうかは難しいところだが……）。若いエンジニアはオブジェクトが世界観だとは思いも寄らないかもしれない。どうやら、ある時点でオブジェクトは孤立した世界観ではなく、世界と世界をつなげる接着剤のような役割に変わってきた気がする。

　ご存じXP（エクストリーム・プログラミング）も、独自の「世界」をできるだけ作らないような仕掛けになっている。XPでは基本的に大文字のアーキテクチャやモデルは存在しない。愚直にストーリー・カードをソース・コードへと変換していく。同時にテストやリファクタリング、リリースなどによって常に「世界」と「世界」の間の擦り合わせをし続ける。じゃあ、そこにはなんの世界も構築されないのか、というとそういうわけでもなさそうなのが微妙なところだ。実際、XPで作られた製品のコードを見ると、非常にユニークな世界観が反映された世界が構築されていることがままある。

　この2つの世界（最初から考え抜かれ人工的に作られた独自世界と、いつの間にか出来上がってしまった独自世界）の違いはいったいなんなんだろうか？ 木村純二の「生命をめぐる根拠−『愛』は『生命』の根拠か」（季刊日本思想史 No.62、2002年12月、ぺりかん社）の註によれば、丸山真男は世界の諸神話に見られる動詞を分析して、キリスト教的な「つくる」論理に対して、 日本的な「うむ（産む）」 から「なる」「なりゆく」発想を特徴として扱っているという。つまり、「作り過ぎない」こと。システムを1つの孤立した世界として作り上げるのではなく、システムを産み落としたら、周囲の無数の世界との相互作用や擦り合わせを通じて「なりゆく」ようにシステムを育てること。だからといって、いわゆる 「日本的」で主体性のない、誰も責任を取らない、どれもこれも似たり寄ったりの無個性なシステムでいいわけでもないが。

　本当のアーキテクトの仕事は、神様のまねをすることではなさそうだ。僕たちは本当の神様ではないから最初からすべてのことをあらかじめ織り込んでおくことはできない。しょせん不完全なわれわれが作り上げる世界は、いつか崩壊する。われわれにできることといえば、できるだけうまくシステムが育つよう、少しでも良い環境を用意してやることだけかもしれない。そして、システムが育つ過程から目を離さないことだ。システムが良く育っていけば、いつかはシステムもわれわれが作った環境を必要としなくなるだろう。ま、それはそれでめでたい、アーキテクト冥利に尽きるということで……。