やったこと

学んだこと

ポイント

• ソフトウェアアーキテクトとは
  • どんな人？
  • 何をする人？
• アーキテクチャの基本構造3つ
• 品質特性とは

学び

• ソフトウェアアーキテクトは、広い視野を持って、技術以上のことを扱う
• 構造にもいくつか種類がある
  • 「構造の種類が異なる」ことを認識できると、様々な性質を考える際に役立つ ## メモ

1.1 ソフトウェアアーキテクトが行うこと

エンジニアリングの観点から問題を定義

ステークホルダー（プロダクトマネージャーやプロジェクトマネージャーなど）と協力し、ソフトウェアのビジネス目標と要求を定義する。

• ステークホルダーと協力し、ソフトウェアのビジネス目標と要求を定義する
• システムに対する品質特性を定義する
• アーキテクチャに影響を与える設計上の制約やフィーチャーに注視する

システムを分割し、責務を割り当てる

以下の効果を得るため、ソフトウェアシステムを、責務別に分解する。

• 品質特性をはじめとするシステム要求を満たす戦略を立てられるようになる
• より開発しやすくなる
  • 小さいものほど、設計、開発、テストなどが容易になる

広い視野を持って全体に目を向ける

システム全体について考える場合、理想と現実のバランスを見極める（≒トレードオフについて考える）必要がある。

設計判断が、ソフトウェアに関わる要素（ユーザー、開発・運用チーム、ハードウェア、開発目的）に与える影響を広くとらえ、うまくバランスを取ることが求められる。

品質特性間のトレードオフを決定する

全ての品質特性を満たすことは非現実的。
そのため、何かをあきらめる必要がある（≒トレードオフを考える）。

• 例）可用性のためにハードウェアを複数購入すると、コストをあきらめることになる
  • コストを引き換えに、可用性をとった形

こういったトレードオフを把握し、最適なトレードオフを、ステークホルダーと共に選択する。

技術的負債を管理する

技術的負債 ... 現在の設計と、継続的に価値を届けるために必要な設計とのギャップ

開発チームは、必要に応じて技術的負債を負う（リリースを早めるため、など）。
そして、定期的に負債を返済する。
定期的に負債を返済するために、アーキテクトは、技術的負債を適切に管理する。

また、アーキテクトは、技術的負債を可視化する。
これによって、ステークホルダーは、技術的負債に対してアクションの必要性を判断できる。

チームのアーキテクチャスキルを高める

アーキテクチャの専門家として、チームのアーキテクチャスキル向上に努める。

• 適切なタイミングで、
• ペア作業や共有ドキュメント作成を通して、
• 建設的な批評を行う

これにより、チームはアーキテクチャを理解できるようになり、優れたソフトウェアシステム開発に貢献する。

1.2 ソフトウェアアーキテクチャとは何か

システムのソフトウェアアーキテクチャとは

望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったもの

「品質特性を促進する」とは、それがソフトウェアシステムの中に現れるよう働きかけることを指す。

• 品質特性の一つが「コスト」であれば、「納期に間に合い、予算内で、残業に頼り過ぎない」というのが正しいアーキテクチャと思われる

基本構造を定義する

「要素」 ... ソフトウェアの基本構成単位
「関係」 ... 「要素」が役割を全うする際にどのように連携するかを示したもの
「構造」 ... 「要素」と「要素」を、「関係で繋いだもの」
![[Drawing 2023-12-17 12.20.50.excalidraw]]

要素と関係の分類には、以下の例がある。

	概要	要素の例	関係の例
モジュール	設計時に現れる構造	クラス、パッケージ、レイヤ、モジュール、構成ファイル、DBなど	～を使用する、～の使用を許可する、～に依存する
コンポーネント&コネクター (C&C)	実行時に現れる構造	オブジェクト、コネクション、スレッド、プロセス、層など	～を呼び出す、～を購読する、～をパイプする、～を戻す
割り当て （対応構造）	上記構造群の対応を示す構造	サーバー、センサーラップトップ、LB、コンテナ、チーム、人	～上で実行する、～内で実行する、～の責務を負う、～を開発する、～を格納する

異なる種類の構造を知っていると、システム内で必要となる様々な性質を考える際に役立つ。

• モジュール構造を使って、テスト容易性や保守性について考えることが出来る
• C&C構造は、可用性やパフォーマンスなどの実行時の問題を考えるのに役立つ

構造は、システムの形状を決定する。
システムの形状は、利用者が体験する部分であり、重要である。

品質特性を見通す

品質特性とは

ステークホルダーがソフトウェアシステムの良さを判断するための、外部から見える特徴。

例) 拡張容易性、可用性、保守性、テスト容易性 など（≒アーキテクチャ特性）

ステークホルダーが望む、ソフトウェアシステムが満たすべき品質特性を、設計に組み込んでいくことになる。
そこには、当然トレードオフが存在する。

1.3 チームのアーキテクトになる

アーキテクトは、チームの役割や名刺上の肩書ではなく、心の持ち方。
ソフトウェアシステムの構造に影響を与える決定を行う人であれば、誰しもアーキテクト代行である。

プログラマーからソフトウェアアーキテクトへの道

アーキテクトは、様々な開発経験を通じて、技術的責任の範囲を広げる。
アーキテクチャに対する責任が増えると、徐々にコードに触れる機会が減少する。
しかし、決して「コードを書かない」状態になってはならない。

今まで携わってきたプロジェクトに対して、以下の問いに答え、振り返る機会を設ける。

• ステークホルダーは誰だったか、主要なビジネス目標は何だったか
• ビジネス目標を満たすために取られた全体のソリューションはどのようなものだったか
• どんな技術に取り組んだか
• 最大のリスクは何だったか、それらをどのように克服したか
• 今もう一度やり直すとしたら、どのようにするか

振り返り、学びをまとめよう。

1.4 素晴らしいソフトウェアを作り上げる

ソフトウェアアーキテクチャの手助け

1. 大きな問題をより小さく、より管理しやすい問題へと変える
2. 人々の協働のやり方を示す
   • 上手なコミュニケーション方法の提案
3. 複雑な問題について会話するための語彙を提供する
   • 話していることを互いに理解するために、基本思想や語彙を提供する
4. フィーチャーや機能以外のモノ（特に品質特性）にも目を向ける
5. コストのかかる間違いを避けるのに役立つ
   • 後々大きな問題を引き起こす可能性のある、難しい部分を発見する
6. 変化への柔軟な対応を可能にする