書いている人
モバイルアプリケーションアーキテクトとして働いています。モバイルアプリケーションのアーキテクチャ、自動テスト、CI/CDに興味があります。
「ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ」 (Mark, Neal (2022)) は、タイトルのとおり、ソフトウェアアーキテクチャの基礎を解説したものです。アーキテクチャは一概に「こうすれば良い」と言えるものではありませんが、どのようにアプローチすれば良いアーキテクチャを導き出せるのか？ということを解説した書籍です。特定のアーキテクチャについて解説するものではありません。
本書では、良いアーキテクチャを導く役割を持つアーキテクトというロールについても解説されています。アーキテクチャについて一般化された定義がないため、アーキテクトについても一般化された定義はありません。その上で、本書では「良いアーキテクトとは何であって何でないのか？」ということが示されています。アーキテクトロールは、最近ではソフトウェアエンジニアのキャリアパスにおける「スタッフエンジニア」のアーキタイプのひとつに数えられることもあります。
働くをもっと楽しくするために、Chatwork株式会社にジョインしました🚀で書いたように、自分はモバイルアプリケーションアーキテクトとして働き始め、既に1年が過ぎました。もっと良いアーキテクトになれるよう、本書をアーキテクトのキャリアガイドとして改めて読み直してみました。
アーキテクトには、技術的な専門性の深さよりも幅が求められます。これは、さまざまなソリューションを理解して、決定を行う必要があるためです。
アーキテクトロールに就いた後は、専門性を犠牲にしても、技術的な幅を広げることに時間を使うべきである、ということが本書では指摘されています。それまで専門性を磨くことに時間を費やしていたエンジニアは、技術的な幅を広げること時間を費やすことに時間を費やすようにマインドを変えていかなければなりません。
一方で、技術的な深さを維持するために、現場でコードを書き続ける必要性も指摘されています。これは簡単なことではありませんが、いくつかのポイントがあると解説されています（本記事では触れませんので、本書を参照してください）。
アーキテクトは、チームの技術的な選択をガイドする存在でなければいけません。これは、アーキテクトがすべての技術的な選択についての決定を下してはならない、ということも意味します。
例えば、同じ機能を提供するライブラリAとライブラリBが存在し、どちらかを導入する選択をしようとしている状況を考えます。ここでアーキテクトがすべきことは、ライブラリAとライブラリBのどちらかを選定するのではなく、選定にあたっての指針を作成することです。たとえアーキテクト本人はライブラリAが好ましいと思っていても、アーキテクトの作成した指針に従っているのであれば、チームがライブラリBを選定してもそれは歓迎すべきことです。
本書によれば、アーキテクトが下す決定のほとんどについて異議が唱えられます。これは良い悪いの話ではなく、現実がそうなっているということです。
だからこそ、アーキテクトは組織の政治を理解し、ファシリテートと交渉のスキルを発揮し、意見の相違を乗り越えて、すべてのステークホルダーが納得できるソリューションを導き出さなければなりません。優れたアーキテクトの50%はソフトスキルである、と本書では指摘されています。