Design It！ の商品レビュー

マイケル・キーリング(著者),島田浩二(訳者)

2025/06/03

ちょっと難しかった

ソフトウェアアーキテクチャ
ステークホルダー（利害関係者）の理解を行う
小さく進める

優れた図
例えば、「C4 モデル」

金字塔：アーキテクチャトレードオフ分析法（ATAM）

銀の道具箱
問題解決
アクティビティ1
たった一つを選ぶ
代替はトレードオフスライダー

アクティビティ2
共感マップ
代替はアクティビティ7、6

アクティビティ3
GQMワークショップ

アクティビティ4
ステークホルダーインタビュー

アクティビティ5
前提リスト

アクティビティ6
品質特性ウェブ

アクティビティ7
ミニ品質特性ワークショップ
代替は伝統的なQAW

アクティビティ8
POV Madlib
代替は、目標の丘、伝統的なビジネス目標ステートメント

アクティビティ9
応答測定のたたき台

アクティビティ10
ステークホルダーマップ

潜在的な解決策を探るアクティビティ
アクティビティ11
アーキテクチャの擬人化

アクティビティ12
アーキテクチャフリップブック
代替は、アクティビティ26

アーキテクチャ13
CRCカード

アクティビティ14
概念マップ
代替は、アクティビティ12

アクティビティ15
分割統治

アクティビティ16
イベントストーミング
代替はユーザーストーリーマッピング

アクティビティ17
グループポスター

アクティビティ18
ラウンドロビン設計

アクティビティ19
ホワイトボードジャム

設計をタンジブルにするアクティビティ
アクティビティ20
アーキテクチャデシジョンレコード

アクティビティ21
アーキテクチャ俳句

アクティビティ22
コンテキスト図

アクティビティ23
まずこれを読もうリスト

アクティビティ24
インセプションデッキ

アクティビティ25
モジュール分解図

アクティビティ26
選ばなかった道

アクティビティ27
学習か判断のためのプロトコル

アクティビティ28
シーケンス図

アクティビティ29
システムメタファー

設計の選択肢を評価するアクティビティ
アクティビティ30
アーキテクチャブリーフィング

アクティビティ31
コードレビュー

アクティビティ32
意思決定マトリクス

アクティビティ33
振る舞いの観察

アクティビティ34
質問-意見-懸念

アクティビティ35
リスクストーミング

アクティビティ36
サニティチェック

アクティビティ37
シナリオウォークスルー

アクティビティ38
スケッチして比較

2021/12/29

アーキテクチャというと開発者のためのものというイメージだったけど、ステークホルダーみんなのものだと気づかされた。
ステークホルダーマップから、コンテキスト図、機能仕様、品質特性など、実装を通じて、選択してきた数々の設計判断などのすべてがアーキテクチャを形成している。
アーキテクトに必要なのは孤高にそびえ立つ、象牙の塔を描く才能ではなく、アンダーエンジニアリングでもオーバーエンジニアリングでもない最適な制約を見出す、継続的な行動、コラボレーションだ。
広く理解し、深く探求して蓄えた暗黙知を、形あるものとして作成し、評価することを継続し続けることでいい塩梅を保つことができる。
そのための、時間の使い方、マインド、コラボレーションのための銀の道具箱に詰めた38のアクティビティが紹介されている。
それなりに大きなシステムなのにアーキテクチャがいまいちだなともやもやしているなら、短時間でもいいので気に入ったアクティビティに投資してみよう。
1時間の設計が1ヶ月のコーディングに相当するということを実感できるんじゃないかな。
(経験則から言うと、それ以下の効果になりやすく、それ以上の効果が得られることはほとんどない気がしている)

2021/11/10

エンジニアなら読んで損はしない一冊。

設計やアーキテクチャーに興味がある人なら序文〜1章あたりで勇気づけられる人は多いはず。

アーキテクティングを象牙の塔にせず、いかに民主化していくかといった話題は参考になる。

システムを作り上げていく過程で行うアクティビティが辞書的に紹介されているのもありがたい。

2020/12/31

ソフトウェアアーキテクチャについて書かれた一冊です。
ソフトウェアアーキテクトの役割、設計の基礎、品質特性、アーキテクチャパターン、アーキテクチャのドキュメント化、評価、チームへの共有、そしてそれらに関するアクティビティ一覧など、幅広く書かれています。

特定のパターンについてではなく、アーキテクチャというテーマで一冊書かれており、勉強になる内容が多かったです。
ステークホルダーやチームとの関わりについても書かれているのが実践的でよかったです。
ただ、どうしても抽象的な話が中心にはなるので、開発の初心者にはわかりづらいかもしれません。
また、途中で出てくる例が正直わかりづらいです。

アクティビティ一覧はおもしろそうと思いつつ、実際にやってみないことにはなにも得られないままになってしまうので、なにかしらチームでやってみるといいと思います。
と書きつつ、自分はどのアクティビティも試せておらず、どうやって実際のプロセスに組み込むかは難しそうです。

2020/11/03

プロジェクト遂行のストーリーに沿って、よくあるアーキテクチャの問題を判断、解決していく内容で読みやすかった。
個人的には、特に ADR (Architecture Decision Record) が参考になった。その技術を選んだ理由、他の候補、見直すタイミングなどをドキュメント化しておくことで、保守や次期リプレースの際にとても役立つと思った。
ストーリーの中で、ステークホルダー同士の会話などがあると更に理解しやすいと感じた。

2020/09/18

今のところ、拾い読みしただけ。
デザインパターンとアーキテクチャパターンの違いの説明が役に立った。著者はその区別はそれほど重要ではないと言っているが、初学者が混乱しやすい点でもあると思う。
7章のアーキテクチャパターンについては、必要に応じて読むようにしたい。

2020/07/05

これは強烈に良かった。どれくらいかというと、電子書籍で読み終えてからさらに物理書籍を注文してしまうくらい。

IBMで培われたアーキテクチャードキュメントの作り方と、そこから現実的に削ぎ落とす部分とを、いい塩梅にして示してくれていて実践的に感じる。
とても好き。

ちなみにこのタイトルは〜It!というシリーズの中の一冊らしい。

2020/03/01

アーキテクチャを実践するために必要な、非技術的な振る舞いまでを含めた入門書。
いかにしてビジネスと紐付けたアーキテクチャをつくりあげるか、評価するか。そういった側面にかなりの分量を割いている本書は、現実世界と向き合うアーキテクトにとっての頼もしい道しるべとなりそうだ。

個人的には、選ばれなかったアーキテクチャを記録しておく、設計の評価をコードレビューで行うといったアクティビティに強く興味をもった。
これらは新規に作り上げるソフトウェアだけでなく、レガシーと化したソフトウェアと向き合うにあたって威力を発揮しそうだ。

基本的には非エンジニアでも読める内容、かつ非エンジニアであっても概念を理解しておくことが望ましいものだと感じた。時折出てくるテクニカルタームに怯まず、手にとってみてほしい。

2020/01/22

PMではなくアーキテクチャを考える立場としてなにをすべきかを書いてある。

大枠から入り個別具体的な手法までカバーされており概要を掴みやすい。これを読んだだけでどうにかなるものではなく、まず全体像をつかむのに向いている。
手法も網羅的に様々なものが紹介されているので、他の本と合わせて使ってみたり習得したものを適用していく想定だろう。

2020/01/13

アーキテクティングに関する本。
BDUF(Big Design Up Front)でもNDUF(No Design Up Front)でもなくENUF(Enough Desing Up Front)を行うことを推奨している。そのために、デザイン思考的なアプローチをアーキテクティングに取り入れよう、というのが本書の目新しい部分か。
現在アーキテクトとして働いている人だけでなく、これから学ぼうという初学者も対象だと書かれているが、実際にはある程度のアーキテクチャ設計経験がないと難しいかもしれない