2週間に一度からリリースを日々の当たり前にするエンジニアリングマネジメント

2023年4月14日に行われたJBUG沖縄 #4「スタートアップがみせるプロジェクトマネジメント」の中で「2週間に一度からリリースを日々の当たり前にするエンジニアリングマネジメント」というタイトルで発表した内容です。

Transcript

1. ２週間に一度からリリースを日々の当たり 前にするエンジニアリングマネジメント CBcloud株式会社 新垣雄志
2. 2020年8月に入社した当時のプロダクト開発状況 • ２週間に一度にリリースできればよい • リリースしても影響範囲やテストが不十分で切り戻しが発生することが頻繁におきる • リリースが怖いので夜間リリースが当たり前
3. 現在のプロダクト開発状況 • 毎日リリースするのが当たり前。 1日に五回リリースすることもある • バグ・切り戻しがないわけではないが、頻度は確実に減っている • リリースが怖くないので大きなリリース以外は日中にリリースすることが当たり前
4. この状況を作るために行ったマネジメントについて • プロジェクトマネジメントというよりは、エンジニアリングマネジメントやプロダクトマネジメントの領域が多め • とはいえ、大事なことで面白いと思うので共有できればとおもってます
5. アジェンダ • プロダクト品質への投資 • リリースマネジメントの考え方の変更 • 開発者リソースを確保するためのプロダクト改善
6. プロダクト品質への投資 • テストコードを書く文化 • QAチームによるリリース前統合テストの導入 • NewRelicというモニタリングツールの導入 • ドキュメントを書く文化
7. テストコードを書く文化を作る • テストコードがゼロだった ◦ とはいえ、書く必要性についてはみんな気づいていたができていない状況 ◦ ということで号令をかけた • テストコードが書かれていない機能はマージしない（新規開発はテストをかく） • コードを書いたとき周辺のコードのテストが書かれていなければ書く • テストカバレッジを計測し、 0.01%でも増えたらSlackで大喝采する • コツコツ育てることで現在のテストカバレッジが 75%超えた（やったー
8. QAチームによるリリース前統合テストの導入 • 当時一年以上このプロダクトを触り続けているエンジニアが一人でそれ以外は１年以下の新人ばかりの 状況 ◦ 正直プロダクトの機能がどこに影響をうけているかわからない ◦ テストコードもない ◦ ドキュメントもない ◦ なのでコード書くとバグる • 外部のQA専門会社に入っていただき、リリース前に機能の統合テストと主要機能のデグレテストを行うよ うにした ◦ これによってリリースするときの不具合率や怖さがへってきた
9. NewRelicというモニタリングツールの導入 • アプリケーションのモニタリングがないのでリリース後になにか想定外のエラーが起きているかどうかわ からない。 • 問題が起きた時はユーザーや社内のカスタマーサポートからの声になり、そこから原因を探ることは困難 • モニタリングツールを導入することにより、エラー検知の速度、エラーの原因調査の速度が上がった • 既存のエラーも潰していくことができ品質が向上した
10. ドキュメントを書く文化を育てる • 機能開発・修正をするときにはかならずデザインドキュメントようなドキュメントを書く ◦ なぜやるのか ◦ だれのためにやるのか ◦ どういう仕様でつくるのか • プルリクに関連リンクを必ず貼る • 既存の機能の仕様を調べたときにも調べた内容をドキュメントに書く • これによって、既存仕様を理解することが簡易になってきた
11. リリースマネジメントの考え方の変更 • 過去はリリースがこわかったのでリリース頻度を上げれなかった • そのためある程度の粒度で複数のバグ修正や機能追加のまとめて一度にリリースする体制をとっていた • ２週間に一度のリリース ◦ リリース日を決め、その日にリリースする内容をまとめる ◦ QAチームにリリース内容を共有しテスト計画を立ていく ◦ リリース用ブランチを作成してマージ ◦ リリース内容を統合テスト ◦ リリース
12. ２週間に一度のリリースの問題点 • 開発が終わってもリリースするまで２週間待たないいけない • QAで一部の機能に不具合があったときにそれだけ修正を取り除くのがむずかしい • リリース後に不具合がでてもどれが起因でおきたのか判別するのがむずかしい • 切り戻す際もまとめたリリース内容をまとめて切り戻す必要がでてしまう。
13. リリースまとめるのではなく、個別リリースへ - 小さなバグ修正でも、大きな機能開発でもまとめるのではなく個別にリリースしていく。 - 例: - 機能開発が終わったら、またはリリース日の目処が立ってきたら QAチームのQA日程を調整する - テスト計画を個別にたてて、 QA日になったら個別に QA - QAが通ったら個別でリリースする - これによってリリースを待つことや問題が起きた時の切り戻しの難易度が減った -
14. 品質が上がったことでQAを省く意思決定も増えた - 影響範囲が大きい、バグが起きた時のダメージが大きいものは確実に QAをした上でリリースするが、品 質が向上したことによって開発メンバーだけのテストで出せる範囲が増えてきた - これによって簡易な修正や機能追加は開発者がステークホルダーのテストだけでリリースできることも増 えた
15. 開発者のリソースを増やすためのプロダクト改善 - サービスの運営をするために必要なオペレーションの部分で管理画面の機能が足りないが故に開発者 に依頼がきてデータベースのデータ変更・投入をしないといけない業務が非常に多かった - 料金表の変更 - お客様の設定変更 - パートナーへのポイント振り込み - etc
16. 負のサイクルが回っていた
18. 新たに運用管理画面を作ることを決定 • 開発者しかできないオペレーション業務を運用管理画面に実装 • それによって開発者以外でもオペレーションできるようになる • それの空いた時間でオペレーション業務を可能な機能を作り、また時間を作るというサイクル • これによって、現在は開発者が DB操作を伴うオペレーションを行うのは月に数回程度も削減 • 開発できるようになる
19. 運用負荷を下げるだけでなくオペレーション効率を上げる効 果もでてくる • パートナーへの一括ポイント加減機能を追加 ◦ いままでキャンペーンによって特定の条件を満たしたパートナーにポイントを付与するという施策がエンジニア に作業時間をネックに実施しづらかったが、オペレーションチームでできるようになることで施策の頻度を増やす ことができた • 荷主へのカスタマイズした料金表の設定機能を追加 ◦ 契約してもらってもエンジニアが料金表を登録するまで使い始めることができなかったが営業が直接登録できる ようになることで使い始めてもらうまでのリードタイムが短くなった ◦ 料金表の仕様をエンジニア以外も理解することで、交渉時にそもそもこの料金体系が実現できるのか？という 面でのやりとりや仕切り直しがなくなった