エンジニアを育てるという発想をそろそろやめにしませんか。

on


昨日、いろいろ積もり積もっていたことをドバーっとツィートしたんですが、まぁ、アレです。中二病みたいのものです。中二病って言っても中年の、ですが。(涙。



このテーマはずっと今年の春からある筋からの宿題だったわけで、途中からズッポリと別案件にかかわっていたのである意味回避できていたんですけど、そうはいってもメンバの育成のサポートについてはかれこれ感じてきたものが経験と積み重なって、でも、「誰でも応用できるそんな手軽な解決方法はないよね。」いうところに帰結して、ときどき幽霊のようにソレを思い出してしまうのでやっぱり「うんうん……。」と思い描き切れていない自分の空想をどうにかしたいなぁ、と思っていたところに、燃料が投下されたわけです。


で、どばーっと中二病垂れ流ししてしまったというか。


エンジニアは育てられません
組織には中計とか年次の事業計画とかあって、それが実行組織に落ちてくるわけです。なので、事業計画に合わせて必要な事業でのスキルセットが変わったりしちゃうと必要なコンピテンシをもったエンジニアを要しなければならんのです。はい。それがマネージャの仕事なのでね。ご苦労様です。


どうするかというと、実情は、on goingな日々の事業をしてるのだから余裕がないのが普通で、「新規事業だ！」と事業予算と人的リソースがつかない限り、「できる範囲で……。」となるのはどこもおんなじでしょう。だって、日銭も稼がないといけないんだもの。


じゃあ、幸いにも空きのリソースがあるとしたらそのリソースを割り当ててやればいいじゃんとか思うかもしれないけれど、大概、そうした空きのリソースはフィットしないことになっているのはマーフィーの法則にそうものです。


で、結局、個人の育成プランになんとか事業計画で必要な目標のスキルセットを持つエンジニアを用意するためにメンバの育成プランを「あーでもない。こーでもない。」と悩みながらプランして、誘い水を掛けてエンジニアをその気にさせるんですが、どうもエンジニアの皆さん関心が違うことに向いていることが多い。


そりゃそうです。個々のエンジニアは個々の担当するエリアの中で楽しみを見つけているか、別のところで好き勝手に好みの技術と戯れているですから。そこに割り込もうと思っても、もともといるところから、こっちの都合の良いところに出てきてもらうだけでも大変なんです。


結果、育成のフォローをしても、期末の評価をしても、思うように育っていないわけです。それって、エンジニアは“自分の興味を軸に勝手に育っちゃう”っていうことでもあるんですね。だって、事業計画なんて世の中の動向に合わせたり先読みしてみたりするからコロコロ変わるものだし、それに付き合ってみてもいいことあったなんて経験を持てるエンジニアが少ないからなんだろうなぁって、思ったりもするんですよ。


育てられるのは概念やしくみのフレームワークだけ
「じゃあ、まったく育てられないの？」と聞かれれば、それもちょっと違って、ウォーターフォールのやり方とかPMBOMの考え方とかWBSを使う狙いとかそうしたプラクティスとしてまとまった概念やフレームワークは、座学でも頭に押し込むことができます。


というか、考え方しかプラクティスを形式知として頭に詰めることはできないんですよ。だって、それを使う使い方なんて、個々のエンジニアがどう理解して、どう腹に収めて、それをふるまうか、ってところによるものに依存しちゃうんだもの。


平たく言えば、知識は詰め込めるけど、それを使うのは別です、ってことです。そこのポイントを押さえないでは、ソフトウェアはいつまでたってもエンジニアリングの部分が出来上がらないと思うんですが、これは個人的な思い。


形式知として押し込む＝育てるということと、その育てられたアセットを使えるようになるのは別のスキルで、後者については「育てようにも個人の奥深くに属するところなので育てることはできませんよ。」って思うんです。はい。


そうしたことを、やっぱり経験値から知っていないといくら頭のいい人たちで育成プランを作っても、総花的で、万遍なく、なんとなくいいようなどうも何かたびりっとしなさそうなプランにしかならんのだと思うんです。


そんな役にも立つかわからない育成プランを作っても、そこで育つのは勝手に育っているエンジニアであって、そのエンジニアはそれがなくても勝手に育っているということで、掛けたコストはどこにいっちゃうんだろうなって。


そんなことにコストをかけるより、今今のエンジニアの関わるプロセスに大鉈を振るって、重複する手順とか手続きを取っ払う方にコストをかけて働きやすくすることで余計なムダをカットする方が効果が見えやすいし、そのカットすることで得られる時間の寄せ集めをサラミのように固めて育成時間に振り分けた方がいいです。


エンジニアの育成に一番効果的なのはマネージャの育成するという意思をアサイメントで表すこと
もう、これにつきます。仕事なんだから、さ。必要なスキルセットを持ったエンジニアが必要なら、事業計画が下りてきたときに、今のチームの個々のスキルセットとあるべき姿のスキルセットのギャップを推し量って、ギャップをどのメンバにどの育成テーマを与えて伸ばすかを考えることなんです。


それも必ず、一つのテーマがあれば複数のメンバに、メンバのレベルに沿って割り振ることを考えながら、例え、同じ業務を継続するにしても、必要なスキルの得方を刷り込んで育成プランとして織り込ませて、ジョブアサイメントするんですよ。


それをプランして、トレースして、修正して、の繰り返し。それで興味を持って取り組んでくれればオーケーだし、関心を示さなければ、何度も繰り返すし、見切れれば、別のテーマを割り振るしかないです。