最近所属するチームが変わって"リリースされるプロダクトの品質担保"について考えている。リリースされるプロダクトということはリリースされる前のプロダクトであり、ユーザーに届く前に品質を担保せえというのが僕の考えることであると理解した。
ユーザーに届く前に品質を担保されている状態とはなにかを考えるとリリース前に客観的に「これは品質が高い！」といえる状態だと考えた。客観的に品質が高いと言えれば開発者は安心してリリースすることが出来る。
品質が高い＝想定外のことが起きない（バグが出ない）だとするとリリース前に100%これはバグがない！といえるかというとありえない気がしていて、なにをやっても結局バグは絶対出る。このあたりは僕がプログラムを書き始めるよりずっと前から考えられてきたことでなるべく想定外を潰す方法はあるにはあるらしいんだけど、ハイコストでありリリースの速度を下げることはやりたくない。なので現実的ではないですね………みたいな事になる。
結局バグが出るのであればバグをなくすことを頑張るのは"ある程度"で収めておいて、バグの影響範囲を小さくすること・バグを早く検知し元に戻すことに注力するのが安心してリリース出来ることに繋がり、ひいてはリリースされるプロダクトの品質担保に繋がるのではないかと思う。
ただそれだけやってもまだ安心とは言えないと感じていて問題は2個あると思っている。
- 品質が高い＝想定外のことが起きない（バグが出ない）はかなりいい加減な定義であること
- "ある程度"が人によって違い客観的ではないこと
最近いろんなソフトウェアテストの本を読んでいると品質が高い＝想定外のことが起きない（バグが出ない）はかなりいい加減な定義であると思った。このあたりも色々とすでに知見はあって、ソフトウェア品質特性モデルや利用時の品質特性モデル(正式な名前がわからない)というのがある。
これらの品質特性が高い状態を品質が高いと定義し品質特性をブレイクダウンして"ある程度"の基準を明確に設けて開発者(というよりプロダクトチーム全員)が参照できるようにしておくといいのではないかと考えている。
DX Criteriaみたいな、はい/いいえで選べる品質の基準が各プロダクトに決まってるとコードレビューとかリリース前とかに便利そうだけど、そういう概念ってもうあるのかな
— ひさいち (@hisaichi5518) 2022年1月9日
ちなみにエリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blogにあるようなメトリクスはリリース後に得れるものなのでここで必要なものとは別物という認識であるがこれらはリリースされたあとに分析などを行うために必要なので別途取る必要がある。その分析を行い課題を見つけることでより洗練された基準になっていくはず。
