新人エンジニアを抱き合わせで連れてこられて大丈夫か
プロジェクトの立ち上げでは、その大小に関わらずプロジェクトとしてのスキルセットを持ち合わせていないとプロジェクトは必ず行き詰まる。ろくに考えもせず、モグラ叩きの好きなマネージャや間抜けなプロマネが人数だけいれば、後はメンバでなんとかしてくれるだろうとやるから確実にやれるウォーターフォールのプロジェクトでもお祭り騒ぎになるのである。
そして、なんとかしてくれと泣き付かれる。個人的にこんな采配をヨシと意思決定するマネージャやプロマネはそのロールから引き摺り降ろしたい。やるなら保険（リスク対策）まで掛けた上でon goingなプロジェクトにしないとそれを丸投げされたエンジニアはたまったものではない。
そうしたプロジェクトをレスキューしたとき、バサバサと人を斬った、じゃない、ご退場願った。切られた協力会社のマネージャや営業は売り上げを確保したいらしく、その代替としていい感じのエンジニア＋新人エンジニアを連れてきた。これで手を打ってほしいという。
貴社の売りなんて自分には全く関心を持っていないのでそんな事情は考慮しない。こっちとしては、これまでいくらドブに捨てたかわかっているのか、と問いたいところだ。同じようにドブに捨てるくらいなら人的リソースを補給せず、自分の懐に納めておきたいくらいである。
総合的判断を行い、できそうなエンジニア＋新人エンジニアを採用することとした。このとき、どのように判断したか。ここはほとんど明らかにされないものであるから、こうした機会を通じて以下に記すので参考にして欲しい。
抱き合わせでも採用した理由。
- コストの観点
予算的には全く問題がない。元々の見積もり工数の山積みと採用時の人員では余裕がある状態であった。 - 作業工数の観点
色々と諸事情のあるプロジェクトを常識の通じるプロジェクトに変える見通しがつき始めたころ。見通しがつき始めた頃、という点がポイント。まだ、実質のリソースは不足しているが、この採用でできそうなエンジニアが期待に応えてくれると見通しの確度が上がる。新人エンジニアについては、作業のオペレータとして手順書通りにやってくれれば、それはそれで進捗を伴う。そうした期待を持てた。 - 品質の観点
バサバサと斬り、新チーム体制に変え、メンバの顔を同じ方向に向かせ、一つひとつのタスクの完了条件（doneの基準）を検査し始めると途端に品質を確保できるようになる（なにせ、基準を満たしていなければ受け入れないので必死にやってくれる）。そうした途上であったから、同じルールでやってもらうので影響は受けない（受けたら斬ればいいと決めておく）。 - タイムの観点
無秩序なスケジュールを日々の生活、１週間の過ごし方、１ヶ月の過ごし方とそれぞれのサイクルを示すと、そのマイルストーンに合わせてくれる（さすが日本人気質である）。作業量とリソースとパフォーマンスを把握し、やれそうだと見極めておく。メンバにやって欲しいことを詰め込みし過ぎないように示せば自分たちで考える。大人であるし、ここまで立て直してくれているメンバに入れ替えでの採用の二人でやりきるように調整してくれる。 - リスクの識別
内部的なリスクは、入れ替えで採用するエンジニア二人である。どの作業を誰がするかはメンバに任せる。やりたいメンバがやってくれて、終われば良いのである。最初のタスクで出来不出来さえ見ておけばいい。後、新人エンジニアがTPOを弁え、指示どおりにやらなければならないところでは指示どおり（言葉どおりで、新人エンジニアが独自で解釈して勝手に指示されない作業をすることがない）にやってくれればそれで支払う費用の対価くらいにはなる。外部的には、自分が識別すればいい（もちろんメンバにヒヤリングを掛ける）し、そうしたリスク対策用にプロジェクトバッファを持っておくくらいにはなっていたからどうにかなると見極められる状態になっていた（これができないと即死である）。
これが自社の新人エンジニアであれば、育てるという観点が入るので話は全く変わってくる。最初からちゃんと育てることを意識してタスクを渡さないと将来困るのは自分たちなのである。ビジネスをキャリーしてもらう候補であるのだから。
