はじめに
ツクリンクでSREエンジニアをやってるida.です。
弊社では、事業成長に伴い開発規模を拡大すべく、エンジニアの増員を進めてきました。メンバーが増え、開発チームも複数体制になったことで、プロダクト開発は加速し、それに伴いリリース頻度も向上しました。
しかし、その一方で、従来のリリースプロセスがボトルネックとなり、リリース作業の負荷が増大するという新たな課題に直面していました。手作業が多く、時間もかかり、ヒューマンエラーのリスクも無視できない状況だったのです。
このままでは、開発スピードの向上やプロダクトの品質担保に支障をきたしかねない。そんな危機感から、 「リリース改善会」 を立ち上げ、スムーズかつ安全なリリースを実現するための改善活動に本気で取り組み始めました。
本記事では、このリリース改善会でどんな改善を行ってきたのかをご紹介します。
1. まずは課題をとことん洗い出す
改善活動の第一歩として、開発に関わるメンバー全員で現状のリリースプロセスに対する課題を洗い出すことから始めました。
具体的には、以下のような点を意識して進めました。
- 現状の問題点の可視化: 実際にリリース作業で困っていること、時間がかかっていると感じる点、精神的な負担になっている作業などを具体的に挙げました。
- 理想の状態の言語化: 「こうなったら嬉しい」「この作業がなくなれば最高」といった、実現可能性やコストを一旦度外視した理想の姿も自由に発想しました。
- ツールの問題点: 利用しているツールに対する不満点（使いにくい、動作が遅い、機能が過剰/不足など）も洗い出しました。
ブレインストーミング形式で出したこれらの課題や要望をNotionに書き出し、グルーピング・整理を行いました。
そして、洗い出した課題に対して、 「実現可能性」「コスト（工数・費用）」「インパクト（効果の大きさ）」 といった観点から優先度を設定。どこから手をつけるべきかを明確にし、具体的な改善アクションへと繋げていきました。
この課題洗い出しによって、チーム全体でリリースプロセスに対する問題意識を共有し、改善へのモチベーションを高めることができました。
2. 改善の成果〜やったこととその効果〜
課題洗い出しと優先度付けを経て、私たちは具体的な改善策を実行に移しました。ここでは、特に効果の大きかった取り組みを4つご紹介します。
改善①：リリースワークフローの抜本的見直し
最も大きなボトルネックとなっていたのが、リリース作業そのものでした。
【従来のワークフロー】
- Notionベースの手順書: リリース手順はNotionのマニュアルにまとめられていました。
- 手作業中心: ほとんどの作業が手順書を見ながらの手作業。
- 複数人体制必須: 本番リリースなのでミス防止のために必ず2名以上でダブルチェックしながら実施。
- 所要時間: 全ての作業を終えるのに半日ほどかかっていました。
-
問題点:
- リリース改善会発足前は3日に1回程度のリリース頻度だったため、大きな問題とは認識されていませんでした。
- しかし、開発規模拡大に伴い毎日リリースへと移行する中で、工数的な負荷が無視できなくなりました。
- 手作業によるヒューマンエラーのリスクが常に存在しました。
- 作業に慣れてくると手順書をよく読まずに進めてしまい、作業漏れが発生したり、手順書自体が形骸化していく兆候が見られました。
【改善後のワークフロー】
従来のワークフローの課題を解決するため、以下の3つのアプローチで改善を進めました。
1. Slackワークフローへの移行
日常的な開発コミュニケーションの中心がSlackだったため、NotionのマニュアルをSlackワークフローに移行しました。
- 手順の実行: Slackワークフローを起動し、表示されるメッセージに従って進めるだけで、手順書を見なくても作業が完了するようにしました。
- 作業漏れ防止: 各作業ステップでチェックボタンを押す形式にし、作業実施を確認しながら進められるようにしました。
-
効率化:
- ワークフローのメッセージ内に、関連するツール（Jira、GitHub、監視ツールなど）へのリンクを埋め込み、すぐにアクセスできるようにしました。
- 従来はリリース当番が各チームに進捗確認して回っていましたが、テスト完了連絡などを各チームから自発的に報告してもらう形式に変更し、リリース当番の負荷を軽減しました。
2. 不要な手順の削除・統合及びツールの変更
Slackワークフローへの移行と並行して、既存の手順に無駄がないかを見直し、不要な作業を大胆に削減・統合しました。また、使いこなせていないツールをより利用しやすいツールに変更することにより作業を簡略化しました。
-
テスト管理ツールの変更 (TestRail → Notion):
- 従来はTestRailでテストケース管理と結果記録を行っていましたが、我々のユースケース（テストケースと結果の記録）に対して機能が過剰（too much）でした。
- また、動作が不安定で遅い、エラーが頻発するといった問題があり、テストの消し込み作業の妨げになることもありました。
- そこで、よりシンプルで動作も軽快なNotionにテスト管理を移行しました。現在の運用ではNotionで十分であり、メンバーからも好評です。
3. 作業の自動化
手作業で行っていた定型的な作業を積極的に自動化しました。
-
リリースPR作成スクリプト:
- リリースの対象となる変更差分（コミットログなど）を元に、リリースノートの本文を含むPull Requestを自動で作成するスクリプトを開発しました。コマンド一つでリリース準備が整います。
-
GitHub Actionsによる自動リリース:
- リリースブランチへのマージをトリガーに、GitHub Actionsが自動でGitのタグ発行、GitHubリリースの作成、リリースノートの発行を行うワークフローを構築しました。
-
Jira連携の自動化:
- Slackワークフローの特定のステップからWebhookなどを利用し、Jiraのリリースバージョン作成や関連チケットのステータス更新を自動で行うようにしました。
これらの改善により、リリース作業の属人性は大幅に排除され、誰でも迅速かつ安全にリリースを行える基盤が整いました。
改善②：リリーストレインの整備
リリーストレインを新たに定義して複数のチームが連携して効率的にリリースできるように整備しました。
【従来のワークフロー】
- チーム数が少なかった頃は、各チームのリーダー間で開発状況を見ながら調整し、「ある程度のボリュームが溜まったらリリースする」という運用でした。
- リリース頻度は3日に1回程度で、明確な締め切り時間はありませんでした。
【改善後のワークフロー】
開発チームが増え、毎日リリースを行うようになったため、リリーストレインを作成してリリースを毎日行う体制を整えました。
-
初期導入: まず、「前日18時までにテスト完了したものを、翌日10時にリリースする」というルールで毎日リリースを行うようにしました。
- これにより、開発者はリリース時間を意識して計画的に作業を進めるようになり、開発リズムが生まれました。
-
リリーストレインの見直し: 上記ルールでは、テストに時間がかかるタスクへの対応や、定時後も作業して少しでも早く機能を提供したいといったケースで柔軟性に欠ける面がありました。
- そこで現在は、「午前中にテストを完了させ、午後にリリースする」というルールに変更し、より柔軟に対応できるようにしました。
- 今後の課題: 現状はこのルールでうまく回っていますが、今後さらにリリース頻度を高め、例えば「1日に2回以上リリースしたい」となった場合には、再度リリーストレインの見直しが必要になると考えています。
改善③：本番相当のFeatureトグルが設定されている環境(pre-release)の構築
Featureトグルを利用した開発プロセスにおける課題も改善しました。
【従来のワークフロー】
- 弊社ではFeatureトグルを活用し、開発中の機能はトグルOFFの状態で
mainブランチにマージし、本番リリース後にトグルをONにして機能公開する、という運用を行っています。 - 開発中やスプリント中は、基本的に検証環境で該当機能のトグルをONにして開発・テストを進めます。
- リリース前には、デグレードが発生していないかを確認するため、トグルをOFFにした状態での確認（デグレードテスト）が必要になることがあります。
- このデグレードテストを行う際、従来は検証環境のトグル設定を一時的に本番同等（対象機能のトグルがOFF）に変更していました。
- しかし、トグルの切り替えにはサーバーの再起動が必要であり、その都度、検証環境を利用している他の開発者に再起動のアナウンスを行い、タイミングを調整する必要があり、手間がかかっていました。
【改善後のワークフロー】
この手間を解消するため、段階的に改善を行いました。
-
Redisキャッシュ: まず、検証環境においてのみ、Featureトグルの設定値をRedisにキャッシュするように変更しました。
- これにより、サーバーを再起動することなくトグルのON/OFFを切り替えられるようになり、無影響確認時の手間が大幅に削減されました。
-
pre-release 環境の構築: 次に、より根本的な解決策として、新しいテスト環境を構築しました。
- この環境は 「pre-release 環境」 と名付け、常にFeatureトグルの設定が本番環境と同じ状態（開発中の機能はOFF）になるように構成しました。
- 開発者は、機能開発・テストは従来の検証環境（トグルON）で行い、リリース前の無影響確認はpre-release 環境（トグルOFF）で行う、という使い分けが可能になりました。
- これにより、トグル設定の切り替え作業そのものが不要になり、他チームの開発をブロックすることなく、いつでも無影響確認を実施できるようになりました。
改善④：E2Eテストによる本番リリース後確認の自動化
リリース後の手動確認作業も自動化しました。
【従来のワークフロー】
- リリースワークフローの最後に、「本番環境で主要な画面をいくつか開き、エラーが表示されていないか、基本的な動作に問題がないかを目視で確認する」という手順がありました。
- 確認項目自体は難しくありませんが、対象画面数が多く、毎回手作業で行うのは手間がかかり、形骸化しやすい作業でもありました。
【改善後のワークフロー】
この手動確認を自動化するために、Amazon CloudWatch Synthetics を利用してE2Eテストを構築しました。
-
自動実行:
- Synthetics Canary を設定し、主要画面へのアクセスや基本的な操作（ログイン、主要機能の表示など）をシミュレートするスクリプトを定期的に実行するようにしました。
- Synthetics を導入したため従来のリリース後確認手順は削除しました。
-
オブザーバビリティ向上:
- これにより、リリース直後の1回だけでなく、常に本番環境の状態を監視できるようになりました。
- 万が一、意図しないデグレードや障害が発生した場合でも、早期に検知することが可能になり、オブザーバビリティ（可観測性）が向上しました。
-
AWS Synthetics の利点:
- テスト実行時のスクリーンショットやHARファイル（通信ログ）、実行ログなどが自動で保存されるため、問題発生時の原因調査が容易です。
- 他のE2Eテスト自動化サービスと比較して、コストパフォーマンスが良いと感じています。
まとめ
リリース改善会での取り組みを通じて、リリースプロセスを大きく変革することができました。
- 工数削減: 従来は半日かかっていたリリース作業が、改善後は1時間かからずに完了するようになりました。また、自動化により手作業で行っていた多くのルーティンワークが削減されました。
- 品質向上: 手順の標準化、自動化、E2Eテスト導入により、ヒューマンエラーのリスクが低減し、リリースの安全性が向上しました。
- 開発体験 (DX) の向上: これが最も大きな成果かもしれません。煩雑でストレスの多かった手作業から解放され、開発者はより本質的な開発業務に集中できるようになりました。
また、現在は毎日リリースを行っていますが、今回の改善により問題なく円滑にリリースが行われていると思います。
これらの成果により、現在の開発規模とリリース頻度においては、改善されたワークフローがうまく機能していると判断し、一旦リリース改善会は解散としました。
しかし、リリースプロセスに「これで完璧」という終わりはありません。開発のフェーズ、チームの規模、技術の進化によって、常に改善の余地は生まれてきます。
今後も、開発現場からの声に耳を傾け、新たな課題が見つかったり、より良い方法が見つかった際には、再び改善活動を立ち上げ、変化に柔軟に対応していきたいと考えています。
この記事が、同じようにリリースプロセスに課題を感じている方々の参考になれば幸いです。
Discussion