はじめに
UPSIDER の支払い.comでバックエンドエンジニアを担当している水村です。
リリース当初はビジネスサイドとエンジニアを合わせて5、6名だった支払い.comのチームですが、リリースしてから2年弱でビジネスサイドを含めると数十名規模になりました。
今回は、アジャイル開発を基本としていますが、スクラム開発ではない支払い.comの開発手法についてまとめました。
支払い.comのリリースフロー
2022年5月に正式スタートした支払い. comですが、2023年11月22日現在、本番環境へのリリース回数は394回に達しました。過去1年半の営業日を約370日と考えると、ほぼ毎日リリースしていることになります。毎日リリースが行われるわけではありませんが、時には1日に複数回リリースすることもあります。開発チームの人数が多くないにも関わらず、この頻度でリリースができていることは良い成果だと思います。
さらに、これまでのリリースは特に大きなバグも少なく、安定して行われています。たまに私が間違えてリリースすることもありましたが、そうしたやらかしは2回程度で、幸い本番環境への影響はありませんでした。翌日にリリースしようと思っていた軽微な修正を早めにリリースしてしまった、という感じです。
支払い.comはスクラム開発を採用していないので、スプリントがありません。ですが、アジャイル開発やスクラム開発の考え方を基本としています。機能が出来上がってテスト環境でテストして問題なければリリースという流れで本番リリースを行なっています。本番リリースまでのリードタイムを短くした方がメリットがあると考えているため、リリース準備が整った機能はどんどんリリースしています。これは和田卓人さんの「質とスピード」や「Lean と DevOps の科学」などから影響を受けています。
リリース頻度が高いことのメリット
良い意味で本番リリースの緊張がなくなることが最大のメリットだと感じています。リリース頻度が2週間に1回だったり、月に1回だった頃と比べても安心してリリースできている実感があります。小さな変更や機能追加を頻繁にリリースできるのでテストする範囲も狭いです。テストもすぐ終わります。いいことづくめなので頻繁にリリースしたくてたまらなくなってきます。
リリース頻度を高めるためにやっていること
当たり前のことすぎるので書く必要なさそうですが、GitHub Actions 上の CI でテストを自動化して CD で簡単にデプロイできるようにしてます。CI は早く終わったほうが嬉しいので定期的に見直して遅くなったら改善します。
本番リリースも GitHub Actions 上で実行されています。バックエンドの場合は Docker Image を作成して Artifact Registry に push して Cloud Run へのデプロイが実行されます。フロントエンドの場合は GitHub Actions 上で Next.js のビルドを実行し Firebase Hosting にデプロイします。
リリースについての基本的な考え方ですが、最小限の機能や変更を細かくリリースするようにしています。「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」に書いてある考え方と近いかもしれません。この本は最近読みましたが、参考になることが多かったです。
スプリントをやらない理由
スプリント方式を採用しない理由は、主にリードタイムが長くなることにあります。スクラム開発では、1-2週間のスプリントを実施し、その期間内にユーザー受け入れテスト（UAT）まで完了しリリースできる状態にすることが目標です。しかし、実際には1つのスプリント内で UAT を完了させるのは難しく、多くの場合次のスプリントに持ち越されます。これにより、機能が本番環境にリリースされるまでには最短で1〜2週間の遅延が発生します。
さらに、スプリント内でリリース対象の機能が多い場合、テストと本番リリースが困難になることがあります。テストで多くのバグが見つかった場合、機能を元に戻したり（revert）、特定の機能を選んでリリースしたり（cherry-pick）する必要が出てきます。また、スプリントの期限に合わせて品質を犠牲にしたコードがマージされることもあり、これは開発の負債となり得ます。
確かにスプリント方式が有効なケースもありますが、現在の私たちの開発体制ではその必要性が低いと感じています。スプリントによって生じる遅延や複雑さを考慮すると、私たちにとって最適な方法ではないと判断しました。
よって、支払い.comではカンバンのような開発方式を採用してます。エンジニアの手が空いたら優先度の高いタスクを順番にやっていくようにしています。
そもそもなぜスプリントが必要なのかを考えると、ステークホルダに対して進捗を伝えやすいことが大きな理由だったりします。UPSIDERのように自社でサービスを運営している会社の場合、進捗に対して説明責任が必要な外部のステークホルダがあまりいないです。
開発の細かい進捗は支払い.comのチーム内で共有できていればよく、リリースタイミングは自分たちでほぼ自由に決めることができます。そのため、スプリントを採用する必要性は、一般的な環境とは異なるかもしれません。スプリントプランニングとは別に、顧客に何を提供したいのかを機能単位で判断して優先順位づけを行なっています。
プロダクトバックログ
以前はプロダクトバックログを GitHub Projects で管理していたのですが、エンジニア以外のメンバーが見づらかったりしたので notion に移行しました。notion に移行するにあたってLayerX さんのテックブログが参考になりました。ありがとうございます！
プロダクトバックログ上で優先度の高いものから要件と仕様を詰めていきます。ビジネスサイドの希望するリリース日が実現可能かどうかの見積もりをエンジニアが行います。見積もり精度はあくまで目安であり、70％の確率で2-3日で完了、90%の確度で4-5日といったブレがあるので、見積もり段階で決定したリリース日からずれることが想定されます。
個人的には見積もり段階でいつ頃リリースできそうかを判断し、実装途中でさらに精度が上がってくると思うので、途中経過を報告していつ頃リリースできそうかをビジネスサイドと調整するのがいいのかなと考えています。また、見積もりはあくまで見積もりであり、コミットメントではないという前提で考えています。
リリース日をどうやって決定するのかは現在改善を行なっている最中です。ビジネスサイドの要望としてはなるべく早い段階でいつリリースできるのかを知りたいのですが、エンジニアとしては見積もりや実装途中までやってみないとなんとも言えない部分があるので、ビジネスサイドとエンジニアのお互いにとってどのあたりで合意を取るのが最適なのかを模索しています。
おわりに
支払い.comは元気な20代前半の若者が PjM, PdM, PMM を担当しています。エンジニアチームも20代中盤から40代、元 SIer や受託開発経験者など、多様性があります。最近の若者は非常に優秀で、めちゃくちゃ優秀ですごいな・・というのを感じながら若者の成長を見守りつつ、顧客にとって価値のある機能を最速でリリースできるように努めてまいりますので、よろしくお願いいたします。
UPSIDERはエンジニアを募集していますので、ご興味がありましたらカジュアル面談などのご応募をお待ちしております！
参考文献
アジャイル開発やスクラム開発についての考え方は以下の本などを参考にしています。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
