https://zenn.dev/okunokentaro/articles/01g08xzr246r7p8336m57amkpn
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今回は、最近噂としてよく耳にしていた書籍『ソフトウェアアーキテクチャの基礎 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン社、Mark Richards, Neal Ford 著、島田浩二 訳、2022 年 3 月発行）を読了したので、その書評をまとめようかと思います。
この書籍は、アプリケーション・アーキテクチャを構築、維持する「アーキテクト」になるために必要な知識を現代（2020 年代）の視点から整理し、包括的に解説することを目的としているらしく、まさに 2022 年に読むべき内容に仕上がっています。
この書籍はよいものでした。ただし、かなり広範囲に包括的に書かれたものであったため、どういう経験や知識を持った人間が読んだかによって、その好みや評価は分かれるだろうと感じています。読者によっては「難解」で片付けられてしまうかもしれません。そのため、まず先に書評者（筆者）の経歴や経験を共有しておきます。
筆者はもともと 2000 年代から HTML, CSS によるウェブページ制作、ウェブデザインの業務に従事しており、そこから WordPress 保守、MySQL 保守、PHP 開発などを経て 2010 年代半ばより Web フロントエンドに進みました。JavaScript 歴は 10 年以上、TypeScript 歴は 9 年という経歴で、複数社の Web サービス設計開発・保守、大手社内システムの Web クライアント設計開発などを手掛けています。1 案件のコード行数は 10 万や 20 万行を超える規模のものもあり、同一案件の開発に携わる人数も 10 人前後と、中規模になりつつあるチームを運営しました。
Web フロントエンドの領域に進んでからは AngularJS, Angular を得意分野として、React や Vue.js の流行も脇で見守りつつ、エンタープライズ向け Web フロントエンドの構築を得意としました。XP およびアジャイル開発、テスト駆動開発 (TDD)、ドメイン駆動設計 (DDD) やクリーンアーキテクチャなどを学び、模倣しつつ、数々の困難を解決してきた自負があります。近年ではアーキテクト、テクニカルディレクター、リードエンジニアとして、React, Next.js を含めたフロントエンド + バックエンド領域の全般に関わるようになり、データベースの特性選定やスキーマ設計、マイクロサービス間のフロー構築、各マイクロサービスの開発案件間のディレクションなども担当しています。
これだけですと壮語を並べるだけなのですが「このような経験値を持った人間が本書を読んでどう感じたか」という部分に今回の書評の意義があるとして、今回述べることとしました。
本書はどういった層に書かれているか、これはずばり 2010 年代を乗り越えてきた経験者に向けてです。つまり、自分にはとても刺さりました。
アーキテクチャの書籍はこれまでも数多く出版されましたし、そのうちいくつかは筆者も読了しています。ただしそれらはすべて 2010 年代前半のエコシステム、2010 年代前半の哲学によって書かれた内容です。もちろん非常に有用な知識に富んでいるのですが今では「10 年前の昔話」とも言えてしまいます。本書は、2010 年前後の知識を 2020 年代に備えてアップデートするためのものだと感じます。
本書では冒頭に、数学の公理とソフトウェアアーキテクチャの理論は異なり、ソフトウェアアーキテクチャの理論は変化し続けるという点を強調していました。また、本書中の至るところで「変化」に重きをおいています。2010 年代を走り抜けてきたエンジニアだからこそ共感できる「変化の速さ」と「変化の難しさ」を整理して包括的に言語化したものが本書です。
筆者は「アーキテクチャはビル建築でいう基礎だ」という学びを前提に持ち、まず入念なアーキテクチャ検討や設計を行ってから開発に臨むべきという哲学でこれまでの業務を進めてきました。もちろん昨今のマイクロサービス・アーキテクチャの台頭に伴って「そればかりではない」という肌感覚は持ち合わせていましたが、それらもすべて「アーキテクチャは骨幹たるものである」という前提の上で付加的に整理していました。
しかし本書を読んだ上で、そもそもの前提を疑うべきではないか、根本的な認識のアップデートが欠けているのではないかという気持ちに至りました。アーキテクチャをビル建築とするメタな例え自体がふさわしいのかどうか？ということです。2020 年代においてアーキテクチャをビル建築のようなものと理解したままでいると、今後の時代の変化についていけないかもしれない危機感に気付かされます。
筆者は 34 歳でして、数年前だったら「35 歳定年説」の 1 歳手前というところです。しかし、ここ数年はもはや「35 歳定年説」自体を聞かなくなり、現に 35 歳以上…40 代、50 代で活躍しているエンジニアもとても多いことを理解しています。すでに 35 歳は引退の区切りでは全くなく、34 だろうが 35 だろうがまだまだ先がある時代になりました。それを理解して筆者が今後のキャリアを進める際、老害化というのは気になり始めた話題でもあります。
現在進めている他社受託案件では、データベースの設計から日々の開発のコードレビューまで幅広く手掛けており、様々な経験を持つ、様々な年齢の開発者とコミュニケーションを取りながら案件を進めています。そこでは「自分の発言は常に正解なのだろうか？全員を常に正解に導けているのだろうか？」という悩みが付きまといます。
これは、自分の過去数年間の経験の上では問題なかった手法が「2022 年においてこれは最善手なのだろうか？」という悩みです。もしかしたらこのレビューを聞く相手はもっと優れた現代的な手法や哲学を兼ね備えているかもしれないのに、自分の発言によってその選択を閉ざしてしまっていないだろうか？という不安です。
自分の成功体験がかえって現代においての懸念になる「老害おじさんの戯言」を流してしまっていないだろうか。