TL;DR（この記事の要約）

• インターナルモビリティとは、社内公募・配置転換・兼務などで社内の人材を流動的に活用する仕組み

• エンジニア採用の競争激化・コスト増加に対する「守りの人材戦略」として注目度が急上昇中

• 制度設計のカギは「スキル可視化」→「社内公募の仕組み構築」→「リスキリング支援」の3ステップ

• 外部採用と社内異動の併用型が最もROIが高く、採用コスト削減と離職率低下を同時に実現できる

• 部門間の「人材囲い込み」を防ぐマネジメント設計が成否を分ける

このページでわかること

エンジニア採用市場の競争が激化するなか、「外から採る」だけでなく「中で育てる・動かす」視点を持つ企業が成果を出し始めています。外部採用のコストが上がり続ける一方で、社内には活用しきれていない人材やスキルが眠っている——そんな状態に気づいた企業が、インターナルモビリティに本格的に取り組み始めています。

本記事では、インターナルモビリティ（社内人材の流動化）を活用してエンジニア人材を確保するための制度設計、運用ノウハウ、そして陥りやすい失敗パターンまでを網羅的に解説します。

この記事を読むと、以下がわかります。

• インターナルモビリティとは何か、なぜ今エンジニア組織で必要なのか

• 社内公募制度・社内FA制度の具体的な設計方法

• リスキリングと組み合わせた技術人材の内部育成フロー

• 部門間の対立を防ぐマネジメントの仕組み

• 外部採用とのバランスをとる人材ポートフォリオの考え方

• 導入ロードマップと効果測定のKPI

1. インターナルモビリティとは何か

定義と基本概念

インターナルモビリティ（Internal Mobility）とは、社内における人材の流動性を高める取り組みの総称です。具体的には以下の制度や施策が含まれます。

海外では「Quiet Hiring（静かな採用）」とも呼ばれ、2026年のHRトレンドとして注目されている概念です。外部から人材を採用するのではなく、社内の既存人材を別の役割やポジションに配置することで、組織が必要とするスキルを確保する手法を指します。

エンジニア組織ならではの特性

インターナルモビリティが特にエンジニア組織で有効な理由があります。

技術スキルの転用性が高い

エンジニアのスキルは「言語」「フレームワーク」「インフラ」「設計パターン」のように構造化されており、ある領域で培ったスキルの多くが別の領域でも活きます。たとえば、Webアプリケーション開発で身につけたAPI設計の知識は、データパイプライン構築でもそのまま応用できます。営業職からマーケティング職への異動よりも、エンジニア間の異動の方がスキル移転の効率が高いケースが多いのです。

ドメイン知識の価値が大きい

エンジニアが生産性を発揮するには、技術スキルだけでなくプロダクトや事業のドメイン知識が不可欠です。外部から採用した場合、このドメイン知識の習得に3〜6ヶ月かかることも珍しくありません。社内異動なら、すでに蓄積されたドメイン知識をそのまま新しいポジションで活用できます。

チーム間の技術連携が促進される

異動経験者は「前のチームではこうやっていた」という知識を持ち込むため、チーム間の技術的なベストプラクティスの共有が自然に起こります。コードの書き方、CI/CDの設計、障害対応のプロセスなど、組織全体の技術レベルの底上げにつながります。

外部採用との違い

「インターナルモビリティは採用の代替手段なのか？」と聞かれることがありますが、答えは「代替ではなく補完」です。

外部採用が得意な領域:

• 社内にまったく存在しないスキルの獲得（例: 初のMLエンジニア採用）

• 組織のカルチャーに新しい風を入れたいとき

• 急激な事業拡大で大量のヘッドカウントが必要なフェーズ

インターナルモビリティが得意な領域:

• 既存メンバーのスキルの延長線上にあるポジション補充

• プロダクト理解やドメイン知識が重要な役割

• 採用コストを抑えながら中長期的にケイパビリティを拡充したいとき

両者を組み合わせた「ハイブリッド型人材戦略」が、コスト効率と組織力の両方を最大化します。

重要なのは、インターナルモビリティを「採用がうまくいかないときの代替手段」ではなく、「人材戦略の柱のひとつ」として位置付けることです。外部採用市場が好調なときでも、社内人材の流動性を高めておくことで組織の回復力（レジリエンス）が上がります。景気変動や採用市場の冷え込みに左右されにくい組織を作るには、内部と外部の両方のパイプラインを常に動かしておくことが大切です。

2. なぜ今エンジニア組織にインターナルモビリティが必要なのか

採用市場の構造的な変化

2026年現在、エンジニア採用市場には深刻な構造変化が起きています。

• 有効求人倍率の高止まり: IT・通信分野の新規有効求人倍率は3倍超で推移（出典: doda「IT・通信の転職市場動向 2026上半期」）

• 採用コストの上昇: エージェント経由の採用単価は年々上昇し、年収の30〜35%が相場に（参考: エンジニア採用コストの最適化ガイド）

• スキル要件の高度化: AI、クラウドネイティブ、セキュリティなどの専門領域でスキルの需給ギャップが拡大

• 採用リードタイムの長期化: 優秀なエンジニアは複数社から同時にオファーを受け、意思決定が長期化

こうした環境下で「外部採用だけで人材を賄う」戦略は、コスト面でもスピード面でも限界を迎えつつあります。

離職防止とリテンション効果

インターナルモビリティには「採用」だけでなく「リテンション」への効果も期待できます。

エンジニアが転職を考える大きな理由のひとつが「成長機会の停滞」です（詳しくは「エンジニアの離職を防ぐリテンション実践ガイド」でも解説しています）。同じチーム、同じ技術スタック、同じ役割で何年も過ごすと、市場価値の低下を不安に感じ始めます。社内異動の選択肢があれば、転職せずとも新しい挑戦ができます。

社内異動がリテンションに効く3つの理由:

1. キャリアの停滞感を解消: 新しい技術領域やプロダクトに挑戦できる（関連: エンジニアのキャリアパス設計で採用力と定着率を高める）

2. 社内ネットワークの拡大: 別チームとの協業で視野が広がり、帰属意識が強まる

3. 「ここでまだ成長できる」実感: 社外に出なくてもキャリアが前に進む体験を提供

一般的に、社内異動の制度が整っている組織では社員の在籍期間が長くなる傾向があるとされています。「辞めたい」ではなく「異動したい」と言える環境があるだけで、優秀なエンジニアの流出リスクは大きく下がります。

コスト面の合理性

外部採用と社内異動のコストを比較してみます。

もちろん、社内異動にも「異動元チームの穴埋め」というコストが発生します。しかし、そのコストは外部採用のそれと比べて圧倒的に予測可能で、コントロールしやすいものです。

3. 社内公募制度の設計と運用

制度設計の5ステップ

社内公募制度をゼロから立ち上げる場合、以下のステップで進めます。

ステップ1: 経営・マネジメント層の合意形成

インターナルモビリティは「人材を部門の所有物とみなさない」思想が前提です。まず経営層やVPoE/EMレベルで「人材は会社全体のリソースである」というコンセンサスを取ります。

• 経営会議でインターナルモビリティの方針を明示

• 「異動を出したマネージャーの評価が下がらない」仕組みを担保

• 人材開発の観点で、異動を「ポジティブなイベント」として位置付ける

ステップ2: ポジション情報の標準化

社内に公開するポジション情報を標準フォーマットで整備します。社外向けの求人票（JD）と同様の情報を揃えるのがポイントです。

• ポジション名と役割の説明

• 必須スキル・歓迎スキル

• チームのミッションと技術スタック

• 期待する成果と評価基準

• 異動後のオンボーディング計画

ステップ3: 応募プロセスの設計

社内公募の応募プロセスは、外部採用の選考よりも軽量にするのが原則です。

• 応募条件: 現職での最低在籍期間（例: 12ヶ月以上）を設定

• 選考: 受入先マネージャーとの面談1〜2回

• 現マネージャーへの通知: 応募後に通知するか、事前承認制にするかを決定

• 異動タイミング: 応募から異動完了までの標準期間を設定（例: 1〜3ヶ月）

ステップ4: 情報公開チャネルの整備

ポジション情報をどこに掲載するかも重要です。

• 社内ポータルサイトやWikiに専用ページを設置

• Slackチャンネル（例: #internal-openings）で新規ポジションを通知

• 月次の全社ミーティングで募集中ポジションを共有

• 1on1で上長がキャリア希望をヒアリングし、合致するポジションを紹介

ステップ5: 異動後のフォローアップ

異動して終わりではなく、異動後の立ち上がりを支援する仕組みが必要です。

• 異動先チームでのバディ（メンター）のアサイン（参考: エンジニアのオンボーディング完全ガイド）

• 30日・60日・90日のチェックポイント面談

• 異動元チームとの引き継ぎ計画の明文化

• 異動後6ヶ月時点でのフィードバックアンケート

社内FA制度との使い分け

社内公募制度は「組織がポジションを提示する」のに対し、社内FA制度は「社員が自らキャリアを選ぶ」仕組みです。

エンジニア組織では、まず社内公募制度から始めて運用が安定した後にFA制度を追加するのが現実的です。

実際の運用で気をつけるべきポイント

社内公募制度を実際に運用してみると、いくつかの現実的な課題が浮かび上がります。

応募のタイミング管理

プロジェクトの区切りやリリースサイクルと異動のタイミングを合わせる必要があります。スプリントの途中で主力メンバーが抜けると、チームの開発速度に大きな影響が出ます。四半期ごとに「異動ウィンドウ」を設定し、そのタイミングでまとめて異動を実施するのが安定した運用方法です。

不採用時のケア

社内公募に応募して不採用になった場合、外部採用の不採用よりも心理的ダメージが大きくなりがちです。「自分はこの会社でキャリアを広げられないのか」とモチベーション低下につながりかねません。不採用の場合は必ず理由を明確にフィードバックし、「次に何を身につければ異動できるか」の具体的なアドバイスを提供してください。

機密性の確保

応募者の情報が現チームのマネージャーに漏れないよう、情報管理のルールを明確にしておく必要があります。特に「マネージャーの承認なしで応募可能」という制度にする場合、応募者の心理的安全性を確保するための機密管理は必須です。人事部門が窓口となり、マネージャーへの通知タイミングを異動決定後にするなどの設計が有効です。

4. エンジニア向けリスキリングと連動させる方法

なぜリスキリングとセットで考えるべきか

インターナルモビリティの効果を最大化するには、リスキリング（学び直し）との連動が不可欠です。理由は単純で、「異動したいけど、異動先で求められるスキルがない」という状態を解消しなければ、制度があっても利用されないからです。

たとえば、以下のようなスキル転換のニーズは多くのエンジニア組織で発生しています。

• バックエンド → インフラ/SRE: クラウド基盤の構築・運用スキルの習得

• QA → セキュリティ: 脆弱性診断やセキュアコーディングの知識獲得

• フロントエンド → フルスタック: API設計やDB設計のスキル拡張

• アプリケーション → データ/ML: Python、統計、MLOpsの基礎習得

• IC（個人貢献者）→ EM: ピープルマネジメント、1on1設計のスキル転換

リスキリングプログラムの設計

エンジニアのリスキリングを効果的に進めるためのフレームワークを紹介します。

フェーズ1: スキルギャップの可視化（2週間）

まず、異動先で必要なスキルと現在のスキルのギャップを明確にします。

• スキルマトリクスを作成（技術スキル・ソフトスキルの両面）

• 現職の上長と異動先の上長が共同でギャップを評価

• 本人の自己評価も加味して、学習計画を策定

フェーズ2: 学習期間（1〜3ヶ月）

業務時間の一部をリスキリングに充てる仕組みを用意します。

• 業務時間の20〜30%を学習に充当（Googleの20%ルールの応用）

• 社内の技術メンターをアサイン

• オンライン学習プラットフォーム（Udemy Business、Courseraなど）の法人契約を活用

• 社内勉強会やペアプログラミングで実践的なスキルを補完

フェーズ3: 段階的な業務移行（1〜2ヶ月）

学習期間の後半から、異動先チームの業務に段階的に関与します。

• 最初はペアワークやコードレビューへの参加から開始

• 小さなタスクを任せて、徐々に独力でこなせる範囲を広げる

• 週次の振り返りで進捗を確認し、学習計画を調整

フェーズ4: 完全異動と定着支援（3ヶ月〜）

異動完了後も、定着するまでのフォローを継続します。

• 異動後90日間は「ランプアップ期間」として期待値を調整

• 元チームとの関係を維持する（技術相談や情報共有を継続）

• 360度フィードバックで本人とチームの相互理解を促進

リスキリングの投資対効果

「リスキリングにコストをかけるくらいなら、スキルのある人材を外部から採った方が早いのでは？」という疑問は当然出ます。

しかし、実際に比較すると以下のような差があります。

• 外部採用: 採用コスト（年収の30〜35%）＋オンボーディングコスト＋早期離職リスク＋ドメイン知識習得に3〜6ヶ月

• リスキリング: 学習コスト（研修費用＋業務時間の一部）のみ。ドメイン知識は既に保有。組織文化への適応も不要

特にプロダクト理解やドメイン知識が重要なポジション（テックリード、SRE、プラットフォームエンジニアなど）では、内部人材をリスキリングする方が立ち上がりが圧倒的に速いケースが多いです。

リスキリングを成功させる組織文化

リスキリングの仕組みを作っても、「学習に時間を使うことへの罪悪感」が社内にあると利用率は上がりません。組織文化として以下の要素を意識的に育てる必要があります。

• 「学習は業務の一部」という認識の浸透: マネージャーが率先して学習時間を確保し、チームに対して学習を推奨する姿勢を見せる

• 学習成果の共有の場: 月次の技術共有会やLT（Lightning Talk）で、リスキリングの学びを発表する機会を設ける

• 失敗を許容する雰囲気: 新しい技術領域への挑戦では必ず失敗が伴う。「できなかった」ことを責めず、「挑戦した」ことを評価する

• 経営層のメッセージ: CTOやVPoEが「技術の幅を広げることは個人にも組織にもプラス」と明言し、リスキリングを組織の戦略として位置付ける

5. 部門間の「人材囲い込み」を防ぐマネジメント設計

よくある失敗パターン

インターナルモビリティの導入で最も多い障壁が、マネージャーによる「人材囲い込み」です。

• 異動を妨害する: 「今は繁忙期だから」「後任が見つかるまで待ってほしい」と引き延ばす

• 評価で報復する: 異動希望を出したメンバーの評価を意図的に下げる

• 情報を隠す: 社内公募の情報をチーム内で共有しない

• 暗黙の圧力: 「うちのチームで成長してほしい」と異動を思いとどまらせる

これらは制度を形骸化させる最大の要因です。

対策: マネージャーのインセンティブ設計

囲い込みを防ぐには、「人材を送り出すことがマネージャーにとってもメリットになる」仕組みを作る必要があります。

1. マネージャー評価に「人材輩出」の項目を追加

• 他チームへ異動した人材の数を評価指標に含める

• 「人を育てて送り出す」文化を評価で裏付ける

• 経営陣が全社会議で「人材輩出マネージャー」を称賛する

2. 異動元チームへの補充を保証する

• 異動により空いたポジションの採用予算を優先的に確保

• 異動完了前に後任の採用・育成を開始する猶予期間を設ける

• 一時的なリソース不足を外部パートナー（業務委託）で補填する選択肢を用意

3. 異動プロセスのルールを明文化する

• 「応募は本人の権利であり、マネージャーの許可は不要」と規定

• 異動のタイムラインを標準化（例: 応募から異動完了まで最長3ヶ月）

• 異動拒否の場合は理由を人事に報告し、不当な拒否には是正措置をとる

透明性の確保

制度の運用状況を定期的に全社に共有することも重要です。

• 四半期ごとの異動実績レポートを公開

• 異動した社員のインタビューを社内報やSlackで共有

• 異動に関するアンケートを実施し、制度の改善に反映

6. スキル可視化の仕組みづくり

なぜスキル可視化が前提条件なのか

インターナルモビリティを機能させるためには、「誰がどんなスキルを持っているか」が組織的に可視化されている必要があります。可視化されていなければ以下の問題が起きます。

• 「あのチームにGo言語が書ける人がいるらしい」→ 噂ベースの人材探し

• 「この人はフロントエンドしかできない」→ 実は個人プロジェクトでインフラもやっている

• 「リスキリング対象者が誰かわからない」→ 施策が打てない

スキルマトリクスの作り方

エンジニア組織向けのスキルマトリクスは、以下の3階層で設計すると扱いやすくなります。

第1層: 技術スキル（ハードスキル）

• プログラミング言語（Go, TypeScript, Python, Rust等）

• フレームワーク・ライブラリ（React, Next.js, FastAPI等）

• インフラ・クラウド（AWS, GCP, Kubernetes, Terraform等）

• 専門領域（ML/AI, セキュリティ, データベース, ネットワーク等）

第2層: プロダクト・ドメインスキル

• 自社プロダクトのアーキテクチャ理解度

• 業務ドメインの知識（金融、医療、EC等）

• 社内システム・ツールの習熟度

第3層: ソフトスキル・リーダーシップ

• コードレビュー・メンタリング能力

• プロジェクトマネジメント経験

• ステークホルダーとのコミュニケーション

• 技術選定・意思決定の経験

各スキルを4段階（例: 未経験 / 基礎 / 実務レベル / リード可能）で評価し、半年ごとに更新します。

運用のコツ

スキルマトリクスは作って終わりではなく、運用の仕組みが大切です。

• 1on1での定期更新: マネージャーとの1on1で半年に1回、スキルの自己評価と上長評価をすり合わせ

• プロジェクト参加歴との連動: どのプロジェクトでどの技術を使ったかの記録を自動的にスキル情報に反映

• 本人の希望スキルも記録: 「今は使っていないが、今後伸ばしたいスキル」を可視化することで異動・リスキリングの候補を特定

• 過度な精緻化を避ける: 完璧なスキル台帳を作ろうとすると運用が破綻する。まずは80%の精度でスタートし、運用しながら改善する

ツールの選択肢

スキル可視化を支援するツールにはいくつかの選択肢があります。

スプレッドシート（小規模向け）

10〜30名程度のチームなら、Googleスプレッドシートで十分です。行にメンバー名、列にスキル項目を並べ、4段階の数値（0〜3）で評価する形式です。導入コストはゼロで、すぐに始められます。

社内Wiki + 自己申告（中規模向け）

30〜100名程度なら、ConfluenceやNotionに各自のスキルシートを作成してもらう方法が有効です。本人が自由に更新でき、マネージャーが1on1でレビューするフローにすると、情報の鮮度が保たれます。

タレントマネジメントツール（大規模向け）

100名以上の組織では、カオナビやHRBrainなどのタレントマネジメントツールの導入を検討します。スキル情報の集約、検索、分析が効率化され、「このスキルを持つ人は誰か」をすぐに特定できます。

規模にかかわらず重要なのは、「更新の手間を最小化する」ことです。入力が面倒だと情報が古くなり、制度全体が形骸化します。

7. 導入ロードマップと効果測定

90日ロードマップ

インターナルモビリティ制度をゼロから導入する場合の90日計画です。

Day 1〜30: 基盤整備フェーズ

• 経営層・EMへのインターナルモビリティの必要性プレゼン

• 現状の社内異動実績と離職率のデータ収集

• パイロット対象チーム（2〜3チーム）の選定

• スキルマトリクスのテンプレート作成

Day 31〜60: パイロット運用フェーズ

• パイロットチームでスキルマトリクスを作成

• 社内公募ポジションを2〜3件テスト掲載

• 応募プロセス・異動プロセスのフロー整備

• パイロットチームのマネージャーとの週次振り返り

Day 61〜90: 制度化フェーズ

• パイロットの結果をもとに制度を修正

• 全社向けの運用ガイドラインを策定

• 社内公募専用のSlackチャンネル・ポータルページを開設

• 全社キックオフで制度をアナウンス

• KPIの計測開始

KPIの設計

インターナルモビリティの効果を測定するためのKPIを設計します。

アクティビティ指標（施策の浸透度）:

• 社内公募ポジション数（月次）

• 社内公募への応募数（月次）

• 制度の認知率（アンケート）

• スキルマトリクス更新率

アウトカム指標（成果）:

• 社内異動成立件数（四半期）

• 異動者の異動後パフォーマンス評価

• 異動者の6ヶ月後定着率

• リスキリング完了率

• 外部採用コストの変化（前年比）

インパクト指標（組織への影響）:

• エンジニア組織全体の離職率変化

• エンゲージメントサーベイの「成長機会」スコア

• 社内異動経験者の在籍年数

• 外部採用の充足率（社内異動で補えたポジションの割合）

目安として、制度導入から半年で社内公募への応募が月5件以上、異動成立が四半期2件以上を最初の目標にするとよいでしょう。

なお、KPIの計測を始めたら、四半期ごとに経営会議やEMミーティングでレビューする場を設けてください。データに基づいて制度を改善するサイクルを回すことで、形だけの制度に終わらせず、実効性のある仕組みとして定着させられます。特に「応募数は多いが成立件数が少ない」場合はマッチングの精度に、「そもそも応募が少ない」場合は認知度や心理的ハードルに課題がある可能性が高いため、原因を切り分けて対策を打ちましょう。

8. 外部採用とのバランス：人材ポートフォリオの考え方

「内部調達」と「外部調達」の最適配分

すべてのポジションを社内異動で埋めようとするのは非現実的です。逆に、すべてを外部採用で賄うのもコスト的に持続不可能です。

ポジションの特性に応じて、「内部調達」と「外部調達」の最適な配分を考えます。

社内異動が向いているポジション:

• テックリードやアーキテクト（プロダクト・組織の深い理解が必要）

• エンジニアリングマネージャー（社内の信頼関係が重要）

• SREやプラットフォームエンジニア（自社システムの全体像理解が不可欠）

• 新規事業チームの初期メンバー（社内のリソースや意思決定プロセスを知っている人が有利）

外部採用が向いているポジション:

• 社内にまったく存在しない専門領域（初のMLエンジニア、初のセキュリティ専任など）

• 急拡大フェーズでの大量採用（参考: エンジニア組織のスケーリング採用戦略）

• 組織に多様性（スキル・経歴・視点）を注入したいとき

• ジュニアポジション（ポテンシャル採用で社外の新鮮な人材を取り込む）

ハイブリッド型の運用例

あるスタートアップのケースを想定して、ハイブリッド型の運用イメージを示します。

前提: エンジニア30名、年間採用目標10名

• 外部採用: 7名（新規専門職2名 + ジュニア3名 + シニア2名）

• 社内異動: 3名（他部門からの異動1名 + チーム間異動2名）

• リスキリング対象者: 2名（並行して育成、半年後に異動）

この配分により、外部採用の目標を30%削減でき、採用コストの大幅な圧縮が期待できます。同時に、社内異動が活発になることでリテンション効果も生まれ、離職による補充採用の必要性も減少します。

人材ポートフォリオを見直すタイミング

人材ポートフォリオの内部/外部比率は固定ではなく、事業フェーズに応じて見直す必要があります。

シード〜アーリーステージ（エンジニア10名以下）

このフェーズでは外部採用の比率が高くなるのが自然です。そもそも社内にいるエンジニアの数が少なく、異動元の穴を埋める余力がありません。ただし、プロジェクト型アサインで「全員がバックエンドもフロントエンドも触れる」状態を作っておくと、後のフェーズで柔軟に動けます。

グロースステージ（10〜50名）

社内異動の仕組みを本格的に検討するタイミングです。チームが分かれ始め、「あのチームでやりたい」という声が出始める時期でもあります。このフェーズで社内公募制度の基盤を整えておくと、50名を超えたときにスムーズにスケールできます。

スケールステージ（50名以上）

インターナルモビリティが最も効果を発揮するフェーズです。チーム間の人材流動性が組織の健全性を左右します。専任の制度運用担当（人事やHRBP）を配置し、四半期ごとの異動計画を経営アジェンダに組み込むことを推奨します。

FAQ（よくある質問）

Q1. 小規模なエンジニア組織（10名以下）でもインターナルモビリティは意味がありますか？

10名以下の場合、正式な社内公募制度を作る必要はありません。ただし「プロジェクト型アサイン」や「リスキリング支援」は組織規模に関係なく有効です。たとえば、バックエンドエンジニアに月に数日インフラタスクを任せるだけでも、スキルの幅が広がり、チーム全体のバス係数（特定の人に依存するリスク）が下がります。

Q2. 異動希望が特定のチームに集中した場合、どう対応すべきですか？

人気チームに希望が偏ること自体は自然です。対応のポイントは以下の3つです。(1) 応募者全員と面談し、スキルマッチとキャリア目標を丁寧にすり合わせる。(2) 不採用の場合は理由を明確にフィードバックし、次の機会に向けたアドバイスを提供する。(3) 不人気チームの魅力を上げる施策（技術的チャレンジの可視化、マネージャーの1on1強化など）を並行して進める。

Q3. 異動元チームのリソースが不足する問題にはどう対処しますか？

これはインターナルモビリティの最大の課題のひとつです。対策としては、(1) 異動のタイムラインを十分に確保する（最低1ヶ月の引き継ぎ期間）。(2) 異動元チームへの外部採用予算を優先的に配分する。(3) 業務委託やフリーランスで一時的なリソースを確保する。(4) 複数チームで同時に異動が発生しないよう、四半期ごとの異動枠を設定する。

Q4. マネージャーが異動を快く思わない場合、どうすればよいですか？

マネージャーの抵抗は自然な反応です。「優秀な部下を手放したくない」という気持ちは理解できます。解決策は、(1) 経営層が「人材の流動性は組織の健全性の証」というメッセージを明確に発信する。(2) 「人材輩出」をマネージャーの評価項目に含める。(3) 異動元チームへの補充を制度として保証する。根本的には「優秀な人材を育てて送り出せるマネージャーこそ優秀」というカルチャーを醸成することが大切です。

Q5. リスキリングの成果が出ない社員がいた場合、どう扱いますか？

リスキリングは全員が成功するわけではありません。成果が出ない場合は、(1) 学習目標やスケジュールに無理がなかったか振り返る。(2) メンターやサポート体制が十分だったか確認する。(3) 本人の適性と希望を再度すり合わせ、別の領域への転換も検討する。(4) 現職での活躍に戻ることを「失敗」とせず、「挑戦した経験」としてポジティブに扱う。大切なのは、挑戦へのハードルを上げないことです。

Q6. インターナルモビリティの取り組みを採用ブランディングに活かすにはどうすればよいですか？

社内異動やリスキリングの制度は、外部への採用ブランディングにも大きく貢献します。(1) 技術ブログで社内異動した社員のインタビューを公開する。(2) 求人票に「社内公募制度あり」「リスキリング支援あり」と明記する。(3) カジュアル面談で「入社後のキャリアパスの柔軟性」を具体的に説明する。「入社した後も社内で新しい挑戦ができる」というメッセージは、成長意欲の高いエンジニアにとって強い魅力になります。

Q7. 社内公募制度を導入したが、応募がほとんどない場合はどうすべきですか？

応募がない原因は主に3つ考えられます。(1) 制度の認知度が低い → Slackでの定期告知、全社会議でのリマインド、1on1での案内を強化する。(2) 応募の心理的ハードルが高い → 匿名での相談窓口を設ける、「まず話を聞くだけ」のカジュアルな面談枠を用意する。(3) 魅力的なポジションが少ない → 募集側に「なぜこのポジションが面白いのか」を具体的に書いてもらう。

Q8. エンジニアのグレード（等級）が異動先と合わない場合はどう調整しますか？

異動先で求められるスキルセットが異なる場合、グレードをそのまま維持するか調整するかは慎重に判断します。基本方針としては、(1) 異動後6ヶ月はグレードを維持し、新しい領域でのランプアップ期間とする。(2) 6ヶ月後の評価で、異動先のグレード基準に照らして再評価する。(3) グレードが下がる場合は報酬を維持する「ソフトランディング」期間（3〜6ヶ月）を設ける。グレードが下がる可能性があると異動へのハードルが上がるため、報酬面での不利益を最小化する設計が重要です。

Q9. 異動したが、うまくいかずに元のチームに戻りたいという場合はどうしますか？

「戻る選択肢がある」ことを事前に明示しておくと、異動への心理的ハードルが下がります。具体的には、(1) 異動後3ヶ月以内は「試用期間」として、本人・受入先・送出元の三者合意で元チームへの復帰を認める。(2) 復帰を「失敗」として扱わない組織文化を醸成する。(3) 復帰後も次の異動チャンスを平等に提供する。「戻れる安心感」があることで、むしろ挑戦する人が増えるという効果が期待できます。

まとめ：外から採るだけが採用ではない

エンジニア採用が年々難しくなるなかで、「外部採用だけに頼る」戦略は持続可能ではありません。社内に眠っている人材のポテンシャルを引き出し、適切なポジションに配置するインターナルモビリティは、採用コストの削減と離職率の低下を同時に実現できる打ち手です。

今日からできるアクション:

1. スキルの棚卸し: エンジニア組織のスキルマトリクスを作成する（まずは1チームから）

2. 社内公募のテスト: 1つのポジションを社内に公開し、反応を見る

3. キャリア希望のヒアリング: 1on1で「今後やりたいこと・伸ばしたいスキル」を聞き、記録する

4. 学習時間の確保: リスキリング支援として、業務時間の一部（週2〜4時間）を学習に充てる仕組みを試す

5. マネージャーへの啓蒙: EM・テックリード向けに「インターナルモビリティのメリット」を共有する

大掛かりな制度構築は後でも構いません。まずは小さく始めて、組織に合った形を見つけることが大切です。

エンジニア採用は「外から採る」だけでなく「中を活かす」視点を持つことで、競争の激しい採用市場でも持続的に人材を確保できるようになります。インターナルモビリティは、その第一歩です。

エンジニア採用の戦略設計やインターナルモビリティの導入支援について相談したい方は、techcellarの採用支援サービスをご覧ください。採用コンサル営業出身の現役エンジニアが、貴社の状況に合わせた実践的なアドバイスを提供します。