一年後、エンジニアはどのような姿になっていたいか

on

5月19日のまなめさんの感想にちょっと応えようかと思い、アンサーソングならぬアンサーブログを書いてみようと思う。
＃迷惑なヤツだ。

★エンジニアの育成は誰の責任なのか
http://d.hatena.ne.jp/fumisan/20120519#1337388599
（情報元：室長のひとりごち）
マネージャの仕事は育成担当をアサインすることと、リスク管理することと、正しく育成されているかの監視、アウトプットの証跡確認くらいじゃないのかなーと思った。

マネージャ視点でエンジニアの育成をPDCAで捉えると、そのとおりだと思う。
感想なので、頭の中でほかに浮かんでいることすべてを書いていないと思われるが、あえてそれを勝手に“想像して”言語化してみよう。

マネージャの育成に関するミッション
エンジニアの育成は、組織の事業のヒューマンリソースとして組み込むことから、リソースの塊としてどう配分するか、マネージメントが意思を持って采配することになる。エンジニアの所属長は、トップダウン的に落とされる事業目標を達成すべくエンジニアを育成しなくてはならないから、所属長自身もエンジニアの育成に対して、事業目標を織り込んだ育成指針を示す。
その育成方針を具体的な個々のエンジニアの育成のPDCAとして展開するとまなめさんが書かれた具体的なHow toになる。
マネージャは組織の事業計画にあわせたエンジニアの育成と個々のエンジニアのタレントを考慮した育成の2つを意識してオペレーションするミッションを担う。


マネージャの指針とエンジニアのwill
育成計画で一つ気をつけたいことは、所属長のマネージャが示したい指針と育ちたいエンジニアのwillが一致すれば幸せなのだが、エンジニアのwillが強く且つベクトルが違う場合、激しくコンフリクトを起こす。ただ、このケースは全体のエンジニアの母数から見れば少ないケースで、強いwillを持っていても、実際に示される指針の解釈を自分のwillに“大人の解釈”をすることでコンフリクトを回避するエンジニアも少なくない。このようなエンジニアは柔軟性を持って自己実現を図るので放置しても勝手に育つタイプだ。ただし、定期的にポーリングをして成長を確認することは必要だ。
一方、先の激しくコンフリクトを起こし、示された指針を自己解釈できない場合、最悪のケースは離職する可能性が生じる。これは、事業のリソースの確保の観点からは、戦力となるエンジニアの場合は、好ましくない。


一年後、エンジニアはどのような姿になっていたいか
さらにもう一つ育成計画時に気をつけたいことは、scrum的に言えば育成計画のDoneの定義が必要だ。育成計画といってもOFFJTであれば組織の予算を使って研修を受けさせることになるから、成果を求める。その受講した研修でどのコンピテンシを伸張させるのかをエンジニア一人ひとりに意識させる。マネージャは、育成はOFFJTばかりではなく、OJTや自己技術の伸張を図る活動も俯瞰的に見て含めておくことを忘れてはならない。エンジニアのコンピテンシは、OJTやOFFJTだけで涵養できるものではないからだ。
それぞれのエンジニア一人ひとりに育成のエリア毎の計画を立てたとき、1年後に自分がどのような姿になっていたいかを具体的に意識させなければならない。計画時に具体的にイメージさせることで、例えば、ブロックのリーダを“自分の力で”やり遂げるとか、先輩エンジニアに支援をもらいながら、担当機能を実装する、など目標達成のイメージをマネージャとエンジニアが共に目標を達成したいというモチベーションを醸成するし、PDCAのCheckでエンジニアが達成したと申告したときの評価の指標値となるからだ。




  • 道具室(アプリとか)
  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します）

画像は、amazonでのお買いもの。テキストリンクは、itunesでのお買いもの。

  • 視聴覚室
  • 調達室