デッドライン読書会#10「Design It!」（前半）の感想文

課題図書

第10回のデッドライン読書会（デッドライン読書会とは？→読書×締切ではじめる「デッドライン読書会」を始めました）の課題図書は、「Design It! ―プログラマーのためのアーキテクティング入門」です。オライリー社から、2019年11月に翻訳・出版されました。今回は、本書の前半部分（最初〜226ページ、第１部と第２部）が範囲です。

訳者の島田 浩二さんが本書を紹介するブログのポストがありましたので、そちらのリンクも掲載します→https://snoozer05.hatenablog.jp/entry/2019/11/16/181626

感想文

今回のアウトプットもこれまでと同様に、最初に「全体」の感想を書いて、続いて気になった部分を「個別」として、引用にてコメントするスタイルで行きます。

全体

今回の読書会の範囲は、

• 第１部：ソフトウェアアーキテクチャ入門
• 第２部：アーキテクチャ設計の基礎

でした。

本書は、「チームのアーキテクト能力を高める」ことを重要視していることが特徴的なテーマだと思います。アーキテクトのロールを持つ個人がその能力を高めるためだけに本書を読むと言うよりは、チームメンバーが持つ設計力のレベルを上げるにはどういったアプローチがあるかも整理しています。序文で、George Fairbanksさんが「本書は（略）アジャイルとアーキテクチャをうまく融合させている」と言っていますし、本書原著の副題が「From Programmer To Software Architect（プログラマーからソフトウェアアーキテクトへの道）」でもある通り、「チーム」というのがキーワードであると感じました。

もう一つの特徴は設計の進め方として、デザイン思考の考え方をベースにしている点です。デザイン思考の4つの原則：

1. 人間性の規則（The human rule）
――すべてのデザイン活動は究極的には社会的な性質を持つ。

2. 曖昧性の規則（The ambiguity rule）
――デザイン思考者は曖昧性を保全せねばならない。

3. 再デザインの規則（The re-design rule）
――全てのデザインは再デザインである。

4. 触感性の規則（The tangibility rule）
――手で触れられるアイデアを作ることは常にコミュニケーションを促進する。

https://ja.wikipedia.org/wiki/デザイン思考#デザイン思考の性質

特に4番目のTangibiriltyを言及することが多かったです。アーキテクチャは設計の中でも、解像度（概要と詳細）を変え、ビューポイントを変え、（システムに対する）理解を深めていく特徴があるため、その意図を関係者が理解できるように、様々な形で触れられるようにすべきというわけです。例えば、「線と箱を使いモデルをホワイトボードにスケッチ」することや、「プロトタイプのアプリやコードを作成しデモ」することなど。また、品質特性にフィットできるアーキテクチャかどうかを早めに検証するために、多様な触覚性が求められると思います。ちなみに本書ではその一例を、後半第３部１６章に「設計をタンジブルにするアクティビティ」という章で深堀しているようです。後半戦に期待します。

個別

この個別部分では、気になった文章を引用して理解を深めようと思います。

優れたソフトウェア開発チームは機能を素早くリリースするために技術的負債を戦略的に利用する。

1.1 ソフトウェアアーキテクトが行うこと（P.7）

文字通り正しく負債を使うべしというところ。お金の増減をなだらかにすることを目的として負債を利用するように、チームの負荷やパフォーマンスを最適化する目的で技術的負債を利用しなくてはいけない。ただ惰性で借金はしてはいけない。

すべての優れたアーキテクチャは、変化の必然性に責任を持つ。

6.5 変化に向けて設計する（P.95）

身にしみます。そして、次節にて、拘束力のある判断はなるべく遅らせるというとことがポイントとなっていますね。

私たちが選ぶ名前は、設計しているものをどれだけ理解しているかを反映している。理解が深まるにつれ、概念に付ける名前も変わる。

8.2.4 良い名前を使う（P.126）

ここでは、Arlo Belsheeさんの「7 Stages of Naming（名前づけの７段階）」が紹介されていました。Twitterで原典を発見したので下記に引用します。

The 7 stages of naming, now with better image. pic.twitter.com/8BQptfV0oH

— Arlo Belshee (@arlobelshee) August 26, 2015

チームがアーキテクチャを自分たちのものにするには、（略）必要な知識とスキルを、チームへ注ぎ込もう。これがうまくいっているとき、アーキテクトは設計判断をすべて下す権威あるリーダーというよりも、コーチやメンターのように見える。

13.2 意思決定を促し、スキルの成長を促進する（P.215）

どうも「アーキテクト」とは孤高の人というイメージがありますが（なんでだろう…）、本書のイメージは上記引用の通り。

次回（#11）

スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。

• #11の候補書籍
  • Design It!（後半戦）
• デッドライン
  • #10の感想交換1Week（2/24〜3/1）
  • インターバル（※今回は前半と後半の間のため、ありません）
  • #11の読書する時間2Week（3/2～14）
  • #11のブログポスト期限（3/15）
  • #10の感想交換1Week（3/16〜22）