この記事はQiitaTechFesta2025参加記事です。
株式会社うるる人事部にて人事マネージャーをしています。
採用・組織開発領域を主に担当しています。
採用を始めたはいいものの、「なんだかターゲットがマッチしていないかもしれない…」と感じることってありますよね。
その原因として意外と多いのが、求めるスキルが曖昧なままスタートしてしまっているというケースです。（私自身もしょっちゅう反省。。）
採用の現場では、スキルの定義や期待値のすれ違いが、ミスマッチを生むこともしばしば。
だからこそ、スキルを言語化し、構造化することで、お互いの理解と納得感を深めていけるはずです。
でも、それは採用の場面に限った話ではありません。
キャリアに迷ったときや、評価に納得しきれないときなど、私たちには日々、スキルという言葉に向き合わざるを得ないシーンが多くあります。
そこで今回は、スキルを「特定の仕事にあてはめ、要素ごとに分解してみる」というアプローチを通じて、自分の現在地と可能性を、よりクリアに捉える試みをしてみたいと思います。
スキルとは、知識・経験・態度・判断力などが組み合わさった、実際の業務で活かすための「実践的な能力」のことを指します。
たとえば「課題解決力」といっても、その裏には「論理的思考」「関係者との対話」「状況把握能力」など、複数の構成要素が含まれています。
よく目にするフレームは以下のあたりでしょうか。
◾ カッツ理論：3つのスキル領域
まず、アメリカの経営学者ロバート・カッツが提唱した「カッツ理論」では、マネジメントにおけるスキルを次の3つに分類しています。
- テクニカルスキル
- 実務の専門性や手法、知識に関するスキル
- 例：プログラミング、製品知識、ツール操作等々。
- ヒューマンスキル
- 他者と効果的にコミュニケーションを取り、協働する能力。
- 例：巻き込み力、共感力、ファシリテーション、フィードバックなど
- コンセプチュアルスキル
- 全体像を理解し、戦略や課題の本質を捉える能力。
- 例：市場分析に基づく戦術立案、プロジェクトの進行管理、施策設計等
この理論では、職位が上がるほどテクニカルよりもコンセプチュアルスキルの比重が高まるという点がポイントです。
たとえば、オペレーションに強い担当者と、戦略を描くリーダーとでは、求められるスキルの構成が異なるのは納得感がありますし、人事評価制度の設計にもよく用いられる印象です。
あとは「ハード / ソフト」なども、よく分類の軸として用いられますよね。
- ハードスキル（技術的スキル）
- 例：プログラミング、英語力、簿記、機械操作、データ分析など
- 特徴：学習や訓練によって身につけやすく、証明しやすい（資格、成果物）
- ソフトスキル（対人・思考系スキル）
- 例：コミュニケーション力、リーダーシップ、問題解決力、チームワークなど
- 特徴：数値化が難しいが、仕事や人間関係でとても重要
ではスキルを分解したとして。得られるメリットはどんなものでしょうか。
- 採用時に「何を見極めるべきか」が明確になる
- 面談での深掘り質問が設計しやすくなる
- 評価や育成時に「何が足りないのか」が具体化される
などは浮かびやすいです。
しかし、スキルを意識するのは単に「評価や採用などの機会がある時だけ」ではなく、日頃から自分のスキルを自己認識できたら、もっと活用できるシーンが増えていくのではないかと思います。たとえば以下のような好影響が期待できそうです。
- 強みを発揮した仕事による成果の創出
- チーム内で共通言語として扱い、チームビルディングに用いる
- ジョブ・クラフティング（自分の仕事の形を自分でデザインし、やりがいにあるものに変えていく手法）
私自身、組織開発を担当する中でジョブ・クラフティングに興味を持ち、社内で何度かワークショップも主催してきました。
そこで感じるのは、
「自分の強みを正しく認識し、組織のミッションを理解して重ね合わせ、そのギャップを埋める工夫をしていくこと」
ができれば、働く人にとって「楽しく働けて、成長もできて、成果も出せる」という良いサイクルを生み出せる可能性が高いのではないかということです。
これは一見、理想論のようにも思えますが、実際には理にかなったアプローチだと考えています。
たとえば「エンジニア採用担当」という職種でも、求められるスキルは会社・フェーズによって異なります。
ここでは、「カッツ理論（テクニカル・ヒューマン・コンセプチュアル）」の枠組みを応用し、ChatGPTに頼ってエンジニア採用担当者に求められるスキルを分解してみました。
| レベル | テクニカルスキル（技術的） | ヒューマンスキル（対人関係） | コンセプチュアルスキル（概念・戦略） |
|---|---|---|---|
| ジュニア（担当初級） | – 技術用語に慣れる（言語、フレームワーク、開発手法など） – 求人票の更新／修正ができる – 採用媒体やスカウトツールの操作 |
– 候補者とのやり取りが丁寧にできる – エンジニア現場の依頼に従い、求人対応ができる |
– 職種理解や採用の背景に少しずつ触れ始める – 言われた要件に沿って対応できる |
| ミドル（自走レベル） | – 技術要件・開発環境をヒアリングし、求人票に落とし込める – スカウト文面を職種に合わせて書き分けられる – GitHub/LinkedInでの候補者探索ができる |
– エンジニアと対等に会話できる基礎知識がある – 候補者に対して職種の魅力を伝えられる – 面接評価や現場の声を適切にフィードバックに活かせる |
– 事業フェーズ・技術スタックに応じた採用要件を整理できる – 選考フローやチャネル選定の改善提案ができる |
| シニア（戦略実行者） | – 職種ごとのペルソナやスキルマップを設計できる – 技術領域に応じたチャネル活用・面接設計ができる – エンジニアブログ・イベントなど採用広報も主導 |
– 現場リーダー・技術マネージャーとの関係を築き、信頼されるパートナーになる – 候補者に対して技術や組織の深い魅力づけができる |
– 「どのようなエンジニアを、なぜ、今、採用するのか」を戦略的に説明できる – 技術組織の課題に応じた採用方針・指標設計ができる |
| リーダー（戦略設計者） | – 年間のエンジニア採用計画を策定・推進できる – 組織横断の採用広報、技術発信施策を企画・リード – 採用チーム・面接官体制の設計・育成 |
– VPoE/CTO/PMとの信頼関係を築き、経営レベルで採用を進行できる – エンジニア組織の課題を抽象度高く言語化し巻き込める |
– 事業戦略・技術戦略と採用戦略を接続して描ける – DE&I（多様性・公平性）やカルチャーフィットを踏まえた設計ができる |
今回は自社の定義に落とし込んだわけではないので、ざっくりした内容ではありますがなんとなくイメージはずれていないと思います。
たとえば人事評価のシーンを想定してみても、
成果評価・コンピテンシー評価・目標管理制度（MBO）・360度評価など、各社様々な評価の仕組みを用いていますが、大体の評価は項目ごとにマルバツを付けていけば済むようなものではないですよね。
全職種において、細かく職種ごとに定義されたものが用意されていることもないでしょう。
そのため「自分の職位に求められる各業務のレベル感を、構成要素ごとに正しく把握できるか」という点は、期待値を認識し、自分の現在地を把握するうえで重要なポイントになりそうです。
構成要素を業務軸で整理してレーダーチャート化するのもいいですね。
（※要素とポイント数は、本記事用に適当に入れたものです）
チーム内で可視化してみると、チームの強み分布がよくわかりそうですし、チームに足りていない部分のところに強みを持つ人を採用したい…という整理をするときにも活用できそうです。
「スキルを要素分解する」ことで、スキルは“感覚的なもの”から“扱える情報”へと変化するはずです。
それは、採用の精度を高めるだけでなく、評価の納得感や、育成の方向性にもつながると考えています。
まずは自分の担当業務において試してみるのはもちろんのこと、昇格したとき・新たな業務へ手を伸ばすときなども整理してみると、周囲との期待値のすり合わせができてよいかもしれません。
誰かの可能性を見出すためにも、自分の可能性に期待し続けるためにも。
スキルの言語化にこだわって仕事をしてみたら、新たな世界が見えるかもしれません！
Views: 0
