リモートで働くようになって、一番困ったのは会議が減ったことではありません。「なんとなく怪しい」という情報が入ってこなくなったことでした。
同じ部屋にいた頃は、誰かが妙に長く同じ画面を見ているとか、独り言が増えているとか、そういうところから「あれは詰まっているな」と分かりました。声をかければ、たいていは何か抱えています。
リモートになると、この経路が丸ごと消えます。チャットには「進捗:実装中」としか書かれておらず、実際に詰まっているのかどうかは分かりません。そして詰まっていることが分かるのは、期限の直前になってからです。
この記事では、情報が流れる経路をどう設計するかを扱います。流れてきた情報の前提がズレている問題は認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に、報告が信用されない問題はプロジェクトマネジメントにおける説明責任とは？に分けました。
目次
1. リモートで消えた情報経路をどう埋めるか
まず、失われたものが何だったのかを整理すると、本人が報告するつもりのない情報でした。
「詰まっています」と報告するには、本人が「これは報告すべき状態だ」と判断する必要があります。ところが実際に詰まっているときは、たいてい本人も「もう少しで抜けられる」と思っています。だから報告されません。以前はそこを、様子から拾っていたわけです。
これを完全に埋める方法は、正直なところ見つかっていません。ただ、多少なりとも効いたものはあります。
作業時間を聞く。 進捗ではなく「この作業に今どれくらい時間を使っているか」を聞きます。予定3日の作業に5日使っていれば、本人が順調だと思っていても状態は分かります。進捗率と違って、これは事実なので解釈がぶれません。
詰まっている前提で聞く。 「何か困っていることはありますか」だと「特にないです」で終わります。「今どのあたりで手が止まりますか」と聞くと、具体的な話が出てきます。困っていることを申告させるのではなく、状態を説明してもらう形にすると、ハードルが下がります。
1on1を定期で入れる。 用がなくても話す時間を持っておくと、雑談の中で出てきます。用があるときだけ話す関係だと、「わざわざ時間を取ってもらうほどではない」という判断で情報が止まります。
三つ目が一番効きましたが、人数が増えると時間的に厳しくなるので、そこは悩んでいるところです。
2. どの情報をどこに流すか決める
情報の経路を設計するというのは、要するにどの種類の情報をどこに置くかを決めておくことです。
決めていないと何が起きるか。私が経験したのは、重要な決定がチャットの雑談の流れの中で行われ、後から誰も見つけられなくなる、という状態でした。決めた本人たちは覚えているのですが、参加していなかった人には伝わっておらず、記録も残っていません。
今は、大まかに次のように分けています。
| 種類 | 置き場所 | 理由 | | — | — | — | | 決定事項 | ドキュメント | 後から探せる必要がある | | 進捗・タスクの状態 | 管理ツール | 一覧で見たい | | 相談・質問 | チャット | 流れてよい。速さが優先 | | 相談の結論 | ドキュメントに転記 | 流れると困る |
肝は最後の行です。チャットで議論するのは構わないのですが、結論だけは流れない場所に移すというルールにしています。ここを決めておかないと、同じ議論が3か月後にもう一度発生します。
完璧に運用できているわけではありません。忙しい時期は転記が漏れます。それでも、決めていなかった頃よりはかなりましになりました。
3. 同期と非同期を使い分ける
会議を減らそうという話はよく出ますが、何でも非同期にすればいいというものでもありませんでした。
私の中の基準は、認識を揃える必要があるかどうかです。
情報を渡すだけなら非同期で足ります。進捗の共有、決定事項の連絡、資料のレビュー依頼。これらは会議にする必要がありません。実際、以前は定例で1時間かけて順番に進捗を読み上げていましたが、事前に書いてもらう形に変えたら30分になりました。
一方で、認識を揃える必要がある場面は、同期でやった方が速いです。仕様の解釈が分かれているとき、方針を決めるとき、悪い知らせを共有するとき。これをチャットでやろうとすると、往復が何度も発生して、結局は時間がかかります。しかも文字だけだと、相手が納得しているのか渋々なのかが分かりません。
定例の時間が短くなったぶん、そこで「相談」に使える時間が増えたのは良かった点です。進捗の読み上げに使っていた時間は、後から思えばほとんど価値がありませんでした。
4. 書くと消えてしまうもの
非同期を増やして分かったのは、文字にすると落ちる情報があるということです。
一番落ちるのが確度です。「来週には終わると思います」と書かれたとき、それが確実なのか希望なのかは、文面からは分かりません。対面なら言い方で伝わっていた部分です。
これについては、書く側にフォーマットを渡すことで多少改善しました。前述の通り「確定／見込み／未確定」を明示してもらう形です。詳しくはプロジェクトマネジメントにおける説明責任とは？に書きました。
もう一つ落ちるのが感情です。これは仕方のない面もありますが、テキストだけのやり取りは実際より冷たく読めます。私も何度か、こちらにその気がないのに「怒っている」と受け取られたことがあります。
対策として、指摘をテキストで送るときは意図を一言添えるようにしました。「責めているわけではなく、原因を切り分けたいので聞くのですが」といった前置きです。少し冗長になりますが、誤解を解く方がよほど時間を使います。
5. 対立を放置しない
最後に、意見の対立について書いておきます。
技術的な方針で意見が割れること自体は、悪いことではありません。問題は、割れたまま放置されることです。放置されると、それぞれが自分の考えで作業を進めてしまい、後で統合できなくなります。
私が気をつけているのは、その場で結論を出さないまでも、いつ誰が決めるかは決めることです。「今は判断材料が足りないので、来週の定例で私が決めます」と言っておく。これだけで、宙に浮いたままにはなりません。
そして決めた後は、採用しなかった方の理由も説明します。これを省くと、「聞いてもらえなかった」という感覚が残ります。次から意見が出てこなくなるので、結果的に情報が減ります。
リスクや懸念が上がってこなくなる問題についてはリスク管理の重要性：ITプロジェクトでのベストプラクティスにも書きました。
6. まとめ
情報の流れを設計するというのは、次のようなことでした。
- 本人が報告しない情報をどう拾うか。 リモートで一番失われたのはここ。作業時間を聞く、状態を説明してもらう、1on1を定期で入れる。
- どの情報をどこに置くか決める。 特に、チャットで出た結論を流れない場所へ移すルール。
- 認識を揃える必要があるかどうかで同期・非同期を分ける。 情報を渡すだけなら会議は要らない。
- 文字にすると確度と感情が落ちる。 確度はフォーマットで補い、意図は一言添える。
- 対立は結論が出なくても「いつ誰が決めるか」を決める。
どれも派手な施策ではありませんが、これらが欠けたまま進むと、問題が表に出るのが遅れます。遅れて出てきた問題は、たいてい高くつきます。
流れてきた情報の前提がズレている場合は認識齟齬がプロジェクトを壊す？成功に導くマネジメント術を、報告が信用されない状態についてはプロジェクトマネジメントにおける説明責任とは？を参照してください。全体の枠組みはITプロジェクトマネジメントの基礎とその重要性です。