今日学んだこと：アーキテクトのパーソナリティに関して

概要

今日はアーキテクトのパーソナリティについて学んだ。

ポイント1

アーキテクトには、コントロールフリークアーキテクト、アームチェアアーキテクト、効果的なアーキテクトという、3つの基本的なパーソナリティのタイプがある。それぞれのパーソナリティは、チーム境界のタイプとそれぞれ一致している。コントロールフリークアーキテクトはきつい境界を、アームチェアアーキテクトは緩い境界を、効果的なアーキテクトはちょうど良い種類の境界を作り出す。

コントロールフリーク

コントロールフリークアーキテクトは、ソフトウェア開発プロセスのあらゆる詳細な側面をコントロールしようとする。コントロールフリークアーキテクトが下す決定は、通常、細かすぎたり、低レベルすぎたりして、その結果、開発チームに多くの制約を与えてしまう。

ントロールフリークアーキテクトは、きつい境界を作り出す。コントロールフリークアーキテクトは、開発チームが有益なオープンソースやサードパーティライブラリをダウンロードするのを制限し、代わりに言語APIを使ってすべてをゼロから書くよう要求する。そして、命名規則やクラス設計、メソッドの長さなどにも厳しい制限を設ける。さらには、開発チーム向けに疑似コードを書くことまでするかもしれない。本質的に、コントロールフリークアーキテクトは、開発者からプログラミングの技術を奪う振る舞いをする。それは結果的に、フラストレーションやアーキテクトに対する敬意の欠如をチームにもたらすことになる。

アームチェアアーキテクト

アームチェアアーキテクトとは、長い間（まったくではないとしても）コーディングをしていないタイプのアーキテクトだ。こうしたアーキテクトは、アーキテクチャを作成する際に実装の詳細を考慮に入れない。彼らは通常、開発チームから切り離されていて、開発チームの近くにいないか、初期のアーキテクチャ図が完成するとプロジェクトからプロジェクトへと移動する。

アームチェアアーキテクトは、技術やビジネスの分野で頭が硬くなってしまっていることもある。そうすると、技術やビジネスの問題の観点から、チームをリードしたり、ガイドしたりすることはできない。たとえば、開発者の仕事はコードを書くことだ。コードを書くことを偽るのは本当に難しい。コードは書くか書かないかのどちらかだからだ。では、アーキテクトの仕事はどうだろう。誰にもわからない。多くのアーキテクトは、たくさんの線や箱を描くが、ではアーキテクトはそうした図をどのくらい詳細に描くべきなのだろうか。これは、アーキテクトのフリをするのはとても簡単だということを暗に示している。

効果的なアーキテクト

効果的なソフトウェアアーキテクトは、チームに適切な制約と境界を作り出し、チームメンバーがうまく連携し、チームが適切なレベルのガイダンスを受けられるようにする。また、効果的なアーキテクトは、チームが正しく適切なツールや技術を備えていることを確認する。さらに、開発チームが目標を達成するために邪魔になるような障害物を取り除く。

これは当たり前で簡単なことのように聞こえるが、実際にはそうではない。開発チームの効果的なリーダーになるには「技」が求められる。たとえば、チームと緊密に協力し合い、チームから敬意を得られていなくてはならない。

アーキテクトに求められるリーダーシップ

偶発的な複雑さを回避する効果的な方法に、私たちがアーキテクチャの4つのCと呼んでいるものがある。それは、コミュニケーション（Communication）、協調性（Collaboration）、明瞭さ（Clarity）、簡潔さ（Conciseness）だ。これらの要素すべてが一体となって、チームの中に効果的なコミュニケーターとコラボレーターを誕生させる。

ソフトウェアアーキテクトは、リーダー、ファシリテーター、そしてネゴシエーターとして、明確かつ簡潔な方法で効果的にコミュニケーションをとれることが重要だ。また、アーキテクトは、開発者、ビジネスステークホルダー、他のアーキテクトと協力して、共に議論し、解決策を形成できることも同様に重要だ。アーキテクチャの4つのCに焦点を当てることで、アーキテクトはチームから敬意を持たれ、質問だけでなく、アドバイス、メンタリング、コーチング、リーダーシップを求めて誰もが訪れるプロジェクトのよき相談相手となれる。