【Bizトレコラム】#5：③仕事は一人で完結しない、「会議・チームワーク」で差がつく

第1回では「仕事の渡し方と受け取り方」、第2回では「相談・レビュー・修正」を取り上げた。

ここまでの話は、上司と部下という一対一の関係が中心だった。

しかし、実際の仕事はもう少し複雑である。

会議には複数の関係者が参加し、ひとつの案件を何人ものメンバーで進める。営業、企画、開発、管理部門など、立場の異なる人たちと協働することも珍しくない。

ここから先は、自分自身の仕事をきちんと進めるだけでは足りなくなる。

自分の考えを他者に伝える。
相手の考えを理解する。
誰が何をするのかを決める。
意見が違えば、その違いを整理する。
最終的にはチームとして一つの方向に進む。

こうした「他者と仕事をする技術」が必要になるからである。

ところが、職場では個人の能力とチームの能力が混同されやすい。

資料を作るのが速い。分析が得意である。専門知識が豊富である。

こうした能力はもちろん重要だが、それだけでチーム全体の成果が上がるとは限らない。

会議で何も発言しなければ、その知識は共有されない。担当範囲が曖昧なら、優秀なメンバーが集まっていても仕事が抜け落ちる。各自が自分の成果だけを追いかければ、部分最適が起きる。

第3回では、こうした協働の場面で必要になる6組を取り上げる。

会議が長くなる原因として、「参加者の話が長い」という説明がよく使われる。

もちろん、それも一因ではある。

ただし、会議の進め方を観察すると、もっと手前に原因があることも多い。

会議が始まってから資料を読み、状況を理解し、その場で初めて論点を考えているのである。

たとえば30分の会議で、

「まず資料の内容を説明します」

と15分使い、その後、

「それで、どうしましょうか」

と議論を始めれば、残り時間は15分しかない。

その状態で複数の意見が出れば、結論までたどり着かないのも不思議ではない。

できる部下は、会議前に資料を読み、自分なりの意見や確認事項を整理してから参加する。

単に資料に目を通すだけでなく、

「この提案には賛成だが、この数字の前提は確認したい」

「A案とB案ならA案がよいと思う。理由は納期への影響が小さいからだ」

というところまで考えておけば、会議中の発言も具体的になる。

一方、上司側には、会議そのものを設計する役割がある。

会議を招集するときに、

「新サービスについて話し合います」

だけでは、参加者は何を準備すればよいのか分からない。

これを、

「新サービスの価格を決定したい。A案とB案のどちらにするかを議論するので、それぞれのメリットとリスクを確認しておいてほしい」

と伝えれば、参加者は会議前から考え始めることができる。

会議時間だけを見るのではなく、会議前の準備まで含めて設計した方が、結果として全体の時間を短くできる。

上司が論点を示し、部下が自分の考えを持って参加する。この組み合わせができると、会議は情報をインプットする場から、判断するための場へ変わっていく。

会議では、発言すること自体が目的になってはいけない。

意見を述べるのであれば、その発言が議論を前に進める必要がある。

たとえば、

「私はちょっと違うと思います」

だけでは、議論は進まない。

なぜ違うと思うのか。
どこに問題があるのか。
代わりにどうすればよいのか。

ここまで話して初めて、他の参加者がその意見を検討できる。

できる部下は、反対するときにも、

「A案だと開発期間が3か月延びる可能性があります。そのため、今回のリリースでは機能を絞り、残りは次回に回す方がよいと考えます」

というように、理由と代案をセットにする。

反対意見を出さない方が協調的なのではなく、必要な論点を出したうえで解決策まで考えることが、チームへの貢献になる。

一方で、参加者から良い意見が出ても、上司が議論を終わらせなければ仕事は進まない。

会議の終了間際になって、

「いろいろ意見が出たので、引き続き検討しましょう」

となる会議は意外に多い。

議論が必要な会議であっても、最後には少なくとも、

「何が決まったのか」

「何が決まらなかったのか」

「次に誰が何をするのか」

を明らかにする必要がある。

すべての論点について結論を出せない場合でも、

「今日はA案とB案の比較までできた。コスト情報が不足しているので、田中さんが水曜までに確認し、木曜に最終決定する」

とすれば、仕事は次につながる。

会議を活性化することと、会議で意思決定することは別の能力である。

部下が建設的な材料を出し、上司がその材料を使って判断する。この役割分担が機能すると、会議は単なる意見交換で終わりにくくなる。

上司から、

「A案とB案、どっちがいいと思う？」

と聞かれたとき、

「私はA案がいいと思います」

とだけ答える人がいる。

もちろん意見を持つこと自体は悪くない。

ただ、ビジネス上の意思決定では、その意見を採用すべき理由が必要になる。

「なぜAなのか」

という問いに答えられなければ、それは判断材料として使いにくい。

そこで、できる部下は、

「納期、コスト、顧客への影響の3点で見ると、A案がよいと考えます。コストはB案より高いですが、納期を守れるためです」

というように、根拠を添えて答える。

これによって上司は、その結論だけでなく考え方まで確認できる。

ただし、「根拠を示せ」と言うだけでは、部下が迷うこともある。

何を基準に判断すればよいのかが明らかになっていないからである。

たとえば、新しいシステムを選ぶ場面で、

「どれが一番いい？」

と聞くのと、

「今回は価格よりもセキュリティと導入スピードを重視したい。その前提でどれがよいと思う？」

と聞くのでは、部下の考えやすさが大きく変わる。

上司が判断基準を示すことには、もう一つ意味がある。

部下は、その基準を何度も使ううちに、上司に聞かなくても自分で判断できるようになる。

最初は、

「AとBのどちらにしますか」

と聞いていた部下が、やがて、

「今回は納期を優先する案件なのでA案で進めます」

と判断できるようになる。

部下に判断力を身につけてもらうのであれば、答えだけを教えるよりも、その答えを導いた基準を共有した方がよい。

実務では、最初からきれいに整理された仕事ばかりが降ってくるわけではない。

「この新規事業について考えてほしい」

「最近問い合わせが増えているので、何か対策を考えて」

「来月の役員会に向けて資料をまとめてほしい」

といった、かなり曖昧な依頼もある。

こうした仕事に対して、

「具体的に何をすればいいですか」

と聞き続けていては、自分で仕事を組み立てる力は身につきにくい。

できる部下は、曖昧な仕事をそのまま受け取らず、自分なりに分解する。

たとえば、

「問い合わせ増加の対策を考えてほしい」

と言われたなら、

「まず問い合わせ件数の推移と内容を確認し、増えている原因を分類します。そのうえで対策案を整理する進め方でよいでしょうか」

と返す。

上司が完成形まで指示していなくても、部下側で仕事の進め方を仮置きできれば、自走できる範囲は広がる。

ただし、それを理由に上司が曖昧な仕事をそのまま投げればよいわけではない。

特に経験の浅い部下に対して、

「そこから考えるのが仕事だから」

とだけ言って任せると、必要以上の試行錯誤をさせることになる。

上司は少なくとも、

何を解決したいのか。
どこまで任せるのか。
制約条件は何か。
途中でどの段階を確認するのか。

といった情報を渡した方がよい。

部下に考える余地を残しながら、判断するための前提は提供する。

「任せる」と「丸投げする」の違いは、仕事を進めるために必要な前提まで渡しているかどうかに表れやすい。