話題の近著「ソフトウェアアーキテクチャの基礎（エンジニアリングに基づく体系的アプローチ）」を読んだ感想などを中心に書き留めておきます。
はじめに
ソフトウェアアーキテクチャ、アーキテクトについての基礎や定義を網羅的に解説してくれています。ソフトウェアを中心としたシステム開発を生業にしている人にとって、ソフトウェアアーキテクチャは、身近なものだと思いますが、その定義について立ち止まって考える機会は意外と少ないのではないでしょうか？少なくとも私には、これまであまりその機会はありませんでした。この本は、過去からの経緯と昨今の時代の変化を踏まえて、ソフトウェアアーキテクチャやアーキテクトというもののあり方についての認識を考えさせられる一冊だと思います。
本の構成
本の構成は、下記のような章立てになっています。
＜構成＞
１章 イントロダクション
■第Ⅰ部 基礎
２章 アーキテクチャ思考
３章 モジュール性
４章 アーキテクチャ特性
５章 アーキテクチャ特性を明らかにする
６章 アーキテクチャ特性の計測と統制
７章 アーキテクチャ特性のスコープ
８章 コンポーネントベース思考
■第Ⅱ部 アーキテクチャスタイル
９章 基礎
１０章 レイヤードアーキテクチャ
１１章 パイプラインアーキテクチャ
１２章 マイクロカーネルアーキテクチャ
１３章 サービスベースアーキテクチャ
１４章 イベント駆動アーキテクチャ
１５章 スペースベースアーキテクチャ
１６章 オーケストレーション駆動サービス指向アーキテクチャ
１７章 マイクロサービスアーキテクチャ
１８章 適切なアーキテクチャスタイルを選ぶ
■第Ⅲ部 テクニックとソフトスキル
１９章 アーキテクチャ決定
２０章 アーキテクチャ上のリスクを分析する
２１章 アーキテクチャの図解やプレゼンテーション
２２章 効果的なチームにする
２３章 交渉とリーダーシップのスキル
２４章 キャリアパスを開く
詳細な目次は、前述したO'Reillyさんの書籍ページもしくは実際の書籍をご覧ください。この目次だけでなんとなく伝わるかもしれませんが、ソフトウェアアーキテクチャについて現代的な視点も踏まえて網羅的に記載されているため、かなりボリューム（約400ページ）があります。読み方は人それぞれですが、個人的には最初から最後まで同じ密度で読むというよりは、「第Ⅰ部」の基礎編を読んだら「第Ⅱ部」はざっと目を通しつつ気になる所を読むくらいが良いかなと思いました。「第Ⅲ部」は、アーキテクトに求められる要素（しかも必須の）としてチーミングやリーダーシップなどのソフトスキルについて記載されており、そこまで求めてくるか…ぐぬぬ…、と少し驚かされました。
印象に残った点
印象に残った点、思ったこと、感じたことを以下に列挙しておきます。
１章 イントロダクション
１．２ アーキテクトへの期待
与えられた役割や肩書き、職務に関係なく、ソフトウェアアーキテクチャには主に次の８つが期待される。
- アーキテクチャ決定を下す
- アーキテクチャを継続的に分析する
- 最新のトレンドを把握し続ける
- 決定の順守を徹底する
- 多様なものに触れ、経験している
- 事業ドメインの知識を持っている
- 対人スキルを持っている
- 政治を理解し、かじ取りする
→最後の２つについて言及しているのは個人的に新鮮でした。特に「アーキテクトには、チームワークやファシリテーション、リーダーシップなど、卓越した対人スキルを持ち合わせていることが期待されている。」は、期待値高過ぎない？とも思いました。
１．３ アーキテクチャと交わるもの
未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解していて、より早く未知の未知に対処するようになっている。（著者のひとりMarkの言葉を引用）
→アーキテクチャを考えるうえで、アジャイルのようなイテレーティブ（というか適応的な？）なプロセスの方がより適しているのは、かつてのソフトウェアとは違い変化を前提とした昨今の状況を鑑みた結果なのかな、と感じました。
１．４ ソフトウェアアーキテクチャの法則
第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ。
第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ。
→シレっと記載されていますが、特に第一法則は、この本全体を通した（強めの）メッセージングだと感じました。
４章 アーキテクチャ特性
４．２ トレードオフと少なくとも最悪でないアーキテクチャ
決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないアーキテクチャを狙おう。
→文脈を加味して読めば、言わんとすることに対して、あまり違和感や矛盾はないと思うのですが、文脈なしでこの言葉がひとり歩きすると、アジャイルマニフェストに記載された12の原則に記載されている「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」を読んだ人が混乱しそうだな、とは思いました。
５章 アーキテクチャ特性を明らかにする
５．１ アーキテクチャ特性をドメインの関心事から捉える
事例：ヴァーサ号（の悲劇）
→トレードオフを無視して言われたまま仕様を全部のせしようとした結果、処女航海で沈没するという、このメタファ好きです。
６章 アーキテクチャ特性の計測と統制
Simian Armyの起源
→Netflixが生み出した有名な（？）カオスエンジニアリングのエピソード好きです。
９～１８章 第Ⅱ部 アーキテクチャスタイル
以下のアーキテクチャスタイルとそのアーキテクチャ特性について解説されています。
- レイヤードアーキテクチャ
- パイプラインアーキテクチャ
- マイクロカーネルアーキテクチャ
- サービスベースアーキテクチャ
- イベント駆動アーキテクチャ
- スペースベースアーキテクチャ
- オーケストレーション駆動サービス指向アーキテクチャ
- マイクロサービスアーキテクチャ
それぞれのアーキテクチャ特性をざっと比較するには一覧表があると便利そうだったので作成してみました。Githubに置いておくので参考までにご覧ください。
１９～２４章 第Ⅲ部 テクニックとソフトスキル
１９章 アーキテクチャ決定
１９．１ アーキテクチャ決定に関するアンチパターン
１９．１．１ 資産防御アンチパターン
重要なアーキテクチャ決定を下すのを、最終責任時点まで先延ばしすることだ。これは、正当であると検証するのに十分な情報が得られるまで、決定を先延ばしすることを意味している。ただし、開発チームを待たせたり、分析麻痺アンチパターンに陥ったりするほど長くは決定を先延ばししてはならない。
→言っていることは分かるが、現実問題として最終責任時点のタイミングの見極めが相当難しいのでは？本人としては、アーキテクト本人が最終責任時点だと思っていても、まだ早かったり、もう遅かったりということが多々ありそうな気がする。
１９．３ アーキテクチャデシジョンレコード
アーキテクチャ決定を文書化する最も効果的な方法の１つに、アーキテクチャデシジョンレコード（Architecture Decision Records、ADR）ある。
→今までは使ったことない。アーキテクチャ決定したWhyの記録（ソフトウェアアーキテクチャの第二法則）として効果的なのであれば、今後のアーキテクチャ決定時に試してみたい。
２１章 アーキテクチャの図解やプレゼンテーション
新米アーキテクトがよく口にすることに、アーキテクトになったのは技術的な知識や経験があったからだというのに、アーキテクトの仕事がそれだけでなく、非常に多岐にわたっていることに驚いた、（中略）。アーキテクトがどんなに素晴らしい技術的なアイデアを持っていたとしても、マネージャーに資金を出してもらい、開発者に作ってもらえなければ、その素晴らしさは決して実現しないからだ。
→うーん、確かに仰る通り。でも、そこまでやれる人がどこまでいるだろうか、、、
２２章 効果的なチームにする
２２．１ チーム境界
アーキテクトが作る制約があまりにも緩いと（もしくはまったく制約を作らないと）、重要なアーキテクチャ決定をすべて開発チームに任せてしまうことになる。これは制約が厳しい場合と同じくらい悪い。
→この点は個人的に反省する点が多い。複数のスクラムチームで比較的大きなソフトウェアを開発する場合、スクラムの文脈を考えると、全てを自己組織化したチームに委ねてしまいたくなる。というより、むしろ委ねないといけない気すらしてしまうのだが、成熟してないチームだと当然カオス気味になる。スクラムにはアーキテクトというロールはないので、有識者が居たとして、どこまでスクラムチームに干渉（最初から制約を突きつけたり、積極的に助けてあげたり）するかは、特に初めてのシチュエーションではなかなか判断が難しいと思う。とはいえ、過去の反省を踏まえた今ならば絶対必要だと思うし、体制面としても明確にしておくべきだと思う。
２２．２ アーキテクトのパーソナリティ
プロジェクトの複雑さやチームのスキルレベルによっては、アーキテクトがコントロールフリークの役割を果たす必要がある場合もある。しかし、ほとんどの場合は、コントロールフリークアーキテクトは、開発チームを混乱させ、適切なレベルのガイダンスを提供せず、邪魔となり、チームを率いてアーキテクチャを実装することに関して効果を発揮しない。
→このあたりのバランスはとても難しそう。経験値が大きく問われそう。
２２．３ エラスティックリーダーシップ
効果的なソフトウェアアーキテクトは、開発チームをどの程度コントロールするかをわかっている。この考え方は、エラスティックリーダーシップとして知られており、Roy Osheroveによって広く提唱されている。（中略）。主に５つの要因がある。
- チームの親しさ
- チームサイズ
- 全体的な経験
- プロジェクトの複雑さ
- プロジェクトの期間
→確かに状況によって柔軟にコントロールするレベルを変えないと効果的でないのは理解できる。上記の要因や指標があっても尚難しそうだが、さじ加減を考える上での参考にはなりそう。
２２．５ チェックリストの活用
万策尽きた場合には、ホーソン効果を活用しよう。ホーソン効果とは、自分が観察されたり監視されたりしていることを知っていると、人は行動を変え、概して正しいことをするようになるというものだ。
→チェックリストの作成まではよくやる。すべてのチェックリストを検証することは現実的には難しいと思うけど、ロット検査のようにランダムサンプリングによる抜き取り検査ならできそう。それによるホーソン効果も期待できそう。（もちろんそんなことしたくはないが、、、イザとなったらロット検査するよ！と伝えるだけでも良いかも）
２３章 交渉とリーダーシップのスキル
２３．２ リーダーとしてのソフトウェアアーキテクト
ソフトウェアアーキテクトはリーダーでもある。アーキテクトはアーキテクチャの実装を通して開発チームをガイドする。私たちは、効果的なソフトウェアアーキテクトであることの50%は、優れたピープルスキル、ファシリテーションスキル、そしてリーダーシップスキルを持っていることだと考えている。
→このあたりのバランス感覚まで兼ね備えてしまうと、もはやアーキテクトの能力を持った有能なスクラムマスターという感じ。もはや君子
２４章 キャリアパスを開く
２４．１ ２０分ルール
このテクニックは、アーキテクトとしてのキャリアのために新しいことを学んだり、特定のトピックを深く掘り下げたりするのに、１日に少なくとも２０分は費やすというものだ。（中略）多くのアーキテクトはこの考え方に従って、昼休みや仕事が終わった後の夕方に２０分ほどかけてこの作業をしようとする。しかし、経験上、これがうまくいくことはほとんどない。ランチタイムはどんどん短くなり、休憩や食事の時間というよりも、仕事の追い込み時間になってしまう。夜はもっとひどい。状況が変わったり、予定が入ったり、家族との時間が重要になったりして、２０分ルールが実現しなくなってしまう。私たちが強く勧めるのは、一日の始まりである朝一番に２０分ルールを活用する方法だ。しかし、このアドバイスにも注意点がある。（中略）そのため、私たちは、朝一番のコーヒーや紅茶を飲んだ後は、メールをチェックする前に、２０分ルールを発動することを強くお勧めしている。少し早めに出勤する。これをすることで、アーキテクトの技術的な幅が広がり、効果的なソフトウェアアーキテクトになるのに必要な知識を身につけられる。
→めちゃワカル。メール見ないようにしてても、私信で来たチャットとかを、つい見ちゃうとそこで試合終了なんですよね。分かっちゃいるけどついやってしまう。キヲツケねば。
２４．４ 別れの挨拶
アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。（著者のひとりNealの言葉を引用）
→ソフトウェアアーキテクチャの第一法則と同じ内容を言葉を変え最後に語っている。著者（ら）がこの本を通して伝えたかった重要なメッセージングなのだと思う。
おわりに
ソフトウェアアーキテクチャには、絶対的な正解が存在しない。すべてはトレードオフなのだ、というこの本の強いメッセージに少し気後れはありますが、だからこそ追い求める価値があるものなのだという、冒険の旅のようなワクワク感もあります。そういえば、最近出版された「O'Reilly Japan - ソフトウェアアーキテクチャ・ハードパーツ」は、今回の「O'Reilly Japan - ソフトウェアアーキテクチャの基礎」の続編のようなタテツケで、長編の英雄譚（サーガ、Saga）の体で書かれているんだとか。ソフトウェアアーキテクチャを学び、追い求めることはまさに冒険なんですね。積読が滞留しているのですぐ手を出せませんが、少し時間を置いてから、そちらの本も読んでみたいと思います。
参考
- 『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2
- ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12
- 島田浩二氏を招聘して「ソフトウェアアーキテクチャの基礎」に関する社内セミナーを開催
https://www.bigtreetc.com/news/seminar_softwarearchitect_20221215/
