【東京通信大学】3年次1学期の成績
palm
Palm Blog
【ざっくり】ソフトウェアアーキテクチャの基礎のまとめ
palm
想定する読者
- ソフトウェアアーキテクト（役割）に興味がある人
- 読む時間がないので概要や要約を把握したい人
- 状況に応じた技術選定をする能力や交渉力が欲しい人
横文字が多い本でした。要約といえど、少し苦労するかもするません。
この記事の目次
ソフトウェアアーキテクトとは？
- ソフトウェアアーキテクトは、数学者が公理に基づいて理論を構築するように、前提を土台として理論＝アーキテクチャを設計する存在である
- ソフトウェアアーキテクトは、過去から引き継がれた前提や「当たり前」とされてきた公理そのものを疑い、検討し直す責任がある。
- ソフトウェアアーキテクチャとは皮肉にも、「後から変更するのが難しいもの」である。だからこそ、慎重な判断が求められる。
- ソフトウェア工学は、他の工学分野と比べてまだ若く、発展途上である。
- ソフトウェアアーキテクトの重要な役割は、唯一の正解を求めることではなく、トレードオフを分析し、状況に応じて技術選定を行うための思考力を持つことである。
「アーキテクチャ=後から変えにくいもの」
間違えた時の被害を最小化する学問です。
そのためのキーワードとなるのが”トレードオフ“です。
Who Needs an Architect?
- アーキテクチャは「重要だが固定的ではない」
- ソフトウェアは急速に進化しており、 アーキテクチャも静的な設計物ではなく、動的に変化する対象として扱う必要がある。
- アーキテクチャとは「構造」ではなく「意思決定」
- 特に重要なのはアーキテクチャ決定で、 「何が許され、何が許されないか」を定め、 チームの自由度を適切に制御する。
- 「指定」ではなく「ガイド」する役割
- アーキテクトは技術を強制（指定）してはいけない。
- 代わりに、「望ましい選択肢」を示し、判断の余地を残す。
- アーキテクトに求められる能力
- 継続的な分析力
- トレンド把握
- 事業ドメイン理解
- 対人スキル・交渉力（政治力）
- リーダーシップ
- つまり、多くの技術の長所・短所を理解している人の方が価値が高い。
- プロセスよりエンジニアリング、そしてアジリティ
- プロセス→アジャイルなど
- 良いエンジニアリング→CIやテストファーストはプロセスに依存しない
- 先読みしすぎた設計（BDUF）は危険。
- 最終的に イテレーティブ（反復的）に進化せざるを得ない。
- 評価と適応：アーキテクチャを「測る」
- 特性を適応度関数（初期から考慮すべき）を用いて客観的に評価
- 進化を前提とした移行戦略
- 一気に作り直さない
- レガシーは「悪」ではなく、 安全に置き換える対象。
- 第一法則：すべてはトレードオフ
- 設計に万能解はない。
- 解決策よりも「どうやって」より「なぜそれを選んだか」意思決定の理由を説明できることがアーキテクトの価値。
つまり、アーキテクチャには正解は存在しません。
技術的な広い視野や経験を持ち長所・短所を押さえ、未来を予測しながも、失敗はつきもの（正解はない）という広い心を持つことです。
「アーキテクト≠設計士、設計図作る人」
みんなが長期的に幸せになるための意思決定をする思想家です。
アーキテクトの思考様式（Architecture Thinking）
- アーキテクトは「視点」が違う
- アーキテクチャ思考とは：
- 設計とアーキテクチャの違いを理解する
- 開発チームと協働してアーキテクチャを“機能させる”
- 技術・選択肢・トレードオフを分析・調整する
- ビジネスドライバーをアーキテクチャ特性へ翻訳する
- アーキテクチャ思考とは：
- アーキテクトと開発チームの責任分担
- アーキテクト（技術的な幅と視野）
- ビジネス要件からアーキテクチャ特性を定義
- パターンやスタイルを選択
- システム全体の構成と制約に責任を持つ
- 開発チーム（技術的な深さ）
- クラス設計・UI設計
- 実装・テスト
- アーキテクチャを成功させるには、 上下関係ではなく双方向の強い協力関係が不可欠。
- アーキテクト（技術的な幅と視野）
- 深さより「幅」が重要になる理由
- 3層の個人の知識とは
- わかっていること（専門性・深さ）
- わかっていないとわかっていること（幅）
- わかっていないとわかっていないこと（未知）
- アーキテクトにとって重要なのは 「知らないことを把握している広さ」。
- 開発者からアーキテクトになるには：
- 一部の専門性を手放す覚悟が必要
- 全方位で専門家であろうとすると破綻する
- 昔の成功体験に縛られるは大きなリスク。
- 3層の個人の知識とは
- アンチパターンと誤解
- 氷漬け原始人アンチパターン
- 昔の経験や常識を押し付けるアーキテクト
- アーキテクチャに正解はない：
- Googleで答えは出ない
- あるのはトレードオフだけ！！！（大事なキーワード）
- 「最善策」は常に場合による！！！！（大事なキーワード）
- 氷漬け原始人アンチパターン
- トレードオフ思考の具体例（キュー vs トピック）
- トピック方式（Pub/Sub）
- 拡張性が高い（新サービス追加が容易）、既存システムに変更不要。
- しかし、盗聴しやすい、コントラクト変更の影響範囲が広い
- キュー方式（P2P）
- セキュリティ・制御性が高く、コンシューマ単位でスケール可能。
- しかし、新機能追加時に変更が必要で結合度が高くなる。
- どちらも正解！！！（ビジネス要件とアーキテクチャ特性次第で選ぶ）
- これがトレードオフ思考だ！！！！
- トピック方式（Pub/Sub）
- アーキテクトはコードを書くべきか
- 全てのアーキテクトは：コードを書ける、一定の技術的深さを
- ただし注意点：クリティカルパスを握るとチームの足を引っ張る
- 回避策：フレームワークや中核部分はチームに任せる
- 現場感を失わないための実践
- PoC（概念実証）をプロダクション品質で書く
- 技術的負債やアーキテクチャ関連ストーリーを引き受ける
- 繰り返し作業を見つけて自動化する
- 適応度関数でアーキテクチャ統制を自動化
- 頻繁なコードレビューで：
- 準拠確認
- メンタリング
- コーチング
アーキテクトは「選択肢と犠牲を理解（トレードオフ）し、チームと一緒に決断できる人」
優秀なエンジニアと優秀なアーキテクトは別物です。
モジュール性・メトリクス・結合の本質
- モジュール性は万能ではない
- ソフトウェアは複雑系であり、モジュールの定義は一貫しておらず、矛盾も多い。
- 意図的に秩序と一貫性を与え続けることが不可欠。
- モジュールとは何か
- モジュールとは：関連する振る舞いやコードを、論理的にまとめた単位
- モジュール性は「測れる」
- メトリクスで評価できる。
- 主な指標
- 凝集度（LCOM）
- 結合度
- 抽象度
- 不安定度
- 循環的複雑度
- 結論：「場合による」
- メトリクスは判断材料であって、正解を出すものではない。
- コナーセンス：結合の「質」を見る視点
- コナーセンスとは：ある変更が、別の要素の変更を強制する関係
- 単なる「結合の有無」ではなく、 どのように結合しているかを見る概念
- 静的コナーセンス
- 動的コナーセンス
- 良いモジュール性を作るためのルール
- モジュール境界を明確にする
- 境界をまたぐコナーセンスは最小化
- 境界内ではコナーセンスを許容・最大化
- 距離が遠いほど、より弱いコナーセンスを使う
- 強いコナーセンスは、可能な限り弱い形へ変換する
一見美しい設計ほど、隠れた欠点を持つ。
「結合をゼロにする」のではなく 「結合を正しい場所に閉じ込める」ことを目指す。
アーキテクチャ特性（非機能要件）の本質
- アーキテクチャ特性とは何か
- アーキテクチャ特性とは、問題領域（業務ロジック）とは独立した、 システムの成功を左右する重要な性質
- 非機能要件・品質特性とも呼ばれる。
- 暗黙的特性と明示的特性
- アーキテクトの仕事は、 暗黙的特性を言語化/可視化すること
- 暗黙的特性
- 要件書にほとんど書かれない
- 例：可用性・信頼性・セキュリティ
- しかし失敗すると即プロジェクトが死ぬ
- 明示的特性
- 要件文書に明確に現れる
- 特性はトレードオフの三角形
- アーキテクチャ特性は互いに影響し合う
- セキュリティ
- パフォーマンス
- 可用性
- 複雑性
- アーキテクチャ特性は互いに影響し合う
- 特性の分類
- 運用特性
- 可用性、パフォーマンス、回復性、信頼性、安全性、スケーラビリティ など
- 構造特性
- 拡張性、保守容易性、再利用性、可搬性、アップグレード容易性 など
- 横断的特性
- セキュリティ、プライバシー、認証・認可、ユーザビリティ、合法性 など
- 分類は理解を助けるためのもので絶対的ではない！！！！
- 運用特性
- 標準と現実のギャップ
- ISOなどの分類は有用だが不完全
- 同じ用語が文脈によって全く違う意味で使われる
- 「可用性」「信頼性」「互換性」などは特に誤解されやすい
- 用語よりも意図と文脈を揃えることが重要
- 特性は設計を難しくする
- 特性を考慮すればするほど、設計は複雑になる
- しかし無視すれば、必ず後で破綻する
- これはヘリコプター操縦のようなもので、常にバランスを取り続ける作業で、一度決めて終わりではない。
アーキテクチャ特性は 「何を大事にするか」を明確にするための道具で最善のアーキテクチャは存在しない。
→最善ではなく、最悪でないアーキテクチャを目指そう。
ドメイン要件からアーキテクチャ特性を導く
- 汎用アーキテクチャはアンチパターン
- どんなシステムにも当てはまる万能アーキテクチャは存在しない。
- 特性を盛り込みすぎると、設計は不必要に複雑になる。
- 「シンプルに保つ」ことは、怠慢ではなく戦略。
- 問題は「言語の違い」
- ステークホルダーとアーキテクトは、違う言葉（言語）を話している。
- 技術側：スケーラビリティ、可用性、耐障害性
- ビジネス側：市場投入までの時間、競争優位、顧客満足
- アーキテクトの役割とは、 ビジネスの関心事をアーキテクチャ特性に翻訳すること。
- ステークホルダーとアーキテクトは、違う言葉（言語）を話している。
- 明示的・暗黙的な特性を見抜く
- 明示的特性：要件に書かれているもの
- 暗黙的特性：
- 可用性
- 信頼性
- セキュリティ
- 弾力性（バースト耐性）
- 要件に書いていなくても、 失敗すると致命的な特性は必ず存在する。
- スケーラビリティと弾力性
- スケーラビリティ：同時ユーザー数を安定して処理できる能力
- 弾力性：突発的な負荷の急増に耐える能力
- 弾力性が必要な場合、 スケーラビリティも必須になる。
- 特性を選ぶ際の指針
- 不要な脆さを設計に持ち込まない
- 特性が「不要」なケースもある
- ステークホルダーと協力して決定する
- 暗黙の期待を過信しない
- 実現可能性（フィジビリティ）を必ず検証する
- 国際化・ユーザビリティも見落とさない
- 特性の盛りすぎは害になる
- 過剰な特性は、
- 設計を複雑にし
- 開発を遅らせ
- 失敗の確率を上げる
- 曖昧な仕様と同じくらい有害。
- 過剰な特性は、
- 象牙の塔アンチパターンを避ける
- 実装チーム・ステークホルダーと協力し、 現実的なトレードオフを選ぶ。
- 理想論だけの設計は、現場を壊す。
アーキテクチャ特性に「正解」はない！！！！
最高を狙うのではなく、
「失敗条件」を先に見抜きトレードオフの集合を作る。
アーキテクチャ特性を測り、統制する
- 構造特性と運用特性はトレードオフ
- 構造の関心事：モジュール性・デプロイ容易性など
- 運用の関心事：パフォーマンス・弾力性・スケーラビリティなど
- これらは同時に最大化できない。両者のバランスを取ろう！！！
- 特性定義が難しい理由
- 形が曖昧（アジリティなど）
- 定義が人によって違う（パフォーマンス）
- アジリティは「モジュール性・テスト容易性・デプロイ容易性」に分解できる
- そのため、 ユビキタス言語（共通語彙）を作ることが不可欠。
- 測れる特性・測れない特性
- パフォーマンスやスケーラビリティは比較的測りやすい。
- アーキテクトやDevOpsは パフォーマンスバジェットを設定し、上限を決める。
- 複雑さは「悪い兆候」
- 循環的複雑度は、コードの不吉な匂いを検出する指標。
- 複雑すぎるコードは、
- 理解しづらい
- 壊れやすい
- 変更に弱い
- 統制とは何か
- 統制＝アーキテクトが品質に影響を与える仕組み全体
- 進化的アーキテクチャと適応度関数
- 進化的アーキテクチャ：
- 変化を前提とする
- 壊れたら検知できる仕組みを持つ
- 適応度関数：重要なアーキテクチャ特性を、 自動で検証する仕組み
- 進化的アーキテクチャ：
- モジュール性は放置すると壊れる
- モジュール性は「意識し続けないと失われる」
- 人間の弱さを前提にする
- 「許可を求めるな、謝罪せよ」型の行動は必ず起きる
- 一度侵食を許すと、長期的に大きなダメージになる
- 安全でないコードは、他の優先度に埋もれやすい
- カオスエンジニアリングとチェックリスト
- カオスエンジニアリング：
- 壊れる前提でテストする
- 破壊を経験することで強くなる
- チェックリスト：
- 専門家でも漏れが出るという前提に立つ
- シンプルだが非常に効果的
- カオスエンジニアリング：
この章を理解してる頃には、もう設計の話をしてるふりをした運用事故に騙されなくなります。
アーキテクチャは「信頼」ではなく「検証」で守るものだ。
おすすめの本
分割と意思決定の残し方
アーキテクチャ量子という考え方
- なぜ「量子」が必要か
- コードベース外の依存（DB・他サービス・通信方式）も含めて 「どこまでが一体として動くか」を測る必要がある。
- その最小単位が アーキテクチャ量子です！！！
- アーキテクチャ量子の定義
- 高い機能的凝集性と同期的なコナーセンスを持ち、独立してデプロイ可能な単位
- DDDとの関係
- 境界づけられたコンテキストは、量子を見つける強力なヒント
- システム全体ではなく、量子ごとに特性を分析する
コンポーネント分割の考え方
- 用語整理
- モジュール：関連コードの論理的な集まり
- コンポーネント：モジュールの物理的・デプロイ可能な表現
- サービス：独立アドレス空間・ネットワーク越し通信
- 最上位分割の選択（2系統）
- 技術による分割（レイヤード）
- 利点：構造が分かりやすい、技術的関心事を分離しやすい
- 欠点：グローバル結合が高くなりがち、分散化・マイクロサービス移行が困難
- ドメインによる分割
- 利点：ビジネスに近い、職能横断チームを作りやすい、分散アーキテクチャと相性が良い
- 欠点：コード重複が起きやすい
- はい！！どちらも正解。トレードオフ次第！！！
- 技術による分割（レイヤード）
- 分割は一度で決まらない
- 初期コンポーネントは「下書き」
- 「正しい設計」を探すのではなく 「最も悪くない分割」を更新し続ける
- 分割手法の例
- アクター / アクション
- イベントストリーミング
- ワークフロー中心
- ORM中心（※エンティティの罠に注意）
アーキテクチャとは「どこまで一緒に壊れるか」を決めること
意思決定は「残さなければ存在しない」
- アンチパターンが示す教訓
- 資産防御アンチパターン
→ 決断を恐れて何も決めない - グラウンドホッグデー
→ なぜ決めたか分からず議論が無限ループ - メール駆動アーキテクチャ
→ 決定が散逸し、誰も守らない - 共通原因： 意思決定が構造化されて記録されていない
- 資産防御アンチパターン
- 何を「アーキテクチャ決定」として残すか
- 構造
- 非機能特性（イリティ）
- 依存関係（結合点）
- インターフェイス
- 構築手法に影響する選択
- ADR（アーキテクチャデシジョンレコード）
- ADRは「設計書」ではない。
- なぜその決定をしたかを未来に伝えるための記録
- 重要なポイント
- メール本文に決定を書かない
- 関係者にだけ通知する
- 1つの真実の場所に集約する
記録されていないアーキテクチャ決定は、存在しないのと同じ
優れたアーキテクチャとは、 良い設計そのものではなく、 良い判断が「なぜ行われたか」を残せる仕組みである。
「交渉力」について
「アーキテクトの決定は反発されやすい→政治力・交渉力が必須」
交渉＝“決める→記録する→守らせる”の運用の話に繋がる。
交渉力（政治力）が必要な理由
- アーキテクトの決定（制約・指針）は、チームの自由度を下げるため反発されやすい。
- だから重要なのは「正しい技術」よりも“なぜそれが必要か”を合意形成できる力。
交渉がうまいアーキテクトの振る舞い
- 指定ではなくガイド：命令で押し切るより、原則と理由を共有する（例外はトレードオフで扱う）。
- ビジネス言語に翻訳：スケーラビリティ等の横文字を「市場投入までの時間」「ユーザー満足」「コスト」に変換する。
- 合意の仕組み化：ARBの例外プロセス、ADRで決定と理由を残し、同じ議論を繰り返さない。
- 継続的に検証：決定は決めて終わりじゃなく、準拠をレビューなどで確認する。
やはりアーキテクトには「交渉力」のスキルも必要なんです。反発は起こるし、絶対的な決定をするわけではなく、納得する理由を押さえて、意思を促しガイドしよう。
読み終わった感想
お疲れ様でした。
私自身ソフトウェア開発歴が短いので、設計士（ベテラン）についての本は、あまり理解や想像ができませんでした。ご覧の通り「トレードオフ」や「場合による」という明確な正解がないことに強く関心を持っています。
設計の意思決定をする人は、ソフトウェアやアプリの数いると思うので、参考になる方も多いと思います。
アーキテクトってこんなに大変な仕事なんだなあ！！「交渉力」についてノウハウも書いてあったし、優秀なエンジニアとしても優秀なビジネスマンとしてもハイブリッドに考えなきゃいけない姿を想像すると、これまで以上に崇拝・尊敬できます。
現実、あのメルカリでさえ、綺麗な設計ができていないそうです。
完璧は不可能です。目指しても無駄です。
しかし、ビジネスやプログラマー、未来に時代を受け継ぐ人のためにも
たくさん経験して知識を蓄えて、なるべく技術的負債は抑えたいですよね。
スポンサーリンク
ABOUT ME
23歳の学生です。
趣味は小説を読むことです。たまに技術書も読みます。
