こんにちは。Kaneyasuです。
re:Invent 2024に参加して帰ってきました。
参加のためにスケジュール調整、特に定例会の調整したのですが、その中で、そういえば定例会の進め方については誰にも教えてもらったことがなく、探り探りでやってきたことを思い出しました。
自分のやり方を書き残しておくと、誰かの役に立つかもしれないと思ったので記事にしてみます。

前提条件

本記事で想定しているプロジェクトは以下の条件を満たしているものとします。

プロジェクトはウォーターフォール型でもアジャイル型は問いません。
各タスクや課題はチケット管理ツールまたは表計算ソフトで管理されている。

定期的に人が集まって話すことを定める意味とは

そもそも定例会は何のためにするのか、ということから考えてみます。

毎日、週一、月一、単位は様々でしょうが定期的にミーティングすることを定めたものを定例会だとします。
スクラム開発であれば、デイリースクラムなども定例と言えるでしょう。
定例会を設ける意味としては、以下のものがあると思います。

関係者が多忙なので、スケジュールを先立って確保しておく

プロジェクト進行を円滑に進めるには、影響力の大きい人を巻き込む必要があります。
しかし、影響力が高い人はどスケジュールが難しい傾向にあるので、その人たちとのスケジュール調整をしていると、ミーティングの開催が難しくなります。

定期的な報告の場を作ることで、プロジェクトにある程度の緊張感を持たせる

定例会では、進捗報告や課題報告が行われます。
進捗報告においては、少なくとも報告内容には根拠が必要です。
例えば進捗をパーセンテージで表現していたとします。
あるタスクを100％と報告するならば、少なくともそのタスクは綺麗に終わらせないといけません。
一度報告した進捗が下がることは、進捗報告の信憑性を失わせることになるからです。
進捗に変更がない状況が続くと、プロジェクトに対して何らかのアクションを求められることもあります。

このように定例会用で報告するために、進捗に根拠を持たせたり、変化があることを見せようとする努力がプロジェクトに緊張感を持たせます。
逆に緊張感がないプロジェクトは、各タスクがずっと80％で停滞しているなど、責任感の欠如が現れる可能性があります。

続けて、比較しないと見えてこない

人がものの良し悪しを理解するには、何かと比較する必要があります。
プロジェクトも同じです。
進捗の％、残課題の数、メッセージに対する返信など、これらの変化・または変化してないことを見て初めて何かを見出すことができます。
定例会でこれといって議論することがなくとも、ひとしきり状況を共有することは必要です。
変化がないこと自体が状況を表している、または状況が見えてないと言えることがあり、そこから議論が生まれる可能性があります。

大事な話はそこですれば周知が効率的という空気を作る

共有するための場が用意されているというのは重要です。
定例会で共有すれば効率がよいと思ってもらえれば、無駄なコミュニケーションが減り効率化が図れます。
逆に共有の場がないと、声が挙げられずアラートが見えなくなることが考えられます。

タスクや課題をチケットで管理している場合、テキストベースでのやり取りでは解決が難しいと感じたら、詳細は定例会会話しましょうと提案する選択肢があります。
実際に定例会で会話したら、その結論をチケットに記載しておくと、記録にもなります。
この場合、経緯は議事録に残るでしょうから、必ずしも経緯までチケットに記載する必要はありません。

定例会の進行

システム開発のプロジェクトにおいて、定例会の司会は一般的にプロジェクトマネージャーが担当しますが、慣れてないとかなり負担がかかります。
理由としては、報告することがないと思えてしまうのと、忙しい中集まってくれているというプレッシャーなどが挙げられます。

アジェンダは型を決める

毎回の定例会のアジェンダを型のように固めておくと、定例会の進行はだいぶ楽になります。
定例会の枠が1時間だとすると、以下のようなアジェンダが考えられます。

例）

進捗報告（10分）
- 全体進捗
- 変化したタスク・遅延しているタスク
- 今後のスケジュールへの影響
重要タスクの確認（10分）
課題共有（15分）
- 変化があった課題の共有
- 停滞している課題の状況確認
その他の議論（10分）
次回定例までの重要タスクの決定（5分）

これで50分です。
どこかで盛り上がる可能性を加味すると、アジェンダはこれぐらいでよいかと思います。

進捗報告はプロジェクトマネージャーが行う

進捗報告は、プロジェクトマネージャー自らが行います。
良いことも悪いことも報告する姿勢を貫いた方が、信頼を得やすくなります。

課題の共有は起票者・編集者に投げる

課題の共有は、プロジェクトマネージャーが全て行わず、課題の起票者／最後の編集者に共有をお願いした方がよいでしょう。
プロジェクトマネージャーの負担を減らすとともに、参加者が傍観者になるのを防ぐ効果があります。

停滞している課題の状況確認も忘れないようにし、起票者／最後の編集者に共有を依頼します。
停滞している課題は、誰もボールを持っている認識が可能性や、解決が困難な問題が発生している可能性があります。
逆に理由もないのに停滞しているなら、定例会を利用してみんなの前で強制的に進めるか完了にした方がよいです。
無駄に残っている課題は見通しの悪さに繋がります。

議論が収束しない場合は、時間を区切る

課題について議論していると、収束しないことがあります。
これは、課題についての準備不足や、新たな情報が出てきたことに起因することが多いです。
この場合、時間を区切って、別枠で議論したり、次回に持ち越すことを提案します。
時間の守られない会議は、参加者のモチベーションを下げる原因になります。

重要タスク (TODO、ネクストアクション)

定例会の最後には、次回までにやるべき重要タスクを決めます。
重要タスクは、TODOリストやネクストアクションと言うこともあります。
基本的にタスクはチケット管理か表計算ソフトで管理されているはずですが、参加者の中には立場上そこまで詳しく情報を追えない人もいるでしょう。
得てして、要件の確認やスケジュール調整には、そのような人たちが重要になることが多いので、強調する意味でも重要タスクを決めることは重要です。
経験上、重要タスクは次の定例会の最初の方で触れるようにしておくと、放置される確率が下がると思います。

以上です。
本記事が誰かの役に立てば幸いです。