今年もあまり本が読めなかったけど、それでも今年に読んだ本の中でピカイチのものでした。
MVP を構築した後で良いフィードバックが得られたとしたら、イチからその MVP を作り直してサービスとして公開しよう、という話は仕事でもよく聞きます。 しかし、実際に MVP がスクラップ&ビルドで再構築されるのは稀有な例で、だいたいは MVP を修正して正式サービスにしようということがされがちです。 ぼくがこの本に出会ったのは、そういう場合に「どうやってアーキテクチャレベルで MVP から正式サービスへ推移させれば良いのか」に悩んでいたときでした。
この書籍で述べられる「進化」は、必ずしも直接的にその答えにはならないですが、それでも「アーキテクチャを進化」させるにはどのような考え・方法が必要なのか、 アーキテクトは何をしていけば良いのか、という示唆を得る上では本当に良い本でした。繰り返し読みたい。
アーキテクチャの進化
システムは開発したときではなく動き続けて価値を生むというのはよく言われることです。一方で、この「動き続ける」中で世の中がどのように動くのかというのは予測できるものではありません。 そして、世の中の動きに依って、システム自体もその動きを反映していかなければなりません。 この意味で、ソフトウェアアーキテクチャ、システムアーキテクチャを設計するときは、「特定の時点に向けての設計」ではなく、時間を加えた4次元の設計として、「進化」を含めてアーキテクチャ設計をしていく必要がある。
それではどのようにすれば、アーキテクチャは「進化可能性」を手にするのか。それが私が思う、この本の取り組む主題です。
機能の追加というレベルでなくアーキテクチャ自体を進化させる、そして進化させるためにどのようなアプローチを取るべきか、という書籍の主題は、アーキテクチャはほとんど静的なものと暗黙的にとらえていたぼくにとっては、衝撃の大きなものでした。 一方で、昨今のサービスにおいては静的であることはそのまま死を意味するので、アーキテクチャを成長させ進化させるのは今後必須の考え方になるようにも思えます。
進化的アーキテクチャ
この書籍においては、進化的アーキテクチャの定義を
複数の次元にわたる漸進的で誘導的な変更を支援するものである
としています。漸進的な進化、誘導的な進化というのは、この書籍で述べていることの大きなカギになります。
アーキテクチャの進化は、そのシステムが持つべきアーキテクチャ特性を評価する必要があります。書籍の中では「適応度関数」と述べていますが、例えば
- セキュリティ
- 可用性
- パフォーマンス
というような非機能要件であったり、「Controlloer 層は Infrastructure 層の機能を直接呼び出してはいけない」というような制約であったりします。
このような重要視すべきアーキテクチャ特性を適応度関数として実装し、それを適切なタイミングでテストし続けることで、アーキテクチャ特性を維持したまま別のアーキテクチャに移動させていったり、特定のアーキテクチャ特性が失われていることを検知できたりします。
非常に興味深かったのは、この適応度関数によってアーキテクチャの進化の方向性を「誘導」していることです。 自然界の「進化」は突然変異に依って意図せぬ方向に進んでしまうことも多いですが、アーキテクトが気にすべきアーキテクチャ特性の次元を見つけ、それを適応度関数として定義し常に検証し続けることで、アーキテクチャの進化は行きあたりばったりの方向ではなく、望ましい方向に収斂していきます。「進化の方向をコントロールする」というこのアイディアを書籍中では「誘導的な進化」と表現しているのですが、設計と開発プロセスによって進化の方向に制約をつけるという考え方を見聞きするのは初めてで、知的興奮がすごかった。
結合
アーキテクチャを進化させる上で重要な観点として、如何にして不要な結合を避けるか、というテーマがあります。
例えば、本質的に独立したコンポーネントが強く強調し合うアーキテクチャを「非構造化モノリス」と呼んでいますが、このアーキテクチャの上で何か変更を加えようとすると、他の箇所にも影響が生じ、簡単にはいきません。これが不要な結合が横行している例です。 それが「レイヤー化アーキテクチャ」ならどうか。「モジュール化モノリス」なら? 「マイクロサービスアーキテクチャなら進化させやすい?」といったアーキテクチャ論はもちろん、他チームと不要な結合をしてしまうと調整コストが嵩み進化可能性を損なうからどうすべきか、といった、「結合」を防ぎ如何に適切な機能を「凝集」させるか、という主張が次から次へと繰り出されます。
アーキテクチャ設計をこれまでよりずっとメタな視点で俯瞰し続ける内容で、アーキテクトとしての今後の未来はここにあるのかなと思ったりもしました。
今まで甘えすぎていたのかもしれない
徹頭徹尾貫かれる主張は、アーキテクトはアーキテクチャ特性を「評価可能なもの」として考えるべき、ということであったと思っています。 必要なアーキテクチャ特性を抽出し、適応度関数として定義・実装し、デプロイメントパイプライン上で検証し続ける。それがアーキテクトとしての当然の責務だとすると、ぼくはずっと甘え続けていたのかもしれないなと、そういう反省を強くする書籍でした。
