arclamp.jp アークランプ

　先日、デブサミの「ITアーキテクト大解剖」でご一緒させていただくマイクロソフトの萩原さん、建築家の大川さんとミーティング。いろいろと話をしてきました。デブサミでは、ここで書かれていることを中心に話題を広げていきたいと思います。

技術や知識は最低限のこと
　まず全員が一致したのは「工学的な知識や技術を知っているというのは最低限のこと」である点。同じような知識としては、先人の知恵という意味でパターンや実績・実例をあげることもできます。

　建築業界で技術の親分というのは構造エンジニアや現場の大工で、アーキテクトとは明確に分離されています。もちろんアーキテクトが設計図を描くために知識は必要になるので、知っている範囲であればその中で、新しい技術を試すのであれば設計段階からエンジニアに入ってもらうそうです。

　一方のIT業界で、アーキテクトとエンジニアに分離は見えていません。これはITの歴史が浅いからでしょう。IT業界では技術自体が客観的な情報として定義しにくく、建築の構造設計書のようなものがありません。ですから、技術を理解するためにはエンジニアと同等のスキルが必要になるのです。

　当然、こうした知識をたくさん知っていることは大切です（新鮮さも）。それは選択肢があるほうが良いからです。

アーキテクトの仕事
　では、アーキテクトの仕事は何でしょうか。それは「対象（家、システム）を構築するために存在する様々な制約条件を抽出し、それらを整理・調整して、構築するための技術や手法を選択をすること」にあります。

制約の抽出
　制約条件とはコスト、期間、クライアントからの要求、あるいは法律や環境などをあげることができます。もちろん人的リソースやプロジェクトマネージメントといった点をあげることができます。建築では重力や風も重要でしょう。

　大川さんが個人邸を依頼された場合、クライアントからの要求は数千にもなるそうです。加えて、土地の形や法律、そしてコストという大きな制約が付きます。IT業界でもシステム規模にもよりますが、数千、数万というが普通の状態です。

　こうした制約条件の中でクライアントが不満を抱かないレベルで対象を構築することが必要になります。当たり前ですが顧客自身が矛盾を孕んだ要求をする場合もありますし、もっと外的な制約条件（法律やコスト）によって要求をかなえることができない場合もあります。

　ですから、制約を理解し調整するという能力が非常に重要になるのです。

技術の選択
　この"調整"というのは要求管理とはまったく違います。要求管理というのは「その要求が実現されたか」「要求がどのように変更されたか」というだけです。ITアーキテクトの調整というのは、数多くの要求をいかに効率良く実現するのかを考える作業です。

　効率良く構築するためにはパターン化が必ず必要になります。複数の要求からパターンを発見し、パターンによってカバーできる範囲を増やせば、それだけ効率的にすることができます。しかし、パターンは融通が利きませんから、場合によっては細かい要求を実現することができなくなります。単純化して考えると、効率度と要求実現度という2軸で考えることができます。

　要求実現度が高い
          |
    B    |   D
          |
-------------------- 効率が良い
          |
    A    |   C
          |

　Dが一番良いわけですが、普通はBとCで深く深く悩むことになります。こうした調整を重ねて構築手段を選択していくわけです。制約がある以上、それらを完全に無理なくかなえるというのは不可能なのです。

　なお、IT業界の場合はパターンありきで要求を抽出することが多いようです。ですが、一般的なOSSで提供されているようなパターンでは、多く繰りすぎる場合が多く、なにかしたの特化パターンを作るというのは日常的に行われていると思います。その場合も同じような悩みが生まれるはずです。

構築という言葉に通じる共通概念
　僕としても、きっとお二人としてもこうした概念論がITと建築で共通して話せることに大きな発見がありました。「何かをクライアントために構築する」といった視点では、こうした技術論ではないところが重要なのだと感じます。