こんにちは。コンシューマ事業部モバイル開発担当の藤原です。

今回は、弊社が提供する「あすけん」のAndroidとiOSアプリについてのデリバリープロセスについてご紹介します。

この記事で伝えたいこと

「あすけん」サービスのモバイル開発は、3つのプロダクトチームで1つのアプリを開発しています。チームごとにユーザー価値の仮説検証サイクルや目的が異なっており、自分のチームの都合だけでリリースすると他のチームへ予期せぬ影響が出てしまいます。弊社において、この課題の解決手段として「リリーストレイン」を採用しており、そのプロセス概要と組織的な基盤の事例をご紹介いたします。同様の課題に直面している方々のご参考になれば幸いです。

この記事で省略すること

内容をシンプルにするため以下のように記載しています。

バックエンドシステムのデリバリーの話は記載しません。
Android, iOSのCI/CDにて利用しているサービスの詳細は記載しません。
プロダクトチームの内容は記載しませんが、詳細についてはこちらの投稿をご参照ください。

「あすけん」モバイル開発のリリーストレイン概要

弊社は毎週水曜にモバイルアプリをリリースしています。

以下の図に示すように、各チームで開発と品質の検証まで済ませておき、締切時点で結合済みの機能をリリースします。

この通り運用すれば、簡単にできる？

いいえ。このプロセスを成立させるためには各チームのエンジニアがチーム横断で協力する必要があります。開発する要件も仕様も違えば、チーム文化も違うエンジニア同士が連携するにはどうしたらいいでしょうか。以下に取り組み内容をご紹介します。

3チームで共同運営するための取り組み

前提：体制

各チームにAndroidとiOSエンジニアがペアで所属しています。PdMを中心に、バックログのリファインメントを始め、仮説検証のための議論やスプリントレビューを通して、ユーザー価値の「Why」や「What」を常に共有しています。一方で、チーム外のエンジニアとはユーザー価値の情報格差が大きい状態です。

施策の競合の回避

「3チームで共同運営」と聞くと、読者の方は第一にソースコードのコンフリクトを想像したと思います。この点について弊社は以下の対策を取っています。

プロダクトチームのPdM同士が事前に施策をすり合わせ、同じ画面を修正する様な事態を避ける
エンジニア同士も、常時モバイル開発ユニット用のSlackチャンネルで連携したり、週次定例ですり合わせる

上記で完璧に回避できる訳ではありませんが、各チームのスクラムタイムボックスが1週間であり、仮に衝突したとしても被害が最小限で済みます。

設計方針の言語化

複数のチームが関与するプロジェクトでは、共通理解が重要です。誰でも理解できるような言語化がされている状態を目指しています。AndroidとiOSでアーキテクチャが異なるため、詳細は割愛しますが、レイヤーやモジュールにおける役割については、全員が共通理解が持つよう対話をしています。また、「意見が割れたらAndroid Developersを参照する」などグランドルールの共通認識を醸成しました。

コードレビューの役割分担

前提に示す通り、他チームのエンジニアが「仕様通りの実装が実現できているか」をレビューで確認するのは難しいです。「同じチームのエンジニアは仕様面を、他のチームエンジニアは設計方針を」という役割分担を全員で議論して決定しました。

ちなみに、同じチームにAndroidとiOSエンジニアが1名ずつ配置されていますので、仕様の実現についてはプラットフォームを越境してソース読解や実装者との対話が行われています。

CI/CDの整備

多い時は1スプリント（タイムボックス1週間）でdevelopへ10回マージが発生することもあります。毎回手動でStaging Buildを行い、アプリ配布のサービスにアップロードするのはロスが非常に大きいです。業務が円滑にまわる最低限のデプロイパイプラインを構築しています（ブランチマージやタグ付をトリガーに配布する、等）。また、Production Buildとアップロードにおいては、手動操作によるミスが重大な事故に繋がる可能性があるためストアへのアップロードまで自動化をしています。

段階リリースとモニタリング

通常、段階的なリリースを行っています。いきなり100％範囲に公開すると、万が一深刻な不具合が流出した際に大きな影響が出てしまうためです。クラッシュの急増や特定のエラーログの検知などでアラートが発生した場合、即座に公開を中止し、hotfixリリースを行います。

ただし、モニタリングに関しては一部は人の手で目視しており、まだまだ改善の余地があります。今後改善していく予定です。

振り返りと適応

スクラムイベントの振り返りとは別に、モバイル職能の横のつながりとして週に1回の振り返りを実施しています。3チームで共同運営するリリーストレインなので、プロセスは定義して終わりではなく、細かく検査と適応をし続ける必要があります。

今週の出来事を振り返り、良い点と悪い点を自覚し、少し先を見据えて状態ゴールに向けた対話を行います。また、今週の具体的なアクションについても議論します。決まったアクションは担当を決め、次週の振り返りで結果を確認しています。

弊社の特徴としては「問題に対する一般論を鵜呑みにせず、自分達にどう適合するのが最適なのかをしっかり議論できている」点です。それは、メンバー各自が「素直に意見を出せている」「結論を行動に反映させている」のが要因です。次節に記載するように、心理的安全性が基盤となり、問題に向き合える組織になっています。

情報格差の解消と心理的安全性

振り返りを起点に改善の学習サイクルを回すためには、自分の意見を遠慮せずにしっかりと表明できる環境が必要です。過去に、お互いの文脈が異なるために意見が食い違っていたケースがあり、そのような状況を改善する必要性を強く感じています。

そのために、様々な手段を用いてお互いの考えを整理し、全員がお互いの考え方を俯瞰できるようにしています。例えば、ブレストで付箋に全員の考えを洗い出し、それをグループ化して整理する方法や、空雨傘を使って考えをロジカルに可視化する方法などがあります。こうした取り組みにより、情報の格差が解消され、余計な認知の歪みが生じにくくなり、安心して対話ができる環境を作り出しています。

思いやりと尊敬

相手を思いやり、尊敬し、励ますことは、信頼関係を築く上で重要です。例えば、「XXさん、大変そう、何か手伝えるかな？」や、「YYさん、いつも頑張っているな」といった気持ちは相手に伝わります。情報格差が無いから相手の状況が理解でき、自然と相手への思いやりや、大変なことや苦手なことへ取り組む人への尊敬が生まれます。このような積み重ねで信頼関係が構築されます。信頼関係があるから自己開示も促進され、失敗や問題を隠さずに共有する文化になっていきます。結果、難しい問題にチームで向き合うことができるようになりました。