こんにちは！Wantedly Visit Culture Squad / Mobile Chapterの朴（パク）です。

現在はWantedlyアプリのAndroidをメインに担当しているモバイルエンジニアです。2020年4月に新卒エンジニアとしてキャリアをスタートし、2025年5月にウォンテッドリーに入社しました。

先日、Mobile勉強会で「iOS/Androidのリリースワークフロー統一」というテーマで発表を行いましたので、その内容を紹介したいと思います。

はじめに

さて、皆さんのチームではアプリのリリース作業をどのように行っていますか？モバイルアプリの場合、複数プラットフォーム（iOS/Android）で展開されるケースが多く、プラットフォームごとにリリース手順が異なることで担当者の負担が大きくなってしまうことは珍しくありません。

本記事では、私たちが直面した課題と、それをどのように解決してチームの開発体験を向上させたのかをご紹介します。リリース作業の属人化や学習コストの高さに悩んでいる方の参考になれば幸いです。

序論：リリースワークフロー統一が必要になった背景

私たちがフロー統一に踏み切った背景には、開発体制の大きな変化がありました。主に以下の3つの出来事がきっかけとなっています。

• 2025年12月のチーム再編：以前は「Mobile Growth Squad」という1つのチーム（業務委託を含め8名）で開発していましたが、組織変更により4つのチームに分割されることになりました。
• モノレポ化の推進：それまでiOS、Android、そして共通ロジックを別々のリポジトリや管理下で扱っていましたが、これらを一つのリポジトリで開発する「モノレポ化」を行いました。
• リリーストレインの導入：チームが分かれたことで、「誰がどのチームから出しても、毎週同じリズムで安全にリリースできる仕組み」が必要になりました。そこで、「電車（リリース）は毎週決まった時間に発車する。乗り遅れたら次を待つ」というリリーストレインを導入しました。

リリーストレインのスケジュールは次のようなイメージです。

※リリーストレインのスケジュールはその後の運用で少し変動していますが、本記事では分かりやすさのため、当時の「水曜にリリースブランチ作成・QA依頼」のスケジュールに揃えて説明しています。

この新しい体制で直面したのが、プラットフォームごとのフローの分断という大きな課題です。以前は週ごとに1人の担当者がiOSとAndroid両方のリリース作業を行っていましたが、プラットフォーム間でリリース手順が全く異なり、学習コストが非常に高い状態でした。さらに、手順の自動化レベルにも差があり、実質的に「iOSのトレイン」と「Androidのトレイン」という2つを別々に管理しなければならず、担当者に重い負担がのしかかっていました。

本論：リリースワークフロー統一へのアプローチ

この属人的で複雑な状態を打破するため、「プラットフォームごとに分断されていたGitHub Actionsやスクリプトを抽象化し、統一されたパイプラインを提供できないか」と考え、ワークフローの統一プロジェクトをスタートしました。

1. 手動・自動ステップの洗い出しと自動化レベルの統一

まずは、iOSとAndroidのリリース手順をそれぞれ洗い出し、どこが手動でどこが自動化されているかを可視化しました。

当時の状況では、iOS側はリリースブランチの作成やバージョン更新、PR作成などが自動化されていたのに対し、Android側は手動での作業（issue作成、バージョン更新など）が多く残っていました。洗い出しの過程では自動化レベル以外の「分断」も見えてきました。CI/CDはiOSがGitHub Actions + Bitrise、AndroidがCircleCIとまったく別の構成で、リリースissueテンプレートの言語すらiOSは英語・Androidは日本語と不統一だったのです。

統合の第一歩として、まずはAndroid側の手動ステップを自動化し、両プラットフォームの自動化レベルを揃えることから始めました。

2. パイプラインの段階的な結合

自動化レベルを合わせた後は、別々に動いていたフローを一つのワークフローとして統合していきます。いきなり巨大な統合スクリプトを作るのではなく、結合できそうな部分から小さく結合し、試行錯誤を繰り返しながら徐々に改善を進めました。最終的には、入力されたプラットフォーム（platformの指定）によって処理が分岐する、統合されたGitHub Actionsのワークフローを構築しました。

実際のワークフローの起動部分（workflow_dispatchのinputs）は以下のようになっています。

name: Prepare Release
on:
  workflow_dispatch:
    inputs:
      release_date:
        description: 'Release date (YYYY-MM-DD format, e.g., 2026-02-17)'
        type: string
        required: true
      platform:
        description: 'Which platform to release?'
        type: choice
        options:
          - both
          - ios
          - android
        default: both
        required: true
      ios_version_type:
        description: 'iOS version type (ignored if platform is android)'
        type: choice
        options:
          - patch
          - minor
          - major
        default: patch
        required: true
      android_version_type:
        description: 'Android version type (ignored if platform is ios)'
        type: choice
        options:
          - patch
          - minor
          - major
        default: patch
        required: true

前提として、visit-appではgit-flowをベースにしたブランチ運用を採用しています。普段の開発はdevelopブランチに集約し、リリース時にdevelopからrelease/{date}ブランチを切り、Store公開のタイミングでmasterへマージします。リリース内容はdevelopにも還元します。

develop
    ↓ リリース対象の feature branch をマージ
release/{date}   ← Prepare Release ワークフローが自動作成
    ↓ Store審査完了 & リリース日にマージ
master  ← release/{date} をマージ（Store公開・タグ作成）
develop ← release/{date} をマージ（リリース内容を還元）

統一後のフローでは、担当者がこのPrepare Releaseワークフローを1回実行すると、リリースは次のように進んでいきます。

1. release/{date} ブランチが自動作成され、iOS/Android両方のバージョンが自動更新される
2. ブランチへのpushを検知して、iOSはBitriseがApp Store Connectへ、AndroidはCircleCIがFirebase App Distributionへビルドを自動配信する
3. release/{date} → master / develop のPRも自動作成される
4. 担当者はリリースノートの更新とQA依頼・iOS審査提出を行う（ここは判断が必要なため、意図的に手動にしている）
5. 審査完了後にPRをマージすると、タグ・GitHub Releaseの作成とGoogle Playへのproductionデプロイが自動実行される
6. 段階リリースは、iOSではApp Storeの段階的リリース（Phased Release）で進行し、Androidでは配信割合が毎日自動で引き上げられる（5%→100%）

手動で残っているのは「判断が必要な箇所」だけで、機械的な作業はすべてワークフローに寄せた形です。

3. 統一が生み出した価値

新しい統合ワークフローが完成し、チームメンバー全員がこの新しいリリースサイクルを一通り経験した後、旧フローとの比較を行いました。結果として、目覚ましい改善が見られました。

チェックリスト（手動ステップ）の大幅削減

リリース作業に伴う確認・操作項目の数を大きく減らすことができました。

これにより、1サイクルあたりのチェックリスト項目数は、合計48項目（iOS 31項目 + Android 17項目）から、36項目へと減少しました。約25%の削減となり、作業がシンプルになったことで学習コストやヒューマンエラーのリスクを大幅に抑えることができました。

なお、これは単純に項目を減らしただけの数字ではありません。審査提出ステータスの確認や段階リリース開始前の確認など、品質ゲートとなるチェック項目はむしろ意図的に追加した上での純減です。ブランチ作成・バージョン更新・PR作成といった作業自体が自動化されているため、実質的な手動作業の削減はこの数字以上に大きくなっています。

リードタイムの大幅な短縮

また、「issue作成からQA依頼まで」にかかるリードタイムも算出しました。ビルド時間や担当者の並行タスクの影響はあるものの、全体としてスピードアップが確認できました。

• 平均リードタイム：約6時間33分から約5時間14分へ（約20%短縮）
• 平均（初回作業者を除外）：約3時間30分から約2時間22分へ（約32%短縮）

新しいフローを初めて触る際の学習コストを含めても20%短縮されており、慣れた状態（初回除外）で比較すると約1時間強短縮しています。

チームの実感

数値だけでなく、実際にリリースを担当したメンバーからも、負荷が軽減されたという声が集まりました。

これまでは両OSで別のフローで申請する必要があり、担当週の水曜日はほぼ申請作業に時間を使っていたが、実際の作業時間は2〜3時間ほどでQA依頼まで進められるようになった

今まで別々のissueで対応していたリリースフローが統一されたことにより、かなりシンプルなものになり、リリース作業が重く感じなかった

Android側のリリースに慣れていないが、今回の改善でとてもスムーズになった

担当した全メンバーが負荷軽減を実感しており、「水曜日がほぼ申請作業で潰れる」状態から脱却できたことは、リードタイムのデータとも整合する結果となりました。

結論：リリースは「作業」ではなく「仕組み」である

今回のリリース統一プロジェクトを通して、エンジニアとして問題に気づき、仕組み化し、それを文化にすることの重要性を改めて強く感じました。

振り返ってみると、時間短縮という数字以上に本質的だったと感じる成果が3つあります。

• ヒューマンエラーの削減：手動で行っていたブランチ作成・バージョン更新・PR作成を自動化し、オペレーションミスのリスクを低減できた
• ワークフローの保守コスト削減：iOS/Androidで重複していたワークフローが一本化され、保守・改善の対象がひとつになった
• 心理的負荷の軽減：iOS/Androidを別々に管理する認知負荷がなくなり、担当者の精神的な負担が大幅に減った

リリースを人間が頑張って遂行する「作業」として捉えるのではなく、誰でも安全に実行できる「仕組み」へと昇華させること。「人が楽をできる仕組み」を整えて、チームがより本質的なプロダクト開発に集中できる環境を作ることが何よりも大切です。

そこから生まれた『挑戦のための時間』を最大化することこそが、ユーザーへ最速で最高の価値を届ける最短経路になると私は信じています。

終わりに

本記事では、複数プラットフォームにおけるリリースワークフロー統一の事例をご紹介しました。開発組織が拡大したり、リポジトリ構成（モノレポ化など）が変わったりするタイミングは、既存のプロセスや負債を見直す絶好のチャンスです。

なお、本記事で紹介したリリーストレインやgit-flowといったフレームワークは、あくまで手段のひとつです。必ずしもそのルールに従わなければならないものではなく、チームの状況に合わせて形を変えて構いません。大切なのは、誰かが「手間がかかる、本質的ではない」と感じている作業を、ルーティンやルール、そして自動化によって少しでも楽にすることだと考えています。AIの普及で開発は確かに便利になりましたが、だからこそ、人が不便を感じている部分をさらに便利にして、チームを横断して改善が広がっていく環境をつくっていきたいです。

前回の記事「『伝わる』GitHub PRと『育てる』レビューコメントの書き方」でも触れたように、少し時間はかかっても、こうした仕組み化や文化づくりは間違いなく未来への投資になります。皆さんのチームでも、日々の「作業」の中に仕組み化できる課題がないか、ぜひ一度見直してみてください。

最後までお読みいただきありがとうございました。