5分で読む「ソフトウェアアーキテクチャの基礎」1章 イントロダクション 要約
はじめに
本稿は名著「ソフトウェアアーキテクチャの基礎」の要約である。読者が5分程度で本書のエッセンスを捉えられることを意識して書かれてある。
本書籍の感想文は他にもいくつか公開されているが、本稿は節単位で要約をしていったため、比較的その中でも解像度の高い内容になっていると思う。
執筆のきっかけは仕事仲間からアクティブ・ブック・ダイアローグに誘われたことである。それまで漠然としていたアーキテクチャという概念を整理したいと思ったこと、そして文章力のトレーニングを習慣化する良い機会であると考え、要約作業に着手した。
本稿は1章の要約となっている。
途中、いくつか私の個人的なコメントも添えている（黄色い網掛けの箇所を参照）。
前後の投稿
更新について
週に1,2回ほどのペースで不定期に更新していく予定。
更新は@d5onodaでお伝えしていきます。もしよければフォローよろしくお願い致します。🙇♂️
本ABDへの参加の希望ありましたら、気軽にTwitterのDMにてお知らせ下さい！
要約の手順
- 前準備として、マインドマップで文章を階層化し整理する。
- マインドマップをもとに要約する。
1章 イントロダクション
なぜソフトウェアアーキテクチャには明確なキャリアパスがないのか?
- 理由1：ソフトウェアアーキテクチャ自体の定義が業界でよく定まっていないから。
- 理由2：ソフトウェアアーキテクチャの役割が非常に広範囲にわたり、拡大を続けているため。
- 理由3：開発エコシステムの急速な進化と比例して、ソフトウェアアーキテクチャも常に変化しているから。
- 本書において、ソフトウェアアーキテクチャは動的な性質を持つものであると定義する。
- 理由4：ソフトウェアアーキテクチャについての過去の試行錯誤の成功や失敗が、意味のある資料として整理されていないから。
なぜ今ソフトウェアアーキテクチャの基礎を扱うか。
アーキテクトが下す決定の多くは、彼らの仕事の環境に基づいている。そして、その決定内容は技術の進歩によって常に変化してきた。いかなるアーキテクチャもこの文脈によって成り立つものである。
1.1 ソフトウェアアーキテクチャの定義
アーキテクチャを分析する際、アーキテクトは何を分析するのか?
私達は、業界全体でソフトウェアアーキテクチャを正確に定義することに取り組んできた。その結果、今日では様々なアーキテクチャの定義が存在する。
- システムのブループリントである。
- システム開発のロードマップである。
- etc...
アーキテクトは、これらの定義に込められた意図を理解せねばならない。アーキテクチャを分析する際、アーキテクトは何を分析するのか?
ソフトウェアアーキテクチャの４つの要素
- 構造
-
システムを実装するアーキテクチャスタイルの種類。
- マイクロサービス
- レイヤード
- マイクロカーネル
- etc...
-
構造だけではアーキテクチャの理解には不十分。
例）以下は、構造についてしか答えてない。他の要素も理解が必要。
Q「アーキテクチャを説明して」
A「マイクロサービスアーキテクチャです」
-
- アーキテクチャ特性
- システムの成功基準を定めるものであり、システムの機能とは直接関係ない。
- システムが適切に機能するために必要なもの。
- 具体的には以下を指す。
- 可用性(Availability)
- 信頼性(Reliability)
- スケーラビリティ(Scalability)
- etc...
- アーキテクチャ決定
- システムの構築ルールを定めるもの。
- 例)データベースに直アクセス可能なのはビジネス層とサービス層のみ。
- システムの制約を形作り、何が許されて何が許されないかに関する開発チームの指針。
- 例外によって破られることもある。
- その正当性やトレードオフに基づき承認される。
- システムの構築ルールを定めるもの。
- 設計指針
- ルールではなくガイドライン（この点でアーキテクチャ決定とは異なる）。
- すべてのルールを定めるのは不可能。代わりに設計指針として望ましいアプローチに関するガイドを提供する。
1.2 アーキテクトへの期待
- ソフトウェアアーキテクトの役割を定義するのは難しいため、アーキテクトへ期待する内容に注目しよう。
- アーキテクチャ決定
- アーキテクチャを継続的に分析
- 最新トレンド把握の維持
- 決定の遵守徹底
- 多様な経験
- 事業ドメインの知見の保持
- 対人スキルの保持
- 政治の理解と舵取り
1.2.1 アーキテクチャ決定を下す
期待されていること
- 組織の技術的な決定のためのアーキテクチャ決定や設計指針を定義する。
重要なのは「指定」ではなく「ガイドする」こと。効果的なアーキテクチャ決定の鍵は、その選択によって、チームが適切な技術的選択を行えるかである。
- 良い例）アーキテクトは、フロントエンド開発にリアクティブベースのFWを使うことを決定する。チームは自分達の裁量でリアクティブベースのFWを選択可能。
- 悪い例）アーキテクトは、フロントエンド開発にReactを使うことを決定する。チームにアーキテクトの決定を押し付けている。
例外もある。特定のアーキテクチャ特性を維持するためにトレードオフで技術的選択をすることもある。
1.2.2 アーキテクチャを継続的に分析する
期待されていること
- アーキテクチャや現在の技術環境を継続的に分析し、改善案を提案すること。
過去のアーキテクチャが現在においてどれくらい存続力があるか、ビジネスと技術、両方の変化から評価される。継続的な分析をしない場合、アーキテクチャは構造的崩壊を起こす。構造的崩壊は、開発作業が、パフォーマンスや可用性、スケーラビリティなどのアーキテクチャ特性に影響を与えることで生じる。
1.2.3 最新のトレンドを把握し続ける
期待されていること
- 最新技術や業界動向の把握を維持し続けること。
アーキテクトが下す決定は、システムに長期間にわたって大きい影響を与え、変更が困難であるものが多い。そのため、現役であり続けるには、最新技術や業界動向をキャッチアップし続ける必要がある。
1.2.4 決定の遵守を徹底する
期待されていること
- アーキテクチャ決定や設計指針の遵守を徹底すること。
決定が遵守できない、例えば離反が発生した場合、離反が続出することに繋がる。これは、求められるアーキテクチャ特性を満たせなくなる要因が増えていくことであり、システムが期待通りに動かなくなる可能性を上げてしまう。
1.2.5 さまざまなものに触れ、経験している
期待されていること
さまざまな技術やFW、プラットフォーム、環境に触れていること。
今日の異種混合のシステム環境に対応するには、以下の組み合わせを広く持っておくことが重要である。
- 詳しくないが知っているもの（インデックス知識）
- 十分によく知っているもの
具体的には、1種類のソフトウェアの専門家であることよりも、10種類のソフトウェアの長所と短所を知っていることのほうが重要である。深い知見が必要となった時には、インデックス知識をとっかかりにすぐに前に進むことが可能であればよい。
1.2.6 事業ドメインの知識を持っている
期待されていること
- 事業ドメインに関する一定の専門知識を持つこと。
ビジネス上の問題や目標、要件、要求を理解し、ビジネス要件を満たす効果的なアーキテクチャを構築するためには、事業ドメインの理解が必要である。
成功しているアーキテクトが持っているものは、幅広い実践的な技術知識と特定のドメインに関する強い知識である。これらは、アーキテクトが役員レベルのエグゼクティブやビジネスユーザーと正確にコミュニケーションして彼らの要求を理解することに役立つ。さらには、これらが顧客からの信頼感を得られることにつながる。
1.2.7 対人スキルを持ち合わせている
期待されていること
- チームワークやファシリテーション、リーダーシップなど、卓越した対人スキルを持つこと。
多くの開発者やアーキテクトにとって、対人スキルを持つことはハードルが高い。理由としては、開発者やアーキテクトが技術的な問題解決を好むためである。
しかしながら、アーキテクトに必要なスキルの半分以上は対人スキルである。それは持っていない他のソフトウェアアーキテクトとの差別化になるだろう。
1.2.8 政治を理解し、かじ取りをする
期待されていること
- 企業の政治的風土を理解し、政治を舵取りする能力。
決定権を持っている人達との交渉力の重要性を理解していることである。
アーキテクトの決定は、そのほとんどが反対される。
組織からみたシステムの最適解が、個々のプレーヤー（ステークホルダーやPO、開発者など）にとっての最適解とは限らない。そのため、様々な場面において各プレーヤーとの調整が必要となる。社内政治のかじ取りと交渉力を用いて、各レイヤーと議論し、説得せねばならない。
1.3 アーキテクチャと交わるもの
昔と違い、今のアーキテクチャは、DevOpsとの連携によってかつての運用も取り込まれている。
以降の章では、アーキテクトと他社との関係と、求められる新しい能力・責任について掘り下げる。
1.3.1 エンジニアリングプラクティス
開発プロセスと開発エンジニアリングプラクティスの分離
従来、ソフトウェアアーキテクチャはソフトウェア開発プロセスとは分離されていた。しかし、技術の進歩で、プロセスの問題がソフトウェアアーキテクチャの領域に入り込むようになってきた。
開発プロセスと開発エンジニアリングプラクティスは分けて考える。
- 開発プロセス
- 人がどのように組織化され相互作用するのかのメカニズム。
- 具体的には、MTGの進め方、ワークフローの整理の仕方、チーム形成や管理など。
- 開発エンジニアリングプラクティス
- 再現性のある効果、プロセスに依存しない手法である。
- 具体的には、継続的インテグレーションなど。
エンジニアリングプラクティスにフォーカスする
- ソフトウェア開発における「欠けていることを自覚する重要性」について整理する。
| 知見の種類 | 概要 | 詳細 |
|---|---|---|
| 既知の知 | 知っていることを、自覚している | ・プロジェクトに必要な知見をすべて把握している。 ・プロジェクトがこの状態であることはまずない。 |
| 既知の未知 | 知らないことを、自覚している | ・多くのプロジェクトはここから始まる。 ・学ばなければならないと知っている技術やドメイン知識を把握できている状態。 ・未知の知識を学ぶためのとっかかり（インデックス知識）を持っている。 |
| 未知の知 | 知っていることを、自覚してない | ・あなたは疲れている。まずは休もう。それから考えよう。 ・頭がクリアな状態で、新しい知識と既存知識の紐付けを試してみよう。 |
| 未知の未知 | 知らないことを、自覚してない | ・開発における最大の敵。 ・開発をしていると突然現れる、誰も予測できなかった課題である。 ・ソフトウェア開発の「時間やリソース、コスト」の見積もりはこの領域。これは、人間がもっとも苦手とすることであり、ソフトウェアの取り組みが失敗する大きな理由の一つである。 ・アーキテクトはこれに対して設計することはできない。 そのため、アーキテクチャはイテレーティブにならざるを得ない。対策としては、アジャイルによる未知への即時対応がある。 |
-
「進化的アーキテクチャ」とはなにか。
アーキテクトは、自分の設計が正しく実装されているかを定期的に確認し続けねばならない。加えて、開発エコシステムによって発生する変化に対応し続ける必要がある。
進化的アーキテクチャでは、時間と共に変化するアーキテクチャ特性（-ility）の整合性を客観的に評価する考え方として、「適応度関数」を紹介している。 -
適応度関数とはなにか。
常に変化していくエコシステムにイテレーティブに対応した結果が、その最適解とどれくらい離れているのかを評価するツールである。
具体例として継続的に「巡回セールスマン問題」のアルゴリズム開発をしていくことを考えてみる。この場合、適応度関数は、経路の長さを評価することになる。 -
アーキテクチャ適応度関数
適応度関数をアーキテクチャに応用することを考える。評価には、メトリクス計測やユニットテスト、監視やカオスエンジニアリングなどの仕組みが用いられる。
具体例として継続的に「ページの読み込み時間」をアーキテクチャの重要な特性としてみなした場合を考えてみる。アーキテクトは各ページの読み込み時間計測処理を適応度関数として構築し、プロジェクトのCIの一環として、その関数を実行することになる。
このように、システムの各部を適応度関数で検証する仕組みを持つことで、アーキテクトはアーキテクチャの重要な部分の状態を常に把握可能となる。
1.3.2 運用とDevOps
DevOpsの登場によってアーキテクチャの公理が見直された。
従来の公理は、リソースの割当が適切ではないことが、偶発的な複雑さを生んでいた。あるチームが、運用上の関心事は運用メンバーが処理したほうがよいと考え、アーキテクチャと運用を連携させるため、設計をシンプルにし、運用メンバーに対応を任せる方法をとった。これにより、マイクロサービスアーキテクチャが作られた。
1.3.3 プロセス
考え方その1：ソフトウェアアーキテクチャと開発プロセスは無関係
プロセスは構造には影響しないという考え方がある。しかし、ソフトウェアアーキテクチャに関する書籍の多くは開発プロセスを無視しており、予測可能性などの問題の誤った仮説を持っている。
考え方その2：開発プロセスはソフトウェアアーキテクチャに大きく影響する
モノリシックアーキテクチャではあえて古いプロセスを使用することもある。これは、アーキテクチャ構築の年代や、政治的要因が理由である。
アジャイル開発アーキテクトはイテレーティブな開発を前提にしている。決定に対するすばやいフィードバックを経て、アーキテクトはFB依存の実験や知識に対して積極的に活動できる。すべてのアーキテクチャはいずれイテレーティブになるだろう。
アジャイル方法論が活きるアーキテクチャの側面としては「再構築」がある。アーキテクチャをあるパターンから別のパターンに移行するのはよくあることだ。
1.3.4 データ
本格的なアプリケーションでは、外部ストレージにRDBMSなどのデータベースが使用される。つまり、コードとデータは共生関係にある。
1.4 ソフトウェアアーキテクチャの法則
第1法則：ソフトウェアアーキテクチャはトレードオフがすべて
すべての決定は、多くの相反する要素を考慮する。つまり、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していない可能性が高い。
第2法則：「どうやって」よりも「なぜ」の方がずっと重要
知識を持っていない既存システムを見た時、アーキテクトはその構造がどう動くのかは解明できる。しかし、なぜその選択がなされたのかの説明は困難である。
ソフトウェアアーキテクチャは、構造や設計指針、アーキテクチャ特性などを超えて定義する。なぜならば、アーキテクチャはそれらの要素よりもずっと広大だからである。
本稿の終わりに
書籍の要約はまだまだ続きます。
更新は@d5onodaでお伝えしていきます。もしよければフォローよろしくお願い致します。🙇♂️
本ABDへの参加の希望ありましたら、気軽にTwitterのDMにてお知らせ下さい！
→ To be continued!
Discussion