“スペシャリストとゼネラリストの択一なんて迷う暇があったら、勉強してアウトプット出せ”
エンジニアをゼネラリストとスペシャリストのどちらを目指したらよいのか、二項対立論で賑わっているようですけど、それ、意味ないですね。大概、このようなネタはマスコミが順番に煽ってネタ作りをしているようなものでしょう。ファッションのサイクルのようなものだと想像すれば、まぁ、「大体あってる」のじゃないか、と。
とは言え、20代や30代のさまよえるエンジニア達にとっては切実な問題です。ワタシは20代後半でそれについて考えるキッカケを享受し、30代で大きく舵を切りました。その経緯は何度か思う都度、書いたのですが3行に約すと、
“スペシャルなエンジニアになるかプロジェクトマネージャどっちに進みたい？と問われた”
“スキルの自己診断した”
“腹を括った”
です。そのあと、プロジェクトマネージャの経験を積み、マネージャにキャリアを変更することになったのですが、当時、配属になった部署があまりにもワタシがイメージしていた組織とは外れた運営をしていたので、ワタシが思うような組織に内部から変えていくことになります。
いくつか組織を変えて行ったのですが、その中の一つがエンジニアの育成です。
組織としてのエンジニアの育成
既に存在する組織に中途参戦するわけですから、ワタシより先にその事業で活躍しているエンジニアが何人もいます。そして、定期採用される新人も配属されます。この事実は2つのことを物語っています。
- 経験を持つエンジニアの育成
- 新人のエンジニアの育成
組織は、中期計画や年度の事業目標をもとに様々な目標を掲げ、その中で人的リソースについても言及します。事業目標は、下位組織へ順次展開し、個々のエンジニアの配置などに深く関わってきます。組織が存在する理由は事業継続にあるので、組織の資源を使用して事業目標を達成し、組織の存続を図らねばなりません。よって、振ってくる組織目標を達成するためにも、最大の資源であるエンジニアの育成を蔑ろにすることはできませんから、現場に近いマネージャはエンジニアの育成を強く意識するものです。
その中で、マネージャはある悩みに板挟みになります。一つは事業目標から要求されるスキルを持つエンジニアの“早期”育成です。もう一つは、個々のエンジニアのタレントです。その2つが一致していれば、悩みはありませんが、まぁ、メンバ全員を見渡したとき、一致しているなんてありえないです。それこそ、ダイバシティであり、多様性なのではないか、ということになりますが、事業目標の前ではそれは棚上げされるものです。
板挟みになる現実を逃避するマネージャもいるだろうし、実際、他組織において、育成面においては何もしないで(メンター的に)メンバから愚痴を聞かされることもしばしばあるものです。個人的に、それは「ネグレストなんじゃね？」と思ったりしますが職権の範囲外なので踏み込むことができません。
話を元に戻して、“経験を持つエンジニアの育成”と“新人のエンジニアの育成”を事業目標から“外れないように”どのように育成するか。ヒントは、変わるモノと変わらないモノがあるということです。
変わるモノ
＃モノと表現するのは言葉のあやなのでつっ込まないように。
変わるモノとは、事業目標とエンジニアのスキルです。組織が継続するために成長を計画するとき、その組織だけで物事はおきません。世の中全体として変わっていきます。その組織はこうなりたい、と思って計画を立て、実行しても、それより先に手を打つ競合がいるかもしれないし、世の中全体として不況に落ちるかもしれません。
エンジニアも日々成長していますし、マネージャとしてそう願いたいものです。願うばかりではなくて、成長しないなら給与をあげる理由がないと、逆にキッパリと申し伝えます。例え、デスマのプロジェクトにアサインされたからと言って、新技術をやったエンジニアより成長しないことはなく、逆に新しい技術をちょっと使ったから、評価してほしいと言われても、それは今まで持っていたスキルを適用しただけなら、なんらプラスの要素にはなりません。デスマにしても、新技術にしてもそれはスキルをあげるための経験をつむ手段であるからです。
そんなこともあって、変わるモノはエンジニアを成長させるための手段としか見做していません。
変わらないモノ
変わらないモノとは、個々のエンジニアです。その人がその組織にいる間は、一人のエンジニアと言う資源です。それも、マネジメントの裁量で決められるgivenの資源です。プロジェクトマネージャもマネージャも、どちらも多少の意向は働くけれど、実質、配下で動かすリソースは“given”であることを強く認識しておく必要があります。「使えないからいらない」と言うものではありません。“given”として与えられた以上、それぞれのゴールに向かって資源の有効活用をしなければなりませんし、それが職責の一つなのですから。
その観点に立つと、変わらないモノであるエンジニアを有効活用するために必要なことは、個々のエンジニアを知ることです。過去の経験、今の仕事の仕方、日常の振る舞い、将来の希望、など。
ワタシがその組織に配属されたとき、最初にしたことは一人ひとりのスキルを本人と周りからの客観的な目線でのインタビューでした。インタビューをして、保有スキルを一覧表にまとめ、そして、それをチームに公開したのです。当時のチームの中の技術リーダは誰か、プロジェクトマネージャは誰か、プロジェクトを構成したらメンバはどのポジションになれるか、などを一目でわかるように。
これはチームの既成観念を壊したようです。今まで、隣に座っている同僚の技量を知る由もなかったからです。これを作った目的は、誰が何をできるかを知っていれば、自分が困ったときに助けてもらえる人をラウンドロビンして聞きまわる必要がない、ためです。
＃で、これは、表向きの理由。
裏の理由があって、それは、個々のエンジニアのスキルを早期に把握しないとビジネスを組み立てるときに困らないようにするためです。人的リソースが要ですからそれを知らず、いったいどのようにして戦うのか、ということです。
変わるモノは、成長のための手段と言いました。変わらないモノは、エンジニアとも言いました。ワタシは、その変わらないモノであるエンジニアの本質的な育成にフォーカスしてチームの一人ひとりのエンジニアに自己伸長するように要求し続けています。
個人としてのエンジニアリングスキルの育成
“経験を持つエンジニアの育成”と“新人のエンジニアの育成”をエンジニアの立場からどのように捉え、行動したらよいか。実は、この“経験を持つエンジニア”も“新人のエンジニア”もどちらも同じ視点で成長を計ればよいのです。
ひとつは、社会人として必要なベーシックスキル。たとえば、文章力、対話力、問題解決力などです。もう一つは、技術スキル。インフラエンジニアなら、OSのプラットフォームからミドルウェアや運用設計のスキルなど。アプリケーションエンジニアなら、フレームワーク、業務設計力など。どちらにしても技術力として共通的に求めるのは、プログラミングとアルゴリズム。インフラエンジニアだって、運用ツールを作る機会があるものです。テストだって、スクリプトをかませば楽になります。いつ、アプリ基盤に移るかもしれません。だから、プログラミングもアルゴリズムも必要なのです。
エンジニア一人ひとりがいるポジションの正確な位置を計り、次のステップを踏み出す。踏み出すためには、社会人として必要なベーシックスキルと技術スキルそれぞれで目標を立て、変わっていく事業目標を踏み台にスキルを伸長させるわけです。
“経験を持つエンジニアの育成”と“新人のエンジニアの育成”は同じ視点でよいと言ったわけはそこにあります。違いを挙げれば、社会人として必要なスキルと技術スキルの目指すレベルと配分が違うくらいです。
で、スペシャリスト？ゼネラリスト？
エンジニアリングの世界に身を置いているなら、スペシャリストでしょう。ゼネラリストと称されていても、実は、その中身はある特定の技術領域でのスペシャリストを経て今の位置にいるわけです。出身は必ずあり、ゼネラリストと言われても実は、ということです。
ワタシが選択しなかったのは技術であって、プロジェクトマネジメントの領域のスペシャリスト、−いや、PMPをもっているのでプロフェッショナルですが−、なのです。そこがお里です。で、マネージャになるなら必要な会計やコーチング、コンサルティングなど基礎力をそれこそ自己研鑚した結果、もしかするとゼネラリストになっているのかもしれません。
結局、ワタシ自身どちらかだか、判別しないし、する必要性がありません。さまよえるエンジニアがこれを読んだとしたら、言いたいことは、
“継続的自己伸長こそ明日の自分を支えるもの”
であって、
“スペシャリストとゼネラリストの択一なんて迷う暇があったら、勉強してアウトプット出せ”
、です。
