本質的な複雑さは単純に、 付随的な複雑さは取り除け

タイトルの「本質的な複雑さ」とは、問題自体の難しさのことです。たとえば、航空管制は、本質的に複雑な問題です。すべての航空機の正確な位置(高度を含む)、速度、向き、目的地をリアルタイムで監視し、空中や滑走路での事故をを避けなければなりません。絶えず笈化する環境の中で、空港が混雑しないようにフライトスケジュールを管理する必要があります。天候が極端に悪くなれば、フライトスケジュール全体が麻痺してしまう場合もあります。

もう1つの「付随的な複雑さ」の方は、本質的な複雑さをやわらげようとして作ったものから出てくるものです。たとえば、今使われている古めかしい航空管制システムは、付随的な複雑さのよい例です。もともとは、数千機もの航空機をコントロールするという本質的に複雑な問題に対処するために作られたものですが、このソリューション自体が複雑になっています。実際、今の航空管制システムは複雑すぎて、アップデートすることが不可能とは言わないまでも、非常に難しい。世界中の多くの航空管制システムは、30年以上前のテクノロジーで動いているんです。

フレームワークとかベンダーの言う「ソリューション」といったものの多くは、往々にして付随的複雑病の兆候を示しています。個別の問題を解決してくれるフレームワークは役に立ちますが、やりすぎると、解消してくれる以上に新しい複雑さを持ち込むことになります。

デベロッパーは、火のまわりに集まる蛾のように、複雑なところに引きつけられていきますで、蛾と同じ轍を踏むことが多い。パズルを解くのは面白いし、デベロッパーは問題を解くのが仕事です。とてつもなく複雑な問題をぱっぱっと解決してみせたいですよね。気持ちいいじゃないですか。でも、大規模なソフトウェアの場合、本質的な複雑さを解決しながら、付随的な複雑さを取り除くのは、とても難しいことです。

ではどうしたらいいのでしょうか。まず、象牙の塔から紡ぎ出されたフレームワークではなく、現場で生まれたフレームワークを選ぶことです。システムの中で、本当に必要なコードはどのくらいでしょうか。ベンダーが言うソリューションは疑ってかかりましょう。もちろん、最初から悪いと決まっているわけではありません。でも、ベンダーはつい付随的な複雑さを増やしてしまうものです。ベンダーのソリューションがちゃんと問題にフィットするようにしなければなりません。

「付随的な複雑さ」を持ち込むことなく、「本質的な複雑さ」の中に潜む問題を解決するのが、アーキテクトの仕事です。