エグゼクティブが期待する人材育成と現状とそれにどうこたえるかという宿題をどうやって解決するなのはー

朝一で偉い方にお呼ばれして、雑談というか仕事振られたというか、それのボヤキというか、宿題をもらったので頭の中の方向付けといういか。とりあえず、文字でも画でも見える形にモヤモヤを形にしておかないと何も進まないのでねぇ。

エグゼクティブの期待
組織は存続し続けなければならないんです。その組織の長たるエグゼクティブはそのための方向を示して、業務遂行を指示するんです。株式会社なら従業員と株主への還元をしなければならないから拡大し続けるか利益率を上げていくほかその原資は得られないですね。だから、エグゼクティブはそれを数字で示す。昨対で10%成長させよう、とか業界の成長率＋3%とか。ちなみに、業界の成長率以下の成長しか見込まれないならヤバイですね。自社比では、一見成長している風ですが業界のパイの中では実は減っているんですね。

組織の成長のため、SIerならプロジェクトを増やす、プロジェクトの規模をマキシマイズする、利益率を上げる、固定費を下げる、のどれかを選択する必要があるかと。人は退職や入社で更新するので、それを支える市場の大きなポーションの人材を少しでも高い対価で買ってもらえる価値のある人材を用意できるか、そこにかかっていると。

組織の中で人材を育てる手立ては、いつも書いているようにOJTとOFFJTで、OFFJTも組織内教育と社外教育、そして自己研鑚に分類される。その中で組織がかかわる教育は、
人事部門が担う教育と技術育成を担う部門が行う教育の二つに大別されるでしょう。この他に、組織内のコミュニティ活動があったりするものです。

エグゼクティブなら、固定的に行われる人事部門や技術育成部門が何をやってどの程度のパフォーマンスか大体わかり切っているでしょう。だから、他の新しい何かに人材育成での成果のウルトラCを期待してしまうのではないか。

もしかすると、固定化され過ぎて、でも変えることはその影響が大きいし、変化の結果が期待値以下の場合の保険のためにも現行の教育手段は残しつつ、恰も事業企画のように第三の道であるコミュニティやタスクフォースのようなチームに期待するのかもしれない。

マネージャの不作為
ハッキリ言って、人材育成のミッションは部下を持つマネージャが育成対象となるエンジニアとシェアしていると思っている。人が、エンジニアが育つかどうかは二人の責任でしか他ならない。

さまざまな制約がある中で、プロジェクトへアサインするのは誰だって同じであるのだから、それを、組織が必要とする人材を意識して育成しないのは不作為に他ならないと思っている。「忙しい、人材育成の目標に合っていない」なんていうのは言い訳でしかない。それ以上以下でもない。忙しいなら何かを削ってでもやらないといけない。それでも育てるマネージャの仕事だし、まなび育つことがエンジニアのミッションなのであるから。

同じように組織の方針、目標とアサインするプロジェクトの役割が一致していないなんて、そこまでしか思考しないのは馬鹿げている。組織の方針も目標もそれに沿った個人の育成目標も“人が作ったコンテキスト”に他ならない。ならば、一致するようにすればいいだけだ。何もエンジニア一人の育成目標は一つだけではないはずだ。優先順位があったとしても、制約の中で業務をすることを当然として、それに柔軟に対応するために優先順位を付けているのだから、そう対応すればいいのだ。

合わないのが技術であれば、基礎スキルを持ち出せばいいし、基礎スキルを重点的に育成したいのに仕事がマッチしないなら、技術を持ち出せばいい。つまり、アサインする方もされる方もそれぞれエンジニアの育成が組織をのばすことであることを本当に意識しているならお互いにエンジニアの育成の目標を作り出すことが出来るのである。

だから、それをできない理由を作ってやらないのは不作為だというんです。

エンジニアの怠慢
いつも言っていることだけど。

去年と同じことをやっていたら給与下がるけど。
だって、あなたより給与の安い若手にその仕事を振れるんだから。
そうできるために若手を育てているんだよ。
あなたは今年何をするんだい？人に言われた仕事しかしないんなら、あなたじゃなくて派遣でもオフショアでもいいんだけど。

チャレンジしない選択も選べるけれど。それで何がエンジニアとして喜びなのはー。

今年は、一人で詳細設計を出来るようになろう。
アルゴリズムの本を買って、運用スクリプトを書こう。
正規表現はとても便利だよ。
今年は、もう、サブリーダに挑戦しようよ。
もう、サブリーダは3回やってきて自信もついだだろう。なら、今年は小さくてもプロジェクトマネージャをやってみよう。

仕事も終わらせないで外に行けると思うなのはー。やることはやる。チームで仕事しているならちゃんとやる。それがチームで信頼関係を作る一つだから。

仕事が10あったら、8で終わらせる工夫をして欲しい。
その2で外部講習に行ってきてもいいよ。
セミナーでもいい。
仕事に繋がると説明してくれ。ワタシを騙せばいい。
騙されたら業務として認めるから。
認めたらそれをスケジューラに入れてブロックしなさい。実際に行けるかどうかは、プロジェクトチームでの自分の役割を果たせば良い。
間違っても、それに行くから予定が遅れるようになることはダメだよ。前倒しでね。
ちゃんと、コミュニケーションをとって、自分でスケジュールの穴を作れるように。
このくらいできないと、夏休みずらして取るのさえ難しくなっちゃうよ。

エグゼクティブの期待は実践知の涵養か
ツラツラかいたら、全然まとまらなかった。エグゼクティブの期待と現状の問題点を並べただけだ。ううん。さてどうしよう。

エンジニアを育成するには、形式知と実践知が必要なんだ。知識として頭に詰め込んだり、その情報のリンクを知としてブクマするということ。何で形式知が必要かというと最低レベルを一律に、狙う通りの所に持っていくことが出来るから。言い換えれば、エンジニアの知識レベルのボトムラインを揃えるということです。最低限、知識として知っているか自分で調べらる力を持っている。だから、自立して、エンジニアが自分の足で立ち、振る舞えるということを保証できるから。

でも、それだけでは、ビジネスを担うエンジニアにはなれない。そこには、実践できる実践知が必要なのだ。ここの育成はとても難しい。対象となるエンジニアのマインドセットの問題、マインドセットがあっても向き不向きの問題、いったいどこまでどのくらいを実践知のインプットとしてそろえるか供給する側の問題。そう言った様々な制約があるだろう。それはわかっているのだけれど。

エンジニアに必要なスキルは、フレームワークの形式知とそれだけでは実践できないから実践で使えるツールが必要でそのツールを揃えられる力、言い換えればテラーリングする力が必要なんだと思う。そこに至る仕組みを期待されているのだろう。その“まなび”は勘と経験と度胸ではなく科学的でとってもエンジニアリングなのである。