RSGT2026に参加して発表してきました。スクラム系のイベント初参加・初発表・かなり大きなホールでの発表ということで緊張した〜。
発表資料はこちら。QAフローの最適化とタイトルに入っていますが、QAチームの立場からというより、開発チームのソフトウェアエンジニアの立場から開発フローを改善していく話です。
資料を作っていて、「うーん自分は結局この発表で何が伝えたいんだろう？」と迷っていたのですが、作っていく中で言語化できたように思います。それは今回のフロー変更がうまくいったのは2つの成功要因があり、さらにこの成功要因はQAだけでなく開発フロー改善全体に言えることだなということです。
簡単にこの部分で話したことを要約するとこんな感じ。
- QAフローや開発フローの改善をするとき、最初からフロー設計をするのではなく、必ず事業やサービス理解から始める方が良い
- よくある罠として、QAでどんな障害・バグも防ぎたいとなり、どんどんQAコストが膨らみ、その結果開発〜リリースまでのリードタイムが伸び、アジリティの高い開発が徐々に失われてしまう
- そうならないように、「何は絶対に守りたいか」を先に明確にする。絶対に守りたいことを言語化すれば、障害などの問題が起きても、今後QAで継続的に確認すべきかを考慮できる
- 絶対に守りたいことは、事業やサービスのコア価値にあり、それはサービス紹介資料・営業資料・PMの頭の中などに存在する。先にその内容を理解すれば、満たしたい品質水準を達成しながらコスパの良いQAを設計できる
- 開発フローの改善を設計する前に、必ず開発フローの中で変更しやすい・変更しにくい部分の理解から始める方が良い
- よくある罠として、開発フローで大きな課題を感じ、理想のフローの設計を始めてしまう
- しかし事業の特性などで開発フローには制約がある。さらにこれまでの歴史的経緯などの理由で開発フローには慣性が生じている。そのため変更しにくい部分を無理に変更しようとしても反発が起きる
- 反発が起きると変更自体は良い方向に向かうはずなのに、「全ての変更が失敗であった」となってしまい、何も変えられずに終わってしまうケースが多い
- そのため、先に変更しやすい・変更しにくい部分を理解しておき、その情報を改善設計に組み込むことで、スムーズに変更を進められる
このような発表をしたので、もし興味が湧いたらぜひ資料も見てもらえればなと思います！
発表概要
QAフローが大変で開発したもののリリースに時間がかかってしまうという悩みはありませんか？
クラスター株式会社では障害を最小に抑えるため厚いQAフローを運用していました。このフローによってサービスの可用性品質は非常に高い一方で、開発を終えたものをリリースするまで最低でも12日かかるという課題がありました。
ソフトウェアエンジニアの立場からこの課題を解決するため、障害数をコントロールした上でリリースまでの期間を最短化する方法を模索・提案し、改善を進めました。具体的に次のことを一つずつ進めました。
- 事業の特性を理解して達成したい品質基準を決める
- 開発フローの制約条件を理解する
- 達成したい品質条件や制約条件を満たすように、QAフローおよびその周辺の開発フローを再検討する
- QAメンバーと一緒に、QAのregressionテストのテストケースや、テストすべき内容を決め直す
- 決定した理想系に向けて移行計画を作る
- 3ヶ月かけて、理想系まで移行する
改善の結果、以前は開発終了からリリースまで12日必要だったものが、今は最短で6日ほどでリリースできるようになりました。さらに新しいフローになった後も顕著な障害増加はなく、可用性品質をコントロールできている状況を作り出せました。
本セッションでは、私がQAフローの運用の最適化を行なった具体的な経験を紹介し、QAフローを最適化する時、もしくはQAフローを新しく始めたい時に何が大切かをお伝えします。
