読書メモ: 「ソフトウェアアーキテクチャの基礎」第1章

「ソフトウェアアーキテクチャの基礎」を読んで学んだことをまとめておく。

はじめに: 公理を疑う

公理とは「確立され、一般に受け入れられているか、または自明の真実とみなされている言説、命題」のこと。
ソフトウェアの世界では、理論のベースとなる公理を含めて、基礎的な物事が急速に変化している。アーキテクチャに関する多くの本が書かれた当時にはなかったプラクティスや運用、開発プロセスなどが出てきている。アーキテクトには、過去の時代から残されている公理や前提を疑う責任がある。
かつてソフトウェアアーキテクチャの定義は「後からの変更が難しいもの」だったが、現在は「変化」こそが第一級の設計上の考慮事項となった。
アーキテクトは決まったものを選べばよいわけではない。トレードオフを分析し、選択の良し悪しを評価する必要がある。

1章 イントロダクション

ソフトウェアアーキテクチャの定義

• 構造
• アーキテクチャ特性(-ility)
• アーキテクチャ決定
• 設計指針

構造

「構造」とは、システムで使われているアーキテクチャスタイルの種類を指す。例えば、マイクロサービス、レイヤード、マイクロカーネルなどが該当する。スタイルだけでは、アーキテクチャを十分に解明することはできず、アーキテクチャ特性、アーキテクチャ決定、設計指針まで含めて考えなければならない。

アーキテクチャ特性

「アーキテクチャ特性」とは、システムがサポートしなければならない特性のこと。
具体的には

• 可用性(Availability)
• 信頼性(Reliability)
• テスト容易性(Testability)
• スケーラビリティ(Scalability)
• セキュリティ(Security)
• アジリティ(Agility)
• 耐障害性(Fault Trelance)
• 弾力性(Elasticity)
• 回復性(Recoverability)
• パフォーマンス(Performance)
• デプロイ容易性(Deployablity)
• 学習容易性(Learnability)

などが挙げられる。

アーキテクチャ決定

「アーキテクチャ決定」は、システムを構築する際のルールを定めるもの。システムの制約を形作り、何が許されて何が許されないのか、というチームの開発指針となる。

例：レイヤードアーキテクチャで「ビジネス層とサービス層のみがデータベースにアクセスでき、プレゼンテーション層からデータベースへの直接的なアクセスは許さない」というルールを定める

設計指針

「設計指針」は、(堅苦しいルールではなく)ガイドライン。

例：開発チームはマイクロサービスアーキテクチャのサービス間の非同期メッセージングを利用して、パフォーマンスを向上させるべきという指針を定める

すべての選択肢を網羅するルールを定めることはできない。望ましいアプローチのガイドラインを定めることで、開発チームが適切な選択をできるように促す。

アーキテクトへの期待

アーキテクチャ決定を下す

アーキテクトには、チームや部門、あるいは企業全体の技術的な決定を導くために使用される、アーキテクチャ決定や設計指針を定義することが期待されている。重要なのは、技術的な選択を指定するのではなく、「ガイドする」こと。

アーキテクチャを継続的に分析する

アーキテクトには、アーキテクチャや現在の技術環境を継続的に分析し、その上で改善策を提案することが期待されている。これはアーキテクチャの存続力に注目したもの。
例えば、三年以上前に定義されたアーキテクチャが今日の時点でどれくらいの存続力があるか、ビジネスと技術、両方の変化から評価するなど。
テストやリリースのための環境について、分析が忘れられがちだが重要。

最新のトレンドを把握し続ける

アーキテクトには、最新の技術や業界の動向を常に把握し続けることが求められる。アーキテクトが下す決定は、長期間影響を与え、変更が難しいものであることが多い。動向を把握し、先を見据えた判断を下す必要がある。

決定の順守を徹底する

アーキテクトには、アーキテクチャ決定や設計指針の順守を徹底することが期待されている。これはアーキテクトが定義し、文書化し、伝達したアーキテクチャ決定や設計指針に開発チームが従っているかを、アーキテクトが継続的に検証することを意味する。
例として、レイヤードアーキテクチャでのデータベースアクセスをビジネス層とサービス層のみに制限する（プレゼンテーション層からはデータベースへアクセスできない）という決定を行なったとする。パフォーマンス上の理由からUIの開発者がデータベースに直接アクセスしてしまうという違反が起きると、レイヤーを閉じることができず、データベースの変更は困難になる。これにより、アーキテクチャ特性が満たせなくなってしまう。

さまざまなものに触れ、経験している

アーキテクトには、さまざまな技術、フレームワーク、プラットフォーム、環境に触れていることが期待されている。今日のほとんどの環境は異種混合のものとなっているためである。さまざまなシステムやサービスとやりとりする方法を、それらがどんな言語やプラットフォーム、技術を使っているかに関係なく、わかっている必要がある。

事業ドメインの知識を持っている

アーキテクトには、事業ドメインに関する一定の専門知識が求められる。ビジネス上の問題や目標、要件を理解するのが難しいと、ビジネス要件を満たす効果的なアーキテクチャを設計できないため。

対人スキルを持っている

アーキテクトには、チームワークやファシリテーション、リーダーシップなど、卓越した対人スキルを持ち合わせていることが期待されている。ワインバーグが言っているように「一見どう見えようとも、それはつねに人の問題」である。リーダーシップスキルは、有能なアーキテクトに必要なスキルのうち、少なくとも半分を占めている。

政治を理解し、かじ取りをする

アーキテクトには、企業の政治的風土を理解し、政治をかじ取りする能力、すなわち交渉力が求められる。（一例として、データベースへのアクセスの仕方を制限するなど）アーキテクチャ決定は影響範囲が広く、その影響力も大きいため、アーキテクトが下すほとんどの決定は社内で反発がある。その正当性を示し、決定を承諾してもらうのは重要なスキル。

アーキテクチャと交わるもの

ソフトウェアアーキテクチャは従来、ソフトウェア開発プロセスとは分離されていた。ところが、現在は開発プロセスがアーキテクチャの領域に入ってくるようになっている。それでも「開発プロセス」と「エンジニアリングプラクティス」を分けて考えた方がよい。

プロセスとは、チームの形成や管理、ミーティングの進め方、ワークフローの整理の仕方などを指す。すなわち、人がどのように組織化され、相互作用するかのメカニズムのこと。

エンジニアリングプラクティスとは、再現性のある効果を示す、プロセスに依存しない手法を指す。例えば、継続的インテグレーションは、特定のプロセスに依存しない、実証されたプラクティスである。

ソフトウェア開発ではなく、エンジニアリングプラクティスにフォーカスすることが重要である。ソフトウェア開発プロセスの弱点として、リソースやコストに対する見積もりの難しさという側面がある。われわれが知らないということさえ知らない「未知の未知」の領域に対する予測や見積が困難であるため。
未知の未知に対しては設計を行うことはできない。このことが「先読みしすぎた設計」が失敗する理由。

未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解して、より早く未知の未知に対処するようになっている。

したがって、アーキテクチャはプロセスとは独立しているものの、イテレーティブなプロセスの方がソフトウェアアーキテクチャの性質により適しているといえる。
また、アーキテクトは、アーキテクチャスタイルに合ったエンジニアリングプラクティスを選択しなければならない。（例えば、マイクロサービスアーキテクチャは自動化されたマシンプロビジョニングや自動テスト、自動デプロイなどを前提としているため、それらを行わない手法で構築しようとすると問題が発生する）
「進化的アーキテクチャ」という書籍では、アーキテクチャの統制を自動化できるようにする新しい考え方を紹介している。例えば「アーキテクチャ適応度関数」という考え方で、アーキテクチャ特性の整合性を客観的に評価する。仮に、アーキテクトがページ読み込み時間を重要なアーキテクチャ特性とみなした場合、パフォーマンスを低下させることなくシステムを変更できなくてはならない。そのため、アーキテクトは、ページの読み込み時間を計測するテストを適応度関数として構築し、プロジェクトの継続的インテグレーションの一環として、そのテストを実行するようにする。

ソフトウェアアーキテクチャの法則

第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ
第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ。