dely Tech Blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

クラシルリワードの開発体制について

クラシルリワード開発

こんにちは！クラシルリワードで開発責任者をしているfunzinです。 この記事ではクラシルリワードの開発体制についてお話ししていきます。 カジュアル面談や面接でどのような開発体制かを聞かれることが増えてきたため、こちらに記事としてまとめていきます。

プロダクトの開発方針

クラシルリワードのプロダクトの開発方針として、「仮説検証を早く回して、スピード感のある開発組織に」を掲げています。

プロダクト開発をする上で、下記のような状況に一度は遭遇したことがある方も多いかと思います。
e.g. 数ヶ月かけて開発をした施策が、結局ユーザーに使われなかった

DALL-E 3で生成した画像

クラシルリワードはまだリリースして1年半ほどのサービスで成長途中なこともあり、まだまだ機能が足りていない箇所がたくさんあります。 そのため施策を早くリリース、検証、改善していく流れがとても重要となります。

次の章でどのような開発体制でスピード感のある開発組織を実現しているかを紹介していきます。

開発体制

1. スモールチーム開発

2024/1現在、下記のような開発体制で行っています。

2024/01現在のチーム体制

大きく機能開発チームと横断チームに分かれています。
機能開発チームでは職能別で5名ほどのチームを作り、機能開発を行っています。 チームトポロジーでいう、ストリームアラインドチームに近しいです。
原則機能開発チーム内で施策や開発プロセスを全て完結するようにしています。

機能開発チーム

このようなチーム体制にしている意図としては下記です。

  • 目標KPIに対して、機能開発チームで責任を持つ
  • 少数精鋭でやり切る
    • チーム内に人数が多くてもタスクのお見合いやコミュニケーションパスの複雑性が発生する
    • 各ポジション1名を基本として、足りない領域はチームでカバーする

どのように機能開発チームが運用されているかは、こちらの記事をご覧ください。
クラシルリワードのプロダクトマネージャーの1週間はどんな感じ？

2. 毎日リリース可能な体制

施策を早く検証する上で、リリース頻度はとても重要になります。 そのため各領域で毎日リリースができる体制を整えています。モバイルとサーバーサイドでのリリース頻度は下記のようになっています。

  1. モバイル(iOS, Android)
    • 各機能開発チームがリリースしたい施策がある場合、いつでも審査提出が可能な状態
    • 週によっては5回リリースしている日もある(平均週2ペース)
      iOSのリリースログ
  2. サーバーサイド
    • GitHub ActionsとAWS CodeBuildを活用し、mainブランチにマージしたタイミングでリリースフローが実行される

高頻度なリリースを実現する上で、下記のようなことに取り組んでいます。

  • PRの粒度を小さくして、早くマージする(レビューの負担を減らす)
    • チーム全体が共通の認識を持つことでPRサイズを小さく保ち、レビューが早くなる
    • ヘルスチェックとしてOffersMGRを利用して、FourKeysのチェックも行っています
      とあるチームのFourKeys
    • 職能のLDRが隔週でFourKeysのレポートをしています
  • FeatureFlagを利用したトランクベース開発を活用
    • 開発環境では常に新機能が確認できる状態(mainブランチに含まれるため)
    • 開発中の施策をTestFlight・Firebase App Distributionで配布することで動作確認を行い、すぐにリリースできるようにしている
  • 細かくリリースし続けることでQAスコープの対象も小さくする

3. CRMツールを活用した施策検証

施策をする上で第一に機能開発をすることを考えますが、新しい機能を開発する前にCRMツール(KARTE, Repro)を活用できるかを考えます。
e.g. RemoteConfig, プッシュ通知、ポップアップなど

CRMツールを利用して開発工数を抑えて検証が行えるのであれば、それらを利用するがベストです。 これによって、実際に開発してみたけど使われなかったといった問題も防ぐことができます。

実際にどのようなユースケースがあるかを紹介します。

ユースケース: おすすめ運用枠の検証

  1. 運用枠などをRemoteConfigで表示(CTR/CVRの検証)
  2. 上記で効果が見込めるかつ、運用し続ける場合は、API化や管理画面の入稿できる対応を検討する

運用枠の効果が見込めない場合は、1の検証のみで終了し2の開発工数を抑えることができます。 施策をする上で自分たちで全てを実装する以外にCRMツールを活用することで開発工数を抑えた検証が行えます。

4. CopilotやChatGPTなどの生成系AIを活用

生成系AIを活用することで、開発の効率化を図っています。
エンジニアチームにはGitHub Copilotを導入し、コーディングの開発の負担を減らしています。
また施策を分析する上で、クエリを書く機会が多いですがこちらも補完が効くため重宝しています。
(Copilotはコードだけでなく文章の補完もできるので、このブログの下書きにも利用しています。)

今までは社内の利用規則に基づいて個々人がChatGPTを使っていましたが、1月にChatGPT Teamが出たため、さっそく導入し活用できなかったビジネスデータをChatGPT上で利用し始めています。
下記のような社内専用のGPTsを作って、各チームで利用できる形にしていきたいと考えています。
e.g. リリース文言、施策案、クエリ補助

まだTeamプランは導入したてなこともあり、実際導入してみてどうだったかは別の機会に紹介できればと思います。

5. M3 Maxの導入

最後にPCのスペックについても触れさせてください。
今までエンジニアはM1 Maxを利用していましたが、検証端末でアプリのビルド時間の計測を行い、投資値効果があうと判断したためM3 Maxを2024/4から導入予定です。
検証機としてM3 Maxを2台購入し、iOSアプリでのクリーンビルド時間がM1 Maxに比べて半分(2min -> 1min)になったため上記のような意思決定を行いました。

M3 Maxは下記2つのサイズで選択できるようにしています。

1. 14インチ
    - 16コアCPU、40コアGPU、16コアNeural Engine
    - 64GBユニファイドメモリ
    - 1TB SSDストレージ
2. 16インチ
    - 16コアCPU、40コアGPU、16コアNeural Engine
    - 64GBユニファイドメモリ
    - 1TB SSDストレージ

純粋にマシンスペックを上げることも、開発生産性において重要な意思決定の一つです。

まとめ

クラシルリワードの開発体制について紹介してきました。 クラシルリワードでどのようにプロダクト開発を行っているかのイメージがもし伝われば幸いです。