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

従来は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年を考えれば、それが小さいままではいけないという自覚は持っていたいと思うのです。

　ソフトウェア開発ではモデリング（モデルを作る）が重要な作業となります。モデリングというと3Dソフトで描かれる構造物の内部図像が一般的ですが、ソフトウェアのソレはもう少し抽象的な意味になります。

　ソフトウェア、特に一般人に馴染みのある企業システムやWebサイトのソフトウェアは、現実の世界でナニカの作業を実現するために使われます。伝票を登録するためだったり、メッセージを伝えるためだったり（ゲームも面白い例なのですが、ちょっと脇に置いた方が良いかな）。

　そういったソフトウェアは"ユーザーに使ってもらう"ことで初めて動きを獲得します。ですから、使ってもらえるように作る必要性があります。人間は良くできているので抽象化した概念を自分の行動とリンクすることが可能です。わかりやすい例で言えば地図を見ることで目的地にたどり着けます。ただし、分かりにくい地図では迷子になる。その分かりにくさは抽象化の理解性に問題があると言うことです。

　つまり、ソフトウェアが"よりよく使われる"ためには、ユーザーが達成したいモノゴトをうまく抽象化し、その表現を的確にすることが重要になります。

　僕はモデリングという作業を、その「モノゴトの抽象化」、あるいは「モノゴトの概念化」であると考えています。

　となると、モデリングがうまいかどうかというのは「モノゴトの抽象化」ができるかどうか、しかも、それが他者に理解可能な状態、つまり、シンプルで、矛盾がなく、そして"いい感じ"であることが求められます。

　モデリングの"正しさ"は難しい問題です。正確な地図が読みやすいとは限りません。僕らが一般的に"正しい地図"と思っている地図帳も、縮尺に応じてデータのレイヤーを追加したり削ったり、色を分けたり地図職人のたゆまぬ努力の成果であって"絶対的に正しい"わけではありません。歩行者用と車用、あるいは観光用と道案内用の地図は違いますよね。

　モデリングには、元となる情報が必要です。僕は"外圧"と呼んでいます。企業システムを作る場合は、企業そのもの（組織などの静的な構造）や業務（フローなどの動的な構造）をヒヤリングしてモデリングを行います。

　道案内の地図でいえば道のりが外圧になります。それは俯瞰的に捉えた"正しい"道の構造と、移動するにあたって重要なランドマーク（角のタバコ屋）です。ここで重要なのは必要でない情報は取り出さない＝省くということです。人は抽象化された空間を認識する能力を持ちますが、一方で断片的で部分的な理解力しか持ちません。大量のデータは事前にフィルタリングしないといけません。だから、道ばたに生えている花がいかにキレイでも地図には書きません（ま、あえて書いてある地図も場合によってはイイですけどね）。

　先ほど"外圧"と書いたからには"内圧"もあります。内圧は作り手側の都合のことで、作りやすさといえるでしょうか。モデリングが完成しても、それを現実的にソフトウェア化できるとは限りません。コストや期間、そして純粋に技術的な問題によって「作れないモデリング」というのもあります。

　地図で喩えれば、チラシの裏側にぶっといマジックで書かなきゃいけない場合と、机に座ってパソコンを使って一日がかりで書く場合では、作られる地図が違うことが容易に想像されるため、抽象化も度合いも異なるはずです。

　余談ですが、ここまで書いてきたことは「オブジェクト指向だから」ということではないと思っています。その昔からソフトウェア開発は抽象化が重要だし、より抽象化の具現が簡単な技術を考えた結果として生まれたのがオブジェクト指向です。技術はニーズから生まれるものので、その逆ではありません。

　さて、このように「外圧を取り入れつつ、内圧も考えつつ、いい感じにモデリングする」のがITアーキテクトの仕事です。もうすこし順序で書くと「現実世界を注意深く観測しつつ、作る側の都合も考えながら、自らの認識によって抽象化を行い、段階的にモデルを詳細化していく。いい感じに」というところ。

　"いい感じに"というのが、まだまだ体系化されていない部分です。ていうか、体系化は無理なんでしょうね。パターンとか、それを目指しているわけですが成果としては限定的であるのはご存じの通りです。

　しかも、ソフトウェア開発は歴史が浅いため、作る側の制約（内圧）が非常に大きくなります。（ただし、内圧の革命が起こることで抽象化の実現レベルが一気に変わることがあります。Google MapsからAjaxが生まれた以降のWebアプリケーションの進化は記憶の新しいところです）

　建築の場合は、近代史の中で「外圧を取り入れる」と「内圧を考える」という作業が少しだけ分離されていて、前者の専門家を建築家（アーキテクト）と呼びます。意匠設計と構造設計と言っても良いです。とはいえ、"いい感じに"の部分の体系化が出来ているわけではありません。そうじゃなければ建築家なんて必要ないですしね。ここら辺の話は拙著『拡張する空間』で藤本壮介さんが話をしているので興味があればどうぞ。

　モデリングするとはなにか、もう少し深く考えていくと微妙な問題も出てきますが、それは次のエントリにします。

　Agile Japanのものにアーキテクチャ要素を足したものになります。あわせて、まとめなどの書き方が少し変わっています。また、今回は「形ではない、型としての標準 」という言葉を使いました。

　23ページ目を補足。ケント・ベックがXP本に書いたハンドルの逸話は有名でしょう。

母を横に乗せ，ハンドルを握り... 最初はうまく行きました．でも， ちょっと油断した瞬間，車は車道を外れて砂利に突っ込んでしまいました． 母は車を道に戻すと，初めて運転とは何かを教えてくれました．

「運転で大切なのは，車を正しい方向に進めることじゃないのよ．大切 なのは，常に注意を払って細かく左右に方向修正していくことなの．」

　この話で忘れてはいけないのは、細かく左右に調整することに車が反応していることです。僕はこの「車の足回り」がアーキテクチャにあたると考えています。アジャイルで成功した事例を聞いていると、多くの場合（というか、ほとんど）アーキテクチャ設計がうまくいっており漸進的な開発に耐えることができるようになっています。アジャイルはプロセスだけがあってもだめで、その細やかなコントロールに対応するだけのアーキテクチャが必要なのです。

　なお、アーキテクチャ標準の8つの特性と11個の構成要素はある企業の事例なので、なにかの推奨ではありません。ただ、特性で捉えるということと構成要素で捉えるというのをマトリクスとして利用するのは分かりやすい手法だと思います。

　残念ながら会場にあまりいられずフィードバックが得られなかったので、コメントやTweetを頂けるとありがたいです。

『ユーザー企業における標準化のあり方 - 形ではない、型としての標準を目指して』

ユーザー企業側の立場から標準化に関わって感じているのは、これまでの「形」としての標準化の限界と、同時に「型」としての標準の必要性です。講演ではユーザー企業がおかれた状況の理解から始まり、型としての標準化として開発環境の整備とアーキテクチャ標準についてお話をします。

　というわけで、Agile Japan 2010で話をしたものにアーキテクチャ標準の話を追加してお話しするつもりです。平日昼間の有料イベントなので、既に申し込みされている方が対象でしょうが興味あれば参加ください。いちおう、申し込みはコチラから。

　にしても、QCconはいつも通りネタが豊富というか、FacebookとTwitterのエンジニアが日本で話をするのは実質、初めてな気がします。僕は講演時間しかいれないので、他のは聞けずに残念なのですが。

　またレポートはあげますね。

　資料に書いちゃったからあんまり書くことはないので、Twitterとか質問とか言い忘れたこととか補足。

・帰り際に牛尾さんに「標準化とか話し出すから何かと思った」って言われたのは狙い通り。「標準化って新しい仕事のスタイルを考えるってコト。実はクリエイティブな仕事なんだよ！」。

・太田くんが「おお、メタレベルで標準化というところか？ #aj10」ってツブヤいてたけど、その通り。ただ、メタレベルって言葉の意味が分かりにくいと思って「コトそのものではなく、コトの外側を標準化する」と書いてみました。

・もう1個、太田くん。「Excelは変更管理、問題管理をするツールじゃなくて、それを管理するツールから出力して報告書を整形するツールだよ (5) #aj10」。そう思う。統計分析もできるし、ビュワーとして優秀。だけで情報共有とかステート管理とかはさせない方がいい。

・木下さんに「"傾向性を与える"っていい表現ですね #aj10」、ふゆこさんに「"傾向性を与える＝自然にやってもらえるようにする #aj10」ってツブヤイてもらいましたが、ツールによる標準化ではコントロールするとか管理するという言い方は嫌いです。ツールを提供しても使わない人はいます。そうした場合、無理に使わせるのではなくて、使わない理由を見つけてソレを潰すようにしないといけません。

・牛尾さんから「ツールを提供していると表層しか理解しないエンジニアが増える。その点はどう考えるか」という質問があったので「それは僕も思うことがあるけど、老害」と答えました（追記：僕が変にゆがめて書いてしまったのでコメント欄も参照ください）。半分は本気。いまは技術要素やマネジメント要素が本当に複雑だし、それを学ばないと前に進めないというのは明らかに間違いです。とはいえ、技術を軽視して良いわけではないです。若いメンバーに事務局の手伝いをさせて、その中で学ばせる努力はしています。あとは向き不向きですかね。

・やっとむさんから「社内で勝手にツールを使っている人がいたらどうする？」という質問。これは「RedMine使っていた人がいたので内部統制上こっちにしてくれとお願いしたことがある」と話しましたが、他にも「ユーザー管理とか大変ですよ」とか「サーバはこっちで立てますよ」とか色々言って説得しました。説得はなんとでもなるので、まず、その事実をつかむことが大事。ここらへんは社内人脈とかインターマーケティングの世界です。

・初日の野中先生の話を聞けなかったのは平鍋さん曰く「今世紀最大の損失」だそうで、めっちゃ悔しいです。ただ、野中先生もITが面白いと気づいたらしく再演はありそうとのことなので、その機会を待ちます。

・クロージングの羽生田さんの自由っぷりにはどうかと思いましたがｗ、結論の「プロセスとアーキテクチャの結合」あたりには合意。僕も同じ問題意識です。資料で「コトそのものではなく、コトの外側を標準化する」と書いて開発プラットフォームを例に挙げていますが、もう1つがアーキテクチャの標準です。プロセスと構造の両面において「コトの外側」を標準化しようとしています。ほんとはそっちの話もしたかったけど自重した。

※4月2日には書店で手に入るようになるはずです。なお、6月後半にイベントを予定しています。5月ぐらいになったら募集すると思うので、興味のある方はこのブログかTwitter（@yusuke_arclamp）をウォッチしていてください。

　IT業界でも藤本壮介をご存じの人はいるでしょう。2008年には情緒障害児短期治療施設で日本建築大賞を受賞、今年は本書でも紹介されている武蔵美の図書館が竣工予定です。また、2009年にはNHKのトップランナーで紹介された日本を代表する若手建築家です。

　本書は 1.対話の開始、2.ITの視点、3.建築の視点、4.振り返りという4つの章から成り立っています。

対話の開始 – 「つくる」という循環
　建築家とITアーキテクトが対談をして何を話したらいいのか。初対面の僕らは”建築家/アーキテクト”という言葉から手探りで対談を開始します。そして互いの風景を交換するうちに、いくつかの言葉に話が集約して議論が進んでいきます。関係性、コミュニケーション、場、空間…、おそらく、それぞれの業界の中ですら捉える人によって意味が変わりそうな曖昧な概念ですが、それらの言葉を通じて、僕らは同じコトを違う方法で成し遂げたいのだという予感を獲得します。

ITの視点 – オブジェクト指向—空間の言葉
　ソフトウェア構造は均一ではなく、対象とする処理の特性/環境/将来性といった諸要件から様々な構造を取り得えます。過去からソフトウェアが対象にすべき処理は複雑化の一途をたどっていますが、同時に構造的な工夫も進化し続けています。この歴史を追いかけるなかで「機能から関係へ」と、そのデザイン意図が変わっていく様が語られていくと、建築とITが実は時代性を共有していることに気づくのです。

建築の視点 – 万里の長城—把握できない全体性
　藤本壮介の作品を見ていると、そこでデザインされている対象が構造物だけでないということが分かります。その設計や施工のプロセスを話すうち、建築の「関係のない関係の実体化」やITの「全体性の欠如」について議論は進みます。そして、建築とITの近似と、一方での相違に改めて驚くことになるのです。

振り返り - あとがき
　あとがきに書いたのは「物理空間と情報空間という2つの空間をいかに融合させるか」ということではありません。2つの空間が融合されることが予感として出現しているなかで、それぞれの業界で何をすべきかという片鱗です。この本に書かれているのは「歩き方」ではなく、「歩けるという予感」であり、掴まり立ちの幼児が偶然にも段差につっかかり「思わず歩いてしまった体験」なのです。

個人的な感想
　今読み返しても、ITと建築の密接で奇妙なリンクに驚かざるを得ません。本当に初対面で何もないところからスタートした対話が、こういった形で立ち上がってきた。それは構造によって物事を表現するという"構築者"という立場を通じて建築とITが互いに理解を示せたということかもしれません。

　一方で、僕にしても、藤本壮介にしても、それぞれの業界での"平均的な意見"の持ち主ではなく、むしろ既存の枠組みから脱却するために、常に疑いと好奇心から行動している者同士。本体から奇妙に伸びすぎた触手が偶然にも出会っただけで、その本体同士は歩み寄りたいなどと感じていないのかもしれません。

　だとしても、出会えて語り合えた経験は非常に刺激的で、この本を読む人にも同じような刺激があればうれしいかぎりです。ぜひ、BlogやTwitterなどで意見を聞かせて頂ければと思います。

謝辞
　この本は多くの人の協力でできています。編集者の羽角さんと延藤さん、ブックデザインをしてくれたPLUSTUS++の柴田さん、表紙写真を加工してカバー画像を作ってくれた村井さん、その画像加工フィルタを書いてくれた石橋さん、ありがとうございます。そして、この対談にインスピレーションを与えてくれた全ての建築家、ITアーキテクト、デザイナー、エンジニア、芸術家、科学者、その他の人々に感謝します。
　僕らは巨人の肩に立ち出現しつつある未来に向かっています。そして、この本も巨人の一部となることを願っています。

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

　今回はアーキテクチャではなくて開発プロセスに関する話をします。といっても、アーキテクチャと開発プロセスは互いに影響を与えるものなので基本的なスタンス同じ。より開発プロセスから見た話になるだけです。

　技術要素の複雑化、市場や顧客の激しい変化。全てのプロジェクトが同じような問題に直面するなかで、アジャイルで培われた開発実務プロセスの効率化手法は非常に有効です。具体的にはEclipse、Subversion、Maven2、Hudson、JIRA、Confluenceといったツールで構成された開発プラットフォームの導入をいかに行ったのか、そこでのフィードバック、課題などを僕の体験も交えつつ話したいと思います。

　最初に断っておきますがユーザー企業視点での話です。何度か「アジャイルは開発者にとっての自己満足に過ぎないのでは」と書いてきましたが、ユーザー側が音頭を取って実施しないアジャイルはアジャイルにはなり得ません。僕らSIerはユーザーの横に立ち、共通の目的に向かうパートナーになる必要があるのです。

　だから「アジャイルを導入しよう」という目的ではありません。ユーザー企業から見たシステム開発のコスト削減や効率化を達成するために、アジャイル的な手法を利用しているに過ぎません。もはや、アジャイルは普及期。目的ではなく、手段として織り込みながら利用するべきでしょう。

　題名を否定しまくりですが（平鍋さん、ごめんなさい！）、アジャイルの導入に苦労しているというのは目的を取り違えているのです。ユーザーが納得できないことをしても誰もハッピーにはならない。ユーザーが何に困っているのか。どうしていったらいいのか。その点を提示すればいいだけ。

　もちろん導入には現場レベルで問題も課題も困難もたくさんあって苦労はします。でも、変化に抵抗があるのは当たり前のコト。大事なのは"アジャイルである"ことではなく、全ての利害関係者が無理しないこと。サス会議での西村さんの言葉を借りれば"システムをきちんと作るという実感を利害関係者全員が持てるようにする"こと。それが持続できる開発プロセスの重要な点です。

　そう、だからデブサミでのpapandaの講演に対するアンサー講演なのかも。重力を突破しようとする者たちへ。そもそも君らを引っ張る重力なんてない。力に抗うのではなく、力を利用すればするのだ。スイングバイしよう。そういう話をしようと思います（PMの人が多いだろうから、このトーンでは話をしません。あしからず）。

　サステナブルは持続可能と訳されていますが『人間活動、特に文明の利器を用いた活動が、将来にわたって持続できるかどうかを表す概念』のことです。環境問題などに紐付けて話されることも多いので、聞いたことがある人も多いでしょう。

　ところが、サステナブルデザイン国際会議のくせに「サステナブルって言葉は嫌い。特に持続可能性という言葉は良くない」というトーンだったのは面白かった。つまり、サステナブルという言葉の意味や意義を考えなおしてほしいというメッセージです。これは非常に示唆に富んでいました。

生きる実感を手放さずにいれば自然にサステナブルにたどり着く
　このブログではお馴染み、リビングワールドの西村佳哲さんは

サステナブルというお題を、エンジニアリング・マターではなく、生命観の問題として捉えたい。

　と提言されていました。自らの生きる実感を手放さずにいれば自然にサステナブルにたどり着く。「実感を大事にするなら、何をしてもいいし、何になってもいい」と。

　これは、○○はサステナブルであるというような情報を頼りにするのではなく、自らの感覚を使って生きていくということです。つまり「誰かが用意した問題を解くのではなく自分で問題を発見する。自分が感じていることを掘り下げるということが大事」なのです。デザインは、この"感じる力"を支援するように機能しなくてはなりません。

　ところが、逆の働きをしていることが少なくない。西村さんが「美味しそうなラーメン屋問題」と呼ぶもの。「最近、美味し"そう"なラーメン屋がたくさんある。毛筆を使った看板やコダワリの○○というメッセージ。でも、実際に食べてみてがっかりすることも少なくない。そういうダブルバインドが増えている。デザインが本来の能力以上に見せてしまう。これを続けていると、人は『どうせおいしくない』と、物事に対する感性を閉じてしまう」。デザイナが単に流行語としてサステナブルを処理してしまい、結局は消費文化を促進しているのだけではないか。そうした警鐘を鳴らす内容でした。

変わることへの恐れから離れ、冒険に出よ
　IDEEや自由大学の創設者である流石創造集団の黒崎輝男さんは「ずっと続くなんてものは存在しない。人は必ず死ぬ。建物は必ず壊れる。不変であり続けるモノなんてないという前提から出発すべき」という話から伊勢神宮の式年遷宮と鎮守の森を例にあげて「一方で、物は変わっても、残り続けるナニカがある。それを大事にしないといけない」と提言。

　だから「物の生産と消費のサイクルを前提とした現代社会では、サステナブルを目指してもたどり着けるはずがない」のです。では、何が必要か。それは"変わることへの恐れから離れる"こと。現代社会は仕事も生活も安定していることを前提として、そこからのドロップアウトを許さない。例えば住宅ローンと長期雇用の組合せがあるから仕事を辞められない。でも、変わらないものなんてない。もっとあきらめて、いい加減（良い加減）でいいのではないか。そういう「これまでの常識から離れる」ことを続けるべきと言われています。

　具体的には「鉄やアルミニウムや洋服は、都市にあるものを資源として再利用できれば数年間は生産する必要がない計算になる」という例を挙げ「都市にこそ冒険がある。都市の可能性を別の形で探るべきだ」と続けていました。

　
付き合い続けるために無形性をデザインせよ
　一方、アミタの熊野英介さんはバリバリのビジネスマン。「企業にとって大事なのは顧客に買い続けてもらえること、そして利益を出し続けていくこと。そのためには物のデザインではなく、関係性や無形性のデザインが重要」と指摘、「人間にとって孤独こそが最大の貧困。それを満足させることができるかどうかが大事だ」と言われていました。森林ノ牧場の話はすごく面白いです。

　僕は「工業資本は時間が経つほどに劣化するが、自然資本や社会関係資本は豊かな時間を過ごすほどに増大する」という言葉が印象的でした。

サステナブルなソフトウェアは可能なのか
　さて、感想。エントリに時間がかかってしまったのは、僕が最近のテーマにしている「成長するシステム」や「持続可能な開発」と、どう関わるのか、サステナブルなソフトウェアは可能なのかを考えていたから。

　企業システムのソフトウェア開発が残念な状況にあることは言うまでもありません。市場や顧客の変化に追従できず、数年ごとの再構築によってしか前に進めない。そうでなくて、もっと育てられるシステムができないか、開発を継続できるようにできないのか。

　このコンセプトが会議の流れとズレているとは思ってません。では、そのためには何をしなくてはいけないのか。

　アーキテクチャ論やプロセス論を語ることはできます。システムがいかにあるか、プロセスがいかにあるか。でも、やはりそれだけでは足りないのです。システムはゴールではありません。僕は『ソフトウェアアーキテクトが知るべき97のこと』に『システムではなく、コミュニケーションをデザインせよ』というエッセイを寄稿しました。

システムユーザーはいないほうがいい。いるのは「コミュニケーター（コミュニケーションをする人）」です。アーキテクトは、ユーザーと呼ばれる存在のいない、コミュニケーションの総体をデザインするべきなのです。

　組織は人のコミュニケーションによって脈打ちます。ソフトウェアは、そのコミュニケーションを助けるために存在するのです。だから、システムがどうあるかを考えるためには、コミュニケーションをデザインしなくてはならない。

　そこでサステナブルにあるためには、西村さんによれば「生きている実感を感じさせる」ことであり、黒川さんによれば「変化を恐れず冒険に出る」ことであり、熊野さんによれば「ずっと付き合うための無形性を考える」ということ。

　僕らがやっていることはソフトウェアを作ることです。でも、僕らの"仕事"は人と人をつなぐことであるべき。これは企業システムでもウェブサービスでも同じです。

　そこに至るためには僕には修行が足らないなぁと感じていますが、僕が修行してもたどり着けるわけでもないでしょう。幸い、世の中はこの方向に進んでいます。

　デブサミのベストスピーカーランキングで「アーキテクチャに憧れろ」が5位に入りました。感想を読んでいても、"ソーシャルなアーキテクチャ"というのに反応がたくさんありました。すごい勇気をもらいました。

　ソフトウェアの可能性はまだまだある。それを色々な形で共有し、少しでも切り開いていきたいと感じています。本当に楽しみです！

　一言目が「インターフェースがダメだね」。僕が「ユーザーインターフェースの話ですか？」と返したら、「そういう一部分の話じゃない」と。

　そもそもインターフェースは「接合部分、接触面、接点、仲立ち、連絡（係）、橋渡し（役）」のこと。益田先生は「ソフトウェアの役割はインターフェースだが、それが出来ていない」と言われているわけです。では、何と何を仲立ちするものなのか？

　僕は話を通じて"人と仕事"ではないかと感じました。つまり、ソフトウェアは人と仕事をインターフェースするのです。

ソフトウェアを導入すると、なんでも複雑になる
　益田先生は「病院でも役所でも様々な手続きがシステム化されているけど、家からパソコンでやろうが、窓口でやろうが、全てが複雑すぎる。ソフトウェアを使うならシンプルにならないと」と言われていました。

　そうなんですよね。業務をそのままシステム化する、複雑な業務を複雑なシステムにするって、言ってしまえば誰にでも出来る。いや、むしろ、より複雑になることが多いのではないでしょうか。「ソフトウェアを導入すると、なんでも複雑になる」。

　それは我々の構築過程にも問題があります。システム化しようと、人間が行なう作業では曖昧に進められていたプロセスをマジメに分析をすると、当然、明示される分だけ複雑になります。しかも、すべてのパターンを網羅することなんかできていないので、複雑なのに融通が利かないという状態に。

　僕が「いまのソフトウェア開発はクライアントの業務を分析し、それをシステム化するというのが一般的になっているんですよね」と言うと「そこだよ。提案していかないとさ」とバッサリ。

　そうなんですよね。ソフトウェアというのは人間が行なう作業に比べて正確無比で距離や時間を超えられるけど、融通が利かない。だから、人間の作業をソフトウェアに代替させようなんて考えても無駄。

人と仕事をインターフェースする
　そうではなくて、人間がやろうとしている課題を的確に表現し、解決までのプロセスを導き、たどり着けるように支援し続ける。それが"人と仕事をインターフェースする"ということではないでしょうか。このインターフェースを考えることこそ、僕らが最初にやるべきなのです。

　「それがデザインでしょ」と、さらっと益田先生に言われてしまいました。うん、確かに全然できていない。

　ただ、簡単なことではありませんね。先生も様々な専門分野の知識が必要になるだろうと言われていました。少なくともソフトウェア工学だけではまったく足りない。心理学の各分野（認知、環境、生態）、グラフィックデザイン、それに言語、数学、経済、法/政治といったものも含まれるはず。そういった分野のプロフェッショナルを巻き込みながらソフトウェア作りをしていかないと、とても"人と仕事をインターフェースする"ことをデザインなんてできない。

　ソフトウェアが人と仕事をインターフェースするようになるのは、まだまだ多くのことが必要そうです。