こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントをしています。好きなE2EライブラリはPlaywrightです。
今回は、LIFULLで取り組んでいるリリース承認の仕組みを変更し、自動化を図った取り組みについてお伝えします。
はじめに
皆さんは、普段の開発フローを一度俯瞰してみたことはあるでしょうか？ 開発からリリースまでを通して見直してみると、思いがけないフローがボトルネックになっていることはありませんか？
普段やっている決まった手順が「会社の規定だから」「昔からやってきた習慣だから」と、そのまま受け継いでいるプロセスほど、意外な手間やムダが潜んでいるものです。
そこで今回は、LIFULLにおける課題感を踏まえつつ、私たちが開発フロー全体を見返す中で明らかになったリリースフローの課題に注目し、我々がサイクルタイム改善に向けてどのように手順の変更、自動化へ向けて改善を行ったのかを紹介します。ご自身やチームのリリースプロセスを見直すきっかけになれば幸いです。
前提の説明
まず、変更前のLIFULLのリリースフローについて簡単に紹介します。
リリースフローの流れ
- 開発者はレビューやテストなどすべての手続きを終えたタイミングでチケットを作成し、そこからリリース承認を依頼します。
- リリースには上長の承認とPJ管理者の承認が必要です。
- 承認されたチケットをリリーサーが最終確認し、開発者以外の視点で内容をチェックしてリリースを行います。
JIRAでのチケット管理
- 開発、レビュー、デザインチェック、テストなど全作業工程をJIRAで管理していました。
- 開発者はGitHubとJIRAの両方を併用していた形です。
開発フローの変更にどう踏み切ったか
我々はサイクルタイムを加速させるべく、VSM（バリューストリームマッピング）で普段の開発フローを客観的に可視化しました。すると、開発終了からリリースまでの間に時間がかかっていることが分かったのです。
リリースチケットの課題
- リリース承認時に作成していたリリースチケットには、リリース対象のPRのURLしか記載されておらず、テストやデザインチェックの状況など、関連するチケットへ遷移できる情報がありませんでした。
- PJ承認を行う企画チームはGitHubのアカウントを持っていなかったため、実際にリリースされるパッケージが何なのか分からない状態に陥っていました。
手作業確認の負担
- 承認者はリリースに必要な情報を、チケットやPR、時にはSlackをたどりながら、目視で確認しなければなりませんでした。そのためチェックに大きな手間と時間がかかっていました。
余計な業務の発生
- 弊社ではリリースチェックをリリースチケットに記載する運用を行っており、チケットに不備があった場合、リリーサーが開発者へリマインドしていました。
- さらに、実際のリリースはGitHubで行うものの、確認はチケットで行うなど状況がチグハグでした。
- リリーサーは当日のリリース対象PRすべてについて上記作業を行う必要があり、非常に時間と手間がかかっていました。
解決策とその効果
これらの問題を解決するために、私たちはリリースに関わる一連の作業をGitHubへ集約することにしました。
実施したこと
チケットを廃止し、すべての情報をPRとIssueにより管理
- リリースチケットを廃止し、GitHubに集約することで、リリースに関係する情報がすべてPR上で確認できるようになりました。
- PR作成時に自動的に関連Issueが作成され、リリースに必要なテスト仕様書などのプロジェクト管理のものをまとめてタスク化でき、開発者の手順漏れがなくなりました。
- 今までサービス企画職(PJ承認者)はGitHubアカウントを持っていないため、リリースパッケージが何かわからない状況でリリースすることになっていましたが、集約に伴い作成していただき、すべての情報が開示できる状態になりました。
GitHub Actionsを使ってリリースに必要な情報のチェックを自動化
- 自動的にチェックをしてくれることで、開発者はリリースに必要な情報やコメントがそろっているかを事前に確認したうえで、承認者へ確認を依頼可能に。承認者のチェックに要する時間が減りました。
- 正しい承認者からの承認であることを、GitHub ActionsとGitHubのチームを用いて検証を行い、権限のある人からの承認であることを担保できるようになりました。
- Issue側に用意したタスクがすべて完了しているかもCIで担保できるので、承認者は開発者が手順にのっとって開発をしていたことが一目で分かります。
- GitHub Actionsにより定刻チェックを自動的に実施し、不備があれば開発者へ連絡できるようになりました。そのため、リリーサーの作業が大幅に削減されました。
具体的には、CIで一部の人間が行う確認を自動化し、人間の思考に頼る部分を最小化するフローに変更しています。
承認者やリリーサーは、作業やチェックに責任が伴うので、作業量以上に心理的な労力を要します。特に、情報が一ヵ所に集約されていないと、必要な情報をたどるだけでも予想以上に時間を費やしてしまいます。しかし今回の変更により、その一部を機械的に事前確認できるようになり、心理的ハードルを下げられました。
その結果、2024年10月時点と比較して、リリースまでのリードタイムの中央値と平均値に効果が現れ始めました。特にリリース中央値はもともと50時間ほどかかっていたものが安定して20時間台にまで削減されています。
また、リリース回数についても2024年10月から2025年2月末までの結果を見るとリリース回数が純増できました。
リードタイムの平均値は休日を挟むリリースパッケージが多くなると待機時間が増えがちになり、まばらな結果になりますが、さらなる開発の数が増えれば改善がよく見えるようになると想定されています。 まだまだ、改善点や指標の取り方に変更が必要ですので、さらにアップデートを行う予定です。
解決に対して考えることと注意点
このような大規模な開発フローの改善を行う場合には、現行の開発フローがどういう意図で作成されているのかを一つ一つ 紐解き、フローにおける最大要求と最低限の担保方法を洗い出す必要があります。
特に、社内事情には十分に注意しつつ調整しましょう。
我々も、手始めにこのフローを実現するにあたって、社内の有識者への担保事項やフロー変更に基づく注意点の確認やものづくりを行うすべてのメンバーへの事情説明を行った上で理解を得て進めています。
こういった会社の常識を変える時には常に守破離を意識して丁寧に実施しましょう。
今後の展望
今回のリリースフローの改変によって、GitHubへの集約を実現し、リリースを加速する基盤を整えることができました。次の段階としては、ここで得られた自動化の基盤を活用し、リリーサーを不要にするリリースの自動化へと進める計画です。今後さらにリリースを高速化し、サイクルタイムを短縮していきたいと考えています。
終わりに
私たちは「価値創造を加速させ続ける」ことをビジョンの一部に掲げ、その実現に向けて開発フローの可視化と数値化に取り組んできました。今回メスを入れたのはリリースフローでしたが、実際にはほかにも多くの課題が隠れているはずです。
「しかたがない」と思っているポイントこそ、変化の余地があるかもしれません。
開発フローにおけるそれぞれの構成要素をあらためて見直し、最低要件を確認してみることで思わぬ改善の糸口が見つかる可能性があります。
今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。
最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。
