Design It! 輪読会 5章 「アーキテクチャ上重要な要求を掘り下げる」
5章はアーキテクチャを検討していく上で大切な要求を定義する方法が述べられていた。
この章で伝えたいことを整理する
アーキテクチャを考える上重要な要求を（Architecturally Significant Requirement : ASR）と呼びます。 これはアーキテクチャを選択する上で強く影響する影響のことだ。 ASRを明確にしていくはアーキテクトの責任であり、明確していく過程で4つの分類に分けて考える必要がある。 その4つとは「制約」「品質特性」「影響を与える機能要求」「その他の影響を及ぼすもの」であると述べられていた。
制約は変更ができない設計判断のことを言う。 そしてこの制約はほぼすべてのソフトウェアシステムが持っている。 制約には良い面と悪い面があり、良い面は課題を単純化しアーキテクチャ設計を簡単にしてくれる面がありますが、悪い面は制約が厳しくなることでアーキテクトにとって選択肢が減ることだ。 制約は一度決めると変更ができないものなので、慎重になり出来る限り時間を掛けて決めたいと感じた。
次に品質特性だが、これはシステムが外部から見える特性と、システムの運用に対する期待が反映されるものだと書いてあった。 最後に書いてあった一文が刺さったので引用する。
様々なアーキテクチャで同じ機能セットを実装することは可能だ。昨日だけでは、ソフトウェアシステムを設計するのに十分な情報とはいえない。アーキテクチャに関する意思決定を左右するのは、アーキテクチャ上重要な要求（ASR）特に品質特性だ。 ここまで読んで品質特性について自分の中で少し腹落ちすることが出来た。 システムを利用する際のユースケースを組み立て、そのユースケースの中でシステムに負荷がかかる部分などを特定することのように感じた。 他にも「品質特性は非機能要求のことか」というコラムを読むことでも理解が深まった。
次に機能要求についてだが、これはシステムの振る舞いを定義するもので、「なにをして」「どうなっていなければいけないのか」を定義するものだと感じた。 いくつか振る舞いを定義していく中で、アーキテクチャの同じ要素に分類されるものをまとめたり、分類が難しければより詳細な機能要求に分解をおこなったりもする。 また、実装が難しそうなものを特定したり、優先順位付けなどもアーキテクトの仕事とされていた。
「制約」「品質特性」「機能要求」以外のものに目を向けることも重要であると書いてあった。 それはいま世の中に出ている技術のトレンドだったり、チームメンバーが出来る技術領域であったりと言ったことだ。 またコンウェイの法則によってチームとアーキテクチャは関係づけられてしまうので、いいソフトウェアを設計したいときにはチームの編成から考える必要があることも述べられていた。 コンウェイの法則は次に引用する。
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
