この記事は株式会社要 cavacanチーム Advent Calendar 2024 6日目の記事です。
Design It! ―プログラマーのためのアーキテクティング入門
設計をしたことがある／設計をすることになった／設計に興味がある人にはぜひ読んでほしい本です。
チームで設計をして評価するということについて本書に書いてある内容をこの記事ではまとめました。
ソフトウェアアーキテクトになる
役職として「ソフトウェアアーキテクト（ソフトウェアの設計をする人）」を肩書きに持っている人がチームにいないとしたら、チームメンバーであるあなたはその役割を担う必要があります（あるいはすでに担っています）。
あなたが「ソフトウェアアーキテクト」なら、チームメンバーに設計の理解と適切なタイミングでの教育活動を行うことがプロジェクトの成功に役立ちます。コードを書く時間は減っていきますが、コードを一切書かないアーキテクトにはならないのがオススメです。
アーキテクチャデザインスタジオを開催しよう！
チーム全員でワークショップ形式のアーキテクチャ設計を行うのはどうでしょうか。これをアーキテクチャデザインスタジオと呼びます。
設計に対する合意を形成し、チームコミュニケーションを形成することができます。
ワークショップは早く、効果的で、楽しいものにすることでこれを達成します。
典型的なワークショップは数時間から1日あれば十分ですが、準備には時間がかかります。想像より大変になる可能性がありますが、頑張りましょう。
本書にはヒントがたくさん紹介されています。
また、対面で行う必要はありません。ツールを活用したり時間配分に気をつけることでリモート開催も可能です。
デザインスタジオの次にやること
アーキテクチャデザインスタジオに参加したメンバーは設計に対して自主性と責任感を促進します。
ワークショップは強力ですが、それだけでは不十分です。
設計はタンジブル（目で見て、手で触れる状態）であるべきです。
チームメンバーだけでなくステークホルダーにも共有していくために、適切な形で設計を可視化していきましょう。
設計に通知表をつける
設計を評価する時間はプログラミング時間を奪うものではありません。
「どの程度良いか？」「どのように良いか？」という基準で評価してみましょう。
どの程度良いか？評価の手順
まずは設計を評価可能な形にします。
それはホワイトボードに書かれたスケッチかもしれないし、ソースコードかもしれないし、draw.ioのような作図ツールで描画されたものかもしれません。
次に、設計上重要な要求についてステークホルダーの観点から見てどの程度良いかを確認していきます。
求められている品質特性を理解している必要があります。
開発者が良いと考えているものがステークホルダーにとっても良いとは限りません。
例えば、「改善が必要」「良い」「とても良い」「最も良い」のような尺度で評価していきます。
どのように良いか？評価の手順
どの程度良いかの評価基準を分析していきます。
「改善が必要」なら、具体的にどう改善するかを決めていきます。「最も良い」でも、改善できる点はあるはずです。
リスクや未解決の問題を探し、ディスカッションをします。この段階で、わたしたちは設計の傾向を知ることが出来ます。
最後に、特定された課題について優先度を決めて対応の分担をしていきます。ここまでで評価が終わります。
この流れは議事録としてまとめ、設計手順の記録として残しておきましょう。
まとめ
アーキテクチャには0点も100点も無く、全体を一度に評価することもできません。
設計したあとの評価までチームで出来たら良い経験になりそうですね。
記事に書いたように、理論的な話だけでなくチームで実践できるワークショップのガイドも充実しています。
本書はオライリーの中でも読みやすい方だったと思います。ぜひ読んでみてください。
次回のアドベントカレンダーは @matsujunjun さんの「スクラム 仕事が4倍速くなる"世界標準"のチーム戦術」です。