12章は「アーキテクチャに通知表をつける」で、今まで作り上げてきたアーキテクチャを評価し、また評価する文化を育むことを教えてくれる章でした。
この章で伝えたいことを整理する
当たり前ですが、章のタイトルでもある通知表は学生が学期末に渡される成績のことです。 学校における通知表は、生徒を始め保護者にとって重要なフィードバックとなっています。 このフィードバックをもとに、その学年・学期ごとの勉強が順調かを見極め、少し遅れている箇所に対策などを行うことができます。 このような考え方をアーキテクチャの評価にも取り入れようという趣旨の話から始まりました。
アーキテクチャ評価は、アーキテクチャが目的を満たしている程度について確認するプロセスです。 筆者は、一般的に設計段階の最後の段階に1回だけアーキテクチャ評価をすることは間違っていると警鐘を鳴らしています。 そもそもアーキテクチャが大きくなればなるほど、アーキテクチャを1回に見きれなくなると同時に評価をすることもできません。
アーキテクチャ評価の中で学ぶ必要があることは、「アーキテクチャはどの程度いいか」「アーキテクチャはどのようにいいか」です。 この2つの質問に答えるため、アーキテクチャ上重要な要求(ASR)についてわかっていることを使っていきます。 アーキテクチャ上重要な要求(ASR)を満たしていればいるほど、アーキテクチャとしての目的も満たしていると言えるからです。
まずは設計をテストするために、評価するものを作らなければなりません。 本の中で繰り返し使われているタンジブルにする必要があるということです。 評価する物自体は、コードであったりホワイトボードスケッチでもなんでも良いようです。 前章の内容からの内容を引っ張ってくると、共有と変更が難しい形での評価物は後のことを考えると辛いと思いました。
次に、デザインルーブリックを定義する手順がおこなわれます。 デザインルーブリックは、アーキテクチャの適合性を判断するときにレビューアが採用する基準を定義するものです。 ルーブリックは「観点」と「尺度」から構成され、観点は設計成果物を評価するために使用する特性を定め、尺度は特性を評価する段階を定めます。 ルーブリックは表の形を取ることが多いです。
他にも評価するためのワークショップを開こうと行った内容もありました。 この辺りは実施するときに参考とすればいいので、頭の中にインデックスを張る程度に留めました。
アーキテクチャ評価を継続的に行っていくためのtipsも書かれていました。 例えば評価ピラミッドを使うですが、すぐにチェックできる部分はスコープが狭いので頻繁におこない、逆に深い評価はスコープも広いのでASRと見比べてじっくりとおこなうといったバランスを取るような考え方です。 アーキテクチャ評価と言われると非常に重苦しい思いを持ちますが、このように書かれると小さなところからでもおこなって良いんだという風に好感が持てます。 他にも、アーキテクチャ評価という場を仰々しく始めるのではなく、手軽なホワイトボードジャムの最後に「どこか問題はありそうかな？」と問題定義をすることでチームとして評価する雰囲気をさり気なく初め、習慣づける方法も書かれていました。
