朝会は長いし無駄？朝会の実施要否パターンと実施内容を公開します

データアナリティクス事業本部＠札幌の佐藤です。

今回は朝会について実施要否から、実際の私のプロジェクトで実施している内容まで、現在私が考えている内容について記載させていただきたく考えております。
当対応にあたっては株式会社コパイロツトの方にもいろいろ相談させていただいたうえで、ルールとして今整備、運用しているものとなります。
ご協力いただきありがとうございます。

お話の前提

私の案件は小規模（メンバー10人未満）のプロジェクトが多いため、小規模案件での前提として記載します。
また、期間においても3ヶ月程度の短期間の開発プロジェクトを前提としております。

大規模案件・長期間案件・保守案件の場合は必ずしも該当しない観点がある可能性がありますので、あらかじめご認識いただければと思います。

そもそも朝会はやるべきなのか

朝会の実施要否については私もいろいろ考え、実施しないケースでのプロジェクトも経験しました。
そのうえでの今の結論としては、朝会は実施すべきと考えています。
ただし、闇雲に毎日実施するというのは避けるべきで、状況を見て実施有無を判断するのがよいと考えています。

■私が今思う朝会の実施要否パターン

朝会の実施の有効度として、プロジェクト初期のメンバー間のコミュニケーションや、案件理解、技術理解が不十分な場合が一番有効だと考えます。
そもそも様々な観点にてギャップが大きい状態ですので、その合間をコミュニケーション量で埋めるというのは、プロジェクト終盤まで見たうえで最善だと考えているからです。

私が担当しているプロジェクト期間は3ヶ月程度が多いため、序盤1ヶ月は工数を使用してもコミュニケーションを密にとってその利点を得、2ヶ月目は得られる利点が少なくなるので止めるという判断を下しています。

中期以降の実施要否

中期以降の場合はギャップが小さくなっている状態にいるケースが多く、小さいずれを精緻にしようとしているだけになります。

プロジェクトが安定しているという、いいサインであるため、ここは思い切って朝会を止めてしまったほうがよいかと思います。
実施する際のメリットに対して、毎日30分程度×メンバー数で工数がかかるデメリットがあるためです。
それを無視できるのであれば続けても問題ないかと思います。
（基本的にコミュニケーションを密にすることはよいことですので）

ただし、一切やらないという判断は下すべきではなく、認識がずれが原因での問題が散見し始めてくる、遅延が大きくなっている、細かなコミュニケーションが必要という場合は、再度朝会を実施すべきかを検討すべきです。

私は遅延の原因や、Slack等の文章コミュニケーション上で何かうまくいっていなさそうという雰囲気を感じた場合に、メンバーにまず実施要否の打診をするようにしています。
（状況においては強制します）

朝会の目的とは

上でも書いていますが、そもそも朝会の目的として、チーム内の混乱をいち早く乗り越えるためのコミュニケーションとして実施するとプロジェクトメンバーに伝えています。

目的として以下5点を掲げ、メンバーに説明を行っています。

1. 意思疎通する回数を増やすことで、お互いを知る（相談をしやすくする）
2. 意思疎通する回数を増やすことで、プロジェクトリーダー・メンバーの思いや不安、心配が全体に共有される
3. 意思疎通する回数を増やすことで、プロジェクトリーダー・メンバー間で持っている情報が全体に等しく共有される（特に立ち上がり時は技術・業務で知見が偏り気味）
4. 今日実施する予定がプロジェクトリーダー・メンバー間で合意されている
5. 今日実施する作業のネクストアクションが明確になっている

そもそも朝会も進捗会議のひとつですので、実施の時間と回数が違うだけでネクストアクションを決めるという点は同じはずです。
朝会はその最小粒度の1日単位での次のアクションを決めていくというスタンスで、各担当者が納得してその1日をそのゴールに向けて対応するものであると考えています。

コミュニケーションという点においても、序盤にメンバーの雰囲気を知るという点は、ある程度役に立つ（こいつ誰やねんがなくなる）ため、意識的に実施しています。
当然、そういった要素に興味がない人もいますので、そこは柔軟に対応すべきかなと思います。

朝会の構築時に意識している点

朝会の構築時に意識している点としては、立ち上がり時は技術・業務で知見が偏り気味という点です。
アサインメンバーが必ずしも難でもトップクラスにできるわけではなく、ある程度偏りがあります。
また、業務・このプロジェクトで何がやりたいのかという点はプロジェクトリーダ・マネージャが一番詳しいはずです。

ここの偏りがあるというのを前提におかないと、以下問題が少なからず発生します。
そのため、プロジェクト初期での朝会はその偏りを意識して平準化させるように、別途説明用の会議を開催するかなど打診をしてあげることも別途必要になってきます。

• メンバーの心的負荷が高いまま、プロジェクト中期に突入し遅延する
• 作業の平準化できず、ある一定の人の負荷が上がってしまう
• やるべき作業を正しく行わない

朝会は何回が理想なのか

朝会の実施回数ですが、基本的には毎日×30分でできればよいのかなと考えています。
ただし、1回30分で討議できることはごく限られています。

そのため、私は朝会では、即判断できることはその場で回答する。討議が必要なものについてはいつ討議をするかという、本当に直近のネクストアクションだけ決定しています。

朝会は状況共有の場であり議論の場ではないため、問題の解決は目指さないというのが前提です。

朝会で30分超過するケースは、そもそも参加する人間が多いか、討議をしてしまっているかだと推測しています。
そこは割り切って討議をしないという選択肢を取ったほうが無難だと思います。

その代わりに討議できる時間を確定で取るようにしています。
現状は週に2回×1時間とし、クライアントとの会議のアジェンダや、細かい討議を実施するようにしています。

討議回数を明示的に用意することで、技術・業務で知見の偏りを減らす（文章で限られた人間の人でやり取りするとどうしても格差が起きる）のと、開催日時が分かっているのでそれに向けてメンバーが準備することができます。
もし討議するものがなければスキップしたらよいので、ゴールを明示的に用意してあげるというのは実施すべきかと思います。

■現状の朝会のサイクルと討議内容

どのようなアジェンダがいいのか

実施するアジェンダは現状、以下5つで構成しています。

1. 良かったこと・楽しかったことの共有（お互いを知る）：全員（ひとり1分くらい。共有事項なくてもいい）
2. プロジェクトの立ち位置の共有：プロジェクトリーダー（1分）
3. 議事録ルールの共有：プロジェクトリーダー（1分）
4. 各自報告ルールに則り報告：全員（ひとり3~5分）
5. その他共有事項：各担当者（残り時間で）

基本的には後述する報告ルールに則り報告していただき、課題などのネクストアクションを決めていくのが主です。
それに加えて「良かったこと・楽しかったことの共有」と、「ルールの説明」をいれています。

良かったこと・楽しかったことの共有っている？

「良かったこと・楽しかったことの共有」は、プライベートでも仕事でもよいので良かったことをみんなに話すというものです。
ここの実施要否については、人によると思います。

実施の目的は、上にも書いていますが互いを理解するというものになります。
特にプロジェクト初期のみんな何者か分からない場合において、どういう人物なのか分からないというのは、非常にコミュニケーションがとりにくいのではと考えています。

今までこの役割は飲み会に行く・ランチに行くが担っていなのではと思います。
ただ、昨今の状況や、複数の拠点間で働いている今の状況においては難しく、その代替としてプチ雑談というものを意図的に設けています。

当然、自分のプライベートを話したくない人はいますので、絶対に強制しないというのがルールになります。
（実務的なところに関係ないことをやらされているという不安・不信を抱かせてしまっては意味がない）

現在は週に1回、週頭の会議で実施していますが必ずしも必要ではありません。
そのため、報告ボリュームがありそうなど状況によってはスキップしても問題ないものになります。

ルールの説明っている？

個人的にはルールの説明は必要と考えています。
ルールを定着するためには、何度もしつこいほど耳に入れて当たり前の状況にしてあげる必要があります。

わざわざルールを1から説明する必要はりません。
簡単に説明してあげる、1枚絵を開いてあげるというだけでも十分です。

私は、上の現状の朝会のサイクルと討議内容の資料を表示して、簡単に説明しています。

朝会の実施までの流れ

ここからは実際に実施している会議の内容について記載します。

会議にあたっては色々な会議用のツールがあると思います。
現在私はSuperGoodMeetings（SGMs）を利用していますので、そちらを前提にして記載します。
また、社内のコミュニケーションツールはSlackのため、そちらをベースに記載します。

必ずしもSuperGoodMeetingsでなければいけないわけではありませんので、現在使っているものでも問題ないかと思います。
私も元々Slack上でやっていましたが、議事も上記ツールで記載できるのと、アジェンダのコピーができるため現在はSGMsを利用しています。

会議前

会議が始まるまでまでに準備をしておく必要があります。
メンバーに作業報告を記載してもらうため、なるべく早めに用意しておくが良いと思います。
フォーマットについては後ほど記載したいと思います。

アジェンダのリンクを張り付けだけじゃダメなのか？

ただ単純にアジェンダを張り付けるだけではNGです。
手間でも何をしてほしいのかなどのルールは、しっかりと提示してあげたほうがよいと思っています。
ルールとして定義した内容は、そのルールが書いてある場所で数ホップで見に行かなければならず、基本的に見てくれないです。
ホップ数を減らすためには、こちらから書いてあげるのが肝心だと思います。
（クライアントに説明するときも同じ）

■実際の通知

会議中

上記アジェンダについて記載している内容をもう少し詳細化したものになります。

会議後

会議中でのネクストアクション決定後の動きになります。
こちらについては状況によります。

事前記載の報告フォーマットについて

事前に記載いただく報告フォーマットは、現状簡単に3つの報告事項としています。
また、フォーマット定義において重要なのは、メンバーに負担がかからないように書いてもらうという点です。

1. 昨日やったこと
2. 今日やること
3. 作業で困っていること・相談したいこと

そもそも報告フォーマットに何かを書くということ自体面倒な作業であり、ここに時間を割くくらいであれば作業をしてほしいですので、とにかく簡単に書いてもらうことが必要だと考えています。
その中で最低限必要だと思っているものは以下の3つだと思っています。

• 今やっている作業が終わるのか終わらないのか
• 終わらないのであればいつまでかかるのか
• 不安に思っていることを何でも話してもらう

私のプロジェクトでルールとして記載しているものを以下、そのまま掲載します。
このくらいの簡単さで現状十分充足します。

なぜそこまでして事前に記載してもらうのか

様々な理由がありますが、主に朝会を30分で完了させるためです。
フォーマットが何もない場合、メンバーのうち何も準備をせずに参加する人もいます。
その場合、自分の頭の中で考えながら話すため話が整理されておらず、冗長になるケースがあります。

ひとりが話せる時間は最大5分ですので、事前に整理してきてもらったほうが討議がスムーズです。

その他の理由としては報告を強制される会ですので、事前に自分のタスクを見ることを必ず求められます。
そうすることで少しずつですが、自分のタスクを自分で管理できるようになりますので、その意識を持ってもらうというのもあります。

昨日やったこと

昨日実施したことを書く。

記載例・発表例

チケットXXXを実施。完了済
or
チケットXXXを実施中
or
チケットXXXを実施。作業遅れ。明日までに終わる見込み

今日やること

今日実施することを書く。

記載例・発表例

チケットXXXを実施

作業で困っていること・相談したいこと

作業をする上で困っていること・相談したいこと・不安を書く。
自分でネクストアクション案を決められる場合は、決めてくること。
決められない場合は、素直に不安事項をそのまま書いてくること。（それを決めるのが朝会であるため）

記載例・発表例

チケットXXXをやっているが、実装が難しくうまく進捗しない
or
チケットXXXをやっているが、相談したいことがある。相談する時間を作ってほしい
or
チケットXXXがちゃんとできるか不安

朝会の議事録

以前書いた記事にも書いていますが、原則議事録は全員でとっています。

議事については以下ルールとして、毎回の会議で必ず口頭で伝えています。

• 発言していないメンバーがとること（メンバー全員でとる）
• 議事録は発言すべて取る必要はなく、決定事項・ToDo事項を記載するのみでOKとする。
• ToDoや決定事項が分からなかったら、とりあえず書いておいてOK
• 同じこと書いても気にせずに書いてOK（それだけ重要ってこと）

これは、以下内容も含め、議事録を取ること自体のハードルを下げるのが目的です。

• 内部的な会議であるためクライアント会議ほどの水準を求める必要がない点
• 討議した内容を記載していないせいで、忘れてしまったという方が問題のため、まずは書いてもらう点

とにかく決まったこと・ToDoを忘れないようにするというのが重要かなと思っています。

さいごに

これが朝会というものに対しての完全な回答であるか、と聞かれたらまだ微妙なところがたくさんあると思います。
もっと効率の良い朝会ができるように、色々試行錯誤していきたいと考えています。

記載した内容が朝会で困っている人の参考になれば嬉しいです。