【19】アーキテクトは手を汚さなければならない

　優れたアーキテクトは、模範となってチームをリードしなければなりません。彼なり彼女なりは、ネットワークの結線、ビルドプロセスのコンフィギュレーション、単体テストの作成、ベンチマークの実装など、チームメンバーがすることなら何でもできる必要があります。テクノロジーを隅から隅までよく理解しているというのでなければ、アーキテクトといっても、プロジェクトマネージャーと大差のないものになってしまうでしょう。チームメンバーが、専門領域でアーキテクトよりも深い知識を持っていることはかまいませんが、アーキテクトがテクノロジーを理解していないようなら、チームメンバーは自分たちのアーキテクトにどうやって信頼を置いたらよいでしょうか。

　他のページでも言われているように、アーキテクトはビジネスと技術チームのインターフェイスです。ですから、技術のあらゆる側面を理解し、いちいちメンバーの助けを借りずに、チームを代表してビジネスサイドの人々に相対することができなければなりません。同様に、ビジネスの役に立つという目標に向かってチームを動かしていくために、アーキテクトはビジネスのことも理解していなければなりません。

　アーキテクトは、飛行機の機長に似ています。いつも忙しく立ち働いているという感じには見えなくても、数十年の経験を活かして状況を絶えず監視し、異常に気付いたらすぐに行動を起こさなければなりません。プロジェクトマネージャー（副操縦士）は、日常的な管理を行う人です。ありふれた仕事や人員の管理のためにアーキテクトが忙殺されないように、アーキテクトを助けます。プロジェクトの質やビジネスへの引き渡しは、最終的にアーキテクトが責任を取らなければなりません。これは、威厳がなければできない仕事です。プロジェクトが成功するかどうかは、アーキテクトの威厳によって左右されます。

　人は、他人を見て学ぶものです。子供の頃は、私たちもそうやって学んだのです。優れたアーキテクトは、問題点を見抜き、チームを集め、犠牲者を名指しせずに、問題がどのようなものかを説明し、エレガントな解決策や回避策を示さなければなりません。尊敬されているアーキテクトがチームに助けを求めるのは、まったく問題のないことです。チームは、それを問題解決の過程ととらえるでしょう。ただ、アーキテクトは議論の中心となって、正しい解決策を見つけなければならないのです。

　アーキテクトは、プロジェクトの開始時点からチームに溶け込んでいなければなりません。象牙の塔から命令を下すのではなく、地上に立って、チームとともに働くのです。方向性や技術的な選択についての疑問点が、新しいプロジェクトや調査活動を生み出すようなことがあってはなりません。アーキテクト自らが調査するか、あるいは同僚のアーキテクトの助言によって解決する必要があります。優れたアーキテクトは、しっかりとした人脈をつかんでいるものです。

　優れたアーキテクトは、自分の専門分野に関しては少なくとも 1 つのツールのエキスパートでなければなりません。アーキテクトは、手を動かさなければならないのです。ソフトウェアアーキテクトなら IDE、データベースアーキテクトなら ER ツール、情報アーキテクトなら XML モデリングツールを知っているのは当然のことです。しかし、技術アーキテクト、エンタープライズ・アーキテクトは、あらゆるレベルのツールを使いこなせなければなりません。Wireshark でネットワークトラフィックを監視することから、XMLSpy で複雑な金融メッセージのモデリングをすることまでさまざまなことができなければならないのです。どのツールについても、低すぎず高すぎないレベルが必要です。

　アーキテクトは、見事な履歴書とめざましい武勇伝を持っているものです。それだけで、経営者や技術者からは高く評価されるでしょう。しかし、その能力を実際に示すことができなければ、チームから尊敬を集めることはできないでしょうし、チームが彼から学ぶことも難しいでしょう。そして、チームメンバーはもともと持っている能力を発揮できなくなってしまいます。アーキテクトは自ら範を示すことが大切なのです。