成長中のエンジニア組織におけるチーム毎のコミュニケーション方法

こんにちは！
プログリットでエンジニア・マネージャーをしている島本（ @diskshima, @diskshima@mastodon.cloud ）です。

以前、開発プロセスや実装時の話を書きました。こちらではPdMやデザイナー、エンジニアの全員に関わるような話を書いておりました。そのときから既に2年近く経っており、プロダクト開発の組織も大きく成長し、携わる人はもちろんですが、開発対象となるもの（お客様が使うものだけでなく、社内で利用するものなど）も多くなり、また保守するものも増えてきております。
その多様さにより、エンジニアグループの中でもコミュニケーションの取り方も多用してきております。今回は、エンジニアグループの雰囲気を少しでも解像度高く伝えるために、グループ内のコミュニケーションの取り方について紹介したいと思います。

前提の考え方

まず、前提として、先ほどの記事のように全体の流れや、プルリクエストを必須にする点などはグループでルール化しておりますが、それ以外の進め方は各チーム（iOS、Android、サーバサイド、フロントエンド）によって異なっております。実際にはそれぞれのチームで相談して決めております。その背景の考えとしては、扱っているもの（モバイルアプリなのか、サーバプロセスなのか）によっても、適切なプロセスが異なりますし、（こちらの方が大きいのですが）メンバーの性格やスキル、メンバー間の関係性によっても、適切なプロセスが異なると考えているためです。

全体の流れは以前の記事に委ねるとして、今回は各チームでのコミュニケーションの取り方についてフォーカスしたいと思います。

現在のチーム構成

まず、現在のチーム構成ですが、プロダクト開発部エンジニアグループでは各領域でチームを分けております。具体的には

iOSチーム
Androidチーム
フロントエンドチーム
サーバサイドチーム

の4チームで構成されており、それぞれ2〜3名ずつ所属しております。
まだ人数も少ないため、事業やプロダクトのラインで担当を分けたりはしておりません。新しい機能の開発時などは適宜メンバーの特性、タスクの具合などを見て、都度割り当てる形にしています。「割り当てる」という表現をしましたが、実際には自分が指定などはしておらず、各チーム内で相談して決めています。

それでは、各チームでのコミュニケーションの取り方について書いていきます。

Androidチーム

Androidチームでは、iOSチームと同じく「座談会」をリリース後に行っております。
内容としては以下について話しております。

リリースした開発内容の実装面でも振り返り（実装の工夫、難しかった点、次回の反省点など）
次の開発サイクルの進め方や課題の共有

余談ですが、Androidチームは座談会のアジェンダと議事録を英語で残すことになりました。エンジニアグループでは、最近プルリクエストのレビューを英語で行うなどの取り組みを始めております。こちらはまた別の機会に書きたいと思います。

フロントエンドチーム

フロントエンドではフロントエンドに携わるメンバーでは「Front振り返り会」をリリース毎に、「エラー確認会議」を2週間に1回開いています。

Front振り返り会では以下の内容を実施しています。

リリースした開発内容の実装面でも振り返り（Androidチームと似ております）
次のリリースのイシュー割当開催する時点では次の開発内容が見えているため、この時点でメンバーがどのイシューを担当するのかを割り当てていきます。ただ、すべてのタスクを完全に決めるのではなく、優先度が高いものや規模が大きいもの割当て、それ以外は「手が空いたらやる」という形にしています。

エラー確認会議では、具体的には以下のような流れで進めています。

発生しているエラーを確認するプログリットのフロントエンドでは Sentry というツールを利用しており、エラー確認会議では、そのSentryで発生したエラーを確認しており、その場でGitHubイシューにするか、クローズするか、様子見するか等の判断をしています。
以前にイシュー化したエラーの進捗を確認する。フロントエンドのカンバン（GitHub Project）を確認し、過去に1のステップでイシュー化したエラーを見て、優先度を上げるべきか、クローズするかを判断しています。
ユーザから声の確認ユーザからの声や問い合わせなどを確認し、その中でエラーに関するものが無いか確認しています。

Sentryのエラーリスト画面

サーバサイドチーム

サーバサイドでもフロントエンド同じような定期Mtgをリリース後に開いており、同様に振り返り、次の開発サイクルの進め方について話しています。

サーバサイドでもフロントエンドと同様にSentryをエラー監視ツールとして使用していますが、フロントエンドのような定期会議は開いていません。代わりにエラー通知がSlackに来た際に、気付いたメンバーが対処する形を取っております。

iOSチーム

iOSチームに関しては以下のほかチームと同じようにリリース後に「座談会」を行っておりますが、それとは別で週3回、午前中に「朝会」を開いています。
主に朝会は今日と明日の時間軸で以下の内容について話しています。

共有事項
相談事項
困り事

朝会のアジェンダと議事録

iOSチームは最近、2名から3名に増えたのですが、やはり2と3の間ではコミュニケーションの難しくなる、というのを強く感じており、より高頻度でコミュニケーションを取る必要があるな、と感じています。

今後の課題

さて、現状の各チームのコミュニケーションについて書きましたが、まだまだ課題があり、常にそれに応じて変化を加えています。iOSチームの朝会も2ヶ月ほど前に始まったばかりです。
現状の課題としても「そもそもグループ全体での会議などがもっと必要なのでは？」や「このままでは人数が増えると振り返りが薄くなってしまう、ないしは長くなってしまう」などの懸念があります。

終わりに

組織は流動的なもので、人が代わることにも影響されますし、各メンバーのコンディションにも影響されると思います。プログリットもまだまだ成長しますし、それに応じてエンジニアグループも、各チームも成長していきます。重要なのは、その変化の中生まれてくる課題に逐次対応し、柔軟に形を変えていくことと考えております。
是非、そのように柔軟に変わっていくのを目の当たりにしたい、自分もそれに貢献したいと思われた場合、是非お声がけください。お待ちしております！