【感想】Design It! - プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

前提

この書籍はいわゆるコンピューターサイエンスの技術的な話ではない。

対話を通してチームとともにアーキテクチャづくりをする本だ。そのため、アーキテクチャの理論本ではない。

本質

現在のソフトウェアアーキテクトは、開発チームに向けて設計するのではなく、開発チームと共に設計を行う(第13章)

一貫して、上記の内容を伝えているように思う。

指針

アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みし過ぎた設計（BDUF=Big Design Up Front)をしないということだ。 ... 省略... DBUFはよくないとしても、NDUF(No Design Up Front)はあまりにもリスクが高い。私たちは、ENUF(Enough Design Up Front)を目指しているのだ。

人の活動としてアーキテクチャづくりにアプローチしている

過剰でもまったくやらないでもない、ちょうどいい落としどころを探究する。チームの活動としてアーキテクチャづくりをしていくことが重要である。

留意事項

最良のアーキテクチャは文脈によって変わる

プロダクトの市場環境やチームの状況によって変わる。大規模向けのアーキテクチャをスタートアップに適用するとミスマッチになるリスクが高まる。例えばマイクロサービスアーキテクチャ。

ソフトウェアアーキテクトとは

リーダーでありコーチのような立場。チームの成熟度によって振る舞いを変えていく。

つまり、チームの成長に合わせて段階的に自身のふるまえを変えていく。

未熟なチームではリーダーシップを発揮。メンバーを育てていく立場に近くなる。いわゆる「牽引する、教える」に近い。

成熟し始めたチームには、サーバントリーダーシップとしての振る舞いが良い。いわゆる「支援する」に近い。

もしかしてSL理論に近い？

アンチパターン

アーキテクトの象牙の塔

デザイン思考の4つの原則

図解してみた。

感想

書籍には多数のアクティビティ（ワークショップ）が記載されている。

アクティビティのカタログとして、職場のデスクにぜひ1冊置いておきたい書籍だ。もしかしたら、今やろうとしているデザインレビューやアーキテクチャづくりで使えそうなGoodなやり方が見つかるかもしれない。

開発チームでアクティビティカタログについて共有する場を設けると良さそうだ。従来のやり方からよりよい手法に変えていく。より開発チームでともに考え、ともにつくる方向に進めるにはとても参考になる。

これまで私が業務で作成してきたアーキテクチャの検討資料やワークショップのいくつかはこの書籍で掲載されていた。われわれの実践で使われているものも集合知として書籍に集約されている印象を受けている。

従来は一子相伝的に資料やワークショップの進め方を学んだり、先輩のやりかたを真似たりといった俗人化的手法が一般的だったように感じる。

これからは、この本とともにチームに伝承していくと良さそうだ。私自身の知見をいち早く後進の人たちに伝えられ、私が知らなかった手法でさえも把握していく。想像を超えるチームに育っていくことを期待したい。

われわれが何であるかは、われわれが繰り返し何を行ったかによって決まるのである。それゆえ、美徳は行いではなく、習慣なのである - アリストテレス