こちらの記事はカケハシ Advent Calendar 2024 の 16日目の記事になります。

こんにちは！エンジニアリングマネージャー（以下、EM）の小田中（@dora_e_m）です。11月より、新規プロダクト開発を主なミッションとするチーム"yabusame"に加え、Musubi AI在庫管理を開発するチーム"hakari"のEMを担当しています。

この記事では、hakariチームにジョインしてから取り組んだミーティング削減施策の狙い、実施までの進め方、効果、そしてこれからやっていきたいことについて紹介します。

hakariのチーム構成

まず、ミーティング削減の話に入る前に、hakariというチームについて簡単に紹介させてください。冒頭でお伝えしたとおり、このチームはMusubi AI在庫管理を開発するチームです。ローンチから数年が経過し、ありがたいことに多くのお客様に使っていただいています。プロダクトが成長するにつれて組織も成長し、30人を超える規模の開発チームになっていきました。

大規模なチームが機動力を発揮するための工夫として、チーム内でいくつかのサブチームが設置されています。各サブチームは職能横断で組成されています。

基本的には各サブチームで開発を進めていくのですが、開発を進めていくうえで同じ職能(フロントエンド/バックエンドなど)のメンバーに相談したい機会や、サブチームには落とし込まれていない横断的な課題を取り扱う場を設けるために、いくつかの定例が設定されていました。

定例会議が引き起こす課題

上記のミーティングは、必要だと判断して設定されたものばかりです。それぞれのミーティングは実施するに足るだけの意味がありました。しかし、「チーム全体で同期をとるミーティング」「自分のサブチームのミーティング」「自分の職能のミーティング」が存在する状態になり、以下のような課題がありました。

ミーティングに割く時間が多く開発時間が短くなってしまう
すぐに共有したほうがよいことも「定例で共有しよう」と寝かせてしまう
すでに定例がたくさんあり、予定を確保するコストが高くなっている

とくに3番目の課題については、「都度予定を確保することが難しいから、定期的に予定を確保しておこう」という考えを誘発し、定例会議を増やす一因にもなっていました。

ミーティングへの考え方

そもそも、同期コミュニケーションであるミーティングはどういった場合に開催するとよいのでしょうか。私は以下のように考えています。

同期してコミュニケーションしたいもの

1-way-door(決定すると後戻りが難しいもの)な意思決定
即時のフィードバックが欲しいとき
多様な視点から行うアイデア出し
関係構築

非同期でコミュニケーションしたいもの

決定事項、周知事項の伝達
緊急性が低い情報伝達
記録を残したい場合

同期して議論したいものはミーティングを開催するとして、何を定例とし、何を都度開催とするとよいかは、下記のように整理しています。

定期的に実施したいもの

何をつくるか、何をつくったか、今のチームの状態は？などを定期的に確認し学ぶため・軌道修正するために役立つもの
- スクラムイベントやDatadogのダッシュボード確認など

不定期で必要に応じて実施したいもの

トピックが定期的に発生するわけではないもの
- 「とりあえず集まって、何もなかったら解散します」みたいなAgendaのミーティングはこれに該当

ミーティングを減らす意義を伝える

上記の基準にしたがって、削減対象のミーティングを選定していきました。同時に、なぜミーティングを減らしたいのかについてチームに説明する資料を作成しました。

ミーティング削減のお試し期間を設ける

削減対象のミーティングが決定したあと向き合うのは、いつからそれを実行するか？という課題です。いまある定例は決して意味のないものではないので、いきなり止めてしまうとさまざまな問題が噴出すると予想されます。なので、いくつかの定例を実際に停めてみる実験期間を2週間ほどとりました。

こちらが、ミーティング削減前と削減後のカレンダーを比較した図になります。

Beforeのほうには「作業時間確保」のような予定も入っていたので実際のミーティング時間より多く見えています（そもそもミーティングを行うわけではないのにカレンダー上で予定が確保されている状況というのはカレンダーの運用を複雑化させてしまうので、これはこれで解決したい課題でした）が、パッと見でカレンダーに余裕が生まれたのがわかるかと思います。

実験の効果測定

削減した時間については定量的に計測できますが、どんな効果があってどんな副作用があったは計測が難しいものになります。そこで、2週間の実験期間中に気づいたことを投稿するフォームを用意し、定性的評価を集めることにしました。なお、率直に思ったことを投稿できるよう、フォームは無記名としました。

集まった意見としては以下のようなものがありました。

MTGが減ったことで、午前中から作業時間を取りやすくなった気がしますね！（デイリーの後に作業に取り掛かれそう）
従来は開発メンバーの1名が不在だったが、その時間が空き、午前中に作業が進むようになった。共通の連絡事項などはslackで共有があるのでキャッチアップできるため、チーム開発が進むのではないかと思いました。
まとまった時間で集中して実装できる時間が増えたのが良かった。
ミーティングで集中が途切れることなく続けられるようになったのはとても助かっている
いろんな情報を共有してもらってたけどなくてもこまってない（？）こういうのはメンバーよりマネージャーが困ってるのかも（？）
リリース内容や担当者を全員が確認できているか少し不安。

フォームの回答からも、解決したい課題であった開発時間の確保が実現していることが確認できました。一方で、それまで存在していた定例がなくなることで一部コミュニケーションが取りづらいところも出ていました。

本運用の開始

2週間試してみて、結論としてはミーティングを減らすメリットが大きかったため、継続して定例を削減した状態を維持することにしました。同じ職能のエンジニア同士で情報共有する定例などがなくなったため「情報共有がしづらくなった」というフィードバックがあり、中には「定例を戻してほしい」という声もありました。ですが、私の中では「定例のタイミングをまたずしてリアルタイムに相談しあう文化」をつくりたいというwillもありました。

なので、「横串で話づらくなった、だからミーティングを元通りにしよう」ではなく、「非同期で横串に連携するには？」を模索していこうと考えています。