目的から見直すリリース基準の改善活動 - Cybozu Inside Out

この記事は、2026年2月に開催された社内カンファレンス
「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTを
ブログ形式にして発信しているものです。

こんにちは！サイボウズでQA(品質保証)エンジニアをしているすずりん🦒です。
2025年に新卒として入社しました。

現在は、Garoonの品質にかかわる活動を担当するSpicaチームに所属し、社内外から報告された不具合の再現調査や不具合登録、リリースプロセスの改善に取り組んでいます。

今回はリリースプロセス改善の一環として行った、リリースクライテリア（リリース基準）の見直しについてお話しします。

製品の品質を考える際の参考になれば幸いです。

皆様はご自身の担当製品をリリースする際に守らなければいけない基準がありますか？
それはどのような理由でつくられた基準なのでしょうか。

Garoonをリリースするためには、社内に存在するリリースクライテリアを満たす必要があります。

リリースクライテリアには、計8項目が含まれます。以下は項目の例です。

Spicaチームではこのリリースクライテリアを月に一度の定期リリースごとに定常業務として確認しています。

確認作業はリリースの直前に行うため、リリースクライテリアが満たされないと緊急対応やリリースの中止が必要になることもあります。

しかし、現行のリリースクライテリアは、「どの項目をどのように確認するか」の手順が書かれているだけで、「なぜその項目が品質のために満たされるべきなのか」がどこにも書かれていません。

そのため、満たされない項目があった際、どのように対応していくかを決めるために時間がかかっていました。

そこで、この改善活動では、リリース前に行う確認事項を整理することで確認にかかる時間を減らすことを最終目標としました。

本記事では、まず1つ目のステップとして行った、品質特性による分類と、CIで確認しているワークフローの整理を紹介します。

まず、リリースクライテリアにある各項目について、なぜそれを確認する必要があるか、目的を明確に書き出しました。

書き出した目的を分類することで、「項目を満たした場合にどのような品質を保証できるか」が整理され、リリースクライテリアのゴールを明確にしたいと考えたためです。

分類には、品質の状態を可視化することに有効な「ソフトウェアの品質特性」を活用しました。

この分類を行ったことにより、Garoonのリリースクライテリアには次のような特徴があることが判明しました。

また、項目が満たされていなかった際に取るべきアクションについても、品質特性ごとに分類したことで具体的に考えやすくなりました。

GaroonのCIの中にはE2Eテストもあればユニットテスト、構文チェックなどもあり、CIで一括に実行される複数のワークフローは、それぞれ担保できる品質の種類が異なります。

しかしながら、それぞれのCIワークフローが何を担保しているかはドキュメント化されているわけではなく、必要に応じて追加・削除を繰り返しながら管理されている状態でした。

このため、リリースクライテリアの1つ、「CIが通っているか」を満たしていたとしても、ただ「CIが通った」事実が分かるだけで、結局何が保証されているのかが不明瞭でした。

今回は1つのマージコミットで動いているCIの内容をすべて書き出して、動いているワークフローの中身を元に「テストの種類」「テスト対象」「テスト目的」を一覧にしました。

これらを各ワークフローのコードから把握するためには、Github Copilotを活用しました。

この一覧を作成したことで、CIで何のためにどのワークフローが動いているかをいつでも探すことができる状態になりました。
また、各項目が先に分類した品質基準にどう対応しているかを明確にすることもできました。

今回の調査では、既存のリリースクライテリア項目は概ね適切であり、問題の原因はその分類と目的が明確でなかったことにあることが分かりました。

また、根本の原因を解消するために、リリースクライテリアが満たされなかった際に取るべき行動をより明確にするための改善活動も始まりました。

Garoonの品質を維持・向上するため、元あった課題をすべてクリアできるよう、1歩ずつ取り組んでいきます！