新規事業や初期導入時にはバグやトラブルがつきものです。バグが発生しないということはリリースが遅すぎたと考えるべきだと思いますし、許容範囲のリスクを取りながらギリギリのラインを攻めて、リリース後は素早くバグを収束させて顧客の信頼を損なわないように対応する必要があります。

バグはなぜ起こるか？

• テストしていない

• テストケースが想定できていない

基本的にテストしてたらほとんどケースはバグは表出してこないのですが、テストするにもコストがかかってリソースが足りなさすぎるからバグは必ず発生します。

toBプロダクトだと特にお客様の業務理解が足りなくて、そもそもテストケースが想定できてない場合も頻繁に発生します。

AI時代の安定した初期プロダクトリリース

顧客理解を進めるために積極的に現場にいって、目に見えるもので見せるか実際に自分で業務であったりをやってみることでテストケースの想定が漏れるリスクをヘッジします。

ここがズレると顧客の信頼を損ねるので必ず外してはいけないし、必ずズレは発生するので定期的に修正していくのがPdMだったりマネジメントの仕事になります。

デザイナーはfigmaで常に最新のデザインをコラボレーションしながら、エンジニアはGPT-4を活用して単体テストの工数を削減しながらテストを積みます。新規コードもGithub copilotで工数削減して、高い品質と素早いデリバリの両立を実現します。

するとアウトプットのサイクルが全体的に上がります。

現場のPdMとリモートでデザイナーがfigmaをコラボレーションしながら、それこそ顧客とデザインを一緒に作りながらでもいいですね。それをエンジニアが高速で形にして、顧客に見せて改善サイクルを回すのが初期プロダクトリリースに求められるチームの動きではないでしょうか。

求められるエンジニアの品質管理スキル

スピードのために単体テストを一部捨てる世界観から、LLMの登場でスピードのためにAIペアプログラミングして単体テストをカバレッジ100%に近いレベルで書くという世界線に2023年変わったと思います。

その上でエンジニアの品質管理は、テスト可能に状態をなるべく持たずに関数化していく必要があります。バグの可能性をLLMが指摘してくれますが、構造的な品質の作り込みまでLLMはまだサポートできません。

例えばデータ取得するコードがあったとして、どういう戦略でデータ取得すべきかはAIがまだサポートしていないので、データ取得がエラーになったときどういうフローで修正していくか、汎用的なコードにしてリソースをかけるのか一旦エラーで落として実際のエラーを確認してから即時対応するのかは事業戦略であったり品質管理です。

具体的に異常系を想定してその対応方法を検討することでリスク管理ができて、許容範囲のリスクなのか許容範囲外のリスクなのかが判別するので事前にバグ収束の戦略を立てることができます。

リスク管理がプロダクトの品質につながる。

理想的な初期プロダクトリリースの状態

リスクやバグはあるものの重大な問題に発展するようなものではないバグリストがあって、そのバグに対応しながらも想定外の事態には即時対応できる体制でリリースボタンを押せると良いのかなと。

クラッカーを鳴らしてリリースを祝って夜気持ちよく寝るにはこういう状態に持っていく必要があります。

最悪なのはリリース直後のトラブルで徹夜で対応して、眠い目をこすりながらやった作業で二次災害が起きたりするのは目も当てられず顧客の信頼が地に落ちます。

すでにバグだらけで燃えている場合はどうするか

まずバグの傾向を分析します。

• ①テストケース増やせば解決するか？

• ②テストケースを増やしてもバグが発生しそうか？

①のケースはLLMに頼ってバグ討伐週間を設定します。バグっている所からGPT-4に単体テストを書かせてエラーが出るようにしてからコードを修正するということを繰り返します。こうすることで、そもそもバグが発生しているエンジニア側のスキル面での成長も得られるので中長期的には品質が上昇していくので、今後の運用が安定していきます。

バグ討伐週間を設定して討伐したバグをSlackで報告するとバグが発生した原因をチームが理解して、再発防止策を自動的に考えるようになります。リスク許容度判断の成長にも繋がります。

②のケースは業務理解が足りてないので深刻です。しかもリリース時点でこうなっているとコミュニケーションも難しくなっています。かなり苦しい判断ですが全力で謝罪してリスケジュールとPdM・デザイナーを顧客に張り付かせるというのが最善手なのかなと思います。

TOIRO美肌院でGitHub Copilotが使われてます

E2Eもテストシナリオが自動化されていきそうです。

バグの収束方法

収束の定義やリリース基準はこういった記事で細かい解説があるが、どっかに線を引いて判断をします。金融だとハードル高いし、メディアだとハードル低いしみたいに結構事業によるのでどこに線を引くべきか？は思想によります。

結局リリースするか、延期するかの判断は経営判断でしかありません。判断に必要な情報はバグの総量・バグのリスク許容度・バグ修正工数の3つなので、最低限スプレッドシートにまとめて管理していればOKです。それさえあればバグ討伐日を設定して1日とか半日で消化できたバグのベロシティからリリース日をある程度の精度で判断できるようになります。

個人的には中長期の計画に影響あるリスクは取りづらいので、そのリスクが高いものは必ずリリース判定までに潰しておくのがベターなんだと思います。

色々問題はあると思いますが、バグも楽しんでやっていきましょう。