エンジニアが突然、配置転換されたら
エンジニアを仕事にアサイメントするのはプロジェクトが立ち上がったからとか、そんなポジティブな話ばかりではない。後ろ向きなアサイメントと言えば、エンジニアのみなさんもご自身が一度くらいは経験しているかもしれないのはデスマになったプロジェクトへの増員を思い浮かべるかもしれない。
デスマプロジェクトへのアサイメントはデスマプロジェクトにアサイメントされているメンバから噂となったり、管理部門から収益の悪化などの対策などからも薄々とわかる場合もある。
プロジェクトチーム内部でのトラブルが原因であれば内部のメンバは目の前で起きているトラブルに気づくし、居合わせなかったとしてもこんなことがあったと情報共有されるので、やはり気づく機会がある。
エンジニアが知らないところで起きている理由で、プロジェクトを外されたり、部門の配置転換をされたりすることもある。こうしたケースは、本人が何かをやらかしたケースでなければ表沙汰にされないので当事者のエンジニア自身は青天の霹靂での異動となる。
当事者のエンジニアを移動せざるを得ないケースは外部からのクレーム対応だろう。クレームもいくつかパターンがあり、本当に誰にも知られない(トラブルを起こせば誰かしらは知ることになり、前述のパターンのどれかに落ち着く)ケースは、顧客からのクレームか自組織側からのクレームである。どちらのクレームも著しく能力が低いか、他のメンバの進捗を阻害している何かしらの事象による。
顧客からのクレームでメンバを変えることは色々と問題があるが、そうしたときには自組織内でも同等かそれ以上の問題視をしていることが下地にあるので背を押させる形で入れ替えを行っているだけに過ぎない。
通常、謙遜、尊敬、信頼の関係を作れていれば、クレームまでは行かない(周りが助けてくれる)はずだが、クレームなり、自組織の自主的な要員交代は3つのうちの1つが欠けていたため起きたとみて良い。
なお、上述では計画的な配置転換は別としている。
職場の問題地図 ~「で、どこから変える?」残業だらけ・休めない働き方
- 作者: 沢渡あまね,白井匠
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る