O'Reillyの97のこと
アーキテクト 【architect】
建築家、設計者などの意味を持つ英単語。ITの分野では、システムやソフトウェアの開発において、全体のプロジェクト管理や基礎・中核部分の設計や仕様策定などを行う(ことができる)人や職種、チームのことを意味する場合が多い。対象分野によって、ITアーキテクト、システムアーキテクト、ソフトウェアアーキテクトなどと呼ばれる。
経済産業省の指定試験機関である独立行政法人情報処理推進機構の情報処理技術者試験センターでは、情報処理技術者試験の一区分として、システムの要件定義や基本設計、開発の主導などを行うための知識や技能を認定する「システムアーキテクト試験」を実施している。
もう1つの「付随的な複雑さ」の方は、本質的な複雑さをやわらげようとして作ったものから出てくるものです。たとえば、今使われている古めかしい航空管制システムは、付随的な複雑さのよい例です。もともとは、数千機もの航空機をコントロールするという本質的に複雑な問題に対処するために作られたものですが、このソリューション自体が複雑になっています。実際、今の航空管制システムは複雑すぎて、アップデートすることが不可能とは言わないまでも、非常に難しい。世界中の多くの航空管制システムは、30年以上前のテクノロジーで動いているんです。
フレームワークとかベンダーの言う「ソリューション」といったものの多くは、往々にして付随的複雑病の兆候を示しています。個別の問題を解決してくれるフレームワークは役に立ちますが、やりすぎると、解消してくれる以上に新しい複雑さを持ち込むことになります。
デベロッパーは、火のまわりに集まる蛾のように、複雑なところに引きつけられていきますで、蛾と同じ轍を踏むことが多い。パズルを解くのは面白いし、デベロッパーは問題を解くのが仕事です。とてつもなく複雑な問題をぱっぱっと解決してみせたいですよね。気持ちいいじゃないですか。でも、大規模なソフトウェアの場合、本質的な複雑さを解決しながら、付随的な複雑さを取り除くのは、とても難しいことです。
ではどうしたらいいのでしょうか。まず、象牙の塔から紡ぎ出されたフレームワークではなく、現場で生まれたフレームワークを選ぶことです。システムの中で、本当に必要なコードはどのくらいでしょうか。ベンダーが言うソリューションは疑ってかかりましょう。もちろん、最初から悪いと決まっているわけではありません。でも、ベンダーはつい付随的な複雑さを増やしてしまうものです。ベンダーのソリューションがちゃんと問題にフィットするようにしなければなりません。
「付随的な複雑さ」を持ち込むことなく、「本質的な複雑さ」の中に潜む問題を解決するのが、アーキテクトの仕事です。