こんにちは！AppBrewでエンジニアとして働いているあっきーと申します！

2024年2月で創業8周年を迎えるAppBrewでは、1,100万DLを超えるLIPSというサービスの開発・運営を行っています。そんなLIPSを支える開発チームとはどんな組織で、どんな開発スタイルなのか、そしてどのような評価制度が設けられているのかについてご紹介いたします！
「これいいな！」と思った箇所を参考にしていただくのはもちろん、「AppBrewで働くことに興味があるかも」と感じていただける方に向けて、弊社での働き方を具体的にイメージしていただけるよう、この記事を執筆しました！ぜひ最後までお読みいただけますと幸いです。

LIPS を創る開発組織

これらのプロダクトの開発・運営を担当しているのが「プロダクト部」と呼ばれる部門で、記事執筆段階でフルタイムメンバーだけでも30人規模になっています。プロダクト部は6つのチームで構成されており、開発業務を行うのは「toCユニット」、「DX支援事業ユニット」の2チームとなっています。これらの開発チームではスクラムを採用しています。

toCユニット

• LIPS の iOS, Android アプリの開発
• • LIPS for iOS
  • LIPS for Android
• LIPS の Web 版と、LIPS SHOPPING（Web）の開発
• • LIPS for Web
  • LIPS SHOPPING
• メンバー
• • iOS Engineer
  • Android Engineer
  • Frontend Engineer
  • Backend Engineer
  • Designer
  • Manager

DX支援事業ユニット

• LIPS の BtoB 領域開発
• • LIPS for BRANDS
• メンバー
• • Frontend Engineer
  • Backend Engineer
  • Designer
  • Manager

このように、ユニットは事業領域毎に分けられていますが、施策によってはユニットを横断する形で開発を担当することがあります。例えば、BtoB 領域の施策でアプリ側の実装が必要になった場合などです。また、マルチスタックに活躍するメンバーも多く、「普段はバックエンドを担当しているが、必要に応じてアプリの開発も行う」というケースも少なくないです。

目標設定と評価

AppBrew では四半期毎に目標設定・チーム編成・評価・振り返りのサイクルを回しています。
会社全体での事業戦略は全社員に向けて共有する場が設けられます。これを元に各チーム毎に OKR を用いた目標設定を行い、必要に応じてチーム編成の見直しが行われます。そして、この目標に対してチームが走り出します。詳細は次のセクションでご紹介します。

AppBrew流スクラム開発

ここからは、フルタイムメンバー11名と、最も人数の多い「toCユニット」を例に開発体制をご紹介します。toCユニットでは主に LIPS の iOS版、Android版、Web版 を開発しており、アプリエンジニアとフロントエンド・バックエンドエンジニア、デザイナーが在籍しています。この規模感のチームを支えるのは、スクラムをベースとする開発体制です。少し特殊な点としては、エンジニアがマネージャを兼任する形でマネジメントを行っている点が挙げられるかもしれません。

2週間1スプリントのスパンで、プランニング・デイリースクラム・スプリントレビュー・レトロスペクティブを実施しています。これらのイベントは基本的には「toCユニット」のメンバー内で実施しますが、例外的にスプリントレビューは「プロダクト部」の中で開発業務を行う2チーム合同で実施しています。前述したように、アプリ開発は BtoC に限らず、BtoB 文脈でも必要になるなど、連携を必要とする場面が少なからずあるという背景からこのような開催形態に辿り着きました。

プランニング

デイリースクラム

スプリントレビュー

レトロスペクティブ

スプリントレビュー後にはレトロスペクティブを実施し、Keep・Problem・Try の3項目に分けてスプリントを振り返ります。例えば「Apple の新製品を買って開発意欲が100倍になった！」のように、自由度高く記載してもらうことを意識しており、Problem として出た課題感に対してユニークな解決策が上がることもあります。この時間で出た Keep と Try を元に来スプリントのプランニング草案を準備し、1つのスプリントを終えます。

今回ご紹介したスクラムを採用するに至った経緯の一つとして、業務プロセスの言語化や共通理解が不足しているという課題を解決する必要がありました。目標設定、施策の優先度判断、スケジューリング、進捗共有、振り返りといった各プロセスが不明瞭だと、特に体制変更やタスク分担に弱くなってしまいます。実際に、スクラムを導入することによって、各チームメンバーが「今自分が何に責任を持てば良いのか」を認識できるようになり、チーム全体でのパフォーマンス向上に繋がっていることを実感しています。

ここまで弊社の開発組織と開発体制を紹介しました。ここで紹介した内容はほんの一部に過ぎず、毎スプリント毎に様々な課題点が出ては改善を試みるというサイクルを繰り返しています。こうしたトピックごとの記事も引き続き執筆していきますので、今後もぜひご覧ください。

「スクラム開発」と言っても会社によって様々な色があるものです。この記事を通して AppBrew の色を少しでも感じ取っていただけたら嬉しいです。AppBrew では全職種積極採用中です。少しでも気になったな！メンバーの方と話してみたいな！と思っていただけましたら、以下よりご連絡ください！ご応募お待ちしています。