皆さんこんにちは。虎の穴ラボのY.Fです。
先日、株式会社オライリー・ジャパン様から発刊された『Design It! プログラマーのためのアーキテクティング入門』を読んだので、感想を書いてみたいと思います！
(過去の書評はこちら) toranoana-lab.hatenablog.com
なぜ読んだのか
はじめに、今回紹介している『Design It!』はUIデザインの本ではなく、ソフトウェアの設計の本です。
普段直接的なプログラミングの本や、フレームワークの本などは読みますが、意識して本を選択しないと偏りが発生しがちと感じます。
弊社ではオライリーの年間定期購読に申し込んでいます。これを活かして、設計絡みの本を読んでみようと思ったのが発端です。
目次
本書の目次は以下になります。
(より詳細な目次は以下を御覧ください) www.oreilly.co.jp
目次
第Ⅰ部 ソフトウェアアーキテクチャ入門 1章 ソフトウェアアーキテクトになる 2章 デザイン思考の基礎 第Ⅱ部 アーキテクチャ設計の基礎 3章 デザイン戦略を立てる 4章 ステークホルダーに共感する 5章 アーキテクチャ上重要な要求を掘り下げる 6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に） 7章 パターンで土台を作る 8章 意味のあるモデルで複雑さを扱う 9章 アーキテクチャデザインスタジオを開く 10章 設計判断を可視化する 11章 アーキテクチャを記述する 12章 アーキテクチャに通知表をつける 13章 チームのアーキテクト力を強める 第Ⅲ部 アーキテクトの道具箱 14章 問題理解のアクティビティ 15章 潜在的な解決策を探るアクティビティ 16章 設計をタンジブルにするアクティビティ 17章 設計の選択肢を評価するアクティビティ
本の概要
本書は全体を通して三部構成で書かれています。
第Ⅰ部では読者が初めてソフトウェアアーキテクトになったときどうすれば良いのか、デザイン思考を絡めて説明されます。第Ⅱ部では実際にどう考えてどう行動すれば良いか、仮想の『Lionheart』というプロジェクトをすすめる形で説明されます。第Ⅲ部では、第Ⅱ部で出てきた各手法の詳細な説明と完成例が説明されます。
副題にもあるように本書はソフトウェアの設計とアーキテクチャの本になります。ただし、よくある詳細設計やDB設計にフォーカスした本ではなく、より大局的にアーキテクチャとそれに伴う設計について書かれた本になります。
最近ではクリーンアーキテクチャがよく話題に上がると思いますが、本書ではそれらも含んだアーキテクチャの選定及び、選定するときに何が大事でどのようなワークを行えば良いのかがしっかり書いてあります。
一般的に、設計というとWikiやエクセルやワードにDB設計を書いたり、構成図などを書いたりなどのイメージを持っている方も多いと思います。本書で触れられている設計作業はそれらにとどまらず、ソフトウェアの特性を決める品質特性とはなにか、その品質特性を洗い出し決めるにはどうすればいいか、各ステークホルダー(顧客だけでなく開発メンバーも含む)とどうやって協調作業すればいいかまで書かれている本です。
以下では全体の感想について述べたあと、気になった章について軽く触れていきたいと思います。
全体の感想
上記の本書サイトに書いてあるとおり、新人アーキテクトや設計をレベルアップさせたいエンジニアにはおすすめできる本だと感じました。単純にDB設計を向上させたい、オブジェクト指向設計を向上させたいなどではなく、どうすれば設計判断や、技術的な判断を上手く行って行けるのかなどの点についても数多くの示唆を与えてくれる本だと感じました。一概に巷で騒がれているアーキテクチャが良いとする本ではなく、ソフトウェアが満たさなければいけない特性からどうアーキテクチャを考えていけばいいかを与えてくれる本です。
また、自分は引退まで手を動かす立場で居たいと思っている方は多いと思います。私もどちらかというとそういうタイプです。そうしたときに、本書のような、マネージャー層が行うような設計や、要件定義のための本が必要ないかというとそうではないと思います。
プログラマーである以上は本書に書いてあるような設計作業に、大なり小なり携わることはあるはずです。そうしたときに、リーダーたるマネージャーやアーキテクトが何を考えていて、何をしようとしていて、何を欲しているのか考えるために必要となる本だと思いました。そうした思考や考え方で自分の設計レベルも向上させられるのではないかなと思います。
メインで設計する人もそうでない人も是非読んでみてください！
1〜2章 ソフトウェアアーキテクトになる、デザイン思考の基礎
第Ⅰ部である、1,2章では読者がチームのアーキテクトになったらどうすればいいか、どのように考えていけばいいかをデザイン思考に基づいて説明されています。
デザイン思考の鉄則として以下4つが挙げられていました。
- 人間性の規則
- 曖昧性の規則
- 再デザインの規則
- 感触性の規則
特に3つ目の 再デザインの規則 については『設計とは再設計である』として、度々出てくるのもあって印象に残りました。今ある設計は過去誰かが行っているはずで、それを元に改善したほうが良いと言うのは、車輪の再発明などとも通じる考え方で納得できます。
4章 ステークホルダーに共感する
ステークホルダーと言われるとお客様とかちょっと偉い人を想像しがちですが、本書で言われるステークホルダーは作ろうとしているソフトウェアに関わる人全般をステークホルダーとしています。
本章ではステークホルダーに共感することで、各ステークホルダーがそのプロジェクトで何を目的とし、何を達成したいのか整理する方法が紹介されています。
お客様の成功と、チームメンバーの成功を同列に扱っており、色々考えさせられました。
5章〜6章 アーキテクチャ上重要な要求を掘り下げる、アーキテクチャを選ぶ
この章では本書を通して度々言及される『品質特性』に対する掘り下げとそれに従うアーキテクチャ選定について書かれています。
後の章で出てきますが、品質特性は『制約』とは別のものです。どちらかと言うと『非機能要件』に近いものとなります。
品質特性は強くアーキテクチャ設計に関わるため、数ある品質特性を洗い出し、どの品質特性の優先度が高いか決めるための方法なども書かれています。
5,6章で特に良かったなと思う部分は、流行っているからや、良さそうだからでアーキテクチャを決めるのではなく、ステークホルダーと決めた品質特性を担保するために正しいアーキテクチャを選ぶ道標が書かれている点です。
アーキテクチャ以外の選定もこの視点は忘れないようにしたいと思いました。
13章 チームのアーキテクト力を強める
設計の本で設計が終わったあとの引き継ぎまで書いている本は珍しいと思いました。
この章を読むことで、アーキテクト以外の人も自分が将来的にどう動いていけばいいか、考える一つの指針になると思います。
基本的にはアーキテクト側が開発者に展開する方法が書いてありますが、開発者側が読んでも、では自分はアーキテクトに対してどうアプローチして行けば良いのか、各ワークでどう動けば良いのかなど考えることができると思います。
16章 設計をタンジブルにするアクティビティ
特にアクティビティ26の『選ばなかった道』についてはあまりやって来てないなぁと思いました。
細かい議事録などに関しても、決まったことにフォーカスしがちで、それ以外がなぜ却下されたのかなどちゃんとまとめていることは稀だなと思いました。
一方で、後でプログラムやシステムの構成を見返すとなんでこうしたんだっけ？となることは多いので、そういうときのためにもこの選ばなかった方法を何かしらの形で残しておくというのは大事かと感じます。
P.S.
虎の穴では一緒に働く仲間を絶賛募集中です！ 興味のある方は是非採用サイトを御覧ください！ yumenosora.co.jp
