しっかりとした問題には高品質のソリューションが与えられる

実社会でのプログラミングは、誰かがあなたに与えた問題を解くことではありません。コンピューター科学の教室では、あなたは与えられたバイナリソートの問題を解かなければなりませんが、実社会では、最良のアーキテクトは難しい問題を解かず、回避します。アーキテクトの腕を示すのは、拡散したさまざまなソフトウェア上の問題の間に境界線を引いて、かちっとした自己完結的な問題にすることができるかどうかです。

アーキテクトは、コンセプト、デー夕、プロセスが入り乱れて混ざっている全体を見て、それらを小さな部品、すなわち「チャンク」に分割できなければなりません。これらの問題チャンクで大切なことは、はっきりとしたスコープ（範囲、境界）を持つシステムによって解決できるしっかりとした内容を持ったものだということです。問題チャンクは、次のような性質を持たなければなりません。

• 求心力があること。塊の中では概念が統ーされており、タス夕、デー夕、機能がすべて関連し合っていることです。
• 他のチャンクからの分離。チャンクは、概念的に正規化されたものでなければなりません。そのようなチャンクの間では、重なり合いはまずないはずですし、あったとしてもごくわずかに抑えられているはずです。

このような線引きがとりわけうまい人は、方向感覚の優れた人が自分の居場所を把握しているのと同じように、自分が線引きをしていることを意識さえしないかもしれません。そのような人にとっては、システムに対してちょうどよい縁(へり)、すなわちインターフェイスが露出するように、タスク、デー夕、機能を分割することが、当然のことと感じられるようなのです。なお、私がここで言っているインターフェイスは、オプジェクト指向言語のインターフェイスではなく、システムの境界としう意味です。

たとえば、RDBMSは、非常に明確なシステム境界を持っています。バイトストリームにシリアライズできるほぼすべてのタイプのデータを管理でき、そのデータを整理、検索、読み出しできます。実に単純です。

面白いのは、問題がかちっとしていると、解決されたときにはほとんど永遠に解決されることです。たとえば、5年後、50年後にウエブ/テレパシーインターフェイスを付けたくなったとしても、コアシステムに変更を加える必要はありません。問題に耐久性があるので、システムも長生きするのです。

もちろん、コードはきちんとしていなければなりませんが、問題がきちんとしていればコードをきちんと書くことはできますし、特殊条件は出てきません。きちんとしたコードはテストしやすく、レビューもしやすいという点で優れています。実装の品質が非常に高いということです。コードがごちゃごちゃしていないので、あなたはユーザーから見えるドメインとは無関係な信頼性の高いメッセージング、分散トランザクションなどの機能に集中することができます。マルチスレッドやアセンプリコードのような低水準言語を使ってパフォーマンスを引き上げることを考えることもできます。問題に変化がないので、そのシステムの特徴と言えるくらいにコードの品質を高めていくことに集中できるのです。

問題がしっかりとしていれば、設計が安定しているシステムを作ることができます。設計が安定していれば、アプリケーションの品質を非常に高くすることに集中できるのです。