ブログの記事を募集したら「こういう人になってはいけない」という話題で書いてみてはどうかという意見があったのでそれを書いてみようかと。
ちなみにネタとして以下のものを上げていました。
- KVMの構築方法
- KVMでゲストOSをコピーする
- golangでRSSを読み取る
- GoogleAppsScriptでSlackに投稿する
- .bashrcと.profileの違い
- Ansibleの使い方
- ネットワーク関連でわからないことをまとめた
- 仮想環境にvyOSをインストールしてpingを通す
- ttrssを使う
- 後輩ちゃんから学んだこと
- 後輩くんの成長を感じた話
- 「時間は自分で作るもの」と宣言したら痛い目を見た話
この中でなんで「こういう人になってはいけない」というのを上げてきたｗｗ
まぁ色々と書きたいことがあるけどようやく書く気分になったので今日は「こういう人になってはいけない」という話題で自分の思っていることを書こうと思います。
視点が2つある
このお題をもらった時に自分の中で一つの疑問が浮かびました。
「なぜこんなことを思ったのか」
です。
他人の意見を聞いてみたいと思ったんだろうとは思うけど、身近な何かで思うところがあって、それが関連してこのお題につながったのかなと。ということで仮説ではありますけど、仕事にフォーカスして"こんな人"を"こんな上司"に置き換えて行こうと思います。
置き換えてたとしても、今度は2つの視点があると思いました。
その2つの視点とは以下。
上司の立ち位置の場合
自分が上司の立ち位置にいる場合には、「どういう風にふるまえばいいのかわからない」「このような対応でよかったのだろうか」という疑問からこの話題を聞いてみたいのかなと思いました。部下の立ち位置の場合
自分が部下の立ち位置にいる場合には、上司のアクションに対して「これって普通なのだろうか」とかそういう疑問から聞いてみたいのかなと思いました。
どっちの視点で聴いてきたのかは定かではないし、どっちも自分の中では別の意見があります。
ただ、反面教師的な部分もあるので今日は「部下の立ち位置」に立って「こんな上司に困った」ことをランキング形式で書こうと思います。
前置きが長くなりましたが、「こんな上司に困った」ランキングを発表しようと思います。
3位 言うことが日々違う（言ったことを忘れる）
第3位は「言うことが毎日違う（言ったことを忘れる）」です。
例えば、資料作成の指示が出たとします。
「この目次でパワポで作ります。」と宣言して「うんうん。それでいいよ」とOKをもらって、数日後にドラフト渡したら「いや・・・こうじゃなくてWordで作ってほしかったんだよね」と意見が180度変わる場合がある。
部下としては「ちゃんと確認したのにーーー」っていう感じでモチベーションがすごく下がります。
意見が変わるのはしょうがない。時間がたてば変わることもあるでしょう。新しいアイデアが浮かぶこともあるでしょう。なので、違うものになることに対してはとくに困ったけど困っていなかったです。
この事例で一番困ったのは
「そんなこと言ったっけ？まぁいいや。さっき言ったとおりにして」
と、ばっさり会話を切ってしまうこと。
「やっぱりこの前こういったけど、こうしたほうがいいと思うから変更して」とか言ってくれればモチベーションも保てるけど、あたかもこっちが悪いかのような雰囲気を醸し出して「確認しないのが悪いんだろうが」という感じで話を進められるのが今後どうやって対応すればいいのかわからなくなります。
そこから学習して、こまめに確認するようになると「そんなに確認されると頼んでいる意味なくない？」といわれる始末。どうすればいいんすかね。
上司の方・・・・仕事管理するならば指示内容ぐらい覚えておいて(´；ω；`)
2位 話を聞かない（資料を見ない）
具体的な例を出しましょう。
とあるスクリプト（50行ぐらい）があり、おそらくそれには求めていた機能が入っていると情報展開されたとします。
「このスクリプトの説明書を作っておいて」と指示されてそのスクリプトの解析をして、全部のコードをマッピングして、図式化した資料を別資料にまとめました。で、資料を展開しました。
解析結果は「求めていた機能は入っていなかった」という結果でした。
まずは口頭で
「あのスクリプト、まだ機能追加されていませんでした。解析資料はこれです」
「いや、このスクリプトの中には求めていた機能が入っているって聞いているから」とまったく聞く耳を持たず、資料も見ず。
「いやいや、ないから！」と資料のほうにもどのコードがどの役割を果たしているのかを書いて、全部のコードを資料中に埋め込んでいるにもかかわらずその資料を見せても信じず。
コードを見せても信じず。
ではどのタイミングで信じた（というか認識したか）というと、本人がコードを見たとき。
そのタイミングで初めて
「なんだよこれ。機能入ってないじゃん。」
って認識しました。
自分で見たものしか信じないという価値観もありだとは思うけれども、個人的には資料にも書いたし、口頭でも説明しているし、資料の説明もしたし、コードも見せたのに「今更かよ！！」と突っ込みたくなりました。
あとは指示確認の時とかも「こういう風にすればいいんですか？」と確認すれば「同じことしか言っていないけど、こうしてほしいんだ」と抽象的な指示。ゴールは確かに同じだけど過程は違うからそこに対して意見をもらいたいのに・・・・
上司の方・・・・とりあえず話を聞いて(´；ω；`)
1位 否定から入る（責める）
何を言っても否定する人っていますよね。
これが一番困るというかぐったりする。一番なってはいけないと思う。
よく聞くのが以下。
- 上司が答えを持っていて、指示のもと調べて報告したら「こうじゃないんだよ」と否定するケース。
- 上司が調べてみたら新たな情報が出てきて「なに調べていたの？」と責めるケース。
上司としては教育の一環としてやっているつもりなんだろうけど、その教育の対処がちょっと足りないと思う。
例えば、答えを持っているのであればそれを先に伝えてそれを探させたうえで違う方法を探させるとか、その答えにたどり着くような具体的な指示を出すとか、どうやって調べたのかを確認したうえで方向性を修正してあげるとか。
そういうフォローがないといっこうに間違っていることにも気が付かないし、成長しないと思います。こういう上司ってけっこう多いように思います。
そこを自分のほうから「何が間違っていたんですか？」と確認すると「そんなこともわからないの？」という始末。話す気なくなりますよなー。
上司の方・・・・否定だけじゃなくて修正もしてあげて(´；ω；`)
まとめ
賛否両論あるとは思いますけど、自分として「こういう人になってはいけない」と感じた上司のふるまいを書いてみました。
人が10人いたら10通りの考え方があると思うので、正解かどうかっていうのはわからないんですよね。
自分は上司がいる場合もあるし、部下がいる場合もあるので上司しかいない環境ではありません。
新入社員の方とか1～2年目は上司しかいないケースが多いので、また違った視点で困る問題があるのだなと以下の記事を見て思いました。
この記事も自分のふるまいを見直すのに非常に参考になりました。
もし理不尽な体験を強いられたとしてもぐったりするだけではなくそれを反面教師として
「こういう風にするとモチベーションが下がるのか」
と新しい発見があったぐらいの気持ちで受け止めて、今後の自分の対応の糧にしていければいいかなと思います。
参考になれば幸いです。
次回は、上司として気にしていることを書いてみようかなー。
