日々の破片

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

翻訳担当の島田さんから頂いたDesign It! を読み終わって少し時間がたったが紹介する。

システムを開発するときに、どのような筋道で開発に着手するかの前段階の調査と思考の筋道を説明した本である。プログラミングそのものも設計だが、それより下位の設計（たとえばクリーンアーキテクチャのような実装設計であり、フレームワークへの適用設計である）よりもさらに下位にくる、全体の見取り図の設計、実装設計のための方向性の決定のための設計と考えると良い。アーキテクチャとしては下位だが、上流工程とも言える。上か下かは立ち位置による。以下では下とする。

内容はおれさま判断で正しい。この言語化（つまりは書籍化、結局は筆者のマイケル・キーリングのノウハウの分化と手順化）には舌を巻く。

11月の末頃いただいて、大体1か月くらいかけて通勤時の何割かと休日に読んだ。ただし、1/3強を占めるパターン集（アクティビティと本書では呼ぶ）は適宜読んでいるので別。

全体は380ページある。そのうち本文に相当するのが全体の2/3で、残り1/3はパターンカタログ（ただし本書ではアクティビティ（ワークショップで実行するための科目）としてあるし、実際に、設計での合意のためのワークショップで行うべき作業）となっている。

本文は第1部30ページ弱と、残りすべてを占める第2部（200ページ弱）で構成される。

第1部は設計という作業全体についての要約である。

第2部ではそれを分解して手順化した具体的なやるべき作業として示す。

結構読むのに時間がかかるのは、コードが無く、ほぼ文章でかつ内容が比較的抽象的（見方による。おれにとっては脳内作業なので抽象なのだが、本書は目的からワークショップでの科目なので具体作業である）なので咀嚼に時間がかかるからだが、考え方の筋道を示す図が多数入っているので難しいわけではない。

おれが読むのに時間がかかったのには2つの理由があると考えられる。

1つは、用語が多数出て来てそれらが自由自在に組み合わさるために、ある言葉がどういう意味で出てくるのか時々見失うからだ。特に重要な語句は頭語になっているのだが、結構これを忘れる。幾つかについては後述する。老化もありそうだし、ボキャブラリーが微妙に異なることにもありそうだ。

もう1つは、今となってはおれにとって瞬時に終わるようになっている設計上のポイントについて、チームでの合意形成のためのワークショップで行う内容の説明と例示として説明されていることにありそうだ。このため、自分の中でほとんど無意識に行える判断と突き合わせるのに、内的な言語化と視覚化が必要となり、そこに時間がかかったようだ。

もう1つ付け加えると、本書は、個人～数人レベルのプロダクトを対象したものではなく、遥かに大きいシステム（総員100名、10人チーム×10サブシステムくらいで、本書の範囲に3ヵ月程度を利用できるというかしなければならない規模）を想定している。本文を読む限りでは開発期間100日のうち30日を本書の範囲としているようだが、それには盛沢山に過ぎるように見える（上で書いた10チームがそれぞれで本書の内容を30日で行うとすれば帳尻は合う）。

そのため、チームマネージメント（下位設計時点なので合意形成が主眼となる）についてのありよう、つまりはワークショップ（会議では断じて無い！）が丁寧に示されている。これは現在のおれには興味がなく、考えたくもない領域だが、読む限りとても良いことを書いていると感じる。

特に重要な点というよりも、本書が正しいと考えられるのは、おれ個人の内部での合意形成（つまりはポイントポイントでのアーキテクチャ選択）の筋道と合致しているからだ。

ここまで書いた時点で疲れたので一度中断。

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