はじめに

チームの生産性を上げるために、まず最も重要なのがコミュニケーションがうまくいっていることであると考えています。
とはいえメンバー(ベンダー)、顧客、マネージャー、経営層など視点によって考え方は変わってくるため、本記事では主にプロジェクトマネージャー向けに、チームのコミュニケーションデザインについて、具体的な実践方法とともにご紹介します。

今回は対顧客向けではなく、主に開発ベンダーのチーム内コミュニケーションについて記載します。

筆者プロフィールと経験

私は現在、3年以上続くプロジェクトで、15人程度をまとめるPM(プロジェクトマネージャー)をしています。
プロジェクトが始まった当初はメンバーとして参画したのですが、なんとなく他のメンバーともPMともコミュニケーションがうまく取れている実感がなく、顧客・PM・メンバーの間でも情報の連携ができていませんでした。
PMに伝えた内容が、正確に顧客に伝わっておらず、顧客とPMとの間で閉じたやりとりが行われ、無理な要望が積み重なることにより、マイルストーンも見えず進捗は遅れていく一方。
その結果として、半年後に無事(?)炎上してしまいました。
しかしその後立て直しと軌道修正を行い、規模を拡大しながら継続し、現在では安定したプロジェクトとして社内でも優良案件に位置づけられています。

ほぼフルリモートで、3ヶ月に一回程度チームでご飯に行っており、参加率は80〜90%ほどと予定が合わなかった人以外は全員参加しています。
10〜15人程度のチームのPMとなりますが、サイズが大きくなったとしても基本的な考え方は変わらないと思うので、少しでも参考となれば幸いです。

プロジェクトマネジメントにおける、コミュニケーションの重要性

「コミュニケーションがうまくいっている」とはどのような状態か?

まずは、コミュニケーションがうまくいっているとはどんな状態かを考えてみましょう。
PM視点では、下記のようなことが挙げられます。

メンバーから、適切なタイミングで報連相が届く
各チームやメンバーが今何をしているのか把握できており、不安がない
進捗が予定通り進んでいるかを把握できている
リスクを、余裕をもって対処可能なタイミングで把握できている
顧客への連絡や、報告する上で必要な情報が必要なタイミングで揃っている
なんらかのトラブルが発生したとしても、チームとして迅速に動ける状態である

どうでしょうか。
皆さんのチームは、上記を全てクリアしていますか?
すべてOK!という場合は、全体としてかなりうまくいっていて時々トラブルが発生したとしても対処できる、安定したチームなのではないでしょうか?

更に深堀りすると、うまくいっているチームでは、下記のことが実践できている場合が多いと思います。

メンバーに連絡をした際に、全員(もしくはPL全員)から何らかのリアクションが返ってくる
業務時間内に緊急連絡をした際に、メンバーとすぐに連絡がとれる
個別チャットやDMでの会話は限定的であり、質問や会議がチーム全体に開かれている
チャットなどで活発なやりとりが行われている
デイリーMTGや内部MTGで、「全く発言しない人」がいない

これらにあてはまらないものが多いという方は、プロジェクト推進において少し不安があるのではないでしょうか。
この場合、コミュニケーション改善の余地がありそうです。

「うまくいっている」状態になるためのポイント

上記の事柄から抽出すると、うまくいくためには下記のポイントをクリアする必要があります。

情報の正確性が高いこと: 進捗やリスクなどの情報を正しく把握できること
機動性が高いこと: すぐに連絡がとれる状態で安心感があること
透明性が高いこと: 全員が必要な情報にアクセスでき、コミュニケーションが極少数だけで行われていないこと

ちなみに心理的安全性が高いことは、上記の前提であると考えています。
心理的安全性については下記の記事が詳しいため、不安がある方はご参考ください。

コミュニケーションがだめだと炎上する

ここまで見てきたように、「コミュニケーションがうまくいっている」ことは「プロジェクト推進がうまくいく」ことに直結しています。
もちろん、コミュニケーションがうまくいけばすべてうまく行くわけではないのですが、逆に、コミュニケーションやチームの人間関係がうまくいっていないと、かなりの確率で炎上します。
炎上してしまうと立て直しがかなり難しくなってしまうので、そうなるまえにぜひ、本記事の内容を実践しましょう!
炎上の火消し方法を含めて困ったときに参考となるおすすめ書籍のリンクを貼っておきます。

必要なコミュニケーションツールは3種類

具体的なアクションプランに入る前に、必要なツールが揃っているかを確認しましょう。

内部用のコミュニケーションツールは、下記の3つが必要となります。
利用するツールが多すぎると情報が散乱し、混乱の原因になるので、コミュニケーションという目的では、それぞれの種別で1つずつ選定して利用しましょう。

種別	用途	ツールの例
チャット	全体連絡や日次の進捗報告、報連相全般	chatworkやslack、Microsoft Teamsのチーム機能など
タスク管理	各タスクごとの細かいやりとり	Backlog, Github, Redmineなど
Web会議	内部MTG	zoom、Google Meet、Microsoft Teamsなど

チャットやWeb会議は、基本的には会社で使っているものになると思います。
タスク管理ツールは、悩む場合はまずは一旦使ってみて、合わなければ別のツールに変えるでも大丈夫です。

私のプロジェクトでは、Githubのissues機能をタスク管理として使っています。

それではここからはアクションプランを紹介していきます。

実践1. オープンに話せる場を作ろう

まず前提として、チャットでのやりとりは、基本的にDMや個人チャットではなく、オープンな板で行いましょう。
たとえば、AさんがBさん宛に質問した場合、それをみていたCさんが、Bさんの代わりにすぐに回答することもできますし、同じところで疑問をもっていたDさんがその回答を見て悩みを解決できることもあります。
これによりチームの生産性が上がることにつながります。

上記を、仮にAさんがBさんとの個人チャットで質問していた場合、Bさんの手があくまでAさんは待たなければなりませんし、Dさんは同じ質問を誰かに投げないといけなくなります。

質問だけでなく、やりとりをオープンにすることで、PMは誰がどんなことをどんなスピード感で進めているのかがわかり、リスクにはやめに対処することにつながります。

この記事で言うオープンとは、プロジェクトのメンバー間にオープンであるという意味です。機密情報は守りましょう。

DM(個人チャット)の使い所

では、どこまでオープンなチャットで話せばよいか?
状況にもよりますが、基本的にはプライバシーや機密情報に関わること以外は、すべてオープンな場でやり取りすれば良いと思っています。
例えば急な休みの連絡はオープンに行いますが、体調・病気のことで相談したいときなどは、DMで問題ありません。

先にも少し触れましたが、オープンな場でのやりとりは心理的安全性が低いと実現できません。
上記のルール化をしているにもかかわらず、メンバーから個人的に質問がきたり、メンバー同士が個人間でやりとりしている場合は、そのメンバーにとっての心理的安全性が低いこと、必要なチャット板がないことなどが疑われます。
その場合は機会的に注意するだけでなく、下記のことも検討してみましょう。

新たな専用の板を作成する
初歩的な質問でもなんでもOKな板を作る
PM自身が質問しやすい雰囲気でメンバーと接しているか見直してみる

1. 必要なチャット板の作成

では、ここからは具体的なアクションにうつっていきます。
チャット板は、SlackやTeamsの場合はチャネルに相当します。
まずは下記のNo.1~3を作成しましょう。
必要に応じて、随時他の板を作っていきましょう。

#	板の種類	追加するメンバー	用途	重要度
1	プロジェクト全体板	プロジェクトメンバー全員	全体連絡	必須
2	各チームの板	フロントエンド/バックエンドなど、プロジェクト内の小チームのメンバー	小チーム内での連絡・相談など	10名以上のプロジェクトや、小チームに分かれている場合必須
3	マネージャー板	PM、PLやそれに準ずるメンバー+場合によって担当営業	プロジェクトの検収や継続提案、金額に関する連絡など	必須
4	進捗報告板	各小チームのメンバー	進捗報告専用の板	あると便利
5	トラブル専用板	トラブル対応に関わるメンバー全員	トラブル対応の連絡用	トラブルごとに必須
6	技術相談板	プロジェクトメンバー全員	技術的な質問	△
7	雑談板	プロジェクトメンバー全員	雑談	△
8	定期連絡板	関連するメンバー	何らかの定期連絡がある場合、全体板やチーム板だと邪魔になってしまうため、専用で作る	必要に応じて

雑談はあってもいいですが、後述するデイリーMTGなどで雑談の場がある場合は、特に作成しなくても問題ありません。
個人的には、チャットでの雑談は全社的にそのような文化が根付いているか、相当仲の良い関係でないと難しく、特にプロジェクトにおいては不要と思っています。

技術相談については、若手や新入社員がいる場合は気軽に質問するためにあると良いかと思います。

2. いつでも使えるMTGのURLの発行

リクルートの「よもやま」をご存知でしょうか?

上記の記事によると、よもやまとは以下の定義になります。

リクルートで言う「よもやま」は、1on1を表す社内用語として使われています。ただ、一般的な1on1のイメージよりも、さらに緩やかなものをイメージでしょうか。例えば、上司やななめ上メンターといった特定の相手との1on1のようなものに限らず、同僚とのありとあらゆる雑多な会話もよもやまと呼んでいます。

これはプロジェクトを進めるうえでも役立ちます。
私のプロジェクトでは、詰まったり口頭で相談したいときや急いでいるときなど、「よもやましましょう」と声をかけてWeb会議をします。

ただ、その都度Web会議を作成するのは面倒だし時間の無駄なので、適当なMTGのURLを発行しておき、チャット板の概要欄に貼って誰でもいつでも利用できるようにします。

よもやまを使う利点はかなり多く、これがあるのとないのとでは生産性にかなり差がでてきます。

都度URLを発行する手間が省ける
MTGのタイトルを考えなくてもよい
相手にURLを共有することなく、「よもやまいきましょう」で集まれる
会話する中で「この人も呼ぼう」となったときに、「よもやま参加できますか?」の一言で呼ぶことができる
そのやりとりを見ていた他のメンバーも、必要に応じて積極的に参加できる

WebMTGが盛んにおこなわれるようになってきたら、チャット板ごとにURLを発行しても良いでしょう。

アクションプランのおさらい

必要なチャット板を作成する
いつでも使えるMTGのURLを発行し、チャットの概要欄に貼る

実践2．内部MTGを設定しよう

次は、内部MTGをスケジュールしましょう。
~15人程度までのプロジェクトの場合は、全員が参加する毎日30分ほどの朝会を設定しましょう。
日々の朝会により、PM/PLは全体の状況を随時把握でき、メンバーはその日のタスクにスムーズに取り掛かることができます。
週一だと、リスクに気づくのが遅れた場合にリカバリーするのが大変ですし、細かい部分の確認が漏れたりして、全体が見えづらくなります。

朝会で話す内容は下記です。

全体連絡
顧客との朝会での決定事項の共有
その日のタスクの認識あわせ
リスクや疑問点の共有

私のプロジェクトでは、顧客朝会を週2で実施しているので、そこで決まったことを内部朝会で全体に共有します。

15人以上の場合は、小さなチームがいくつかあるはずなので、そのチームごとに分かれて実施し、各リーダーがPMに報告する形でもよいでしょう。

朝会では、顔出しはなしでも問題ありません。

内部MTGで喋るべきなのはPMではない

PMは、全体連絡をするくらいにとどめ、タスクについてはPLもしくはそれ以下のメンバーに自ら共有してもらいます。
これは、プロジェクトの推進がPMに大きく依存してしまうことを防ぐ狙いがあり、具体的には下記の効果があります。

PMが各自のタスクまで管理して本来のPMがやるべき業務に手が回らなくなるのを防ぐ
メンバーが期日とやるべきことを自覚し、責任感を持てる
普段から発言してもらうことで、疑問点や懸念点などを積極的に発言しやすい場を作る

進捗に関しては、口頭よりも、チャットで夕方に日次報告を上げてもらうと管理が楽になります(実践3)。

全体連絡は、チャットとWeb会議の二刀流で

チーム全体に共有する内容は、まずチャットで連絡をしてから、デイリーミーティングでも共有を行いましょう。
チャットのみだと流れてしまうこともありますし、口頭でのみだとその場にいなかったり聞きそびれてしまうメンバーが出てきます。
さらに、重要な連絡は一度だけでなく、複数回アナウンスしましょう。

MTGで決まった内容は、必ずテキストに残す

MTGの注意点として、その場で口頭でのみ指示してしまい、あとで確認したら指示した内容と違うことを進めていたり、MTGで確定した内容を文面で共有せずに後々メンバー間で認識がずれてしまうことがあります。
指示内容は改めてタスク管理ツールでメンションするか、各自に記載させましょう。
確定事項については、各タスクの概要欄に記載しておき、すぐに参照できるようにするのが良いでしょう。

チャット・Web会議・電話を駆使する

当然、デイリーMTGにはおさまらない内容や、特定のメンバーのみで集まりたい場合もありますので、必要に応じてMTGを設定しましょう。
トラブルなどの緊急時は、ほぼ1日中Web会議をつなげながら作業することもあります。
急ぎや緊急の連絡の場合は電話をするなど、目的にあわせて様々な手段を駆使しましょう。

アクションプランのおさらい

デイリーMTGを設定する
MTGではメンバーに喋ってもらう
全体連絡はチャットとWeb会議両方で行う
MTGで決まった内容は必ずテキストに残す
チャット・Web会議・電話を駆使する

実践3. 日次報告をルール化する

最も基礎的で、難しいのが報連相、特に「進捗報告」です。

進捗報告が得意なメンバーもいれば、苦手なメンバーもいるでしょう。
毎朝のMTGで進捗報告から行っていては、どれだけ時間があっても足りなくなります。
進捗報告は、基本的にはチャットで行い、毎日17時に報告を上げるなどルール化してしまうと楽です。
その際、下記のようなテンプレートを用意し、全員が同じ粒度で報告できるように整備しましょう。
進捗報告専用の板があると他の連絡で流れないため、おすすめです。

進捗報告テンプレート(例)

## 作業日
xx月xx日

## タスクサマリ
全◯件(完了:◯件, 進行中:◯件, 未着手:◯件)

## 報告内容
- タスクA(オンスケ)
  - 50%完了
  - ◯月◯日完了見込み
- タスクB(遅延)
  - 20%完了
  - タスクAに想定より時間がかかり遅延しているが、バッファを使うことで全体としての遅れはない想定。
  - ◯月◯日完了見込み
- タスクC(オンスケ)
  - 完了

## リスク
あれば記載

##相談内容
あれば記載

もちろん、上記は最低限で、急ぎのタスクやリスクのあるものについては、より細かい頻度で報告してもらうようにしましょう。

各メンバーの報告をPLがとりまとめ、PMに報告する流れを作りましょう。

アクションプランのおさらい

報告テンプレートを準備する
日次報告をルール化する

実践4. 半年に1回は顔を合わせる

フルリモートで、プロジェクトのメンバーと一度も顔をあわせたことがないということも珍しくないと思います。
可能な場合は、3ヶ月〜半年に一度は顔を合わせるのをおすすめします。

オンラインでのやりとりと、実際に会うのとでは、その人に対する印象が結構変わります。
実際に会うことで、その後のオンラインでの雑談につながることもあります。

すでに仲が良い場合は、夜の飲み会でも良いのですが、まずはランチをおすすめします。
飲み会より気軽ですし、出社してランチにいったり隣で作業することで、メンバーについてよりよく知ることができ、距離も縮まります。

アクションプランのおさらい

メンバーと3ヶ月〜半年に一度はランチに行く

おわりに

Qiita Engineer Festaで気になるテーマがあったため、書き始めてみたところ想定以上のボリュームになってしまいました。
今回はPM向けに、チームのコミュニケーションにおいてすぐに取り組めて効果が高い内容を記載しました。
これからPMを任されるけれど不安な方や、どうすれば良いチームづくりができるのか悩んでいる方に届き、これらを実践することでコミュニケーションが活発になり、生産性の向上につながれば何よりです。