NEWTの急成長を支えるアプリリリースの裏側

リリースサイクル

まず、Appチームは基本的に1週間に1回のリリースを行っています。

1スプリントを1週間と設定し、スプリント単位ごとにリリースを行っています。もちろん、開発案件のサイズによってはスプリントを跨ぐものもありますが、基本的には本スプリントで開発したものを次のスプリント期間中にQAを実施しリリースするというタイムラインでサイクルを回しています。

つまり、1週間で開発したものを次の1週間でQAしリリースするので、開発着手から2週間でリリースを行い、このレーンを並列で走らせることで毎週のリリースを実現しています。そのため、テストフェーズにて見つかった不具合については機能の開発と並行して対応する必要があります。

このサイクルを維持するためにも、テストフェーズに入る前の初期品質をいかに高い状態にできるかが重要になってきます。

特にアプリの場合は、リリースするには各ストアの審査を通す必要があるため、毎週リリースを安定的に実施するには、開発生産性を高く保ち続け、リリースサイクル安定させる必要があります。

このあたりの生産性を高めるための取り組みに関しては、以前こちらのブログで紹介しているので、気になる方はチェックしてみてください。

スケーラブルで生産性高いチームをつくるための取り組み

令和トラベルに所属するエンジニアのブログです。「あたらしい旅行を、デザインする。」令和トラベルは、海外旅行事業を展開するデジタルトラベルエージェンシーです。

https://engineering.reiwatravel.co.jp/blog/Engineering-Manager-Advent-Calendar-20231218

結果として、FY24(2023年4月~2023年3月)で、iOS/Androidそれぞれ通算で約50回のリリースを実施することができました。

スクラム運用

次に実際にスプリント単位で実施している以下のスクラムイベントについて、Appチーム流の実施方法について1つずつお話します。

イベント	タイミング / 頻度	時間
デイリースクラム	毎日	20min
バックログリファインメント	月曜日 / 毎週	30min
スプリントプランニング	火曜日 / 毎週	30min
レトロスペクティブ	火曜日 / 隔週	30min
Dog Fooding	火曜日 / 毎週	30min
月次振り返り	金曜日 / 毎月	1-1.5h
読み合わせ会	適宜	15-30min

厳密にスクラムのフレームワークに準拠しているわけではないですが、日々の運用の中でブラッシュアップを行い、今の形になっています (あくまで弊社の場合)。定期的に振り返り、改善できそうなことに対して、積極的にトライしてみるスタンスを大事にしています。

デイリースクラム

概要

チームとして最速で目標を達成するために、お互いにやっていることを共有しあって、効率よく効果的な動きがチームでできるようにすることを目的に毎朝20分で実施しています。

緊急度の軸でタスクを記載し、スプリントゴールを達成するにあたってブロッカーになるようなものや気になることがあれば、サクッと相談して認識を合わせる場として機能しています。また、各メンバーが能動的にアウトプットするスタイルにすることで主体的に参加する形を目指しています。

(朝からアウトプットすることで目を覚ます効果もあればいいなあと思っていたり…)

内容

■ 記入タイム

最初に各メンバーごとに割り振られた付箋を使って、各自セクションに合わせて記載を実施します (miroでフォーマットを用意して利用しています)

主に以下の3つのセクションを中心に記載をします

今日やること：

各メンバーが、本日取り組むタスクについて他のメンバーにも伝わる解像度で記載するパート

共有事項・雑談：

全社アナウンスのリマインドやチーム内での共有事項をメインとしつつ、雑談として何でも書いていいパート

相談したいこと・困っていること：

全体で相談したいこと、特定のメンバーと個別で相談したいこと、相談するほどではないけどちょっと困っていることを記載するパート

上記に加えて、補足セクションとして「QA・リリース確認」「別チームからの申し送り」「休み予定」の3つを用意しているので、必要に応じて記載します

■ リアクションタイム

記入タイムが終わったら、各自で全体を確認して気になることや取り上げたいことを中心に各自リアクションやコメントをつけます

■ トークタイム

リアクションタイムが終わったら、ファシリテーターが緊急度の高いものや相談事項を優先しつつ、リアクションの多いものから取り上げていきます

これによって短時間で、スプリントゴールの障壁になりうるものから効率的に解消することができています

リリース前日には、リリース項目の確認と各プラットフォーム間の依存がないか、リリース順序の確認を事前に行っています

さらに、この場で話すには関係するメンバーが限られていたり、時間がかかりそうなトピックについては簡単な状況の共有の後、分科会を開くことで効率化を図っています

バックログリファインメント

概要

スプリントプランニングを実施する前に、次のスプリント以降で着手したいバックログの内容をエンジニアメンバーで確認し、仕様の認識合わせと見積もりを実施します。そのなかで仕様に対する疑問点や不明点が出れば、プランニング前にPMとすり合わせを実施します。

見積もり精度を高め、スケジュール通りにリリースできるようにするために重要なイベントになっています。また、チーム内で相互レビューする際に、仕様を把握しておくことでコードレベルだけでなく、仕様の観点からもレビューできるようにする意図もあります。

内容

■ 事前準備

リファインメント前に、次のスプリント以降で着手したい案件のチケット化をPM中心に実施します

すでに起票済みのチケットも合わせて、PM観点で対応の優先順位を決めておきます

■ チケットの内容確認

新規チケットの仕様とデザインを確認する

仕様やデザインに対して疑問点や不明点があれば、PMやデザイナーに確認する

案件の規模に合わせて、親チケットに対して、実装サブチケットを作成する

このとき、大きな案件については対応スコープ単位で細かめにサブチケットを作成する

案件の規模や複雑性を加味して、Dev Docの作成可否を決める

Dev Docを作成する場合はサブチケットとしてタスク化する
Dev Docについては以下の記事を参照ください

NEWT アプリ開発におけるドキュメンテーション “Dev Doc” の導入

https://engineering.reiwatravel.co.jp/blog/newt-app-devdoc

■ 見積もり

内容を確認した新規チケットに対して、ストーリーポイントを付与します

サブチケット単位でプランニングポーカーを実施し、メンバー間で認識合わせを行います

スプリントプランニング

概要

バックログから次のスプリントにて着手するチケットを決定します。

リファインメントを実施することで、各チケットにストーリーポイントが付与された状態になっているので、それを元に次のスプリントで対応できるボリュームを確認し、弊社ではこのタイミングで案件単位で各プラットフォームの担当メンバーを決定しています。

その後、必要に応じて各案件に対する読み合わせ会(後述)をPMで実施し、設計から開発まで基本的に担当メンバーが責任を持ってスケジュール通りに進めます。また、プランニングにて各案件の進捗状況やストーリーポイントから、リリース予定のバージョンを付与し、リリースタイミングを決めています。

内容

■ リリース確認

基本的にスプリントが切り替わるタイミングでリリースを実施しているので、改めて本日リリース予定の項目について確認します

前日のデイリースクラムのタイミングでリリース順の確認などは終わっているので、ここではサラッと最終確認を行います

■ スプリント振り返り

リリース案件数やストーリーポイント消化数など、モニタリングしている指標について共有し、簡単に状況を振り返ります

しっかりとした振り返りは、別途レトロスペクティブや月次振り返りで実施します

■ プランニング

既存スプリントにおける進捗状況の確認

進行中の案件の進捗を確認し、リリースタイミングはいつになるか、次のスプリントにタスクを持ち越す必要があるのかを確認します

新規スプリントに向けた案件確認とアサイン

上記の状況を鑑みつつ、優先順位を決め、新規スプリントで対応するタスクのアサインを行います

次回リリース項目の確認と調整

次回のリリース項目については、新規スプリントでQAを実施することになります
このタイミングでリリース項目を確認し、QAリソースとの兼ね合いを見て調整したり、Dog Foodingの対象項目を確認します

ボードの整理とスプリントスタート

一通り確認が終わったら、既存スプリントにて計上するストーリーポイントを整理し、スプリントをクローズ、新規スプリントをスタートさせます
弊社ではタスク管理にはJIRAを利用しています

レトロスペクティブ

概要

チームのスクラム運用について、2週間おきに振り返りを実施しています。(月次でプロダクト全体の振り返りを別途実施しています。)

1週間おきだと振り返り項目を捻出するのが大変、1ヶ月おきだと記憶が曖昧になってしまうことから、我々のチームでは隔週で振り返りを実施するスタイルに落ち着きました。

振り返り手段についてもKPTやセイルボートを順番に利用し、違った観点からの振り返りになるように工夫しています。

内容

■ KPT

主に各フローにおけるボトルネックを可視化して、改善プロセスを検討するために実施しています。セイルボートと比べるとより具体的な話に発展しやすいので、ネクストアクションを決めやすい利点もあります。

機能開発のフロー単位で、それぞれにおけるKeepやProblemを各自記載する

記載された内容を確認してリアクションをつける

ファシリテーターがリアクションが多いものやピックアップした方がよいものについて取り上げて議論

その中でTryを決める

■セイルボート

主にチームを俯瞰的に見て改善プロセスを検討するために実施しています。また、KPTに比べてポジティブなフィードバックも得やすい形になっているので、チーム内で日々の感謝を伝えやすいことも利点になっています。

以下の項目に対して各自記載する

記載内容に対して投票を行い、取り上げる優先順位を決める

投票結果に応じて内容を取り上げて深ぼっていく

項目	概要
宝	振り返り期間で目標だったことや、今後目指すチーム、向かっていく理想的な状況
星	プロジェクトに好影響を与えたメンバーへの感謝 (メンバー単位)
風	プロジェクトを前進させるのに貢献しているプロセスやスキル、状況 (チーム単位)
アンカー	個人・チームにとってプロジェクトを推進する上で妨げになっていること
サメ	今後避けたい潜在的なリスクや注意したい落とし穴

Dog Fooding

概要

テストフェーズに入る前にチームメンバーで事前にデバッグをすることで、仕様の考慮漏れや実装の漏れがないかを確認します。また、「仕様通りではあるが、実際に使ってみると違和感がある」などのフィードバックもここで検知することで、カスタマーにより良い価値を提供するためにも効果的に機能しています。

Dog Foodingを実施することで、QA期間のスケジュールが安定し、手戻りも減らすことができています。

内容

■ 事前準備

実施時間までに各OSで次バージョンリリース予定のアプリをStaging配信しておく

この際、動作確認に必要なAPIもStagingにデプロイしておく

配信されたアプリを各メンバーは手元にダウンロードしておく

■ 実施

リリースに含まれる予定の機能を中心に動作確認を実施する

各自フィードバックを機能単位でNotionに記載していく

一通り確認したら、見つかった不具合や気になりポイントに対して、対応の優先度や実施有無、仕様の変更などの方針を決める

■ 事後対応

バグや修正点が見つかった場合は、対象案件のチケットに紐づく形でDog Foodingチケットを切る

Dog Foodingにて見つかった内容と分かるように、prefix付きでチケットを切る (ex. [DF] hoge)

仕様の変更可能性が見つかった場合は、Slackなどでやり取りを行い方針を決める

必要に応じてスポットでMTGを実施する (とにかく早く方針をFixさせる)

実施が決まったチケットを担当メンバーが確認して対応を実施する

修正が完了するまではQAに回さないので、必要に応じてリリースタイミングを調整することもあります
Dog Foodingチケットについては、修正した人が責任を持ってクローズする運用にしています

テストフェーズでは別途テストケースに則る形で確認するため、QAエンジニアの確認は省いています

月次振り返り

概要

隔週のレトロスペクティブとは別に月次で振り返りを実施しています。

こちらでは「プロダクト目標進捗」「開発生産性・技術課題」「品質」の3つの観点で振り返ります。1ヶ月単位で、チームの成果とそれに紐づく目標の進捗と現在地の確認をメインで行います。

内容

■ プロダクト目標進捗

主にPMからプロダクト目標に対しての進捗状況を共有します

開発してリリースした施策が実際どのように目標に寄与したのかを確認したり、目標達成に向けて現在地を確認し、次月どういう動きをしていきたいかを議論します

■ 開発生産性・技術戦略

開発生産性

主にEMからリリース案件やモニタリング指標の共有と、開発生産性に対するまとめを共有します
チームの健康状態を確認したり、次月どういう動きができるとより生産性を向上できるかについて議論します

技術戦略

EM、テックリードから各プラットフォームごとの技術戦略の進捗状況を共有します
基本的に機能開発と並行して技術的な対応を進めているので、PMに状況を共有した上で必要なすり合わせを行います
特に機能開発に影響がありそうなものや緊急度の兼ね合いで優先してリソース割く必要があるものなどはどう進めていくべきか議論します

■ 品質

主にQAエンジニアから本番障害率・Regression障害率・初期品質の3つの観点で品質に関するまとめを共有します

それぞれの項目で特に振り返りたい項目について掘り下げていき再発防止に向けた議論します

読み合わせ会

概要

要件が複雑だったり、ボリュームがあるような案件に対して、認識を合わせる場として、必要に応じて読み合わせ会を実施しています。

プランニングで決定した案件の担当メンバーで集まって、PM/デザイナーからFigmaを中心に仕様やデザインを共有します。実装に着手する前に仕様の漏れがないか、実現したいことは実装可能か、または工数感が見合っているのかなどを議論します。

上記に加えて、エンジニアからDev Docを元にしたより実装ベースの詳細な仕様のすり合わせを別途実施する場合もあります。弊社では最小スコープで最短でカスタマーに価値を届けることを大事にしています。

内容

■ 共有

まずFigmaを用いて、主にPMから実現したい内容とそれに伴うデザインについて一通り共有します

■ すり合わせ

共有された内容を踏まえて、主にエンジニアから仕様や優先度の確認や工数感の共有を行います

その中でよりすばやく効率的に価値を届けることができる形に実装方針を決めていきます

まとめ

今回は直近チームで運用してきたスクラムについて、イベント単位で紹介させていただきました。

これまで日々試行錯誤をしながら、より良い形を模索してきました。その結果、チームで開発してきたアプリは2024年4月でリリース2周年を迎え、ダウンロード数は累計で16万を超え、レビューもAppStoreで4.7と高い評価をいただくことができています。

私たちは引き続き、「あたらしい旅行を、デザインする。」というミッションの実現に向けて、さらにプロダクトを進化させていきます。

そして今、スケーラブルなチーム体制を構築し、さらにスピード感を持って開発をドライブしていくフェーズに来ています。

まだまだ、ミッションを実現するために取り組むべき課題は多くある中で、いかに早く、より良いものをカスタマーに届けることができるかは日々のスクラム運用がカギを握っています。

今後チーム体制を見直す中で、これまで培ってきたスクラム運用をベースに生産性の高いチームを再現性高く増やしていけるかが、新たなチャレンジになると思っています。

ありがたいことに順調な形で2周年を迎えたNEWTですが、もっと多くのカスタマーにしっかり価値を届けられるプロダクトを目指して、引き続きコミットしていきたいと思います。

明日、DAY16のNEWT 2nd ANNIVERSARY CALENDARは、対談企画第6弾！トラベルコンシェルジュチームの伊藤と佐野の対談をお届けします。日々お客さまと向き合うなかでこだわっていること、令和トラベルだからこそ実現できている価値、そしてこの1年間のチームの成長と変遷について、それぞれの立場から語ります。明日もぜひご覧ください！

『NEWT 2nd ANNIVERSARY CALENDAR』についてはこちらから。

NEWT 2nd ANNIVERSARY CALENDAR を開催します！

https://engineering.reiwatravel.co.jp/blog/Advent-Calendar-kickoff