報告・共有は相手によって何を変えるか
読み手を影響力と関心度、役割の2つで分けると、伝える頻度と中身がそれぞれ決まる。意思決定者にはペライチを渡し、ラリーは事前の個別の会話で減らす。遅れはバッファを積んだ日付で出し、重大な問題は6点で上げる。
まとめ
- 読み手を「影響力 × 関心度」と「役割」の2つで分ける。前者で頻度と手間が、後者で伝える中身が決まる
- 意思決定者にはペライチを渡す。ドキュメントを作って投げてもラリーは減らない。減らすのは事前に個別で話しておくこと
- 遅れは楽観値で出さず、バッファを積んだ日付で出す。重大な問題は6点で上げる
参考: How To Communicate Project Status To Different Stakeholder Groups / ステークホルダーコミュニケーション - 上手な付き合い方とは？
ドキュメントを作って投げていた
プロジェクトを始めると、まず必要そうなドキュメントを一通り作っていた。 同じ説明を何度も求められるラリーを先回りして減らしたかったのと、あとから参加する人に「これを見ておけばいい」と渡せるようにしたかったからだ。 立ち上げでそこにリソースを取られ、開始が遅くなるデメリットは感じていた。
上司にこの進め方を聞いたところ、答えは前提から違っていた。 意思決定する人はドキュメントを読まない。 サマリーがあれば読むかもしれない、くらいだという。 ドキュメントがあってもラリーは起きるし、「ドキュメントのここに書いてあります」と返すのは、相手には「なんで読んでないの」と聞こえる。
ラリーを減らすのは、主要な人と事前に個別で話しておくことだと上司は言う。 立ち話でも Slack でもよく、大事なのは相手が「事前に聞いていた」という事実のほうだ。 知らされていなかった人は「なんでこうなってるの」と聞き返す。 事前に聞いていた人は、理解の深さは同じでも「聞いてたしな」で終わる。
読み手を2つの軸で分ける
ドキュメントが悪いわけではない。 手を動かす人とのずれをなくすには要る。 問題は、全員に同じものを渡していたことだった。 読み手ごとに何を渡すかを決めるために、まず読み手を分類する。
1つ目の軸は影響力と関心度で、4つの象限に分ける。
表1: 影響力と関心度の4象限
| 象限 | 例 | 接し方 |
|---|---|---|
| 影響力が高く関心も高い | 顧客、プロジェクト責任者 | 定例や週次で密に報告し、判断に巻き込む |
| 影響力が高く関心は低い | 上層部 | 重要なことだけを簡潔に、定期的に。出しすぎない |
| 影響力が低く関心は高い | 影響を受ける部署の担当者 | 週報や共有ドキュメントで定期的に知らせ、質問に応える |
| 影響力も関心も低い | 間接的に関わる部署 | 公式の報告の場に含め、見たいときに見られるようにしておく |
最初に勘違いしたのが、この2軸を自分から見た値だと思っていたことだ。 影響力は相手がプロジェクトの行方（日程・範囲・体制）をどれだけ左右できるか、関心度は相手の業務に響くので進み具合をどれだけ気にしているか、で、どちらも相手側の性質である。 自分の役目は、その値を見積もるところまでになる。
役割ごとに渡すものを変える
4象限で決まるのは頻度と手間までで、中身は決まらない。 中身は役割で決める。
表2: 役割ごとに気にすることと渡すもの
| 役割 | 気にすること | 渡すもの |
|---|---|---|
| スポンサー（後ろ盾になって最終的に判断する人） | スコープ、大きなリスク、自分が下す判断 | ペライチ |
| 部門マネージャー | 人の要求量、チームの空き、部署間の依存 | 人と時間の見通し |
| 影響を受ける部署、連携先 | いつ始まりいつ終わるか、何に響くか | 開始、終了、影響範囲 |
| チームメンバー | 優先順位、ブロッカー、担当 | 手順書、作業指示 |
当てはめてみて分かったのは、肩書きと役割が一致しないことだった。 部門長でも、こちらが判断を求める相手ならスポンサーとして扱うほうが合う。 影響を受ける部署や連携先は、手順書を渡されても、気にするのは開始と終了と影響範囲くらいだろう。
自分のプロジェクトで並べると、チームメンバー向けの手順書や作業指示はすでに足りていた。 空いていたのはスポンサー向けのペライチだけだった。
スポンサーに渡すペライチの型
スポンサー向けの要約は、次の3つに答える。
- 計画どおりか
- 何がリスクか
- 何を決めてほしいか
本文は毎回同じ順に並べる。 要約（1〜3文）、前回から完了したこと、リスクとブロッカー（担当・対策・期日つき）、次の節目、依頼（誰に何を）の順だ。 要約と依頼だけ読めば判断できる形にしておく。 上司の言い方では「ペラ一にまとめられないことは伝えきれない」。 詰め込むのは、自分でもまとめきれていない証拠だという。
遅れを報告するときの日付についても指摘を受けた。 実績から引いた日付は楽観でしかなく、それで出すとまた遅れて2回目の遅延報告になる。 1回目にバッファを積んでゆるい日付を出しても、怒られる量はあまり変わらない。 2回目の遅延報告のほうがダメージが大きい。
重大な問題を上げるとき
ペライチに載せる問題は、スポンサーに判断か動いてもらう必要があるものに絞る。 自分たちで対処できる問題は手順書やチケットの側で扱う。
上げるときは次の6点を書く。
- 何が起きたか
- 影響（日程、費用、範囲、品質のどれにどれだけ）
- 原因（推測ではなく実際の原因）
- 選択肢
- 推奨（どれを、なぜ）
- 担当と次回の報告時期
人を責める書き方は避け、事実で書く。 上げたあとに続報を出さないでいると、相手には対処が進んでいるのかどうかが分からない。 問題がもう一つ増えるので、進み具合を続けて知らせる。
デイリーで何を報告するかは以前 デイリーミーティングで何を報告するか？ に書いた。 あちらはチームメンバー向けの話で、今回の分類では一番下の段にあたる。