この記事はハワイアンAdvent Calendar 2020 3日目の記事です。2日目 読んだ方、今日は何日後に寿命が尽きるものを作りましたか。遺書は書きましたか。その遺書は一旦寝かせておいて、次の作業に移りましょう。

もうちょっと合間を埋めるべきな気がしますが、気持ちが先走っているので進化的アーキテクチャに足を突っ込んでしまいます。 イメージが欲しい方はこのスライドも見ながらどうぞ。

進化的アーキテクチャの第一原則は「複数の次元で誘導的かつ漸進的な変更を支える」となっています。では、後ろから攻めていきましょう。

「漸進的な」とか「インクリメンタルな」という表現を初めて目にしたのはXP (Extreme Programming) だったかなあとあやふやに覚えていますが、あれって原点てなんなんでしたっけ。忘れました。漸進的なアーキテクチャについて触れている本でいうと Beautiful Architecture がありますね。近年ではあんまり話題にあがらなくなりましたが、あれも楽しい本です。プログラミング初学者にはおすすめしません。まあおいといて、漸進的な変更やら漸進的な成長という表現は現代のソフトウェア開発からは切り離せないキーワードですね。

「誘導的な」という点はどうでしょうか。Technology Raderに初めて登場した頃や、InfoQで再度取り上げられた頃は「誘導的」の部分は「継続的(Continual)」だったような気もしますが、初の書籍となった Building Evolutionary Architectures でも “guided” となっているし、実際に「誘導的」だというのも構築・運用してみてたしかに誘導的だな、と納得できるものがあります。ここは長い話になりそうなのでとっておきましょう。うまく文章として仕上げられるのか分かりませんが…。

「複数の次元」という点についてはどうでしょうか。書籍の中では「技術・データ・セキュリティ・インフラ」といった非機能要件を主にアーキテクチャ特性として取り扱っていますが、本当にそれだけでしょうか。補足として、書籍の中では「変更が影響を与える全ての部分を考慮しなくてはならない」とあるので、上記だけではない事を示唆している事が読み取れます。では、それはなんでしょうか。ここまでの文章のテンポが悪いのでさっと書きますが「技術・データ・セキュリティ・インフラ」を更に蒸留していけば、それらを支えている人、チームがいます。人やチームはスキルセットを持っています。加えて、ソフトウェアはなまものなので、複数の次元は時間と共に変化していきます。つまりメンバーのスキルセットも変更が入ります。エンジニアの採用市場も変化しますね。数年後xxエンジニアの採用市場はどうなっているでしょうか。市場動向にむけた会社の取り組みを元に、どれくらい人が取れて、またどれくらい人が抜けて、どれくらい社内でも流動性があって…いやあ組織運営は大変です。もっと根本的な所が抜けてますね。なんでしょうか。サービスそのものがありますね。プロトタイプフェーズだったり、事業拡大フェーズだったり、サービス開発のスタイルも変更しますよね。こうやって脊髄で書いているだけでポンポンと出てくるので、ボトムダウンすればもっとありそうですね。

皆さんの開発しているソフトウェアのアーキテクチャはそれら全てを包括し漸進的な変更として支えられるアーキテクチャとなっているでしょうか。もちろん最初からこんなに考慮する必要など無いわけですが、それならそれとプロトタイピング段階でのソフトウェアアーキテクチャに寿命が来る事を踏まえてソフトウェアアーキテクチャそのものに対しても漸進的な変更ができているでしょうか。加えて、その変更はこれまでに述べた「複数の次元」をすべて考慮できているでしょうか。できてないから「成長痛」が発生してしまうんですね。遺書の話でも書きましたが「予測できる未来は予測して寿命見積もりの精度を高める」というのは、ソフトウェアアーキテクトのスキルセットとして、適切なタイミングで変更へと導く意味で必要、という事が言いたかったわけです。そしてこれまでに記載した通り、複数の次元というのは本当に色んな次元を向いているので、その設計精度を高めるためにはプログラミング知識だけでなく様々な分野の知識が必要なんですね、という話でした。ソフトウェア設計って、楽しいよね！

今日は以上です。良いと思ったら、高評価・コメント・チャンネル登録よろしくお願いします。