こんにちは！22日目に引き続きオルターブース エンジニア花岡です。
この記事はオルターブース Advent Calendar 2021の24日目の記事です。 adventar.org
最近ソフトウェアアーキテクチャに関する本を読んでいて、一度まとめたいなと思い、記事にしました。ソフトウェアアーキテクチャとは何なのかをこの記事で考えていきます。
ソフトウェアアーキテクチャの定義を探る
ソフトウェアアーキテクチャという抽象的な概念は人によって異なり、決定的な定義というものはなく、そもそも定義をすることが難しいです。しかし、ソフトウェアアーキテクチャの性質は本から探ることはできると思いました。それでは、Clean ArchitectureとDesign It!という2冊の本の定義から、ソフトウェアアーキテクチャとは一体何なのかを考えてみます。
Clean Architectureでの定義
まずは、Clean Architectureによると以下の通りです。
ソフトウェアシステムのアーキテクチャとは、それを構築した人がシステムに与えた「形状」である。その形状を生み出すためには、システムをコンポーネントに分割し、コンポーネントをうまく配置して、コンポーネントが相互に通信できるようにする必要がある。アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ、運用・保守を容易にすることである。～（中略）～優れたアーキテクチャがあれば、システムを容易に理解・開発・保守・デプロイできる。最終的な目的は。システムのライフタイムコストを最小限に抑え、プログラマの生産性を最大にすることである。
プログラマの生産性に着目しているのがポイントです。 ソフトウェアアーキテクチャはシステムを複数のコンポーネントによって分割、構成され相互に通信ができる形状であり、適切な形状であればプログラマの生産性を最大にできるというのは納得できます。逆に言えば、アーキテクチャが適切ではない場合、プログラマの生産性は最小に陥ってしまうことを開発者であれば経験したことがあると思います。初期の段階でアーキテクチャを深く考えずにソフトウェアを作ってしまうと、回収が難しい技術的負債ができてしまうのは、容易に想像できます。
Design It!での定義
次に、Design It!から引用します。
システムのソフトウェアアーキテクチャ とは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。設計判断の中には、さまざまな理由で重大な影響を与えるものもある。それは、後戻りできない判断かもしれないし、品質特性やスケジュール、コストへ影響を与える判断かもしれない。そのような重大な判断によって、多くの人が影響を受けたり、他のソフトウェアシステムが変更を強いられるかもしれない。いずれにしても、重要な設計判断を誤ると、後の変更コストが高くつくことになる。
文中にある品質特性とは利害関係者がソフトウェアに対する何らかのニーズを満たしているか（品質）を評価するための特性のことです。具体的には機能性や可用性、保守性、テスト容易性などのことです。Clean Architectureの定義では品質特性のことは言及していませんが、「システムを容易に理解・開発・保守・デプロイできる」というのは主に保守性や生産性のことを指していると思います。また、Clean Architectureではプログラマ視点でのソフトウェアアーキテクチャの定義ともいえます。そして、この定義では設計判断や品質特性といった言葉が使われており、利害関係者を含む考慮すべき設計事項の視点を含んだ定義ではないかと考えます。
そもそも、ソフトウェアにおける設計とはまさにソフトウェアをどう構成するかの決定や判断を積み重ねる活動のことを指すと私は考えています。ソフトウェアを構成するコンポーネントをどうするか、データストアをどうするのか、複雑な処理をどうやってプログラミングするかなどといった具体的なことから抽象的なことまでを階層構造的に構築し、ビジネス価値や環境の変化に対応していく設計をしていくことがソフトウェアアーキテクチャを構成していくことではないかと、この定義で感じました。
自分なりにソフトウェアアーキテクチャを定義してみる
2冊の本のソフトウェアアーキテクチャの定義の考察を書きました。それを踏まえて定義を自分なりの定義を考えてみました。
ソフトウェアアーキテクチャとはビジネスの要件や価値をソフトウェアに適応させるための設計判断の積み重ねである。
定義の意味を解説します。
ソフトウェアの価値は何らかのビジネスの要件や価値を実現させるためのものであると私は考えています。そしてそれを適応していくための設計と、ビジネスや環境の変化に対応できるような判断を積み重ねていくことがソフトウェアアーキテクチャの役割ではないかと考えました。
もちろん、異論は認めます。むしろどこかで議論の土台になればいいなと思います。
おわりに
今回ソフトウェアアーキテクチャの定義のことについて書いてみましたが、自分なりの定義を書くのが少し難しかったです。また、まだまとまっていないというか、まだ書けそうなこと（ソフトウェアアーキテクトやアーキテクチャパターンなど）があるので機会があれば書いてみようと思います。
