ソフトウェアアーキテクチャメトリクス - Forkwell Library #44に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第44回目では『ソフトウェアアーキテクチャメトリクス - アーキテクチャ品質を改善する10のアドバイス』を取り上げます。 本書では、アーキテクチャが目標にどれだけ合致しているかの計測、追跡すべき適切なメトリクスの選択、可観測性/テスト容易性/デプロイ可能性を向上させる方法、アーキテクチャに対する取り組みの優先順位付け、学びに満ちた適切なダッシュボードの構築などを解説しています。

今回は訳者の島田浩二氏をお招きし、書籍に登場するメトリクスやその背景にあるソフトウェアアーキテクチャやソフトウェア品質の考え方、計測をアーキテクチャ上の決定に活かす方法などを紹介しながら、ソフトウェアアーキテクチャメトリクスの基礎について解説していただきます。

会の様子

講演〜ソフトウェアアーキテクチャメトリクスの基礎〜

書籍概要

経験豊かな10人のアーキテクトが知っておきべきメトリクスをケーススタディとともにまとめた本で、2022年6月に原著が発売されたという話がありました。

ただし、本書はアーキテクトの今現在の関心事への取り組みが書かれている本であり、ソフトウェアアーキテクチャメトリクスというタイトルに惹かれすぎると、期待からずれてしまい失敗するということです。

本書の補助線1〜SQuBOK〜

ソフトウェアアーキテクチャメトリクスは品質の計測に関する本であり、品質マネジメントの知識体系であるSQuBOKの品質マネジメント(品質計画/品質保証/品質管理/品質改善)を知ったうえで本書を読むとよいという話がありました。

ソフトウェアアーキテクチャプロセスは品質マネジメントにあると島田さんは考えているそうで、プロセス品質/内部品質/外部品質/利用時の品質をそれぞれ保証するために計測と評価を行うのがメトリクスの役割であるという話がありました。

また、SQuBOKでは、定義された測定方法および測定尺度としてメトリクスは定義されており、製品やプロセスの品質を定量的に把握し、継続的に改善するために用いるもので測定することは目的でないと記載されているそうです。

本書の章自体も、全ての章に関して品質にまつわるトピックが書かれているということです。

本書の補助線2〜アジャイル品質パターン〜

QA2AQの文脈でアジャイル開発プロセスへの品質保証の考え方および活動の組み込みの核心となる活動や考え方をパターン形式でカタログ化したものがアジャイル品質パターン*1も本書の補助線になるという話がありました。

QA2AQはアーキテクトたちが継続的にアーキテクチャ改善していこうとしているプロセスと近しいものを島田さんは感じるということで、例えば「品質のインテグレート」パターンは進化的アーキテクチャや継続的アーキテクチャの実装と読むことができたり、「システム品質ダッシュボード」の話を実装したのが1章だと捉えたりすることもできるそうです。

他にも、プロダクト品質チャンピオンパターンはアーキテクトが果たす役割として捉えることもできるだろうということで、アーキテクトはQAに品質を任せきりにするのではなく、システムの品質保証や品質改善の取り組みを推進していることが重要だということでした。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を常体かつ一問一答形式で記載していきます。

プライベートビルドの章があまり理解できなかったのだが、マイクロサービスでサービスが分離している場合、すべてのマイクロサービスをローカルでビルドし、追加機能に対して全てのサービスを通してローカルで動作確認する必要があるということか？

この章は2つ話がある。

1つ目は、CI/CDが正しいみたいな話はあるが、もしそれでプロセスのメトリクスが落ちるならそういうやり方に縛られずにプライベートビルドしようという話。

2つ目は、プロセス品質を計測するための実例。

機能要件も品質要件も不明確な状態でアーキテクチャ設計と品質設計をバラで進めるコツや並列で進めるコツは？

まずは機能要件と品質要件を明確にすることから初めたほうがよいのではないか？と思う。もちろん大体こんな感じかな？とアーキテクチャ設計はするが、機能要件と品質要件が不明確な状態でできることはたかがしれている。

多様なメトリクスから組織や案件に応じて柔軟に「何の手札を使うと妥当な品質判断ができるか？」を考えるのが難しいのだが、アドバイスはないか？

6章や10章は一つの回答になるのではないかと思う。

メトリクスはゴールありきなので、メトリクスが手札として多いけれどゴールが決められないと言うなら、経営層も巻き込んでゴールを決めていく必要がある。

ゴール&ストラテジ入門なども参考書籍としておすすめ。

品質チャンピオンを作り上げるためのアプローチは？

自分たちのプロダクトに対する品質ってみんな気になるんじゃないか？とまずは思う。プロセスが人を作ることを考えると、DevOpsの実践やSREに学ぶことが大切。エラーバジェットを考えるプロセスなどから考えられるとよりよい。

Clean Architectureの次に読む本としてソフトウェアアーキテクチャメトリクスはおすすめできるか？

これまで読んできた本がわからないのでなんとも言えないが、Clean Architectureとメトリクスは距離が遠い気はする。たくさん本を読んでほしい。

ソフトウェアアーキテクチャメトリクスは様々なトピックがあって面白かったが、具体的に何かアクションするというところに繋ぐことが難しかった。どこから始めるといいか？

1on1でならもっと話せそうだが、まずは自分たちが何を目指しているんだっけ？みたいなことを考えるところから始めてそこに向かってやるとよいかも。3章は今すぐにでも実践できそう。

メトリクスを収集しているが機能開発に追われて活用や改善ができていない。どうしたらいいか？

何かしらは変えていくところから入らないとメトリクス収集自体も負債になってしまうので、早めに何かしら改善をしないと、なぜ取っているんだっけ？という話になる。

管理職とのコミュニケーション不足とかもありえるかも知れない。

メトリクスのアラートに対して担保したい品質特性などを明記することでアラートの存在意義を明確にするアプローチを適応度関数の概念を基に実践しているのだが、適応度関数を初めから定義するのに良いアプローチがあれば知りたい

SLOスタックとかの事例などから考えることができるかもしれない。

本書はSREにもおすすめの内容か？

SREではない人や内部品質に抱えている問題を理解するためには使えるかもしれない。

一番翻訳が難しかった章はなにか？楽しかった章はなにか？

2章が難しく、ストーリー調である6章が楽しかった。

プロダクト品質チャンピオンってどのように取り組んでいるのか？(品質保証部門などが存在する組織を想定)

QA2AQなどが大切であるという世界観をわかって貰ったうえで、皆でプロダクト品質チャンピオンの各領域をサポートし合ったり、できそうな人がいるならその人が担うことになるのだと思う。

会全体を通した感想

書籍はざっと読んだのですが、たしかにメトリクスがたくさん紹介されている本だと思って手に取るとGapが大きそうだったので、今回の講演は本を買うか悩んでいる人にとっては非常によかったのかなあと思いました。

質問は普段以上に具体的な質問も多く、メトリクス関連でみなさんがいろいろな実践をされていたり関心を持っているんだなあということが想像できて面白かったです。(特に適応度関数の実践例は面白かったです)

*1:中核パターン/品質のアジャイルなあり方/品質の特定/品質の可視化で構成