こんにちは！AppBrewでエンジニアとして働いているあっきーと申します！
2024年2月で創業8周年を迎えるAppBrewでは、1,100万DLを超えるLIPSというサービスの開発・運営を行っています。そんなLIPSを支える開発チームとはどんな組織で、どんな開発スタイルなのか、そしてどのような評価制度が設けられているのかについてご紹介いたします！
「これいいな！」と思った箇所を参考にしていただくのはもちろん、「AppBrewで働くことに興味があるかも」と感じていただける方に向けて、弊社での働き方を具体的にイメージしていただけるよう、この記事を執筆しました！ぜひ最後までお読みいただけますと幸いです。
LIPS を創る開発組織
AppBrew では LIPS という美容プラットフォームを開発しています。詳しくは C 向けの「LIPS」と B 向けの「LIPS for BRANDS」の2つに分けられ、「LIPS」は Web, iOS, Android、「LIPS for BRANDS」は Web での提供を行っています。
これらのプロダクトの開発・運営を担当しているのが「プロダクト部」と呼ばれる部門で、記事執筆段階でフルタイムメンバーだけでも30人規模になっています。プロダクト部は6つのチームで構成されており、開発業務を行うのは「toCユニット」、「DX支援事業ユニット」の2チームとなっています。これらの開発チームではスクラムを採用しています。
toCユニット
- LIPS の iOS, Android アプリの開発
- LIPS の Web 版と、LIPS SHOPPING（Web）の開発
- メンバー
- iOS Engineer
- Android Engineer
- Frontend Engineer
- Backend Engineer
- Designer
- Manager
DX支援事業ユニット
- LIPS の BtoB 領域開発
- メンバー
- Frontend Engineer
- Backend Engineer
- Designer
- Manager
このように、ユニットは事業領域毎に分けられていますが、施策によってはユニットを横断する形で開発を担当することがあります。例えば、BtoB 領域の施策でアプリ側の実装が必要になった場合などです。また、マルチスタックに活躍するメンバーも多く、「普段はバックエンドを担当しているが、必要に応じてアプリの開発も行う」というケースも少なくないです。
目標設定と評価
AppBrew では四半期毎に目標設定・チーム編成・評価・振り返りのサイクルを回しています。
会社全体での事業戦略は全社員に向けて共有する場が設けられます。これを元に各チーム毎に OKR を用いた目標設定を行い、必要に応じてチーム編成の見直しが行われます。そして、この目標に対してチームが走り出します。詳細は次のセクションでご紹介します。
評価制度としては360度評価を採用しており、チームや立場の違うメンバーが互いに評価し合います。まず、評価期間の振り返りシートを作成し、直近の上長とチームメンバー、可能であれば違う部署で関わりがある人など、3〜5人を目安に自身の判断で評価者を選び、評価依頼を出します。評価リクエストを受け取った人は、その振り返りシートとグレード定義を元に評価をすることになります。上記の画像は、実際の評価入力フォームです。
評価をすることに慣れていない人にとっては責任重大で難しい作業に感じるかもしれません。しかし、メンバーによって異なる評点の重みを均一化する仕組みが評価システムに導入されていたり、評価指針となるグレードが明確に決まっているため、勤続年数や立場に関係なく評価に参加することができます。
実際の評価フローに関してはオープンポータルにて一般公開していますので、合わせてご覧ください。
AppBrew流スクラム開発
ここからは、フルタイムメンバー11名と、最も人数の多い「toCユニット」を例に開発体制をご紹介します。toCユニットでは主に LIPS の iOS版、Android版、Web版 を開発しており、アプリエンジニアとフロントエンド・バックエンドエンジニア、デザイナーが在籍しています。この規模感のチームを支えるのは、スクラムをベースとする開発体制です。少し特殊な点としては、エンジニアがマネージャを兼任する形でマネジメントを行っている点が挙げられるかもしれません。
2週間1スプリントのスパンで、プランニング・デイリースクラム・スプリントレビュー・レトロスペクティブを実施しています。これらのイベントは基本的には「toCユニット」のメンバー内で実施しますが、例外的にスプリントレビューは「プロダクト部」の中で開発業務を行う2チーム合同で実施しています。前述したように、アプリ開発は BtoC に限らず、BtoB 文脈でも必要になるなど、連携を必要とする場面が少なからずあるという背景からこのような開催形態に辿り着きました。
プランニング
スプリントのスタートはプランニングから始まります。目標としてチームで決めたOKRを元に、タスクの優先度や規模感の共通認識をチームで作ります。そこから、メンバーがそれぞれ今スプリントで着手・完了予定のタスクを、施策立案・仕様策定・デザイン設計・実装といった単位で細分化します。一定規模のリソースを必要とするタスクは、実装着手前にキックオフという形で仕様の把握と不明点の払拭を目的としたミーティングを実施します。ちなみに、タスク管理は GitHub Project に集約しており、エンジニア以外も GitHub issue を使ってタスク管理を行っています。
デイリースクラム
デイリースクラムでは Notion と GitHub を利用して進捗確認とタスクの方向性の調整を行います。例えば、差し込みタスクが発生した場合には、担当するメンバーの見直しや着手順をその場で変更します。逆に、技術的に苦戦していてアドバイスを求めているメンバーが居る場合には、相談を行うタイミングと参加するメンバーを決めるだけにとどめます。ただ、その場で解決できそうな問題だと思って話し始めたが、議論が白熱してしまう…なんてことも少なくなく、ファシリテーション力が試されます。この問題は、ファシリテーターだけではなく、チーム全体で意識することが重要だと考えており、toCユニットではチームメンバー全員が毎日交代でファシリテートするように工夫しています。
スプリントレビュー
スプリントの最終日にはスプリントレビューを実施します。今スプリントで完了したタスクを共有するのはもちろん、OKR 進捗度の確認もチームメンバー全員で行い、来スプリントに向けた共通の温度感を作ります。この場では、タスクの本質を理解したうえで共有することがチームメンバー全員に求められます。例えば、バックエンド専任のエンジニアであっても、「そのタスクは誰に対するもので、どのような問題を解決するものなのか、そして結果はどうだったのか」を共有しています。この文化は、弊社のバリューである OPEN・OWNERSHIP・LEAN・USER FIRST をメンバーそれぞれが体現できていることを示す一つの特徴かもしれません。なので、エンジニア以外の方でも SQL を書いて仮説・検証を行えるスキルを磨く「SQLテスト制度」というものもあり、詳細は過去記事「SQL学習モチベを爆上げする「SQLテスト制度」を導入している話」にまとめられていますので、ぜひご覧ください。
レトロスペクティブ
スプリントレビュー後にはレトロスペクティブを実施し、Keep・Problem・Try の3項目に分けてスプリントを振り返ります。例えば「Apple の新製品を買って開発意欲が100倍になった！」のように、自由度高く記載してもらうことを意識しており、Problem として出た課題感に対してユニークな解決策が上がることもあります。この時間で出た Keep と Try を元に来スプリントのプランニング草案を準備し、1つのスプリントを終えます。
今回ご紹介したスクラムを採用するに至った経緯の一つとして、業務プロセスの言語化や共通理解が不足しているという課題を解決する必要がありました。目標設定、施策の優先度判断、スケジューリング、進捗共有、振り返りといった各プロセスが不明瞭だと、特に体制変更やタスク分担に弱くなってしまいます。実際に、スクラムを導入することによって、各チームメンバーが「今自分が何に責任を持てば良いのか」を認識できるようになり、チーム全体でのパフォーマンス向上に繋がっていることを実感しています。
ここまで弊社の開発組織と開発体制を紹介しました。ここで紹介した内容はほんの一部に過ぎず、毎スプリント毎に様々な課題点が出ては改善を試みるというサイクルを繰り返しています。こうしたトピックごとの記事も引き続き執筆していきますので、今後もぜひご覧ください。
「スクラム開発」と言っても会社によって様々な色があるものです。この記事を通して AppBrew の色を少しでも感じ取っていただけたら嬉しいです。AppBrew では全職種積極採用中です。少しでも気になったな！メンバーの方と話してみたいな！と思っていただけましたら、以下よりご連絡ください！ご応募お待ちしています。
Discussion