タレントインテリジェンスチームは、たいてい同じ種類の質問を投げかけられる。この会社は実際にはどう組織されているのか、そして自分たちが採用や営業を仕掛けられそうなギャップはどこにあるのか、という質問だ。
つい、どこかに存在する文書であるかのように組織図を探しに行きたくなる。だが、そんなものはない。公開情報から構築できるのは、証拠を積み上げて組み立てた構造のモデルであり、わかっている部分と推測した部分が混在している。この違いは重要だ。モデルを文書として提示してしまうことこそが、タレントマッピングが失敗する原因だからだ。
情報源からではなく、境界線から始める
これは人に関する仕事であり、制約は末尾のコンプライアンス段落にではなく、冒頭に置くべきものだ。
擁護可能なタレントマッピングは、組織構造を記述する。どの機能が存在するか、階層はどれだけ深いか、チームの規模はおおよそどれくらいか、どこで採用が行われているか、どのスキルがどこに集中しているか。これは組織が自ら公開している情報を使う。
一方、チームをトラブルに巻き込むバージョンは、個人のダossierを構築する。名前のある個人についての個人情報を集約したり、技術的に閲覧可能だったという理由で連絡先情報を収集したり、自動化を禁止する利用規約を持つプラットフォームのログイン後コンテンツをスクレイピングしたりすることだ。GDPRや類似の規制の下では、見つけやすかったかどうかにかかわらず個人データは個人データであり、「公開されていた」ということ自体は適法根拠にはならない。
作業をクリーンに保つ実践的なルールが2つある。ロールが質問に答えられる限り、ロールレベルで情報を収集すること。なぜなら「プラットフォームエンジニアリングのディレクターが存在し、インフラ部門に報告している」というのが通常必要な事実であり、誰がその地位にいるかではないからだ。そして、リーダーシップページで名前が明記されているために特定の個人を記録する場合には、その職務上の文脈で会社自身が公開した情報にとどめ、それ以外はすべて取り込み時点で除去すること。
実際に構造を伝える情報源
公開情報による組織マッピングのほとんどは6つの入力から構築されるが、これらは信号の質において大きく異なる。
**求人情報。**最も強力な単一の情報源でありながら、一貫して活用が不十分だ。求人情報には報告ラインが明記されていることが多く（「データ担当VPに報告」など）、チーム名を挙げ、隣接する機能を記述し、そのチームが使うツールを列挙する。求人情報には日付もついているため、いつのプロフィールが最後に更新されたかではなく、「今」についての証拠となる。機能別の求人量は、どのチームが成長しているかの良い代理指標になる。この情報源の収集手法については、job-board data and labour-market intelligence で扱っている。
**企業のリーダーシップページやチームページ。**上位2階層については権威ある情報源だが、それより下は通常沈黙している。存在する場合はグラウンドトゥルースとして扱う価値がある。なぜなら会社が意図的に公開した情報だからだ。
**プレスリリースと人事発表。**上級人事の変更を捉えるのに優れており、日付も付いている。ここで組織再編を早期に察知できる。新しい機能は他のどこかに現れるより前に発表されることが多いからだ。
**規制当局への提出書類。**各国の企業登記簿における役員・取締役情報、および上場企業の提出書類における同等情報。範囲は狭いが信頼性は高く、子会社をまたぐ法的実体構造について検証可能な唯一の情報源であることも多い。
**カンファレンス講演と技術論文。**スピーカーリスト、公開された論文や特許は、名前のある専門家を名前のあるチームの中に位置づけ、企業のマーケティングが語ることではなく実際に何を構築しているかを明らかにする。
**オープンソースおよび公開技術活動。**組織レベルのリポジトリと貢献パターンは、チーム構成やスタックを示すことがある。これは個人単位の生産性シグナルとしてではなく、チームレベルで読み取ること。
証拠を構造に変換する
組み立ての段階こそが規律の効果が発揮される場所であり、それは観察したことと結論づけたことを分離することに尽きる。
**タイトルから階層を、慎重に。**タイトルの慣習は企業ごと、国ごとに異なる。ある組織の「ディレクター」は、別の組織の「シニアマネージャー」に相当する位置にいることがある。言葉を鵜呑みにするのではなく自社の社内シニオリティ・ラダーに正規化し、生のタイトルと正規化後のタイトルの両方を記録すること。
**チーム規模は採用状況から、公表人数からではなく。**ある機能について複数四半期にわたる継続的な求人量は、公表されているどんな数字よりも実際のチーム規模や軌道について多くを語る。
**報告ラインは明記されている場合のみ。**これはほとんどのマップが放棄してしまう規律だ。求人情報がそのロールは特定の機能に報告すると述べていれば、それは観察だ。タイトルが隣接していそうだからと推測したのであれば、それは推論であり、そのようにラベル付けしなければならない。
出来上がった構造の各ノードは、3つの要素を持つべきだ。どの情報源から来たか、いつ観察されたか、そして確信度だ。提出書類で検証された役員と推測された報告ラインが同じように見えるマップは、いずれそれを提示する人物を困惑させることになるマップだ。
組織データはほとんど何よりも早く劣化する
組織再編、離職、名称変更は絶えず起きているが、どれも通知を発しない。
タレントマップは構築された日には正確だが、翌日から劣化し始める。すべてのノードをタイムスタンプ付きの観察として扱い、明示的な鮮度しきい値を適用し、一度構築して1年間参照し続けるのではなく、スケジュールに従って再観察すること。変化の速い企業では、四半期でもすでに長すぎる。
これに伴う帰結として、鮮度はマップの利用者に見えるようにすべきだということだ。11ヶ月前に最後に確認されたノードは、先週確認されたノードとは異なって見えるべきだ。
収集レイヤー
これらの情報源には収集手段を左右する3つの特性がある。
求人情報や登記簿は地理的にフィルタリングされているため、ある企業のドイツ組織は米国の視点からは見えないことがある。国際的なカバレッジを主張するなら、収集はその市場から行わなければならない。結果セットはページネーションされており、興味深いロールが1ページ目にあることはめったにない。そしてこれらは通常のレート制限を持つ普通のウェブ表面だ。
Shifterのゲートウェイでは、視点とセッションは p.shifter.io:443 に対する認証情報の中に入れる。
customer-USERNAME-country-de-city-munich-sid-map-4412-ttl-600:PASSWORDcountry-de と city-munich はリクエストを正しい市場に配置し、sid-map-4412 はページネーションを含むクエリ全体を通して1つの出口を保持し、ttl-600 はそのアドレスを10分間維持する。リクエスト単位ではなくクエリ単位で1つのセッションを使うことが、ページネーションされた結果セットの内部一貫性を保つ鍵だ。
ペースは急激なバーストではなく、着実で控えめであるべきで、エラー時には適切なバックオフを行うこと。詳細は rate limiting and request throttling で扱っている。この作業のプロダクト視点は recruitment and talent ページにあり、採用側の関連記事は residential proxies for recruiting and job market data だ。
公開情報によるマップにできないこと
限界について正直であることが、それ以外の部分の信頼性を支える。
誰も公開していない報告ラインを証明することはできない。非公式な構造を見ることもできない。それこそがほとんどの組織で実際に意思決定を左右しているものだ。誰が予算を持っているかを教えることもできない。そして、社内の誰かとの会話の代わりにはならない。会話こそが、重要なことのほとんどを知る唯一の方法であり続ける。
できることは、どの機能が存在するか、おおよそどれくらいの規模と深さか、どこに採用が集中しているか、どのスキルがどこに集まっているか、そしていつ何かが変化したかを教えることだ。ほとんどのタレントインテリジェンスやゴーツーマーケットの質問にとって、それが役立つ部分だ。
FAQ
プロフェッショナルネットワークをそのままスクレイピングしてもいいのでは?
ログインの背後ではだめだし、利用規約が自動化を禁止している場所でもだめだ。この経路は、保持する根拠のない個人データを生み出す可能性が最も高い経路でもある。上述の情報源は、ログイン後のプロフィールフィードとは異なる意味で公開されている。
公開情報による組織図はどれくらい正確になり得るか?
上位2階層は企業が公開しているため、通常信頼できる。中間階層は確信度にばらつきのある推論だ。それより下では、個人ではなく機能とチーム規模を記述することになるが、それで通常十分だ。
最小限の実行可能なバージョンとは何か?
1社分の求人情報を自社のシニオリティ・ラダーに正規化し、明記された報告ラインは観察として記録し、それ以外はすべて推論として記録する。それだけで、ほとんどの構造的な質問に答えられる。
必要のない個人データを保持しないようにするには?
保存時ではなく取り込み時に判断すること。質問がロールで答えられるなら、名前は書かない。求人情報のテキストから連絡先情報を機械的に除去すること。リクルーターの電話番号が探していたものであることは決してないからだ。
結論
公開情報から構築された組織図は、確信度が付与されたモデルであり、その形であれば真に有用だ。それが事実として提示された瞬間、あるいは構造の記述ではなく人の収集へと逸脱した瞬間に、負債となる。
ロールレベルで作業し、すべてのノードについて情報源と日付を記録し、観察と推論を分離し、企業が実際に事業を展開している市場から収集し、スケジュールに従って再観察すること。収集レイヤーの料金はpricing pageに掲載されている。