やったこと

• Design It! 12章 アーキテクチャに通知表をつける 読了

学んだこと

ポイント

• アーキテクチャ評価とは
• 良いアーキテクチャ評価の特徴
• 評価ワークショップの目的

学び

• アーキテクチャ評価とは、アーキテクチャがどの程度目的を達成しているのか知るプロセス
• 良いアーキテクチャ評価
  • 頻繁に評価を行い、フィードバックサイクルを回す
    • 評価の観点
      • アーキテクチャはどの程度良いか？
      • アーキテクチャはどのように良いか？
    • 評価と価値のバランスを取る
      • イメージは、テストピラミッド
      • たくさんの軽い評価と、少数の重い評価でバランスを取る
  • 様々な課題を探る
    • いくつかある観点から、アーキテクチャにおける課題を探り、既知の未知をふやす
    • 同じ観点の問題ばかり探るのは、よくある失敗
• 評価ワークショップを開き、評価に必要なデータを収集して分析し、改善に役立てる

メモ

アーキテクチャを評価・改善することによって、後続のプログラミングは、更に効率的なものになる。
評価から得たフィードバックは、学び、設計判断への肯定的な意思の作成、リスク軽減、アーキテクチャの改善など、様々なことに活用できるはずだ。

評価し、そこから学ぶ

アーキテクチャの評価は、アーキテクチャが目的を満たしている程度について学ぶプロセス。

アーキテクチャの評価は何回か行うことになる。

• 少なくとも、「最後に一度だけ実施すればよい」という考えは間違っている
  • アーキテクチャ全体を一度に評価するのは非常に困難
  • アーキテクチャが誤っていれば、振出しに戻る

評価で得るべき学びの観点は、以下の二つ。

• アーキテクチャはどの程度良いか？
• アーキテクチャはどのように良いか？

アーキテクチャが、「アーキテクチャ上重要な要求」を十分に満たしているほど、アーキテクチャは目的を満たしているといえる。

設計をテストする

アーキテクチャを 早くにテストし、早く失敗し、早くフィードバックを得よう。
このサイクルを素早く回そう。

アーキテクチャの評価に必要なものは、以下の3つ。

• 視認できる成果物
• ステークホルダーの視点から見た「よりよい」または「悪い」を定義したルーブリック
• レビュー計画

◆ルーブリック
学習の達成度を示す評価基準を、観点と尺度からなる表として示したもの

評価できるものを作る

実物が無ければ、評価は非常に難しい。
ホワイトボード上のスケッチでも、アーキテクチャ記述でも構わないので、視認できる成果物を作成する。

欲しいフィードバックに合わせて、評価の準備を行う。

• 例）特定の品質特性の評価が欲しいなら、品質特性に関連するレビューの準備を行う ... など

デザインルーブリックを定義する

デザインルーブリックとは、アーキテクチャの適合性を判断する時にレビュアーが採用する基準を定義するもの。

ルーブリックは、「観点」と「尺度」から成る。

観点に品質特性シナリオを例としたルーブリックを示す。

評価尺度 ... 観点の評価方法を定義
1 : 期待に応えられない、または評価できない
...
4 : シナリオを満足させる

ルーブリックを作成する際のポイントを示す。

• 観点は、アーキテクチャ上重要な要求に基づいて選択する
  • 以下を満たす、優れたルーブリックとなり得る
    • 重要かつ不可欠
    • 観点が重複しない
    • 観察可能かつ測定可能
    • 明確
• 観点の評価尺度を決定する
  • 上記例では 1 ... 4 の4段階だが、2段階など、必要に応じて変更できる
  • 5段階以上は、使用を控えること
    • 評価者によって尺度のブレが生じ始めるため

レビュアーが評価した際、「何を考えてその評価を下したのか」という情報は非常に貴重。
これを得るために、インサイトを生成する。

インサイトを生成する

インサイトとは、「設計がアーキテクチャ上重要な要求を満たしているか」をレビュアーが意見するために使用するもの。

• インサイトは、アンケートや探求、リスクの導出やコードの分析など、様々な方法で生成できる

レビュアーがインサイトを文字や言葉にするのを助け、評価を下した理由を明確化する。

ルーブリックで答えなくてはならない情報は何か？を把握すると、どういったインサイトが効果的か見えてくる。

評価ワークショップを開く

アーキテクチャ評価ワークショップの目標は、アーキテクチャを評価するのに必要なデータを集めて分析する事。

望ましい品質特性やその他アーキテクチャ上重要な要求をどれだけ満たしているか確認する。

大体、以下の流れ。

1. 準備する
   • ルーブリックの定義、レビュアーの招待、評価で使用する成果物の検索または作成など
   • レビュアーには、アーキテクチャで使用する技術に明るい人物が良い
2. レビュアーに前もって伝える -　評価の目的、システムのコンテキスト、成果物、ルーブリックなど、評価に必要な背景情報を前もって伝える
3. 評価する
4. 分析する
   • リスクと未解決の問題を探し、アーキテクチャがどのように良いか判断する
5. 事後点検する
   • ワークショップで得た学びから、次のアクションアイテムを決定する
   • 見解の要約とアクションアイテムを、すべての参加者に共有する

早くから評価をはじめ、頻繁に継続的に評価する

早い段階で評価するほど、早く改善できる。
可能であれば、アーキテクチャ評価を開発ルーチンに組み込もう。

評価ピラミッドを使ってコストと価値のバランスを取る

評価ピラミッドのイメージは、テストピラミッド。

• 大部分は、低コストで素早くチェックできる評価
  • 個別の設計判断
• 少数の、徹底的で高コストな評価
  • システム全体と、いくつかのアーキテクチャ上重要な要求の相互作用
• 上記二つの評価の間に一貫性を持たせる、対象を絞った評価
  • 一つの判断、コンポーネント、アーキテクチャ上重要な要求

様々な課題を探る

アーキテクチャにおける課題を探る観点を示す。

• リスク
  • 発生する可能性があるものの、まだ発生していない良くないこと
• 未知のこと
  • 未解決の問題から得られる、わかっていないこと
  • 既知の未知と、未知の未知は全然違う
• 問題
  • 顕在化してしまった、良くないこと
• 理解のずれ
  • ステークホルダーの考えと設計のずれ
  • 進化するアーキテクチャに対して、理解が遅れている
  • など
• アーキテクチャの浸食
  • 設計されたアーキテクチャと実装されたアーキテクチャの差
• 状況の横滑り
  • 新事実の発覚や状況の変化によって、ビジネスの推進要員や判断を左右するコンテキストが変化すること

常に同じ種類の問題を探そうとしてはならない。
様々な課題を探ることで、既知の未知を増やすことが出来る。