はじめに:キャリアの行き詰まりを越えて
技術を愛するエンジニアの皆さん、キャリアについてこんな風に悩んでいませんか?
このまま技術を深掘りしてスペシャリストになるべきか、それともマネジメントに進むべきか・・・
そして、生成AIの進化により、もう一つ、大きな不安が加わりました。
AIがエンジニアの仕事を担うようになったとき、自分はどうなるのか。
多くのエンジニアが、スペシャリストかマネジメントかというキャリアの二極化、そしてAIによる技術的価値のコモディティ化という、二重の課題に直面しています。
スペシャリストもマネジメントもエンジニアのキャリアの王道ですが、どこか自分の想い描く形とズレていると感じる人も多いのではないでしょうか。その行き詰まりは、あなたが持つ技術的知見を活かす場所が、まだ見つかっていないだけかもしれません。
何を隠そう、私もそうでした。
SES/受託のソフトハウスから事業会社へ、組み込み制御開発から業務システム開発へ。PG、SE、PMを経て、PJを推進してきました。最終的にはSES事業組織の部長を担っていました。また、人材開発部の立ち上げの過去もあります。
今は組織・人材開発という、一見技術とは遠く人事領域に近いポジションですが、エンジニアリング課に身を置いています。
企業によっては、EM、DevHR、 Engineering Office、HRBP、人事、様々な部署や職種に相当しますが、役割範囲も明確には定義されていません。
この変化の中で気づいたのは、エンジニアのキャリアは「技術・マネジメント・ビジネス」の3つだけではない、ということです。
本記事のゴール
あなたの技術的知見を組織という最大のアウトプットに繋げる第5のキャリアすなわち「組織デザイナー」としての組織・人材開発の可能性と、その道筋を具体的に紹介します。
一般的なキャリアパスと私の起点:王道ルートと転換点
まず、現在エンジニアが目指す主要なキャリアパスを確認し、そこから私がどのように転換点を見つけたのかを説明します。
エンジニアの4つの王道キャリアパス
| キャリアパス | 概要 | 求められる役割 |
|---|---|---|
| 1.スペシャリスト(IC) | 特定技術を極める | 技術的な複雑な問題を解決する |
| 2.プロジェクトマネジメント(PjM) | プロジェクトを牽引する | QCD(品質・コスト・納期)を管理し、目標達成に導く |
| 3.エンジニアリングマネジメント(EM) | エンジニアリング組織を管理・育成する | チームの生産性向上、メンバーのキャリア開発、技術負債の管理 |
| 4.プロダクトマネジメント(PdM) | ビジネスと技術を繋ぐ | プロダクトの成功と事業成長に責任を持つ |
二足のわらじは正直に言って過酷
私のキャリア初期は組み込み開発で技術者としての原点を築き、その後ライフステージの変化とWebの進化に伴うスキルチェンジを経て、技術の深化からプロジェクトマネジメントへの移行を辿ってきました。
その後、プロダクト開発と組織システム設計を並行して行う、独自の土台が形成されました。
| フェーズ | 期間 | 概要 | 王道パスとの関連 |
|---|---|---|---|
| 新卒〜4年目 | 4年 | SES(制御設計/組み込み開発) | スペシャリスト(1)の要素。「動くものを作る」技術者としての原点。 |
| ブランク | 3年 | 結婚・出産・育児 | 視点の獲得。「限られたリソースでの効率化」「計画性」を磨く。 |
| 復帰後〜11年間 | 11年 | SES/受託(業務システム開発:PG→SE→PL→PM)【並行して組織開発・人材開発を7年間実施】 | プロジェクトマネジメント(2)の道。QCDを学びチームを牽引。 |
【ポイント】PjMと並行して行った「二つのシステム開発」
PjMとして業務システム開発を担う期間のうち、約7年間は業務システムの開発・運用と組織・人材のシステム設計という、二つの領域を並行して担当していました。
業務システム開発 : 顧客の課題を解決するプロダクトを設計・構築。
組織・人材開発 : 自社のエンジニアのパフォーマンスとキャリアの課題を解決する組織システムを設計・運用。
プロジェクトを進める中で気づいたことは、技術や設計が完璧でも、プロジェクトはほとんどが「人」の要因で失敗しているということです。技術だけではなく、「計画、コミュニケーション、そしてメンバーのモチベーション」が非常に重要であると考えました。
そこで、EMの役割も担いながら、社内のエンジニア育成・研修や新評価策定などの仕組み化に取り組みました。この二つのシステムを同時に扱う経験が、私の「第5のキャリア」への移行を可能にした最大の土台です。
エンジニアリングの延長としての組織・人材開発
「技術」から「人・組織」への転身は、畑違いの異動ではありません。エンジニアリングの適用範囲を「コード」から「組織」へと広げた、進化の過程と捉えます。
なぜ「組織・人材開発」がエンジニアの専門領域になり得るのか?
エンジニアが日常的に使うスキルは、「組織」という複雑なシステムを設計・デバッグする上でも活かされるものです。
| エンジニアのスキル | 組織・人材開発での適用先 | 効果 |
|---|---|---|
| システム思考 | 人事評価制度、育成プログラム設計 | 制度を一つのシステムとして捉え、インプット(教育)とアウトプット(成果)の連動性を高める。 |
| 要件定義スキル | 組織課題のヒアリング、ニーズ分析 | メンバーや部門の曖昧な不満を、解決すべき課題(要件)として定義する。 |
| デバッグ・改善サイクル | 制度の運用と効果測定(PDCA) | 制度をアジャイル的に導入・効果測定し、ボトルネックを修正(デバッグ)する。 |
EMと組織・人材開発の決定的な違い
EMは、組織・人材開発に非常に近いですが、スコープが異なります。(企業により同一の場合もあります)
EMは現場の実行に責任を持ちますが、組織・人材開発は戦略的な構造設計に特化します。
| 項目 | エンジニアリングマネージャー(EM) | 組織・人材開発 |
|---|---|---|
| スコープ | チーム、開発部門のパフォーマンス | 全社、特に開発組織の構造と制度の設計 |
| 目的 | 組織の実行力の最大化 | 長期的な事業成長のための組織拡大と人的資産価値の最大化 |
EMが「現場の生産性を高める実行役」であることに対し、組織人材開発は「事業戦略を達成するための組織の骨格(制度・構造)を設計するシステムエンジニア」と言えます。
「第5のキャリア」への道筋
組織改善するエンジニアリングの力を発揮するために、今すぐ実践できる具体的なステップを紹介します。
Step1:組織の課題を「バグ」として捉えよ
あなたのチームの生産性が低いのはなぜですか?
- 特定のスキル不足という「人」のバグでしょうか?
- 評価基準の曖昧さや情報共有の仕組みが不十分という「制度や仕組み」のバグでしょうか?
技術的な視点で、感情論ではなく構造的なボトルネックを探し出し、それを具体的な解決すべき要件として定義しましょう。
Step2:小さな組織改善プロジェクトを立ち上げよ
いきなり全社的な制度改革はできなくても、自分のチームから始めることができます。
- チーム内の学習文化を改善するメンター制度を提案・導入する。
- 新メンバーのオンボーディングの仕組みをドキュメント化し、効率化を図る。
これらは、PMやEMスキルがそのまま活かせる、小さな「組織改善プロジェクト」です。
Step3:「人と戦略」を学び続けよ
組織というシステムを設計するには、新しい知識が必要です。
技術書だけでなく、組織行動論(なぜ人は動くか)、リーダーシップ論、経営戦略論もインプットしましょう。組織全体の流れと、事業がどこに向かっているかを理解することが、より戦略的な組織システム設計に繋がります。
技術者は組織デザイナーになれる
AIが技術的な作業を効率化する未来において、「エンジニアリング」の定義は変わります。
AIが代替しにくい価値、それは「組織設計」と「戦略的なヒューマンシステムの最適化」です。
人々のモチベーションを分析し、部門間の利害調整を行い、事業戦略に基づいた評価制度や配置計画という名のヒューマンシステムをAIがデバッグすることはできません。人には感情があり、それは常に変化し、時には自分でもコントロールができないものだからです。
エンジニアリングとは、単にコードを書くことではありません。問題を解決し、価値を生み出す仕組みを設計することです。
その仕組みが、あるプロダクトに閉じることなく、組織全体にまで広がるのが、「第5のキャリア」の醍醐味です。
あなたの持つシステム思考力を武器に、組織という巨大なシステムに挑む組織デザイナーとして、現場から未来の働き方を設計しませんか。