空間的再利用とは「複数のプロジェクトに対して同時にライブラリやコンポーネントを再利用すること」を言います。あるプロジェクトで作られたモノを複数のプロジェクトに展開するものの含まれます。一般的な再利用は「空間的再利用」を示す場合が多いと思います。

　時間的再利用とは「そのプロジェクトにおいて同じライブラリやコンポーネントが使い続けられる」ことを言います。プラットフォームやアーキテクチャ、あるいは関係する他モジュールに変更があっても、昔のライブラリがそのまま（あるいは微妙な変更で）使えるという意味です。

　再利用におけるメリット、例えばコスト削減効果は同じです。ですが、この2つの再利用は分けて考えた方が良い。簡単にいえば空間的再利用は「早く作る」ための再利用で、時間的再利用は「長く使う」ための再利用です。とはいえ、これについては異論があると思います。僕自身も整理中なので、ぜひ意見をください。
　

　空間的再利用性を高めるにはドメインコンテキストからの独立性が重要になります。クレジットカードのオーソリは世の中で共有されているルールなので個別ドメインの事情からは独立します。そのため使い回しが可能です。あるいは特定のドメイン（ある業界／あるグループ）に特化し、その下のサブドメイン（ある企業）に適用することもよいでしょう。
　ただし、コンテキストの独立性が維持されない場合は再利用はうまくいきません。一般的にビジネスロジックの再利用性を確保することは非常に難しいのは、同じ企業は2つないという単純な理由です。

　一報で時間的再利用性が高めるためにはやや異なる視点が必要になると思われます。
　例えばSalesforce.comでは自動アップグレードが提供されており、新しい機能が追加された場合でも、古い機能を利用するスクリプトやコードの実行は保証されます。これは時間的再利用性が高い状態と言えます。
　内部的な仕掛けはシンプルで、スクリプトの実行エンジンを世代別に管理しており、実行時に切り替えているだけです。この方法が永遠に有効とは言いませんが、Apexは既にバージョン18になっており、これまで問題なく動作しているのは評価に値するでしょう。
　同じような事例としてはEclipseを上げることができます。急成長をし続けていますが、過去のサードパーティ製プラグインがかなりの確率で動くのはすばらしいと思います（動かないのも、ちょっと直せば動くとか）。

　過去、EJBなどの言われていた「コンポーネントの再利用」は空間的なものを指していました。これがうまくいくためにはコンテキストの固定が必要であり、実際、そのようにしたものは成功したと思っています（サントリーグループ内とか、一部の業界団体主導で行なわれた標準化）。

　現在では時間的再利用性のほうが興味を集めていると思います。他人のコンポーネントを使って早く作るよりも、自分なりのコンポーネントを長く使いたい。ユーザーニーズの変化から再利用に対する捉え方も変わってきていると感じます。

　僕が最近強く感じてるのは、

ユーザー・ニーズは「新規開発の生産性」から「追加開発を伴う運用保守性」に移ってきている。

　という変化です。これは変えられない流れ。それは、なぜか。

背景にあるのは近年の経済状況だ。この不況下では情報システムをなるべく長期間使うことが必要になるが，ビジネス環境の変化は大きく，システム変更を免れない。できる限り再構築を避けながら，システムの改善を繰り返していくことが求められる。

　「運用保守性」を高めるにアーキテクチャの観点は非常に重要です。この例として挙げられるのがクラウド・コンピューティングです。

クラウド上にアプリケーションを追加しても，データ量やユーザー数などが増えたとしても，基本的には問題なくサービスを拡張できる。

　その理由というのが、

ただし，現状のクラウド コンピューティングはアーキテクチャにかかわる制約が多い。例えば，オンプレミスのシステムとの連携，処理時間（Google App Engineでは30秒以内）ユーザー，インタフェースの開発（Force.comでは専用ツールが推奨される）制約として挙げられる。

　つまり、アーキテクチャに一定の制約を課すことで、拡張性を担保しているわけですね。一方で、オンプレミスを考えてみると

クラウドのような拡張性を担保することは難しいので，（機能などを）「追加」していくのではなく，既存のものを「変更」していくことが求められる。その場合に重要なのは変化の影響を限定することで，言い古された言葉になるが「モジュール化」の徹底を図るのが効果的だと思う。

　ただし、これを「徹底」するのが大変です。そもそもオブジェクト指向だってEJBだってモジュール化は大事なテーマでした。しかし、モジュール化を実現するための枠組みが設計思想でしかなかった。そこでOSGiのようなモジュール間での境界制御を可能にする技術が重要になります。その代わりOSGiも制約（バンドルにしないとリリースできないとか）があります。

　このように「新しいアーキテクチャを活用する」＝「既存とは異なる制約を受け入れる」ことで、顧客にとってはこれまでにない価値を提供できるようになるのです。これまでの制約や所与を変えることなく都合良く得られるものを変えることはできません。特に今の時期は大きな変化の変わり目だと感じています。

システムを作ることが難しかった時代は開発生産を高めていれば対価を得ることができた。しかし，その時代は終わろうとしている。これからは，システムが長期間にわたって顧客に価値をもたらすことを示さなくてはいけない。そのためにはアーキテクチャの視点からシステム開発全体を見直していく必要がある。

　作ることではなく、使ってもらうこと。ここに注目できるか、そのために何を受け入れるべきか。冷静な視点で見るべきだと考えています。

2010年2月18日（木）　10:00-
【18-B-1】クラウドがもたらすパラダイムシフトとデベロッパーへのインパクト by 栗原潔さん
　クリキヨさんのクラウド総括。4大クラウド（Google, Amazon, Saleforce.com, Microsoft）の戦略分析と、今後のクラウド時代におけるデベロッパーとしての心構えについて鋭い論考を展開してくれるはずです。

2010年2月18日（木）　10:00-
【18-E-1】SIerのこれからのソフトウェアを創る by papandaさん（市谷聡啓）
　DevLOVEでおなじみのpapandaさんの講演。TISというSIerにあって積極的にコミュニティ活動を続けるのはなぜか、何処に行こうとしているのか。その未来に何が見えているのか、熱い講演になるはず！

2010年2月18日（木）　11:10-
【18-B-2】“クラウド”をビジネスにしませんか？ 〜 Force.comのテクノロジーとビジネスモデル 〜 by 岡本充洋
　セールスフォース岡本さんの講演。テクノロジーカットではなくて、まさにビジネスとしてクラウド（Force.com）をどう利用するのか、どう顧客に提供するのかについて。クリキヨさんの講演もですが、"クラウドの技術"だけではなくて"クラウド上のビジネス"に興味がある方は必見です。

2010年2月18日（木）　13:10-
【18-B-3】Google 的分散コンピューティング by Gregor Hohpe
　EIP（Enteprirse Integration Patterns）、「スターバックスはツーフェーズコミットしない」でおなじみ、GoogleのHohpeさんの講演。Googleの様々なインフラ技術のアーキテクチャを分析し、共通する設計テーマやパターンを抽出してくれます。ITアーキテクト必見。

2010年2月18日（木）　14:20-
【18-B-4】アピリオ（まだ名前はでていませんが、決定しています）
　世界最高峰のクラウドインテグレーター、アピリオさんがついに講演に出てくれることになりました。ホントにデブサミぐらいでしか聞けません。セールスフォース上の国内案件で、あんなもの、そんなもの、全部が彼らの仕事です。最高峰のエンジニアがクラウド上で何を感じ、どんな未来を創ろうとしているのか。僕自身も非常に楽しみな講演です。

2010年2月18日（木）　14:20-
【18-C-4】ドッグフーディングとアジャイル開発 by 大澤俊介
　もはや定番になりつつあるタスク管理ツール「JIRA」や企業Wiki「Confluence」で有名なアトラシアン自身によるの国内初講演。最近ではTEDでダニエル・ピンクが絶賛するなど、企業スタイルとしても評価の高い会社。そこではどんなことが行なわれているのか、なにを作ろうとしているのか。現場から話をしてもらえます。

2010年2月18日（木）　17:40-
【18-C-7】アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション by 伊藤直也, 江島健太郎, 小野和俊, 鈴木雄介
　江島さんを迎え、97本の日本人著者若手チーム集合のイベントになります。全員、なんらかのアーキテクチャに憧れて、何かを生み出そうとしているのではないか。彼らの目には何が見えていて、何を作りたいのか。そこを語ってもらおうと思います。

2010年2月19日（金）　10:00-
【19-C-1】これからのアーキテクチャを見通す by 鈴木雄介
　手前味噌です。企業システムのアーキテクチャへの課題はなにか、過去にどんなトライが行なわれてきたの、これからどうなっていくのか。なるべく中立的な視点から話をしますね。

2010年2月19日（金）　13:10-
【19-C-3】成長できるエンタープライズシステムを目指して- OSGiによるモジュール型アーキテクチャの実現 by kompiro（近藤寛喜）
　個人的なパワープッシュである「OSGi」についてこんぴろさんに入門から可能性までを話してもらいます。OSGiってなに？何がメリットなの？という方に聞いてもらいたいです。

2010年2月19日（金）　16:35-
【19-C-6】VMware
　（以下の情報は予定です）SpringSourceを買収したVMware。何を考え、どのようなクラウド戦略を立てているのか。VMwareの視点から語られるはずです。

申し込みはデブサミ2010のサイトから

　さて年末から年明けにかけて、いわゆるゼロ年代論（2000年から2009年の総括）と"これからの10年"についての議論が活発になっているようです。ゼロ年代は目の前のことに必死だったように思いますが、これからの10年は変化をじっくりと感じる時期になる気がします。それとともにITが変化を迎えるべき10年ともいえるでしょう。

　先日、"場の理論"で有名な東京大学名誉教授の清水博先生にお会いする機会がありました。その中でITについていくつかの話をさせて頂きました。

　清水先生に会うキッカケはデブサミ2010と併設されるPM Conference 2010（有料）です。基調講演にお招きするのですが、それを知って主催者側に連絡したところ、事前の打ち合わせに参加させていただく事が出来ました。以前から本などを通じて存じ上げていたので非常にうれしい出会いでした。

　"場の理論"の細かい説明は省きますが、"場"という現象によって生命や社会や組織を捉えなおす考え方です（哲学と言うほうがいいかな）。清水先生は78歳、野中郁次郎や松岡正剛が影響を受けたといえば凄さが伝わるでしょうか（松岡正剛によるすばらしいレビュー）。

　"場"は"形”です。それぞれの現場に最適な"場"がある。そのため"場の理論"は"場"を作り上げるための"型"として機能します。良い"場"に必要なものは、1.全体性、2.関係性、3.ドラマ性の3つ（以下の説明には僕の解釈が含まれるのが、正しくは後述の原典を見てくださいね）。

　全体性ですが、場というのは"境界"を持つ1つの塊として認識されなくてはいけません。ただし、その境界は"里山"的、つまり里山が部落と自然の緩衝地帯として機能するように、内と外を緩やかに分離し、かつ繋げるものです。先生は即興劇に喩えますが、そこにおける観客と役者のような関係。舞台は全体性を持ちますが、観客とは緩やかに繋がっています。

　次が関係性。舞台の上にいる役者同士が個々の個性を残したまま、互いに関わり合い、関係を築き、それによって創出されてくるものがある。

　最後がドラマ性。劇は進みますが、その方向性をドラマとして表現する。ビジョンや理念に近いモノですが、より動的な表現としてドラマという言葉を使われています。

　この"場の理論"も時代と共に変化しています。現在、世界は資本主義や金融主義のグローバリズムが限界を迎え、持続可能な社会への大きな転換が起きています。

　清水先生はグローバル化によって全体が見通せなくなっており、"場"に全体性を見いだすことが難しくなっていると言われていました。だからこそ、より身近な"関係性"が重要であり、そこにITがやるべきことがあると。

　一方で、ノイズ工学という言葉で進みすぎたデジタル化の問題を指摘されています。あまりにクリアなモノは、人と物の"境界"をモノ側が規定してしまう。そうなってしまうと、"境界"の豊かさが失われて、人との関わり合いが苦しくなってしまう。ハイビジョンテレビとブラウン管、デジカメと銀塩写真、プラスチックの眼鏡とガラスの眼鏡。境界に良いノイズが含まれていることで、そこに関わる人が豊かさを見いだしうるのではないか。ITにも、デジタルの対称としてのアナログな感覚を取り入られれないものか。

　お話しさせて頂いたことをまとめると「豊かな関係性の創出に対してITにできることがある」ただし、「境界がクリアすぎては豊かさが失われる」ということになります。

　このテーマは、まさにこれからの10年でITが解いていくべきものでしょう。もはやインターネットなしで我々の生活が成り立ちません。新しい関係性の創出にITは大きな影響を与えましたが、それが豊かな関係であったかと言えば、それだけではなかったはずです。

　最近、Googleと中国政府が難しい関係にありますが、そこで行なわれている議論の本質は上記のようなことです。ビジネス上の観点からすれば中国市場を放棄するのはあり得ない。しかし、情報の民主主義を掲げるGoogleからすれば許されないことがあったわけです。もちろん、Googleにも商業主義的な側面は多分にありますが、それだけではないという姿勢が初志貫徹されればGoogleが真に持続可能な企業になりうるということなのかもしれません。

　社会に積極的に関わっていけないならITが産業として持続できることもないでしょう。ITが真に持続可能な社会インフラとして機能することができるのか。あえて比べれば電話や電車や電気と肩を並べうるかは、これからの10年で少しでも進むべきトピックスだと思います。

生命を捉えなおす―生きている状態とは何か (中公新書) 中央公論社 1990-10 by G-Tools

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

　僕のポジションですが、SIerに勤務しており、企業システムのアーキテクトで自社のフレームワークやOSSをベースにした開発をしています。ただし、クラウドあたりは一通り触っていますし、中の人含めて色々と話はしている。あと、クラウドという言葉はパブリッククラウドを示していて、ただの仮想化とは区別しています。Google、Amazon、Salesforce.com辺りのこと。

　クラウドが登場したことでSIerが抱える問題が明らかになったと考えています。それはSI的なアプローチで作られる最適化されたソリューションが顧客視点での経済合理性について課題を抱えており、結果として顧客との適正な関係構築を阻害しているということです。

　クラウドの特長を3つ上げると、1."規模の経済性"の実現、2.ITサービスとしての提供、3.従量課金でしょう。

　"規模の経済性"の実現とは、より多くの顧客に同時に同じサービスを提供することです（マルチテナント型、一斉バージョン適用）。このためにプラットフォーム型のカスタマイズを前提としたアーキテクチャを採用最奥しています。全ての顧客に同じプラットフォームを適用し、その上の最適化はユーザー側に判断が任されます。ASPやホスティング/ハウジングは、最初から最適化が前提とされており顧客間は分断されていました。これでは経済性を追求できない。

　ITサービスとしての提供とは、コードからサービスまでの時間が極端に短いことを指します。つまり、クラウドはソフトウェアを早く作る事が目的ではなく、ITサービスを早く提供できるようになるわけです。昔から規模の経済を実現しようという試みは多くありました。EJBで目指したコンポーネント取引市場もそうですし、オープンソースだって似てます。ですが、それらはソフトウェアをいかに作るかが重要だった。だから、エンジニアのための価値だったのです。多くユーザー企業が望んでいたことはITサービスの提供を効率化するでした。

　上記のような特長は従量課金に良く合います。ユーザーは、ITサービスのスケーラビリティについて対価を支払います。本質的にソフトウェアは同時共有ができるものなので従量課金の支払いは馬鹿らしいと思われがちです（違法コピーがなくならない理由）。ですが、ITサービスを提供するのはハードが必要ですし、それを同時共有するのは物理的に不可能です。だから、ITサービスのスケーラビリティが従量課金であるのは当たり前なのです。

　一方で、SIerのやっていることは何でしょうか。要件分析をして最適なソリューションを提案することは悪ではありません。ですが、そこでは規模の経済が働かないことは明らかで、価格は高止まりします。オートクチュールと既製品のどちらも着るというような経済性と品質のバランスについての選択肢をユーザーに与えていないのです。
　また、納品するのはソフトウェアであり、ITサービスではありません。一時期、運用保守サイドに居た自分としては、この違いの大きさには何度も泣かされていました。
　結果として対価の支払い対象が不明瞭になり人月理論に落ちざるをえなくなる。人月の問題は、そのものの問題ではなく取り巻くビジネス環境から規定されていることです。

　クラウドが示したのは、システム開発が作り手の理論ではなく、使い手の理論で経済合理性を持たなくてはいけないということなのです。SI的な最適化されたソリューションは、その特性上、どうしてもユーザー視点の経済合理性が薄くなりがちです。その結果、作り手と使い手の適正な関係が阻害されてしまっています。

　この流れは産業の成熟と捉えて良いでしょう。家内制手工業から大量生産の世界への変化と同じです。SIの「課題分析をして最適なソリューションを開発する」というのは聞こえは良いけど、やはり原始的な産業スタイルであることを自認すべきです。
　すでにクラウドサービスの周りに経済圏が出来つつあることが観測されています。クラウドを前提とし、組み込み機能を活用しつつ、様々なコンポーネント/サービスを組合せ、必要な部分だけを追加して顧客に提供する。デリバリースピード、品質のどれをとってもこれまでは違うシステム開発が実現できます。

　では、現行SIはクラウドサービスに飲み込まれて消えてしまうのか？というと、そういうわけでもないと思います。単純に考えてもオートクチュールとユニクロの間には、たくさんのカテゴリがあって良い。ただし、上記にあげたクラウドの特長そのものは、つまりユーザー視点での経済合理性の確立は重要です。ただ、それを実現する手段がパブリッククラウドだけではないですよね、ということ。ここは頭のひねりどころです。
　アジャイルやリーンだって、その一翼でしょうし、プラットフォーム型のアーキテクチャという意味ではOSGiのようなコンポーネント技術も成熟しつつあります。きちんとした実力があり、顧客側に立てるSIerであれば十分に生き残っていけるのです（そうでないSIerがどうなるかは分かりませんが）。

　何度も書いていますが、システム（ITサービス/ソフトウェア）の価値が重要であること変わりはありません。その価値に対して使い手視点での経済合理性を持ち込めるのかが、僕らの大きな課題と言えるでしょう。

　まず、アットマークITさんの記事、『「外の視点」を導入するソフトウェア開発 － ＠IT自分戦略研究所』。1ページ目はpapandaさん、倉貫さんの講演で、2ページ目に紹介して頂きました。実際に受講して頂いての記事なので、すごく丁寧です。ありがとうございます。

「これまではソフトウェアを作ることだけを考えていればよかった。もちろんソフトウェアを作ることを考えるのは大事だが、ソフトウェアを『使う価値』について考えてみる必要があるのではないか。しかし、ソフトウェアを使う価値は、ソフトウェアを作る立場から見ても分からない。そのため、あえて違う分野からソフトウェアを使う価値について思考し、何か気付きを得てほしい」と、鈴木氏は提案した。

　次にビデオです。えー、色々と反省があるのですがご覧頂ければ幸いです。自分の脳内で言葉を勝手に補正して話をしちゃうから、言葉が飛ぶし、「あれ」だの「それ」だのが多くていかんです。

訂正：ミシェル・フーコーの『監獄の誕生』を「19世紀に発行」と言ってしまっていますが、1975年発行なので20世紀です。心より恥じる。

アーキテクトの一般的なイメージは，「システムを構築する際に使う製品・技術を決める人」であろう。そこでは，技術者としての力量が重要になる。これは確かにアーキテクトの仕事であるが，これだけでは100点満点の50点にも満たない。

　単に新しい技術を知っているとか、使えるだけでは50点です。場合によってはそれ以下。大事なのは技術そのモノではなくて、それを使って何をするのか。それを見抜くためには視点を変える必要があります。

ユーザーにしてみればシステムを作ったら終わりではなく，リリースされてからが始まりである。システムの価値はリリース日に決まるのではなく，そのシステムが使われなくなる日に決まるべきだ。だから，アーキテクトはリリース後まで見越してアーキテクチャを考えなければならない。

　これが出来てきて、はじめてアーキテクトだと言えるでしょう。アーキテクチャ設計とは、

リリース後の不確定な問題に対して，システムが作られてもいない段階でアーキテクチャを決めなければならない，という難しい問題をはらんでいる。

　のです。そのためには「覚悟を持った第三者」である必要があります。まず第三者というのはユーザーからもエンジニアからもPMからも離れ（つまり、ビジネスや技術やQCDからも離れ）

目的，課題，技術などから見て中立的な視点に立って判断するということだ。

　そして、

中立的でいるために，アーキテクトはアーキテクチャの有効性に対する責任をすべて引き受ける覚悟が必要だ。

　そういう覚悟がないと、きっと誰か（顧客かエンジニアかPM）が言ったことに流されてしまい「あなたがこう言ったからそうしたんだ」のような批評家になってしまう。そんなアーキテクチャで変化に適応できるわけがないのです。

　こうしたアーキテクト像を語ると、どうしても強いリーダーシップを感じてしまいがちです。ですが、そんなことはありません。なぜなら

今後，アーキテクトが解決すべき課題はより複雑になる。どんなに知識があっても足らず，利害関係者が増えて決断は難しくなる。中立的な視点が独りよがりになってはいけない。これからは，エンジニアだけでなく，ユーザーも含めた利害関係者からの協力を引き出しながらアーキテクチャを決定する。そうした合意形成力がますます重要になる。

　僕も含め、雑誌で記事やコラムを書くようなアーキテクトは技術的な信念を持ってクライアントを説得していると思われがちです。ですが、そんなことは本当にまれです。ビジネス領域はクライアントが専門家なのだから、僕らが何を言っても価値が示せないなら使わない。作る部分ではエンジニアが専門家なのだから、上から理想論ばかりで指示をしても納得してくれるわけがない。

　そういった専門家集団とコミュニケーションをしながら、どのようにソフトウェアを作り育てるのか。アーキテクトに求められているのは、こうした全体の方向付けなのです。

　覚悟を持った第三者たれ。本当に自分が中立的なのか、覚悟を持っているのか。常に自分に問いかけたい言葉です。全文は雑誌にて。

氏の興味対象は、動的な世界に適したアーキテクチャの構築なんだろうと思う。プロセスや人の活動だけで動的な世界に対抗することもできるが(それがTDDやAgileでのアプローチ)、その先を考えた時に、どうしても静的な思考でしか捉えることのできない’’構造’’を如何に動的な世界に適合させるかということ。

　分かってらっしゃる！という感じなのですが、少しだけ補足説明。

　アジャイルは「動的に変化する世界を捉えるためには、イテレーティブに成果物を出しながらコミュニケーションをしていくべきだ」というコンセプトです。それそのものは僕は大賛成です。

　そもそもアジャイルが重要とされたのは、"構造"に限界があるからです。構造は強く、そして長く残ります。システム開発は構造として機能を表現します。コードは構造そのものです。現在のシステム開発は、現実を切り取った断面しか実装できません。だから時間が経過すると現実との間にギャップが生じてしまいます。だから、アジャイルのようなプロセスでの対応が必須となります。

　しかし、基本的にプロセスというのは構造に比べて脆弱です。具体的には実践者の能力に強く依存しスケールしません。なぜならプロセスの実践ノウハウは形式化しにくく経験を通してしか学ぶことができないからです。だから長期間にわたって安定的に運用することができない。やれるとすれば時間をかけて育てる必要があります。でも、その人が辞めてしまえば最初からやり直しです。

　小さなシステムや再構築できればいい。でも、現在ではソフトウェアが重要視されているからこそ、長期にわたりシステムを使い続ける必要が出てきています。経済環境の変化もありますね。これを実現するような持続可能な開発モデルとか漸進的な開発モデルを実現するのに、プロセスだけで対応するのには無理があるのです。

　そこで懸田さんが書いている「’構造’’を如何に動的な世界に適合させるか」という挑戦が必要です。Kentが喩えるように、ハンドルを細かく動かすのがアジャイルだとしたら、その制御に安全/安定に応えられる制御構造がアーキテクチャです。ちょっと急にハンドル切ったぐらいで車がひっくり返らないようにするのです。

いわゆる「テストしやすいフレームワーク」があるとしたら、それはダイナミックなプロセス、漸進的な成長を支援する構造といえる。しかし、もし漸進的成長を、アーキテクチャ側で面倒を見るとしたら？ 変化に適応できる構造は、テストしやすい だけではないということが言えるのだろう。

　短期的に注目されているのはコンポーネント指向開発です。プラットフォーム（環境）を構築し、その上にコンポーネント（モジュール/プラグイン）を足していく開発モデル。この場合、テストはコンポーネント単位で行えばいいことになります。プラットフォームはコンポーネント間の齟齬を解消し、安全性を提供します。

　アーキテクチャが脆弱だと仕様変更が発生した場合にシステムのあちこちに同時に手を入れる必要性が出てきます。これは調停が非常に難しい問題になりがちです。つまり、変化の影響範囲が制御できない。こうなってしまうと安全に複数のチームを並列に走らせることができません。結局、中央のチームが全体を調整する必要が出てしまう。それがボトルネックになるとアジャイルのメリットが失われてしまいます。結局は、ウォーターフォールのように慎重な計画が必要になるのです。

　では、どうするか。例えばOSGiではバージョンも含めてコンポーネント間の依存関係が明示されます。そのため依存先のコンポーネントがバージョンアップしても、それを無視することができます。これは変化の影響を限定的にするためには非常に重要なことです。イテレーションが進んでコンポーネントのバージョンが上がったとしても、そのバージョンに依存するところだけ変更すればいいのです。これはEclipseで既に実現されて効果を上げています。

　また、依存性が解決されない場合でも動き続けることができます。今日のOSGi勉強会で出ていた例は「ログサービスに依存はするけど、見つからなければそれはそれで動くようにする。ログを出さなければいい」というような振る舞いをさせることができます。環境に適応してコンポーネントが動作を変えるです。

　ココまで読んでコンポーネント指向開発って色々と無理があるのでは？と思ったあなたは正常です。課題は多いのです。分割方針とワイヤリング手法。前者はShared Databaseパターンからの脱却であり、後者はイベントドリブンアーキテクチャへの挑戦です。あと、複数のコンポーネントをまたがる場合に動的に現れてくる機能をどうテストするか、とか。いずれもSOAとよく似た話です。

@yusuke_arclamp氏は、もっと先のコンセプトを出しているが、この領域はまだまだ発展段階だし、可能性が多く残されているといえる。

　僕がもっと先のコンセプトとして提示しているのが「ソフトウェアに身体性を持たせる」ということです。現在のオブジェクト指向開発の限界は、それが人間の"認識"に強く依存することです。認識は断片的で一時的なものです。その認識に従ってシステムを作っても現実は変化してしまう。であれば、人間が認識したオブジェクトに頼ってシステムを作るのではなく、オブジェクトを取り出す前の環境そのもの（アフォーダンスで言えばサーフェイスのレイアウト）とソフトウェアが直接的にインタラクションすればいい。つまり、ソフトウェアが自律的に学ぶのです。これを完全に実現するのは100年先かもしれませんが、擬似的に実践しようという動きはいろいろと出てきています。上に書いた、コンポーネントが他サービスの状況に応じて動きを変えるというのも1つの方法です。

　そもそも、ぼくらは動きを動きそのものとして捉えることができません。例えば扉の開き方を直接デザインすることはできません。それは扉の構造を通じて行う。例えば時間の経過は構造がもたらす状態変化によってしか感じられません。時計の針が進むから時間を感じるわけで、時間そのものの直接感じることは出来ない。すべてのものが停止した世界は「時間が止まっている」のです。

　動的な世界というのは、実は静的な構造の状態変化なのです。ソフトウェアは「静的な構造の状態変化」というのを比較的記述しやすい。だから、まだまだ可能性は色々とあると思うのです。

　今回の目玉は、QCon London 2009でOSGiセッションのスピーカーを務めたNeil Bartlettさんの講演です。観光旅行のついでに寄ってもらいます！

申し込みはこちらから

　近年、OSGiがキーテクノロジーだと言われてきました。EclipseやJavaEEアプリケーションサーバでは既にOSGiが導入されています。これらの製品ではOSGiが導入されたことにより、運用性の向上、モジュールアーキテクチャ、システムの柔軟性、可用性を導入できました。

　では、これらの利点を業務アプリケーションに生かすには、どうしたらよいでしょうか？

　この勉強会はQCon London 2009でOSGiセッションのスピーカーを務めたNeil Bartlett氏の来日にあわせて開催します。観光旅行でしたが、国内でのOSGiへの取り組みをお話ししたところ、喜んで話をしたいとおっしゃってくださり、この機会を作ることができました。Neilさんからは「OSGi入門」を紹介します（簡易な英語ですが、通訳もします）。

コンテンツ（調整中）
17:00-17:30　XX　「XXX」
17:30-18:00　IBM須江さん　「WAS7.0におけるOSGi」
18:10- 19:15　Neilさん　「OSGi入門」
19:15-20:00　全員　「ディスカッション」
懇親会へ移動

　ぜひご参加ください。

== Neil氏の紹介 ==
　家電組み込みや、Eclipseのようなプラグイン機構以外のアプリケーションに組み込み始めたエンタープライズOSGiの黎明期に、OSGiの技術的な入門記事を書いたのは彼が一番初めかもしれません。
Neil’s point-free blog

　Neilさんの書いた文章はとてもわかりやすく、QCon London 2009でも"アプリケーション開発者のためのJavaのモジュール化とOSGi（原題:Java Modularity and OSGi for Application Developers）というタイトルでスピーカーを務められました
[リンク]ブログでの自己紹介
[リンク]QCon London 2009での講演者情報

日時：2009年12月23日　17:00-20:00（後に懇親会あり）
開催場所：IBM渋谷
参加費：無料
定員：50人(先着順)
企画／主催：
　kompiro　チェンジビジョン
　kawamura　OSSCRM
　yusuke　グロースエクスパートナーズ／アークランプ

申し込みはこちらから

　このセッションはpapandaさんに依頼されて考えたものです。システム開発ではない業界から、僕らの業界を見ることで学べることはあるのでは、というコンセプトです。ただし、リアリティのない話でもしょうがないので、聞いた時になるべく体感できるようなネタを選びました。4つの話をしたのですが、僕なりには「身体性と環境との相互作用」というのが共通テーマになっています。

　また、セッションの後にダイアローグの時間が取られていて、聞いてくださった皆さんでチームに分かれて会話と共有がありました。僕の講演は他業界の話題ですから、システム開発に引き寄せる前に消化不良になってしまう部分もあるかなと思っていたのですが、ダイアローグがあることで「皆さんと話をして理解が進んだ」という言葉が聞こえて良かったです。というわけで、ダイアローグで頂いたフィードバックもいれこみながらエントリしていきます。

ランドスケープ・アーキテクチャ
　定義はwikipediaを見て頂くとして、僕らが日常的に見るのはビルのすき間に立つような植栽です。つまり、人工的に植物を植える仕事。木を植えるというのはビルを立てるのとは違う面があります。それは時間的/空間的な環境変化を考えると言うことです。木が育つためには土や太陽や水が必要で、それらすべてがなければ木は育つことができません。しかも、樹齢20年の木を植えるなら、20年前からソコに木があったような環境にしないといけない。こうしたことを考えながらビルのすき間ある木を見ていると、それを成り立たせるための環境があることに気づけます。

　システム開発でも、システムは周りの環境に影響を受けながら育っていきます。データの増加、仕様の変更、あるいは外的要因としてユーザー組織の変更や連携先システムの仕様変更。これらの環境変化を考えることがシステム開発では重要といえるのではないでしょうか。

　ダイアローグでは、システムが時間とともに変化するということに共感していただき「引き継ぎ」「過去の流れを未来につなげる」「設計の賞味期限」「制約」といったキーワードが出ていました。

ビルディングタイプ
　ビルディングタイプとは、建築物の中でもステレオタイプがあるようなもので学校、病院、刑務所、工場などがあげられます。どの病院にいっても、まぁ、病院らしいということ。つまり、各建物の様式に注目するのではなく、その建物の形を成り立たせている法律や規則などに注目すると言うことです。今回は刑務所の例を挙げましたが、パノプティコンからペンシルバニアシステム、資料にはないですがオーバーンシステムといった変遷を見ると、歴史上の要請から形が生まれていることが分かります。

建築の即物的な力を借りて、はじめて制度は成り立っていると言える

という山本理顕さんの言葉があるように、近代社会というのは規則をビルディングタイプにすることで無理矢理に人を規律化させているとも言えるのです。

　同じようにシステムも即物的に制度を成り立たせるために作られているといえるでしょう。

　ダイアローグでは、「制約が形を生み出す」「とはいえ縛られすぎない」といったことが共有されていました。

包囲光（アフォーダンス）
　アフォーダンス理論を理解する上で重要なのが包囲光という概念です。人はモノを見ているのではなく、環境の表面にあるレイアウトを見ている。光の光線はレイアウトの肌理に反射しながら全方向であらゆる場所に存在します。つまり目を包囲するように光が満ちているのです（本当は空気の話とかも必要なんだけど）。そして、その光からレイアウトのエッジを見つけモノを"認識”します。同じレイアウトが見えていても、同じモノが見えるとは限らない。

　これはオブジェクト指向でも同じことです。同じ情報が与えられても同じオブジェクトが認識できるとは限らない、経験がないドメインに参加すると何も認識できない、一度認識できてしまうとそこから離れるのは大変なわけです。一方で、世界は常に変化してしまう。オブジェクト指向の根本的な難しさは人間の認識に頼っている点で、その認識が優れているかどうかで設計の質に大きな影響が出てしまいます。

　ダイアローグでは「パターンを業界を横断して転用するのが難しい」「チームでも役割によって見えるものが違う」といったことが言われていましたね。

認知発達ロボティクス
　もうこれはビデオを見てください。エントリも書いています（身体の情報構造@デブサミDAY2）。このロボットは身体があることで、直接的に環境と相互作用しダイナミックな動きを手に入れています。

　前述のようにシステム開発は人の認識に左右されてしまう。それではシステムが自律的に環境の変化に適応することはできません。であれば、システム自身が身体を持ち、直接的に環境と相互作用しダイナミックな動きを手に入れることができるのではないかと考えています。もちろん、夢の話です。

　ダイアローグではソフトウェアが進化することから「ソフトウェアに死はあるのか」「データは死なないからこそ、過去の遺物を引きずるのでは」「相互作用は実はあらゆるところに現れる」などが議論されていたようです。

　いずれの話もシステム開発が閉じた系だけで完結せずに、その周りにある環境と良し悪しではなく関わる必要があることを示しているつもりです。だって、世界はそのようにして成り立っているのですから。

　個人的な謝辞はデブサミですね。ランドスケープはデブサミ2008のベストスピーカー石川初さんから、ビルディングタイプはデブサミ2007でMS萩原さんとセッションをした大川信行さんから、認知発達ロボティクスは突撃オファーに応じていただきデブサミ2008に来ていただいた國吉康夫教授から、それぞれ学んだことです。僕のわけわからん講演案を快く実現してくれた岩切さんに感謝。アフォーダンスも講演してもらいたいのだけど再来年かなぁ。

　それから、こういった場を用意してくれたpapandaさんにも感謝。純粋に自分が興味を持っているものと、そこからの思考の連鎖を表現することができました。この数年で学んだことを振り返る良い機会になったよ。ありがとう。

※上記サイトからの直接リンク

　これは単にデザイナが持続可能なプロダクトを作るという話ではありません。デザイナとしてトレーニングを受けた人々が新しい社会のあり方を生み出すための過程に関わることで、よりよい成果を生み出そうという試みです。

　まずは実例ですが、ミラノで行われているco-hausingという取り組み（サイト）。co-hausingというのは、20-30ぐらいの世帯が様々なサービスを共有しながら共同に暮らしていくという住まい方の形態です。洗濯機や大工道具の共有なんかが分かりやすい例で、僕が思うには長屋。

　非常に面白いのは、新しいco-hausingの場所を生み出し、そこに人々が暮らすことまでをデザイナがファシリテートしていく過程です。「co-hausingは、そこに住む人々が創り出すもの」という理念があるため、まだ場所も何も決まっていないうちから募集を始め、デザイナ達が人々の要望を聞いたり、実際のミーティングをファシリテートしたりして場所や住まい方を決めることを支援していく。実に1年半にも及ぶプロジェクト。もちろんco-hausingで実際に使われる製品をデザインしたりすることもしますが、それはほんの一部。デザイナとして訓練された様々なスキルを活かして持続可能な住まい方を生み出す手伝いをする。

　教授はそういったデザイナの仕事を『ビジョンをしめし、クオリティをあたえ、その可能性自体を具体化させること』と定義しています。『人々（一般市民/消費者）は意図せずにデザイン行為をしている。そのデザイン行為を助けることこそが、デザイナの役割である』というわけ。

　そうしたデザイナの道具としてあげらていたのが、協業のきっかけとなる「フォトシナリオ」や「デザインカード」といったもの。

　フォトシナリオは、実際のユーザーをリサーチしてから、ペルソナを作ってフェイクのシナリオを書き、それに従って写真を撮るというモノ。実際に「毎週、有機野菜をネットを注文して、たまにその畑に行き、農家を手伝ったりして、一緒に食事をする」というフォトシナリオを見せてもらいましたが、とても力強く魅力的でした。

　デザインカードはIDEOで使われているモノが有名ですが、あれの応用版。例えばco-hausingでは、40種類のデザインカードを作り、人々が何を望んでいるかを引き出し、互いの会話のきっかけを生み出すために使っていたそうです。

　そして、教授が「DESISプロジェクトの中でも、最もカギとなりえるもの」として紹介していたのがデジタルプラットフォームでした。『これまでのデジタルプラットフォームは、デジタルで関係が完結していた。その関係を現実世界に出現させることができるんだ』として、いくつかのソーシャルネットワークのサイトを紹介していました。

PledgeBank
「I’ll do it, but only if you’ll help」。個人がPledge（誓約、公約）をすると、それに賛同する人が集まって物事が成功するといったことを支援するサイト。

Activmob
いわゆるスマートモブス。カルチャークラブ的なものから海岸の掃除とか、様々なモブのマッチングサイト

TimeBanks
Time Dolla。誰かを助けるために時間を使うと、その報酬が時間ドルとして銀行に貯まり、その仮想通貨で取引ができる。コミュニティ通貨。

　この話は非常に勇気をもらいました。僕らソフトウェアエンジニアだって、社会改革や持続可能性のためのデザイン過程に参加できるって事ですからね。教授は『デジタルなソーシャルネットワークが、人々をつなぐ。そこからムーブメントが生まれ、社会を変えていく可能性がある』と何度も繰り返されていました。

　僕は企業システムに関わっています。だからお金を払ってくれる顧客のためにシステムを作る。それはとても大事なことだし、間違いではありません。でも、僕自身は、その先にいるユーザーを通じて社会をより豊かにすることにコミットしたいと思っています。残念ながら情報システムだけがあっても人々を豊かにすることは難しい。でも、可能性がある。情報システムが人々をつなぎ、コラボレーションさせることで、豊かな社会に向けた変革を助けることができるのです。その意思は持ち続けたい。

　97本で「コミュニケーションの総体をデザインせよ」と書きました。情報システムはコミュニケーションの道具なのです。道具の出来が良いことは大事です。でも、その道具をどういったコミュニケーションに使うのかを考えておかないと出来の良さは自己満足に終わります。
　
　これは企業システムを作っていようが公開サイトを作っていようが同じことです。繰り返しますが、大事なのは情報システムが直接的に何かをできるわけではないということ。情報システムに関わる人に求められるのは、そういう意思を持った人々（ユーザー）を支援し、そのプロセス全体をデザインすることなのです。

場所：
グロースエクスパートナーズ（株）　応接会議室
〒102-0083 東京都千代田区麹町4-5-20 KSビル3階
地図はこちら

時間：
19時～

内容：
OSGi関連ならなんでも、いろいろと。

発表者（予定）：
kompiroさん（チェンジビジョン）　Eclipse RCPあたり
須江さん（IBM）　動向あたり
河村さん（OSSCRM）　動向あたり
北條さん（GxP）　Spring DMあたり
yusuke（GxP）　OSGiの可能性あたり

参加したい方：
事前にyusuke _at_ arclamp.jpに連絡をいただけると幸いです。

筆者が流通企業の子会社でシステム運用保守に携わっていたときのことだ。あるとき，POSレジのシステムが停止してしまった。

＜中略＞

そんな中，その流通企業のシステム担当者との定例会が行われた。当然のごとくPOSレジのシステム停止が話題になったのだが，担当者は平然とした様子で「まぁ，顧客が買うなら売るさ。レジが止まろうが『申し訳ございません，お帰りください』とは言わないしね」と話してから「さぁ，自分たちの仕事をしよう」と続けた。

＜中略＞

筆者はその担当者の言った「システムが止まっても業務は継続できる」ということに衝撃を受けていた。それまでITエンジニアとして「システムがなければ業務は継続できない」ことを一種のプライドのように感じていたし，そのために止まらないシステムを作り，システムを止めないように運用を担当してきた。しかし，実際はそうではなかった。

　もちろん、止まってはいけないシステムはあります。ですが、

止まらないことが目的になってしまうことで，システムに対する適切な評価ができていないと感じることがある。

　これを防ぐためにはどうしたらいいいかを顧客（ユーザーの顧客），ユーザー，開発者という三つの視点で考えてみています。簡単に書くと、以下のような感じ。

・顧客の視点：システムそのものの品質ではなく、顧客へのサービス品質を見ているか

・ユーザーの視点：システムを止めないことへの投資が，システムを利用して得られる価値を超えてないか

・開発者の視点：どの程度止まらないシステムにするのかを指標化できているか

　基本的にはリスクマネジメントですが、その置いている視点に問題がないかをチェックする必要があるわけです。

　さて、この連載は27回も書いてきたのですが、2010年3月号を持って終了することになりました。あと3回、まとめてとして悔いのない記事を書くつもりです。

　六本木ヒルズで開催されている第14回 SFC Open Research Forum 2009（ORF）に行ってきました。お目当ては「創造するアーキテクチャ2」。かなりガツンと来たのでエントリ。

　「創造するアーキテクチャ2」は第7回アーバンコンピューティングシンポジウムの続きで、メンバーは中西泰人さん、木原民雄さん、江渡浩一郎さん、濱野智史さん。会場がゆるやかに開かれた場所だったのもあってか居酒屋ノリのgdgdっぷりにはどうかと思いましたが、すごい〆が良かったので許す（何様）。

　このセッションでの僕の気づきは、アーキテクチャには"無意識のアーキテクチャ"と"意識のアーキテクチャ"があるということです。

　先に言っておきますが、話している当人達もアーキテクチャの定義を共有しきれおらず、議論がかみ合っていない部分があったように思います。だから、ここに書かれている通りのことが話されたわけではありません。事実が知りたい方はアーカイブかなんかを見て下さい。

　さて、濱野さんの提示するアーキテクチャ論は「多様な価値観を持った人々に対して、単一のインフラとして機能するアーキテクチャ（主に情報システム）を通じて、自動実行的に社会を動かすべきではないか」というものです。自動実行といってもプログラミングされた通りに人々が動くようなツマンナイ話ではありません。

　例えばニコニコ動画はインフラとして機能してます。その上で作られるコンテンツについての規定は非常に少ない。著作権侵害については「権利者に削除権を渡して、自由に消させる」という仕組みだけを用意することで解決をしています。こうしたアーキテクチャはユーザーの行動に一種の方向性を与えます（ある種のギリギリを楽しむ動画が出現することも含めて）。

　この"インフラとして機能するアーキテクチャ"というのを突き詰めたのが、（都市伝説だけど）「マクドナルドは椅子の堅さと温度で回転率を調整してる」というような人々の無意識に働きかけるアーキテクチャの存在です。

　マクドナルドの例を初めて、こうしたアーキテクチャ論は無意識の統制や管理社会を連想しがちです。しかし、ポジティブに捉えなおせば「普通の人がやりたくないようなこと、放っておいたらダメダメになってしまうようなことでも社会的に実現できる可能性がある」と言えます。

　例えばベーシックインカム。ベーシックインカムを簡潔に言うと「死なない程度のお金を毎月あげるから、将来の保証とかは一切なしね」という考え方です。ところが、このお金を生きるためではなくて娯楽に使ってしまうダメダメな人が出てくるかもしれない。であれば、電子マネー化して食料品にしか利用できないようにしてしまう。そうすればベーシックインカムが正常に機能する可能性があるのではないか（他にも東さんの民主主義2.0とか、仮想キャラクターによる政治とか、いろいろ例は出ていました）。

　ところが、こうした"無意識のアーキテクチャ"にはアーキテクチャのルールが分かった瞬間から悪意との戦いが始まるという宿命があります。前述のベーシックインカムの電子マネー化であれば、おそらく食料というカテゴリを通じて何か裏をかく人がでてくる。

　江渡さんは「Googleの20%ルールを裏返せば、80%はスパムとの戦いという作業」と指摘したうえで「誰が、それをやりたがるのか」という疑問を投げかけています。ある種の正義感や責任感が機能する可能性はあるものの、明確なロジックを組み立てることはできないでしょう。

　というわけで、「"無意識のアーキテクチャ"というのは存在するし、それは現実社会でも有効に機能する可能性はあるけど、実際やるとなるとスパム対策が大変すぎて本当にやれるの？」というところで話がぐるぐるというのが前半。

　そこで濱野さんが投げかけた「メディアアートって、この状況でなにができるの？」という質問が話を展開させます。中西さん、木原さん、江渡さんというのはメディアアートの人です（本当に不勉強で申し訳ないのですが、僕は江渡さんの『インターネット物理モデル』ぐらいしか知らないです...）。濱野さんは確信犯的にメディアアートの視点から3人を煽ることで対立軸を作りだしたのですが、これが大正解。

　3人の話を僕なりに解釈すると「メディアアートとは、個人に対して身体感覚に落とし込んだレベルで問いかけを行い、意識の変容を招くもの」となります。「人の意識に作用しないものはメディアアートではない」とも断じていました。話の中ではコーチングやファシリテーションが出ていましたが、ああいった手法も同じです。個人との対話（←これ身体的体験）を通じて、意識の変容を招く。

　この後、時間切れで次回持ち越しになるのですが、僕なりに思考を進めてみます。

　少し卑近な例を。iPhoneの入力でフリック入力というのがあります。これ、できるようになると入力が非常に早くなります。どのくらいかというと、このぐらいまでできる。

　使えるようになると便利でしょうがない。こんな風にAppleの製品では手に取った瞬間はよく分からないんだけど、使っているうちに日常になってしまうというデザインが多い。これは人の適応能力をうまく利用しています。

　「それって人を選ぶだろう」って思いますか？確かに使える人と使えない人が出てくる。じゃ、30年後は？きっと、若い人はフリックを一瞬でマスターします。そういう人が大人になれば必然的に多くの人がフリックを使うようになる。意識の変容は個人にしか影響を与えないし、場合によっては刺激にしかならない。でも、それが日常に落ち込んだ瞬間から積み重ねられた歴史になるのです。

　このように意識を進化されるのが本来のデザインであり、メディアアートであり、僕が思う"意識のアーキテクチャ"です。

　"無意識のアーキテクチャ"の問題は自律的には持続できない点です。

　"無意識のアーキテクチャ"は、観察されたパラメタからルールを作り出します。だから、そのルールを悪用するスパムに対してフォロワーにならざるを得ない。PageRankなんて、まさにそう。ルールが顕在した瞬間にユーザーが変化してしまう。これに対応するには正義のガーディアン（守護者）が必要になってしまいます。そして、その正義は誰のモノかという議論が起きる。

　そして、結局は"無意識のアーキテクチャ"も格差を生む。スパムとは言わないまでも、ルールを旨く利用して成長できる人と無意識のまま流してしまう人。しかもルールは変化し続けるから、成長できる人も学び続けなくてはならない。

　一方、"意識のアーキテクチャ"は人の認識や身体は変容できるという前提に立ちます。そして、意識の変容を通じて日常に埋め込まされていきます。だから、変化に強い。一度得られた視点は、たとえ社会が変化しても有効に機能します。学び方を学べば、何を学ぶにしても早いと言うわけです。

　変化し続ける多様性に対応できるのは人であってアーキテクチャではありません。アーキテクチャに出来るのは手助けだけ。そうしないと自律的に持続できる仕組みはならないのです。

　もちろん"意識のアーキテクチャ"も、現実世界に埋め込むのは簡単ではありません。個人の意識変容をしていくのは大変な手間です。もっとも重要なのは教育でしょう。でもね、これって当たり前だと思うんですよ。そんな簡単に問題解決するなんてありえない。時間はかかるかもしれないけど、やっぱりきちんと意識を変容させていくしていくしかない。

　それを情報システムが支援することはできます。ただ、たくさんの試行錯誤が必要でしょう。セッションの冒頭で木原さんが「技術が進んでいるのだから、こうやればできるという提案をばんばん出して、どんどんやればいい」と言われていましたが、その通り。ただし"無意識のアーキテクチャ"で作ってしまうのはツマラナイです。もっと未来を見て、可能性を切り開くような"意識のアーキテクチャ"を作っていきたい。

　個人的にはずっとモヤモヤしていた理由がはっきりして、とても勇気づけられました。少なくとも、僕が信じている方向について先を行っている人がいると分かっただけでもうれしかった。江渡さんが言葉を選びながらアートについて語っている所はマジで格好良かったです。

　あー、そうだ。濱野さんが「僕と3人の違いはメディアアート」って言ってたけど、少し違うと思います。たぶん「意識を持ったモノづくりをしているかどうか」です。コンピューターの中であれ構造物を成り立たせるのは大変な苦労です。しかも、それに何かを語らせようと思ったら、かなり強い意思が必要。だから、そういう体験をしているようなソフトウェア・アーキテクトでも建築家でもプロダクトデザイナーでも同じような議論ができると思います。

　最後に振り返って自分のこと。僕の作品と呼べるようなものは、まだ現実世界に埋め込めていません。ただ、来年辺りから少しずつでもやっていけそうな気配がしています。泣き言を言わせていただくとエンタープライズ分野でやろうとするとマジで大変なんです。予算も削られているし。でも、現実に人と人が接するようなところで使えるアーキテクチャを作りたいんですよ。楽しいじゃないですか、みんなの喜ぶ顔が見れるのって。一歩一歩だけど、そこに向けてやれているという感覚はあります。

　「かわいい」という言葉は良く聞くでしょう。それどころが、なんでもかんでも「かわいい」で済まされてしまう。そんな言葉の出現も時代の流れであろうと本書では説きます。

言葉が軽くなっている。

　しかし、それを危機だと煽り立てるわけではありません。

言葉が思考の対象や手段である時代は終わり、言葉の媒介性が「建築」にとって欠かせない時代は過ぎた。言葉は嗅ぎ分けるてゆくものになってくる。ここで必要になってくるのは、言葉に対する感性であり、感性の言葉ということになってくる。言葉に対して、身体が反応する、つまりは、言葉の理解が身体的になってきたのだ、と思う。言葉が頭に留まる、のではなく、言葉が身体を共振する。

　つまり、観念を操り抽象を表現する小難しい言葉から、より言葉が原始的になってきている。その代表が「かわいい」。そんなパラダイムをカワイイパラダイムとして定義しています。

　感性の言葉は、その言葉だけで自立し得ません。何かモノがあって、それを感性の言葉で表現することによって人と共有することが大事です。「アレがかわいい」とすることで初めて成り立つ。それは対象物がかわいいかということではなくて、他人と"かわいいと感じた感性"を共有することに意味がある。だから、かわいいことに論理性は説明は必要がありませんし、明確な定義もいりません。だから、なんでも「かわいい！」になるわけです。

　以前も書きましたが、多様なモノが大量に溢れる現代においてはモノを購買/選択する行為がアイデンティティの獲得に繋がります。モノと離れて自我が存在し得ないとすれば、モノを通じたコミュニケーションが主体となるのはある意味で当然なのかもしれません。モノという明示的な存在が誰にでも手に入るなら、それを見せるのが一番楽。だから、言葉が"自己と対峙したモノへの解釈"ではなく、"モノによって自己を表現するための補助"になっていくとも言えそうです。

　さて、カワイイの対立軸として上げられているのがモダンデザインです。

モダンデザインはこれまで理性による合意形成を前提としたコミュニケーションの上に成り立つデザインであった

モダンデザインの第一原理ともいえる機能と形態との関係。モノの機能性を検討していきながら、モノの形態を追求していく。そこには、絶対的なモノの機能性という指標が厳然としてあって、形態はそこから決まってくる。これが「形態は機能に従う」というモダンデザインのドグマになってきたものだ。

　そこには明確な合理性があります。モダンデザインの代表ともいえる流れるような美しいエアロデザインは流体力学を元に作られています。流体力学に従っていることにカッコイイを感じるのです。これが理性による合意形成です。ところが、

カワイイデザインでは機能から形態へと直線的に移行するものではなく、機能と形態の間に、一旦、「使い手」を想定した感覚共有の場面を描き出して、望ましい形態に収めてゆく。つまり、「使い手」とデザインを通じて、どのように感覚共有が図れるか、を主題化してゆく

となるわけです。モダンデザインでは感性よりも論理が優先されました。でも、カワイイは感性だけなのです。なんとなく、でいいんです。むしろ、その感性を感じられるか。

　では、話をITに引き寄せましょう。

　ご存じのようにITこそ「言葉で観念や抽象を操る」ものであり、「形態を機能に従わせる」ものであり、「理性の合意形成」が大事な産業です。それって、まさにモデリングですね。本書が指摘するような状況が起きているのであれば、日本人はモデリング力がどんどんなくなってくるわけです。

　じゃ、それがダメなのかというと時代の流れであれば逆らってもしかたない。もちろんモデリングは変わらずに重要ですが、お客さんをはじめ、世の動きがそっちにいくなら、ある程度は感性の言葉を受け入れていく"カワイイIT"が考えられないものでしょうか。

　一方でカワイイITを積極的に目指すべきとも感じます。情報システムの利害関係者は増え続けており、ビジネスの状況はどんどん複雑になっている。そんな状況で、今後も"理性の合意形成"を貫くことはできるのでしょうか。もはやツリー構造できれいに戦略マップが引けるような時代ではないのかもしれません。

　であれば、多様性や曖昧さを受け入れてシステムをペットのように育てていく。完璧である必要はないくて、むしろユーザーに使われることで完成していくような、かまってもらえるようなシステム。そのためには理性の合意ではなく、それを超越した「かわいい！」で共感してもらうことが重要ではないか。いや、直球でかわいい必要性は無いんですよ。画面をピンク色にしろとか言っているわけではありません。

　じゃ、カワイイITって何ですかというと、前述の「『使い手』を想定した感覚共有の場面を描き出す」という所に尽きるのでしょう。最近、ずっと書いてますが作り手の視点から離れて、使い手の視点になることです。そして「これって共感できる？」という問いかけをしていけばいいと思います。

　ちなみに感性が重要だからロジカルシンキングがいらないというわけではありません。考える力は重要です。でも、必要以上にロジカルになることもない。世の中、割り切れることだけではありません。最終的にはスペックは明確にしないと実装はできないので、どこかに落とさないといけないのですが、その後の変更は許容すべきでしょう。

　あまり結論めいたこともないですが「カッコイイITからカワイイITへ」なんていう流れはあると思います。常に時代は変化しています。世の中に目を向けて、より世に役立つソフトウェアを創っていきたいものです。

カワイイパラダイムデザイン研究 平凡社 2009-09 by G-Tools