Design It!
- https://www.oreilly.co.jp/books/9784873118956/
- 2019-11-25 発売
- snoozer05 による邦訳
- 2020-01-02 にガッと読んだ
本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。
読書メモ
日本語版序文
平鍋健児さんの文章だ！
アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みをしすぎた設計(BDUF = Big Design Up Front)をしないということだ。
BDUF って呼ぶのか。
BDUF は良くないとしても、NDUF(No Design Up Front)はあまりにもリスクが高い。私たちは、ENUF(Enough Design Upfront)を目指しているのだ。
BDUF、NDUP、ENUF、なるほど。「EDUF」じゃないのかな？
Big Design Up Front - Wikipedia
序文
Michael は、水と油のようにならない、アジャイルとアーキテクチャ両方の一番良いところを組み合わせる方法を探し求めているのだ。
第III部には、アーキテクトがチームに向けて彫った石版は出てこない。出てくるのは、週単位のイテレーションに適したアクティビティやチームが設計の主導権を持つことを奨励するアクティビティ、そして設計をチームの第一級の関心事へと押し上げるアクティビティだ。これらの手法を実際に適用しているチームの写真も見ることができる。
しかし今日では、私の経験上、自分たちはアジャイルだと言いながら、無秩序なカウボーイコーディングをしているだけのチームが数多く存在している。
はじめに
本書では、デザイン思考と人間中心手法を使い、チームと協力してソフトウェアアーキテクチャを設計していく方法を学ん でいく。このアーキテクチャ設計のアプローチは、設計判断とその判断の影響を受ける人々との結びつきを強固なものにするのに役立つ。人を第一義に考えることで、より良い設計判断が可能となり、その結果、より優れたソフトウェアを作ることができるようになる。
銀の弾丸はない。しかし、ソフトウェアエンジニアであれば誰もが、素晴らしいソフトウェアを届けるためのプラクティスや手法、テクニックでいっぱいの銀の道具箱を持っいるものだ。第III部で紹介しているものは、いずれも私自身の銀の道具箱にあるものだ。それらを共有できることを光栄に思う。
銀の道具箱、かわいい。
1 章 ソフトウェアアーキテクトになる
1.1.5 技術的負債を管理する
技術的負債とは、ソフトウェアシステムの現在の設計と、継続的に価値を届け続けるために必要な設計との差分のことだ。技術的負債の量は、その差を埋めるのに必要な労力を見積もることで計測できる。すべてのソフトウェアには技術的負債がある。 技術的負債は、成功のための必然的な副産物だからだ。優れたソフトウェア開発チー ムは機能を素早くリリースするために技術的負債を戦略的に利用する。そして、時を経ても価値を届け続けられるよう、定期的にその負債を返済する。
1.2 ソフトウェアアーキテクチャとは何か
システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断 が集まったものだ。
アーキテクチャがうまく構成されている場合、ステークホルダーの求める品質特性は向上する。そして、求めていない品質特性は控えめに取り扱われるか、または、取り除かれる。
1.2.3 品質特性を見通す
品質特性とは、ステークホルダーがソフトウェアシステムの良さを判断するための、外部から見える特徴だ。それには、たとえば拡張容易性や可用性、保守性、テスト容易性などが含まれる。人は、ソフトウェアとやり取りする際に、必ず何らかの品質特性を体験している。
1.3.1 プログラマーからソフトウェアアーキテクトへの道
忘れてはならないのは、ソフトウェアアーキテクトとは、単なるチームの役割だけではなく、心の持ち方だということだ。プログラマーとして開発に取り組んでいるとき、あなたは毎日何十もの設計判断を行なっている。これらの判断の中には、アーキテクチャに対して大きな影響を与えるものもある。ソフトウェアシステムの構造に影響を与える決定を行う人であれば、誰しもがアーキテクト代行だ。
2 章 デザイン思考の基礎
私たちが必要とするアーキテクチャは、どこかその辺で私たちに発見されるのを待っている。
このやりがいのある仕事に役立てるために、デザイン思考と呼ばれる手法について学ぼう。
ここで「デザイン思考」の話が出てくる。
2.1 デザイン思考の 4 つの原則
デザイン思考は、プロセスというよりは、影響を受ける人々の視点から問題や解決策について考えるための方法だ。
-
- 人間性の規則 (The Human Rule)
- すべてのデザイン活動は究極的には社会的な性質を持つ。
-
- 曖昧性の規則 (The Ambiguity Rule)
- デザイン思考者は曖昧性を保全せねばならない。
-
- 再デザインの規則 (The Re-design Rule)
- すべてのデザインは再デザインである。
-
- 触感性の規則 (The Tangibility Rule)
- 手で触れられるアイデアを作ることは常にコミュニケーションを促進する。
頭文字をとって「HART」と名付けよう。
「HRT」もハートって読むんだっけね。
2.1.1 人間のための設計
設計とは本質的に人間中心の取り組みだ。私たちは人のためにソフトウェアを設計する。そして、人と共に設計する。アーキテクチャにおけるあらゆる設計判断は、何らかの形で誰かの力になるものだ。すべての設計判断は、他の人々に理解され、共有されなければならない。
2.1.2 曖昧さを保つ
Ruth Malan と Dana Bredemeyer は論文「Less is more with minimalist architecture」MB02 において、アーキテクトは必要最小限のアーキテクチャ(Minimalist Architecture)を設計すべきだと提案している。
必要最小限のアーキテクチャ (Minimalist Architecture) ってのは、リーンの MVP に通じるものを感じるね。決めすぎないことの重要性を示唆しているように思う。
アーキテクチャを必要最小限にするとは、責任を持てる限りにおいて設計判断を遅らせるということだ。
曖昧さを保つことによって、私たちは、たとえ周りの世界が変化したとしても、ソフトウェアを届けることができるのだ。
「遊び」「余白」の類を内包しろ、と言っているっぽいな。
2.1.3 設計とは再設計である
『パタン・ランゲージ』で、Christopher Alexander らは、253 以上にわたる土木工学の問題をよく知られた解決策と共にカタログ化した。取り上げている内容は、建築資材からコミュニティ組織のテクニック、建物の構造まで多岐にわたる。
ぼくらは何度でも Christopher Alexander の足跡と出会ってしまう。
ソフトウェアアーキテクチャを設計する際には、新しい何かを設計するよりも、既存の設計を洗練させることに、より多くの時間を費やすことになる。以前からあるソフトウェアシステムを無視するというのは、アーキテクチャを設計する際に最も効果が薄いやり方だ。
これは「世界全体」で見てもそうだし、「組織の中」で見てもそうだと思う。先人たちの活動や成果物にもっと興味を持てるようにしていきたい。
2.1.4 アーキテクチャをタンジブルにする
あるアーキテクチャを誰かと共有したいときには、コードだけではできない方法でそれを形にする必要がある。
アーキテクチャをタンジブルにする方法には色々なものがある。アーキテクチャを図に描く、アーキテクチャをコードの中で生き生きと表現する、構造や品質特性を体験できるようなプロトタイプを構築する、アーキテクチャの一部がどう機能するかを示す簡単なモデルを作成する、関連するメタファーを作成する、システムの制御フローの一部を身ぶりで伝える、などだ。
「コードを読めばわかる」のは素晴らしい状態だとして、そうでもないのにそのフレーズに甘えているのだとしたら悪い意味で「怠惰」ってだけになってしまう。
2.2 デザインマインドセットを身に付ける
ソフトウェアシステムを設計する際は、異なるデザインマインドセットの観点からアーキテクチャについて考える必要がある。デザインマインドセットとは世界について考える方法だ。それによって、適切なタイミングで適切な詳細に意識を集中させることができる。
- 理解 Understand
- 探求 Explore
- 作成 Make
- 評価 Evalute
「Evalute」って見慣れなくて「Evaluate」かな…？と思うなどした。原著の情報っぽい下記を当たってみてもそう思う。 https://www.oreilly.com/library/view/design-it/9781680502923/f_0021.xhtml
この 4 つ組は PDCA っぽさも感じる。
2.3 Think、Do、Check
ソフトウェアシステムに完成はない。ただリリースされるだけだ。ソフトウェアが決して完成しないのだから、私たちの設計アプローチにも終わりはない。既存の設計に手を加える場合でも、新しいものを作成する場合でも、アーキテクチャの一部を再考する必要があるときには、いつでも同様のアプローチを適用する。
2.3.2 任意の順でマインドセットを適用する
3 章 デザイン戦略を立てる
3.1 満足のいく設計を見つける
ソフトウェアアーキテクチャを設計の最適化問題と考える代わりに、次の活動に力を注ぐことで、必要最小限の設計を探し求めよう。
- 解決策を実験とみなす
- リスクを減らすことに専念する
- 問題を単純化する
- 素早く繰り返し、素早く学ぶ
- 問題と解決策を同時に考える
Christopher Alexander は「形の合成に関するノート」の中で、問題が常に解決策を念頭において定義されることを論じている。
形の合成に関するノート/都市はツリーではないにリンクしておこう。
3.2.1 デザインスイートスポットを見つける
ここでは「スイートスポット」というフレーズが繰り返される。
3.3.3 リスクが軽減されたら、パッシブデザインへと移行する
George Fairbanks は『Just Enough Software Architecture: A Risk-Driven Approach』の中で、アーキテクチャがシステムにおける最大のリスク要因でなくなるまで、アーキテクトは技術的リスクを減らすように取り組むべきだと語っている。
4 章 ステークホルダーに共感する
4.1 適切な人たちと話をする
実際には、それぞれのステークホルダーが 1 人だけということは滅多にない。そのことを際立たせるため、私たちはステークホルダーグループという用語を使う。グループとうまくやるというのは、個人とうまくやることとは異なる。同じステークホルダーグループにいる二人が矛盾した情報や競合する情報を提供してくる可能性もある。そのため、私たちはグループ全体の関心事を理解し、時には彼らの合意形成を手助けするように務める必要がある。
コラムの中で「顧客体験アーキテクチャ」という力強いフレーズが登場する。
ぼくのこれまでの経験において「ステークホルダー」について考える機会が少なかったからか、この章はほとんどメモを取らずに通り過ぎてしまった。
5 章 アーキテクチャ上重要な要求を掘り下げる
アーキテクチャ上重要な要求(Architecturally Significant Requirement:ASR) とは、アーキテクチャ構造の選択に強く影響する要求のことをいう。
5.2 品質特性を定義する
- 設計時の性質
- 修正容易性、保守性、再利用性、テスト容易性、製造容易性・製品化までの時間
- 実行時の性質
- 可用性、信頼性、パフォーマンス、スケーラビリティ、セキュリティ
- 概念上の性質
- 管理容易性、サポート容易性、簡潔さ、学習容易性
5.2.1 品質特性をシナリオとして記録する
- 刺激 (Stimulus)
- 発生源 (Source)
- 成果物 (Artifact)
- 応答 (Response)
- 応答測定 (Response measure)
- 環境 (Environment)
5.3 機能要求の分類を探す
機能要求がアーキテクチャ上の設計判断を促進するとき、それを影響力のある機能要求(influential functional requirement)と呼ぶ。
影響力のある機能要求は、アーキテクチャキラーと呼ぶこともできる。価値が高く優先度の高いこうした機能が実装可能でなければ、アーキテクチャを破壊して最初からやり直さざるをえないからだ。
「私の考えた最強の電卓アプリ」これの原文はなんなのだろうw
5.4.1 コンウェイの法則に従って生きることを学ぶ
あなたのチームがどのように組織され、どんな協働の仕方を好むかは、アーキテクチャ設計に影響を与える。1967 年に Melvin Conway によって考案され、Fred Brooks の『人月の神話』によって広められたコンウェイの法則は、チーム組織とアーキテクチャの関係を説明している。
5.6 ASR ワークブックを組み立てる
アーキテクチャにおける重要な要求を特定したら、それらを ASR(アーキテクチャ上の重要な要求)ワークブックに記録しよう。新しいソフトウェアシステムの始まりでは、ASR ワークブックは生きたドキュメントであり、急速に変化していく。アーキテクチャがまとまるにつれ、ワークブックを編集する頻度は少なくなる。しかし、逆に参照の頻度は高くなっていく。ドキュメントは重要な歴史的記録として残るが、最終的には、実行可能なテストやソースが真の情報源として ASR ワークブックの一部に取って代わる可能性はある。
「ソフトウェアデザインドキュメント」「Design Doc」みたいなものなのかな〜と想像しながら読んだ。
5.7 Lionheart プロジェクト:ここまでのあらすじ
要求ワークショップの数日後、あなたは数人のステークホルダーと品質特性に関する小さなワークショップを開催する。ワークショップでは、およそ 240 個の品質特性シナリオを引き出し、優先順位をつける。ワークショップで発生したすべての懸念事項を正式に記録するわけではないものの、参加者と協力し、優先度の高い上位 7 つのシナリオを洗練させる。
これまでのところ、主な焦点は問題を理解するところにあった。問題について分かっていることをステークホルダーと共有できるようにするため、いくつかの生成物を作成した。
さらっと書いてあるけれど、ソフトウェア開発プロセスにまつわる重要な示唆を含んだ文章だと思う。ワークショップを実施したり、あれこれ発見したり、そういった体験を経て「(要求定義なんてとうに終わっていて) 設計もけっこう進んできた」と思う人と「だんだんと要求を理解できてきた」と思う人で、このフェーズの感じ方がぜんぜんちがうと思う。
6 章 アーキテクチャを選ぶ (君がアーキテクチャに選ばれる前に)
すべてのソフトウェアシステムはアーキテクチャを持つ。けれど、それは望むアーキテクチャが自然と最後に残るということではない。設計判断を天に任せるなら、どんな運命が待っているかは言うまでもないことだ。ソフトウェアシステムをどのように構成するかについて積極的に判断を下すことで、私たちのニーズに合ったアーキテクチャを得られる可能性は著しく高まる。
「人生そのものじゃん」と思った。ぼくらひとりひとりの人生も、自分で思考して選択することでニーズに合ったものになる可能性が高まると思う。きっと「人生にもアーキテクチャがある」と言えるのだろう。
6.1.1 アーキテクチャ上重要なものを探求する
Grady Booch は、「すべてのアーキテクチャは設計だが、すべての設計がアーキテクチャではない」と述べている。「1.2 ソフトウェアアーキテクチャとは何か」で学んだように、システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。アーキテクトは、これらの重要な設計判断を検討し、望ましい品質特性を満たすようにソフトウェアを構成する方法を積極的に選択する必要がある。
これを読んで「設計とアーキテクチャのちがいとは…？」となって「1.2 ソフトウェアアーキテクチャとは何か」まで戻って読み直してきた。まだ自分の言葉ですらすらと説明できるようになっていないな〜と感じる。
現代のソフトウェア開発技術には、アーキテクチャ上の前提が含まれている。フレームワーク、ミドルウェア、ライブラリといった、すべての既製技術は哲学を持っている。技術はそれを使用する方法と時期を教えてくれる。意見を持った技術は、アーキテクチャに決定を強制する。
技術の意見が私たちのニーズと一致しているとき、私たちは最高の状態を迎える。私たちのニーズが、技術が想定しているニーズの範囲から外れているとき、私たちはフレームワークとの大乱戦を始める準備が必要となる。
ニコニコしながら読んじゃった。英文だと Opinionated って言われるやつ。雄弁なソフトウェアってあるよね。
6.5.1 拘束力のある判断を最大責任時点まで延期する
簡単に元に戻せない決定、つまりアーキテクチャ上の設計判断は、重大だ。行き詰まることや方向間違いを避ける 1 つの戦略は、責任を持てる限り拘束力のある判断を遅らせることだ。決定しなくてはならなくなるまで設計判断を遅らせることは、調査や探求の時間を生み出すことにつながる。
ぼくも「不可逆な操作はなるべく回避する、あるいは遅延させる」という行動方針を持っている。
『リーンソフトウエア開発 : アジャイル開発を実践する 22 の方法』で、Mary Poppendieck と Tom Poppendieck は、重要な選択肢を失うのを避けるために、判断を下さなければならない時期まで決定を遅らせる「[最終責任時点](last responsible moment)」という考えを紹介している。最終責任時点について考える代わりに、私たちは「[最大責任時点](most responsible moment)」、すなわち、ソフトウェアシステムに最も良い前向きな影響を与えるタイミングで設計判断を下すことを試みたい。
設計判断を下すのに適した時期かを見極めるのに役立つ質問を次に示す。
- 判断しないことが進捗を妨げるか?
- 判断は後回しにできない問題を解決するか?
- 判断はより多くの選択肢や新しい機会を生み出すか?
- 判断を遅らせることで、はるかに大きなリスクが発生するか?
- 判断の意味を理解し受け入れるか?
- 今この判断を下す理由について明確な根拠があるか?
- 判断が間違っていた場合に、それを取り消す時間があるか?
- 失敗を許容できるだけのゆとりがあるか?
6.5.2 設計判断をアーキテクチャの外に移す
設計判断を後から変えるのが容易なのであれば、それはもはやアーキテクチャ上の関心事ではない。可能であれば、変更の可能性がある部分については後続の設計者が設計判断を下せるよう、アーキテクチャを設計しよう。
ソフトウェア開発における「関心事」っていう語彙、なんか好きなんだよな。英語だと Concern かな。身近なところだと moro 先輩が上手に「関心」「関心事」という語彙を使うイメージがある。
「関心」って言葉を上手に使うあたりが @moro 先輩っぽいなぁと思って安心しながら聴いている https://twitter.com/june29/status/638321088640913408 は 2015-08-31 のツイートだった。
ActiveSupport::Concern の Concern って、日本語でいうとどういう意味なんです…？ https://twitter.com/june29/status/293951612186136576
@june29 伝統的には「関心事」ですかね…? Crosscutting Concern とか Core Concern とかの訳語に使われることが多いです。 https://twitter.com/t_wada/status/293952123224330241
2013-01-23 のぼくがツイートして、それに t-wada さんが答えてくれていた…！便利！！
さっき「関心事っていう語彙が好き」と書いたけれど、ぼくのこの感覚は t-wada さんや moro さんのおかげで持てている感覚なのだろう、と思えた。先輩に恵まれすぎ。なんとありがたいことか…。後輩たちに恩送りしていきたいね…。
プログラミングから私たちが学んだ設計原則の多くは、設計原則として普遍的な価値のあるものだ。たとえば、SOLID 原則の適用はオブジェクト指向に利点をもたらしたが、アーキテクチャにも同様に多くの利点をもたらす。
SOLID 原則 は、もうページをつくっちゃおう。今後も何回も参照するだろうしね。
7 章 パターンで土台を作る
アーキテクチャパターンのお話。実例が次々に紹介される。
7.2 レイヤー (Layers) 7.3 ポートとアダプター (Ports and Adapters) 7.4 パイプとフィルター (Pipe and Filter) 7.5 サービス指向アーキテクチャ (Service-Oriented Architecture) 7.6 パブリッシュ・サブスクライブ (Publish-Subscribe) 7.7 共有データ (Shared-Data) 7.8 多層 (Multi-Tier) 7.9 コンピタンスセンター (Center of Competence) 7.10 オープンソース型の貢献 (Open Source Contribution) 7.11 巨大な泥団子 (Big Ball of Mud)
ひとつずつを楽しく眺めていたら 7.11 で急に現実が襲いかかってきて笑う。
7.12 新しいパターンを発見する
アーキテクトは、昆虫学者が新種の昆虫を発見するのとほぼ同じ方法でパターンを発見する。フィールドで過ごし、周囲の世界を観察する。そして、考えられるパターンを特定したら、それを説明し、既存のパターンと比較して分類する。発見が既存のものと似ている場合は、ブログの投稿か論文の発行を通して、既存のパターンに関する私たちの集合知にその知識を追加する。発見が新しいものだった場合には、それをチームのパターンカタログへと追加する。
パターンは「作り出す」というよりは「発見する」もの。
8 章 意味のあるモデルで複雑さを扱う
絶え間ない用心がなければ、ソフトウェアシステムは最終的に自らの成功の犠牲となる。
癌細胞じゃん…！
8.1 アーキテクチャを見通す
優れたアーキテクチャモデルには、多くの利点がある。次に示そう。
- 設計の語彙を確立する
- 関心を持つべき細部に注意を向ける
- 品質特性やその他のシステム特性を見通せる
- アーキテクトの意図を記録できる
「1 ヶ月コーディングすることで、ようやく 1 時間のアーキテクティングに相当する」。アーキテクチャの欠陥は、コードを書いたり、受け入れテストを実行したり、リリース後に顧客からの苦情をレビューしたりしているときよりも、アーキテクチャを設計しているときのほうが、より早くより低いコストで修正できる。
8.2.1 新しい概念を個体化する
好奇心サイクル、おもしろいな〜。ぼくらは好奇心によって理解や設計を進めているのかもしれない。
8.2.4 良い名前を使う
物に名前を付けるのは難しく、そして驚くほど重要だ。名前付けは設計ツールだ。 そのため、良いコードを書く際に学んできた名前付けに関する多くの原則は、アーキ テクチャにも同様に当てはまる。
Matz よろしく「名前重要」文化圏で育ってきたぼくは、今では「命名重要」という価値観も持つようになった。この 8.2.4 には共感できそう。
Arlo Belshee は、「Good Naming Is a Process, Not a Single Step」の中で、「名前づけの 7 段階(7 Stages of Naming)」について説明している。
- ステージ 1:名無し
- 名前がない状態。システムやコンテキストについて、名前付き要素を抽出するのに十分なだけのことが分かっていない。
- ステージ 2:無意味
- 名前に意味はないものの、何らかの形で関連していると考えられるアイデアの集まりを特定した状態。
- ステージ 3:的確
- 要素の責務について少なくとも 1 つを表している状態。
- ステージ 4:的確かつ完全
- 要素のすべての責務を直接表している状態。
- ステージ 5:適切な行い
- 要素の責務を進化させるという意識的な決定が名前に反映されている状態。これは、アーキテクチャの文脈における要素の役割について、より多くの知識が得られたときにのみ起こる。
- ステージ 6:意図
- 名前には要素の責務だけではなく目的も表されている。目的を理解するには、その要素に加えて、その要素の存在理由を理解する必要がある。
- ステージ 7:ドメイン抽象
- 名前は個々の要素を超えて新しい抽象概念を作成する。これがメタモデルのための新しい概念が生まれるところだ。
8.4 Lionheart プロジェクト:ここまでのあらすじ
チームメンバーの多くが、アーキテクチャ内の同じ要素を表すために異なる単語を使用している。その結果、設計についての議論は合意を持って終わるものの、後で各メンバーが異なる結論を持ち帰るだけとなっている。
コードはすでに大破した。これは、これまでに行われた設計判断に対するチームの理解不足を反映している。チームが選択したとあなたが考えていたパターンは、システム内には見る影もない。
唐突にプロジェクトがめちゃくちゃになっていてびっくりした！
9 章 アーキテクチャデザインスタジオを開く
ユーザーエクスペリエンス(UX)コミュニティは、この教えをデザインスタジオとして普及させた。デザインスタジオはグループコラボレーションを促進し、チームが短期間で幅広いアイデアを見るのを助けるために厳しい時間的制約を持っている。
デザインスタジオという概念がお目見えした。
良いファシリテーションとは、単に作法が守られることをいうのではない。物事がうまくいくようにするのが、良いファシリテーションだ。
ファシリテーションの大事な話も出てきた。
アーキテクチャデザインスタジオってやつは、ここに書かれているような説明を 10 回読むより、一度でも体験してみると理解が捗るんだろうな〜と思う。やってみたい。
9.4.2 開始前に期待を設定する
ワークショップの開始時に基本原則を設定しよう。以下に示すのは基本原則の例だ。
- 全員参加
- 「正しい」または「間違った」答えはない
- 時計を見る(私もお手伝いする)
- 時間が経ったら先に進む
- 助けが必要な場合は質問する
- (真剣に)楽しむ
10 章 設計判断を可視化する
11 章 アーキテクチャを記述する
ソフトウェアアーキテクチャの文書化は、悪名高いことで有名だ。コードを書く時間を奪うし、賞味期限が切れていることがほとんどだ。独自のバイナリファイル形式で書かれていて、手軽に編集できないことも多い。それに加え、それを読む人がほとんどいない! ソフトウェアアーキテクチャ記述(Software Architecture Description)のことを SAD と呼ぶ人がいるのも不思議ではない。
悲しい話からのダジャレが炸裂した…。
11.2 状況に応じた記述方法を選ぶ
11.2.2 共通の方法によって到達範囲をさらに広げる
共通のアーキテクチャ記述方法には、アーキテクチャ俳句(アクティビティ 21)、アーキテクチャ上明白なコーディングスタイル(「8.3 コード内にモデルを構築する」)、アーキテクチャデシジョンレコード(アクティビティ 20)などがある。
「アーキテクチャ俳句」めっちょ気になる。
11.3 聴衆に配慮する
11.5.1 選ばなかった道を説明する
ソフトウェア開発は旅だ。道は曲がりくねっていて、同じ目的地に通じる道がたくさんある。すべての分岐、すべてのあなたが下した判断は、ソフトウェアアーキテクチャがそうなった理由を理解する助けとなる。あなたが下した判断を理解する方法の一つに、選ばなかった選択肢すべてを列挙するという方法がある。
Pull Request 上でコードレビューをするときも、採用しなかった方法が記されていると安心するしレビューが捗るよな〜。これは大事だと思う。
12 章 アーキテクチャに通知表をつける
評価をプログラミング時間を奪うものだと考えるのを止めよう。代わりに、プログラミング時間をさらに強力なものにする方法だと考える。評価にかける時間はわずか 1 時間だっていいし、既存の開発プロセスの中に気付かれないよう評価を組み込むことさえ可能だ。
評価の中で学ぶ必要があるのは、「アーキテクチャはどの程度良いか?」ということと「アーキテクチャはどのように良いか?」ということだ。これらの質問に答えるため、アーキテクチャ上重要な要求(ASR)について分かっていることを使う。アーキテクチャが ASR を十分に満たしているほど、アーキテクチャはその目的を満たしているといえる。
12.4.2 さまざまな課題を探る
12.4.3 低セレモニーな評価方法から始める
高セレモニーな方法とは、形式的な決まり事で満ち、実施にコストがかかる可能性があるものだ。高セレモニーな方法は繰り返しが容易で、一貫した結果を生む。一方、低セレモニーな方法は、堅苦しくないもので、形式的な決まり事はほとんどない。低セレモニーな方法は、より早くより低いコストで実施できる。しかし、範囲は狭く、矛盾する結果を生む可能性は高くなる。
「高セレモニー」「低セレモニー」っていう語彙いいな。使っていきたい。
12.6 次にやること
アーキテクチャはチームの文化の一部だ。私たちは設計したアーキテクチャと日々を共に生きることを選ぶ。貧弱な設計で生きることは、耐え難いものになる可能性がある。アーキテクチャ評価は、アーキテクチャをより良くする方法を理解するのに役立つ。
13 章 チームのアーキテクト力を強める
現代のソフトウェアシステムにおいて、開発者とアーキテクトの違いはほとんどない。
現代のソフトウェアアーキテクトは、開発チームに向けて設計するのではなく、開発チームと共に設計を行う。今日のアーキテクトは、コーチであり、メンターであり、技術の第一人者でもある。本書では、本質的なアーキテクチャとデザインの原則について説明するところから始めた。そして、第II部を通して、それらの原則を実践に移す方法を学んだ。この章では、素晴らしいソフトウェアアーキテクチャを一緒に設計する仲間として、チームを成長させ、力を与える方法を学んでいく。
13.3.1 ペア設計
ペア作業は、設計を実践するための最も簡単で安全な方法の 1 つだ。チームメンバーと一緒になって設計作業をすることから始めよう。
いいですな。プログラミングだけじゃなくて、設計も複数人でやっていく。
13.4 設計権限を委譲する
『Management 3.0: Leading Agile Developers, Developing Agile Leaders』で、Jurgen Appelo は「権限の 7 つのレベル(The Seven Levels of Authority)」について説明している。これらを使えば、設計権限をどれだけ保持するか、そしてチームに何を委譲できるかを判断できる。
デリゲーションポーカーで見たことあるやつだ！…とか思っていたら 13.4.3 がまさにデリゲーションポーカーの話だった。
- レベル 1:指示する (Tell)
- レベル 2:説得する (Sell)
- レベル 3:相談する (Consult)
- レベル 4:合意する (Agree)
- レベル 5:助言する (Advise)
- レベル 6:尋ねる (Inquire)
- レベル 7:委譲する (Delegate)
13.6 Lionheart プロジェクト:大団円
市長は喜んでいる。開始時から仕様が変わり続けたにもかかわらず、プロジェクトは当初の予定よりわずか数週間遅れで終了することができた。正式公開前の負荷テスト中にいくつかの問題があったものの、優先度の高いすべての品質特性は実現することができた。それ以外もすべてうまくいった。
めっちょよかったじゃん！ここまで読んできたぼくもうれしく思うよ。おつかれさま。
13.7 次にやること
次にやること? 次は、素晴らしいソフトウェアを作るために学んだことを使う番だ! 第III部では、アーキテクトの旅を始めるのを助けるため、デザイン思考の 4 つのマインドセットを中心にした実用的なデザインメソッドのコレクションを紹介する。私はこれを「銀の道具箱」と呼んでいる。もちろん、この名前は Fred Brooks の論文『銀の弾などない̶ ソフトウェアエンジニアリングの本質と偶有的事項』へのオマージュだ。
日本語の文章よりも英語の文章でよく見かけるノリで 13 章が終わっていった。学んだことを使う番だ！
10 年前のソフトウェア設計の実際は、今日とは大きく異なっていた。今後 10 年でも、ソフトウェアシステムの設計方法は変わることだろう。あなたは今、未来を形作るコミュニティの一員としてそこにいる。心配しないでほしい。きっと楽しいものになる。そして、私たちはその過程で素晴らしいソフトウェアを作っていくことだろう。
いい話！
14 章 問題理解のアクティビティ
-
- たった一つを選ぶ
-
- GQMワークショップ
-
- ステークホルダーインタビュー
-
- 前提リスト
-
- 品質特性ウェブ
-
- ミニ品質特性ワークショップ
-
- POV Madlib
-
- 応答測定のたたき台
-
- ステークホルダーマップ
15 章 潜在的な解決策を探るアクティビティ
-
- アーキテクチャの擬人化
-
- アーキテクチャフリップブック
-
- CRCカード
-
- 概念マップ
-
- 分割統治
-
- イベントストーミング
-
- グループポスター
-
- ラウンドロビン設計
16 章 設計をタンジブルにするアクティビティ
-
- アーキテクチャ俳句
-
- コンテキスト図
-
- まずこれを読もうリスト
-
- モジュール分解図
-
- 学習か判断のためのプロトタイプ
-
- シーケンス図
-
- システムメタファー
17 章 設計の選択肢を評価するアクティビティ
訳者あとがき
われわれが何であるかは、われわれが繰り返し何を行ったかによって決まるのである。それゆえ、美徳は行いではなく、習慣なのである。 ── アリストテレス
謝辞
「6.5.2 設計判断をアーキテクチャの外に移す」のところで言及した moro さん、レビュアーだった…！
最後に、これまでの「… It!」シリーズの翻訳に携わってこられた方々に敬意と感謝を記します。10 年ほど前の自分にとって、『Ship It!』をはじめとする書籍たちを「今世界のどこかで、こうやったやり方や考え方で開発していっている人たちが実際にいる!」という感覚を持ちながら日本語で読めたことは、プログラマーとしての世界観を形成していくにあたって大事な経験でした。この恩送りがうまくできたかは先になってみないとわかりませんが、願わくば、ぼくがいただいたものをうまく先の人たちに繋げられていればと思っています。ありがとうございました。 2019 年 11 月 島田浩二
島田さんも「恩送り」と言っておったやんけ！！！