何度も書いていることですが、今の認識をまとめておきます。大事なのはアーキテクチャが単なる”モノ”ではなく、"コト"だということです。
構造＝要素の組合せ
工法＝構造の組み立て手順
フレームワーク＝構造＋工法
まずは、構造（ストラクチャー）から考えていきます。ソフトウェアに限らず、人間が作るプロダクトというのは、小さな要素を組み合わせることで作られています。こうした「要素の組合せ」を構造と呼びます。構造はソフトウェアの内側にあるもので、外側（ユーザー）から直接は見て取れるものではありません。いわゆるパターンは、構造のことをしめします。
次に工法ですが、これは構造を組み立てるためのプロセスをしめします。構造は組合せの結果です。要素を組み合わせるには、手順が存在します。家で言えば、土台を作り、柱を立て、屋根を載せる。個別の要素を事前に作っておくことはできますが、それを組み立てるためには手順が必要なわけです。
この構造と工法がセットになったモノがフレームワークです。フレームワークは特定の問題領域について最適な構造と工法を提供します。もちろん問題認識が違いますから、具体的な解き方は様々になります。Strutsであれば、MVCパターンを実現するために、Form、Action、JSPという要素を作り、それらを配置したらstrtus-config.xmlに書くことで組み立てていきます。
また、その問題領域の設定が広ければアプリケーション全体で適用できますし、小さければ部分として適用します。Strutsは前者ですし、ロギングフレームワークのSLF4JやLogBackは後者と言えます。後者のことをライブラリと呼ぶこともありますが、構造がフレームワークの外部（使う側）に要求するようになっているだけで、同じ事です。
アーキテクチャ＝ソフトウェアにかかる外圧（使うこと）と内圧（作ること）のバランスを取った結果
さて、アーキテクチャというのは、これら構造や工法、フレームワークといった”モノ”ではありません。アーキテクトの主な仕事はモノ（構造、工法、フレームワーク）の選択です。アーキテクチャというのは、それらのモノを選択するに至った「理由全体」という"コト"的な存在です。
僕の定義は、「ソフトウェアにかかる外圧（使うこと）と内圧（作ること）のバランスを取った結果」となります。ソフトウェアには多くの利害関係者が関係しますが、大きく分けて使う側と作る側に分けられます。これは同一人物であっても変わります。
例えば、”ユーザー”といっても、リリースするまでは要件定義者として作る側にいますが、いざリリースされれば、まさにユーザーであり、あるいは運用担当者として使う側になります。これら”使うこと”と”作ること”のバランスを取っていき、もっとも価値がある状態にしていくことがアーキテクトの仕事です。アーキテクチャというのは、それらのバランスを取るための選択であり、その結果なのです。
良いアーキテクチャ＝外圧と内圧が時間軸上で変化するのに耐える
アーキテクチャを考える上で、時間軸は非常に大事です。外圧と内圧は日々変化するからです。ビジネス環境が変われば使いかたも変わります。機能が増えれば作る側の管理状況も変わってきます。そして、関わる利害関係者も変わりますし、判断も日々変わる可能性がある。
こうした外圧や内圧の変化に対して、なるべく長い間、価値を出し続けていくのが、良いアーキテクチャといえます。
アーキテクチャが変化に対して弱いと、選択されたモノである構造や工法との齟齬が発生します。この結果として、ありがちなのが「構造が悪い」という指摘です。ところが構造はモノである以上、カタチとして劣化したわけではない。あくまでも変化したのは外圧と内圧であり、それの変化を受け止められないアーキテクチャが悪い、というのが本質的な指摘でしょう。
（外圧や内圧の変化を無視して、モノを固定化するというのが、昔ながらの標準化です。こうした標準化が、いかに無意味かは説明するまでもないでしょう。標準化をするのであれば”アーキテクチャの標準化”に取り組むべきであって、”フレームワークの標準化”ではありません）
良いアーキテクチャの作り方＝変化の方向性を読む、未来を想像する
では、いかにして外圧と内圧の変化に耐えるのか。そのために重要なのは”変化の方向性を読む”ことです。つまり、未来を想像すること。可変性分析、とも言われます。
先ほど、外圧と内圧のバランスが重要と言いましたが、それが今のスナップショットでは意味がないのです。未来になったとしても、そのバランスを保てるように考えられている必要があります。そう言う意味で、僕は球体をイメージしています。Ｘ軸、Ｙ軸だけでなくて、Ｚ軸もバランスを取らないといけない。
長くなってきたので一旦切ります。アーキテクチャを考えるにはどうしたらいいのか、というのは次回。また、”アーキテクチャの標準化”というのも、書いてみたいと思います。
