マルチスキルなエンジニアの育て方

on


誰でも人から言われてやるのはなかなか気が進まないものです。仕事でも。システムエンジニアなら初めて所属した部署での適用技術を手習いして、次第に技術を深めたり、広げたりしてステップアップしていくのですが、そうはいってもインフラエンジニアはインフラエンジニアである特定のエリアだけ、アプリケーションエンジニアならある業種の、のように広報性の幅がある程度決まってしまうものです。


ビジネスがある程度の巡航速度で進んでいるならそれでもいいわけですが、ビジネス自体に山谷が激しかったり、プロジェクトが安定しないときは、一つのエリアで、一つの業種でなんて贅沢は言えないものです。そういった背景があるので、マネージャからは、ひとり一人のエンジニアの顔や特性を見ながら、技術に長けていたり、新しい物好きなエンジニアを中心に新しいパッケージや開発言語を振って幅を広げようとするのです。


エンジニアと言っても人の子ので、その他大勢のプロジェクトに組み入れられたら、そのプロジェクトの限定されたロールをこなすことが第一目標になるからどうしても一兵卒な役割でしか動けなくなるのは仕方がないのですが、エンジニアの育成やビジネスの対応力ののりしろを広げておくにはどうしても実プロジェクト上でそうした狙いの経験をさせる機会を与えないといけないです。


人はその性質から頼られれば正直うれしいもので、そうした性質やその人の特性やプロジェクトとしての環境などを加味すると、エンジニアの幅を広げるような育成には大きすぎるプロジェクトでは少し期待する効果が得られにくいのではないかと感じています。


では、どうすればよいか。5名程度の少人数のプロジェクトをキックオフからクローズまで一貫してアサインすることです。キックオフからクローズまで、プロジェクトの全工程に関与するということは、変遷するフェーズをすべて経験するという上に、少人数であるからこその様々な役割を担わないとプロジェクトのチームとして成り立たない、という台所事情も半ば強制的に生じるので、「わたしはこのエリアしかできません。」なんて言ってられない状況に置くことができるのです。


それと、少人数だからこそ、責任が明確なロールを自らが主体者となってリードしなければならず、リーダーシップを伸ばすという機会も強制的に適用することができるのです。


それまでの個々のメンバの顔や経験をもとに対面で会話したところでは、

「この人はマルチで動けるかなー」


ってアサイメントを踏み込むことが出来なくても、様々な制約の中でフォローをする前提でアサイメントをしてみたら、

「あれ、こんな一面を持っていたんだ。なら、もっと早くこうしたロールを担わせればよかった。」


なんて思ったりしたこともあったです。当の本人に言わせれば口ではブツブツ言っていることもありますけれど、目は笑っていたりして、頼られたり、経験してこなかったエリアに明日を踏み出せたことに対して自信を持てていたりするようです。


こうしてみると、マルチスキルのエンジニアを育てないなら、やっぱり、密度の濃い経験が積める少人数のプロジェクトで、となるのは当然なのかもしれません。