今日の記事の中にある引用はこの書籍の5章後半〜6章。
まずは要求を知るための話として、アクティブリスニングが紹介されていた。
会社でも度々話には上がっていたのだけど、正確には理解していなかったことが読んでわかった。その上、自分はできていない。これを機に試してみたいと思う。
日本語でアクティブリスニングは積極的傾聴、なんだけど、積極的に聞くこと＝傾聴で、これは重ね言葉じゃないかしら。（どうでもいいか）
人物Aが人物Bに達成度や自分が解決した問題について話をしているとする。コツは、人物Aが発言を終えたことを示すまで、人物Bは口を挟むのを許されていないということだ。人物Aが発言を終えたことを示したときだけ、人物Bは人物Aの発言への理解を深めるために問いかけることを許される。質問をフィードバックや批評に変えることはできない。人物Bの目標は、理解を深めることだ。それが終わったら、今度は役割を逆にして、同様の訓練を体験しよう。
それから、アーキテクチャードキュメントの話も出てきた。会社でもアウトラインは聞いていたけど、こういった紹介はありがたい。
これがあれば、いざ実際にアーキテクチャーを設計するぞ、と思った時に、それをどうアウトプットにすればいいかのイメージがしやすくなる。
目的とスコープ
対象者
ビジネスのコンテキスト
ステークホルダー
ビジネス目標
ASR
技術的な制約
ビジネス上の制約
品質特性の要求
トップシナリオ
影響力のある機能要求
トップユーザーまたはユーザーのペルソナ
ユースケースまたはユーザーストーリー
付録A：用語集
付録B：品質特性の分類
それから、アーキテクチャー v.s. デザインはよく語られることだと思う。
会社の研修で学んだものだと、要求(作ってほしいもの)と設計(作るもの)の間にあるものがアーキテクチャーだってことで、何を作ろうとしているかでアーキテクチャーの対象は変わると聞いた。それなりに納得感があると思ってる。
とはいえ、アーキテクチャーを設計する、って表現もよく聞く。そうすると、結局アーキテクチャーとデザイン(設計)との違いはなんだろう、という話になるなあ。
すべてのアーキテクチャは設計だが、すべての設計がアーキテクチャではない
この記述と自分の理解を合わせていくと、設計には広義と狭義があり、広義の設計にはアーキテクチャーも上記で言及している設計も入る。
その上で、狭義の設計はいわゆる基本設計の一部と、詳細設計が入るのだと思う。
ちなみに、この基本設計とか詳細設計っていう言葉遣いは業界的には常識なのだろうけど、境界がわからなくて未だにピンとこない。
要件定義・基本設計・詳細設計、という分類でいくなら、要件定義と基本設計の一部までがアーキテクチャー、残りの基本設計と詳細設計がデザイン(設計)といった括りでいいのだろうか。
それから、ドキュメントを書いていると、図の上に示される要素ばかりがどんどんと増えていって、役割の不明なものが多くなってしまうことがある。
なので、次の記載も頷く以外にできることはなさそう。
明確に定義された責務のない要素はすべて排除されるべきだ。
フレームワークが決定を強制するっていうのは興味深い。確かに、各フレームワークやデザインのパターンは時々そうやって思想を反映するためにアーキテクチャーに制約を与えることがあると経験的にも感じることはある。
特にフルスタック系のフレームワーク、具体的にはフロントエンドならAngularとか、バックエンド系ならSpringとかは必要なものを大体備えているけれど、そこにはまらないものを使おうとすると苦労するかもしれない。
現代のソフトウェア開発技術には、アーキテクチャ上の前提が含まれている。フレームワーク、ミドルウェア、ライブラリといった、すべての既製技術は哲学を持っている。技術はそれを使用する方法と時期を教えてくれる。意見を持った技術は、アーキテクチャに決定を強制する。
技術の意見が私たちのニーズと一致しているとき、私たちは最高の状態を迎える。私たちのニーズが、技術が想定しているニーズの範囲から外れているとき、私たちはフレームワークとの大乱戦を始める準備が必要となる。
理想的には、要求があってそれに従ってアーキテクチャーが設計されて、そのアーキテクチャーに合ったフレームワーク等々が選択されるのがいいのだろうけど、各フレームワーク特有の知識なども求められるから必ずしもそうはうまくいかないということだよね。
使いたい技術が先にある、と言う時があると思うけど、それは結果的に良くも悪くもアーキテクチャーに制約を与えることになるってことでもあるね。
これもすごく好きな記述だった。
制約には技術的なものとビジネス上のものの2種類が存在する。技術的な制約は技術の選択肢を制限する一方で、ビジネス上の制約は人、プロセス、コスト、スケジュールを制限する。
要求には制約が含まれる、とわかったとしても、そのままだと漠然としすぎて適切に探索しきれない時がある。
技術的なものとビジネス上のもの(人・プロセス・コスト・スケジュール)、のように分けてもらえると、もやのかかった部分が晴れてこれまでの経験などから今回のシステムに該当する制約を引っ張り出してきやすくなる。
初期の設計判断は制約となる可能性があるものの、それらは実際には制約ではないことを覚えておこう。家の耐力壁のように、こうした初期の設計判断はすべてのものを定位置へと留める。耐力壁を家の中で動かすのは、費用がかかり困難な場合ももちろんある。しかし、それは技術的に不可能なことではない。与えられた制約と自分自身で与えた制約を常に区別しよう。
恥ずかしながらこの耐力壁は調べた。
従来からある木造建築の場合の筋交いのかかっている壁の部分で、揺れや横からの圧力に強くするために必要なものみたい。
これがあれば耐久性が上がるのだからジャンジャン増やせばいいじゃないか、と考えたくもなる。ただ、耐力壁を作ることには間取りを制限してしまうというデメリットもある。（具体的にはその壁には窓をつけれないとか）
耐力壁は（基本的には）自分自身で与えた制約だから、変更不可能なものではない。採用しているフレームワークや言語と同じ位置づけのものかもしれないね。
話は変わって品質特性のための例示。ブレンダーはどれを使ってもスムージーを作れる（機能要求）けれど、それぞれのブレンダーによってどう作れるか（品質特性）が変わる。（英語版の方が分かりやすくて原著から表を持ってきた）
表6-1 各ブレンダーの品質特性
Here is a summary of how well our top-quality attributes are promoted by each blender:
Standard Blender | Hand Blender | Chainsaw Blender | |
Cleanability | Neutral | Positive | Neutral |
Counter top-ability | Positive | Negative | Strongly Negative |
Quietness | Neutral | Positive | Strongly Negative |
Power | Neutral | Negative | Strongly Positive |
Portability | Strongly Negative | Positive | Strongly Positive |
Safety | Neutral | Neutral | Negative |
上の表のことをこの書籍では「意思決定マトリクス」と呼んでる。
よく具体的な数字を入れてわかりやすくする、といった対応を求められる。でも、それは必ずしも適切ではないとここでは取り上げられてる。
確かに、合計値が高いからこれ、とか、平均値が高いからこれ、とか、そういった話に至ってしまいがちなのは経験則として頷ける。
それでよく、この指標は優先度が高なので3ポイント、そして候補1は中程度だから2ポイントで掛け算すると候補1は6ポイント、みたいな計算をすることもある。
数字で分かりやすくて判断しやすいだけど、この掛け算の傾きで結果を左右することができるのは、確かに意図したものではないし、不適切だね。
表を作成する作業は、表自体よりも重要だ。意思決定マトリクスは、調査結果を要約し、ステークホルダーとの議論を促進するのに便利な方法だ。私たちは、ステークホルダーに設計判断のトレードオフについて強く議論をしてもらいたいのだ。表内のスコアを説明する準備をしておこう。
表内で数字を使うことは魅力的だ。しかし、それをしてはいけない。数字は分析において誤った信頼感や精度を与えるものだ。最終的に、誰かがステークホルダーの好みを加味してスコアを調整したり、列を合計したり、平均値を計算したり、その他恐ろしいアイデアを試したりしようとする。それは問題だ。
責務が曖昧な要素を排除する話は前述の通りだけど、じゃあ、責務をどうやって明確化するのか、ということで、Component Responsibility Collaborator（CRC）カードに書くというやり方が紹介されていた。
要素責務カタログを作るには、既知の影響力のある機能要求リストを調べ、各機能が1つの要素によってのみ所有されるようにする。また、アーキテクチャ内の各要素は、それが担う機能を少なくとも1つ持つべきだ。そうでなければ、その要素がある意味がない。
責務の明示だけでなくて、影響を与える相手の集中度合いなども確認できるから、コンポーネントの分割のためにも使えるとのこと。
最後に、アーキテクチャー上の決定を出来るだけ遅くにするという話。
拘束力のある判断を最大責任時点まで延期する
提案と同じだね。お客様に、なぜ今このプロジェクトを進めるべきかを理解してもらえると初めてプロジェクトは先に進む。
不確定要素は早く減らしてしまいたいと思ってついさっさと色々な判断を急いでしまうのだけど、そうすると前述の耐力壁ではないけれど、（動かせないわけではないけれど）動かしにくいものをわざわざ増やしてしまうことになりかねないってことだね。
相変わらず読み応えのある本だ。やっと次は7章に進める。