本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「「Design It!」書評」を再編集したものです。
はじめに
これからの業務の中でアーキテクチャ選定の知識も必要かなと考えていたところ、「こんな本があるよー」と言って教えてもらったのがこの本です。 しかしここしばらく忙しかったりクレジットカードの今月の利用上限（私はクレカ破産が心配なので普段10万円に設定してます)に引っかかったりしていてこれまで読めていませんでした。 この度年末で実家帰りして本を読む時間が作れたり利用上限が無事引き上げられたり（やっぱり不安なので来月は元に戻します）したため、書籍を購入して読むことができたので、書評して内容を共有したいと思います。
Design It!とは
皆さん大好きO’reilly本です。 原著は2017年に出版され、2019年11月に日本語の訳が出版されました。 この書籍はソフトウェアアーキテクチャのデザインについて述べられた本で、アーキテクチャを決める際の考え方から、アーキテクチャデザインを行う際の方法論まで幅広く扱われています。 これまで作っているソフトウェアやサービスのアーキテクチャについてあまり深く考えたことがなくて「あーそろそろアーキテクチャについても考えられるようになっといたほうがいいな」とか考えている方や、既にアーキテクチャを決めるような業務に携わってはいるけれどもどのように設計を行うべきかといった考え方が固まっていなくて何かしら確固とした基準を持てるようになりたい方にはぴったりの一冊だと思います。
目次
第Ⅰ部 ソフトウェアアーキテクチャ入門 ・1章 ソフトウェアアーキテクトになる ・2章 デザイン思考の基礎 第Ⅱ部 アーキテクチャ設計の基礎 ・3章 デザイン戦略を立てる ・4章 ステークホルダーに共感する ・5章 アーキテクチャ上重要な要求を掘り下げる ・6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に） ・7章 パターンで土台を作る ・8章 意味のあるモデルで複雑さを扱う ・9章 アーキテクチャデザインスタジオを開く ・10章 設計判断を可視化する ・11章 アーキテクチャを記述する ・12章 アーキテクチャに通知表をつける ・13章 チームのアーキテクト力を強める 第Ⅲ部 アーキテクトの道具箱 ・14章 問題理解のアクティビティ ・15章 潜在的な解決策を探るアクティビティ ・16章 設計をタンジブルにするアクティビティ ・17章 設計の選択肢を評価するアクティビティ
デザインマインドセットの話
この書籍は、「デザインマインドセット」という言葉を中心に展開していきます。 この言葉は本のほぼほぼ最初に出てくる言葉で、それ以降の章のアーキテクチャ設計の方法論の中心となる概念です。 これはソフトウェアシステムのアーキテクチャを設計する際の観点で、「理解」「探求」「作成」「評価」の4つがあります。 大雑把にそれぞれのマインドセットを説明すると以下のようになります。 ・「理解」のマインドセット ソフトウェアで解決しようとしているビジネス上の問題や品質特性について積極的に理解しようと働きかけるマインドセット。 ・「探求」のマインドセット より良いソフトウェアアーキテクチャを求めて探求を行おうとするマインドセット。 ・「作成」のマインドセット ドキュメントやプロトタイプといったものを作ってアーキテクチャのアイデアを積極的に人に伝えようとするマインドセット。 ・「評価」のマインドセット 今考えているアーキテクチャが問題に対して妥当かどうかを判断するマインドセット。 第Ⅱ部では、アーキテクチャのデザインの考え方について、これらのマインドセットを用いて解説されています。 そして、第Ⅲ部ではアーキテクチャデザインを行うにあたって実際にすることをアクティビティとして、マインドセットごとに解説されています。
特に有用だと思った「作成」マインドセットのアクティビティ3選
第Ⅲ部においてはアーキテクチャデザインを行うにあたって実際にやることが解説されていると書きましたが、その中で「作成」マインドセットを用いて行うアクティビティの内容はアーキテクチャデザインを説明する際に必要な作成物そのものです。 その中で、書籍を読んでいて自分が現状のアーキテクチャを説明する際にまず作っておきたいなと感じた作成物をいくつかピックアップします。
まずはこれを読もうリスト
これは、ステークホルダーや新参の開発者が現状のアーキテクチャについて素早く理解することを助けるリンク集です。 ほとんどのプロジェクトにおいてどこかしらにWiki等の形で作られているとは思いますが、ここをうまく整理、管理しておけば（書籍では「キュレーション」と呼ばれている）アーキテクチャを知るための出発点として確実な情報が提供できるため、かなり重要だと考えます。 例には「放置され気味だけどまだ使える」とか「このドキュメントは最新」といったコメントも加えられており、自分が作るときはマネしたいなと感じました。
アーキテクチャデシジョンレコード
アーキテクチャを設計してから時間が経つと、「あそこなんであんな設計になってるのだっけ？」という話をする機会が増えます。 新しい開発者が開発チームに参入してきたときや新しい要件が追加される際などはなおさらです。 その際に、過去の設計を変更するべきかどうかといった判断を迫られるわけですが、その際に有用なのがこのドキュメントです。 内容としては、設計判断ごとにタイトル、背景、内容、ステータス、影響といった項目を埋めてレコード上にしたもので、それぞれの設計判断を後から振り返りやすくすることができます。 設計判断の背景や理由、影響範囲を記述しておくことによって、将来的に設計を変更するべきかどうか判断する際にその変更を行う理由が過去の設計判断より重要かどうか比べることが出来たり、アーキテクチャの変更の履歴が追いかけやすくなったりします。 アーキテクチャについて記述するとき、普段私たちは現状の設計だけを記述しがちですが、それに加えてどんな背景や理由があったかについても記述しておくべきだと感じました。 また、書籍内ではこれをレコードとして記録するような説明がなされていました。 イメージとしては、excelのようなスプレッド形式で列ごとに背景、内容、ステータス・・・といったカラムを作るものです。 これについては、特に全体のアーキテクチャについて説明することを考えるとこの形式は網羅性としてどうなのという疑問を感じています。 私がこれを作るならば、設計判断についてレコード形式で時系列に記録するものとは別に、現状のアーキテクチャについて全体図、各部の設計、それらの背景や設計判断の理由をまとめたものを別に作るかなぁ等と考えながら読んでいました。
選ばなかった道
前述のような「アーキテクチャを変更すべきかどうか」問題を解決するもう一つの方法がこれになります。 過去に下そうとして却下した設計判断について、その理由とともに記録しておきます。 これによって、過去に却下した設計判断が後になって急にチーム内で湧き上がって採用されるような事態を防いだり、あるいは過去に却下した設計判断でも当時の背景と現状が変わったということを根拠として改めて採用するといった判断を下す際の根拠として使うことができたります。 南條 祐輝（a.k.a.なむゆ）／FIXER Fintech事業部のバックエンド担当ですがフロントエンドの仕事もしたいです。本の虫。面白い本を教えてもらうと喜びます。Azure、AWS、GCP、データベース、セキュリティ、アーキテクチャなどいろいろ書いていきたいです。この間AWS Associateに落ちたのでリベンジを狙う。ついでにｾｷｽﾍﾟも落ちたのでそっちもリベンジします。必ず！！ [転載元] 「Design It!」書評 ■関連サイト cloud.config Tech Blogのエントリー cloud.config Tech Blog FIXER