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

• コンピテンシーモデルは「高い成果を出すエンジニアに共通する行動特性」を体系化したもの。スキルではなく"行動"に焦点を当てるのが最大の特徴

• 採用・評価・育成の3つを同じ物差しでつなげることで、「面接で見たポイント」と「入社後に求める行動」のズレを構造的になくせる

• エンジニア向けには技術コンピテンシー（設計力・コード品質・運用力）とビヘイビアコンピテンシー（協働・リーダーシップ・学習姿勢）の2軸で設計するのが実用的

• 習熟度は**4段階（L1: 指導下で実行 → L2: 自律実行 → L3: 他者を指導 → L4: 組織を変革）**が運用しやすい

• 作って終わりにしないために、採用面接の評価シート・人事評価・1on1のアジェンダにコンピテンシーを組み込む仕組み化が不可欠

• 2026年はAI活用力・AIとの協働行動を新たなコンピテンシーとして追加する企業が増加中

エンジニア組織にコンピテンシーモデルが必要な理由

「技術力は高いのに、チームで成果を出せない」「面接では優秀に見えたのに、入社後のパフォーマンスが期待と違う」。エンジニア組織でこんな課題を抱えていないだろうか。

このページでわかること

• コンピテンシーモデルとは何か、スキルマップとの違い

• エンジニア組織に特化したコンピテンシーの設計手順（7ステップ）

• 技術コンピテンシーとビヘイビアコンピテンシーの具体的な項目例

• 習熟度レベルの設定方法と判定基準

• 採用面接でのコンピテンシー評価の実践テクニック

• 人事評価・育成計画との接続方法

• AI時代に追加すべき新しいコンピテンシー項目

• 運用を形骸化させないための仕組みづくり

原因の多くは、採用・評価・育成で"見ているポイント"がバラバラになっていることにある。

面接では「技術的な深さ」を重視して採用したのに、評価制度では「チームへの貢献度」で測られる。育成計画は「新しい技術のキャッチアップ」を軸にしているが、それが面接で確認した項目とつながっていない。こうしたズレが積み重なると、エンジニア本人は「何を求められているのか分からない」状態になり、パフォーマンスも定着率も下がる。

この問題を根本的に解決する仕組みが「コンピテンシーモデル」だ。

コンピテンシーとは何か

コンピテンシー（competency）は、日本語では「行動特性」と訳されることが多い。ざっくり言えば、**「仕事で高い成果を出す人が、繰り返し取っている行動パターン」**のことだ。

ポイントは、スキルや知識そのものではなく「それをどう使うか」に焦点を当てている点。たとえばGoの文法を知っていること（スキル）と、チームの技術選定で「なぜGoが最適か」をデータを添えて提案し、合意形成まで持っていく行動（コンピテンシー）は別物だ。

スキルマップとの違い

スキルマップは「誰が・何を・どのレベルで"できる"か」を可視化するもの。コンピテンシーモデルは「どう"振る舞う"か」を定義するもの。補完関係にあり、両方持っている組織は採用精度が格段に上がる。

スキルマップの詳しい設計方法は「エンジニア採用のスキルマップ設計ガイド」で解説しているので、あわせて参照してほしい。

なぜ今コンピテンシーモデルが重要なのか

2026年現在、3つの環境変化がコンピテンシーモデルの重要性を高めている。

1. AI時代のスキル要件の不安定化

Cursor、Copilot、Claude CodeなどのAIコーディングツールの普及で、「コードを書く」スキルの価値が相対的に低下している。一方で「AIに的確な指示を出し、出力を正しく評価し、アーキテクチャを設計する」行動能力の重要性が急上昇。スキル要件が激変する時代には、変わりにくい「行動特性」を軸にした方が、採用・評価基準が安定する。

2. エンジニア採用の高度化

情報処理・通信技術者の新規求人倍率は3倍を超えており、「技術スキルだけで判断する」採用は限界を迎えている。カルチャーフィットやチームでの協働スタイルまで含めた多面的な評価が、採用のミスマッチを減らす鍵になっている。

3. リモート・ハイブリッドワークの定着

物理的に一緒にいない環境では「自律的に動ける」「非同期コミュニケーションで情報を構造化できる」「チームの状況を自ら発信できる」といった行動特性が、パフォーマンスを大きく左右する。

1. コンピテンシーモデルの基本構造

エンジニア組織のコンピテンシーモデルは、2つの大分類と4段階の習熟度で構成するのが実用的だ。

2つの大分類

技術コンピテンシー（Technical Competency）

ソフトウェア開発に直結する行動特性。「何の技術を知っているか」ではなく、「技術をどう使って問題を解決するか」を定義する。

• 設計・アーキテクチャ: 要件を構造化し、拡張性・保守性のあるシステムを設計する行動

• コード品質: 読みやすく、テストしやすく、変更に強いコードを書き、レビューで改善する行動

• 運用・信頼性: 障害対応、パフォーマンス最適化、モニタリング設計など、本番環境を健全に保つ行動

• 技術的意思決定: 技術選定やトレードオフ判断を、データと根拠に基づいて行う行動

• AI活用: AIツールを適切に活用し、出力を検証・改善して生産性を高める行動（2026年新設項目）

ビヘイビアコンピテンシー（Behavioral Competency）

チームや組織での振る舞いに関する行動特性。技術力だけでなく、「どうチームに貢献するか」を定義する。

• 協働・コミュニケーション: 技術的な内容を非エンジニアにも伝え、チーム内で建設的な議論を促す行動

• リーダーシップ・影響力: 公式な権限がなくても、技術的な方向性を示してチームを動かす行動

• 学習・適応: 新しい技術や環境変化に対して主体的に学び、業務に適用する行動

• 問題発見・解決: 顕在化していない課題を自ら発見し、解決策を提案・実行する行動

• オーナーシップ: 担当領域に対する責任を持ち、期限・品質・スコープを自律的に管理する行動

4段階の習熟度レベル

習熟度は4段階が運用しやすい。5段階以上にすると「L3とL4の違い」で評価者ごとにブレが生じやすくなる。

職種・等級別の期待レベル設定

すべてのエンジニアに全コンピテンシーでL4を求める必要はない。職種と等級ごとに「期待レベル」を設定し、現実的な目標を示すのがポイントだ。

ジュニアエンジニア（入社1〜2年目）

• 技術コンピテンシー: 設計L1、コード品質L2、運用L1

• ビヘイビアコンピテンシー: 協働L2、学習L2、オーナーシップL1

ミドルエンジニア（3〜5年目）

• 技術コンピテンシー: 設計L2、コード品質L3、運用L2、技術的意思決定L2

• ビヘイビアコンピテンシー: 協働L3、リーダーシップL2、問題発見L2

シニアエンジニア（6年目〜）

• 技術コンピテンシー: 設計L3、コード品質L3、運用L3、技術的意思決定L3

• ビヘイビアコンピテンシー: リーダーシップL3、問題発見L3、オーナーシップL3

テックリード・EM

• 技術コンピテンシー: 設計L4、技術的意思決定L4

• ビヘイビアコンピテンシー: リーダーシップL4、協働L4

2. コンピテンシーモデルの設計手順（7ステップ）

コンピテンシーモデルを「使えるもの」にするために、以下の7ステップで設計する。

ステップ1: ハイパフォーマーの行動特性を抽出する

最初にやるべきは、自社のハイパフォーマーに共通する行動パターンの特定だ。

具体的な方法は以下の通り。

• 行動インタビュー: ハイパフォーマー3〜5名に「成果を出した具体的なエピソード」を聞く。STAR形式（Situation→Task→Action→Result）で深掘りし、「何をしたか」ではなく「なぜそう判断し、どう動いたか」に焦点を当てる

• マネージャーへのヒアリング: 「高い成果を出すメンバーと平均的なメンバーの行動の違い」を具体例付きで聞く

• 360度フィードバックの分析: 既存の評価データがあれば、ハイパフォーマーに共通して高評価される項目を抽出する

注意点として、ハイパフォーマーが1名しかいない場合は、その人の属人的な特性がモデルに入り込むリスクがある。業界のベストプラクティスやフレームワーク（後述）を組み合わせて補正するとよい。

ステップ2: 外部フレームワークを参照する

自社のデータだけで設計すると視野が狭くなる。以下の外部フレームワークを参考にすると、抜け漏れを防げる。

IPA（情報処理推進機構）のiコンピテンシ ディクショナリ（iCD）

経済産業省が推進する、IT人材のスキル・コンピテンシーの辞書。タスクと連動したスキル体系が整理されており、日本のIT企業の人事制度設計で広く参照されている。

Googleのエンジニアリングラダー

Googleが公開しているエンジニアの等級定義は、技術力と影響範囲（個人→チーム→組織→業界）の2軸でレベルを定義しており、コンピテンシーモデルの設計に参考になる。

Radford / Mercer の Tech Job Architecture

グローバルで利用されるIT職種の報酬・等級フレームワーク。職種ごとのコンピテンシー定義が充実しており、特にグローバル採用を行う企業には有用だ。

ステップ3: コンピテンシー項目を整理する

ステップ1の社内データとステップ2の外部フレームワークを統合し、コンピテンシー項目を整理する。

実用的な項目数の目安は以下の通り。

• 大分類: 2つ（技術・ビヘイビア）

• 中分類: 各3〜5項目（合計6〜10項目）

• 行動指標: 各中分類に3〜5個の具体的な行動例

合計で30〜50個の行動指標が目安だ。これ以上増やすと、評価者の負担が大きくなり形骸化する。

ステップ4: 習熟度レベルの行動記述を作成する

各コンピテンシー項目について、L1〜L4の習熟度ごとに「具体的にどんな行動を取れるか」を記述する。

「設計・アーキテクチャ」のコンピテンシーを例にする。

L1（学習・実行）: 既存のアーキテクチャを理解し、設計ドキュメントに従って実装できる。設計レビューで質問や確認ができる。

L2（自律・応用）: 機能単位の設計を自ら行い、トレードオフを説明できる。設計レビューで代替案を提示し、建設的な議論ができる。

L3（指導・標準化）: サービス全体のアーキテクチャを設計し、非機能要件（スケーラビリティ、可用性、セキュリティ）を考慮した判断ができる。チームの設計基準を策定し、メンバーの設計力を引き上げられる。

L4（変革・牽引）: 複数サービスにまたがるシステム全体のアーキテクチャ方針を策定できる。技術的負債の解消戦略を立案し、経営層と合意形成して組織全体の技術方向性をリードできる。

ステップ5: 職種・等級ごとの期待レベルを設定する

前述の「職種・等級別の期待レベル設定」に従い、自社の等級制度と接続する。

ここで重要なのは、すべてのコンピテンシーで同じレベルを求めないこと。ジュニアに「リーダーシップL3」を期待しても意味がない。強みと成長余地のバランスが見える設計にする。

ステップ6: パイロット運用する

いきなり全社に展開すると、現場からの反発やフィードバック対応が大変になる。まず1〜2チームで3〜6か月間のパイロット運用を行い、以下を検証する。

• 評価者間で習熟度の判定にブレがないか

• 行動記述が実際の業務に即しているか

• 評価に要する時間が許容範囲か（1人あたり30分以内が目安）

• エンジニア本人が「納得感がある」と感じるか

ステップ7: フィードバックを反映して正式展開する

パイロット運用で得た改善点を反映し、全社展開する。展開時には以下を準備する。

• 評価者向けのキャリブレーション研修（評価基準の目線合わせ）

• エンジニア向けの説明会（「何のために」「どう使われるか」の理解促進）

• 運用ガイドライン（更新頻度、例外対応のルール）

3. 採用面接でのコンピテンシー評価の実践

コンピテンシーモデルの最大の価値は、採用面接の評価精度を上げることだ。スキルや経験年数だけでは見えない「入社後に成果を出せるかどうか」を、行動ベースで判断できるようになる。

行動面接（Behavioral Interview）の設計

コンピテンシーを面接で評価する最も効果的な手法が「行動面接（BEI: Behavioral Event Interview）」だ。過去の具体的な行動エピソードを聞くことで、将来の行動を予測する。

質問の作り方

各コンピテンシー項目に対して、STAR形式で深掘りする質問を用意する。

「協働・コミュニケーション」の評価例:

• 「チーム内で技術的な意見が対立した場面を教えてください。あなたはどう行動しましたか？」（Situation/Task）

• 「なぜその方法を選んだのですか？」（Action の深掘り）

• 「結果として、チームの意思決定はどうなりましたか？」（Result）

• 「振り返って、別のアプローチを取るとしたら何を変えますか？」（学習姿勢の確認）

「技術的意思決定」の評価例:

• 「技術選定で複数の選択肢から最終判断した経験を教えてください」

• 「どんなデータや根拠に基づいて判断しましたか？」

• 「その判断の結果、想定通りにいかなかった部分はありますか？どう対処しましたか？」

評価シートへの組み込み方

面接官が一貫した基準で評価するために、コンピテンシー別の評価シートを用意する。

評価シートに含める要素は以下の4つ。

• コンピテンシー名: どの行動特性を評価するか

• 質問リスト: STAR形式の質問（2〜3問）

• レベル判定基準: L1〜L4の行動記述と照合して判定

• エビデンス欄: 候補者が話した具体的な行動事実をメモする欄

よくある失敗は、「なんとなく良い印象だった」で評価してしまうこと。行動事実（何を・どう・なぜやったか）をエビデンスとして記録し、判定根拠を明確にすることが重要だ。

面接官間のキャリブレーション

複数の面接官がコンピテンシーを評価する場合、判定基準のブレが最大のリスクになる。以下のキャリブレーション手法を取り入れる。

事前キャリブレーション（面接前）

• 同じ候補者のレジュメを読み、各面接官が「この人はL何と予測するか」を事前に出し合う

• 予測のギャップがあれば、判定基準の認識合わせを行う

事後キャリブレーション（面接後）

• デブリーフ（合否判定会議）で、各面接官のレベル判定とエビデンスを突き合わせる

• 判定が割れた場合は「行動事実」に立ち返って議論する。印象ではなく事実ベースで合意形成する

面接評価の詳しい設計方法は「エンジニア採用の面接評価シート設計ガイド」も参考にしてほしい。

構造化面接との組み合わせ

コンピテンシー評価は構造化面接と組み合わせると効果が最大化する。面接ごとに「どのコンピテンシーを評価するか」を事前に割り振り、評価の重複と漏れを防ぐ。

• 1次面接（技術面接）: 設計・アーキテクチャ（L判定）、コード品質（L判定）、AI活用（確認）

• 2次面接（チームフィット）: 協働・コミュニケーション（L判定）、リーダーシップ（L判定）、オーナーシップ（確認）

• 最終面接（カルチャーフィット）: 学習・適応（L判定）、問題発見・解決（L判定）

構造化面接の設計方法は「エンジニア採用の構造化面接設計ガイド」で詳しく解説している。

4. 人事評価との接続

コンピテンシーモデルは採用だけでなく、入社後の評価制度にも接続させることで真価を発揮する。「面接で見たポイント」と「評価で測るポイント」が一致するため、エンジニアにとって「何を期待されているか」が明確になる。

評価制度への組み込み方

エンジニアの評価は一般的に「成果評価」と「行動評価」の2軸で構成されることが多い。コンピテンシーモデルは「行動評価」の軸として使う。

成果評価（What）: OKR・KPI達成度、プロジェクトの成果、技術的な貢献 行動評価（How）: コンピテンシーモデルで定義した行動特性の発揮度合い

配分は組織のフェーズにもよるが、**成果50%：行動50%か成果60%：行動40%**が一般的だ。初期スタートアップは成果重視に寄りがちだが、組織が30名を超えるあたりから行動評価の比重を上げないと、「結果さえ出せば何をしてもいい」という文化になりやすい。

評価サイクルへの組み込み

半期ごとの人事評価サイクルに、以下のようにコンピテンシー評価を組み込む。

期初（目標設定）

• 各コンピテンシーの現在レベルと期待レベルを確認

• ギャップがある項目について、具体的な行動目標を設定

期中（1on1での進捗確認）

• 月次の1on1で、コンピテンシーに関する行動の振り返りを実施（1on1の設計方法は「エンジニア組織の1on1設計ガイド」を参照）

• 「今月、設計レビューで代替案を提示した場面はあったか？」のように具体的に確認

期末（評価）

• 各コンピテンシーのレベル判定を実施

• 行動事実に基づくフィードバックを提供

• 次期の成長目標を設定

等級昇格の判定基準

「なぜあの人が昇格して自分はしないのか」。エンジニア組織で最も不満が出やすいのが昇格判定だ。コンピテンシーモデルを使えば、昇格の判定基準を客観化できる。

昇格の条件例（ミドル → シニア）:

• 技術コンピテンシー3項目以上でL3を達成

• ビヘイビアコンピテンシー2項目以上でL3を達成

• 直近2期連続で期待レベル以上の評価

• 昇格委員会でのプレゼン・質疑応答

ポイントは「すべてL3以上」ではなく、強みと弱みを認めつつ、昇格に必要な最低ラインを明確にすること。エンジニアのキャリアには多様性があり、全方位で均等に強い人はまれだ。

エンジニアの評価制度設計については「エンジニアの人事評価制度設計ガイド」でも詳しく解説している。

5. 育成・キャリア開発との接続

コンピテンシーモデルの3つ目の用途が「育成・キャリア開発」だ。「今のレベル」と「次のレベル」のギャップが可視化されるため、エンジニア自身が「何をすれば成長できるか」を具体的に理解できる。

個人育成計画（IDP）への接続

IDP（Individual Development Plan）にコンピテンシーを組み込むことで、育成が「なんとなくの成長」から「意図的な行動変化」に変わる。

IDP作成の手順:

1. 現在のレベル判定: 各コンピテンシーについて、自己評価とマネージャー評価を突き合わせる

2. ギャップの特定: 現在レベルと期待レベル（または次の等級の期待レベル）のギャップを洗い出す

3. 優先順位付け: 全ギャップを同時に埋めようとせず、四半期で1〜2項目に集中する

4. アクションプラン: 「どの行動を・いつまでに・どの場面で実践するか」を具体化する

5. 進捗確認: 月次1on1でアクションの実行状況と成果を振り返る

メンタリング・コーチングへの活用

コンピテンシーモデルがあると、メンターやコーチが「何を伸ばすべきか」を明確に把握できる。

• 強みの活用: L3以上のコンピテンシーを持つエンジニアに、その領域のメンター役を任せる

• 弱みの補強: L1のコンピテンシーがある場合、そのL3以上のメンバーとペアを組ませる

• ストレッチ機会: L2のコンピテンシーをL3に引き上げるために、意図的にチームの基準策定やレビューリードの機会を与える

キャリアパスの可視化

エンジニアにとって「この会社で自分がどう成長できるか」は、入社・定着の最重要ファクターの一つだ。コンピテンシーモデルを使えば、等級ごとの期待行動が明確になるため、キャリアパスが具体的にイメージできる。

キャリアパスの可視化で重要なのは、ICトラック（Individual Contributor）とマネジメントトラックの両方を用意すること。

ICトラック: 技術コンピテンシーを深めていく道。シニアエンジニア → スタッフエンジニア → プリンシパルエンジニアと進む。リーダーシップは「技術的な影響力」で発揮する。

マネジメントトラック: ビヘイビアコンピテンシーの比重を上げていく道。テックリード → EM → VPoEと進む。技術力は維持しつつ、「組織を動かす行動」の比重が増える。

どちらのトラックでも同等の処遇・昇格機会があることを明示することが、エンジニアの安心感と定着率につながる。キャリアパス設計の詳しい方法は「エンジニアのキャリアパス設計で採用力と定着率を高める実践ガイド」を参照してほしい。

6. AI時代に追加すべきコンピテンシー項目

2026年現在、AIコーディングツールの普及がエンジニアの働き方を大きく変えている。コンピテンシーモデルにも、この変化を反映する必要がある。

AI活用コンピテンシーの具体項目

AIとの協働（AI Collaboration）

L1: AIコーディングツール（Cursor、Copilot等）の基本的な使い方を理解し、コード補完を活用できる

L2: プロンプトを工夫してAIの出力品質を高め、出力結果を適切にレビュー・修正できる。AIに任せるべきタスクと自分で書くべきタスクを判断できる

L3: チームのAI活用ガイドラインを策定し、生産性向上のベストプラクティスを共有できる。AIの出力に潜むリスク（セキュリティ、ライセンス、品質）を体系的にチェックする仕組みを作れる

L4: AIを活用した開発プロセスの変革を主導できる。AIエージェントを活用したワークフロー設計や、AIネイティブな開発体制の構築を組織レベルで推進できる

AIリテラシー（AI Literacy）

L1: 生成AIの基本的な仕組み（LLM、プロンプト、コンテキストウィンドウ）を理解し、業務で基本的な活用ができる

L2: AIの限界と適用範囲を理解した上で、ハルシネーション対策やプロンプトエンジニアリングを実践できる

L3: チームのAI活用教育をリードし、技術選定においてAI関連ツールの評価・導入判断ができる

L4: 組織全体のAI活用戦略を策定し、AI時代のエンジニア組織のあるべき姿を定義・推進できる

既存コンピテンシーの再定義

AI活用スキルの具体的な評価方法は「エンジニア採用のAI活用スキル評価ガイド」で詳しく解説している。

AI時代には、既存のコンピテンシーの定義も更新が必要だ。

コード品質（更新）: AIが生成したコードの品質を担保する行動が加わる。AIの出力を「そのまま使わず、設計意図との整合性を検証し、テストカバレッジを確保する」行動を重視する。

設計・アーキテクチャ（更新）: AIエージェントを活用した開発を前提とした設計力が求められる。「AIが理解しやすい（コンテキストが明確な）設計」「AIが生成しやすいモジュール分割」を意識した設計行動が重要になる。

学習・適応（更新）: AI関連ツールの進化速度は極めて速い。「新しいAIツール・サービスを継続的に検証し、業務への適用可否を判断する」行動を追加する。

7. コンピテンシーモデルの運用を形骸化させない仕組み

コンピテンシーモデルの最大の失敗パターンは「作ったけれど使われない」だ。以下の仕組みで運用を定着させる。

形骸化の3大原因と対策

原因1: 項目が多すぎて評価が面倒

対策: 中分類は6〜10項目に絞る。「網羅性」より「実用性」を優先する。特に採用面接では、1面接あたり2〜3項目の評価に集中する。

原因2: 行動記述が抽象的で判定できない

対策: 「主体的に取り組む」のような曖昧な表現ではなく、「チーム定例で未解決の技術課題を自ら議題に挙げ、解決策の選択肢を提示できる」のように、観察可能な行動で記述する。

原因3: 経営・マネージャーの関心が薄い

対策: コンピテンシーデータを採用の歩留まり改善や離職率低下の指標と紐付けて報告する。「コンピテンシーL3以上で採用したエンジニアの12か月定着率は92%、L2以下は71%」のようなデータが経営層の関心を引く。

定期メンテナンスのサイクル

コンピテンシーモデルは「一度作ったら完成」ではない。以下のサイクルで定期的にメンテナンスする。

四半期: 行動記述の微修正（現場からのフィードバック反映） 半期: 期待レベルの見直し（等級制度の変更との連動） 年次: コンピテンシー項目の追加・削除（技術トレンドや事業戦略の変化を反映）

特に2026年はAI関連のコンピテンシーが急速に変化しているため、AI活用コンピテンシーは四半期ごとの見直しを推奨する。

ツール・テンプレートの整備

運用を効率化するために、以下のツールを整備する。

• コンピテンシーマトリクスシート: チームメンバー×コンピテンシー項目×レベルを一覧化するスプレッドシート

• 面接評価シートテンプレート: コンピテンシー項目・質問・判定基準・エビデンス欄のテンプレート

• IDP テンプレート: 個人育成計画のフォーマット（現在レベル・目標レベル・アクションプラン）

• キャリブレーションガイド: 評価者間の目線合わせのための事例集

これらをConfluenceやNotionのような社内ドキュメントツールにまとめ、全員がアクセスできる状態にしておく。

8. 導入企業でよくある課題と解決策

コンピテンシーモデルの導入は一筋縄ではいかない。多くの組織が直面する課題と、その実践的な解決策を整理する。

課題1: エンジニアからの反発

「また人事の施策か」「数値化できない行動を評価されるのは不公平だ」。エンジニアからこうした声が上がるのは珍しくない。

解決策:

• 導入の目的を「管理・監視」ではなく「キャリア成長の支援」として明確に伝える

• エンジニアのテックリードやEMに設計段階から参加してもらい、当事者意識を持たせる

• 最初は評価ではなく「自己診断ツール」として導入し、心理的ハードルを下げる

課題2: 評価者間のレベル判定のブレ

同じ行動を見ても、面接官AはL2、面接官BはL3と判定するケースが起きる。

解決策:

• 各レベルの行動記述に「具体的な行動事例（アンカー）」を3つ以上用意する

• 四半期に1回、過去の候補者・メンバーの行動事例を使ったキャリブレーションセッションを実施する

• 判定に迷ったら「下のレベル」を選ぶルールを設ける（判定基準の引き締め）

課題3: 職種の多様性への対応

フロントエンド、バックエンド、SRE、データエンジニア、MLエンジニア。エンジニアの職種は多様で、「全職種に同じコンピテンシー」は無理がある。

解決策:

• ビヘイビアコンピテンシーは全職種共通にする（協働・リーダーシップ・学習姿勢は職種を問わない）

• 技術コンピテンシーは「共通項目（60%）」と「職種固有項目（40%）」に分ける

• 職種固有項目の設計は、各職種のテックリードに委任する

課題4: 小規模チームでの運用

5名以下のエンジニアチームでは、「フルスペックのコンピテンシーモデルは大げさ」という意見もある。

解決策:

• 項目数を絞り、技術3項目×ビヘイビア3項目の計6項目でスタートする

• 習熟度も3段階（できない/できる/教えられる）に簡略化する

• スプレッドシート1枚で管理できる軽量版を作る

• 組織が10名を超えたら、正式版に移行する

FAQ（よくある質問）

Q1: コンピテンシーモデルの導入に、どれくらいの期間がかかりますか？

設計に1〜2か月、パイロット運用に3〜6か月が目安だ。ただし、既存の評価制度やスキルマップがある組織はそれらを活用できるため、設計期間を短縮できる。小規模チーム（10名以下）であれば、2週間の集中ワークショップで初版を作ることも可能だ。

Q2: コンピテンシーモデルとスキルマップは両方必要ですか？

理想的には両方あるとよい。スキルマップは「何ができるか」、コンピテンシーモデルは「どう振る舞うか」を測る。片方だけでも効果はあるが、両方を組み合わせると採用・評価の精度が大幅に上がる。リソースが限られる場合は、まずコンピテンシーモデルから始めることを推奨する。行動特性は技術トレンドに左右されにくく、長期間使えるためだ。

Q3: エンジニアの等級（グレード）とコンピテンシーレベルはどう対応させますか？

等級ごとに「期待レベル」を設定する方法が一般的だ。たとえばミドルエンジニア（等級3）であれば、技術コンピテンシーの主要項目がL2〜L3、ビヘイビアコンピテンシーがL2以上、のように設定する。ただし「全項目で期待レベル以上」を昇格条件にすると達成が難しすぎるため、「主要項目の70%以上で期待レベル達成」のような柔軟な基準が現実的だ。

Q4: 中途採用と新卒採用で、コンピテンシー評価の方法は変わりますか？

変わる。中途採用では「過去の行動事実」を聞く行動面接が有効だ。一方、新卒採用では業務経験が少ないため、「学業やプロジェクト活動での行動」「仮想シナリオへの対応」で評価する。新卒の場合は「現在のレベル」よりも「伸びしろ（学習・適応のコンピテンシー）」を重視するのがポイントだ。

Q5: コンピテンシーモデルを外部に公開するメリットはありますか？

ある。採用ブランディングの観点で、「自社がエンジニアに何を期待し、どう評価するか」を透明化することは大きなアドバンテージになる。候補者は「入社後のキャリアパスが見える会社」に魅力を感じる。GitLabやBuffer、Artsy（オープンソース企業）のように、エンジニアリングラダーを公開している企業は、採用力が高い傾向にある。

Q6: AI時代のコンピテンシーモデルはどのくらいの頻度で更新すべきですか？

AI関連のコンピテンシーは四半期ごとの見直しを推奨する。AIツールの進化速度は極めて速く、半年前のベストプラクティスが陳腐化することも珍しくない。一方、ビヘイビアコンピテンシー（協働・リーダーシップ等）は年次の見直しで十分だ。技術の変化は速くても、「チームで成果を出す行動」の本質はそれほど変わらない。

Q7: コンピテンシーモデルを採用面接で使う場合、候補者に事前に共有すべきですか？

共有することを推奨する。候補者に「面接で何を評価するか」を事前に伝えることで、候補者が適切なエピソードを準備でき、面接の質が上がる。「準備してきたら正確に評価できない」と懸念する声もあるが、コンピテンシーは「実際に取った行動」を評価するため、準備で偽装しにくい性質を持っている。

まとめ: コンピテンシーモデルで採用・評価・育成をつなぐ

エンジニア組織のコンピテンシーモデルは、「採用で見るポイント」「評価で測るポイント」「育成で伸ばすポイント」を一つの物差しでつなげるフレームワークだ。

導入のポイントを振り返る。

• 技術コンピテンシーとビヘイビアコンピテンシーの2軸で設計する

• 4段階の習熟度を「観察可能な行動」で記述する

• 職種・等級ごとの期待レベルを設定し、全員に全項目L4を求めない

• **採用面接では行動面接（BEI）**でコンピテンシーを評価し、エビデンスを記録する

• 人事評価・育成計画・キャリアパスに接続させて運用を定着させる

• AI時代の新しいコンピテンシー（AI協働・AIリテラシー）を追加する

• 形骸化を防ぐ仕組み（定期メンテナンス・キャリブレーション・ツール整備）を整える

コンピテンシーモデルは一度作って終わりではなく、組織の成長とともに進化させていくものだ。まずは小さく始めて、パイロット運用から全社展開へと段階的に広げていくことが成功の鍵になる。

techcellarでは、エンジニア採用の要件定義から選考設計、評価制度の構築まで一貫した支援を行っている。コンピテンシーモデルの設計や運用についてお困りの方は、ぜひお問い合わせページからご相談いただきたい。