はてなブログへ。いろいろ微妙なところはありますが、なぜか はてな は応援したくなる。
http://arclamp.hatenablog.com/

以下のようなエントリを書いています。

デブサミ2012のオススメ
アーキテクトがプロジェクトマネジメントをしたら
VSUGアーキテクトアカデミー Vol.03

過去コンテンツの扱いは検討しますが、とりあえずは残しておくつもりです。

　アーキテクトの選択対象は静的な構造です。構造は確定すると劣化を始めます。時間軸の変化に適応する幅は小さく、一度選択されたものを変更するのには大きな代償が伴います。

　もちろん、プロジェクトマネージャーもスケジュールや体制を「事前に選択」します。ただし、その選択対象は動的なプロセスです。

　動的なプロセスは時間軸の中で変化に適応することができます。アジャイルなどのイテレーション（繰り返し）を含む開発プロセスは短期的なゴール選択と実績棚卸しによる適応を推奨しています。これは非常に有効な手法です。動的プロセスは事前の選択における過ちを認め、それを事後的に変更させることができます。

　「Good managers do things right（優れたマネージャーは事を正しくする）」という言葉ありますが、プロジェクトマネージャーは事前の選択（予定）と事後的な活動（実績）のズレを把握し、それに対して様々なパラメタを調整して予定通りの状態に戻す作業をしているのです。

　ところが、アーキテクトの選択は対象物が静的な構造なのでアジャイル的に進めることができません。

　PO（Proof of concept/概念実証）やプロトタイプといった「試してみて評価する」という行為は有効です。ただ、POやプロトは未知というリスクを軽減して事前の選択を促すための手段であって、選択した結果としての事後適応を可能にするわけではありません。

　では、こうした状況でアーキテクトはいかに選択をすべきなのでしょうか。

　「ソフトウェアアーキテクトが知るべき97のこと」（オライリージャパン）には、「24：不確定性が潜むという感覚を磨け」というエッセイがあります。

2つの選択肢を目の前に突き出されると、ほとんどの人々は、どちらかを選ぶことが最も大切なことだと考えてしまいます。しかし、ソフトウェアに限らず、設計ではそうではありません。2つの選択肢があるということは、設計の中に不確実確定性が潜んでいると感じなければならないというシグナルなのです。

　著者であるケブリンは「選択できるようになるまで決断を先延ばししろ」と書いています。これは非常に大事なことですが、もちろん、いつまでも先延ばしすることはできません。ぼーっと選択できる日を待っていては手遅れになります。

　ですから、アーキテクトは「そうでしかない決定」をするために、今、できる限りのことをするということが重要になります。

　選択肢があって、そこに迷いがあるということは判断の基準が定まっていないということです。その判断の基準を探すことこそが重要なのです。

　そもそも、優れたアーキテクトは判断そのもの意味を小さくすることができるはずです。どちらのアーキテクチャを選択しても、なんとかする自信はある。でも、それでは「そうでしかない決定」に至ることはできません。

　つまり、今、目の前にある判断基準ではない、なにか、決定に至るためのパラメタを探すのです。それは時間軸や空間軸で考えることができます。

　1年後は？2年後は？3年後は？
　プログラマの視点では？PMの視点では？ユーザーの視点では？運用者の視点では？

　そうやってステークホルダーのビューポイントを拡げていき、判断するための基準を探すのです。想像だけじゃ分からないでしょうから聞きに行きましょう。どうすれば判断基準を引き出すことができるのか戦略を立てましょう。彼ら自身の行動原理はなんでしょうか？

　そうして「そうでしかない決定」に至ることができます。

　どんなに頑張っても「そうでしかない決定」に至れないとしたら、足りないのはきっと覚悟です。その選択に責任を取ること、あるいは未来へのリスクに立ち向かうことができていない。

　その選択は間違っているかもしれない。でも「この選択しかない」と言い切る覚悟が必要です。「それでしかない決定」に至る努力をし続け、最後は直感にも似た僅かな差で選んだ、そこへの覚悟です。

　覚悟がないと「そうでしかない決定」に至るための行動ができないのです。どんな大きさのプロジェクトであれ、アーキテクチャの決定は、そのプロジェクトに関わった多くの人々に影響します。これを背負う覚悟です。

　権限は先に与えられるものではなく、責任を取る覚悟によって生まれてくるものです。覚悟をしていれば誰に向かってでも「これが正しい選択だ/それは間違った選択だ」と言い切れるのです。

　未来は常に不確定です。でも、その中で事前的な選択をするしかない。そこで「そうでしかない決定」に至るのために戦略を練ることが、アーキテクトという職能の本質ではないでしょうか。

　皆さんが良くご存知の通り、ソフトウェアのプロセスは要求＞設計＞実装という形で進みます。各工程で作られた成果物が次の工程に渡ることで、工程がつながっていきます。

　つまり、各工程の作業というのは、前工程のアウトプット（＝自分にとってはインプット）を見ながら、それを次の工程のインプット（＝自分にとってはアウトプット）に変換していくことと言えます。

　要求工程では、顧客へのインタビューがインプットで、要件一覧がアウトプット。
　基本設計工程では、要件一覧がインプットで、基本設計書がアウトプット。
　詳細設計工程では、基本設計書がインプットで、詳細設計書がアウトプット。
　実装工程では、詳細設計書がインプットで、ソースコードがアウトプット。
　
　もちろん、こうした工程は飛ばすことも可能ですが、そうだとしても、なんらかのインプットに基づいてアウトプットを作るということに変わりはありません。

　こうしたインプットやアウトプットは何らかの「形」で作られます。つまり、インプットもアウトプットも第三者が評価可能な静的な構造体として定義されます。そうでないと、次の工程に持っていけないから。要件一覧も、基本設計も、詳細設計も、ソースコードも「静的」です。

　では、優秀なITアーキテクトは、どういう作業をしているのでしょうか？上の図でいう矢印の部分の能力が重要なのでしょうか？変換効率が良くて時間が早いのでしょうか。あるいはアウトプットされるものが正確なのでしょうか。

　もちろん、そうした要素は重要です。ですが、優秀なITアーキテクトが優秀であるのは、成果物に書かれていないことも配慮できるからなのです。それはユーザーや運用やPMや、あるいは他のあらゆるステークホルダーたちが書ききれなかったことへの配慮です。そして、業界の特性やユーザーの未来を鑑み「こう書かれているが、この方が良いのでは」といった逆提案をするのです。

　では、優秀なITアーキテクトは、どうしたこんなことができるのでしょうか？それは、自分仕事を「ただ単にインプットをアウトプットに変換する」こととは捉えていないからです。優秀なITアーキテクトは、インプットを読んだら、それを自分の中で「動かし」、動いたものをいかに実現させるためかを考え、その結果をアウトプットにするのです。

　これを図にしました。先ほどと異なり、インプットからアウトプットは直接結びつかなくなります。静的なものを、一度、動的に考え、そこから静的にしていくのです。

　この時に重要なのが「想像力」と「創造力」です。

　「想像力」というのは、インプットに基づくことで現れる未来の姿、つまりビジョンを考える力です。先ほど書いた通りインプットは静的な構造物です。これを自分のフィルタを通して動的なストーリーとして想像するのです。様々なアクターが登場し、時間が流れる中で、彼らがいかに関わり、いかに行動するのかを想像します。

　そして、彼らの行動に矛盾はないか、その行動原理に不明な点はないか。そうしたことを確認していきます。これができると「書かれていない事」にも気づくことができるのです。

　例えば「ユーザーにAという情報を見せたい」という要件があれば、そのAが誰がいれるのか？Aを手に入れるのにかかる時間はどのくらいか？ユーザーはAをなぜ/いつ/どのように見たいのか？といったことを想像する必要があります。

　「Aを見せたいのだから、データベースにはAのテーブルがあって、それって、どういう属性なんだろう」という変換ではダメなのです。

　次に「創造力」とは、想像したビジョンの実現手段を考える力です。これは戦略的でなくてはいけません。先ほども書いたようにビジョンには様々なステークホルダーが関係します。エンドユーザーにとってはAが望む通りに見れればよいでしょうが、PMにしてみれば期限も予算も品質も気になるところです。管理者はAを効率よく扱いたいでしょう。エンジニアは他の機能と同じような作りで実現したいはずです。

　そういったバランスがとれる最適な方式を創造するのです。これは実現性がなくてはなりません。「こうなったらいいな」というような想像ではなく、明日には取りかかれて現状のリソースでまかなえる必要があります。創造された結果は「明確な形」であることが重要です。

　さて、どうしたら「想像力」と「創造力」を上げる事が出来るのでしょうか。

　「想像力」で重要なのは「具体性」です。例えばアクターのキャラクター設定を理解し、彼らの行動原理や作業目的を知る事で、より具体的にビジョンを描けるようになります（企業内アクターであれば、どうやったら彼らの給料があがるのかを知るのは大切です）。できれば実際のアクターには会うとよいです。「あの人が使うんだ」ということが分かれば想像力は高まります。

　他にも時間を具体的に定義する事もあげられます。１時間、１日、１週間、１ヶ月、四半期、半年、１年、２年、３年といったスケールを定義しながらアクターを動かしてみましょう。時間が過ぎるほどデータが増え、環境は変化していきます。どんな作業であれ、繰り返すのは間違いないので、それがどういうタイミングで起きるのかを考えるのです。

　「創造力」で重要なのは「多様な視点」です。例えばレビューをすること。自分の視点だけから見ていると、その創造力は自分の限界に限られてしまいます。だから、ユーザーに見てもらったり、PMやエンジニアに見てもらったり、自分の考えている事が実現できるのか、実現したとして価値があるのかを聞くのです。

　創造力は多くの事を経験するなかで培われていくものです。努力を行い、時間をかけただけ創造力は鍛えられます。アイデアが面白いとか、発想がぶっとんでいるとか、そういうことは創造力の一部でしかありません。勘違いしてはいけないのは、創造力とは「実現する力」であり、そのためにあらゆる手段を行う力なのです。発想力がないなら、そういう人を巻き込めばいいだけ。それを繰り返しているうちにパターンが出来てきて、ある程度は自分で出来るようになってきます。

　長々と書いてきましたが、想像力と創造力が重要なのはITアーキテクトだけではありません。PMもエンジニアも、誰も彼も仕事をする上では重要な能力だと思います。あなたの仕事は「指示された事を成果物にする」ではないのです。自分の仕事を「指示された事を自分の中で動かし、それを実現する」と捉えると、幅が広がり、仕事の面白さが分かるはずです。そこには想像も創造もあるのですから。

　引き続き、人材募集してます！アプライはこちらから。 http://www.gxp.co.jp/recruit/index.html

併せて読みたい：SIを仕事にするということ

　アーキテクチャ設計といわれる作業の対象物は何か？というのを考えてみると、それは「静的な構造物」ではなく「動きそのもの」です。

　つまり、ソフトウェアそのものではなく、ソフトウェアを通じて行われるコミュニケーション、ビジネス活動といったもの。

　つまり、サービスそのものではなく、サービスを通じて行われるコミュニケーション、活動といったもの（この場合のサービスはSaaSのようにWebサイトを通じて提供されるソフトウェア機能のこと）。

　ソフトウェアやサービスといったものは「事後的に観察可能になる構造体」であり、人々によって共有可能なオブジェクトに過ぎません。

　僕の感覚では、そのソフトウェアやサービスといったものをデザインしているつもりもないし、デザインしたいと思えません。

　僕がデザインしたいのは構造体によって生み出される動的なもの。誰かがソフトウェアを使って何かをして、何かを得て、もしかしたら何かを失うという、その過程全体。それは時間軸の中で生まれ、続き、消えていくもの。一回性のあるもの。

　まぁ、だから、僕にとってはソフトウェアだろうがサービスだろうが、"そのモノ"を作ることには興味はなくて。ソフトウェアやサービスを通じて生成される、カタチにはできない動的なフローそのものを創り出したいのです。"動き"そのものをデザインしたい。

　提案書の最初に書くのは機能そのものではなく、どんな動きが生み出されるべきか。そして、その動きを生み出すためには、どういう機能（構造体）が必要か。

　僕自身がSIerで働いていてエンタープライズ領域が好きなのは、そういう"動き"がどこまで広がって社会全体につながっていくからです。そして、ソフトウェアなんか気にしない人にも影響を与えられるから。

　とても「ゲームすると楽しい」みたいなことにはコミットする気にはなれず。ゲームを通じて社会のあり方を考えてみる、みたいなレベルならいいのかもしれないけど、でも、やっぱりエンタープライズな領域のおもしろさにはかなわないかな。間接的に人を幸せにはできなそうだし。

　だから、僕の作る対象が、どこか1カ所だけにデプロイされるWebアプリケーションでも、クラウドで動いているSaaSでも、全国に展開されたパッケージでも、なんでもいいです。良い動きを生み出すための最適な構造を作ればいい。

　なんで、こういう感覚なんだろうなぁ。キャリアのスタートがユーザー企業側だったというのは大きいとは思います。かつ、流通業だったので、そのユーザー企業の裏側の業務に詳しくなりつつ、表側ではお客さんになれたので、ソフトウェアが生み出す動的な系の全体を俯瞰することができました。すっごいおもしろかった。

　たぶん、それ以来、こういう視点が至極当然のことだと思っていました。このエントリに書いたようなことは、僕自身が思う普通のことを真面目にやっているだけです。

　さて、こういう感覚を共有できる方がいるかどうか分かりませんが（幸い1名いたわけですが）、弊社では人材募集をしています。

　大手企業のプライム案件しかないです。業種は流通、医療ヘルスケア、建築、データ。システム領域は自分たちで「エンタープライズコミュニケーション」と呼んでいるインターネットを利用したB2BやB2Cが多いです。開発だけじゃなくて、企画、設計、運用、コンサル、セールス、マーケター、デザイナーなどなど、ITに関係するなら、どんな職種でも求めています。

　アプライはこちらから。 http://www.gxp.co.jp/recruit/index.html

　なお開発事業部の統括マネージャーを拝命しておりますので希望しなくても僕が面談します。質問があればメール（y.suzuki あっと gxp.co.jp）でも、Twitterでもどうぞ。お仕事、たくさん用意して待ってます。

　今回はビデオがあるので、よろしければこちらから。

　デブサミの時はQCon Tokyo 2011前だったのでDDDは紹介だけだったのですが、無事に開催されEricと和智さんとパネルをやらせてもらった時の話を追加しました。あとは3.11の話を追加しています。

　トゥギャッターはこちら

　「アーキテクトがいないとプロジェクトがうまくいかない」という当たり前な事を、できるだけ標準的なフレームを使って説明しようという試みです。

　講演でも話をしましたが、世に聞く"優れたプロジェクト"に限ってアーキテクト要素が暗黙的な前提になっていることが多く、ここを知る事はプロジェクトマネージャーの役に立つだろうと思います。アーキテクトという役割（ロール）に、マネジメントの視点からスポットをあてたいですね。そうすればプロジェクトマネージャーが戦略的（アーキテクチャ的）にアジャイルを取り込んでいけると思います。

　あと、現場のエンジニアの方にとっても、なにか霧が晴れるような部分があればうれしいです。敵が分かれば対処のしようもあります。解決は簡単なことではないかもしれませんが、自分の感覚を信じて、目の前の敵を倒してもらいたいです。

　資料を振り返るに、最近は現場だけじゃなくて、いわゆるマネージャー仕事もやっているので、プロジェクトを第三者的に見る事も多く、そこで整理されたのでしょうね。いましか書けないという感覚です。

　ということで、今回は書ききれなかった、現在進行形のテーマは３点。

1.アーキテクトの機能をどうやってプロジェクトにもたらすか
2.アーキテクト（あるいはアーキテクト的視点）をどうやって育成するか
3.プロジェクトアーキテクトの詳細な定義

　１については、PMO（Project Management Office）をアーキテクト的要素から再考することで、２についてはキャリアパスも含めた人事／組織面でのアプローチとなります。３はプロジェクトとは何か、という根本を掘り下げたいなと。

　ここらは年末あたりに発表できればいいなぁ、と思っています。

　ところで二日目朝一の横並び（吉岡さん、和田さん、僕、嵩原さん）にはご意見も多かったようで、縦に並べて再演しようという企画が動いています。そんなことがあれば、ぜひ、また話をしたいと思います。

　なお、最近はtwitterで活動していますので、そちらもよろしく。

16:35-17:20「早い安い新しい「Fast IT」を使いこなせ！ クラウドを楽しめるエンジニアの条件」

　XDev2010自体がFast IT（すぐに使えるIT）というのコンセプトを掲げており、それを受けての講演です。Fast ITというイメージからすると早くて安くて...みたいかと思いますが、エンタープライズシステムという視点ではFastというイメージだけにとらわれていると見誤ります。

　結局、Fast ITだけで企業システムが完成することはありません。企業として必要なIT資産を整理し、最適化としてIT手法を選ぶべきです。そのための1つの手段としてFast IT、まぁ、クラウドは良い選択肢です。

　前半は趣味な感じでファストファッションの話で進めてみましたが、思ったよりもうまく説明できて面白かったです。H&Mは「いま流行なものを1シーズンだけ着たい」 から「それなりの品質で安く」がいいというコンセプトになっています。つまり、「早い、安い、新しい」は手段であって 目的ではない。これはそのままITでも当てはまります。クラウドは手段であって目的ではありません。

　なにかフィードバックがあればコメントでもメールでも！

　それにしてもLTの内容がひどい。健康とか、ビジネスとか、職業斡旋とか、営業とか、加齢臭とか、35歳にもなると、こんなもんですよね。僕もLTしましたが時間を守る気もないし、酔っぱらった勢いで言いたいことを言うという感じでした。

　で、結局のところ僕が一番言いたかったのは「35歳の自分を認めよう」ということです。

　35歳にもなれば適応能力もなくなるし、物忘れもひどくなるし、体力も衰えます。でも、経験を積んでいるから得意な成果を出すのが早いし正確になる。そういう自分自身の成長や老化に意識的なるのは大事です。それが見えていれば様々な変化を受け入れられるし、適応もできると思います。

　あ、別に35歳だから、というわけでもないですね。ある役割の自分、あるスキルを持った自分、ある生活がある自分、そういう自分自身との向き合いを通じて、自らがやりたいことをやるのが大事ではないかなと。

　結局、プログラマを定年するかどうかを選ぶのは自分です。定年してもいいし、しなくてもいい。でも、意図せずにしなくなったり、無理にやめさせられたり、あるいは無関心にしなくなるのがよくない。今の自分が大事にするものに意識的であって、そのバランスが取れるようになっていればいい（興味とか、家族とか、働き方とか、お金とか、その他なんでも）。それがプログラミングな人もいれば、そうでない人もいる。

　LTはどれも素晴らしかったです。みんな自分の好きなことがあって、それに向かって純粋で、そうやって世界を拡げてきたんだなと、素直に感心してしまいました。ホントに人生いろいろ。

　急な集まりにも関わらず、20名以上も参加していただき本当にありがとうございました。「よくわかんないけど楽しい」っていう感じだったので、また機会があればやってみたいです。若い人も絡まれに来ればいいと思うよ。

参加者リンク：
「プログラマ35才定年説」飲み会に行ってきた - 麦わら帽子の「記」
「プログラマ35才定年説」飲み会 - fkino diary
35才定年説飲み会に行ってきた - はてっちょ
「プログラマ35才定年説」飲み会に行ってきた - Social Change!
「プログラマ35歳定年説飲み会」に行って来た。 - いまいにっき
年老いた犬の生きる道 - SlideShare by Kwappaさん

　釣りっぽくなったのは反省していますが、簡単に要約すると以下の感じ。

従来は35才という年齢が注目されて議論がされていましたが、そこに「技術の変わり目」という時代性を組合せると、まさに今年35才になる世代から、新たなプログラマ定年説が始まる気がするのです。

　というわけで（？）、悩み多き30代、キャリアやスキルについてLTしつつ、ビール飲みながら＆ピザを食べたいと思います。もちろん、「これから30代」も「30代を卒業した」という方も大歓迎！！。

　8月3日（火）19:30- 新宿にて（地図などは下記リンクから参照してください）

申し込みページ：「プログラマ35才定年説」飲み会

　LTもやりたいと思います。申し込みをされるときに「LTやる！」か「観客で」を選んでください。「35才定年説なんかない！」、「お前のエントリはココがダメだ！」みたいな意見も大歓迎です。僕も自分のエントリをサマリしたLTをします。参加者の皆様からフィードバックを得つつ、進めていきたいと思いますので、よろしくお願いいたします。

今の35歳はインターネットともに育った世代
　75/76世代と呼ばれるように、1975年生まれのエンジニアは日本のインターネット創生期からWebアプリケーションに魅せられました。大学に入学（1994年）するとインターネットとメールが与えられ、MozaicでNASAのページを見ていたと思ったら、Yahoo（1994年）、Amazon（1994年）、そしてGoogle（1996年）が創業。就職活動もインターネットで行い、会社に入ればEコマース全盛、DoCoMoがiモード（1999年）をスタートすれば携帯サイトも花盛り。日米の株式市場ではインターネットバブルが起こり（1999年末）、すぐに収束（2001年）していました。

　仕事はダウンサイジングとオープン化の流れで汎用機（ホスト）やCOBOLってなんですか？は当たり前。クラサバをちょっとやっていたら、1999年にはサーバサイドJavaの定番といえるJ2EEが登場。Blueprintを真似して、いまとなっては痛々しいフレームワークを組み、そうこうしていたらStruts（2001年）が登場、Hibernate（2003年）でORマッパーブーム、Inversion of Control が Dependency Injection になった（2004年）りして。あぁ、懐かしい。

　こうした変化の先端で走っていた僕らの世代はやりたい放題でした。技術が一気に切り替わったので、周りも知らないことだらけ。バブルもあったので失敗を怖れずプロジェクトが立ち上がったように思います。自分たちで新しい技術への挑戦し、失敗したり、成功したり、もう、好き勝手。

35歳定年を年齢でなく時代から理解する
　で、2010年。そんな僕らも35歳。ひと回り年下の"ゆとり世代（第1期）"が入社してきました。世の中はリーマンショックから立ち直れ切れておらずプロジェクトには安全確実が求められ、技術のトピックスはクラウドやモバイル端末。ソフトウェア作りはサービス提供の時代になったのです。今や技術を作ることよりも、使うことに価値がおかれつつあります。

　そう、技術の変わり目が来ているのです。あの頃のように。技術の変化は冷酷です。個人のスキルや体力の問題ではなく、世の変化だから。それまでのコダワリを捨て、新たなステージへと飛び込むマインドセットを持っているかが重要なのです。年齢なんか関係なくスタートラインからやり直し。当時の僕らが先輩どうこうではなく学んだように。

　そもそも、35歳といえば気力も充実しているし、体力不足は補って余りあるものです。「これまで培った能力を発揮する」ことについては最高の年齢と言えるでしょう。しかし、一方では「まったく新しいことにチャレンジする」ことが難しくなる年齢です。しかも、それを「状況に負けてしかたなく」ではなく、前向きにトライするのは大変な努力が必要になります。

　つまり、そういうことなのです。いわゆる「プログラマ35歳定年説」は、いまから12-5年前に技術の中心がインターネットへと変化していった時、そこについていけないために引退したプログラマが35歳付近だったというだけなのです。

　もうお分かりですね。そうです、2010年から「新プログラマ35歳定年説」が生まれるのです。これから起きる（もう起きている）技術の変化に対してついていけない35歳付近のプログラマが大量に引退させられる。

　クラウド、仮想化、モバイルデバイス、マルチコアとか勉強していますか？むしろ、使って遊んでますか？やってないなら危険領域です。「信頼性が足らないから使えない」とか言っているなら症状が重いですね。あと「最近の若い奴は...」もね。

　話はこれで終わりません。12年前は業界として人数が少なかったし、仕事は増えるばかりでした。だから、会社の中でスキルチェンジしてPMや営業になればよかった。でもね、いまやエンジニアの数は数十倍に膨らんでしまいました。しかも、案件は縮小傾向にある。そんなにPMも営業もいらないんですよ。さらにフリーランスという形態では会社としての雇用保障やスキルチェンジができない人も多い。

　以下のような人が危険です。

・30才を過ぎてもプログラミングが仕事の大半
・50人月以上のPM経験がない
・小規模SIerに所属するか、フリーランス
・運用や足回り（ミドルウェア、インフラ、OSなど）の経験がない
・もちろん、営業経験もない

　中規模以上のSIerでも「あの人は技術に強いから」という理由でプログラミングだけをやってきたような人、インフラやミドルをやったことがあったとしても小規模で全部自分1人でやってきたような人も危険領域です。

どう生きていくべきか
　今は技術の変わり目なので旧世代のエンジニアも重宝されます。古いシステムはすぐにはなくなりません。でも、5年ぐらいするとニーズが減ってきます。そこら辺が本当の分水嶺。だから、この5年くらいで何かをやっておかないと飲み込まれる。

　今年になってから、こういった悩みを聞くことが増えました。皆さん危機意識はお持ちなんですよね。

　ありきたりなアドバイスですが、これまでと違うことをして、違う人と話すことが大事です。もちろん最初は苦労も多いから「なんでこの歳になって」と思うこともあるでしょう。でも、そういう変化を怖れる気持ちがプログラマ35歳定年説の原点なのです。

　なんでもかんでも挑戦したあの時と同じようにすればいい。知らないことを学ぶ楽しみを思い出しましょう。達成してしまえば、苦労なんて吹き飛んだでしょ？習うより、慣れろですよ。

　転職も悪くないアイデアです。でも、雇う側も余裕があるわけではありません。これまでのキャリアを活かしてもらうために雇うわけだから、あまり違うことができない可能性の方が高い。もちろん、場が変われば色々とチャンスが拡がります。でも、変化を場に期待しているだけでは何も変わりません。変わるべきは"あなた"です。そのための転職でないといけない。

　明るい話を。幸いなことにITがなくなることはありません。おそらくIT業界は縮小しますが、それは他の業界にITが融けていっている証拠です。ですから、これまでIT系でキャリアを積んできた人には、かなりの可能性があります。ただし、IT業界だけの視点を持っていてはダメなのです。

　残念ながら時代は移り変わっていきます。それに対して自分も変化しなくてはいけない。それは僕らの世代の宿命なのでしょう。宿命であれば受け入れるしかない。その上でいかに生きるか。皆さんとともに頑張っていきたいものです。

　阿部雅世さんからソフトウェア品質モデル、ビルディングタイプを経て、ITアーキテクチャに一直線に引いてあります。（参考：「ソフトウェアをデザインしてはいけない」、「プロセスこそアーキテクトのもの」）

　「アーキテクチャとはつなげるコト」というのは前から言っていたことですが、今回初めて言葉にしてみました。また、その力はアーキテクトだけのものではなくて、ソフトウェア開発に携わるあらゆる人にとって必要な発想だと思います。

　資料にない部分の補足。その昔はソフトウェア品質モデルで言うところの利用状況に多様性がなかったはず。その時代ではシンプルに利用時品質＝外部品質とすれば良かったし、内部構造も安定していた。だから、プロセス品質（要はマネジメント手法）のことだけを考えていれば良かった。でも、いまは利用状況も内部構造の多様化していて、プロセス品質を高めているだけでは全体の品質が上がらなくなってきています。

　今の時代にアーキテクチャなり、アーキテクトというものが求められる要員は「技術の複雑化」ではなくて「多様化した社会からの要請」なのです（参考：「ITで変化する社会とITアーキテクトの意義」）。

　あと「沖縄の IT はどこへ向かうべきか？」というパネルディスカッションにも参加させていただきました。僕からの提言は2点。

　1点目は「リーマンショック以降、人出し受託モデルが崩壊し、物づくりから視点を動かさないといけない」（参考：「デブサミ2010 - これからのアーキテクチャを見通す」）という背景から「観光関連など内需型のシステム開発について、施設や運用ノウハウなどを含めたサービスとしてパッケージングし、県外観光地（北海道や中国）に売っていく」。要はビジネス・トランスフォーメーション・アウトソーシング (BTO) を県主導でやってはどうか、というものですね。

　2点目は「インターネット向けシステム開発と共に育ってきた35才近辺エンジニアが技術のシフトにより世代遅れになってきており、精神的にも疲れている。ただし、基礎技術力はあるし、開拓精神も強い」という背景から「都心で疲れた35才近辺エンジニアを沖縄に招き、3年限定であえて観光や農業などのIT外産業でプチリタイアさせる」というもの。これは「ITは、IT以外の産業で活かされるもの。でもエンジニアはIT産業に留まりすぎている。どんどんIT外の産業に飛び込んでいくことで体験からIT活用を考えることが出来るはず。こうすることでIT外産業も、そこに飛びこんだエンジニアも成長できる。プチリタイアの3年が過ぎてITに戻るもよし、留まるもよし、起業するもよし」という意識です。ITエンジニアはもっと外に出ていくべきですね。

　一緒に参加されていた宮里さんの「10年後を見据え、子供教育にITを積極的に活用してグローバルな感性を磨かせたい」とか小橋川さんの「プログラマ・アイランド構想」も、すごく面白かったです。

　個人的なプレゼン振返り。

１．「隣の人とシェアしてください」メソッドを使ってみた
　1回目は4ページ目で「シャボン玉をデザインするってどういうことだと思う？」、2回目は24ページ目で「ソフトウェア品質モデルやビルディングタイプで何か気づきがあった？」です。それぞれ2分30秒。2回目は静まるまで3分ぐらいかかっていて、なんか、すごいうれしかったです（もっと話せることがある、ということですからね）。でも、みんなが何を話しているかが気になって仕方ない。

２．ダイアグラムと写真中心にしてみた
　公開資料は付記がいろいろとありますがプレゼンした資料はもっと付記が少ないです。字ばっかりから、プレゼンテーションZENにはまって写真いっぱいになったけど、藤本壮介さんのダイアグラムばっかりもかっこいいなと思い、中間的なところに収まってきました。なんとなく、手法として確立して行けそうな気がする。気づきとしては、より生成的に話ができること。昔は緊張して言いたいことを忘れちゃうから書いていたっていうのもあったんだよね。

　はじめに僕からは3つのWebサービスを紹介しながら、ITによって"かかわり"を拡張するという試みを説明しました。

　1つ目がニコニコ動画。ご存じの通り、ニコニコ動画は動画上にコメントを付けることができ、それが動画の上を流れます。だから、動画を見ていると笑えるところでは「wwww」（ｗは"笑"の意味）が大量に流れたり、ツッコミが流れたり、なんかうまいこと言おうとするコメントが流れたりします。場合によっては、動画が見えないぐらいに流れる。

　ニコニコ動画が面白いのは「絶対時間からすると動画を同時に見ているわけではないけど、動画の中の時間軸では同時に感情を共有できる」ところです。時間的に非同時的でありながら、感情的に同時的である。個別の人のコメントを動画時間軸に"重ね合わせる"ことで、新たなコミュニケーションが生まれています。

　2つ目が言わずと知れたTwitter。Twitterはミニブログと言われるように、ツブヤク側からするとブログのように情報を発信するだけのツールです。ですが、他人をフォローすることで、その個別のツブヤキを自分用に再編集し"重ね合わせる"ことができます。これをタイムライン（TL）と呼びます。ですから、まったく同じ人をフォローしていない限りTLは固有となります。

　トークの中では紹介しませんでしたが、公式RT（リツィート）を使うコトで他人のTLにフォローしていない人を強制的に割り込ませることができ、これはこれで非常に面白いです。公式RTは、はじまるまでは反対意見が多かったようですが、いざ開始されてみると意外に楽しい機能になりました。公式RT経由で新しいフォローをしたことは1度や2度ではないです。

　3つ目はセカイカメラ。セカイカメラは言葉、音声、写真を封入したエアタグという仮想マーカーをセカイに貼付けることが可能です。単純には地理的な位置に対して、非同時的な体験の結果を埋め込むことが可能です。事後的にその場を訪れた人は、過去に訪れた人の体験を"重ね合わせる"ことで、その場を楽しむことができます。

情報の重ね合わせによる"かかわり"の創出
　これら3つのWebサービスに共通するのは"情報を重ね合わせる"をいう点です。ITによる"かかわり"というのは、デジタル化された情報を媒介としています。メールなんかがイメージしやすい。一方で、デジタル化された情報というのは再構成が容易です。特に最近ではPCもサーバも性能が上がってきており、再構成できる範囲が劇的に拡がりました。

　上記のWebサービス達は個々の情報が面白いわけではなく、それらの情報をある軸で重ね合わせることで、より高次のコミュニケーションが創出されてくる。デジタル情報の構成の"系"を変えていくことで新たな"かかわり"を生み出しうる、というのがITの面白いところではないでしょうか。

　ですから、Webサービスにとっては、どのような系（まさにシステムですね）を生み出すかが重要であると言えるのです。

セカイカメラはアーキテクチャは主張しすぎ
　会場でも反応が大きかったのはセカイカメラです。でも、僕自身はセカイカメラは未成熟であると感じています。トークでも言いましたが「セカイカメラはアーキテクチャが強すぎる」のです。

　セカイカメラでは、リリース後に無意味なタグが貼付けられる"エアタグ汚染"や"エアタグテロ"と呼ばれる行為がおきました（セカイカメラが公開されて秋葉原で歴史的事件発生？）。これについて「アーキテクチャが面白すぎるから、ただアーキテクチャを使いたいだけで、コミュニケーションとして無意味なことをしてしまう」と説明しました。これに対して藤本さんが「建築でも主張し過ぎるアーキテクチャというのはある。分かるなぁ」と、受けてくださったのが面白かった。

　地理的な情報を元にしたコミュニケーションは注目の手法です。セカイカメラは先鞭を付けたという意味では素晴らしい系（システム）ですが、コミュニケーションをするための系としては未成熟であると感じています。そもそも、地理的な体験は多様すぎて時間を超えて体験を共有するのが難しいかも知れません。foursquareぐらいシンプルにするか、あるいは特定の場所や目的に絞るようなことが必要なのかもしれません。

　一方で、Twitterはコミュニケーションのプラットフォームとして自社を位置づけています。シンプルなUI、控えめな広告、オープンなAPI。コミュニティに運営をまかせることを基本にしています。お勧めユーザーリストも、リスト機能の提供と共に停止しています（Twitter、「おすすめユーザーリスト」を中止へ）。

建築における"かかわり"
　この後、藤本さんからは"かかわり"をキーワードに作品を紹介して頂きました。藤本さんは「建物は、"都市と自分"、"家と自分"、"他人と自分"といった関係の隔たりのバリエーションを作る。建物を使う人は、自分の領域を感じながら他者との離れ具合を調整しつつ、その関係を選び取る。それが住まうということ」と説明されています。

　藤本さんが何度も繰り返されていたのは「建物はソコに絶対的に存在してしまう」ということです。建ってしまったら圧倒的な存在感が生まれてしまう。「だからこそ、人を刺激し、人が発見的に関われるということを大事にしたい」のだそうです。

　「東京というのは雑木林のような場所。だから、東京らしい集合住宅を造ろうと思ったら、こうなった」と紹介した東京アパートメントは、ハコガタの家を積み上げた"だけ"の集合住宅。でも、箱と箱のすき間を通って上り、屋根的な場所を歩くといった曖昧な場所が多数あります。

　あるいは、武蔵野美術大学の図書館（武蔵野美術大学 美術館・図書館（設計：藤本壮介）レポート…竣工した図書館を見てきた（5/21/2010）、新図書館潜入レポートその２）は本の森。森は距離によって様々な風景を生み出します。遠くから見えるモノ、近寄ったときに見えるモノ、視点を低くしたときに見えるモノ、その全てが異なっている。その体験が発見的に関わりたいと人に思わせる豊かさなのかもしれません。図書館はぐるぐると巻かれた巨大な本棚によって構成され、そこに穿たれた穴は立つ位置によって本棚が重なっていくような風景を生み出します。

　
雑さやゆるさが"かかわり"を生み出す
　僕が一番聞きたかったのは「ITと建築は交わるのか？」ということ。もちろん、ズバリな答えなどないのですが、ヒントになりそうな話がありました。

　先日、上野公園のユビキタスコミュニケータというものを利用してきました。ユビキタスコミュニケータはRFIDや無線を利用した音声/動画情報端末。機能の1つに、園内を歩いていると自動的に付近の情報が音声で流れるというものがあります。ところが音声がエリアに入る前に聞こえたり、エリアに入ってからしばらくしてから聞こえてきたりと、少しズレていたりします。

　僕が「ズレるから、おいおいって思ってしまう」と言ったら、藤本さんは「もしかしたら、そういったズレが豊かさではないか」という指摘をしてくれました。続けて「雑さやゆるさといったものがあることで、人が発見的に"かかわる"余地を生み出す」と。

　なるほど、ITにも曖昧さ、雑さ、ゆるさ、といったものが必要なのかもしれません。それによってユーザーが発見的に"かかわり"を探索したくなるようなもの。

　例えば、ニコニコ動画のコメントは古いモノから消えていくので人気のある動画のコメントは常に動いています。動画を見ていて「職人乙！」みたいなコメントだけが残っていて、肝心の米職人の作品がなかったりすると、それに対してくやしがったり、復活させたり、違うコメントをいれていったり、そうやって新しい"かかわり"をしようとしているのではないか。

　僕は企業システムを作っているので曖昧さは敵。でも、ある種の曖昧さは許されるのではないか、それによって、ユーザーをより強く関わらせることができないか。藤本さんが言う"森のような"アーキテクチャを作りたい。そういう思いを強くしました。

感想
　いやぁ、それにしても藤本さんとの対談は面白いです。3日前に僕の資料を見てもらっただけで、ほぼ打ち合わせ無しで挑みました。スタートは迷いがありましたが話し始めたら2時間があっという間でした。これからも、こういう異業種での対話は続けていけたらと思っています。

拡張する空間 建築家とITアーキテクトがつくるもの 藤本 壮介 鈴木 雄介 コム・ブレイン 2010-04-02 by G-Tools

池袋ジュンク堂の告知＆申し込み（電話予約）

------------------------------------------------------------
『拡張する空間　建築家とITアーキテクトがつくるもの』刊行記念トークセッション
拡張する“かかわり”

■2010年6月24日(木)19:00～

【概要】
建築とITにはメタ・レベルで共通する部分があり、融合できるという予感が多くの人たちに共有されています。その予感を対談の形で表現した書籍『拡張する空間　建築家とITアーキテクトがつくるもの』をもっと深く、もっと楽しく読むため、“かかわり”をテーマに著者２人が再び対談します。普段なら出会わないはずの人と人が出会い、かかわりを持たないはずのもの同士がかかわる。──建築やコンピュータ・ソフトウェアには“関係”を生み出す力があります。関係性をつくる力の源泉とは何か、そしてその力を建築とITが共有し、さらなる関係性を生み出すにはどうしたらいいのか？実例の紹介、講師２人による対話、そしてトークセッションに参加するみなさんも巻き込んで“かかわり”が拡張するでしょう。

藤本壮介（ふじもと　そうすけ）／建築家
鈴木雄介（すずき　ゆうすけ）／ITアーキテクト
------------------------------------------------------------

池袋ジュンク堂の告知＆申し込み（電話予約）

　さて、まずは基礎的なところからですが、お手元にAndroidケータイがあれば、先日リリースされたNyARToolkit for AndroidをAndoroidマーケットからダウンロードすることができます。NyARToolkitはARの基本的な機能を提供するツールキットで、これを応用することで様々なARを作ることができます。

　ところでARというのは「センサーを使って周囲の状況を把握し、適切な処理をする」こと。これだけではエアコンの温度調節と同じです。エアコン的なものを越えて最近のARが面白いのは次のような2つのポイントと感じます。

　1つ目は周囲の状況を把握するのに画像解析や地理情報解析が利用できること。これで（比喩ではなく）"目の前の"状況に適用できるようになった。そして、人が"自分のリアル"と"カメラの中の映像"が連続的であることを理解し、つながりを認識します。技術的な観点で言えばARが拡張している"現実"とは映像や地理情報でしかなく、ただ、それを人が現実と認識しているだけなのです。

　2つ目は可搬性の向上。AR技術は大量のコンピューティングパワー（CPUとかメモリ）を要求しますが、ようやくモバイル端末で十分な速度で利用が可能になりました。人は様々に移動しテンポラリな活動の場を持ちます。そこに持ち込まれたモバイル端末によって"近現実"が掬い上げられ、適切なデータを提供されるのです。

　1年ぐらい前ですが、The BMW Z4 in 3D Augmented Realityは分かりやすくAR。Z4のCMに合わせた内容ですが、ソフトウェアをインストールすると自分の部屋の上でミニチュアZ4が走りまくりタイヤの後を残します。このキャンペーンでBMWが制作した「BMW Z4 vs London」というビデオクリップがすごく楽しい。

　このクリップが楽しいのは街中でZ4が走り回っているところでしょう。映像そのものに僕らが勝手にリアリティを感じ、そこを走り回るZ4の虚像にリアリティを感じてしまう。この脳内の困惑が楽しさとなります。

　最近話題のARといえばセカイカメラです。セカイカメラは地理情報を利用して現在位置を特定し、ユーザーがその場に対して登録したタグを表示します。技術そのものはシンプル（現実的）ですが、モバイルという特性を活かし、ARをコミュニケーションのツールとして定義したことが非常に高い評価を得たのでしょう。以下はTechCrunch50でのデモ画像です。リリースされているセカイカメラではできないような機能も含まれていますが、まぁ、セカイカメラの行き先を理解するのは良いと思います。

　ARはリアルの体験を豊かなものとする可能性があります。場所や人などの対象そのものが情報を記憶することはありません。あくまでも見る側が対象に意味を見出す。体験としての出会い（場所、人問わず）、とくに日常から離れた出会いは強い影響を持ちますが、そこに物語が与えられればより強く記憶されることになります。観光名所には解説が必要なのです。ライブを楽しむ文脈的知識のことを"教養"と呼ぶわけですが、その一部がARによってもたらされるのはリアルの拡張と言えると感じます。

　TED2009で発表された「パティ・マースによる 「第六感」デバイス 」は面白かったですが、その開発者であるプラナフ・ミストリー氏がTED Indiaで行ったプレゼン。

　彼のアイデアが面白いのは持ち運び型のプロジェクターを使う点です。カメラをかざすことなくプロジェクターがダイレクトにリアルに情報を重ねます。もちろん、プロジェクターが万能なわけではないですし、現実化にむけて技術的な障壁は低くないですが現実を拡張する感覚がよく伝わってきます。

　一方で、ARはリアルの喪失とも見えます。以前、「Google Earthで街並みを見ているだけで満足。特にそこに行きたいとは思わない」という若者の話を聞いて、残念に思ったのですが、それにライブ映像が加われば「もう行く必要ないじゃん」という人は増えそうです。こちらはマイクロソフトのBing Mapsの情報に写真や動画を重ねるデモ。後半、ストリートビューにリアルタイムの動画を重ねていますが、これはすごい。

　ただ、これはこれで豊かな取組みなのかもしれません。地図サービスが大きな災害に際して特設サイトを立ち上げるのは、擬似的であれ世界で起きていることを体験してもらうため。場所性の喪失を単純に悲しい事というだけではなく、自分の"目の外の現実"を知る現実拡張だと捉えるのです。

　最初には、ARとは「見えなかった現実が見える」と書きました。ARは単にデジタル情報を重ねるというものではありません。最後に、実現はいろんな意味で不可能に近いと思いますが面白い妄想を。ロンドンに住んでいるKeiichi Matsuda氏の作品。人々が広告の表示で生きている時代、1杯分のお湯を沸かすために、どれだけの広告を表示するのか。極端ではありますが、ARの間違った進化を示す作品です。

Augmented (hyper)Reality: Domestic Robocop from Keiichi Matsuda on Vimeo.

　別にAR（画像認識/地理情報認識）に限らず、ユーザーのアクティビティをセンシングし、そこに含まれている近現実から適切な情報をフィードバックするという手法は色々と考えられます。ARはとても分かりやすい形で、これを表現しただけ。

　例えばGoogle PowerMeterやMicrosoft Hohmというのはスマートメーターを使って家庭の電力消費量をリアルタイムに表示する取組みです。いずれも完成したサービスとは言い難い状態ですが、導入した家庭では10%-20%の電気消費削減ができるとのこと。もっとフィードバックを上手に出来れば大きな成果を挙げられる気がします（ちなみに日本でも経済産業省が主導してスマートグリッドの議論を進めています。ただ、実証実験とか見ていると、電力会社とメーカーやベンダーの技術自慢にしか見えないんですよね...）。

　ITによって見えなかった現実を知ることで変わる事ってたくさんあると思います。単なる技術自慢に終わらずに生活を豊かにできないもんかと考えていきたいです。

　歴史的に振り返ってみましょう。インターネットの前身となる"ARPANET（アーパネット）"の稼働が1969年で、インターネットの本格的な普及が1995年（Windows95発売後）になります。知の巨人たるGoogleの創業が1998年、その後、SNSの代表格MySpace、mixi、facebookなどが2004年ごろに創業、最近話題となっているtwitterが2006年、ustreamが2007年に創業しています。

　一方で、社会ネットワーク論という視点では、"6次の隔たり"で有名になるスタンレー・ミルグラムのスモールワールド実験が1967年、それから時代が下ってダンカン・ワッツとスティーヴン・ストロガッツが1998年に「スモールワールドモデル」、アルバート＝ラズロ・バラバシとレカ・アルバートが1999年に「バラバシ＝アルバートモデル」という数学モデルを発表することで「複雑ネットワーク」という概念が様々な分野に応用されるようになります。彼らの著書は「スモールワールド・ネットワーク―世界を知るための新科学的思考法（2004/10 ）」、「新ネットワーク思考（2002/12）」です。

　そして、インターネットが社会生活に影響を与えていきます。これを扱った書籍としては「民主化するイノベーションの時代（2005/12）」、「フラット化する世界 （2006/5）」、「ウィキノミクス（2007/6）」、グローバル金融に特化した「世界はカーブ化している（2009/5）」、オバマ大統領選挙でのソーシャルテクノロジー活用を描いた「「オバマ」のつくり方（2009/12） 」、そして、本にはなっていないですが"ガバメント2.0"（TechCrunch：ティム・オライリー特別寄稿：ガバメント2.0―政府はプラットフォームになるべきだ）。時代が下るほど個人の趣味趣向から経済や政治との関係が強く語られているのは進化の適応順番ですね。マーケティングが早すぎ（セス・ゴーディンの「パーミションマーケティング（1999/11）」懐っ！）で、一番遅いのが法律なのは言うまでもないでしょう。

　というわけで、やや乱暴に纏めると1960～70年ぐらいに理論として予測されたものが、20世紀終盤に現実社会に進出、1995-2005年ぐらいが導入初期、そして2005年ぐらいから普及期といえるでしょう。1世代10年という考え方に従えば、2010年は普及期の真ん中になります。

　余談ですが、近年では携帯電話などのワイヤレス/モバイルデバイスの進化から、インターネット上でのコミュニケーションがリアルタイム化、分節化して（参照：拙作のコミュニケーションマップ）、その一方でクラウドをベースに、1.人軸、2.地理/時間といった物理絶対軸、3.動画/音楽といったコンテンツ軸での急速な集約が進んでいます。

　まぁ、要するにインターネットと社会ネットワークが絡まり合いながら"進化し続けている"のが現状です。世界レベルでユーザー数が爆発な拡大を続けており、日々、新たな概念が生まれているような感じです。

　で、ここの変わり目が本当に面白い。文化が「あるグループにおける行動の繰り返し密度」で測定されるとすれば、新たな技術は広範囲に濃密な行動変化を及ぼすため、絶対時間として短期間に文化を形成させ、それが急激な変化を印象づけます。

　そして、いつかは社会全体の認識が変わります。このサイトの名前であるarclamp（アークランプ）は、電気照明の「アーク灯（アークライト）」が普及し始めたとき、灯りをつけるという同質性から油を使う「ランプ」という言葉を使った造語的な存在。時代の変わり目には過去の概念を引きずったまま新しいものを理解していく姿勢が見えますが、これはいつの時も同じなのです。

　しかし、技術のもたらす急激な変化が社会に与える影響が大きいほど、そこでは良いことも悪いこともおきます（賢明な読者は善悪が立場による主観的な判断であることを知っているでしょうが...）。

　「出会い系サイト」という言葉は社会悪として認識されていますが、そもそも人と人が出会には大きなエネルギーが発生するのは当然であり、そこで善悪は別として倒錯的行動が起こりうるのは古来からの常識です。そこから目を背けたまま、単純にSNSや出会い系サイトを"規制"しても技術がもたらした変化を止めることは非常に難しい。現在では個人認証や個人情報のフィルタリングが義務付けされる方向にあるようですが、結局はニーズがなくならない以上はアンダーグラウンドになるだけです。それって臭いものには蓋ってこと。

　ようやく本題。こうした技術によって変化している社会においては、技術の特性を熟知した人間が、技術と社会の折りあいをつけていうことが重要になるはずです。それが、現代ではITアーキテクトと呼ばれる人たちであると思っています。もちろん、自分自身がその肩書きを名乗りつつも、ここで書いている職責に耐えられるかには疑問を抱いていることを先に書いておきます。

　ただ、そういった意識に目覚めつつある同世代の人物が非常に多いのが実際です。デブサミで対談では同世代のメンバーと「社会学的なアーキテクチャ」について議論が及びました。

　であれば、ITアーキテクトという役割にたいして社会的に意義が形成され、何らかの形で体系化されているのは必然です。

　僕が建築に興味を持つのは、建築家が建築物という「人間の認識に対する情報戦略上の重要な構造体」を管理することを目的に生まれ、体系化されたきたと考えているからです。ビルディングタイプは政治や経済などの社会的要請から生まれてきた社会的アーキテクチャがパターン化したものでしょう。「拡張する空間」を通じた対談でも、そういった視点は共通していると感じています。

　なので、単なる技術論としてITなりITアーキテクチャを語るというのでは不足感が強いわけで、より経済、政治あるいは社会という視点から発想が欠かせないものとなります。

　そんなの日常の仕事に関係ないと思いますか？ですが、すでにアーキテクチャの決定には経済、政治、社会といったものが強く関わっているのです。特にエンタープライズ案件に関係している人は、その仕様がどこからきているのか考えてください。いや、別にB2Cでも一緒です。僕らが作っているソフトウェアは、すでに経済/政治/社会の要請として形作られているのです。その意識を持つことがまずは重要です。

　前回エントリ「"いい感じに"モデリングする」で書いた「外圧」というのが、まさにそれです。外圧を拡張していったときに現れるのは、非常に広大な空間です。その空間を認識するだけの力を持たなければ、もはや優れたモデリングはできないのです。それぞれの業界で優れたシステムを作るには、業界の仕組みや動向を知らなくてはいけないのです。

　技術による社会変化が起きているとき、そこで技術側に立つ人間が果たすべき役割は小さくありません。僕自身に経済、政治、社会といった側面で何ができるのか。まだまだ小さいことしかできませんが、これからの10年、あるいは50年を考えれば、それが小さいままではいけないという自覚は持っていたいと思うのです。