Design It!の輪読会が終わった / 実際の開発メンバーと輪読会すると効果が高い本と思った
challenge-every-monthというコミュニティで行なっていた、Design It!の輪読会が終わりました。
Design It! ―プログラマーのためのアーキテクティング入門
- 作者:Michael Keeling
- 発売日: 2019/11/25
- メディア: 単行本（ソフトカバー）
まだ、全体振り返り＆打ち上げの意味を含めた、座談会を残していますが、Design It!を読んで＆輪読会を経て、とくに自分が記憶に残った学びや気づきをメモしておきたいと思います。
輪読会について
輪読会の「輪読1」は
数人が一冊の本をかわるがわる読んで解釈し意見を交わすこと。
と言う意味です。
今回、自分が輪読会に参加したのは、以下の理由からです。
- 読破するモチベーションを高める
- 理解を深める（1人だと理解が曖昧なところを、他人と意見を交わすことで深掘りできる）
会社でも輪読会を実施されているところがあるようです。
実施方法
以下のような形で実施しました。
- 参加人数 ... 5人
- 読書ペース ... 1章/週
- 使用ツール ... Slack / Zoom / Jamboard / Google Slides
輪読会メンバーに感謝
輪読してくれるメンバーがいることで、議論が発生・理解が深まりました。本当にお疲れ＆ありがとうございました！
（以下、輪読会に参加された方のブログリンクです）
- よしたく blog ... 最近、Azureの記事が多いイメージ
- 脱脂綿｜note ... グラレコがとても参考になった
- 継続は力なり ... AWSと筋肉
- もがき系プログラマの日常 ... 最近、Nuxt系の記事が多いイメージ
Design It!について
読もうとした理由
なぜこの本を読もうと思ったかの理由は以下です。
- プロダクト開発において、詳細設計・開発だけでなく、ステークホルダーとどのように関われば良いかの指針を知りたい
- チーム開発において、設計の判断をどのように記録・インデックス付けするかを知りたい
学び・気づき
いますく実践できるということに着目し、学び・気づき点を記載します。
ステークホルダーには、開発チームも含まれる
「4章 ステークホルダーに共感する」では、ステークホルダーは誰なのか？解決すべき問題をどのように話し、設計を始めるのか...ということを教えてくれています。
本章にて、ステークホルダーは「ソフトウェアに興味関心を抱く人たち」と定義されている。ステークホルダーには、実際に使用するユーザーはもちろん、開発チームも含まれています。
なぜ、開発チームがステークホルダーに含まれるのか？
それは、品質特性・トレードオフ・技術的負債を議論するために必要な、ビジネス目標（ソフトウェアを使って、何を達成したいか）を定義するためです。
ビジネス目標の例（社内システムを使い、売り上げをたてるイメージ）
| ステークホルダー | ビジネス目標 |
|---|---|
| ユーザー | 担当業務の効率化、利益向上 |
| 開発チーム（改善） | 要求分析〜リリースまでの時間短縮 |
| 開発チーム（新機能） | 保守しやすいアーキテクチャ設計 |
ユーザー・開発チームに限らず、ソフトウェアに関わる人々をステークホルダー、ビジネス目標を定義することにより、何をどのような優先度で開発を進められる...という点が学びとなりました。
手法「ステークホルダーマップ」
ステークホルダーを洗い出し＆視覚化する手法として、「ステークホルダーマップ」という手法が紹介されていました。
アーキテクチャを記録する「アーキテクチャデシジョンレコード(ADR) / アーキテクチャ俳句」
11章「アーキテクチャを記述する」では、アーキテクチャを明文化し、チームメンバーへアーキテクチャを伝えるマインドや手法が紹介されていました。
印象的だったのは、以下の手法です。
| 手法 | 概要 | 参考資料 |
|---|---|---|
| アーキテクチャデシジョンレコード(ADR) | アーキテクチャの意思決定を記録する | Architecture Decision Records導入事例 | Fintan アーキテクチャの意思決定を記録する Lightweight Architecture Decision Records について - Tbpgr Blog |
| アーキテクチャ俳句 | アーキテクチャの重要部分を1枚絵に収めて説明する | Architecture Haiku |
のような運用方法が推奨されています。アーキテクチャ俳句を読むことで、全体像(またはアーキテクチャの重要部分)を理解、詳細はADRを辿る...というような導線ですね。
「どのような歴史を辿り、今のアーキテクチャに至ったのか？」「なぜAというFWを採用し、Bを選ばなかったのか？」というアーキテクチャの歴史を知ると、（とくに参入時期の浅いメンバーの）アーキテクチャへの関心と理解が深まり、今後どのような設計にすべきかも考えやすくなります。
アーキテクチャの歴史は、自分の経験上、以下のような方法で知ることが多いです。
- ドキュメンテーションツール(DocBase/esa/etc...)
- チャットコミュニケーションツール(Slack/Chatwork/etc...)
- GitHubのPR/Issue
- 息の長いエンジニアさん（先輩）から聞く
上記は理解の個人差が発生してしまいますが、アーキテクチャ俳句 x ADRの手法を用いることで、「アーキテクチャの歴史」理解を平準化の方向に持っていける...という点が学びでした。
おわり
座談会でさらなる気づきも得られると思いますが、とりあえずここまでです。
Design It!は、実業務がアーキテクトではなくても（プログラマーであっても）、個人からでも始められることが書いてありました。
しかし、実際の開発(会社)のメンバーでDesign It!の輪読会を行うと、アーキテクトの考えをメンバー全体で咀嚼・実践でき、効果が高いと感じました。
もし、今からDesign It!を読もうと思っている方がいらっしゃいましたら、ぜひ開発メンバーを誘い、輪読会またはディスカッションの場を設けることをお勧めします。
