気になっていた「Design It!」を読んだ．副題に「プログラマーのためのアーキテクティング入門」と書いてある通り，ソフトウェアのアーキテクチャをどのようにデザインするか？という観点で視野を広げられる1冊だった．読む前は「そもそもアーキテクチャというものは抽象度が高いし〜」とか「ソフトウェアによっても要件が違うから再現性も低そうだし〜」という懸念もあったけど，うまくまとまっていて読んで良かった！と思えている💡理論的な内容から Lionheart という具体的なシナリオ紹介もあった．また後半は「アーキテクトの道具箱」として，すぐに試せるアクティビティが多く紹介されていた．

作者:Michael Keeling
オライリージャパン

Amazon

本書は大きく「3部構成」になっている．本書における重要な用語などは序盤から出てくるため「1章」から「13章」までは順番に読むと良いと思う．「14章」以降はリファレンスとして気になるものを中心に読む．そして，原著は2017年に出版されていて，本書は2019年に出版されているため，技術トレンドとして比較的新しいアーキテクチャが紹介されているのも良かった．

第Ⅰ部「ソフトウェアアーキテクチャ入門」
- 1章「ソフトウェアアーキテクトになる」
- 2章「デザイン思考の基礎」
第Ⅱ部「アーキテクチャ設計の基礎」
- 3章「デザイン戦略を立てる」
- 4章「ステークホルダーに共感する」
- 5章「アーキテクチャ上重要な要求を掘り下げる」
- 6章「アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に）」
- 7章「パターンで土台を作る」
- 8章「意味のあるモデルで複雑さを扱う」
- 9章「アーキテクチャデザインスタジオを開く」
- 10章「設計判断を可視化する」
- 11章「アーキテクチャを記述する」
- 12章「アーキテクチャに通知表をつける」
- 13章「チームのアーキテクト力を強める」
第Ⅲ部「アーキテクトの道具箱」
- 14章「問題理解のアクティビティ」
  - アクティビティ 1 : たった一つを選ぶ
  - アクティビティ 2 : 共感マップ
  - アクティビティ 3 : GQM ワークショップ
  - アクティビティ 4 : ステークホルダーインタビュー
  - アクティビティ 5 : 前提リスト
  - アクティビティ 6 : 品質特性ウェブ
  - アクティビティ 7 : ミニ品質特性ワークショップ
  - アクティビティ 8 : POV Madlib
  - アクティビティ 9 : 応答測定のたたき台
  - アクティビティ 10 : ステークホルダーマップ
- 15章「潜在的な解決策を探るアクティビティ」
  - アクティビティ 11 : アーキテクチャの擬人化
  - アクティビティ 12 : アーキテクチャフリップブック
  - アクティビティ 13 : CRC カード
  - アクティビティ 14 : 概念マップ
  - アクティビティ 15 : 分割統治
  - アクティビティ 16 : イベントストーミング
  - アクティビティ 17 : グループポスター
  - アクティビティ 18 : ラウンドロビン設計
  - アクティビティ 19 : ホワイトボードジャム
- 16章「設計をタンジブルにするアクティビティ」
  - アクティビティ 20 : アーキテクチャデシジョンレコード
  - アクティビティ 21 : アーキテクチャ俳句
  - アクティビティ 22 : コンテキスト図
  - アクティビティ 23 : まずこれを読もうリスト
  - アクティビティ 24 : インセプションデッキ
  - アクティビティ 25 : モジュール分解図
  - アクティビティ 26 : 選ばなかった道
  - アクティビティ 27 : 学習か判断のためのプロトタイプ
  - アクティビティ 28 : シーケンス図
  - アクティビティ 29 : システムメタファー
- 17章「設計の選択肢を評価するアクティビティ」
  - アクティビティ 30 : アーキテクチャブリーフィング
  - アクティビティ 31 : コードレビュー
  - アクティビティ 32 : 意思決定マトリクス
  - アクティビティ 33 : 振る舞いの観察
  - アクティビティ 34 : 質問－意見－懸念
  - アクティビティ 35 : リスクストーミング
  - アクティビティ 36 : サニティチェック
  - アクティビティ 37 : シナリオウォークスルー
  - アクティビティ 38 : スケッチして比較

ソフトウェアアーキテクト

「1章」では「ソフトウェアアーキテクト」という役割が整理されている．以下の責任を受け入れる必要があると書いてあり，ソフトウェアを深く理解し判断できるスキルが求められていると感じた．企業によっては明確に「ソフトウェアアーキテクト」というポジションがあるかもしれないけど，今までの経験だと CTO の役割にも近そう．

エンジニアリングの観点から問題を定義する
システムを分割し，責務を割り当てる
広い視野を持って全体に目を向け続ける
品質特性間のトレードオフを決定する
技術的負債を管理する
チームのアーキテクチャスキルを高める

品質特性

本書では「品質特性」という用語が繰り返し出てくる．「ソフトウェアアーキテクト」はプロダクトマネージャーによって定義された機能（フィーチャー）に対する「品質特性」に責任を持つ．本書に載っている表現は「ステークホルダーがソフトウェアの良さを判断するために外部から見える特徴」となり，「5章」には以下の「品質特性」の例が載っている．これらの特性を基本的には促進しつつ，場合によってはトレードオフとして抑制する．

設計時の性質
- 修正容易性 / 保守性 / 再利用性 / テスト容易性 / 製造容易性 / 製品化までの時間
実行時の性質
- 可用性 / 信頼性 / パフォーマンス / スケーラビリティ / セキュリティ
概念上の性質
- 管理容易性 / サポート容易性 / 簡潔さ / 学習容易性

そして「6章」には「スムージーを作るブレンダーの品質特性」という比喩で具体例が紹介されている．以下の品質特性のどれを促進したいのかによってアーキテクチャも変わる．

清掃しやすさ
カウンタートップにおけるか
静音性
パワー
携帯性
安全性

本書を読んでいるときに「ようするに品質特性って非機能要件のこと？」という疑問が湧いたけど，コラムとして明確に記載されていた．非機能要件でもあるけど，特定の環境下で実現する「品質特性シナリオ」を考慮すると機能要件の側面もあると書いてあった．また追加で調べると「品質特性」に関連する国際規格もあった．指標として参考になるー．

ja.wikipedia.org

タンジブル

本書を読んでいて，今まで聞き馴染みがなかった用語として「タンジブル (tangible) = 人がそのものに触れられる状態」がある．デザイン思考の中に「アーキテクチャをタンジブルにする」という考え方があり，言い換えると「アーキテクチャをより伝えられるようにすること」とも言える．アーキテクチャ図を書いたり，品質特性を確認するプロトタイプを実装したり，モデル化をするなども挙がっていた．

そして「16章（設計をタンジブルにするアクティビティ）」も良かった．ADR (Architectural Decision Records) に設計判断（歴史）を残したり，結果的に採用しなかった選択肢に対して関係者から「○○は検討したの？」と聞かれたときに回答できるドキュメントを残すなど，すぐに試せるアクティビティだった．

アクティビティ 20 : アーキテクチャデシジョンレコード
アクティビティ 26 : 選ばなかった道

adr.github.io

道具箱

「第Ⅲ部（アーキテクトの道具箱）」を読んでいたら他にも気になるアクティビティが多くあった．例えば「14章（問題理解のアクティビティ）」では，GQM (Goal-Question-Metric) を使ってビジネス目標に対する質問とメトリクスを洗い出したり，ホワイトボードなどに「前提リスト」をまとめて，意思決定や優先順位付けの参考にする．今までも似たようなドキュメントは作った経験があるけど，ここまで明確に落とし込めるとよりアーキテクチャに自信が持てそうだった．

アクティビティ 3 : GQM ワークショップ
アクティビティ 5 : 前提リスト

そして「17章（設計の選択肢を評価するアクティビティ）」では，設計を評価するためのアクティビティが載っている．僕は現在は技術講師をしていて，クラウドを活用したアーキテクチャ設計レビュー（ディスカッション形式）をファシリテーションする機会が頻繁にある．そのときに意識している観点である「どういう価値基準で意思決定をしたのか」や「どういうリスクが考えられるか」や「こういうシナリオに対処できるか」などを裏付けるためのアクティビティがあり，それぞれに名前が付いていることに価値を感じた．

アクティビティ 30 : アーキテクチャブリーフィング
アクティビティ 32 : 意思決定マトリクス
アクティビティ 35 : リスクストーミング
アクティビティ 37 : シナリオウォークスルー

まとめ

本書を読んで，改めて「ソフトウェアのアーキテクチャデザインって難しい！けど楽しい！」と感じた．今回の記事では紹介できなかったけど，他にも本書で良かった点は多くあり「7章（パターンで土台を作る）」や「12章（アーキテクチャに通知表をつける）」も印象に残っている．また冒頭に載っている平鍋さんの「日本語版序文」もとても良かった．Big Design Up Front (BDUF) でも No Design Up Front (NDUF) でもなく Enough Design Up Front (EDUF) を目指すという話もあった．

そして何と言っても翻訳された島田さんの記事に載っている「地図とコンパスを手に入れられる」という表現はあまりに的確すぎた！まさにそう👏本書は地図とコンパスを持ってソフトウェアのアーキテクチャデザインに挑戦するための1冊！僕自身もまた読み直すことになる！

「Design It!」おすすめでーす！

本書が良いなあと思うのは、とりあえずこれ一冊あれば、ビジネスを支えるソフトウェアのアーキテクティングにどう取り組んでいったらいいかの地図とコンパスを手に入れられるようになっているところです。
『Design It! ― プログラマーのためのアーキテクティング入門』 - snoozer05's blog