記事のサマリー（TL;DR）
- サイボウズ Garoon の月次リリース基準（8項目）は「何を確認するか」の手順のみ記載で、「なぜ必要か」が不明確だった
- ソフトウェア品質特性フレームワークを使って各項目を分類し、どの品質を保証するかを明文化
- GitHub Copilot を活用して CI の全ワークフローを「テスト種類・対象・目的」の一覧に整理し、「CIが通った」だけでは分からなかった保証範囲を可視化
国内 kintone・Garoon 利用企業が参考にすべきリリース品質管理の視点
サイボウズが公開した本事例は、Garoon という大規模業務 SaaS のリリースプロセスに関するものですが、同様の課題は kintone をはじめとする国内業務 SaaS の内製開発チームや、ecforce・futureshop などの EC プラットフォーム上で開発を進めるチームにも広く当てはまります。「リリース基準はあるが、その意味が属人化・形骸化している」という状態は珍しくありません。
品質特性（機能適合性・信頼性・保守性など）という共通言語で各チェック項目を分類することで、クライテリア未達時の判断ルールを事前に設計できます。特に月次・週次の定期リリースを回しているチームでは、リリース直前に緊急対応が発生するコストは高く、事前分類による意思決定の高速化は直接的な工数削減につながります。
また、GitHub Copilot を使ってコードベースから CI ワークフロー仕様を自動抽出する手法は、テストコードを正としたドキュメント整備として再現性が高く、CI パイプラインを持つ開発組織であれば同様のアプローチを適用できます。
詳細
リリースクライテリアの課題
サイボウズの QA エンジニア「すずりん」氏は 2025年新卒入社後、Garoon の品質管理を担う Spica チームに配属されています。Garoon をリリースするには、社内で定めたリリースクライテリアを満たす必要があり、現行では以下を含む計8項目が存在します。
- 取り込みたい PBI（プロダクトバックログアイテム）がすべて完了しているか
- 開発中に発見された不具合が修正されているか
- 性能基準を満たしているか
- セキュリティテストが完了しているか
- CI（継続的インテグレーション）は通っているか
Spica チームはこれらを月次の定期リリースごとに確認しますが、確認はリリース直前に実施されるため、クライテリア未達が発覚した場合は緊急対応またはリリース中止を迫られることがありました。
根本的な問題は、現行クライテリアに「どの項目をどのように確認するか」の手順しか記載がなく、「なぜその項目が品質のために必要なのか」という目的が一切ドキュメント化されていなかった点です。目的が不明確なため、未達項目への対応方針を決めるのに時間がかかっていました。
本改善活動の最終目標は、リリース前確認事項を整理して確認にかかる時間を削減することです。本記事ではそのファーストステップとして実施した、品質特性による分類と CI ワークフローの整理を紹介しています。
リリースクライテリアの見直し
1. リリースクライテリアの分類
まず各項目について「なぜ確認する必要があるか」を書き出し、品質の状態を可視化する「ソフトウェアの品質特性」フレームワークを用いて分類しました。ISO/IEC 25010 を参考にした8つの品質特性・31の品質副特性の枠組みを活用することで、各クライテリア項目が「何の品質を保証するためのものか」を明示できます。
分類の結果、Garoon のリリースクライテリアには以下の特徴があることが判明しました。
- 機能適合性（Functional Suitability）に関する項目が多数を占める
- 「CI が通っているかどうか」という単一項目の中に、複数の品質特性にまたがる確認が混在している
品質特性ごとに分類したことで、クライテリア未達時に取るべきアクションも特性に応じて具体化しやすくなりました。
2.「CI が通っているかどうか」という項目の見直し
Garoon の CI には E2E テスト・ユニットテスト・構文チェックなど複数のワークフローが含まれており、それぞれが担保できる品質の種類は異なります。しかし各ワークフローが何を担保しているかはドキュメント化されておらず、必要に応じて追加・削除を繰り返しながら管理されている状態でした。
このため「CI が通っているか」というクライテリアを満たしていたとしても、結局何が保証されているかが不明瞭なまま運用されていました。
改善策として、1つのマージコミットで動作する CI の内容をすべて書き出し、各ワークフローについて次の3項目を一覧化しました。
| 項目 | 内容 |
|---|---|
| テストの種類 | E2E / ユニット / 静的解析 など |
| テスト対象 | 対象コンポーネント・モジュール |
| テスト目的 | 保証したい品質特性との対応 |
各ワークフローのコードから上記情報を把握するために GitHub Copilot を活用しました。コードベースから仕様を自動抽出することで、手作業でのドキュメント整備と比較して大幅に工数を削減しています。
この一覧を作成したことで、CI でどのワークフローが何のために動いているかを随時参照できる状態となり、各ワークフローが先に整理した品質基準のどれに対応しているかも明確になりました。
改善活動から得られたこと・展望
今回の調査を通じて、既存のリリースクライテリア項目自体は概ね適切であり、問題の根本原因は「分類と目的が明確でなかったこと」にあると特定できました。
また、クライテリアが未達だった際に取るべき行動をより明確にするための改善活動も、並行してスタートしています。Garoon の品質維持・向上に向け、同チームは段階的な改善を継続していく方針です。