ダメ評価をされていた若手エンジニアを引き取った話

結果的には、件の若手エンジニアは自分の進む道を自分で見つけ、旅立った。送り出したマネージャの立場でいえば、もう少し技術を身につけてからと思わなくもないが、今のプロジェクトだと制約があるので若手エンジニアの判断はよかったと思っている。

ある年の年度始めに増員のリクエストを出したらスキルの合うエンジニアはいないと言う。需要の旺盛な時期で(今もそうだが)気長に待つしかないな、と腹は括っていた。プロジェクトの特性上、プロジェクトで知り得た情報を漏らすことはできないし、プロジェクトのステークホルダになる関係者の役職レベルもあり、採用する要員の席は制限された(と言うよりはこちらから条件として出していた)。

こちらからは顔を思い出す要員を適当にあげてリクエストするも、ことごとく却下される。そんなことはわかっていても要求はしなければ要求にならない。

少し経って、若手エンジニアがいると吉報が入った。

『若手エンジニアがいるんだけど、ちょっと…』

とネガティブな文章が続いていた。

これまで何十人もの部下を持ってきた経験から言えば、部下(か年下のエンジニア)をネガティブに評価している時は、その評価自体に注意が必要だと思っている。

何かと言えば、マネージャがエンジニアの特性を把握できておらず、フィットする仕事にアサイメントできていないケースがまま見られることだ。目の前にやらないといけない(とそのマネージャは思っている)案件に適用する技術、必要とする技術レベルにフットしないエンジニアを当てはめ、フォローもせずにできないやつだと悪評をつける。

そういったケースを知っていると、お前の評価はどこまでフォローした上での評価なのかと疑ってかかる。実際、エンジニアが『できない』エンジニアと言うケースもあるだろうし、エンジニアに向いていないケースもある。であれば、エンジニアの職種から別の職種に移すことを考えればいいはずである。リソースを使えないと言うマネージャはマネージャが使えないのである。

条件は、プロジェクトの特性の一部でも適合する技術を持っていることと所属の席の制限である。後者はクリアするが前者がかなり物足らない。

デリバリのプロジェクトでメンバが多ければチームとしてのスキルセットを満たすことを見切れれば引き取っただろう。

では当時の判断は。

そのダメ評価の若手エンジニアを引き取ることにした。かなり、忠告めいたことを言われた。アイツはどうのこうのという。親切心で情報提供をしているつもりなのだろうが、こちらとしてはそのダメ評価のエンジニアを『1から育てる』つもりで引き取っているのである。

少なくとも自分の部下でいる限り、放置したり、無下に扱うことはしない。リソースとして活かすのが仕事なのだから。

実際、仕事をしてみると若手エンジニアから中堅に差し掛かる経験年数には見合わない技術レベル(低い方という意味)であることを実感した。

多分、これまでアルバイトのように、細切れに、都合よく、急かして、やっつけで仕事をしてきたのだろう。そう思わないと理解しづらい技術レベルであった。

どうしたか。

プロジェクトの仕事は自分が付きっ切りでサポートすることにした。この他に、基礎的な技術スキルを身に着けるためにプロ級のエンジニアに指示して、マンツーマンのハンズオン的な技術習得をさせた。中堅のプロマネ資格をもつエンジニアにプロジェクトでの自分の作業管理の基礎を身につけられるように時間を確保させた。

少しずつ、できる仕事が増えてくると自信を持つようになった。やることを自分から説明できるようになってきた。ゆっくりだが歩き始めたのである。

まあ、あと1年もすればそこそこのエンジニアとして基礎の基礎くらいはキャッチアップできただろう。

そう思っていた頃、若手エンジニア自身の事情で休みを取ることになり、最終的には去ることを本人の希望として決めた、と連絡があった。

その連絡を受けたとき、若手エンジニア自身の事情と付き合っていける新しい道を探せたのだな、と思った。

一緒に働いた年月は新しい道を探すためのサポートになっていたのだったとしたら、マネージャとしての役割を果たせたのかもしれない。

それは若手エンジニアが選んだ新しい道での活躍が証明してくれるだろう。

 

 

 

 

エンジニアになりたい君へ 理工系学生のためのキャリア形成ガイドブック

エンジニアになりたい君へ 理工系学生のためのキャリア形成ガイドブック

 
SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル