進捗会議に限定するわけではありませんが、問題点や課題を報告しているのに相手に伝わらない、という経験はないでしょうか。
確かに報告しているのですが、受け取り側が報告内容の重要度を誤ったり、正しい判断が行われなかったことでトラブルにつながるようなケースです。
こちらはしっかり報告しているのに、後回しにされたり、何も手を打たれなかったり。
そして忘れたころに揉めるんです。
このような事態を回避するためには何をしなければいけないのか、考えていきたいと思います。
報告トラブルの例題から原因を考察
よくありそうな例を出してみましょう。
ある新規のシステム開発におけるチームリーダとプロジェクトマネージャとのやり取りです。
開発しているシステムの一部機能について、チームリーダは品質に問題があることに気づきました。
しかも不具合がでると業務影響の大きい部分の品質問題です。
特に致命的な不具合が発見されたわけではないのですが、潜在バグが残っている可能性があると思われます。
そこで、チームリーダは進捗会議で次のように報告しました。
「XXXの機能ですが品質に問題があります。現状のままでは不具合無しで本番稼働させるのは難しいです」
その報告を受けたプロジェクトマネージャは、次のように回答しました。
「では、次のテスト工程で不具合を出すように注意してテストするように」
以上のやり取りを行った後、特に具体的な対策が行われることなく本番稼働しました。
すると上記の機能で不具合が発生。
しかも業務に大きな影響がでる致命的な障害となりました。
チームリーダとしては、品質問題について報告書への記載と口頭での説明を行っているため、報告義務は果たしていると考えています。
プロジェクトマネージャとしては、まさか業務影響につながる品質問題だったとは考えておらず、本格的な対策の必要性を感じていませんでした。
これは「プロジェクトマネージャの考慮不足ではないか」と言われそうです。
確かに報告内容を受け止めて、品質向上の対策を適切に指示していれば回避できたトラブルとします。
ただし「受け止め側が気を付ける」だけでは限度があります。
また報告してもトラブルにつながっては意味ないので、相手に正しく理解してもらうための工夫が必要です。
この例から、何が問題だったのか考えていきましょう。
曖昧なやり取り
チームリーダは機能に品質問題があると伝えたのですが、その影響範囲や重要度について具体的にプロジェクトマネージャに伝えていませんでした。
プロジェクトマネージャとしては、報告を受けたときに業務影響への影響が大きい話と認識していなかったとします。
もし「業務に大きな影響を与える部分の品質問題」であること伝えていれば状況は変わっていたかもしれません。
また「不具合なしで本番稼働させるのは難しい」という報告では、頑張れば対応できると捉えることもできそうです。
リスクについて報告するのであれば「影響度」と「発生確率」が必要です。
注意すべき報告については曖昧なやり取りではなく詳細まで報告し、報告する側と受け取り側が同じ認識となるようにする工夫が必要です。
現場と管理者、経営者の観点の違い
報告者と受け取り側では、お互いの考え方や気になる点が異なっていることが良くあります。
特に現場と管理者、経営者では意識している観点が違います。
現場はモノづくりが気になりますし、経営者は事業の観点で考えています。
そのため報告の仕方を工夫しないと経営者側に必要な情報が届かないことになります。
トラブルを回避するためのルール作り
報告書を作成するとき、相互に意思疎通ができるためのルールを設けるのが効果的です。
ルールとは報告の基本テンプレートであり、「この事象のときはこれを報告すること」ということを最初に取り決めておきます。
上記の事象であれば、報告内容に「影響度」「発生確率」「リスク発生時の事象」「リスク対策」を記載するルールにするなど。
このルール決めには報告をする側も、また受ける側も参加して全体合意します。
そもそも報告する側とされる側では立場や考え方が違うので、最初から自分の言葉だけでは伝わらないと認識した方が良いです。
終わりに
コミュニケーションは相互の言葉や意思のキャッチボールです。
ボールを投げたからと言って、相手が受け取れなければ意味がありません。
また受け取り側も、どこにボールを投げてほしいか明示すべきです。
「〇〇の言っていることが伝わらない」というのではなく、何を伝えてもらえれば理解できるのか、はっきり言うべきです。
その橋渡しとなるルールを決めることで、お互いのコミュニケーションを円滑にすることができれば、「言ったけど伝わらない」は改善されていきます。
