リリース判定の基準はどうしたらいいのか

nsk917

はじめに

結論から言えば「自信を持ってリリースできる状態になったらリリースをする」です。
文脈は、Webサービスでのアジャイル（スクラム）開発になります。
あと、なにかを言っているようでなにも言っていない内容になっているかも知れません。予めご了承を。

書こうと思ったきっかけ

こちらのt-wadaさんの素敵な記事を読んでいる最中に、なんかこう、色々繋がった感覚を覚えて、そのふわっとしてる気持ちを整理したくなりました。

2019年の後半、キャリアのスタートとなった頃と同じQA担当になり、改めて「品質ってなんだろう？保証ってなんだろう？」と考えることが当然ながら増えました。そんななか「品質とは誰かにとっての価値である」という考えが個人的には一番しっくりきました。
そして「リリースはどんな状態になったら出来るのか？」と考えていたら「自信を持ってリリースできる状態になったら」なんじゃないかという結論に至ったという感じです。

自信を持ってリリースできる状態になったら

開発しているプロダクトに依ると思いますが、○○なバグさえ発生しなければ他は別にどうでもよかったり、反対に1秒でも止まってしまうとダメだったり、パフォーマンスは悪くても確実にデータのCRUDが成功すればよかったり、様々あると思います。
さらに、リソース（人、金、物）は有限であり、ビジネスのために新たな機能や体験の追加や改善をし続けていく必要もあり、どこかで折り合いをつけなければならない場面に出くわすこともあるかと思います。

折り合いをつける、というのは妥協をするとも言え、そこにはなにかを諦めるようなネガティブなニュアンスが含まれます。
そんなとき、自信の拠り所になるなにかがあれば、おそらくきっと、祈りながらリリースをする、なんてことはなくなっていくはずです。

（下記は素敵な記事からの抜粋）

毎回爆弾処理のようにリリースしたくはありません。 自信を持って動くコードに手を入れ続け、競争力を高め続けられるようなソフトウェアを、私たちは作りたいのです。
(中略)
触らなくていいソフトウェアよりも、積極的にかつ自信を持って触り続けられるソフトウェアの方がずっと価値があるのです。

自信を持ってリリースできる状態になったらリリースしたらいい、と考えるようになってしばらくしてから、上記の記事に書かれてあった言葉と出会い、「あぁ、やっぱりそうなんだよなぁ」と共感とともに点と点が繋がった感覚を覚えました。

自信を持って、ってどういうこと？

『自信を持ってリリースできる状態になったら』で書いたようにプロダクトの領域やサービスの性質に依りますし、不具合の検出率などのメトリクスを使って自信を持つ組織もあるとは思います。
つまり、どうなったら自信が持てるようになるのかを考え、その状態を目指し、キープし、さらに高め続けていくことが大事だと感じています。

自信を持つのは誰なのかといえば、チームの関係者全員です。
プログラマー、テスター、デザイナーはもちろん、プロダクトマネージャー（またはプロダクトオーナー）やアナリストなどプロダクト開発に関わるすべてのメンバーがそれぞれ自信を持てたほうがいいと思っています。
また、各メンバーや役割だけでなく、チームとしても自信を持てるなにか（自信の拠り所）があるといいのではないかとも思います。

そのためにやったほうが良さそうなことを挙げておきます。

・やらないことを決めて合意しておく
タスクの実施中、追加で対応すべきかどうか微妙な気づきがあったとき、やらないことに分類されていることであれば、即座にやらない判断ができるかと思います。もし、やらないことが決まっていないと、場合によっては議論が必要となり、手戻りになってしまいかねません。これらが頻発してしまうと、計画や見積もりの信頼度が下がります。
その結果、やり残したことがないかどうか、不安になって自信を持てなくなっていくと思います。
ちなみに、やらないことを決められそうになければ、不確実性を許容した上でその場合はどうするのかを決めておければ良いかも知れません。

・方針や原則をつくっていく
共通の認識や価値観、行動指針や原理原則などをつくっていくと良さそうだと考えています。スクラム開発でいうところのワーキングアグリーメントのようなイメージです。これらがあることにより、ただタスクをこなすだけではなく、何のためにやっているのか、何に関心を持ちながらやっているのかがわかり、メンバー同士の相互理解にも繋がります。
ただし、盲目的に方針や原則に則って開発すればよいわけではなく、何らかの目的や目標のためにやっているはずですので、これらがいまのチームにとって合わないと感じたら廃止や見直しも検討しなければならないと思います。

・みんなで同じ方向を向く
『方針や原則をつくっていく』で述べたこととと被りますが、目的や目標をチームメンバー全員が理解し、そのために自分たちは何ができるのか、何をして貢献するのかを考えていく必要があると思っています。
自分が目的とは異なる方向に進みかけたとしても、誰かがそれに気づいて軌道修正してくれるのであれば、安心して間違えることができそうです。

・きちんと時間を設けて振り返る
スクラム開発でいえばスプリント（開発サイクル）ごとにレトロスペクティブと呼ばれる振り返りを行います。
これは、現在の問題点を把握し、より良くするための活動だと私は解釈しています。そして言い換えると、常に自分たちを疑い続けることでもあると考えています。
もしかすると、みんなで同じ方向を向いて進めていると思っていたのに全然違う方向をみんなが向いていたとか、進んでいるように感じていただけで進歩していなかったとか、そういうことが起きているかも知れません。
1つ1つ丁寧に振り返ることが、自信を持つことに繋がっていくと思います。

おわりに

t-wadaさんの記事を引用したにもかかわらず、あえてテスト自動化の話には触れませんでした。極端な意見かも知れませんが、テスト自動化は自信を持つための1つの手段だと思うからです。とはいえ、自動テストを否定するわけではなく、むしろ推奨したいくらいです。
しかしながら、自分たちのサービスやプロダクト、チームのスキルや成熟度を考えたうえで選択することがなによりも大事だと感じているため、このような内容となりました。

『やったほうが良さそうなこと』を実践したとしても、致命的な不具合を内包したままリリースしてしまうことはあるでしょう。
考えに考え抜いた結果、そうなってしまったのであれば、それは現在のチームや組織の限界だったというだけの話なので、その失敗を糧に再度チャレンジしていく必要があります。
そうして、それらを繰り返すうち、自分たちにとって最適で自信の持てるリリース基準が出来上がっていくのではないかと思っています。

たぶんよろこびます。よろです。