アーキテクチャ設計の難しさについて
アーキテクチャについては、以下のパワポを見て頂くとして。
アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。
"何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。
次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。
"静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システムが完成した状態でのシステム構成要素の構成のこととなります。これは「価値を達成するために最終的にどのような構成になっているべきか」を考えることになります。
"動的なプロセス"というのは最終の構成を実現するために、どういった手順で組立をするかということになります。構成要素ごとに、それを作り出すための作業があり、それらの前後関係を考慮する必要があります（いわゆるWBSですね）。これは「最終構成を作るために、どのような作業手順で実現していくか」を考えることになります。
上記をまとめると、アーキテクチャ設計というは、
・このシステムが動き出した時、どんな価値を生み出すべきか（未来における動的な姿）
・価値を達成するために最終的にどのような構成になっているべきか（未来における静的な姿）
・その構成を作るために、どのような作業手順で実現していくか（現在から未来への動的な姿）
を、まとめて考えてバランスを取ることと言えます。
難しく書いているようですが、料理だろうが、犬小屋だろうが、いわゆるものづくりをする上では当たり前の行為でしょう。しかし、一方で、アーキテクチャ設計には時間軸と空間軸について幅広い思考が必要となるため「アーキテクチャ設計は難しい」ということになります。特にアーキテクトが経験したことのある分野であればまだよいですが、新しい分野については簡単ではありません。
そこで「新規領域においてアーキテクチャ設計を最初にきちんとやるのは難しいので、成果物を作りながら、段階的に設計していこう」という発想が生まれてきます。アジャイル開発プロセスが代表的ではありますが、プロトタイプやイテレーションなど、もはや、あらゆるプロジェクトにおいてアーキテクチャを段階的に設計するのは通常のプロセスとなっているでしょう。
アーキテクチャ設計を段階的に進めるためには「リスクや変化の濃淡を見分ける」ことが大事です。そして、その濃淡から境目を見極め、対象物を分割していきます。分割が明確になれば、判断を先送りするにしても、判断の決定が影響を及ぼさないようにすることができます。
単純な例で言えば「サーバのアドレスが決まらないなら設定ファイルにしておく」ということです。サーバのアドレスが不確定だと分かれば、それを設定ファイルにさえしておけば決定を遅らせることができます（「リスクや変化の濃淡を見分ける」というのは、それだけで長い話なので今回はこれぐらいで）。
ちなみに大前提ですが、アーキテクトが「リスクや変化の濃淡を見分ける」ためには、アーキテクトが現場にいることが非常に重要です。チームの一員となり、全体の状況からリスクをかぎ分け、判断をしなくてはいけません。象牙の塔に閉じこもっているようなアーキテクトは、実際のプロジェクトでは使い物にならないでしょう。
どうやってもアーキテクチャ設計は難しいものですが、おそらくは多くの人が無意識に実践をしていることだと思います。なので、まずはアーキテクチャ設計ということに意識的になり、何らかの方法で共有をすることで、より良いアーキテクチャ設計にむけた議論をしていければいいと考えています。まずは自分の周りからでも話を始めていこうとしています。
