こんにちは！
開発部の冨永です。
現在SODAには30名弱のエンジニアが所属をして、サービスの改善を行っております。
今回はどのような判断で現在の体制やプロセスに至ったのかをご紹介したいと思います。
チーム体制や開発プロセスの考え方に共感いただけた方は弊社にマッチしていると思うのでぜひご連絡ください！
立ち上げフェーズ
2021年までは CTO の佐藤と 現VPoE の林の2名のエンジニアの体制で開発をしており、経営陣が PdM を兼任し機能開発を進めていました。
立ち上げフェーズでは、少人数だったのでチーム開発というよりも各タスクを1人のエンジニアが担当して実装していくことを意識して開発を進めていました。
複数チームでの開発
2021年から徐々に新しくエンジニアがジョインをしてくれましたが、
開発スタイルは大きな変更はせずに、基本的に1つのタスクを1人のエンジニアが担当し、いわゆるリソース効率を重視した開発をしていました。
人数が増えるに従ってチーム分割は行っていましたが、
徐々に「実装対象について把握していることが少なくレビューコストが上がる」、「開発スケジュールの長さも見積もりが属人化していることによって人による差が顕著になり、次第にスケジュールが不安定になる」など開発における問題が露呈してきました。
アジャイル開発の導入
事業を伸ばすために機能を最速でリリースすることを意識して開発してきましたが、
組織が拡大するにつれて「中長期的にプロダクトスケジュールを決めれるよう出来るだけスケジュールは正確に」、「しっかり実装方針を検討して手戻りもバグも無い安全な状態を目指そう」といったことを意識する必要が出てきました。
徐々に出できた問題や組織拡大してきたことを考慮して、2022年3月に開発プロセスを見直しました。
当時専任の PdM がいないなどの組織の状況を考慮して、「スクラムを導入するのではなく、スクラムの考え方・手法を取り入れること」、「スピード感は落としすぎず正確性と安全性を獲得すること」を意識して改善しました。
また、各チームが開発プロセス改善していける状態を作るために、
Four Keysやサイクルタイム、Velocity（Sprint中に消費できる合計Story Point）、PR作成数などのメトリクスを Findy Team+ や Notion のDatabase/Viewを使って可視化・分析をできるようにしました。
以前のブログでメトリクスの可視化の取り組みについて紹介しました。
PdMとエンジニアを1つのチームに
開発のプロセスは改善したのですがエンジニアの人数も増え並列で実施するタスクの量が多く「PdMと開発スケジュールに関するすり合わせ・調整に必要以上に時間がかかる」などのコミュニケーションの問題が発生してきました。
調整コスト増大に繋がってしまっていた原因として、「エンジニアチーム」と「PdMチーム」のように2つのチームがチーム間連携を行うことでプロダクト開発を進める、という体制に実質なっていたことが挙げられます。
そこで、1つのエンジニアチームに対して1人のPdMが担当として付くことで、エンジニアとPdMが一緒に同じチームとして動いていける体制を整備しました。
これによって、それぞれのエンジニアチームで実施していた定例MTGにPdMが参加しやすくなったり、コミュニケーション相手が固定されることで業務をスムーズに進められるようになったりと色々進めやすくなり チームトポロジーで紹介されているストリームアラインドチームに近い体制になりました。
以前のブログでこちらの取り組みについて紹介しました。
各チームが独自に進化
現在は、前述のメトリクスの可視化や、各チームの担当ドメインの違いによりチームごとに自分たちに合った開発プロセスに改善していっています。
一例として以下のようなことを行っています。
- Four Keys における「変更のリードタイムの改善」を目的にプルリクエストの粒度を小さくする
- 社内向けの機能を開発するチームでは、ステークホルダーと連携するためスプリントレビューを実施
- 連携が必要な部署のKPIを開発者が認識できるようにミーティングを実施
- フロー効率の改善や知見の共有を目的にチームでペアプロやモブプロを定期的を実施
- 見積もりをプランニングポーカーで行う
- 振り返りの方法を改善 (KPT、なぜなぜ分析 などを試してみる)
- オンラインのホワイトボードツールを使うなどミーティングの進め方改善
また、週に1度のエンジニア全体のミーティングで各チームの取り組みを共有していることや、振り返りなどの議事録が Notion 上でオープンになっていることから、他のチームで良かったことを取り入れるといったことも頻繁に行われています。
開発チームをサポートするチームの発足
また、エンジニアの人数が増えてきたこともあり、機能追加をしていると手が回らない領域が出てきたのでチームトポロジーで紹介されている、イネイブリングチームやプラットフォームチームに近い以下のチームが発足しています。
| チーム | 取り組み |
|---|---|
| EM | 各チームのプロジェクトマネジメント力の向上を支援、ピープルマネジメントを通じて事業成長を実現 |
| SRE | SLO/エラーバジェットの策定・運用といったより専門的なDevOpsに取り組む、各チームがDevOpsをより高水準でしていけるための支援 |
| Security | ユーザ様や取引相手に安全性を提供するためのセキュリティレベル向上 |
| QA | ユーザへの価値提供における品質とスピードを最大にすべく、リリース前の検査に留まらず開発プロセス全体に対してQAの観点を強化 |
今後について
現在デザイナーは4名の独立したチームになっていて、各開発チームやマーケターから施策ごとにクリエイティブの依頼が飛んでくる状況になっています。
今後はPdMとデザイナーとエンジニアが一つのプロダクト開発チームとして協力して、事業戦略の達成に動けるような体制にしていきたいと考えています。
最後に
▼下記ではより詳しく弊社のプロダクト開発組織について紹介してますので 是非ご覧ください！
またSODAでは特にエンジニアを積極的に採用しておりますので
少しでも弊社に興味を持っていただけましたらご応募お持ちしております！
▼詳しい会社情報はこちらから
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion
本当に入社をしたいですが、まだ自分の能力が足りないと思います。 いろいろ気になる点があります。
1.もし、ぜひ知って面接に来てほしいと思うことはありますか？（Flutter、開発希望）
2。 ネイティブアプリケーションの経験のない人の場合、どんなことを勉強すればいいでしょうか？
3。他の開発的な質問ですが、今個人プロジェクトで天気別の製品おすすめ、個人の好みによって製品おすすめアルゴリズムを作ろうとしていますが、バックエンドの能力が良くありません。
ヒントをいただけますか？