エモーションテックの開発体制について(2023年編)

はじめに

こんにちは、Product TeamのManagerのよしだです。今年も年末にエモーションテックの体制がどのように変化したかをご紹介します（いわゆる思い出話です）。チームに対する改善施策数が多く全ては書けないので、特に印象に残ったものだけとなります。

• エモーションの開発体制について(2021年編)
• エモーションの開発体制について(2022年編)

この記事はエモーションテック Advent Calendar 2023の23日目の記事です。

2023年1月ごろ

2022年から開発しているプロダクトのベータ版がようやくリリースされました（開発のエピソードはまた別の機会に）。この時、新製品開発に集中していたため、エンジニアとしての学びや挑戦の機会をどのように増やすかを考えていました。

体制

プロダクトチームの体制は、仮説検証と製品検証を行う２チーム体制を2022年12月から実践していましたが、その体制の中で、機能ごとに2、3名で兼務しながらつくっている状況でした。 職種ごとバックエンド、フロントエンドの情報共有を円滑にするため、テックリードのかどたみが定期的にミーティングを開催することで、機能間の課題を共有することが行えていることを確認していました。

• バックエンド: 7名
• フロントエンド: 6名
• SRE: 2名
• QA: 2名
• デザイナー: 2名
• PdM: 1名

当時の課題

チームの状況は、エラスティックリーダーシップ本でいうところ「サバイバル」状態でした。新機能開発に集中していたためアウトプットは多くなりましたが、インプットへの時間が十分に確保できておらず、各メンバーの成長実感が薄れているのを感じていました。また、社内の他チームの課題に気がつく余裕がありませんでした。

取り組んだ施策

• 開発勉強会
  • 目的
    • 仕事を進めながら学ぶだけではなく、今後遭遇する課題を解決できるように知識を増やす(言われてから慌てて学ぶのではなくビジネスサイドからの要望に「できますよ」と言えるチームになる by テックリード)
  • 仕組み
    • 聞くだけの人はNGとして、参加者はどこか会で発表をするという方法でインプット量を増やせるようにしている
  • 結果
    • 毎月１時間だが継続できている。ちょっと気になっていたけど調べられていなかったことを学ぶことはできていると思われる
• ハッカソン
  • 目的
    • 社内の別チームの課題を技術的に解決し、社内をもっとイキイキさせる
  • 仕組み
    • 社内に溜まっている要望、課題を整理して、Product Team提案型で毎月１日エンジニア全員でなんらかの課題を解決を目指す
  • 結果
    • 一部の課題は解決することはできたが、ハッカソン当日にビジネスメンバーと一緒に進める準備が十分でなかったことや業務改善の効果を高めようとすると１日では難しいこともあり、2023年3月までの３回実施して終了（アプローチを見直し、再度実施したい）

2023年7月ごろ

1月にリリースしたベータ版機能のテストが終わり、既存顧客への提案を開始をするための準備をしていました。また、4月から生成AIをつかったTopicScan サービスの開発にSRE Teamも参加。開発チームの生産性向上のためにGitHub EnterpiseとGitHub Copilotの導入も行いました。

体制

新機能の開発が決まり、仮説検証と製品検証の体制をやめ、機能ごとのチーム体制に変更しました。PdMと私で進めていた開発タスクの優先度の整理は、チームごとで実施するようになり、開発手法の見直しの議論が始まりました。開発手法は、カンバンスタイルとスクラムの要素が混ざった方法（SprintとBacklog Refinementがあるカンバン、ビジネスの変化に合わせて定期的にカンバンの優先度を見直すことを目指していました）。

• バックエンド: 8名
• フロントエンド: 7名
• SRE: 2名
• QA: 2名
• デザイナー: 3名
• PdM: 1名

当時の課題

機能の開発の検討ミーティングとコードレビューなどの時間が多くなり、それぞれが思うように開発が進められていないということがありました。

• 開発手法関連
  • スプリント終了時の成果発表の話し方。成果発表はビジネスメンバーも自由参加できるようにしている。実施した結果だけの報告になってしまい、ユーザーにどんなメリットがあるかわからないという問題があった
  • KPTでそれぞれが思うことの発表だけになってしまい、特に課題のディスカッションができていなかった
• 運用面
  • リリース作業をどうやっていくか
    • 各マイクロサービスのデプロイとリリース内容の社内告知の方法

取り組んだ施策

• 開発手法関連
  • 成果発表の際に以下を意識して話すことにした
    • 計画 : 対象のストーリーでは何を実装・解決しようとしているか
    • 進捗・成果 : 計画に対して
    • 動作確認 : 確認できるものがあれば共有
  • KPTの内容をグルーピングして話すことで、類似のテーマをディスカッションしやすくした（KPTはMiroを使って行なっている）
• 運用面
  • デプロイは、GitHub Actionsを使って行なっているが、Actionsの実行をエンジニアが行う必要がある。マイクロサービスアーキテクチャを採用しているため、修正内容によってはマイクロサービスごとのリリースタイミングを意識する必要があるため、リリースの旗振り役を交代で設けた
  • 社内へのリリース告知は、顧客向けのアウトカムを意識した文章に変更し、Slackで通知するようにした

2023年12月時点

体制

PdMが1人加わり、改善検討と新機能検討が以前よりは、同時に考えやすくなってきました。KPT外でもチームの課題が議論され自主的に改善され始めています。マネージャーがプロダクトの提供活動とプロダクト戦略の時間も確保できるようになり、チームの成長を実感することができました。

• バックエンド: 8名
• フロントエンド: 7名
• SRE: 2名
• データサイエンティスト: 1名
• QA: 3名
• デザイナー: 3名
• PdM: 2名

今の課題

• チームの開発マネジメント体制
• タスクのフェアさ

取り組みたいこと

• 開発マネジメント体制の見直し
  • 課題を見つけ、原因分析を行い、改善を議論するチームになってきたため、マネージャー判断になっていたものを分散させ、今まで以上に自分たちで判断できるチームをめざしていきたい
• 必須タスクの負荷分散
  • チーム運営上で必須のタスク（例えば、アラートの調査、障害対応）が特定のメンバーに偏っているため、必須のタスクをどのように負荷分散させるか考えていきたい

おわりに

ここまで読んでいただきありがとうございました。これを読んでいただいている方を取り巻く状況は、エモーションテックの状況（利用している技術、開発チーム人数、テクノロジーで解決したい課題）と必ずしも一致しないと思いますが、チームで向き合った課題とアプローチについて何か参考になれば嬉しく思います。

この記事や他の記事を見て弊社に興味をもっていただけましたら、ご応募お待ちしております。一緒にチームを育てていくことを考えていくメンバーも募集中です。

hrmos.co