勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「Design It! ― プログラマーのためのアーキテクティング入門」の後半も読んだ #デッドライン読書会

後輩の年下エンジニアに突き上げられて老兵エンジニアが未消化の積読技術書を読み、感想をブログに書く企画の第11回。今回も「Design It! ― プログラマーのためのアーキテクティング入門」である。今回は残り(第3部)を2週間で読んだ。というわけで本書は読了である。やりきった。

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

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

  • 作者:Michael Keeling
  • 発売日: 2019/11/25
  • メディア: 単行本(ソフトカバー)

デッドライン読書会のルールは、以下参照

わたしのDesign It!の前半の感想はこちら

なお、訳書が発売されてはいるのだが、本ブログでは原著で読んでいる。https://learning.oreilly.com/ のサブスクはオライリーだけでなくPragmatic Bookshelfも対象なのだ。このテクニックについてはこちらの過去記事をどうぞ。アーキ部のkawasimaさんもおすすめしてた。

チーム活動としてのアーキテクティング

さて、第3部「アーキテクトの道具箱」は言葉通り、アーキテクトがアーキテクチャに関する情報収集、検討、共有するためのテクニックが列挙されている章である。

非機能要件のヒアリングとしてのテクニック

「14章 問題理解のアクティビティ」で紹介されているテクニックは、これまでの文脈で言えば要件定義における非機能要件ヒアリングに相当するのだろう。紹介されている手法はすでに知っているものも多い。たとえばGQMなどはIPAでいろいろと資料が公開されているので見てみるとよいだろう。

なお言うまでもなく、本書で扱われる手法は抽象度がとても高い。一方で日本においてはより詳細レベルのヒアリングテクニックとして、非機能要求グレードがポピュラーである。このあたりの使い分けはよく考えた方が良さそう。

チームでのアーキテクティングテクニック

「15章 潜在的な解決策を探るアクティビティ」はチーム活動としてアーキテクティングする方法という点でとても新鮮である。
自分の経験では、アーキテクチャはリードメンバーが集中して考えるものであって、チームメンバーはあくまでそのレビュアーである。しかし、本書で紹介されているテクニックの多くは、複数メンバーのグループワークとして検討を実施する形となっている。これはかなり興味深いのだけれども、どこかで素振りをしておかないと、いきなり実戦適用は難しそうな印象。

アジャイルアーキテクチャを共有するためのテクニック

「16章 設計をタンジブルにするアクティビティ」「17章 設計の選択肢を評価するアクティビティ」は、情報共有に関するテクニックとアドバイスになっている。
とくに16章はシンプルかつアジャイルに情報を共有するためのいろいろなアイデアが紹介されていて、すぐにでも活用できそう。本書の前半でも紹介されていた「悪名の高いアーキテクチャ文書」の対策でもあると思う。

ソフトウェアアーキテクチャの文書化は、悪名高いことで有名だ。コードを書く時間を奪うし、賞味期限が切れていることがほとんどだ。独自のバイナリファイル形式で書かれていて、手軽に編集できないことも多い。それに加え、それを読む人がほとんどいない! ソフトウェアアーキテクチャ記述(Software Architecture Description)のことを SAD と呼ぶ人がいるのも不思議ではない。
Design It! ―プログラマーのためのアーキテクティング入門 11章 アーキテクチャを記述する

Design It!の感想まとめ

現時点での(時代に即した)アーキテクチャ設計論としては、本書Design It! ―プログラマーのためのアーキテクティング入門Release It!: Design and Deploy Production-Ready Software (English Edition)が二代巨頭だと思っている。残念ながら後者は未翻訳ということもあるので、本書が日本語で読めるようになったというのはとても良いことだと思う。
でも、英語/機械翻訳でも、けっこう読めるけどね。