祐輝(a.k.a.なむゆ)はじめにこれからの業務の中でアーキテクチャ選定の知識も必要かなと考えていたところ、「こんな本があるよー」と言って教えてもらったのがこの本です。ここしばらく忙しかったりクレジットカードの今月の利用上限(私はクレカ破産が心配なので普段10万円に設定してます)に引っかかったりしていてこれまで読めていませんでした。この度年末で実家帰りして本を読む時間が作れたり利用上限が無事引き上げられたり(やっぱり不安なので来月は元に戻します)したため、書籍を購入して読むことができたので、書評して内容を共有したいと思います。It!とは皆さん大好きO’reilly本です。原著は2017年に出版され、2019年11月に日本語の訳が出版されました。この書籍はソフトウェアアーキテクチャのデザインについて述べられた本で、アーキテクチャを決める際の考え方から、アーキテクチャデザインを行う際の方法論まで幅広く扱われています。これまで作っているソフトウェアやサービスのアーキテクチャについてあまり深く考えたことがなくて「あーそろそろアーキテクチャについても考えられるようになっといたほうがいいな」とか考えている方や、既にアーキテクチャを決めるような業務に携わってはいるけれどもどのように設計を行うべきかといった考え方が固まっていなくて何かしら確固とした基準を持てるようになりたい方にはぴったりの一冊だと思います。設計の選択肢を評価するアクティビティデザインマインドセットの話この書籍は、「デザインマインドセット」という言葉を中心に展開していきます。この言葉は本のほぼほぼ最初に出てくる言葉で、それ以降の章のアーキテクチャ設計の方法論の中心となる概念です。大雑把にそれぞれのマインドセットを説明すると以下のようになります。「理解」のマインドセットソフトウェアで解決しようとしているビジネス上の問題や品質特性について積極的に理解しようと働きかけるマインドセット。「探求」のマインドセットより良いソフトウェアアーキテクチャを求めて探求を行おうとするマインドセット。「作成」のマインドセットドキュメントやプロトタイプといったものを作ってアーキテクチャのアイデアを積極的に人に伝えようとするマインドセット。「評価」のマインドセット今考えているアーキテクチャが問題に対して妥当かどうかを判断するマインドセット。第II部では、アーキテクチャのデザインの考え方について、これらのマインドセットを用いて解説されています。第III部ではアーキテクチャデザインを行うにあたって実際にすることをアクティビティとして、マインドセットごとに解説されています。第III部においてはアーキテクチャデザインを行うにあたって実際にやることが解説されていると書きましたが、その中で「作成」マインドセットを用いて行うアクティビティの内容はアーキテクチャデザインを説明する際に必要な作成物そのものです。その中で、書籍を読んでいて自分が現状のアーキテクチャを説明する際にまず作っておきたいなと感じた作成物をいくつかピックアップします。これを読もうリストこれは、ステークホルダーや新参の開発者が現状のアーキテクチャについて素早く理解することを助けるリンク集です。ほとんどのプロジェクトにおいてどこかしらにWiki等の形で作られているとは思いますが、ここをうまく整理、管理しておけば(書籍では「キュレーション」と呼ばれている)アーキテクチャを知るための出発点として確実な情報が提供できるため、かなり重要だと考えます。例には「放置され気味だけどまだ使える」とか「このドキュメントは最新」といったコメントも加えられており、自分が作るときはマネしたいなと感じました。アーキテクチャデシジョンレコードアーキテクチャを設計してから時間が経つと、「あそこなんであんな設計になってるのだっけ?」という話をする機会が増えます。新しい開発者が開発チームに参入してきたときや新しい要件が追加される際などはなおさらです。その際に、過去の設計を変更するべきかどうかといった判断を迫られるわけですが、その際に有用なのがこのドキュメントです。内容としては、設計判断ごとにタイトル、背景、内容、ステータス、影響といった項目を埋めてレコード上にしたもので、それぞれの設計判断を後から振り返りやすくすることができます。設計判断の背景や理由、影響範囲を記述しておくことによって、将来的に設計を変更するべきかどうか判断する際にその変更を行う理由が過去の設計判断より重要かどうか比べることが出来たり、アーキテクチャの変更の履歴が追いかけやすくなったりします。アーキテクチャについて記述するとき、普段私たちは現状の設計だけを記述しがちですが、それに加えてどんな背景や理由があったかについても記述しておくべきだと感じました。書籍内ではこれをレコードとして記録するような説明がなされていました。イメージとしては、excelのようなスプレッド形式で列ごとに背景、内容、ステータス・・・といったカラムを作るものです。これについては、特に全体のアーキテクチャについて説明することを考えるとこの形式は網羅性としてどうなのという疑問を感じています。私がこれを作るならば、設計判断についてレコード形式で時系列に記録するものとは別に、現状のアーキテクチャについて全体図、各部の設計、それらの背景や設計判断の理由をまとめたものを別に作るかなぁ等と考えながら読んでいました。前述のような「アーキテクチャを変更すべきかどうか」問題を解決するもう一つの方法がこれになります。過去に下そうとして却下した設計判断について、その理由とともに記録しておきます。これによって、過去に却下した設計判断が後になって急にチーム内で湧き上がって採用されるような事態を防いだり、あるいは過去に却下した設計判断でも当時の背景と現状が変わったということを根拠として改めて採用するといった判断を下す際の根拠として使うことができたります。祐輝(a.k.a.なむゆ)Fintech事業部のバックエンド担当ですがフロントエンドの仕事もしたいです。面白い本を教えてもらうと喜びます。Azure、AWS、GCP、データベース、セキュリティ、アーキテクチャなどいろいろ書いていきたいです。associateに完全勝利しました。春のIPAはDBS受けます。2020-02-17やっぱり作りながら学ぶのが一番だと思うの。Days%d人のブロガーが「いいね」をつけました。