Design It 読んだまとめ（第二部3-4章）

アーキテクト投資の割合

完璧な設計を目指すことは現実問題不可能と言っていい。（時間などのコストを考えると）
そのため、私たちは実現可能な必要最小限のアーキテクチャを見つけることを目指すとよさそう。

アーキテクチャの探し方の観点としては以下の通り。
・解決策は実験: 仮説を検証し、捨てることを許容する
・リスクを減らすことに専念: リスクから優先順位を決める
・問題を単純化する: 既知の解決策（定型問題）を見つける、ステークホルダーの数を減らすなど
・素早く繰り返し、学ぶ: 早く失敗して学ぼうということ
・問題と解決策を同時に考える: 解決策を探求するには問題を深く理解する必要があるし、問題を理解するのに解決策を探ることが役立つ。相互の関係性がある

これらについて使用する時間は結果的に実装を遅らせることになる。
逆に、将来的なスピード感を高めることにもつながる。
2つの反する関係を持っていることから、デザインスイートスポットを見つけていくと良い。
これはシステムの規模にもよって異なるので、小さいシステムならアーキテクチャ投資はあまり恩恵を受けられないかもしれない。

リスク駆動

リスクという言葉をあえて定義するなら「将来起こるかもしれないよくないこと」となる。
リスクについてを因数分解すると次の２つに分けることができる。
・条件: 現在の世界の事実
・結果: 将来発生する可能性のあるよくないこと

リスクの条件と結果の例
現在はコロナウイルスに多くの人が感染している。（条件）
3密になる場所へ行くと感染する可能性がある。（結果）

リスクによってデザインのマインドセットが異なってくる。いくつかの問によってどのマインドセットが適切かを判断できそうだ。

・ステークホルダーたちのことをもっと深く理解する必要があるか（問題にリスク、理解のマインドセット）
・代替策を十分に検討したか（解決策にリスク、探求のマインドセット）
・ステークホルダーに理解はされているか（コミュニケーションにリスク、作成のマインドセット）
・設計判断を行う必要があるか（設計判断や設計の適合性にリスク、評価のマインドセット）

このような観点からリスクを絞り、最も問題を引き起こす可能性が高いモノをリストの一番上にくるように優先順位を付けるのが良い。そこから着手していくことになる。

そして、リスクが軽減されたら能動的にデザインを行うフェーズから受動的に移行しよう。（アクティブデザインからパッシブデザインへ）

設計の計画

アーキテクチャの設計は期待を設計し、詳細を説明するものになっている。
主に次のことを考慮すると良いだろう。
・設計を止める条件: タイムボックス、ゴールを区切るなど
・必要な設計成果物: 文書化の方法は開始前に決める。ホワイトボード？confluence？
・タイムライン: 要求のレビュー、設計のレビュー、評価のスケジュール
・上位リスク: 必ず優先順位が上位に来るリスクを組み入れる。優先順位は常に入れ替わるので、見直しも必要
・概念的なアーキテクチャ設計: 解決策から始める。軽量のスケッチからでも良い。

ステークホルダーへの共感

利害関係者のことをステークホルダーと呼ぶが、多くの場合はそれは複数人存在する。そのため、ここではステークホルダーグループと名付けている。
これだけ多いと関係性や相互作用も多くなってくるため、ステークホルダーグループを線でつないでステークホルダーマップを作ると視覚化できて良い。

これらを眺めると、本質的な目的のビジネス目標を発見できてくる。
これを形にすることで価値を届ける人々を理解することの手助けになる。
主に次の項目から考えると良い。
・主体: 個人だったり、役割だったり
・成果: 何が変わるのか、何を目指すためにアーキテクチャを設計するか
・コンテキスト: ステークホルダーのインサイト（購買意欲の核心やツボ）を共有することで、共感に役立つ

ほとんどのシステムのビジネス目標は３～５つが良いところ。
それ以上は混乱しか招かないのでやめるべき。

ビジネス目標を測定可能なものとして明確にすることは難易度が高い。
アーキテクトはいくつかそのための引き出しを持っておき、ステークホルダーが言語化する手伝いをする必要があるだろう。

Lionheartプロジェクト～戦略立てと共感～

上記の内容をさらに読み解くために、本書で扱うプロジェクトについてもまとめる。

問題を市長へ聴取しにいく。最大の関心ごとはセキュリティとプライバシーだった。
市のIT部門が何か固有の制約を課してくるかもしれないが、最大のリスクの優先度は今のところ高くないので、まずは共感するところから開始する。

ステークホルダーマップを作ったところ、いくつか分かったことがあった。
・開発チームとやり取りするのは市長
・行政管理予算局は市長と市議会から政策の支持を受ける
・全員と話すことは無理。会話するステークホルダーを絞り込んだ方がよさそう
・企業の提案依頼に一部、弁護士を通している企業がいた。既存システムが様々な使われ方をしているかもしれない
・行政管理予算局が実際にユーザとやり取りしているため、行政管理予算局とも対話する必要がある

ビジネス目標はステークホルダー（主体）ごとに異なるものを持っている。
今回は市長・行政管理予算局が各々持っており、市長は予算と企業との関りを。行政予算管理局はRFPの時間とデータの蓄積について成果を求めていた。

さいごに

リスク駆動でアーキテクトの優先順位を考えよう、ステークホルダーへの共感は大事にしよう・・・ということを抑えてきた。
ここまでで先ずは着手するきっかけまではつかめるようになったので、今後は選択肢を持って具体案を掘り下げていくことを学んでいくことだろう。

ではまた。