スキルをどう証明するか？ コンピテンシー証拠の6段階モデル

Skills First は、学歴や肩書きといった形式的なラベルより、本人が実際に示せる能力へ焦点を移す考え方です。ただし、それだけで能力の評価方法が自動的に解決されるわけではありません。

OECD は skills-first を、採用や人材マネジメントにおいて、実証されたスキルに基づいて人を評価するよう実務を調整するアプローチとして説明しています。また、適切な評価ツールやスキルフレームワークの必要性も指摘しています。 [1]

したがって、"Education" を長い "Skills" リストに置き換えるだけでは不十分です。なぜそのスキルの主張を信頼できるのか を示す方法も必要です。

同じスキルを記載している二人でも、実務経験は大きく異なることがあります。

例えば二人の専門家が次のように記載しているとします。

Angular - 上級

一人目はコースを修了し、個人プロジェクトをいくつか作り、framework の基本を理解しています。

二人目は3年間 production application を開発し、システムの一部アーキテクチャを担当し、Angular のバージョン間 migration を行い、具体的な成果を示せます。

通常のスキル一覧では、二人はほとんど同じに見えるかもしれません。

違いを示し始めるのは 文脈を持つ証拠 です。

このモデルは、人に共通の点数を付けるためのものではありません。職種によって生まれる証拠の種類は異なり、すべてのプロジェクトを公開できるわけでもありません。

目的は、より単純な問いに答えることです。

ある能力を信頼できる形で示すための材料は、どの程度強いのか？

最も基本的なのは本人による自己申告です。

例:

• Angular
• Figma
• SEO
• チームリーダーシップ
• B2B交渉

検索や discovery には役立ちますが、証拠としての強さは限定的です。

まだ次のことが分かりません。

• どこで使ったか,
• どのくらいの期間使ったか,
• どの規模で使ったか,
• どの程度の責任を持ったか,
• どんな結果につながったか

自己申告は評価の出発点であり、終点ではありません。

そのスキルを どこで、どのような文脈で使ったか が分かると、証拠は強くなります。

単に:

Angular

ではなく:

物流業界向け SaaS application の開発で Angular を2年間使用。

これだけでは仕事の品質を証明しませんが、重要な文脈が加わります。

• 実際のプロジェクト,
• 使用期間,
• 適用領域,
• 環境の性質

この段階で、スキルは単なるラベルではなくなります。

次の段階は、自己申告と経験を 実際の成果物 に結びつけられる場合です。

職種によって、次のようなものが考えられます。

• 動作する application,
• code sample,
• repository,
• interface design,
• prototype,
• report,
• analysis,
• campaign,
• article,
• documentation,
• financial model,
• photograph,
• engineering design,
• 完了した仕事の記録

成果物は重要な問いに答えます。

このスキルを使って実際に作られたものを見ることができるか？

これは portfolio が正式な能力テストであるという意味ではありません。一方、人材選抜の研究では、work samples や職務知識テストなど、実際の仕事に近い方法がパフォーマンスの有用な予測指標になり得るとされています。また、結果は文脈、コスト、各手法の限界を踏まえて解釈する必要があります。 [2]

成果物があっても、重要な問いが残ることがあります。

この人は具体的に何をしたのか？

チームプロジェクトでは特に重要です。

Application は20人で作ったかもしれません。Campaign は8人のチームかもしれません。Rebranding には agency、社内 marketing、外部 consultant が関わっているかもしれません。

そのため、より強い証拠は 個人の貢献を明確にした case study です。

少なくとも次を分けて書くべきです。

• 問題または目的,
• プロジェクト全体の範囲,
• 本人の責任,
• 実際に行ったこと,
• 使用した能力,
• 他者との協働,
• 結果

例えば:

E-commerce platform を作りました。

よりも:

Frontend architecture、checkout implementation、payment-flow integration を担当しました。プロジェクトは5人のチームで実施しました。

後者の方が、チーム全体の仕事を一人の成果として扱わないため、より有用です。

仕事が 具体的な結果 につながり、それを曖昧な表現なしで説明できると、証拠はさらに強くなります。

例:

Frontend
メイン画面の読み込み時間を4.2秒から1.8秒に短縮。

UX
登録フローの再設計後、フォーム離脱を減少。

Marketing
同程度の traffic quality を維持しながら cost per lead を低減。

Sales
新しい customer segment を開拓し、一定数の契約を獲得。

Operations
数日かかっていたプロセスを数時間に短縮。

すべての職種で結果を割合や金額にする必要はありません。プロフィールを良く見せるために metric を作り出すべきでもありません。

重要な問いは:

この仕事によって何が変わったか？

最も強い段階は、情報の少なくとも一部を プロフィール所有者の自己申告とは独立して検証できる 場合です。

例えば:

• 公開プロジェクト,
• contribution history のある repository,
• 公開出版物,
• プロジェクト参加の確認,
• 合法的に公開できる顧客または同僚の reference,
• 独立して確認できる結果,
• 実際に関連する official credential,
• 特定の仕事を確認する別の情報源

すべてのプロジェクトを公開する必要はありません。

多くの重要なプロジェクトは NDA、営業秘密、その他の守秘義務の対象です。

したがって、公開証拠がないことは 能力がないことを意味しません。

独立検証の程度が低いという意味にすぎません。

レベル1 - 自己申告
Angular。

レベル2 - 文脈
SaaS applications で3年間 Angular を使用。

レベル3 - 成果物
公開 application、repository、その他表示可能な work sample。

レベル4 - 個人の貢献
特定 module の architecture、shared components、application migration を担当。

レベル5 - 結果
Optimization により main module の startup time を4.2秒から1.8秒に短縮。数値は例示です。

レベル6 - 検証
結果と貢献は、公開 project、change history、reference、その他の独立した情報源で追加確認できます。

同じ段階の証拠でも価値は大きく異なります。5つの追加観点が質の解釈に役立ちます。

1. 関連性 - 証拠は評価したい能力に本当に関係しているか？

2. 新しさ - いつ使われ、その分野で最近の経験はどれほど重要か？

3. 本人の貢献と責任 - 実際に何をしたか分かるか？

4. 文脈 - 規模、複雑さ、責任、資源、労働条件はどうだったか？

5. 検証可能性 - 情報の一部でも独立して確認する方法があるか？

関連性

技術を少しだけ使ったプロジェクトは、その能力が中心だったプロジェクトより弱い証拠です。

新しさ

重要性は分野によって異なります。10年前の経験でも高い価値がある分野もあれば、ツールや実務が急速に変化する分野もあります。

本人の貢献と責任

プロジェクトやチームが大きいほど、全体成果と個人の貢献を分けることが重要です。

文脈

同じ結果でも、規模、期限、資源、責任、課題の複雑さによって重みが変わります。

検証可能性

独立検証は常に可能でも、常に必須でもありません。ただし独立情報源が結果や貢献を確認できれば、信頼性は高まります。

本人が担当部分を非常によく実行していても、プロジェクト全体はビジネス上失敗することがあります。

逆に、大成功したプロジェクトに参加していても、最終的な成功への影響は小さい場合があります。

そこで3つを分けます。

1. 能力
その種類の仕事ができるか？

2. 貢献
どの部分を実際に担当したか？

3. 結果
その仕事で何が変わったか？

3つを組み合わせることで、より完全な理解ができます。

Certificate やその他の formal credential は有用な証拠になり得ますが、価値は 実際に何を確認し、どのように取得されたか によります。

例えば:

• training 修了,
• 定義された learning outcomes の達成,
• 特定の assessment の合格,
• standard の知識,
• formal requirements の充足

European Commission は micro-credentials を短期の学習体験によって得られた learning outcomes の記録として説明し、透明性と品質を重視しています。 [3]

Certificate を、実際の職場で複雑な仕事を独立して行えることの自動的な証明とみなすべきではありません。

したがって credential は 証拠になり得る要素の一つ であり、その意味は文脈に依存します。

プロジェクトを公開できないからといって、価値ある経験が消えるわけではありません。

ただし NDA、守秘義務、営業秘密、著作権、データ保護のルールは、portfolio を見せたいという希望より優先されます。

専門家は、契約、適用法、他者や組織の権利が許す範囲でのみプロジェクトを説明するべきです。顧客名を削除するだけでは、他の情報からプロジェクト、顧客、技術、成果、秘密の方法が特定できる場合があります。

開示が許される場合でも、次のように十分一般化して説明します。

• 業界,
• 機密情報を含まない課題の性質,
• 自分の役割と責任,
• 使用した能力,
• 許可された範囲の規模,
• 保護されたデータを含まない結果の種類,
• 十分に一般化したアプローチ

公開できるか不明な情報は、契約を確認するか権利者の許可を得るまで開示しない方が安全です。

能力証拠の仕組みを、すべての職種が software development であるかのように設計すべきではありません。

Designer は process、design decisions、prototype、結果を示せます。

Developer は product、code、architecture、technical responsibility を示せます。

Marketer は campaign、approach、responsibility、結果の変化を示せます。

Sales professional は顧客の機密データを公開せずに market segment、sales process、自分の役割、結果を説明できます。

Project Manager は project scope、仕事の組織化、制約、delivery への影響を示せます。

Photographer は人工的な KPI を作らずに完成作品を示せます。

原則は共通でも、証拠の種類は柔軟であるべきです。

1. その能力が実際にどこで使われたか確認する。

2. 成果物や具体的な実行例を探す。

3. 専門家本人の貢献とチーム全体の仕事を分ける。

4. 意味のある形で説明できる場合は結果を見る。

5. 経験の新しさと、解決したい課題との類似性を評価する。

6. 可能で適切な場合は独立した確認を探す。

これにより、評価はプロフィールのキーワードから 実証された能力と具体的なニーズの実際の適合 へ移ります。

このモデルは情報を整理し、人間の判断を支えるためのものです。採用、候補者の拒否、業務開始を自動的に決める判定として使うべきではありません。

すべての能力にレベル6の証拠が必要なわけではありません。

重要なスキルごとに次を確認する方が有用です。

• どこで使ったか？
• どんな問題を解いたか？
• 具体的に何をしたか？
• 成果物があるか？
• 結果は何だったか？
• 機密性を損なわず説明できるか？
• 自分の貢献を確認できる人や情報源があるか？

例えば:

Figma - 上級

から:

B2B application の onboarding flow を設計し、research、prototyping、usability testing、final design system を担当しました

に変えるだけでも、プロフィール情報の質は大きく向上します。

Skills First は、"skill" が単なる tag 以上の意味を持つときに初めて価値を持ちます。

能力を専門家の発見や比較の主要な軸にするなら、可能な限り良い文脈と結びつけるべきです。

experience -> portfolio -> individual contribution -> outcome -> verifiability.

すべての能力が最高レベルに達する必要はありません。

目的は、プロフィール項目ごとに官僚的な負担を作ることではありません。

専門家が なぜそのスキルの主張を信頼できるのか を説明でき、専門性を探す人がより良い情報に基づいて判断できるようにすることです。

1. 自己申告だけでなく具体性 - どこで、どのように能力を使ったか示す。

2. チーム全体の成功ではなく個人の貢献 - 自分の仕事と組織全体の結果を分ける。

3. タスク一覧ではなく結果 - 可能なら仕事によって何が変わったか示す。

4. 数字だけでなく文脈 - 条件のない metric は誤った結論につながる。

5. 可能な範囲で検証 - 独立した確認は信頼性を高めるが、それがないからといって能力が否定されるわけではない。

プロフェッショナルプロフィールは、スキル一覧の背後に何があるのかを読者に推測させるべきではありません。

自己申告は能力を見つける助けになります。証拠は能力を理解する助けになります。

6段階は次の流れにまとめられます。

1. できると述べる。
2. どこで使ったか示す。
3. 何を作ったか示す。
4. 具体的に何をしたか説明する。
5. 結果を示す。
6. 可能な場合は独立した確認を可能にする。

答えられる問いが多いほど、自己申告だけに依存する必要は減ります。

そのとき Skills First は、プロフィールの情報順を変えるだけの考え方ではなくなります。

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
出典を開く

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
出典を開く

[3] European Commission - A European approach to micro-credentials
出典を開く

方法論上の注記: [1]-[3] は Skills First、能力評価、credential に関する広い文脈を提供するものです。コンピテンシー証拠の6段階モデル自体は本稿で提示する独自の概念モデルであり、これらの出版物の研究成果として提示しているものではありません。