やったこと

• Design It! 5章 アーキテクチャ上重要な要求を掘り下げる 読了

学んだこと

ポイント

• アーキテクチャに影響を与える要求とは
• アーキテクチャの制約をうまく利用する
• 品質特性シナリオとは
• ASRワークブックとは

学び

• アーキテクチャに多大な影響を与える要求に注視し、これを発見するために手を尽くす
• 適切に選択された制約は、問題を単純化し、アーキテクチャ設計を容易にする
  • 一方で、非常に厳しい制約は、アーキテクチャ設計を必要以上に複雑化する
• 設計判断（特に開発初期）は、後々制約と化す
  • しかし、制約と化した設計判断は変更できる
  • 与えられた制約か、制約と化した設計判断なのか、区別できるようにする
• 品質特性の説明するために、品質特性シナリオを書く
  • テスト可能で、測定可能であると良い
• 特定した「アーキテクチャに多大な影響を与える要求」は、ASRワークブックとして文書に記録する ## 所感

要求の内、アーキテクチャに大きな影響を与えるものに注視するのは、非常に納得感のある話だった。
アーキテクチャを判断する際、優先的に考慮するべき事項として、貴重な情報元になりそう。

与えられた制約か、制約と化した設計判断なのか区別するというのは、あまり考えたことが無かった。
制約とかした設計判断を、勝手に「変えられないもの」と思い込み、「変更する」という選択肢が見えなくなってしまう状態は非常に怖い。
そうならないためにも、与えられた制約か、制約と化した設計判断なのか区別することは重要だと考えるようになった。

初期の設計判断が、後々に制約と化す様はイメージしやすかった。

制約を活用することで選択肢を絞る話、バックログを作成する際にスコープを絞る話に似ていると感じた。

メモ

ステークホルダーの要求の内、アーキテクチャに多大な影響を与える要求を アーキテクチャ上重要な要求、（ASR） と呼称する。
アーキテクトは、ASRを明らかにする責務を負う。

• ステークホルダーも気付いていない、隠れたASRは無いか
• ステークホルダーの要求の内、ASRに該当するのか

ASRだと判定するには、以下の要求分類について考える。

1. 制約
   • 変更できない設計判断
   • 通常は与えられるものだが、選択することもある
2. 品質特性
3. 影響を与える機能
   • アーキテクチャにおいて特別な注意を必要とするフィーチャーや機能
4. その他、影響を及ぼすもの
   • 例） 時間、知識、経験、スキル、社内政治など

制約を活用して設計の選択肢を絞る

ここで言う制約とは、 変更できない設計判断を指す。

適切に選択された制約は、問題を単純化し、アーキテクチャ設計を容易にする。

一方で、非常に厳しい制約は、アーキテクチャ設計を必要以上に複雑化する。

制約によって、人、プロセス、予算、スケジュールに関する判断を制限する。

制約の例）

• 技術的な制約
  • プログラミング言語の選択(JVM上で動くか、など)
  • OS・プラットフォーム（特定のOSで動くか）
• ビジネス上の制約
  • チーム編成
  • 予算・スケジュール
  • 法的制約

制約について、決定事項とその発生源を簡潔にまとめておく。

まとめた制約の例）

制約	発生源	タイプ	コンテキスト
OSSとして開発しなければならない。	市長	ビジネス	市はオープンデータポリシーを持ち、市民はソースコードにアクセスできなければならない。
...	...	...	...

制約は一度決定すると、 100%交渉不可能となる。
そのため、受け入れる制約は慎重に決定する。

ソフトウェア開発が進むにつれて、設計判断は（変更が困難という意味で）制約のようになる。

• 特に、開発初期の設計判断は、開発終盤で大きな制約となる可能性がある

ステークホルダーから与えられた制約とは異なり、設計判断は（困難を伴うかもしれないが）変更することはできる。
そのため、「与えられた制約」なのか、「制約と化した設計判断」なのかは区別するようにする。

品質特性を定義する

品質特性とは、ソフトウェアシステムの外部から見える特性とそのシステムの運用に対する期待を表す。
つまり、アーキテクチャ特性。

ASRを考える際、品質特性は常について回る。

品質特性は、システム運用の文脈においては非機能要件と同義と言える。
一方で、品質要求の文脈においては、品質特性は機能的な意味合いもあるため、非機能要件とは呼べない。

また、ソフトウェアアーキテクチャ設計の際は、機能、制約、品質特性を区別した方がよい。

品質特性シナリオとして記録する

品質特性を明確に説明するために、品質特性シナリオを使用する。

品質特性シナリオは、ソフトウェアシステムが特定の環境のコンテキスト内でどのように動作するかを説明したもの。

◆品質特性シナリオの例

品質特性	シナリオ	優先度
可用性	RFPDBが応答しない場合、システムは障害を記録し、3秒以内に古いデータで応答する必要がある	高
可用性	ユーザーは、RFP検索機能を、年間を通して平均99%の確率で行うことが出来る	高
信頼性	RFPの更新は、変更後24時間以内にアプリケーションに反映される	低
...	...	...

良い品質特性シナリオは、以下を満たす。

• 誤解の余地なく、誰でも理解できる文で要求の意図を伝えることが出来る
• 正確
• 測定可能

具体的かつ測定可能な応答測定とするように努める

ステークホルダーと会話を始める前に、応答測定のたたき台を用意する。
たたき台をもとに、ステークホルダーと議論を重ね、ステークホルダーの共感を呼ぶ応答測定を発見する。

よい応答測定は、テストしやすい。
言い換えると、シナリオを使ったテストを作成できないのであれば、そのシナリオは特定の計測可能な応答測定を持っておらず、詳細化が不十分だと言える。

機能要求の分類を探す

アーキテクチャ設計に影響を与える機能要求を、影響力のある機能要求と呼ぶ。
影響力のある機能要求を発見するのはセンスを伴う。

書籍では、以下の手順を紹介している。

1. アーキテクチャについての現在の考えを要約した概念的なアーキテクチャをスケッチする
2. 大量の機能要求リストから、同じものをグループ化し、代表的な機能要求のみ抽出する
   • 同じアーキテクチャ要素内に実装されている可能性のある機能要求を探す
   • 実装が難しそうな機能要求を探す
   • 価値が高く、優先度の高い機能要求を探す
3. 特定した問題の種類ごとに、概念的なアーキテクチャを辿りながらそれぞれの要求グループをどう達成背売るか示す
   • 実装方法がすぐに示せない場合、ASRである可能性がある

それ以外のアーキテクチャに影響するものを見つけ出す

例

• 知見のある技術
  • RoRしか経験が無ければ、他のフレームワークの採用は見送られやすい => 設計判断
• コスト（金）
  • システムにかける予算が十分になく、貧弱なマシンしか使えないのであれば、それに合った機能や言語・フレームワークを使用せざるを得ない

など

必要な情報を掘り下げる

ASRは、プロダクトバックログから発見しやすい。
ユーザーストーリーから、品質特性シナリオを作成し、詳細を明らかにしていく。
そのためにも、ステークホルダーと話をする。

ASRの発見に役立つ手法の例

• GQMワークショップ
• ステークホルダーインタビュー
• 前提リスト
• ミニ品質特性ワークショップ
• インセプションデッキ

ステークホルダーの目標を理解するためにも、積極的傾聴能力を磨く

ASRワークブックを組み立てる

特定したASRは、 ASRワークブックとして文書に記録する。
開発初期は頻繁に更新される。
アーキテクチャがまとまっていくと、更新頻度が減る。代わりに、参照頻度が高くなり、重要な文書に昇華する。

• まれに、実行可能なテストやソースコードが、ASRワークブックにとって代わる