ソフトウェアアーキテクトのエレベーター

第一部 アーキテクト

アーキテクトは、IT企業においてエキサイティングだが時に困難な人生を送っている。マネージャーやテクニカルスタッフの中には、アーキテクトを現実離れした、スライドや壁一面のポスターで社内に自分の考えを押し付ける、高給取りの象牙の塔の住人と考える人もいるかもしれない。

良い面を挙げれば、ITアーキテクトは最も求められるITプロフェッショナルの一人となっている。従来型の企業が、デジタル・ディスラプターに対抗するためにITランドスケープの変革を模索しているからだ。しかし皮肉なことに、最も成功しているデジタル企業の多くは、世界トップクラスのソフトウェアとシステムアーキテクトを擁しているが、アーキテクトは全くいない。

では、名刺にアーキテクトと印刷されている以外に、何がその人をアーキテクトたらしめているのだろうか？

アーキテクトとは何か？

何かを正確に定義しようとするよりも、何がそうでないかを説明する方が簡単な場合がある。アーキテクトの場合、誇張された期待によって、午前中は断続的なパフォーマンス問題を解決し、午後は企業文化を変革する人物というイメージが描かれることがある。これは、アーキテクトが、アーキテクトである目的を明らかに逸脱した、いくつかの役割に引きずり込まれるシナリオにつながる：

シニア開発者

開発者 、キャリアの次のステップとして（そして給与のグレードとして）アーキテクトになる必要があると感じることが多い。しかし、アーキテクトになることとスーパースター・エンジニアになることは2つの異なるキャリアパスであり、どちらが優れているということはない。アーキテクトは組織的・戦略的側面を含むより広い範囲をカバーする傾向があるのに対し、エンジニアは専門化し、実行中のソフトウェアを提供する傾向がある。成熟したIT組織はこのことを理解し、並行したキャリアパスを提供している。

消防士

多くのマネージャは、アーキテクトが現在のシステム状況を幅広く理解した上で、トラブルシューティングを行い、どのような危機も解決できることを期待している。アーキテクトは生産上の問題を無視すべきではない。なぜなら、生産上の問題はアーキテクトの弱点となりうる可能性について貴重なフィードバックを与えてくれるからだ。しかし、消防訓練から次の訓練へと走り回るアーキテクトには、アーキテクチャについて考える時間はないだろう。アーキテクチャは演算子ではない。

プロジェクトマネージャー

アーキテクトは、多くの異なる、しかし相互に関連するトピックを両立させなければならない。彼らの決断は、プロジェクトの時間行程、人員配置、必要なスキルセットも考慮に入れ、影響を与える。その結果、上層部はプロジェクトの情報をアーキテクトに頼るようになることが多い。特に、プロジェクトマネージャーがステータスレポートのテンプレート（第30章）の記入に追われている場合はなおさらである。これは、アーキテクトにとっては貴重な仕事であるが、アーキテクトの主な責任から目をそらすことになる。

科学者

アーキテクトは、 、鋭い知性を持ち、モデルやシステム（第10章）で考えることができなければならないが、彼らが下す決定は、実際のビジネスプロジェクトに影響を与える。そのため、多くの組織ではチーフアーキテクトの役割をチーフサイエンティストと分けている。個人的には、アーキテクトが論文以上のものを生み出すことを強調するために、チーフエンジニアという呼称を好む。最後に、科学者は物事を複雑で難解なものにすることで論文を発表することができるが、アーキテクトの仕事はその逆で、 ...