【産経】激しい言動で部下を潰す「クラッシャー上司」から自らを守るすべはあるのか？
http://www.sankei.com/premium/news/160429/prm1604290015-n1.html
ないだろ。マジで。
俺の仕事は、まあシステムエンジニアなわけだけど。10年仕事やってりゃ1回ぐらい、クラッシャー上司に当っている。「犬も歩けば棒に当たる」レベルで。
結構、ありふれた上司だと思う。10年前ならば。
上記記事で紹介されているクラッシャー上司はものすごく典型的で、最近では結構レアだと思うのだけど。もっとソフトで人当たりのいいクラッシャー上司の方が果てしなく厄介である。この記事では問題視されていないようだが。
だいたい、このレベルのクラッシャー上司は恒常的に部下を潰すので、本人が有能でもだいたいそのさらに上の上司がクラッシャーぶりに気がつく。すると、下につける部下を、クラッシャー上司のお気に召す人にする事が多く、そしてクラッシャー上司の欠点は埋もれていく。つまり何の問題にもなっていない事が多い。
問題は、こんな典型的なクラッシャーじゃなく、人当たりの良いクラッシャーだ。
こいつらは、まず、パワハラ呼ばわりされる事をきちんと警戒していて人前では怒らない。どっかに呼び出してこんこんと諭すように説教をする。で、普通の仕事なら、部下に対しても基本的に温厚で、ちゃんとリソースの割り振りもできる。自他共に、彼が有能であると認められている。
これが、彼にとって不可能な作業量で仕事が降りてきた時に、状況が急変する。
俺が体験したケースだと、常駐先の仕事を円満に完了し、自社に戻ってきたら、自社内で稼働してたプロジェクト…仮にプロジェクトＧとしようか。がデスマーチになっていた。プロジェクトリーダーは、問題の「人当たりのいいクラッシャー上司」である。仮にＭとしよう。
プロジェクトＧのスケジュールを見ると、スケジュールが、土日込、1日1人10時間で線引されていた。期間は残り3ヶ月、参加人数10人という状態だった。勤怠も250時間を全員超えていた。話を聞けば、顧客から無理な仕様変更が入ってきた上で、納期を伸ばしてもらえなかったとの事であった。
俺は、正直無理だと思ったので、Ｇのメンバーと昼食を取る時に、大丈夫なのか確認してみたら、全員が無理なのはわかっているとの事だった。無理でも、とにかく限界までやったという言い訳ができる状況で、顧客には「頑張ったけど無理でした」という体裁にしたいとの話であった。
スケジュールが問題なく完璧に消化できれば、ギリギリ間に合う計算であった。そして、Ｍは諦めていなかった。
※ちなみに俺なら、全員土日出勤を禁止してスケジュールを引き直す。顧客には「できるだけ頑張ってます」と伝える。こうするともう絶対に無理なんだけど。完全に諦める俺と、絶対に諦めないＭで、顧客への報告内容と受け取る売上は同じ…という形になる。
そこに、絶望的な要望が、顧客から降りてきた。「単体テストの精度が低い。もっと精度を上げる為、こーゆーエビデンス資料を作り、単体テストを確実に実施している事を設計者は確認せよ」という話であった。
実は、このプロジェクト、単体テストフェーズを端折っていた。そうでないと不可能だからだ。しかし、単体テストフェーズは本当に実施しているのかと。疑問を持たれていた。そして、そのテストフェーズをやった証拠として、実行履歴であるエビデンスを作成し、提出せよというのである。
はっきり言って万単位のページ数になる資料で、そんなもの、提出しても顧客は確認しない。つまり無意味な作業をやれと言ってきたのだ。
これにはＭ以外全員がキレた。できるわけがないと。しかし、そのＭは「スケジュールはそのままで、なんとかできる方法を考えよう」と、なんと言われようとその結論に帰結する語りを繰り返した。そう。それはまるでワタミの渡邉美樹のような感じである。「無理という奴は嘘つきなんです。ぶっ倒れるまでやらせる。でも、多分ぶっ倒れない。ほら。無理という奴は9割嘘つきなんですよ」。これがＭ部長の持論なのかと、こんな奴だったのかと、その豹変っぷりに全員が愕然としたのであった。
結局、俺はそのプロジェクトにヘルプとして参加する事となった。
俺は、そのプロジェクトメンバーに事情を説明されて、Ｍに社内リソース不足を説明し、善処を求める人として、先頭に立っていた。
しかし、結局、Ｍはこわれたカセットテープのように、「なぜネガティブな想像しかできないの？もっとポジティブに考えてみようよ！」「なぜ、できると想像できないの？できるかもしれないじゃないか？」と繰り返し、まったく言葉が届かなかったのである。
このままでは、全員地獄を見る事が明らかだったので、俺は必死で頭をしぼり、単体テスト資料作成をほぼ自動化するプログラムを作成した。それで、完全に破綻していた部分をキャッチアップしつつ、俺がこのプロジェクトに参加する事と、夜勤組と昼勤組にメンバーを分けて、クリティカルパスに当たる作業を24時間とめないようにして、結局そのプロジェクトは最後まで破綻しなかった。
Ｍは、「どうすればいいか」の提案すらできなかった。マスターアップの時のＭ部長の台詞が、「な？できたやろ？」である。実はこの台詞は、俺はこの会社の上司達から何度か聞かされていたお決まりの台詞であった。
このプロジェクトで、優秀な人材（中堅だ）が２名、会社を去った。
そして、このプロジェクトを乗り切った事により、またＭ部長の株は社内であがり、そして、ウチの会社は他社よりも評価が上がるのである。
辞めていった人材に、人権はない。会社にとっては、単なる必要経費、なのであった。
クラッシャー上司か…。うまいこと言ったな。当然、俺らの世代では大人気だった小説＆アニメ、「クラッシャー・ジョウ」からとったものであろう。
歳がバレてしまうぜ？
パワハラで潰すような、わかりやすいジョウではなく、こんなわかりにくいジョウが潜んでいるのである。
実は、本当に問題なのはこっちのジョウだと思うんだがな。俺は。
人気ブログランキングへ ※ちょっとランキングが落ちてきました！応援よろしくお願いします！
クラッシャージョウ デザイナーズノート
http://www.sankei.com/premium/news/160429/prm1604290015-n1.html
ないだろ。マジで。
俺の仕事は、まあシステムエンジニアなわけだけど。10年仕事やってりゃ1回ぐらい、クラッシャー上司に当っている。「犬も歩けば棒に当たる」レベルで。
結構、ありふれた上司だと思う。10年前ならば。
上記記事で紹介されているクラッシャー上司はものすごく典型的で、最近では結構レアだと思うのだけど。もっとソフトで人当たりのいいクラッシャー上司の方が果てしなく厄介である。この記事では問題視されていないようだが。
だいたい、このレベルのクラッシャー上司は恒常的に部下を潰すので、本人が有能でもだいたいそのさらに上の上司がクラッシャーぶりに気がつく。すると、下につける部下を、クラッシャー上司のお気に召す人にする事が多く、そしてクラッシャー上司の欠点は埋もれていく。つまり何の問題にもなっていない事が多い。
問題は、こんな典型的なクラッシャーじゃなく、人当たりの良いクラッシャーだ。
こいつらは、まず、パワハラ呼ばわりされる事をきちんと警戒していて人前では怒らない。どっかに呼び出してこんこんと諭すように説教をする。で、普通の仕事なら、部下に対しても基本的に温厚で、ちゃんとリソースの割り振りもできる。自他共に、彼が有能であると認められている。
これが、彼にとって不可能な作業量で仕事が降りてきた時に、状況が急変する。
俺が体験したケースだと、常駐先の仕事を円満に完了し、自社に戻ってきたら、自社内で稼働してたプロジェクト…仮にプロジェクトＧとしようか。がデスマーチになっていた。プロジェクトリーダーは、問題の「人当たりのいいクラッシャー上司」である。仮にＭとしよう。
プロジェクトＧのスケジュールを見ると、スケジュールが、土日込、1日1人10時間で線引されていた。期間は残り3ヶ月、参加人数10人という状態だった。勤怠も250時間を全員超えていた。話を聞けば、顧客から無理な仕様変更が入ってきた上で、納期を伸ばしてもらえなかったとの事であった。
俺は、正直無理だと思ったので、Ｇのメンバーと昼食を取る時に、大丈夫なのか確認してみたら、全員が無理なのはわかっているとの事だった。無理でも、とにかく限界までやったという言い訳ができる状況で、顧客には「頑張ったけど無理でした」という体裁にしたいとの話であった。
スケジュールが問題なく完璧に消化できれば、ギリギリ間に合う計算であった。そして、Ｍは諦めていなかった。
※ちなみに俺なら、全員土日出勤を禁止してスケジュールを引き直す。顧客には「できるだけ頑張ってます」と伝える。こうするともう絶対に無理なんだけど。完全に諦める俺と、絶対に諦めないＭで、顧客への報告内容と受け取る売上は同じ…という形になる。
そこに、絶望的な要望が、顧客から降りてきた。「単体テストの精度が低い。もっと精度を上げる為、こーゆーエビデンス資料を作り、単体テストを確実に実施している事を設計者は確認せよ」という話であった。
実は、このプロジェクト、単体テストフェーズを端折っていた。そうでないと不可能だからだ。しかし、単体テストフェーズは本当に実施しているのかと。疑問を持たれていた。そして、そのテストフェーズをやった証拠として、実行履歴であるエビデンスを作成し、提出せよというのである。
はっきり言って万単位のページ数になる資料で、そんなもの、提出しても顧客は確認しない。つまり無意味な作業をやれと言ってきたのだ。
これにはＭ以外全員がキレた。できるわけがないと。しかし、そのＭは「スケジュールはそのままで、なんとかできる方法を考えよう」と、なんと言われようとその結論に帰結する語りを繰り返した。そう。それはまるでワタミの渡邉美樹のような感じである。「無理という奴は嘘つきなんです。ぶっ倒れるまでやらせる。でも、多分ぶっ倒れない。ほら。無理という奴は9割嘘つきなんですよ」。これがＭ部長の持論なのかと、こんな奴だったのかと、その豹変っぷりに全員が愕然としたのであった。
結局、俺はそのプロジェクトにヘルプとして参加する事となった。
俺は、そのプロジェクトメンバーに事情を説明されて、Ｍに社内リソース不足を説明し、善処を求める人として、先頭に立っていた。
しかし、結局、Ｍはこわれたカセットテープのように、「なぜネガティブな想像しかできないの？もっとポジティブに考えてみようよ！」「なぜ、できると想像できないの？できるかもしれないじゃないか？」と繰り返し、まったく言葉が届かなかったのである。
このままでは、全員地獄を見る事が明らかだったので、俺は必死で頭をしぼり、単体テスト資料作成をほぼ自動化するプログラムを作成した。それで、完全に破綻していた部分をキャッチアップしつつ、俺がこのプロジェクトに参加する事と、夜勤組と昼勤組にメンバーを分けて、クリティカルパスに当たる作業を24時間とめないようにして、結局そのプロジェクトは最後まで破綻しなかった。
Ｍは、「どうすればいいか」の提案すらできなかった。マスターアップの時のＭ部長の台詞が、「な？できたやろ？」である。実はこの台詞は、俺はこの会社の上司達から何度か聞かされていたお決まりの台詞であった。
このプロジェクトで、優秀な人材（中堅だ）が２名、会社を去った。
そして、このプロジェクトを乗り切った事により、またＭ部長の株は社内であがり、そして、ウチの会社は他社よりも評価が上がるのである。
辞めていった人材に、人権はない。会社にとっては、単なる必要経費、なのであった。
クラッシャー上司か…。うまいこと言ったな。当然、俺らの世代では大人気だった小説＆アニメ、「クラッシャー・ジョウ」からとったものであろう。
歳がバレてしまうぜ？
パワハラで潰すような、わかりやすいジョウではなく、こんなわかりにくいジョウが潜んでいるのである。
実は、本当に問題なのはこっちのジョウだと思うんだがな。俺は。
人気ブログランキングへ ※ちょっとランキングが落ちてきました！応援よろしくお願いします！
クラッシャージョウ デザイナーズノート
