スポンサーリンク
概要
オライリーから発売されている、「Design IT! プログラマーのためのアーキテクティング入門」を読んだので感想を書こうと思います。
技術書のセールとおすすめ書籍を紹介しています。合わせてご覧ください。
スポンサーリンク
書籍概要
どんな本？
本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。
- Michael Keeling 著、島田 浩二 訳
- 2019年11月 発行
- 404ページ
- 定価3,960円(税込)
スポンサーリンク
スポンサーリンク
内容のまとめと感想
プログラムや実装の話ではなく、全体の構造を決めるためのアーキテクチャの設計フォーカスした本です。
具体的なアーキテクチャの設計方法よりも、どのように考えて設計すれば良いかという話が多く、全体的に抽象度が高く、個人的に読むのが大変な本でした。
技術的な側面よりも、ステークホルダーやチームメンバーなど、アーキテクチャに関係する人々とどのように協働していけばいいかを示した、コミュニケーションやファシリテーションに関しても多くを割いている印象を受けました。
また、分量として後半1/3は設計作業で必要となる、各種会議や設計手法をまとめたツール集的な側面も持っています。
テーマ的にしょうがないのですが、抽象的な説明が多くて理解が難しく、読んでいてかなりしんどかったです。
ある程度熟達した経験を持つエンジニアや、何度も読み返していく必要性がある本かもしれませんね。
一度に読んで理解するのではなく、定期的に何度も読んで、自分の経験値に応じて新たな気づきが見つかる本だと思います。
(2022/04 追記)
同様なアーキテクチャの設計にフォーカスした書籍である、「アーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ」が発売されました。
感想を下記で紹介しているので合わせてご覧ください。
アーキテクチャの基礎の方がより、具体的なアーキテクチャ構造などの知識にフォーカスを当てているのが特徴です。
重複はあるものの、相互補完的な形になっているので合わせて読むことをオススメします。
良かった点
事例ベースでの補足
１冊を通して１つの仮の事例をベースに各章の最後に章で学んだことを活かして、仮の事例がどのように進めたか書かれています。
全体的に抽象度が高い内容となっていますが、これのおかげで少しはイメージがしやすくなっていました。
ツール集
後半1/3は設計作業を助けるツール(手法)の使い方や具体例が示されています。
このあたりは図が多く、具体例も示されているので、理解しやすいです。
本書の内容を丸々使うのは難しくても、この部分の一部だけを使用して、現在の設計作業を助けるといったことも可能になるかもしれません。
その他オライリー本感想
その他のオライリー本の紹介をしていますので、合わせてご覧ください。
【オライリー本感想】Seleniumデザインパターン&ベストプラクティス はUIの自動テストのガイドとして良くまとまっている良書
スポンサーリンク
読書ノート(個人的なまとめ)
第1章 ソフトウェアアーキテクトになる
ソフトウェアアーキテクトとは何を行うのか？その役割に関して説明されている章です。
技術的な観点はもちろんのこと、ビジネスやユーザーなど様々な観点が求められている事が書かれています。
何に優先を置くのか、品質特性を決めるというのは確かに重要な点だと思いました。
- ソフトウェアアーキテクトが行うこと
- チームで独自の立ち位置(プロジェクトマネージャでもプロダクトマネージャでもない。ただしビジネス上の責任やリリース責任を持つ。コードも書く。)
- ビジネス、技術、ユーザ全ての観点を持つ必要がある
- エンジニアリングの観点から問題を定義する
- 品質特性の定義、方針に従うための設計上の制約や機能に関して責任を負う
- システムを分割し、責務を割り当てる
- 小さいものほど予測やテスト、設計が用意になるので分割を行う必要がある
- 広い視野を持って全体的に目を向ける
- 幅広いコンテキスト(ユーザ、チーム、ハードウェア、開発目的など)を調査せる
- 設計判断がこれらのコンテキスト対してどのような影響があるのか広い視野を持つ必要がある
- 品質特定のトレードオフを決定する
- 品質特性を満たすために犠牲となるものの判断（例：冗長性を上げるためにコストが向上する点に関しての判断）
- 技術的負債を管理する
- 技術的負債を可視化し、管理するためにステークホルダーがどのような行動を取れば良いかを判断できるようにする
- チームのアーキテクチャスキルを高める
- 設計のスキルとアーキテクチャの概念を適切なタイミングでチームに教えていく
- ソフトウェアアーキテクチャとは何か？
- 望まれる品質特性やその他の性質を促進するために、重要な設計判断が集まったもの
- 基本構造を定義する（３種類の要素と関係を用いてアーキテクチャを構築する）
- モジュール：クラス、パッケージ、DBテーブルなど（〜を使用する、許可する、依存する）
- コンポーネント&コネクタ：オブジェクト、コネクション、スレッド、プロセスなど（〜を呼び出す）
- 割り当て：サーバー、センサー、LB、人、コンテナなど（〜の上で実行する、責任を負う）
- 品質特性を見通す
- 品質特性：ステークホルダーがソフトウェアシステムの良さを判断するための外部からの特徴（拡張容易性、可用性、保守性、テスト容易性など）
- 自分たちが望む品質特性をを選択する必要がある
- チームのアーキテクトになる
- ソフトウェア設計に関して特定のやり方で考える人
- どんなチームでも１人以上のアーキテクトがいる（役割上無くても）
- プログラマからソフトウェアアーキテクトへの道
- 平均３〜５個のソフトウェアの開発経験がある
- プログラムを書く時間は減るがやめてはいけない
- プロジェクトポートフォリオを作成する
- ステークホルダー、ビジネス目標は何だった？
- 目的を満たすためにとられた全体のソリューションは？
- どんな技術に取り組んだか？
- 最大のリスクは何だったか？どのように克服したか？
- 今もう一度やり直すならばどのようにするか？
- 素晴らしいソフトウェアを作り上げる（ソフトウェアアーキテクチャが助けてくれる事）
- 大きいな問題をより管理しやすい小さい問題へと変える
- 人々の協働の仕方を示す
- 複雑な問題についての会話するための語彙を提供する
- 機能以外のものにも目を向ける（スケーラビリティや保守性など非機能的なものも）
- コストのかかる間違いを避けるのに役立つ
- 変化への柔軟な対応を可能とする
スポンサーリンク
第2章 デザイン思考の基礎
アーキテクチャを設計(発見)し、解決すべき問題を明らかにするために、デザイン思考といった手法に関して学ぶ章です。
デザイン思考とは、問題解決のために人間に注目する手法で、設計判断によって影響を受ける人々に注目する事で、解決すべき本質的な問題に集中する方法と説明されています。
結構抽象的な説明が多いのですが、最後に具体例を使って説明されているのが嬉しいポイントですね。
- デザイン思考の４つの原則
- 人間性の規則（すべてのデザイン活動は社会的な性質を持つ）
- 設計する際にはチームのメンバーと協働し、アーキテクチャを作っていく。離れてはいけない
- 曖昧性の規則（デザイン思考者は曖昧性を保全せねばならない）
- 必要最低限のアーキテクチャを設計すべき(優先すべき品質特性がどのように満たされるのか？促進するためにどのようにリスクを減らすのか？だけを示す)
- それ以外の設計判断は後続の設計者に委ねる（それらは詳細な設計。）
- 曖昧に保つ事で後続の設計がアーキテクチャの外で行えて、外部の変化に強くなる
- 再デザインの規則（すべてのデザインは再デザインである）
- 新しい何かを設計するより、過去の既存の設計を利用し、洗練させること時間を割くべき
- 感触性の規則（手で触れられるアイディアを作ることは常にコミュニケーションを促進する）
- アーキテクチャを共有するときには、タンジブル（感じられる）ものにする必要がある
- プロトタイプや簡単なモデルを作成するなど
- デザインマインドセット
- アーキテクチャを考える上での４つの観点
- 理解：ステークホルダーから情報を集め、問題を説明して理解する
- 探求：さまざまなアイディアを試して品質特性を満たす構造をみつける
- 作成：モデルやプロトタイプといった形で見える形にする
- 評価：アーキテクチャの一部をさまざまなシナリオを通して評価する
- 人間性の規則（すべてのデザイン活動は社会的な性質を持つ）
スポンサーリンク
第3章 デザイン戦略を立てる
2章で学んだデザイン思考を用いてアーキテクチャを設計する上での考えが示されている章です。
アーキテクチャ設計に時間を割けば後続の手戻りが少なくなるが、かけすぎると総合的には時間が長くなり、最適な場所を探す必要があるという点が説明されています。
(この最適な場所をスイートスポットと呼ぶ)
規模が大きいほど前段階に時間に割けば手戻りが減って、効果が大きいという点は一般的なウォーターフォール開発やV時開発モデルでも言われている点ですね。
例は面白おかしく、読みやすくイメージしやすいものとなっています。
- 満足のいく設計を見つける
- 解決策を実験とみなす(より早く低コストで問題を見つけるための実験)
- リスクを減らすことに専念する
- 問題を単純化する
- 素早く繰り返し、素早く学ぶ
- 問題と解決策を同時に考える
- どれくらい前払いの設計を行うかを決める
- アーキテクチャ設計に費やすのに最適なポイントをみつける（スイートスポット）
- アーキテクチャ設計に費やす時間と修正作業は逆の相関を持つ(設計に費やす時間が大きい=>修正時間が減る。費やす時間が小さいと修正時間が増加。 )
- 一般的にPJの20%の時間を割り当てるのが一番良い結果となる研究結果がある
- このパーセンテージはシステムの規模によって変化する(大規模ならば40%,小さいならば5%。)
- 大規模なほど、アーキテクチャ設計で受けられる恩恵が大きくなる
- リスクに道案内させる
- ソフトウェアシステムに関しての不安を全て書き出して、優先順位をつける
- リスクは条件 ~ 結果といった形で書く (例：オフィスの近くにレストランがオープンした => チームメンバーは食べすぎて病気になる可能性がある)
- リスクを軽減する方法
- 確率を下げる：管理された食事配分に関するセッションを開く。
- 影響を軽微する：オフィスに胃腸薬を常備
- リスクの時間的制約を取り除く：ランチミーティグを設定し、夕食のみレストランを利用可能とする
- 条件を取り除く：事務所を移転する
- 受けいれて何もしない：リスクが問題に変わったらその時に対処する
- リスクをマインドセット(理解、探求、作成、評価)を使用してリスクを軽減する活動を行う
- 例：データ処理は時間とリソースを消費するため処理が失敗する可能性がある => 探求：信頼性を向上させる方法についてブレイミングストーミングと、研究し、処理時間を減らすための代替設計を行った
- 軽減を行い、リスクのしきい値以下になったら、能動的な対応を終えて、監視する（問題になったらまたアクティブに対応を行う）
- 設計計画を立てる
- チームがアーキテクチャにどのように時間を費やすか全般的な戦略を定める。（軽量なドキュメント）
- 考慮すべき内容
- 設計を止める条件：タイムボックスで行うか、減らせるだけリスクを減らすか などどこまでやるかを決める
- 必要な設計成果物：どういった形で残す？（ホワイトボードの内容？それとも正式なドキュメント？）
- タイムライン：重要なマイルストーンを決める（評価やワークショップ、最初の実装タイミングなど）
- 上位リスク：一定のタイミングで見直す
- 概念的なアーキテクチャ設計：必要十分な軽量のスケッチ
スポンサーリンク
第4章 ステークホルダーに共感する
ステークホルダー(利害関係者)を明確にして、ニーズを理解することはアーキテクトにおいて重要な仕事のうちの１つとなります。
本章では、そのようなステークホルダーを明らかにし、どのようにニーズを明確にするかを示しています。
具体的な事例をベースに、ステークホルダーと関係を示してくれるので非常にわかりやすいです。
ステークホルダーに価値を提供する事がシステムにおいて重要な事なので、こういった形で重要なステークホルダーと話す内容を決めるのは重要だなと感じました。
- ステークホルダーマップを作る
- ステークホルダーとその関係を示す図を作り、話し合うべき重要な人々を見つけ出す
- コストを支払うのは？使うのは？関係の出入りが多いのは？利害関係の対立する人々は？といった観点で俯瞰して、更なる調査やインタビュー対象を見つける
- ビジネス目標を発見する
- ステークホルダーがソフトウェアを使って達成したいことをまとめ、優先順位付けなどに役立てる
- 書くときのコツ
- 主体：具体的な名前の方が良い(組合より、統一ハムスタートレーナー組合の方が良い)
- 成果：測定可能な形でニーズを表現する
- コンテキスト：ニーズに関する本質的な情報を記載する（例：市長のニーズ：調達予算を30%減らす => 選挙年度に教育や重要なサービスの予算が削減になることを避ける）
- POVフォーマットを使用して目標を書くと良い(例：(ステークホルダー)は(ニーズ)の必要がある。なぜなら(コンテキスト)だからだ。)
第5章 アーキテクチャ上重要な要求を掘り下げる
アーキテクチャ上重要な要求(ASR)は、構造の選択において強く影響するものです。
それを明らかにする事が重要で、アーキテクトの責任となります。
本章ではASRを明らかにするために４つの要求分類を説明した章になります。
結構抽象的な内容が多く、例も少なめでこの章は難しいです。ただ、最後に説明のあったASRワークブックのアウトラインは例があって便利そうでした。
- ４つの要求分類
- 制約：変更できない設計判断
- 品質特性：システムの動作を特徴付ける、外部から観測できる性質
- 影響を与える機能要求：特別な注意を必要とする機能
- その他の影響を及ぼすもの：時間、知識、経験、スキル、社内政治、余計なバイアス、意思決定をするその他全てのもの
- 制約
- 技術的な制約：プログラミング言語の選択、OS、プラットフォームの選択、コンポーネント、技術の使用
- ビジネス上の制約：チーム編成、スケジュール、予算、法的制約
- 制約は簡潔に記録する
- 制約、発生源、タイプ、コンテキスト
- 例：オープンソフトとして開発しなければいけない、市長、ビジネス、市のオープンデータポリシーに従う必要がある
- 作り出した制約なのか(適切な制約は問題を単純化する)、与えられた制約なのか区別し、変更する選択肢を常に持つこと
- 品質特性
- 一般的な品質特性
- 設計時の性質：修正容易性、保守性、再利用性、テスト容易性、製造容易性、製品化までの時期
- 実行時の性質：可溶性、信頼性、パフォーマンス、スケーラビリティ、セキュリティ
- 概念上の性質：管理容易性、サポート容易性、簡潔さ、学習容易性
- 特定の性質を促進し、一方で他を抑制する事が重要（トレードオフ）
- 一般的な品質特性
- ASRワークブック
- 特定した要求を書いたドキュメント
- チームやステークホルダーに共有し、理解を共有する
第6章 アーキテクチャを選ぶ
前述の通り、アーキテクチャ洗濯において、重要な要求(ASR)を満たすために、トレードオフを考慮して取捨選択を行う必要があります。
本章では、ASRに基づいてどのように意思決定を行なって構造設計を行なっていくかを説明している章となります。
この章も抽象度が高い説明が多いですが、一方で具体的な例や技術的な用語や要素も出てきたり、濃度が高いです。
意思決定マトリクスや要素責務カタログはわかりやすく、実際の設計段階で取り込みやすいものだと思いました。
（個人的には後でもう一度読み直しておきたい章です。）
- アーキテクチャ上重要なものを探究する
- 要素の相互作用を明確化する（通信方法は？HTTP?TCP？など。細かいインターフェス定義は後続の設計でカバーすべき領域)
- 品質特性を促進できるような技術やフレームワークを選択する（ニーズがフレームワークの思想に沿っているのか？）
- 出荷を確実にするような構築方法やデプロイ方法を探究する（継続的なデリバリー、自動テストなど）
- 意思決定マトリクスによるトレードオフの分析
- 考えられる選択肢に対して各品質特性に対して５段階の評価を行う
- （例：３層、Pub/Sub、SOAの候補のアーキテクチャに対して、可溶性など要求からそれぞれに関して５段階評価する）
- 機能的責務を要素に割り当てる
- 機能的な要求を達成可能にする概要図を作ってみる
- （例：WebUI、表示ビジネス、検索サービスなど）
- 各要素とその責務を表にしてみる（要素責務カタログ）
- 変化に向けて設計する（ソフトウェアの変化は必然。それを考慮する）
- 決定しなければいけない段階まで設計判断を遅らせる（調査や探究の時間を生み出す）
- 設計を判断を下すべき時期かの判断が必要。（下記は判断をするための質問例）
- 判断しないと進捗が遅れるか？多くの選択肢や新しい機会を生み出すか？遅らすと大きいリスクが発生するか？明確な根拠があるか？
- SOLID原則の適応など、単一責務で変更や分離しやすい構造にする
スポンサーリンク
第7章 パターンで土台を作る
アーキテクチャを一から作ることは無く、既存のパターンの再利用となる事が一般的である事をこれまでの章で説明されてきました。
本章では、どのような既存のパターンがあるのかを幅広く紹介している章です。
ただ、個人的にはかなり概要レベルでの説明でかつ、抽象度というか翻訳の問題なのかわかりづらい説明が多いです。
何個も例を挙げるよりはもう少し深掘りした説明の方が良かったかも。
この辺りの個々のパターンの説明の多くは、ググれば出てくるほど有名なものなのでそちらで理解するのがおすすめです。
- アーキテクチャパターンの採用のメリット
- 問題に適したパターンを採用する事で、ゼロから設計した場合と比較して厄介な問題を回避できる
- コミュニケーションの円滑化（共通の知識）
- アーキテクチャの例(個々の説明は省略)
- レイヤー
- ポートとアダプター(ヘキサゴナルアーキテクチャ)
- パイプとフィルター
- サービス指向アーキテクチャ(SOA)
- パブリッシュ、サブスクライブ
- 共有データ
- 多層(Multi-Tier)
- コンピタンスセンター
- オープンソース型の貢献
スポンサーリンク
第8章 意味のあるモデルで複雑さを扱う
ソフトウェアの複雑さ抑制し、粗い抽象度の観点でソフトウェアを考えるためのモデル化の方法に関してまとめている章です。
正直に言えばここも抽象概念の話が多く、眠くなります。
モデル間の関係の矯正に関しては、ツールなどを使って強制する方法は面白いと思いました。
- 優れたアーキテクチャモデル
- 設計の語彙を確立する（良い要素名を付ける）
- 関心を持つべき細部に注意を向ける（必要なものだけに詳細化する）
- 品質特性やその他のシステム特性を見渡せる
- アーキテクトの意図を記録できる（図を見て意図がわかるか
- メタモデル
- 概念、規則を定義し、それを満たす要素(メタモデル)と関係(モデル間の接続)を記載する
- 新しい概念を固体化する（例：可用性の要求＝＞各モデルにコストの概念を導入する=> コストをで色分けしたモデルを作る)
- 良い名前をつける（名前付けの７段階）
- ステージ１：名無し （なにかをするもの）
- ステージ２：無意味 （グランベリー）
- ステージ３：的確 => 要素の責務に対して１つを表している (ジョブスタータープロセス)
- ステージ４：的確かつ完全 =>要素の全ての責務を直接表している (データフェッチャー)
- ステージ５：適切な行い => 要素の責務を進化させる意図的な決定が含まれている (データ変換ジョブランナー)
- ステージ６：意図的 => 目的も表されている(データプリぺアラー)
- ステージ７：ドメイン抽象 => 個々の要素を超えて新しい抽象概念を作り出す(データ準備エージェント)
- コード内にモデルを構築する(モデルが適切にコードに反映させるようにする方法)
- アーキテクチャの語彙を適応する (モデルの名前をクラスやパッケージ名に使用する。)
- 要素感の関係を強制する
- モジュール構造：モジュール間の関係をチェックするために静的解析的なものでルールを作り検知する
- コンポーネント&コネクタ構造(C&C) ：マイクロサービスなどで用いられる。認証を実装し(契約)、要素間で許可された関係以外の実装はエラーが発生する
スポンサーリンク
第9章 アーキテクチャスタジオを開く
チームで設計に関して協働を行っていくワークショップ（アーキテクチャスタジオ）に関して書かれている章です。
アーキテクチャスタジオで行うべき内容とファシリテートする方法に関してまとまっている章です。
テレワークで同様なワークショップを開く際の補足などもあり、面白いです。（実際のところ、やはりこういったものは対面が一番だとは思いますが・・・。）
- アーキテクチャスタジオを計画する
- アーキテクチャ設計に全員参加してもらう事で、設計判断に関する合意を形成し、コミュニケーションを改善する
- ３つのF（早く、効果的、楽しい）
- スタジオで生まれるアイディア
- 作るもののアイディア
- もっと探究が必要なアイディア
- 新しい疑問としてのアイディア
- 時間としては数時間〜１日
- 基本構造
- 準備、キックオフ、作成、共有、批評、繰り返し、事後点検 (作成〜事後点検は繰り返す）
- 準備：ワークショップでの重要な目標を１〜２つ設定する
- キックオフ：知識の共有のため、コンテキストや目標説明にしっかりと時間を使う
- 作成：１人もしくは少人数のグループで取り組む。ペンなどのアナログな手法が望ましい
- 共有：作成したものを要点を説明して共有する
- 批評：共有された内容に関して、目的に合致したものか批評を行う
- リモート実施におけるポイント
- コラボレーションツールを利用する
- 時間を増やす
- 少人数グループに分ける
第10章 設計判断を可視化する
設計を共有する上で重要となる、理解しやすい図を書く方法をまとめた章です。
ただ１つの図を格納ではなく、粒度が異なる複数の図を書く事で理解を深めるなど、効果的な説明が含まれています。
- 複数のビューを持つ
- 絞り込みビューで拡大または縮小する
- 例：表示、ビジネル、サービスアクセスの３層 ＝＞ それぞれの層の詳細を書き出すビューを作る
- 可溶性ビュー：マイクロサービスなど要素が動的に増加する様子を図に示す
- 絞り込みビューで拡大または縮小する
第11章 アーキテクチャを記述する
ソフトウェアアーキテクチャを文章化する際のコツをまとめている章です。
冒頭にも書かれていますが、ドキュメント化というのは難しく、放置されて賞味期限切れしたり、読む人間の時間を多く奪うなど悪い点が目立ってしまいがちです。
ですが、優れたドキュメントは、資産となりコミュニケーションを促進し、品質を上げるものとなるので、そういったドキュメントをどうやって書くかといった事にフォーカスしています。
様々なステークホルダーがいるシステム開発において、それぞれのメリットに立ったドキュメントを記載する点などは、アーキテクチャに関わらず大事だと思いました。
- アーキテクチャ記述(文章化)が必要な理由
- 整理する：コンポーネント間の連携を誰もが把握できるようにする必要がある
- 技術、ビジネスステークホルダー間での共通語を確立：ビジネス目標や品質特性がどのようにアーキテクチャに現れているか示す
- 品質特性にスポットライトを当てる：誰もが品質特性を思う浮かべられるようにする
- 考えを明確にする：文章として書く事で、わかっている事、わかっていない事が明確になる
- 評価できるものを作る：早期での設計判断を分析する機会を与える（コードを使って実現するよりも早い段階でレビューや判断ができる）
- 聴衆に配慮したドキュメント作成
- 聴衆の価値を置くものを見つけ出すために、共感マップを作ってみる
- 共感マップ：渡した情報を使って何をするかを[行動、発言、作る、思考]の観点から書き出す
- 理解しやすさに配慮する
- 聴衆が利用しているドメインの言葉を使用して書くようにする（例：品目マスター番号といっているのに商品IDと書かない
- 不必要に新しい概念を使わない（必要ならば初出のタイミングで説明
- 図に凡例を使用する（専門用語を使用しない。UMLとかはあまり使わない方がいい
- ステークホルダーの関心事を中心にビューを作る
- 運用部門向けのビュー => 各コンポーネントのデプロイ先を示す
- よく使うビューポイント例
- スケーラビリティ、セキュリティ、保守性：アーキテクチャが特定の品質特性シナリオをどのように満たすか示す
- 規制：監査を実施するために必要な情報を示す
- 学習容易性：新しいメンバーがアーキテクチャを理解、コードを初めてコミットできるようなプラクティス
- ビジネスインパクト：様々な部分がビジネス価値にどのように貢献しているのか
- 判断の論理的根拠を示す
- 選ばなかった手法を理由と共に説明する（例：表示サービスにJavaを使用する => 開発チームがNode.jsが得意でクライアントとサーバでJSを使用して保守性を上げる）
- 聴衆の価値を置くものを見つけ出すために、共感マップを作ってみる
スポンサーリンク
第12章 アーキテクチャに通知表をつける
アーキテクチャは定期的に評価し、フィードバックを得る必要があり、本章ではそういった評価の方法に関して学ぶ事ができます。
- 設計をテストする
- 評価するものを作る：アーキテクチャをタンジブルにする（コードを書く、モデルのスケッチ、etc)
- デザインルーブリックを定義する：品質特性、シナリオ、評価(1~4段階)の表を作る
- 観点：重要かつ不可欠、区別(重複しない)、観察可能かつ測定可能、明確
- 評価は１〜４段階までにすべき。１０段階など多いと、個人差が出てしまう
- 評価ワークショップ
- レビュアーに上記の評価を実施してもらう
第13章 チームのアーキテクト力を強める
現代のアーキテクトは従来のようなトップダウン型の設計ではなく、開発チームと一緒に設計を行なっていくスタイルとなる。
そのようなスタイルを実現する上で、チームをどのように成長させていくかを学んでいく章になっています。
アーキテクトがチームに権限委譲をどの程度やっていくかをレベルで示している点はなるほどと思いました。
レベルを上げていく方法に関しても書かれてはいるが、実際のところ難しい部分ではあると思います。
- アーキテクチャ思考を促進する
- アーキテクチャを批評できるメンバーが多いほど、品質は向上する（意図を理解し、一貫性を維持する）
- 設計上の判断を監視をする代わりに、チームが進むための手引きを用意する（権威のあるリーダーよりも、コーチやメンター）
- 安全にチームに設計権限を与える方法
- ペア設計：メンバーと図を使いながら設計したり、ステークホルダーとの会議を行う
- 足場を作る：テンプレートやスケルトンコード、良い例悪い例の共有など
- ガイドレールを作る：自動でチェックする仕組み（８章のモジュール間の関係のチェックなど）
- 権限移譲のレベル
- レベル１：指示する（アーキテクトが判断を下し、チームに指示する）
- レベル２：説得する（アーキテクトが判断を下し、正しい理由をチームに示す）
- レベル３：相談する（チームに意見を求める、判断はアーキテクトが行う）
- レベル４：合意する（協同して、グループとして合意する。誰もが平等に会話する。）
- レベル５：助言する（助言などは行うが、設計判断はチームが行う）
- レベル６：尋ねる（チームが設計判断を行なって、影響をアーキテクトがチームに尋ねる）
- レベル７：委譲する（アーキテクト以外が設計判断を行う）
- チームが未熟な場合はレベル１〜３はアーキテクトが実施する
スポンサーリンク