代表ブログ

上司も人間なので
仕事でうまくいかない時は悩んでしまいます。

よくある悩みとしては

「自分の指示が部下に上手く伝わっているか分からない」

 
ということですね。

相手のオデコに
何を考えているかが表示されれば分かりやすいのですが、
残念ながらオデコには何も表示されません。

相手の頭の中は見えないんですね。

そして、部下も上司の頭の中が見えないんです。
見えていないので、理解できないんです。

口頭で伝えただけで、
100％を理解することは不可能で、
いいとこ20％くらいしか伝わっていないのが普通なんです。

だから、
口頭で伝えて部下が
「はい」
「わかりました」
って言ってても、それは
「聞こえました」
と同じ意味で、
理解しましたではないんです。

なので、
伝わっているかどうか分からない
場合は
ほぼ伝わっていない、と思ったほうが無難です。

前提を変える

では、どうすればいいのか？

それは
前提を変えることです。

デザインでの鉄則は
ユーザーは
まず、見ないし
見たとしても信じないし
信じたとしても動かない
という前提に立つことです。

デザインを作っただけでは誰も見てくれません。
見たとしても他人の言っていることをすぐには信用しません。
信用したとしても、いろいろと理由を付けて動かないことを選択します。

なのでデザイナーの仕事は
いかに見せるか？
いかにして、信用させるか
いかにして動かせるか
になります。

見てくれない、
信じてくれない
動いてくれない

と嘆いているのは仕事をしていません、
と言っているのと同じなんですね。

上司も同じで
部下には
伝わらないし
伝えても理解しないし
理解しても行動しない
という前提で接する必要があります。

部下が真面目に仕事に取り組もうとしていても
そもそも伝えられたことをしっかりと聞くにはスキルが必要です。

でもそのスキルがない状態では聞けません。

聞けたとしても、それは音として情報を受け入れただけなので
内容について、全く精査できていません。

理解するために必要な土台の知識もない状態なので、
理解することは出来ないんですね。
上司が手伝ってあげる必要があります。

また、理解したとしても、行動できるかは別です。
多くの場合は行動する方法が分かりません。
なので、自分で勝手に失敗が確定している方法を選んでしまいます。
どうせ失敗するならストレスが少ないほうが良い、
ということでストレスの少ない楽な方法を選択します。

そういう仕組みなので

いかに伝えるか、
いかに理解させるか
いかに行動させるか

 
を具体的に考えて、

伝わったか、
理解させられたか、
行動したか

を測定し、数字を見せて、部下を育成する必要があります。

部下は失敗する
を前提にして

一緒に成功させるために何が出来るかを考えることが上司の仕事なんですね。

 

責任は部下にある

ただしここではっきりとさせておく必要があるのが

部下が失敗したときの責任は誰にあるか？

です。

答で言うと

失敗した場合、
部下は部下に責任があると考え、上司のせいにしてはいけない。

上司は上司で自分に責任があると考え、部下のせいにしてはいけない。

が前提です。

上司のせいで失敗した、と言っている部下は
問題の本質が見えていないことが多く、

部下のせいで失敗した、という上司は、
上司として自分の仕事ができていなかったと言っていることと同じです。

部下は部下の目線で、
失敗を避けるために出来たことを明確にする責任を負います。
それが上司の判断に問題がある場合はそれを情報として明確に伝えて、
再発防止をする責任があります。

自分だけで愚痴を言って、
上司の責任にすることは責任を果たしていることにはなりません。

上司も
部下の失敗は全部、自分が悪いです、
みたいな高倉健っぽい昭和の上司感を出してしまうことがあると思いますが、
それは正しくありません。

誰も悪くなんてない

 
という前提で、
誰が悪いかの犯人探しではなく、
問題を明確にして、
対処法を明確にして、
期日を定め、
再度実行するだけです。

部下の頭の中を出来るだけ早い段階で明確にする

上司は部下よりも経験が豊富なことが普通なので、
事前に部下の頭の中が把握できれば、事前に問題を潰せます。

でも
頭の中が見えていなければ
成果物で、頭の中を理解することになります。

部下が
「できましたーーー」
って何かを作って持ってきた時に、
こいつ、全く理解していなかったな、

って。

下記のフローで言うと

１、タスクを振る前
２、タスクを振る最中
３、タスクを実行中
４、タスクを仮完了
５、タスク完了

の4の段階で気づくんですね。

そうなると時間も無駄ですし、
上司も部下もメチャメチャ、ストレスがたまります。

なので、
出来るだけ早い、
というか

打合せの段階で、部下と上司の頭の中を明確にする必要があります。

 
その時に部下が理解していない
という前提で進めることが出来れば
明確にするための指摘は必須ですし、
攻撃でもなく必要なことと理解できます。

それがないと指摘を減らしたい、
打合せをむやみに短くしたい、
という間違った価値観の下での仕事になります。

部下を失敗から守る

仕事は元々、誰かのストレスをお金をもらって代行する行為です。
そのストレスの多くは失敗で増幅します。
打合せで、頭の中を明確にすることで
失敗を減らしストレスを最小化することが出来ます。

でも、打合せは明確にする作業なので、
打合せにもストレスが掛かります。

部下は目の前のストレスを優先するので
打合せのストレスを最小化しようとします。
なので打ち合わせを避けます。
相談せずに作業を行います。

ストレスがかかるのを出来るだけ先にしようとします。
そうすると手戻りが発生するんですね。

なので、
上司は打合せをする意味をしっかりと説明し、
指摘が必要な前提を伝え
迷うことなく指摘をして明確化します。

それが部下を失敗から守り、ストレスを減らすことになるからです。

相手の経験が少ないのに、
打合せもせずに、部下に任せています、という上司は責任放棄ですね。
成功する仕組みを作れていれば、それでいいですが。

ということで
子供が親無しで生きていけないように
部下も上司無しで会社で生き残れません。

部下本人は気付いていなくても、
上司はメチャメチャ部下のことを守っています。

それによって部下が育てば、上司はメチャメチャ嬉しいです。
少なくても自分はメチャメチャ嬉しいです。

その喜びを得るために、

敵は問題、

 
と明確に認識して
部下のために問題を潰していきましょう。

電子書籍にまとめてみました。

「正社員が1年で働く時間は
たった２２％ってご存じですか」

代表ブログでアクセスの多い記事をピックアップしております。

幸せに働くとは何か？ その答えがここにある。
奥野　勝也 (著), シナジーデザイン株式会社 (著) 形式: Kindle版

Amazonで99円で販売中

Kindle Unlimited会員なら0円

書籍の詳細はこちら