こんにちは、Tochiです。 先日上司からお薦めされた「ソフトウェアアーキテクチャの基礎」という本を読み始めたので、 記録用にブログでまとめていきたいと思います。
第一章
第一章はイントロダクションになっているので若干ふんわりしたまとめです。
1.1 ソフトアーキテクチャの定義
システムの構造とは、そのシステムを実装するアーキテクチャスタイル（マイクロサービス・レイヤードなど）を指す。
アーキテクチャ特性とは、システムがサポートしなければならない「イリティ（ility）」を指す。 (可用性・信頼性・テスト容易性・スケーラビリティ・セキュリティ・アジリティ・耐障害性・弾力性・回復性・パフォーマンス・デプロイ容易性・学習容易性）
アーキテクチャ決定は、システムをどのように構築すべきかのルールで、例えば、レイヤードアーキテクチャでいうビジネス層とサービス層だけがDBアクセスできるというルールを決定することです。
設計指針は、いわゆるガイドライン。アーキテクチャ決定とは異なる。
1.2 アーキテクトへの期待
ソフトウェアアーキテクトには8つの期待がある。
- アーキテクチャ決定を下すこと
- チームや部門の技術的な決定を導くためのあー着てくや決定や設計指針を定義すること。
- 例: 「フロントエンドにリアクティブベースのフレームワークを使う」など
- アーキテクチャを継続的に分析すること
- 現在の技術環境を継続的に分析し、改善を提案することが期待されている
- 3年前の定義が今日時点でどのくらい存続力があるかをビジネスと技術の両方から評価すること
- 最新トレンドを把握し続ける
- 先を見据えた判断をするために業界の動向や最新技術にキャッチアップ
- 決定の順守を徹底する
- さまざまなことに触れ、経験している
- 様々な技術・FW・プラットフォーム・環境に触れていることが期待されている
- 事業ドメインの知識を持っている
- 対人スキルを持っている
- アーキテクトにはチームワークやファシリテーション・リーダシップなど卓越した対人スキルを持ち合わせていることが期待されている。
- 政治を理解し舵取りをする
- アーキテクトには企業の政治的風土を理解し、政治を舵取りする能力が求められる
この章で個人的に印象的だったのは、「アーキテクトが下すほとんど決定は反発される」という部分。 アーキテクチャ決定はコストや作業量（時間）の増加の面から、PdMやPM・ビジネスサイドなどのステークホルダーから反発を受けますという旨の内容だったが、まさに似たようなことを前職で経験したなあとおもった。
1.3 アーキテクチャと交わるもの
この10年間で、ソフトウェアアーキテクチャの範囲は、ますます多くの席にや観点を含むようになってきている。
1.3.1 エンジニアリングプラクティス
プロセスは、チームの形成や管理・ミーティングの進め方・ワークフローの整理の仕方などを意味する。 つまり人がどのように組織化され、どのように相互作用するのかメカニズムを指す。
エンジニアリングにおけるプラクティスとは再現性のある効果を示す、プロセスに依存しない手法を意味する。例えば継続的インテグレーションなど。 このエンジニアリングプラクティスにフォーカスを当てることは重要だが、我々は「未知の未知」の領域に対してあらじめ設計することはできない。 よって、必要とされるのは「進化的なアーキテクト」であり、それを実現するにはアジャイルなエンジニアリングプラクティスを採用することが望ましい。
1.3.2 運用とDevOps
かつては運用とソフトウェア開発は別の機能として捉えられてきたが、いまや多くの運用上の関心ごとをアーキテクチャと組み合わせるようになった。
1.3.3 プロセス
ソフトウェアアーキテクチャとソフトウェア開発プロセスは直接関係がないとされる公理もあるが、、、、、、
チームがソフトウェアを開発するプロセスはソフトウェアアーキテクチャに多くの面で影響を与える。 例えば、アジャイルでの開発のPJのアーキテクトははイテレーティブな開発を前提にしていたりする。
1.4 ソフトアーキテクチャの法則
第一の法則は 「ソフトウェアアーキテクチャはトレードオフがすべてだ」
第二の法則は 「どうやってよりもなぜの方がずっと重要である」
