少し間が空いた。
まず最初は、名前付けの話として、Arlo Belsheeの記事であるNaming as a Processに言及している。（書籍の中ではこの記事の前身の記事で、Good Namign Is a Process, Not a Single Stepという記事だったみたい）
Deep Roots - Naming as a Process (Article 1) https://www.digdeeproots.com/articles/naming-as-a-process/
私たちが選ぶ名前は、設計しているものをどれほどよく理解しているかを反映している。理解が深まるにつれ、概念に付ける名前も変わる。Belsheeの「名前付けの7段階」をソフトウェアアーキテクチャに適用したものを次に示す。
ステージ1：名無し - 名前がない状態。システムやコンテキストについて、名前付き要素を抽出するのに十分なだけのことが分かっていない。
ステージ2：無意味 - 名前に意味はないものの、何らかの形で関連していると考えられるアイデアの集まりを特定した状態。
ステージ3：的確 - 要素の責務について少なくとも1つを表している状態。
ステージ4：的確かつ完全 - 要素のすべての責務を直接表している状態。
ステージ5：適切な行い - 要素の責務を進化させるという意識的な決定が名前に反映されている状態。これは、アーキテクチャの文脈における要素の役割について、より多くの知識が得られたときにのみ起こる。
ステージ6：意図 - 名前には要素の責務だけではなく目的も表されている。目的を理解するには、その要素に加えて、その要素の存在理由を理解する必要がある。
ステージ7：ドメイン抽象 - 名前は個々の要素を超えて新しい抽象概念を作成する。これがメタモデルのための新しい概念が生まれるところだ。
良い名前をつけることは重要だというのは一定の経験のあるシステムエンジニアの中では自明だと思っているけれど、それをステージ別に整理しているのがわかりやすいと思った。
それから、これは自分が会社の研修で習ったことのある話と全く同じだった。
プログラミングデザインパターンとアーキテクチャデザインパターンを区別することはそれほど重要ではない。結局のところ、ある人のアーキテクチャは別の人の詳細な設計かもしれないからだ。
なにがアーキテクチャーかは何をデザインしたいかによって変わる、という話を経験豊富な同僚としたこともある。
記憶が正しければ、要求-アーキテクチャー-デザインという関係性が成立するという話だったと思う。
アーキテクチャーの上方向には要求が、下方向にはデザインが。そしてデザインする対象がより詳細なものにシフトした場合、そのデザインのアーキテクチャーはさっきまでデザインとして扱っていたものになる、とかそういう話。
だから、よくある議論である「これはアーキテクチャか？それともデザインか？」というのは、やっぱりそれほど重要な議論のトピックではないんだろうなあ。
アーキテクチャーをドキュメントにするという点で、名の知れたテンプレートとして次のものが紹介されていた。
あなたの組織にも、何らかのテンプレートがあるかもしれない。私が強くお勧めするのはSEIのViews and Beyondテンプレート†3とISO/IEC/IEEE 42010の標準テンプレートだ。
Views and Beyond: The SEI Approach for Architecture Documentation https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513862
見てみると30ページの立派なドキュメントという感じ。堅くアーキテクチャーについてドキュメント化するならこうなんだろうなと思う。
ただ、書籍を読み進めていくと、Software Architecture DocumentationはSad（悲しい）と揶揄されることがある、といった話もあった。
きちんと書けば価値のある文章だけど、現実にはそうでないものもあるから（＝ということは書くのに時間がかかる一方で価値が届けられてない、時間の浪費になってしまっているものもある）、ということみたいね。
未解決の問題や懸念が既に見えている部分はドキュメントに残して後続の人に伝えよう、というのは結構大事だなと思う。
仕事によっては、それがわかっているなら対処すれば良い、なんて言われてしまうこともあってここを書きづらいこともあるのだけど、時間は有限だしフェーズを切って進めていくしかないのでともすると、このリスク、未解決の質問、今後の課題を残そう、という記述はとても価値がある。
既知のリスクと未解決の質問に関するセクションを含める。これらのセクションの目的は、すでに分かっている地雷に光を当てることだ。これによって、後続の設計者はうまくいけばそれらを避けることができる。
さっきのアーキテクチャードキュメントにもあったけれど、価値のあるドキュメントはどうしたら書けるかということで、一般論として4つあげられている。
個人的には一番上と一番下が好き。
一番上は、お客様だったり、関係者の言葉を使って書くとか、ちゃんとドメインに入り込んだドキュメントにするという話だと思ってる。
これをしないと実際に必要とする関係者が、読んでもちっとも理解できない何かができてしまう……。
一番下は、実際には自分はあんまりできていないのだけど、かなり重要だと思ってる。なぜそうしたのか、というところには色々な歴史的背景があるはずで、それを汲み取らなかった結果改修に失敗したり想定外のバグを埋め込んでしまう話はよく聞く。
派生開発のUSDMだと、要求に対して理由を書く枠が用意されていたと思う。その要求に対する仕様については、候補に挙げた仕様も書くけど、決まったやつに特別な印をつける、というのも書き方になっていたはず。どうしてその仕様にしたかについては特別重要な場合だけ理由を書いていた気がするから、そこをこのアーキテクチャードキュメントと整合をとるなら、全ての設計判断ではなく、ASR（＝Architectual Siginicant Requirementだったかな、影響を与える機能要求のこと）についてのみ書くと解釈すればUSDMとも整合が取れる、はず、かな。（そもそもUSDMが出てくるところとアーキテクチャードキュメントが出てくるところは同じ、とは言い難い気がするけど）
時間を無駄にしない最良の方法は、優れたアーキテクチャ記述を作成することだ。どの記述方法でも、優れた記述には次の4つの特徴がある。
* 聴衆を念頭に置いて特別に作られている。
* アーキテクチャの複数のビューを示している。
* 要素とその責務を明確に定義している。
* 設計判断についての根拠を説明している。
これもさっきと同じ話。アーキテクチャー上の決定は選択肢も含めて記録する必要があるという話。
アイデアを選び取る際には、より多くのアイデアが捨てられているものだ。人はそれに気づくことさえなく、多くの選択肢を瞬く間に退けることができる。チームとして話し合ったいかなる議論も、きちんと記録しておこう。内面に強く思っていることがもしあれば、他の人がそこから利益を得られるよう考えを言語化しよう。
もうすぐこの本も読み終える。かなり気に入ったので、電子書籍で購入済だけど、物理本も買うことにした。ぱっと見てあの箇所なんだっけ？と引き出すには物理本の方が優れているというのが今のところの印象。