ソフトウェアアーキテクチャの基本と進め方# 「アーキテクトの教科書 価値を生むソフトウェアのアーキテクト構築」書評 第1回
皆さんは「アーキテクチャ」という言葉を聞いて、何を思い浮かべますか？建築でしょうか？それとも何か壮大なシステム設計？
実は私も数年前まで、「アーキテクチャって要するに設計図のことでしょ？」と思っていました。しかし、実際のプロジェクトでアーキテクチャの重要性に直面した時、その認識がいかに浅はかだったかを痛感したのです。
今回から3回にわたり、素晴らしい一冊「アーキテクトの教科書 価値を生むソフトウェアのアーキテクト構築」の内容を基に、ソフトウェアアーキテクチャについて解説していきます。単なる書評ではなく、本書から得た知識と自身の経験を融合させた実践的な内容をお届けします。
1. アーキテクチャとは何か
アーキテクチャとは、「ユーザーに価値を提供するために決めるべき特性」のことです。言い換えれば、システム全体の骨組みであり、各コンポーネントがどのように連携して機能するかを定義するものです。
昔ながらの一軒家を想像してみてください。基礎、柱、梁、屋根といった構造が家の「アーキテクチャ」です。これらが揃っていないと、どんなに美しい内装も意味がありません。ソフトウェアでも同じで、堅牢なアーキテクチャがなければ、どんなに優れた機能も、長期的には価値を発揮できないのです。
なぜアーキテクチャが重要なのか？現代のシステム開発では、クラウドの普及により処理の複雑性が増し、長期的な運用保守を見据えた設計が不可欠になっています。適切なアーキテクチャなしでは、システムは拡張性や保守性に欠け、やがて「レガシーシステム」の呪いにかかることになります。
2. アーキテクチャ設計の3ステップ
アーキテクチャ設計は、以下の3つのステップで進めます：
- アーキテクチャドライバの特定
- アーキテクチャの選定
- アーキテクチャの文書化
これらを順に見ていきましょう。
2.1 アーキテクチャドライバの特定
アーキテクチャドライバとは、アーキテクチャを検討する上で重要な考慮事項のことです。まるでドライバー（運転手）がクルマの進む方向を決めるように、これらの要素がアーキテクチャの方向性を決定します。
主なアーキテクチャドライバには以下のものがあります：
A. 制約（Constraints）
制約とは、システム開発やデリバリーに対して課される所与の条件です。これらは通常、交渉の余地がない前提条件となります。
ビジネス上の制約の例：
- 内的環境：プロジェクトの予算、スケジュール、稼働後の保守運用コスト
- 外的環境：法令対応のための特定時期までのリリース、業界標準対応期限
あるプロジェクトでは、「9月に部長の役員報告があるため、8月末までにリリースを間に合わせる」という制約がありました。この一見シンプルな制約が、アーキテクチャの複雑性を大きく制限することになったのです。
技術的な制約の例：
- 使用するプログラミング言語、ライブラリ、フレームワーク
- インフラ環境（クラウドプロバイダーの指定など）
「バックエンドはPythonとNext.jsを使用する」という制約は、開発チームが複数企業にまたがり、それぞれが異なるスキルセットを持っていたためでした。
制約を表形式でまとめると、このようになります：
| タイプ | 制約 | 背景 |
|---|---|---|
| ビジネス(内的環境) | 8月末までにリリース | 9月に部長の役員報告があるため |
| ビジネス(外的環境) | 8月末までにリリース | 競合の生成AIアプリ導入が9月末に決定 |
| 技術 | バックエンドはPythonとNext.jsを使用 | 開発担当者が複数会社に渡っており、その中で保有するスキルが違うため |
B. 品質特性（Quality Attributes）
品質特性は、システムが満たすべき非機能要件です。多くの品質特性がありますが、特に以下の3つを優先的に考慮するとよいでしょう：
- 可用性（信頼性）：システムがどれだけ安定して利用できるか
- 性能：応答時間やスループットなど
- セキュリティ：不正アクセスや情報漏洩からの保護
これらに加えて、以下の要素も重要です：
- 保守性（システムの追加開発のしやすさ）
- 移植性（環境変更への対応力）
- 法規制と業界基準の遵守
- 分散システムにおけるリアルタイム性
- 環境要件（動作環境の制約）
品質特性は、具体的に測定可能な形で定義することが重要です。例えば、「システムは高速であること」ではなく、「検索機能は95%のケースで2秒以内に結果を返すこと」といった具体的な指標を設定します。
これらの品質特性は、品質特性シナリオとして文書化します：
| 要素 | 要素の説明 | シナリオ例 |
|---|---|---|
| 刺激 | システムに応答を要求するイベント | 2つの同時APIリクエスト |
| 発生源 | 刺激を引き起こすエンティティ | ユーザー |
| 成果物 | 刺激を与える対象システム | GPTからのAPIリクエスト結果 |
| 応答 | 刺激の結果として起こる振る舞い | UI画面にリクエスト結果が返される |
| 応答測定 | 目標達成の測定基準 | リクエスト時にレスポンスタイムも同時に出力 |
| 環境 | システムの周囲の条件 | 同デプロイされたGPTモデルをローカル環境上で使用 |
シナリオは、「もし〜が起きたら、システムは〜すべきである」という形で記述します。これにより、抽象的な品質要件を具体的な検証可能な要件に落とし込むことができます。
C. 影響を与える機能要求
通常、機能要件はアーキテクチャよりも詳細なレベルで検討されますが、一部の機能要件はアーキテクチャにまで影響を及ぼすことがあります。
例：
| 機能要求番号 | 詳細項目 | 検討ポイント |
|---|---|---|
| REQ-12 | アプリA起動時もBへ遷移が可能 | 状態管理を行うことが可能なようにアプリ統合の際は考慮する |
このような機能要件は、初期のアーキテクチャ設計段階から考慮することが重要です。後から追加すると、大規模な設計変更が必要になる可能性があります。
D. その他影響を及ぼすもの
開発チームのスキル、知識、過去の経験なども、アーキテクチャ選定に大きな影響を与えます。
例えば、マイクロサービスアーキテクチャは技術的に優れていても、チームがその経験を持っていなければ、導入の際のリスクが高まります。チーム構成や組織文化も重要な考慮要素です。
2.2 アーキテクチャの選定
アーキテクチャドライバを特定したら、次に適切なアーキテクチャを選定します。基本的なアーキテクチャパターンには次のようなものがあります：
- モノリシックアーキテクチャ：全体を一つのデプロイとして構成
-
分散アーキテクチャ：
- サービスベースアーキテクチャ：DB共有型の分散サービス
- マイクロサービスアーキテクチャ：DBも含めて完全に独立したサービス
選定にあたっては、アーキテクチャ比較マトリクスを使用すると効果的です：
| 評価項目 | 粗粒度のサービス分割 | 細粒度のサービス分割 |
|---|---|---|
| 時間効率性 | △現時点で想定されるトラザクション量では問題ないが将来大幅に増加した場合、サービス全体のスケールアップが必要 | ○申請・承認と一覧検索を分割することで、必要に応じて個別にスケーリングが可能 |
| 解析性・ログ | ○問題なし | △サービスが分かれることによるログのトレースは難しくなり、なんらかの対応が必要 |
| 解析性・性能 | △スローレスポンスやスループット低下などの問題発生時の原因の切り分けが難しい | ○性能問題が発生しているサービスの特定が容易 |
| 開発チームのスキル | ○問題なし | △マイクロサービス経験が少ないためリスクがある |
| 開発工数 | ○問題なし | △サービス間のデータ連携などの開発内容が増える。見積もりがブレるリスクもある |
技術的な確信が持てない場合は、アーキテクチャプロトタイピング を行って検証することも有効です。ただし、プロトタイピングのコードを本番に持ち込まないように注意しましょう。
選定した結果は、**アーキテクチャデシジョンレコード（ADR）**として文書化します。ADRの例：
タイトル: ADR-001 経費精算サブシステムのサービス分割検討
背景:
システムの論理分割結果、経費生産サブシステムが一つのサブシステムとなった。
申請・承認、一覧検索、マスタ管理をマイクロサービスとして独立させるべきか、
一つの粗粒度のサービスとしてまとめるべきか方針決めが必要である。
決定内容:
経費生産サブシステムは一つの粗粒度のサービスとする。
スケーラビリティにおいてマイクロサービス化のメリットはあるが、
チームの開発スキルと開発工数の面から納期に対するスケジュールリスクが大きいため。
ステータス:
承認済み
備考:
将来的なマイクロサービス分割を想定し、移行しやすいアプリケーションアーキテクチャは
検討しておく。
2.3 アーキテクチャの文書化
最後に、選定したアーキテクチャを文書化します。アーキテクチャ文書には以下の要素を含めます：
- 目的：アーキテクチャの目的と背景（ADRと類似）
- アーキテクチャドライバ：明文化による認識齟齬の防止
- システム全体構成：システムの概要図
-
アクターとステークホルダー：
- アクター：システム利用者と重要な観点（例：品質における回答品質90%以上）
- ステークホルダー：関心事項と影響力
- アーキテクチャモデル：「4+1ビュー」などを活用
特に「4+1ビュー」は、システムを異なる視点から表現する効果的な手法です：
- 論理ビュー：システムの構造（クラス図、レイヤー図）
- 開発ビュー：モジュール構成（パッケージ図）
- プロセスビュー：実行時の振る舞い（シーケンス図）
- 物理ビュー：デプロイメント構成（ネットワーク図）
- +1: ユースケースビュー：システムの利用シナリオ
これらの異なるビューにより、それぞれのステークホルダーの関心に応じた表現が可能になります。
3. まとめと次のステップ
アーキテクチャは、単なる技術的な設計図ではありません。ビジネス要件、技術的制約、品質特性などを総合的に考慮した、システム全体の骨格です。適切なアーキテクチャは、システムの長期的な成功の基盤となります。
本記事では、アーキテクチャドライバの特定、アーキテクチャの選定、文書化という3つのステップを紹介しました。次回は、アーキテクチャ基盤の構築と開発プロセスの標準化について掘り下げる予定です。
「アーキテクチャは小規模プロジェクトでは必要ない」と思われるかもしれませんが、小さく始めて大きく育てるプロジェクトこそ、初期段階からの適切なアーキテクチャ設計が重要です。アーキテクチャの負債は、時間が経つほど返済が困難になります。
皆さんのプロジェクトで、アーキテクチャについてどのような取り組みをされているでしょうか？コメント欄でぜひ共有してください。
次回は「アーキテクチャ基盤の構築と開発プロセスの標準化」について解説します。お楽しみに！
こちら本を購入したいという方はこちらに画像リンクを貼っています👇
最後に
私は2つのプラットフォームで生成AIに関する発信を行なっております。
生成AIサービスの考察を見たい方へ
生成AIサービスの動向やや具体的な内容は、noteで詳しく解説しています。
noteプロフィール: @mizupee
日々の生成AI分析を追いたい方へ
毎日1つの生成AIサービスを分析するTwitter投稿「#100DaysofAI」もぜひフォローください。簡潔なポイント分析とアイデア共有を継続中です。
Twitter: @mizupee
Discussion