(a) 背景

• 昨今のデジタル化の進展やCOVID-19の影響により、企業の採用プロセスのデジタル化が急速に進展している。こうした中で、就職・転職活動を行う個人にとっては、自らの機微な情報の取扱いに対する懸念やリスクが高まっている。
• 一方、人口減少や人材需給逼迫の下、採用難が広がる中、採用企業にとっては、採用時のミスマッチを回避すべく、信頼できる情報を得るニーズが高まっている。このような中、人材を採用する際に、採用企業は応募者本人が作成する履歴書や職務経歴書の内容の確認に加え、応募者の現職または前職の同僚や上司に対し、応募者本人の実績や勤務状況に偽りがないかの確認を行うリファレンスチェックを実施するケースも増えてきている。しかしながら、採用企業からすると、応募者本人やリファレンス提供者について、本人確認や、現職・前職企業の在籍確認などを行うにはハードルが高く、確認手法の信頼性の担保には課題がある。また、応募者やリファレンス提供者の機微な情報については、採用企業にとっても、その取扱いに対する信頼性を高めることが求められている。応募者本人やリファレンス提供者についての情報管理の重要性は言うまでもない。すなわち、これら関係者が安心して自らの情報を提供できる環境を整えることが求められている。
• 本ユースケースでは、応募者、リファレンス提供者、採用企業が「検証できる領域の拡大によるTrustの向上」を図るための適切なデータのあり方、やり取りの記録の可能性について検討した。
• 検討と並行して、検討結果の一部を具現化したプロトタイプを開発した。なお、プロトタイプで実装したのは検討結果の一部であるため、たとえば、全てのペインポイントを解決した形にはなっていない。プロトタイプ実装についての議論は「5-(2)④ プロトタイプ開発と結果の整理」を参照のこと。

図 5‑1.個人のユースケース

(b) ペインポイント

• ペインポイントを、整理・集約すると、以下のようになる

1. 全ての参加者の視点
   1. 情報をやりとりする相手が、主張する通りのアイデンティティに結びつく本人であるかを検証できない
   2. 相手が示した情報が正しいのかを検証できない
   3. 相手が所属（現在あるいは過去）を主張している企業への在籍の事実があるかを検証できない
   4. やりとりする情報が改ざんされているかどうか検証できない
2. 情報の提供側の視点
   1. 提供する情報が正しく管理されていることを知り得ない
   2. 提供する情報が不正に開示されるリスクがある
   3. 目的外利用や第三者提供のリスク
   4. 提供する必要がない情報の開示を求められる場合がある
   5. 提供した情報を撤回できない
3. 情報の受け取り側の視点
   1. 受け取った情報が正しく管理されていることを情報提供側に示すことができない
   2. 不必要な情報を受け取るリスクがある

(c) Trusted Web適用により効果を期待できるポイント

• 本人確認情報や在籍確認情報などを検証可能な情報として渡すことで、転職先企業側の関係者が、応募者本人であることや在籍を現実的なコストで確認可能になることが期待できる。
• 応募者本人やリファレンス提供者が転職先企業に対して、応募にあたって必要な情報のみ転職先企業にのみ開示する形で提供することとし、検証可能な情報への一時的なアクセスを制御できるようにすることで、応募者本人は、開示先をコントロールし参照履歴も確認することができる。
• また、転職先企業において、例えば情報を取得する際の同意や、取得した情報を目的外利用していないことの証明・担保が容易になることにより、情報の取扱いに対する信頼性を高め、これら関係者が安心して自らの情報を提供できる環境を整えることができる。
• ここで述べたように、情報をやり取りする相手の確証が持て、個人のスキルや実績等のデータを各個人が開示範囲のコントロールをしつつ、情報自身の確からしさを確保しつつ伝達することが一般にできる。このような個人の情報の制御下におけるやり取りが実現することにより、①個人にとっては、自らが活躍し、自己実現できる機会を広げることができ、②採用企業にとっては、コロナ後やDXに伴う社会の変革の中で、効率的・効果的な採用を実現でき、③社会全体にとっては、人口減の中で、社会全体として人材リソース配分の最適化を図ることができる。

(d) 本ユースケースにおける特異な点

• 応募者とリファレンス提供者のプライバシーを保ちつつ、企業への十分かつ検証可能な情報提供が困難である点が特異である。本人、転職先企業、リファレンス提供者のそれぞれが必要かつ十分な情報のやりとりをする必要があり、それぞれのエンティティが、どの情報を誰に見せるかを厳密にコントロールできる必要がある。また、本人確認情報に加え、現・前職における在籍確認の証明も必要となるが本人のプライバシーを確保した方法が必要である。

(e) 本ユースケースで抽出された検討すべき課題

• 個人情報の開示という側面を持つため、特にTrace機能がどのように実装されるかが課題と言える。とりわけ、プロトタイプではIPFSに暗号化されたデータを保持し、アクセスコントロールするとともにアクセス記録を残すようにした点が課題と言えよう。暗号化されているとはいえ個人情報であり、少なくとも長期的な視点での安全性の確保が必要である。そして、アクセスコントロールを個人が繊細にコントロールする手段の確保も難しい。第三者に依存せずに済むような方式の検討が必要である。
• また、他のユースケースとも共通する課題であるが、データモデルの対象領域毎の共通化や標準化が必要であろう。
• さらに、前述（ｃ）で記載した「応募に当たって必要な情報のみ転職先企業にのみ開示する形で提供することとし、検証可能な情報への一時的なアクセスを制御できるようにする」ことを実現する場合に、それが、ver1.0で提起したTrustable Communication機能なのか、Trace機能なのか、機能が十分整理できていないとの認識に至った。このため、４つの機能の実装を意識して再整理を行うことが必要と考えられる。この点については、後述の２つのユースケースにおいても同様である。