AI時代のシステム会社における人事評価制度のあり方
結論
AI時代のシステム会社では、「現在の仕事で何を達成したか」という Performance と、「将来どのような仕事を担える状態になったか」という Capability を分けて評価する必要がある。さらに、個人の知識を教育、レビュー、標準化へ転換した Organizational Contribution も別に見る。現在の成果を軽視する話ではない。成果だけを価値とみなす前提を改める話なのだ。
資格は評価する。ただし、資格数をそのまま点数へ変換しない。資格は知識を裏付ける Skill Evidence の一つとし、Lab、技術試験、ケース演習、PoC、設計レビュー、実案件、知識共有などと組み合わせて、能力の深さ、広さ、実証可能性、最新性、応用可能性を判定する。
評価だけを変えても学習は組織能力にならない。確認したSkillを社内で検索できるようにし、短期プロジェクト、兼務、レビュー、PoC、社内公募へ接続する必要がある。目指す循環は次のとおりである。
Learning → Recognition → Opportunity → Application → Contribution → Further Learning
なぜ、いま評価制度を変えるのか
世界経済フォーラムの『Future of Jobs Report 2025』は、2030年に向けて重要性が増す能力として、AI・Big Data、ネットワーク・サイバーセキュリティ、技術リテラシーだけでなく、創造的思考、レジリエンス、柔軟性、好奇心、生涯学習を挙げている。1 経済産業省とIPAのデジタルスキル標準ver.2.0も、生成AIの活用を含むデジタル技術を、事業や組織の文脈で扱う人材像を示している。2
SFIA 9のLearning and Developmentは、個人が知識不足を認識して学ぶ段階から、新しい知識を批判的に評価し、他者へ共有し、標準へ反映し、組織の学習文化を形成する段階までを扱う。3 学習は業務の外側にある善行ではなく、職務能力の一部として捉えられているのだ。
生成AIは知識作業を一様に自動化するわけでもない。Dell'Acquaらが758人のコンサルタントを対象に行った実験では、AIの能力範囲内にある課題で速度と品質が改善した一方、能力範囲外の課題では正答率が低下した。4 また、顧客サポート担当者5,172人を扱った研究では、生産性向上の平均効果が確認されたものの、効果は経験やSkillによって異なり、単一企業・単一職種の結果を全業務へ一般化できないとされている。5
したがって価値を持つのは、知識量やAI利用回数だけではない。新しい知識を学び、問題を設定し、AIを使う境界を判断し、出力を検証し、未経験の問題へ知識を転用する能力である。これはLearning AgilityとAdaptive Performanceを重視する方向への変化と整理できる。67
従来制度の「担当業務依存」
一般的な評価は、担当業務、目標設定、成果、評価という順に進む。この構造では、会社が割り当てた仕事が、社員に証明可能な能力の範囲を決める。
たとえばJavaの業務システムを担当する社員が、AI、Cloud、Data Analytics、Securityを自主的に学んでも、その知識を使う案件がなければ業務成果には現れない。すると、「使う機会がない」「成果を作れない」「評価されない」「学ぶ意味がない」という循環ができる。社員が現在の仕事に必要な能力だけを学ぶのは、制度に対する合理的な適応なのだ。
この制度は、既存技術の習熟や効率化を表す Exploitation を強くし、新技術や隣接分野を試す Exploration を弱くする。Marchは、既存知識の活用が探索より速く改善されるため、短期的には有効でも、長期的には自己破壊的になり得ると論じた。8
現在使っていないSkillは、無価値なのではない。CohenとLevinthalが示した Absorptive Capacity、つまり外部知識の価値を認識し、理解し、利用する能力は、既存の関連知識に依存する。9 生成AI、Cloud Native、PQCなどを理解する社員がいれば、変化が起きたときに意味を早く認識し、採用の要否を判断できる。担当外Skillは、将来の選択肢を増やす未使用資産として扱えるのだ。
3つの評価領域を分ける
一つの総合点ですべてを処理すると、異なる価値が相殺される。少なくとも評価会議では、次の3領域を分けて見る。
| 評価領域 | 評価するもの | 主なEvidence |
|---|---|---|
| Performance | 現在担当する業務の成果 | 品質、生産性、顧客価値、納期、プロジェクト成果 |
| Capability | 現在または将来に発揮できる能力 | 資格、試験、Lab、ケース演習、PoC、設計、実務 |
| Organizational Contribution | 個人の知識を組織へ波及させた程度 | 教育、レビュー、標準、Tool、Guide、他部署支援 |
3領域を完全に別制度へする必要はない。ただし、業務成果がないことを理由にCapabilityまでゼロと判定しない。反対に、将来性だけで現在のPerformance不足を覆い隠さない。評価結果は一本の順位ではなく、3軸のProfileとして残す方がよい。
評価比率は全員一律にしない。Delivery中心、Expert中心、探索・企画中心など、Role Familyごとに期待配分を定義する。ただし、期中に会社都合で担当が変わった場合は配分も見直す。本人が制御できないアサインで評価が固定されないようにするためである。
Skillは「証拠の束」で確認する
Skillは完全な数値化にも、上司の印象だけにも向かない。定量情報と定性情報を組み合わせる。
| 観点 | 確認する内容 | Evidenceの例 |
|---|---|---|
| Knowledge | 知識を持っているか | 資格、試験、研修修了 |
| Demonstration | 自力で扱えるか | Hands-on、Lab、技術試験 |
| Application | 現実的な問題へ適用できるか | PoC、設計、Code、分析 |
| Transfer | 別の問題へ転用できるか | Case演習、技術提案、比較評価 |
| Breadth | 隣接領域を理解しているか | 複数領域のProfile |
| Depth | 複雑な判断が可能か | 設計Review、専門判断 |
| Currency | 知識が現在も有効か | 最近の活動、更新、再認定 |
| Sharing | 他者へ移転できるか | 勉強会、教育、Review |
| Leverage | 組織能力へ変換したか | 標準、Tool、Guideline |
たとえばAWS資格はKnowledgeの有力な証拠になるが、設計能力のすべては証明しない。そこで、資格、Lab、Architecture Review、PoC、実案件、標準化という異なるEvidenceを積み重ねる。
重要なのは、実案件を唯一の入口にしないことである。仕事のアサインは本人だけでは制御できない。Lab、社内技術試験、Case Study、PoC、Peer Reviewを代替経路として用意すれば、「仕事を与えられていないから能力を証明できない」という不公平を減らせる。研修内容を別の課題へ移すには、本人の特性だけでなく、支援的な職場環境も関係することがTraining Transferのメタ分析で示されている。10
6段階のSkill Level
資格数を加算するより、確認できた能力レベルを管理する方がよい。
| Level | 状態 | 判定例 |
|---|---|---|
| 0 | 未確認 | 関心や自己申告のみ |
| 1 | Knowledge | 資格、研修、試験で基礎知識を確認 |
| 2 | Demonstrable | Labや技術試験を自力で完遂 |
| 3 | Applicable | 現実的な問題へ適用し、判断根拠を説明 |
| 4 | Advanced | 複雑な問題を設計・Reviewし、例外を判断 |
| 5 | Multiplier | 他者育成、標準化、組織展開を主導 |
資格を持つが実務経験がない場合もLevel 1として認識する。個人環境で構築し、社内審査で再現性が確認できればLevel 2に進める。資格がなくても、高度な設計や専門判断のEvidenceがあればLevel 3や4になり得る。資格の有無とSkill Levelを混同しない設計なのだ。
Levelには有効期限ではなく Currency Check を付ける。技術の変化速度、法令・規格の更新、実務から離れた期間を踏まえ、最近の活動が確認できなければ「失効」ではなく「再確認が必要」と表示する。古い認定をゼロ扱いするのではなく、確証の強さを下げる。
資格コレクター問題をどう解くか
結論は「資格は評価する。しかし資格数を評価しない」である。
資格取得には、テーマ選定、教材探索、時間確保、継続学習、受験、一定水準の突破が必要であり、自律的学習行動のEvidenceになり得る。一方で「資格1件につき○点」とすれば、Skillではなく取得数の最適化が始まる。同一領域の類似資格を複数取得した場合は点数を累積せず、その領域のKnowledge Evidenceを補強または更新する。
| 人物 | 確認できること | 評価 |
|---|---|---|
| A:AWS資格10件、構築Evidenceなし | AWS領域の広いKnowledge | Level 1の確証を高める。10倍にはしない |
| B:AWS資格1件、Terraform Lab、設計Reviewあり | KnowledgeとDemonstration/Application | Level 2または3を審査 |
| C:AWS、Security、AIの資格、担当業務では未使用 | Skill PortfolioのBreadth | PerformanceではなくCapabilityで認識 |
DepthとBreadthも一本の点数へ潰さない。一領域でLevel 5のExpertと、三領域でLevel 3のConnectorは、異なる組織価値を持つ。Cloud × Security、AI × Software Development、Data × Domain Knowledgeのように領域を接続できる人材は、AI時代の問題設定と検証で重要になる。
動機を壊さない制度にする
自己決定理論では、自律的な動機形成にAutonomy、Competence、Relatednessが重要とされる。11 「指定資格を取れ」「年間40時間学べ」「3資格未満は減点」といった制度は、学習を会社による統制へ変えやすい。
制度が行うべきことは、社員を勉強させることではない。本人がCareerと会社の方向性を踏まえてテーマを選び、会社が時間、教材、環境、Feedbackを提供し、獲得した能力を認識し、利用機会へつなぐことである。Choice Theoryの「他者を直接統制できる範囲は限られ、本人の選択と責任を支援する」という考え方とも整合する。12
外発的動機を完全に排除する必要もない。183研究、212,468人を扱ったメタ分析では、内発的動機と外発的IncentiveはともにPerformanceを予測し、内発的動機は成果の質、Incentiveは量との関係が相対的に強かった。13 試験費用補助、学習時間、認定、表彰は学習開始を支援できる。問題は「資格を取れば昇進」のように、報酬が学習目的を置き換えることなのだ。
評価では、他者より資格が多いかではなく、以前より何ができるようになったかを見る。Goal Orientationのメタ分析でも、Learning Goal Orientationは学習戦略、Feedback探索、学習、Task Performanceと正の関係を持つ。14
失敗した探索もEvidenceにする
新技術のPoCは失敗する。調査の結論が「採用しない」になることもある。成功だけを評価すると、社員は成功が保証された活動しか選ばなくなる。
適切な仮説、比較基準、検証環境、結果、再現条件、次の判断が残っているなら、不採用という結論にも価値がある。Edmondsonの研究では、Team Psychological SafetyがLearning Behaviorと関連した。15 未知の技術を試した人が、失敗を隠さず共有できることも制度の一部なのだ。
ただし、努力しただけで高評価にするわけではない。探索のEvidenceには、仮説の妥当性、検証方法、記録、学びの再利用可能性を求める。「うまくいかなかった」と「検証によって採用しないと判断できた」は別物である。
Skill Visibilityと社内流動性を接続する
社員AがAIを学んだことを本人と上司しか知らなければ、そのSkillは組織として利用できない。社内Skill Profileには、少なくとも次の情報を持たせる。
- SkillとLevel
- Evidenceと確認者
- Certificationと更新日
- Experienceと最近の活動
- Interestと今後担いたい領域
- Learning History
- 利用可能な支援形態
これは監視用の人材台帳ではない。「生成AIの検証ができる人」「AWS Network設計をReviewできる人」「OAuthに詳しい人」「PQCを調査できる人」という需要と接続する検索基盤である。
確認したSkillを、短期の社内Project、兼務、技術Review、社内Consulting、PoC、Task Force、Community of Practice、社内公募へ接続する。正式異動を待たずに新しいSkillを試せれば、学習は経験へ変わる。
学習して市場価値が上がっても、仕事内容、評価、給与、役割が変わらなければ、転職がSkillを利用する唯一の方法になり得る。組織内のCareer GrowthがTurnover Intentionと負の関係を持つ研究や、Perceived Organizational Supportが離職意向と強い負の関係を持つメタ分析も、この問題を補強する。1617 育成施策だけで定着を保証できるわけではないが、成長に伴って社内の選択肢も増える構造は必要である。
制度を形骸化させない8原則
Performance Managementは、日常の仕事から切り離された形式的手続きへ縮小すると機能しにくい。PulakosとO'Learyは、制度の書式を作り直すことより、期待の明確化、短期目標、継続的な支援と対話へ注意を向けるべきだと論じている。18
- 学習時間をKPIにしない。時間は支援量として把握し、成果点へ直結させない。
- 資格数をKPIにしない。資格はSkill Evidenceとして使う。
- 実務経験だけをEvidenceにしない。Lab、試験、Case、PoCを認める。
- 直属上司だけでSkillを判定しない。専門家とPeer Reviewを使う。
- 現在部署への貢献だけで判断しない。会社全体へのCapabilityを見える化する。
- Skillを永久認定にしない。Currencyを再確認する。
- 合理的な探索失敗を罰しない。仮説、検証、知見を評価する。
- 評価資料を作るための仕事を増やさない。Git、Review、資格、Lab、社内文書など既存Evidenceを再利用する。
導入するときの実装案
いきなり全社員の給与制度を変えると、評価誤差と説明負荷が大きい。まず一つの職種群で6か月のPilotを行い、Capability Profileと社内機会の接続から始める。
| Phase | 実施内容 | 終了条件 |
|---|---|---|
| 1. 定義 | Role Family、Skill領域、Level、Evidenceを定義 | 10〜20個の主要Skillを同じ基準で説明できる |
| 2. Pilot | 本人申請、Peer Review、Profile表示を試す | 重複判定と不公平事例を収集できる |
| 3. Opportunity接続 | PoC、Review、短期Projectを公募 | 確認Skillから実経験へ進む事例が出る |
| 4. 評価接続 | CapabilityとContributionを評価会議へ追加 | Performanceと混同せず説明できる |
| 5. 報酬接続 | Role拡大、専門手当、昇格条件を整理 | 取得数ではなく担える責任と連動する |
Pilotでは、評価者間一致、申請に要する時間、Evidence却下理由、社内Opportunityへの接続率、Skill更新率を確認する。学習時間や資格数を成功KPIにしない。制度が増やしたいのは、記録量ではなく、確認済みCapabilityと利用機会の循環なのだ。
最終提言
AI時代のシステム会社が評価すべき人物は、知識を大量に暗記した人でも、資格を大量に持つ人でも、現在の担当業務だけを極めた人だけでもない。自分が何を知らないかを認識し、必要な知識を選び、学び、試し、批判的に評価し、別領域と接続し、仕事や組織へ還元できる人である。
成果を出した人を評価する原則は残す。ただし、成果だけが価値であるという前提は捨てる。Performance、Capability、Organizational Contributionを分け、資格を含む複数のEvidenceでSkillを確認し、Skill Visibilityと社内Opportunityへ接続する。
人事評価制度の最終目的は、評価によって社員を学習させることではない。自ら学び続けることを、社員自身が合理的に選択できる組織を作ることなのだ。