見出し画像

プロダクト開発チームのデイリーミーティングって何を意識している?

こんにちは、株式会社Relicの北川です!
寒くなってきましたね、2023年も残り1ヶ月となりました。
今回の記事では、プロジェクトを円滑に進めるための方法の1つとして、プロダクト開発チームのデイリーミーティングについて意識していることを記載したいと思います。
それでは行ってみましょう!

対象とする読者の方

  • プロジェクトマネジメントをしている方

  • プロジェクトマネジメントに悩みがある方

  • デイリーミーティングに悩みがある方

  • デイリーミーティングが進捗報告になってしまっていて意義を感じられていない方

デイリーミーティングの定義

まずここで記載するデイリーミーティングの定義をしておきます。
1つのプロダクトですべての機能、または1つ以上の機能を開発する、複数人で構成されるチームが、毎日同じ時間・同じ場所で実施する15分程度の会議のことです。

不定期だったり、(オフラインであれば)場所が変わったり、参加するメンバーが変わったりするのは、本記事の対象外になります。
※その場合は別の課題があるかもしれませんが。

デイリーミーティングの課題

次にデイリーミーティングにおける課題を挙げていきます。

  • 進捗報告になっていて価値が感じられていない

  • 15分で終わらない

  • 不定期開催になっている

  • 何をすればいいかわからない

  • そもそもデイリーミーティングを開催していない

それぞれの課題を深掘っていきましょう。

進捗報告になっていて価値が感じられていない

デイリーミーティングの場が、リーダーやマネージャーへの進捗報告になっていて、メンバーにすれば意義を感じられていない状態のことです。
メンバーにとって時間はすごく貴重です。メンバーは、リーダーやマネージャーには常に状況の把握して欲しい、ということを求めていると思います。

15分で終わらない

議論が白熱して大幅に時間を過ぎてしまっている状態のことです。
議題1つ1つに対して丁寧過ぎる状態で、デイリーミーティングで扱う議題かどうか判断できていないのだと思います。

不定期開催になっている

リーダーやマネージャーが忙しく、直前のミーティングが長引いたためスキップする、といった状態です。
さらに議題がないのでスキップする、という状態のこともです。

何をすればいいかわからない

何のためにやっているかが定まっていないため、発生する状況のことです。
そのため「とりあえず進捗報告」を選択することがあるため、1つ目の課題「進捗報告で価値が感じられない」という課題にも繋がってしまう状態です。

そもそもデイリーミーティングを開催していない

開催すればOK、開催しないのはNG、ということはありません。
価値があるから開催します。
ではどんな価値があるのか、そのことを次の項目以降で記載します。

デイリーミーティングで意識すること

どの課題も多少心当たりがあるかもしれません。
これらの課題を解決するために、デイリーミーティングで意識することを記載します。

  • まずは目的を決める/決めてもらう

  • メンバーの、メンバーによる、メンバーのための会議へ

  • 参加人数を考える

  • 開発の習慣・リズムを作る

  • 議題が適切か見極める

  • 議題がないわけがない、なければ気付かせてあげる

こちらもそれぞれ深掘っていきましょう。

まずは目的を決める/決めてもらう

すべての会議において必要な工程ですが、なぜデイリーミーティングを開催しようと思ったかを明らかにすることです。
すでにチーム内に課題があるなら、それを解決するための手段がデイリーミーティングだったのかもしれません。その場合はメンバーに目的を決めてもらってもいいでしょう。
決めた結果「進捗報告」だったとしても、メンバーが価値があると判断できていれば問題ないと思います。

メンバーの、メンバーによる、メンバーのための会議へ

リーダーやマネージャーによるトップダウンでは、メンバーは価値を感じにくいと思います。デイリーミーティングがあって良かった、なかったら解決できていなかった、と思えるようにしなければなりません。
メンバー間の連携を促すことを意識することが大事です。

参加人数を考える

一般的に人数が多いと発言しにくくなる傾向があります。
最新版(2020年版)では言い回しは異なっていますが、初期のスクラムガイドでは、1つのスクラムチームは、7±2人が最適であると記載されています。
※スクラム開発をしていなくても参考になると思います。
少なくとも15分で全員が価値があると思える人数にするのがいいでしょう。

開発の習慣・リズムを作る

不定期開催や都度スキップ判断が入ってしまうと、開発チームとしての流れができにくいです。人間に体調の波があるように、デイリーミーティングを習慣化することで、開発チームの波が乱れないようになるでしょう。

議題が適切か見極める

会議の時間に対して、見合うだけの時間を1つの議題に使っているかは、常に考えなければなりません。
基本的な考え方として、1つのプロダクトを作っている以上、メンバーは関わらないなんてありません。なので議題それぞれに対して「関わらないから別途相談」ではなく、「関わる人で別途相談」をし、次回(次の日)のデイリーミーティングでは、「こうなりました」と話すのがいいでしょう。

議題がないわけがない、なければ気付かせてあげる

会議の目的設定もできず、議論する議題も本当にないならデイリーミーティングを開催しない方がよいですが、ほとんどの場合それは「メンバーが、議題があるのに、議題を見つけられていない」状態だと思います。
議題に気付くように、質問や対話で促すことも大事です。

デイリーミーティングのやり方

最後に、上記を意識して実際にデイリーミーティングで行なっていることを記載します。

目的は「進捗報告ではなく議論するため」

まず目的設定では明確に”進捗報告ではなく議論するため”としています。
目的設定時にメンバーが課題を見つけられなくても、”議論する”ことが目的であれば、未来のデイリーミーティングでメンバーが議題として課題を見つけてくることが予想できるため、”議論する”ことを目的にしています。

デイリーミーティングをメンバーが積極活用

目的を”議論すること”に設定することは、メンバーの自分ごと化に寄与し、積極的にデイリーミーティングを活用しようとするようになります。
ちなみにデイリーミーティングにおける議題は誰でも事前に書いて置けるようにスプレッドシートを用意しています。
結果的にですが、進捗状況が分かる、というのもあります。

職能で分けるか、機能で分けるか

参加人数の調整はチームやプロジェクトのフェーズによって変化させています。
フロントエンドエンジニアチーム、バックエンドエンジニアチームで分けることもあれば、決済機能チーム、商品管理機能チームなどエリアによって分けることもあります。
頻繁に変化するのは良くないので、大きなリリースの後など状況に合わせて調整をしています。

開催は午前中がオススメ

リーダーやマネージャーが忙しいことがあるため、差し込みされにくい午前中に開催することにしています。
これは開発のリズムを作る上でも効果を発揮します。
午前中のデイリーミーティングの開催は、その日のはじまりの合図になって良い習慣になります。

アイスブレイク込みで30分

デイリーミーティングそのものは15分で行いますが、午前中に開始早々いきなり本題に入るのは、柔軟体操なしでランニングをするのと同じ状態なので、昨日あったことや最近気になっていることを話す(話してもらう)ことで、スムーズに本題に入れると思います。
参加者が遅れた場合にも対応できて、本題15分+雑談5~10分+バッファ5~10分で余裕も取れます。
オフラインであれば、同じ時間・同じ場所で、できるだけスタンドアップで開催するようにしています。

デイリーミーティングとして議題が適切か判断する

例えば数回のやり取りで答えられる議題であれば、デイリーミーティングを活用するのが良いと思います。
議論が展開して、別の課題を発見していくこともあると思います。
その場合は”1つの議題につき5分とする”、”追加の議論はデイリーミーティングの後に参加者絞って開催する”といったルールを作ります。
緊急度や重要度によっても判断は異なるので、マネジメントの腕の見せ所だと思います。

まとめ

いかがでしたでしょうか?
短い時間の会議でも、意識的に行うと大きな効果になると思いますので、ぜひ明日からのデイリーミーティングに活用していただければと思います。
年末に向けて寒くなり忙しくなりそうですが体に気をつけていきましょう。

最後に

Relicではオンライン勉強会を定期的に開催しております。
過去のオンライン勉強会の一覧はこちらです。

さらに他のRelicメンバーが書いた記事は以下にまとめられていますので、よろしければ見ていただければと思います!

またRelicではさまざまな職種について積極的に採用中です。
地方拠点もありますので、U・Iターン大歓迎です!🙌
新規事業にご興味のある方は、Relic採用サイトからエントリーください!

それでは次の投稿でまたお会いしましょう!

この記事が気に入ったらサポートをしてみませんか?