1億円の案件が舞い込んでくる。発注者が信じて作り上げた完璧な仕様。僕ならそれを美しくデザインできる。綿密に考慮されたデータ設計、拡張性と柔軟性に優れたアーキテクチャ、シンプルで無駄のないUI。おそらく利益も普通に確保できる。「でも」と僕は思う。その仕様はトレンドからすると古びた機能。どう考えても多くの人に使われることはない。この投資は無駄に終わるな。

　1000万円の案件が舞い込んでくる。発注者は自分のビジネスに情熱を持ち、これから作られるシステムに愛情を持っている有能で魅力的な人物。仕様はない。ただコンセプトがある。僕は彼とたくさんの話し合いを積み重ねてデザインをしていく。おそらく荒削りなデザインにはなるだろうけど、このシステムは世の中にとって大きな意味を持つはずだ。多くの人に受けいれられ、多くの人を助けるだろう。「でも」と僕は思う。1000万円じゃ、赤字だな。

　どちらかだけ受注できるなら、皆さんはどちらを選びますか？

　僕が「悩むなぁ」と言ったら、後輩に「私なら1億円ですね」と即答されて、ちょっと答えに詰まってしまいました。

　で、本当は悩むまでもなく僕は1000万円の案件を選ぶんです。その瞬間は、後輩の手前「マネージャーとしては1億を選ぶときもある」とか言うべきかも、とか思っただけなんです（苦笑）。

　なぜ1000万円の案件を選ぶのか。それは1000万円の案件の方が将来につながるからです。「何を作るのか」よりも「誰と、なぜ作るのか」を大事にした方がトータルのリターンは間違いなく大きい。

　そして、より正確に答えるなら「1000万円の案件をやって1億円儲かる方法を考える」のです。それだけ価値のあるシステムなら出資してリターンを得ることも可能なはずです。やりたいことをやって、成功すればいい。

　97アーキテクト本の1つ目は「システムの要件よりも履歴書の見栄えを優先させてはならない」というやつで、これは色んな人に「面白い」と言われました。

あなたのキャリアにとって何よりも大事なのは、「前のプロジェクトでいい仕事してくれた」と思って、あなたを推薦してくれる顧客が山ほどいる状態です。流行りの言語やらパラダイムで、優れたオブジェクトを作ったなんてことよりも何十倍、何百倍も大事なことなのです。確かに、優れた最新のトレンドやテクノロジーを知っていることは大切です。生死を分けるぐらい大切ですが、そのために顧客を犠牲にしては本末転倒です。

　「あなたのキャリア」と言い切るあたりがアメリカンな感じですが、企業としても同じことが言えます。

　自分がやりたいと思うことと仕事での成功は両立します。これは二兎を追うことにはなりません。そもそも1匹のウサギなんです（「羽」は食用の時なんだとか。ちょっとwikipediaあやしいけど）。

　「仕事のために自分のやりたいことを曲げる」とか「自分がやりたくないことをしないために仕事を諦める」とか、あるいは「この苦しい仕事を超えると、自分は成長できる」とか。そういう考え方でいる必要はありません。こういう考え方をすると、どうしても「その問題」に捕らわれてしまう。「その問題」の提示したルールの中にはまり込んでしまう。

　まずは、自分がやりたいことと仕事での成功を大事にすればいい。自分のルールをはっきりさせる。そして与えられた問題から距離を置く。そうすると折り合いが付くところが見つかるものです。

追記：
　この場合で言えば、仕事の成功としては1億円の案件だし、自分のやりたい事としては魅力的な人物と世の中に意味のあることができる1000万円の案件です。ここで考えを止めてしまうと与えられた問題に捕らわれてしまう。どちらかを選ぶには「1億円を得るためだから、使われないと分かっていてもシステムでも作る」とか「自分がやりたいことだから赤字になってもやる」とか考えるしか無くなります。

　でも、両方とも大事にしたいと思って問題から距離を置けば「1000万円の案件で1億円儲かる方法はないか？」と思える。もちろん、そんなに簡単に良い方法が見つかるわけじゃないけど、少なくとも「どちらかを選ばなくては」という強迫観念からは逃れることができます。

　自分がナニカを選択するとき、自分の気持ちを曲げて選択肢に倒れ込む前に、本当にその選択なのか？ということを問い直すのです。そうするだけで、だいぶ気持ちが楽になります。

（なお問題に捕らわれるとか、問題から距離をおくとかについては、こちらも参照ください。『振り子のルールを壊す』）

（追記ここまで）

　この時代に自分のキャリアに自信が持てる人は少ないと思います。特にIT業界は変化が大きいので、いま存在しない職種が大事になるかもしれません。そんなときだからこそ、自分のルールを大事にして欲しいです（ルールも時々で変えれば良いんです。ルールに固執すると、それはそれではまり込むので）。

　僕からできるアドバイスは1つだけ。「何を作るのか」よりも「誰と、なぜ作るのか」を大事にした方が良い。人の"縁（えん）"は、本当に大事。これが縁だと思ったら突撃しましょう。

　行動が縁を呼び、縁が未来を変える。

　3年前に頂いた言葉ですが、フリーランスから会社員になった今でも大事にしています。

ソフトウェアアーキテクトが知るべき97のこと Richard Monson-Haefel オライリージャパン 2009-10-05 by G-Tools

　ソフトウェアを作っていると世界の変化が目に付きます。

　ソフトウェアにおけるデザインというのは、人が環境から情報をすくい取ってモデルを作ることです。情報は地から図として区別することで浮かび上がります。当然、これはデザイナーの認識によって行なわれることです。つまり、情報にはデザイナーの世界"観"が反映されます（複数人でやるので、そのメンバー間の緩やかな合意というのが正確な説明でしょうが）。

　モデルは、モデルを作る瞬間までに知り得た情報によって構成されています。先ほど書いたように情報は認識によって作られるので、言い換えると「モデルは、そのモデルを作る瞬間の認識によって構成されている」ということになります。

　一方で、時間が過ぎれば環境も変わるし、僕の認識も変わってしまいます。なので、モデルは、どの時点でどんなに適切であったとしても、次の時点には適切でない可能性があります。この変化にあがなうことは、現在のソフトウェア工学ではできません。

　なので、経験的に変化を予測し、構造上の工夫を凝らすか、イテレーティブなプロセスによって対応を行ないます。ソフトウェアデザインパターンやXPは、こうした背景で説明することができます。

　では、変化に本質的に対応することは出来ないのか。

　有望視されているのが数理科学的な発展です。最近、統計学の先生と仕事をしてみて数学が状態の変化を表現できることに素直に感動しました。とはいえ、それとて決定論的に振る舞わざるを得ない。もちろん数学上のモデルを正しく定義できれば、実証主義的に正しさを証明できます。でも、所詮、未来を予測することは不可能だと思うんですよね。限定されたミクロには可能だとしても、マクロには無理。

　こうしたモデルと現実のズレというのはソフトウェアに限らずあらゆる場所で発生しています。

　たとえばサービス産業代表の小売であっても、客をモデル化して対応（接客）するというのは一般的な手法です。マニュアル主義がある程度機能するのは枠としてのマニュアルがありながら、最終的には環境（＝客）に対して主体（＝スタッフ）がインタラクティブに場を形成するからです。その場によってズレは解消され、モデルは適切に機能しえます（しないこともあるけど）。

　一方で、建築やソフトウェアではモデルは構造物として構築されてしまいます。当たり前ですが構造というのは安定的な存在なので、当初のモデルを長い時間保持します。ですから、モデルを元にした構造物と現実世界がズレているのは当然のことです。

　建築におけるズレの解消はどうやって行なわれているのでしょうか。100年とか1000年前の建物が機能するのは、それを利用する人が建物に対する関わりを調整しているからでしょう。例えば内部設備の入れ替えだったり、あるいは宗教建築のように構造を維持することに意味があったり（多くの場合は両方ですね）。

　ところが、ソフトウェアではズレの吸収が非常に難しい。そもそも、ソフトウェアとユーザーのインタラクションはディスプレイ、キーボード、マウスといった非常に貧弱なデバイスによってしか行なわれません。そこには多様な関わり合いを創出するノリシロがありません。近年でこそiPadのようなステート端末ができてタッチによる直感的なインターフェースが広まりつつありますが、それとて完璧ではありません。

　というわけで、ソフトウェアというのは別に他の産業と対して変わるモンでもなくて、ただ、まだまだ成熟していないだけだということが分かります。ソフトウェアで今がんばるべきなのは、ユーザーが自律的にズレの解消を行えるようにユーザービリティを成熟させることです。ま、Appleがやっていることですが。

　さて、ソフトウェアが未成熟ですね、というだけでは話は終わりません。ソフトウェアの可能性は、ソフトウェア単体ではなく、ITとして捉えるべきモノです。その代表例がインターネット。Twitterは試されましたか？ソーシャルウェブ/アプリケーションは、人と人のコミュニケーションに新たな有り様を生み出しました。

　そもそも世の中は人間同士の関係によって営まれています。ですから、その関係のあり方を変化させることができれば、新たな可能性をもたらすことができます。このBlogで何度も引用している西村佳哲さんの言葉、

私ははじめてインターネットに触れた時、ものすごく感動しました。どんなページよりも、インターネットという大きな仕組みそのものに感激したのです。「これこそデザインだ！」と思った。デザインとは色や形ではなく、人の世界観を拡げる仕事でしょう？

　一方、先日、清水博先生に会ったときに言われたのは「グローバル化によって全体性が失われているからこそ、関係性の創出についてITにできることがある」ということ。

　この視点では建築とITは交わりきれていないし、まだまだ成果も出ていないと感じています。建築だって社会における人と人の関係をデザインしているのに、なぜ同じコトをしているITと交わらないのか。考えてみれば不思議なのです。
　たとえば地域センターの建物と地域SNSが、建築家とITアーキテクトによって同じコンセプトでデザインされるとか良さそうなモンなのに。なんでないんですかね？事例を知っている人がいたらぜひ教えてください。

　ITに期待されていることはとても多いのです。ITのデザイナーは真摯に人間に向き合い、人間の集合（＝社会）に向き合い、世界に向き合う必要があります。僕自身が出来ているとは思ってないですが、間違いなくそう。そのために建築家が考えていることを除くのは１つの手段でしょう。
　
　ちょっと飛躍しちゃいますがITが世界観を反映するのであれば日本人の世界観には可能性がある。ある、と信じたい。グローバルでジャパンが相対的にプレゼンスを失うのは間違いからこそ、ジャパンのITにできることはたくさんあると思っています。
　

　こうした議論を通じて、建築家という人達がソフトウェアやコンピュータの可能性についてどう考えているのかを知るのは楽しい体験です。建築家は"社会的な問題を発見し、構造物によって解決するように訓練をされた職業人"です。そういう人々がソフトウェアをどう捉えているかを知るのは、ソフトウェアと社会の関わりを考えるための大事なプロセスと感じています。

　なお、ここでいうソフトウェアの可能性は"計算"のためのものではありません。建築では建物を立ち上げなきゃならん（しかも、崩壊しないように）という分かりやすい制約があるため構造計算としてのソフトウェアの利用は重要です。

　ですが、ここでは"意匠"に関わる部分を考えます。意匠とは「物品（物品の部分を含む。）の形状、模様若しくは色彩又は これらの結合であって、視覚を通じて美感を起こさせるものをいう。（意匠法2条1項）」という定義ですが、もう少し広くとれば建物の社会的な意味や社会との関わりを表現したものになります。

　先に言っておきますが、意匠におけるソフトウェアの利用を「鉄筋コンクリートとガラスという形態自由度の高い素材を手に入れた後のトリックアート的な要素に過ぎない」とか「所詮はアナロジーのネタに尽きただけの亜種」とかいうような面はある気がしますが、本質的ではないので省きます。

アルゴリズムが生み出すもの
　本題。キーワードは「アルゴリズム」です。Wikipediaによれば「問題を解くための効率的手順を定式化した形で表現したもの」。

　コンピューターは人間にはできない精度や量の処理をこなすことができます。コンピュータの仕組みは、入力データに対して"プログラムによって定義されたアルゴリズム"が処理を行なうことで出力データを得るというものです。つまり、アルゴリズムには問題を解くための手順であると言えます。

　逆に言うと、アルゴリズムを組むためには問題をプログラミング可能な形式に変換する必要があります。これはモデル化という作業です。

　さて、建築の設計は、様々な要件（顧客にとって自覚的であるかは関係なく）に対して建物という答えを提示します。これを「入力（要件）に対して出力（建物）を得る」と理解すると、過程をアルゴリズムとして位置づけ可能になります。このようにデザインそのものをアルゴリズムに見なすというあたりがポイントです。

　セシル・バルモンドの展示では、自然の形態に着想を得たアルゴリズムによって問題の解決が図られています。花のような競技場、互い違いになっている橋、無数のキューブで作られた美術館など、なんともいえない魅力に溢れた構造物ばかりです。

　自然の形態は一見すると複雑でも裏側にある法則はシンプルなものであることが知られています。複雑系、フラクタル、カオスといった用語は聞いたことがある人も多いでしょう。そうした法則はソフトウェアで扱うことができ、アルゴリズムとして表現が可能です。展示には作品例も出品されていますが、入力されたデータからアルゴリズムによって複雑な構造が段階的に作られている、しかも、それが現実に構築可能であるというのは実に興味深いものです。

　こうした議論は世界の近似としてソフトウェアが利用可能であることを示しています。『アルゴリズミック・アーキテクチュア』では、アルゴリズムを人間の思考と同等のパートナーとして捉えるような概念を提示しています。

アルゴリズムは世界を表現しない
　では、本当にソフトウェアは世界を再現できるのでしょうか？

　僕はできないと考えています。モデル化は人間が環境から意味を取り出す行為です。意味やモノが環境に直接存在するわけではありません。意味やモノは環境から情報を取り出した人間の中に存在します。つまり、ソフトウェアが近似として表現している"世界"というものは、その人の中に構成されている"世界観"というべきものです。

　ですから、ソフトウェアは決して構築者を超えることができません。超えているようにみえるのは、人間が無意識にモノゴトを分けたり、省いたり、集約したりしてしまうクセに影響されずに、ただ生真面目に処理を実行しているからです。

　『アルゴリズミック・アーキテクチュア』は、概念としての整理法は面白いのですが、ちょいちょい矛盾があり、人間中心的な言説があるので読むのに注意が必要です。その点をさっぴけば興味深い本だと言えます。

モデルと現実のギャップを埋める手法
　さて、ソフトウェアが世界を再現できないなら、なぜモデルを使って現実の建物をデザインすることができるのでしょうか。

　それはモデルと現実のギャップを埋める作業をしているからです。

　建築の施工過程は、抽象化された設計図と現実のギャップを埋め、そこで発生する自然の揺らぎを管理する体系的/形式的な手法として確立されています。例えばコンクリートがちゃんと必要な強度に固まるように流し込むテクニックとか。そういった現場レベルの抑えが効いているからこそ、モデルが現実の建物になることができるのです。

　余談ですが、ソフトウェア業界でも、同じようにモデルを取り出し現実での構築を行なっていますが、その結果は悲惨なものです。これは建築の施工のように、モデルと現実のギャップを埋めるための体系的/形式的な手法が確立していないと考えるのが正しいでしょう。この確立は時間のかかる作業です。建築だって数千年かかっているわけですし、まだ、50年程度の歴史では難しいのです。

建築とソフトウェアの対話
　というわけで、思いつくままにソフトウェアと建築の関係について書いてみました。いろんなところを端折り過ぎで意味不明なところもあると思いますがBlogなので勘弁してください。

　僕にとって建築業界は憧れの対象です。建築のような教育体系がソフトウェアでも充実してくれば、もうすこし社会意義のあるソフトウェアが増えるのではないかと思います。100年かかる話だと思うので、僕が死ぬまでにきちんとした大学ができれば十分でしょう（そこに関わるのが、僕のささやかな夢です）。

　なんにせよ、建築業界とソフトウェア業界は、もっと互いに語り合う機会も言葉もたくさん持つべきだと思います。その機会の１つを近いうちにお届けできる予定です。

アルゴリズミック・アーキテクチュア 田中 浩也 彰国社 2010-03-10 by G-Tools

さらに@yusuke_arclampさんの「手紙でもメールでも情報に形を与える意味では同じ。ただし、手紙では身体性の痕跡が情報そのものに残り、メールではデータという論理モデルに抽象化される」なんてつぶやきが目に飛び込んでくると、これは「形の会」なるものを開いて、徹底的に話をしてみるとおもしろそうだなということに。

　形とは何かから始めると長いので、ここではコミュニケーションという視点から「他人と共有できる形態」という定義に留めておきます。たとえば言葉、映像、物体など、あらゆる表現は「形」と言って良い。つまり、人間は形を作り出してコミュニケーションをしているわけです。
　ですから、手紙でもメールも「形」の一種といえます（これまたクドイですが、ここで書いた手紙やメールは「型」としての概念ではなく「この手紙」や「このメール」のことを指します）。

　さて、手紙とメールを考えてみると、どちらも文字によって伝えるという点では同じです。ですから、僕らは「書く」という行為を通じて手紙やメールと関わります。そこまでは一緒。

　ところが、「書くという行為」と「結果として生み出される形」の対応について考えると、手紙とメールでは異なる点であることに気づきます。

　手紙では、書くという行為の関わり先は「この手紙」そのものです。ペンを使って痕跡を刻んでいくという"形作る行為"と、その結果には緊密な関係があります。ですから、手紙では、「この手紙」そのものが他人と共有される形になります。

　一方、メールでは、書くという行為の関わり先は「メーラー（＝メールソフト）」になります。そして、タイピングという"形作る行為"によって生まれるのは「メールのデータ」であり、他人と共有されるのも「メールのデータ」です。
　「メーラー」と「メールのデータ」という分別を付けると、「メーラー」というのは形そのものよりも「人がメールを書くという行為のあり方」を定義していると考えられます。
　むしろ、形はメール型として事前的に共有されており、それを変えてしまうことはソフトウェアの世界では標準からの逸脱として嫌気されることはご存じの通りです。

（個人的な解釈ですが、メーラーというソフトウェア全体が「飾り」であるも言えます。メールにおいて共有されるのはデータで、そのデータをいかに書かせるか/見せるのかがメーラーの本質なのですから）

　ここから先は皆さんで感じていただければと思います。手紙を書こうと思うとき、どうやって手紙を選んでいますか？あるいはメールを書くときにどうやってメーラーを選んでいますか？もっと対象を広げて、他人にメッセージを伝えたいときに何を基準に「形」を選んでいるのでしょうか？アナログな形とデジタルな形には、どういう区別があるのでしょうか。

　我々はソフトウェアなしに生きられない世界に住んでいます。たとえ、あなた自身が使わなくても、あなたが属している公共機関は必ずソフトウェアを使っているでしょう。ですから、ソフトウェアとどう付き合うべきかというのは避けられないテーマ。
　我々は既にソフトウェアに対する関わり方を無自覚に獲得しています。しかし、それが豊かな体験かは別の問題。僕自身はより豊かな体験になっていくべきだと感じます。では、どうやったらそれが実現できるのか。社会学的なアーキテクチャというのは、そういった視点なのです。

　さて、前述の「形の会」ですが3/4（木）に第1回会合をすることになりました。興味がある方は連絡をいただければと思います（小部屋なので参加を確約はできませんが）。

　まずは問題意識。

2000年から2009年までの10年間の情報システム市場は成熟期の苦しみであったといえる。パッケージ・ソフトや開発ツールの進化，オフショア開発の台頭，オープンソースの普及など新しい技術や開発手法が断続的に登場し，開発生産性は飛躍的に高まった。しかし，人月モデルは変更されず，生産性向上要素は情報システム開発事業者にとって両刃の剣であった。一方，情報システムはユーザー企業にとって重要ではあるものの，その度合いは段階的に引き下げられていった。情報化投資は縮小し，景気が回復しない限り増加することはないだろう。

　デブサミの資料にあるとおり2002年からは1%成長しかしていません。しかも、ここ数年での変化は常に光と闇がありました。生産性向上が売上増加に繋がらないという話は有名ね。他にもオープンソースは多くの開発者を助けましたが、一方で価格破壊を招き、能力格差を広げてしまったと感じています。製品の変化が早すぎるためノウハウはすぐに陳腐化し、ベンダーサポートがないため手厚い教育は受けられません。

　これからの10年を考えたとき、やはり旧来型のSIビジネスが成熟期から衰退期に向かうことは避けられないと見るべきでしょう。しかし，新しい企業システム開発市場が生まれるという予感があります。例えばクラウドですね。

クラウドが示したことは，「システム開発が作り手（開発者）の論理から，使い手（ユーザー）の論理に移行している」ということだ。これは産業の根本的なあり方を変える出来事である。企業システム開発は家内制手工業の時代からようやく脱しようとしている。「課題を分析して最適なソリューションを提供する」というのは，聞こえは良いが，その実は原始的な産業スタイルである。

　この変化はクラウドだけではありません。リーンやOSGiも、その一旦でしょう。兎にも角にも、これまでの常識にとらわれず、ユーザー視点で"価値があること"を見抜く視点が必要なのです。

　さて、これで2年半（全30回！）の連載も終了です。始めたときは1年ぐらいで終わると思っていたので、こんなに長期にわたって続けられたことに驚いています。まずは編集の松山さんに感謝です。毎月のように編集＆校正バトルのなかで文章を磨いていただきました。また、読者の方にも感謝いたします。僕のコラムは「高評価ランキング」と「悪評価ランキング」の両方に同時に入賞することがあったそうで、そういうよく分からない連載を続けられたのも皆様からの反応があってのことです。

　連載はつらいですが毎月のアウトプットとして続けるのは大事な習慣なので、また、どこかでやりたいと思っています（誰か仕事くださいｗ）。では、また、どこかで。

　資料はコチラ。

　この資料を作るにあたって経済産業省の特定サービス産業動態統計調査を調べて思わず声を上げずにはいられませんでした。受注ソフトウェアの売上伸び率は1995年から2002年まで10%を超えているにも関わらず、2002年以降の平均は1％。これは完全に成熟期をしめす数字です。しかも、リーマンショック後では-3.0%になっており、完全に衰退期モード。労働集約的、手工業的なソフトウェア開発の限界を感じたのです。

　では、これから何が起きるのか。以前もプレゼンしたとおり「使い手視点での経済合理性が進む」ということしかありえません。代表的なのがクラウドです。ですが、多くのエンジニアやユーザーは言うのです。

「制約が厳しい。これでは、必要な要件をクリアできない」

　その通りです。ですが、そこで僕らは小説家 開高健さんの言葉を考えなくてはいけません。

何かを得れば、何かを失う。そして何ものをも失わずに次のものを手に入れることはできない。

　何ものも失わずに前に進むことはできない。あなたが必要としている要件とは、本当に次の世界で必要なことなのか？過去の常識に縛られているだけではないのか？まったく次元の違う価値を手に入れるとき、これまでの価値観にどれほどの意味があるのか。新しい時代には新しいアーキテクチャが必要なのです。そして、それを手に入れるためには何かを失わなくてはいけない。

　そう、ここで我々は過去の常識に立ち向かうのです。例えばオブジェクト指向とアジャイルプロセス。変化に適応するために最強と呼ばれているこのタッグさえも疑ってかかる必要がある。そして、その視点に立って考えればオブジェクト指向もアジャイルプロセスも優れた手法ではあるが、それだけでは足りないと、そこに気づくのです。

　僕は「これからのアーキテクチャ」に構造の不変性を利用した
・変化の影響を管理する。→モジュール
・変化の方向を管理する。→プラットフォーム
という2つのものをあげました。それぞれOSGiとエンタープライズソーシャルアプリケーションを例としてあげています。

　これが正解だとは思わないでください。もちろん、僕は正解に近いと信じています。だからこそ、取り組んでいる。でも、変化の時代、変革の時代にあっては信じることが全てとはいえ、それだけにすがり続けるのも破滅への道のりです。どうぞ、自らが何処にいるかに自覚的であってください。

　どうも僕には「次は、君の番だ。」なんて言うほどの心の広さはないようです。僕に付いてこられても困る、みたいな。そんなたいした人じゃないし。でも、なぜだが僕の目には他の人には見えないナニカが見えてしまっているようで、それが見えてしまったのであれば、みんなに伝えないといけないとは思う。だからこそ、こうした話をしています。もっともっと伝えたいことがあるけど、どうにも伝えられない。そんなもどかしさを感じる日々です。

　だから他人の言葉を借りました。

何かを得れば、何かを失う。そして何ものをも失わずに次のものを手に入れることはできない。

　僕には「共に月に行こう」と言える度量はない。でも、月があることは分かる。だから「月はそこにある」と言い続ける。「共に月に行こう」と言える日まで。

　なお、このセッションのきっかけはデブサミの事前企画会議で「アーキテクチャの今後について語るセッションが欲しい」と言ったら@t_wadaに、「じゃ、ゆーすけさんやって」と言われたというもの。少しだけ「共に月に行こう」と言い出せた気がします。チャンスをありがとう。

　97本をきっかけにしたセッションでしたが、結果から言えば97本を超えることができたのではないかと思っています。そのくらい未来に可能性を感じさせるセッションでした。

　アジェンダは以下の通り（「アーキテクチャに憧れろ」って題名にちなんだお題は直前の打ち合わせで皆に散々Disられたので泣きながら削除しました。半分本当です）。
・普段、触れているアーキテクチャは？
・アーキテクチャで失敗したことはある？
・この1，2年で注目しているアーキテクチャって何？
・未来にどんなアーキテクチャを作ってみたい？

　tudaってくれた人も多くて、いくつかログがあったので紹介しておきます。
・■デブサミ2010 アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション
・Developers Summit 2010 (初日) 私的不完全議事録 【DevSumi2010】
・デブサミ2010のメモ的なもの
・『ソフトウェアを作る上で、コードを書く以外に大事なこと』を実施。その後、何かの機会に岩切さんに「4人でやりたいんですよねぇ」みたいなことをボヤいたら「デブサミでやっちゃえば？」と言われ、それから色んな偶然の巡り合わせがあって、このセッションが実現したのです。

　前回の3人もだけど、今回の4人も本当に息がぴったりと合っていて、リズムが同じだから話も途切れない。壇上では互いに話す順番やバランスを意識し合っていて変な割り込みもなし。僕は話の流れるままに自分が聞きたいことを聞いていただけ（最後の質疑応答だけ我慢できずに口出ししちゃっだけど）。

　ログを見てもらえれば分かりますが、アーキテクチャの話から、アーキテクトとしての判断や資質、そして社会学的なアーキテクチャまで、本当に話が拡がりました。打ち合わせしてあったやり取りは20％ぐらいかな。あとは純粋に自分たちが話したいことを話したという感じ。

　3人とも、まぁ本当に個性的でコダワリも強いし、一言ではいえない魅力を持っています。舞台裏で話をしてても飽きない（楽屋でうるさくしてごめんなさい）。よく、そんだけ話のネタがあるよね、と。ちなみに、ほとんど雑談です。それから「お疲れ！」ってメールしたら、なぜだかゲームの話になちゃったのは秘密です。

　最後になりましたが、この4人でイベントができてすごい楽しかったです。オライリー社の本にもかかわらず快く会場提供してくれた翔泳社の皆様に感謝。サイン会の仕切りをしてくれたりしたオライリーチームの皆様にも感謝。それから来場してくれた皆様も本当にありがとうございました。

　3人へ。また、そのうちどこかで。

　内容は若手メンバー（1年目、2年目）の3名を対象に行なった開発演習です。当初は技術習得を目的とした開発演習だったのですが、僕がファシリテーターをすることになったので目的を『「聴く力、考える力、伝える力」という3つの“力”の習得』として、要件定義から開発までの広い範囲を実習したものです。そのために次のコンセプトに従って演習を組み立てました。

答えはメンバー自身で出す
　いわゆる開発演習だと要件定義書や仕様書ぐらいはありますが、今回はなし。「ユーザー役の社員」を用意し、要件は彼らに自由に出してもらいました。つまり、整理されていないし、技術的な可能性も検討されていないし、開発範囲も制限がない状態です。そこから「何を作るべきか」「なぜ作るべきか」を考えさせました。

間違っても良いからアウトプットを早く出す
　考えるというのは、腕を組んでやることではなくて手を動かしてやることです。整理されていない情報を矛盾無く構成するのは地道な作業です。小さく成果物を出しながら、あーでもない、こーでもないという作業を繰り返し、段々と見えてくるモノ。そのためには「間違っているかどうか」を気にしないでアウトプットしていくことが大事です。

すぐに周りのフィードバックをもらう
　3人寄れば文殊の知恵とはよく言ったもので1人でもんもんと考えていても良いものはできません。互いにアイデアを持ち寄り洗練させていけばいい。成果はチームで出すもの。1人では出来ないことでみんなでキチンと相談すればよりよい成果物に繋がります。

　細かな内容は雑誌記事に譲るとして、その中で利用したテクニックを紹介しておきます。
・モデリングを利用したインタビュー（時系列分析から機能分析へ）
・パワーポイントによる提案（ビジョン＞課題＞戦略＞戦術の落とし込み）
・ペーパープロトタイピング
・KPTでの振り返り

　特に活用したのは小さな付箋紙です。書いて、動かして、まとめて、というのに付箋紙は最高のツールです。PCの前にいるよりも机を囲んで全員で考えさせることを重視しました。それぞれの工程はそんなに突飛なことはしていません。むしろ、オードドックスと言えます。
　大事なことは要件定義の手法やツールを知っていることではなく、ユーザーと、あるいはチーム内で深い対話をすることなのです。専門知識が足りなければ専門家を足せばよい。だけど、それだけでは解決にはなりません。チームとして力を発揮するのに必要なのは、やはりコミュニケーションなのです。

　雑誌には載せなかった個人的な感想。僕は決まりきったコンテンツの演習だけを行なうことに疑問を感じています。手法やツールをなぞることは学校の勉強と変わらない。僕が大事にしたかったのはメンバーに「ゼロから何かを作りだし、それを実現していくシステム開発の醍醐味」を感じて欲かった。これを知ってしまうとソフトウェア開発の魅力は桁違いに高まります。

　最後に謝辞。ユーザー役をやってくれたＫさん、Ｈさん、そしてメンバーを技術的に支えてくれたＮさんありがとう。あと、こんな実験的な演習にも関わらず成果を評価してくれた関係者各位にも感謝。記事に出来たのはタイミング良く長谷川さん（Starlight & Storm）に声をかけてもらったから。何よりも演習に参加して成果を残してくれた3人のメンバーに感謝です。あっという間に成長する君たちを見ていて、こちらが大いに刺激を受けたよ。今後のさらなる活躍を祈念しています。そのうち、がっつりとプロジェクトをやりましょう。

DB Magazine ( マガジン ) 2010年 03月号 [雑誌] 翔泳社 2010-01-23 by G-Tools

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

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

　再利用におけるメリット、例えばコスト削減効果は同じです。ですが、この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】現場から見たエンタープライズクラウドby 山口幹一朗
　世界最高峰のクラウドインテグレーター、アピリオさんがついに講演に出てくれることになりました。ホントにデブサミぐらいでしか聞けません。セールスフォース上の国内案件で、あんなもの、そんなもの、全部が彼らの仕事です。最高峰のエンジニアがクラウド上で何を感じ、どんな未来を創ろうとしているのか。僕自身も非常に楽しみな講演です。

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】クラウド時代のアプリケーション開発環境～Spring Framework、仮想化と企業クラウドの融合～ by 名倉丈雄
　SpringSourceを買収したVMware。Springとクラウド/仮想化はいかに繋がるのか。エンタープライズクラウドに必要な開発から運用までの一貫したライフサイクルについて語られます。

申し込みはデブサミ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）が言ったことに流されてしまい「あなたがこう言ったからそうしたんだ」のような批評家になってしまう。そんなアーキテクチャで変化に適応できるわけがないのです。

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

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

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

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

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