変幻する実行可能知識 11「なるといふこと」アーキテクトとはかたちづくる人のことなり, という話からこの話は始まったのであった. アーキテクトはがんがん作るのが仕事なのだ. 「こんなシステムを作りたいのだが...」という依頼を受けて, 「いや, まぁやめときましょう. システムなんざ作ったってろくなことになりゃしねぇ. 今のままでじゅうぶん, じゅうぶん. そんな金があるんだったら, どうですこれからひとつ印度へでも放浪の旅に...」などということはあまりない. 「まぁ作ったっていいんですがねぇ. 半年や一年でまともなものができると思ってもらっちゃあ困るんだ. システムってやつは10年, 20年かかってようやくほんものだ. ひとつどうです, それまで何も言わず俺のこの腕にぽーんと20億ばかり...」という話も寡聞にして聞かない. 世の中はアジャイルだ, なんだとかまびすしい. アジャイル・プロセスとは別に急いでものを作る技術ではなかったはずだが, とにかく速く作るのが偉いという風潮がなきにしもあらずだ. その一方でスロー・フード, スロー・ライフなどという言葉も流行っていて, これはこれで洒落たスロー・フード・レストランで優雅に飯を食うことと混同されているきらいがある. これからはスロー・プロセスだ, と豆蔵の羽生田さんもアジャイルプロセス協議会の設立記念セミナで力説 (?) していたなぁ. もう2年近くの前の話だけれど. 問題は作るのが速いか, 遅いかということではない. いくらケント・ベックだって某大企業情報システム部門と同じものを同じやり方で作っていたら, やっぱり同じだけのコストと時間がかかるだろう. 問題なのはむしろ作りすぎていることなのだ. そしてやたら作っては, 作りっぱなし, かっこいいシステム作っといたから後は保守部隊よろしくねー, なのだ. そしてそういうシステムは数年後には使われなくなってまた新しいシステム構築に励んでいるか, つぎはぎだらけでにっちもさっちもいかないシステムをユーザが (しなくていい) 知恵と苦労で使いこなしているという事態に陥っているかだ. 作りすぎているという問題には, 二つの側面がある. 一つは量の問題で, 本来作らなくてもいいはずなのにいっぱい作りすぎているということ. どこかの国で使いもしない建物をむやみに立てまくっている問題と同じですね. これはもちろん永久に作り続けないと仕事がなくなってしまうという作り手側のビジネス・モデルの問題でもあるのと同時に, 新しいシステムを入れ続けないと何となく不安で仕方がない顧客側の問題でもあるかもしれない. もう一つは「作る」ということの意味の問題. 建物を造るときも同じかも知れないけど, 我々がシステムを作るときには「世界」あるいは「世界観」を問題にする. あるシステムを作るとは言ってみればひとつの世界を作ることだ. 世界がどれほど素晴らしい「世界観」を元に作られているか. ときには一神教の神が世界を作るように, アーキテクトの「世界観」をシステムに吹き込むことができればアーキテクトは無上の喜びに満たされる, というような傾向があることも否めない. スクラッチから美しく作られた世界は素晴らしいが, その世界観が孤高のものであればあるほど, 一部の熱狂的なファン以外には受け入れられない可能性も高い. 何よりもシステムは常に開いている. ユーザに対して, 現実の世界に対して, 他の数多くのシステムに対して. それらのひとつひとつも自分自身の世界観を持っているのだ. 孤高の世界観を持ったシステムは往々にして, 外の世界の世界観との軋轢によって崩壊していく... 例えばEJB (Enterprise Java Beans) というのは独自の世界観を持ったひとつのシステムだ (それが美しいか美しくないかはおいておくとして:-). EJBが失敗だったと結論づけるのは早すぎるとしても, 少なくとも一般的にあまり好まれていないのは, EJBの持つ世界観を何重にも翻訳しないと我々の持つ世界観 (ただのJava = POJO) と整合しなかったからかもしれない. また世の中にはさまざまなモデリング方法論というものもある. 例えばたまたま手元にある, ピーター・コードの方法論 (「Javaエンタープライズ・コンポーネント - カラーUMLによるJavaモデリング」は, 4種類のアーキタイプ (瞬間 - 時間間隔, 役割, 説明, パーティ/場所/物) とそれらの組み合わせパターンに基づいてエンタープライズ・モデリングをしようというものだ. この考え方はなかなか素晴らしい. よくできている. 多分実効性もあるだろう. じゃあ自分がエンタープライズ・システムを作るときにこの方法論に基づいて作るかといえば, そんなことはない. コードの方法 (やその他いろいろな方法論) を横目で見つつも, やはり独自の方法でモデリングしているのだ. クライアントの顔や開発メンバの顔を思い浮かべながら, 開発ツールやフレームワークのマニュアルを思い出しながら... その一方で, オブジェクト指向というのもやはり20年前には孤高の世界観であった. 「美しいかもしれないけど, 使えないね」「単なる遊びじゃないの」「理想でシステムは作れないから」などと言われていたものだ. しかし今や「オブジェクト」という言葉はあまりにも当たり前のものになってしまった (それが本当の「オブジェクト」を指しているかどうかは難しいところだが...). 若いエンジニアはオブジェクトが世界観だとは思いもよらないかもしれない. どうやらある時点でオブジェクトは孤立した世界観ではなく, 世界と世界をつなげる接着剤のような役割に変わってきた気がする. ご存知XP (エクストリーム・プログラミング) も, 独自の「世界」をできるだけ作らないような仕掛けになっている. XPでは基本的に大文字のアーキテクチャやモデルは存在しない. 愚直にストーリ・カードをソース・コードへと変換していく. 同時にテストやリファクタリング, リリースなどによって常に「世界」と「世界」の間のすり合わせをし続ける. じゃあそこにはなんの世界も構築されないのか, というとそういうわけでもなさそうなのが微妙なところだ. 実際XPで作られた製品のコードを見ると, 非常にユニークな世界観が反映された世界が構築されていることがままある. この二つの世界 - 最初から考え抜かれ人工的に作られた独自世界と, いつの間にかできあがってしまった独自世界 - の違いはいったいなんなんだろうか? 木村純二の「生命の根拠をめぐる一考察」(季刊日本思想史 No.62, 2002年12月, ぺりかん社) の註によれば, 丸山真男は世界の諸神話に見られる動詞を分析して, キリスト教的な「つくる」論理に対して, 日本的な「うむ (産む)」 から「なる」「なりゆく」発想を特徴として扱っているという. つまり「作りすぎない」こと. システムをひとつの孤立した世界として作り上げるのではなく, システムを産み落としたら, 周囲の無数の世界との相互作用やすり合わせを通じて「なりゆく」ようにシステムを育てること. だからといって, いわゆる「日本的」で主体性のない, 誰も責任を取らない, どれもこれも似たり寄ったりの無個性なシステムでいいわけでもないが. 本当のアーキテクトの仕事は, 神様の真似をすることではなさそうだ. 僕たちは本当の神様ではないから最初からすべてのことをあらかじめ織り込んでおくことはできない. しょせん不完全な我々の作り上げた世界はいつか崩壊する. 我々にできることといえば, できるだけうまくシステムが育つように少しでもよい環境を用意してやることだけかもしれない. そしてシステムが育つ過程から目を離さないことだ. システムがよく育っていけば, いつかはシステムも我々が作った環境を必要としなくなるだろう. ま, それはそれでめでたい, アーキテクト冥利に尽きるということで... |