LoginSignup
115
81

More than 5 years have passed since last update.

上司の起爆スイッチを押さない技術

Last updated at Posted at 2018-11-29

これはエンジニアがコミュニケーションを取るにあたってしてはいけないことへのアンサー記事です。

大前提として

パワハラ、モラハラはダメです。
そして言っている内容が正しくても言い方だけでハラスメントになり得ます。

起爆スイッチとは

上司や指導役は、自分のタスクも抱えている中で、あなたを指導し、あなたの力を借りながらPJを遂行しなければならないのです。

元記事を読んでいて、確かにこう言われたら、コメントのようにお説教のひとつもしてしまうなと感じるところがありました。(そしてそうやって上司も作業時間が指導に圧迫されていく不幸)
なので、上司がそう言いたくなる状況や背景にも考えを巡らし、上司の起爆スイッチを押さないように工夫して、みんなもっと幸せになってほしいと思います。

Re:その1:言葉の最初に必ず「でも〜」 【でもでも上司】

気持ちは分かります。というか私は新人時代「仕様を考えるのはアーキテクトの仕事だ。お前が口を出すには10年早い」と上司に怒られました。今は仕様を考え、共通モジュールを設計する立場です。

上司のやり方に明確な問題やムダがありますか?
逆にあなたの提案した方法は確実にうまくいき、時間も掛からない方法ですか?

上司は前にうまくいった安全確実な方法で進めて、不要なリスクをなくしたいのです。そこを汲んでください。
あなたのやり方は将来あなたが主導するPJでやりましょう。
あなたが「どうすればいい?」と聞かれる日は必ず来ます。(ユーザーへの提案とか)

できたら、第3者として意見を聞ける、年次の近い先輩がいるといいですね。
「それは君が間違っているよ」とか「君の言う通りだね」とか。

Re:その2;人の言葉を遮ること【遮断怪獣サエギラー】

確かにひどいですが、上司は次のMTGまでの20分でこの資料を作り終えないといけなかったりするので、質問に対してだけ答えてほしいのです。
説明も結論だけ一言で言ってほしいのです。(これは私自身がまだうまくできていませんが)

ただし、懸念事項がある場合はちゃんと言いましょう。
じゃないと後で「なんで言わなかった!」とまた怒られることになります。
上司は判断することと、ユーザーに説明することが仕事ですが、それができなくなるからです。

あなた「ただしそのやり方でできない例外もあります」
上司「そんなに頻繁にないなら、その時に対応すればいいんじゃないかな」

または

あなた 「ただしそのやり方でできない例外もあります」
上司 「え、例外もあるのか。それはユーザーに説明しておく必要があるね。
    課題表に書いておいてくれるかい?」

その3:言った言葉に対してすぐに「ちゃうちゃう」 【チャウチャウ同期】
これは上司のスイッチではなさそうなので割愛。

Re:その4:「〜もできないの?」【単純にモラハラ発言上司】

「そんなこともできないの?」をやらなかったとしたら、コメントのように長いお説教を始めてしまうスイッチを押しています。(そして上司も作業時間がなくなって不幸)

「調べながらやります」この一言を言わなければいいのではないでしょうか?(相手を不安にさせない技術

Re:その5:「自分で考えてやって」→やったら「何やってんだ!」【手のひら返し上司】

全部できあがってから見せていませんか?
全部掛かる時間の1/4か1/3くらいで、ラフスケッチの段階で確認をとることで、スイッチを回避できると思います。

あなた「こういう風にしようと思いますが、それであっていますか?」
上司「いやそうじゃなくて、こういうやり方でやってほしい。」

間違った方向に進んでいることは最初の1~2歩では分かりませんが、最後まで行かないとズレていることに気づかないということはないはず。
途中で確認して軌道修正することで、時間の無駄を減らすことができます。

無駄になった時間が1時間ならまだいいですが、それが1日、1週間だったら悲惨です。(上司の深夜残業、休日出勤確定…)

あと掛ける時間も大事です。あなたは4時間掛かると思っていても、上司はクオリティを犠牲にして1時間で終わらしてほしいかもしれない。

相手の立場を汲む技術

この記事を書いた理由は、コミュニケーションだけではなりません。
「相手の立場を考えるスキル」を高めることは、PJの遂行に必要だと思うからです。

  • 要件定義ではユーザー担当者は、こちらの提案で問題ないということだったが、受入テストで現場ユーザーから「こんな仕組みじゃ業務が回らない」とクレームが出てリリース延期。
  • 別システムのベンダーX社とI/F仕様について合意していたが、こちら側のデータを参照できるI/Fを作らなかったせいで、X社の負担が大きく、システム的にもムダになっていた。
  • 設計書だけでなく、サンプルデータを提供することで、結合テストでの問題発覚、手戻りを防ぐことができた。

こういう事例をいくつも見聞きしてきましたが、相手の立場を考えていれば、もっとうまくできた、問題を回避できたというケースが多いのではないかと私は考えています。(1つめはユーザー業務の理解も必要ですが)

「2025年の崖」

今後、IT人材の不足はますます深刻になり、2015年に17万人不足していたのが、2025年には43万人不足に拡大するそうです。
SIerは今どこも人材不足で、スキルがあるエンジニアにPJ業務とメンバー教育を両方押しつけられていますが、その状況は今後ますます深刻になります。
上司だけでなくメンバーも、技術スキルとともにヒューマンスキルも高め、お互いに支え合っていかないと、幸せなエンジニアライフなんて夢のまた夢、そう思います。

謝辞

@hiroking815さんが、「パワハラ上司が悪いのは当たり前」で終わらせることなく、元記事を書いてくれなければ、この記事を書くきっかけも生まれませんでした。
ありがとうございます。アウトプット大事。

115
81
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
115
81