ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

エンジニアのキャリアパスに思うところ

みなさんこんにちは。@ryuzeeです。

世の中ではエンジニアが35歳すぎたらどうする?といった話が最近話題になっていますが、ちょっとエンジニアのキャリアパスについて考えてみました。

なんで35歳が転機だと言われているのか

以下は従来の会社にありがちなキャリアパスの構造です。 最初はアソシエイト(見習い)エンジニアとしてキャリアをスタートして、その後エンジニアとして自分で仕事を進められるようになります。 そしてエンジニアとして優秀で、昇進するという場合に、エンジニア職をやめて管理職にロールチェンジするしかないというものです。 35歳くらいがそのタイミングだ、ということですね。

レベルエンジニア系(個人型)管理職系
5 ディレクター
4 シニアマネージャー
3(シニアエンジニア)マネージャー
2エンジニア 
1アソシエイトエンジニア 

ここでのよくある問題点としては以下のようなものが挙げられます。

  • 組織の制度設計的に、ロールチェンジしないと給与があがらない仕組みになっていることが多い(エンジニアとして活動してもらえる給与の上限が低い)
  • 生活スタイルや家族観については多様な考え方があるとはいえ、一般的には35歳〜50歳くらいまでの間はお金がかかりやすい。そして途中で生活のために今までやっていたことを望むかどうかに関係なく捨てないといけなくなることがある(踏み絵を踏まされる)
  • 優秀なエンジニアがロールチェンジを望まず、かといって行き止まりのキャリアパスを見ると、その組織に長くいる理由がなくなる。したがって優秀な人で技術キャリアを追求したい人ほど組織から流出する
  • ロールチェンジを受け入れるにしても、そもそもエンジニア職と管理職系のスキルは延長線上にあるわけではなく、管理職としてのキャリアを再度1から積み上げないといけない
  • そしてエンジニアとして技術的に優秀だった人が、ピープルマネジメントや数字の扱い、戦略的な話についてうまくできる保証がまったくない

あるべき組織内のキャリアパス

上記のような組織内のキャリアパスの問題を解決するには、エンジニアのキャリアパスを行き止まりにしないことです。 管理職として上にいくだけでなく、エンジニアとして上にいくパスも定義して、本人の志向でどちらを選ぶのかを決められるのが望ましいと思います。

レベルエンジニア系(個人型)管理職系
5チーフエンジニアディレクター
4プリンシパルエンジニアシニアマネージャー
3シニアエンジニアマネージャー
2エンジニア 
1アソシエイトエンジニア 

このとき意識しておくべき点は以下のようなことになります。

  • エンジニアを貫くか管理職系にいくかは本人の志向によって決める
  • エンジニアから管理職になったが、やはりまたエンジニアに戻るという選択肢もある
  • ロールチェンジするときには十分な教育が必要(これは従来型のパスだろうと同じだが)
  • 自分が管理職だった場合に、自分よりもレベルが上のエンジニアが管理対象になることがある(部下の方が給与が高いことも当然ある)
  • 要はそれぞれのロールが違って責任が違うだけなので、上司なので偉いとかそういう話ではない
  • エンジニアは多くの場合、技術が分かっていない人から技術的な指示をされることに抵抗感を持つ。すなわち技術的な点の意思決定については現場やチーフエンジニアやプリンシパルエンジニアといった上級のエンジニアに委譲した方がよい
  • 年功序列ではなくて、各レベルで定められたJob Descriptionに合致しているかどうかが次のレベルにいけるかの判断基準になる

個人としての選択

個人としてどう選択するかは、完全に個人の問題であり個人の責任です。

正常性バイアス

心理学によく出てくる話に認知バイアスというものがあり、そのうちの1つに正常性バイアスがあります。正常性バイアスとは

自分にとって都合の悪い情報を無視したり、過小評価したりしてしまう人の特性のこと。自分にとって何らかの被害が予想される状況下にあっても、都合の悪い情報を無視したり、「自分は大丈夫」「今回は大丈夫」「まだ大丈夫」などと過小評価したりしてしまい、逃げ遅れの原因となる(Wikipediaより加筆修正)

というものです。すなわち周りはそんなことを考えていないから大丈夫だ、という話でもなく、会社もそれなりに大きな規模なので大丈夫という話でもありません。 会社の平均存続期間よりも自分が働く期間の方が長いので、どこかで職場を変える・キャリアの方向性を変えるといったことが必要になってきます。

とはいえ、正常性バイアスとは、こういうことをいっても「自分には関係ないし〜」とか「大げさすぎだろ!」みたいな反応を示すことでもあるので痛い目を見るまでは分からないかもしれません。それも含めて自己責任ということです。

社外で通用するようにしておくことの安全性

どこかで職場を変えたりキャリアの方向性を変えることをしないといけないとすると、その可能性を広げるためには社外で通用するようにしておくことです。 技術でも管理でも構わないですが、自分の「社内価値」ではなく「市場価値」を上げる方向で自分のキャリアを考えていくのが安全です。

そう考えた時に言えそうなこととしては以下のようなことが挙げられるでしょう。

  • レガシー環境の中で枯れた(いまさら新規に誰も使わない)技術にロックインされ続けるのは避ける(一方でCOBOLくらいになるとまた別の市場価値がある)
  • マイナーな商用製品にロックインされ続けるのも同様で、オープンスタンダードを知っておくようにした方がいい
  • 業務知識があるから大丈夫、というのはちょっと待った方がよい。業務知識はお客さんの方が詳しい。業界としての知識は役にたつが、独自に作りこみまくった特定のお客さんの業務を知っていたからといって、その業務がずっと継続するのかも分からないし、そもそもそのお客さんが存続し続けるかも分からない
  • 自己申告評価より他人からどう評価されるかが重要なので、目に見えるアウトプットがあるといい(オープンソース、ブログ、執筆、登壇いろいろ手はある)。そういったものを定期的に棚卸ししたり、自分のレジュメを定期的に更新していくのも良い
  • 管理職側で生きていくなら、自分の会社の独自のマネジメントのやり方だけでなく、一般に通用する色々な理論やベストプラクティスを身につけること

とはいえ全ては価値観の問題

「仕事はそこそこのお金が貰えればよくて、苦しくても週末の趣味を楽しみにして我慢するからいいや」も勿論ありですし、「勉強するのもめんどくさいしそこまでやらなくてもなんとかなるだろ」でもそれで本人が良いなら構わないでしょう。 ただ、他人は自分に起こることの責任は取れないというだけです。人のせい・環境のせいにしないで済むように自分のキャリアを考えてみるとよいと思います。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 物理カンバンの写真10枚(+勝手レビュー)
次の記事 【資料公開】カンバンのキホン

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World