「リーダーの報・連・相」こちらの本、読みました。
報・連・相は、仕事で特に問題なく出来ているとは思いますし、どういった動きをすれば良いかも分かっているつもりです。
ただ、報・連・相を言語化するとなると、意外と難しいかもなぁと思ったり。
また、本タイトルに「リーダーの」と付いているのに興味を持ちました。
なんとなく「リーダー」と「報・連・相」があまりリンクしないというか、関連性がそこまでないような気がしてしまうというか。
そういった部分で気になって本書を読んでみました。
なお、本書の読書感想は「前編」「後編」の2つに分けて投稿しようと思います。
今回は前編として、アレコレ書いていきます。
本の内容
まずはAmazonから本の内容を抜粋します。
報連相を機能させるのは「あなた」です。
この本は、「いつも指示通りに動かない」「ミスをひた隠しにする」「何を考えているかわからない」という部下に困っている、
もしくは「チームでの伝達がうまくいかず、成果が上がらない」と悩んでいる
中堅社員（リーダーやマネジャー）のために書きました。
あなたのチームは「報連相」を徹底することで必ず見違えます。
「報連相」というと「それって新入社員が学ぶものなんじゃないの？」と思われる方もいるかもしれません。
しかし、実は報連相を機能させるための鍵を握っているのは、部下を指導する立場にある中堅社員、
つまりこの本を手に取った「あなた」なのです。
こんな感じの本です。
記事の冒頭でも少し触れましたが、「リーダー」と「報・連・相」は関連性がそこまでないような気がしていました。
ですが著者からすると、報連相を機能させるための鍵を握っているのはリーダー、とのこと。
いくつか引用と感想
報告のキホン
報告とは、「指示を与えられた人が、指示を与えた人に仕事の途中経過や結果を告げること」です。
通常、指示は自分より上位の人から与えられます。ですから報告は、部下から上司へ、また担当者からお客様へということもあるでしょう。
このように報告は上位者に行うもので、基本的には1対1で行います。忘れてはならないことは、報告とは指示を受けたものの「義務」であるということです。つまり、依頼された限り、どんな小さな仕事でも終了したら報告をして初めて義務を果たしたことになります。そういう意味では「報告までが仕事」とも言えます。
「報告」はもちろん分かっているつもりですが、言語化するとなると意外と難しいです。
その自分にとっては難しい言語化をしてくれていたので、引用してみました。
自分がメインで報告を行うタイミングは、朝に行われるデイリーの会議です。
そこで一日分の進捗報告をしている感じです。
引用では「基本的には1対1」となっていますが、そのデイリー会議では5人前後のチームメンバーが集まっている感じです。
もちろん、デイリー会議以外でも報告するタイミングがあります。
例えば、「次の日のデイリー会議を待たずに、早めに報告しておいた方が良いな」と思うものや、突発的に発生したトラブルに関するもの等です。
本書でも「中間報告」「結果報告」「トラブル報告」「変更報告」に関して、それぞれ詳しく解説しています。
引用すると長くなってしまうため、その辺りは割愛しています。
詳しくは本書を読んで頂ければと。
連絡のキホン
連絡とは、「自分が見知った仕事に関する事実や情報、あるいは自分の身に起きたこと、経験したことを関係者に正確に伝えること」です。ここで言う見知った事実や情報とは、お客様の人事異動や競合他社の新商品の開発などが当たります。
「連絡」は関係者全てに対して行うものですので一対複数、つまり上司だけでなく同僚や部下、他部署に対しても行います。また、「連絡」も「報告」と同様に「悪い情報」だけでなく、「良い情報」も関係者と共有することが大切です。
「連絡」は「報告」と違い、義務ではありません。だからと言って、もちろん軽く考えてはいけません。「義務」になっていない分、「連絡」するしないは、その人の主体性が問われます。ですから、周囲への思いやりや配慮の気持ちといった「チーム意識の差」が、明確に表れてしまいます。指示の有無にかかわらず、仕事を円滑に進めるためにも周囲に有用な情報は積極的に「連絡」を行うよう指示していきましょう。
「連絡」も個人的に意外と言語化が難しいなということで、引用してみました。
こうやって言語化された状態で振り返ると、自分はあまり連絡的なことをそこまで多くはしていない気がします。
他のメンバーのことを思い返しても、連絡の頻度にはかなり個人差が出ている感じがします。
引用にもある通り、連絡が義務ではないとなると、コミュニケーションに若干の億劫さを感じる自分としては少なめになってしまいます。
とはいえ連絡することはもちろんあります。
例えば、職業的にはよくある内容ではありますが、「開発環境の構築時に発生したエラーと、そのエラーの対策」を共有することは多々あります。
この開発環境構築時のエラーは、他のメンバーはエラーにならず、結局自分だけしかそのエラーが出なかった、なんてこともけっこうあります。
なので共有するかどうか、という観点だと義務ではない感じもあります。
ですが、こういったエラーとその対策は積極的に共有するようにしています。
もし同じエラーが発生したなら、とりあえず自分が共有した対策が役立つことも多いですし、チームで仕事を進めていくうえで大事な習慣かなと思っています。
（なぜか同じエラーなのに、その対策で解決しない場合もありますが。）
相談のキホン
相談とは、「上司や先輩、経験者などに話を聴いてもらって解決の糸口をつかむこと」です。
長期的に成功している人には共通点がありますが、その一つが他人の知識・スキル・経験を活用するのがうまいということです。
相談することで得られた情報や知識は、問題を解決するきっかけとなり、アドバイスされた解決策がその後のノウハウや経験として蓄積されていきます。
上司や先輩の経験やアドバイスは部下を成長させる絶好のチャンスです。報告や連絡だけでは、決して得ることができない諸先輩のノウハウや、会社の貴重な知的財産を得ることができるのです。（中略）
「相談」は「連絡」と同様に義務ではありません。つまり、するかしないかはその人の判断になります。
義務ではないだけに、相談とは「仕事に対する意欲」の表れが「見える化」したものなのです。「何としても高い目標を達成したい」と強く思えば思うほど、自分一人の力では足りないと感じて、必然的に「相談する」という行動になります。
「相談」もうまく言語化されていたので、引用してみました。
「報告」「連絡」ときたので、「相談」もついでに。
相談に関しても、こうやって言語化された状態で振り返ると比較的少なめかもしれません。
なるべく自分で解決しようという意識が強めなのと、なかなか周りを頼れない性格の影響かなと思います。（以下のような本を読んでるくらいですし。）
なお、引用に『相談とは「仕事に対する意欲」の表れが「見える化」したもの』とありますが、なんでもかんでもすぐに相談する人はそれに該当しないかなーとも思ったり。
ただ本書では相談のポイントとして「自分の意見を持って相談する」を挙げているので、そこも含めて考えれば納得できます。
※ポイント部分は長くなってしまうので割愛しています。詳しくは本書を読んで頂ければと。
おわりに
ということで、「リーダーの報・連・相（前編）」としてアレコレ書いてみました。
今回の記事で引用したのは
- 報告のキホン
- 連絡のキホン
- 相談のキホン
の3つでした。
前編は報連相それぞれの詳しい説明を引用してみました。
報連相それぞれは分かっているつもりだったのですが、こうやって言語化されると解像度が上がると言いますか、意外と具体的には理解出来てなかったかも…と思いました。
今回こうして報連相を学び直せて良かったです。
次回は「リーダーの報・連・相（後編）」としてアレコレ書いていきます。
（追記）
「リーダーの報・連・相（後編）」の記事を書きました。
こちらも良ければぜひ。
