社内従業員ディレクトリを作る: 情報を更新し続ける仕組み

社内ディレクトリが古くなる理由

社内従業員ディレクトリは、更新作業が日常業務と切り離されると、すぐに古くなります。新しい人が入社したり、誰かがチームを異動したり、オフィスが移転したりしても、情報は古いスプレッドシートに残ったままです。やがて同僚が急いで必要な情報を探し、間違った電話番号、マネージャー名、タイムゾーンを見つけることになります。

小さな間違いでも、実際の遅れにつながります。営業担当者が、以前の製品責任者に顧客からの質問を送ってしまうかもしれません。オペレーションマネージャーが、同僚の勤務時間外に会議を設定することもあります。新入社員は、給与処理の担当者を知るために何人もの人へ聞くことになります。ディレクトリに明確な答えがないからです。

プロフィールがうまく機能しない理由の1つは、会社が入力を求めすぎることです。正式な経歴、プロジェクト履歴、個人的な関心、スキル評価、SNSのリンク、整った写真まで求めると、簡単な更新が面倒な作業になります。多くの人は後回しにし、そのうちリマインダーも無視するようになります。

役立つ従業員プロフィールデータベースに必要なのは、適切な人に連絡したり、その人の仕事を理解したりするための情報です。名前、チーム、役割、マネージャー、勤務地またはタイムゾーン、仕事用の連絡先、スキルの短い一覧などが該当します。誰かが定期的な利用方法を説明できる場合だけ、項目を追加しましょう。

ディレクトリは役割を絞っておくべきです。スタッフが同僚を見つけ、専門知識を確認し、仕事の担当者を把握するためのものです。投稿、フォロワー数、リアクション、アクティビティフィードを加えると、管理するコンテンツが増えます。従業員にとっても、助けられているというより監視されているように感じられる可能性があります。

人は、直接的なメリットが見えると情報を更新します。たとえば、同僚が「契約確認」で検索して、すぐに適切な担当者へ連絡できるなら、正確なプロフィールは時間を節約します。誰も読まない自己紹介文は、逆の効果をもたらします。

最初のバージョンは控えめに作りましょう。業務情報を簡単に変更できるようにし、全社共通の項目には担当者を置き、誰も使わないものは削除します。スタッフが普通の勤務日に安心して使えるとき、ディレクトリは信頼されます。

プロフィールに含める項目を決める

プロフィールは、よくある業務上の質問を中心に作ります。給与処理の担当者を探したり、Salesforceに詳しい人を見つけたり、同僚がBerlinオフィスで働いているか確認したりする場面を考えましょう。項目が同僚への連絡、仕事の振り分け、業務内容の理解に役立たないなら、入れないほうがよいでしょう。

まず、必須の業務情報を少数に絞ります。これなら長いフォームを強いることなく、社内従業員ディレクトリに一貫した構造を持たせられます。

• 氏名と希望する名前
• チーム、役割、マネージャー、勤務地
• 仕事用メールアドレス、電話番号、必要に応じてタイムゾーン
• 業務に関係するスキルや知識分野
• その人が対応できることについての短い説明

スキルは検索しやすい程度に具体的にします。「Finance」だけでは広すぎます。「経費規程」「請求書の承認」「NetSuiteレポート」なら、同僚が連絡する理由が明確になります。可能なら、承認済みのスキルラベルを選べるようにし、一覧に入らない内容だけ短い補足を追加できるようにします。

必須項目と任意項目を分けます。チームが通常必要とするのは、役割、連絡先、勤務地、業務スキルです。個人の経歴、好きな言葉、誕生日、写真まで必要とは限りません。任意の写真は名前と顔を結び付けるのに役立つことがありますが、プロフィールを完成させるために必須にするべきではありません。

プロフィールには、実務に役立つ対応可能時間も含められます。Torontoのサポート責任者なら、「英語とフランス語」「平日のエスカレーション窓口」「9:00から17:00 ETまで対応可能」と書けます。営業担当者は長いやり取りをせず、緊急の顧客問題を適切な人へ振り分けられます。

これはスタッフディレクトリであり、ソーシャルネットワークではありません。公開投稿、リアクション、フォロワー数、コメント欄、アクティビティフィードは省きます。すっきりしたページなら、その人が誰で、何をしていて、どこで働き、いつ連絡できるかをすぐに確認できます。

役割、スキル、勤務地のルールを決める

すべての項目には、職場での質問に答える役割を持たせます。役割の分類は、同僚を探す方法に近づけます。部署、職種、チーム、役職などです。顧客アカウントの担当者を知りたいだけなのに、ほぼ同じ役職名を長い一覧から選ばせるのは避けましょう。

分類ごとに短い共有リストを作ります。営業グループなら、Sales、Customer success、Partnerships、Sales operationsなどを使えます。必要に応じてマネージャーが新しい分類を提案できるようにしますが、承認する担当者は1人に決めます。これで同じ仕事に複数の名前が付くのを防げます。

スキルを経歴ではなく検索項目にする

わかりやすいスキルラベルを選び、必要に応じて追加できるようにします。「SQL」「スペイン語」「契約確認」「Figma」は、仕事上の関心についての長い文章よりも同僚の役に立ちます。スキルディレクトリの目的は、仕事を任せられる人を探すことです。キャリアの物語を読むことではありません。

ルールはシンプルにします。

• スタッフには、仕事で自信を持って使えるスキルを最大5つ登録してもらう
• 「プロジェクト管理」のように、各スキルで表記とラベルを統一する
• 不足しているスキルを従業員が提案し、担当者が重複をまとめる
• 「働き者」「チームプレーヤー」のような曖昧な特徴は除外する

AppMasterでディレクトリを作る場合、承認済みラベルを持つスキルテーブルを使いながら、スタッフが新しい候補を審査に提出できるようにできます。フォームを窮屈にせず、検索結果の一貫性を保てます。

役立つ場合だけ勤務地を含める

勤務地のデータは、仕事の調整に役立つものにします。会議の予定を組んだり、機器を配送したり、勤務時間を把握したりする必要があるなら、オフィス、都市、タイムゾーン、リモート勤務の状況を記録します。ディレクトリに必要のない自宅住所や個人情報は求めません。

シンプルなプロフィールなら、「Remote, UTC+1」や「Chicago office, Central Time」と表示できます。複数のオフィスを行き来する人には、複数の項目を並べるのではなく、主な勤務地と短い補足を使います。

チームと役割の変更は、通常、責任の変化を把握しているマネージャーが管理します。従業員はスキル、写真、希望する名前、連絡方法を管理できます。誰が更新するかを明確にすれば、全員が誰かに任せたつもりになる事態を防げます。

データソースとアクセスルールを選ぶ

同じ情報が3か所にあると、ディレクトリへの信頼は失われます。HRには1つの役職名があり、チームのスプレッドシートには別のスキルが記載され、従業員が別の場所で電話番号を変更しているかもしれません。スタッフは、どの記録が最新なのかを知る必要があります。

新しいものを作る前に、従業員情報がすでに存在する場所を一覧にします。一般的な情報源には、HR記録、給与システム、IDプロバイダー、チームのスプレッドシート、オンボーディングフォーム、マネージャーが管理する一覧などがあります。各情報源の担当者と、含まれる項目を記録します。

ディレクトリの各項目に、1つの管理元を割り当てます。HR記録では、法的な氏名、雇用状況、マネージャー、正式な役職を管理できます。従業員は希望する名前、写真、業務上の関心、スキルを編集できます。必要なときには、チームリーダーがプロジェクトへの割り当てを確認します。

シンプルな管理分担で、編集の衝突を防げます。

• HR: 雇用状況、正式な役割、部署、マネージャー、入社日
• 従業員: 希望する連絡方法、スキル、言語、プロフィール画像
• IT: 仕事用メールアドレス、会社の電話番号、アカウント状況
• チームリーダー: 現在のチーム、プロジェクトへの割り当て、社内での担当業務
• オフィス管理者: 座席の場所とオフィス情報

アクセスルールにも同じ配慮が必要です。ほとんどのスタッフが必要とするのは、名前、役割、チーム、スキル、勤務地です。自宅住所、個人の電話番号、生年月日、報酬、緊急連絡先まで必要とは限りません。HRや給与担当者など、必要な人だけが機密項目にアクセスできるようにします。

プライバシーに関するルールは、わかりやすい言葉で書きます。「このディレクトリには業務に関係する情報だけを表示します。HRは個人情報や機密情報を保護された記録で管理します。従業員はHRチームを通じて訂正を依頼できます。」

AppMasterのディレクトリアプリでは、スタッフがプロフィールを検索し、従業員が自分の項目を編集し、HR管理者が保護された雇用データを管理できるように権限を設定できます。誰もが役立つ情報を見つけられ、変更できるのは適切な人だけ、という状態を目指します。

チームを異動した人や退職した人のアクセスも確認します。アクセスは速やかに削除し、各データソースの管理担当者を記録しておきます。

ディレクトリを段階的に作る

まずは、日常的な質問に答えられる1つのプロフィールテンプレートを作ります。その人が誰で、何をしていて、どのチームに所属し、どこで働き、どんなスキルについて相談できるのかがわかるようにします。必須にする項目は最小限にします。長いフォームでは、未完成のプロフィールが増えます。

名前、仕事用メールアドレス、役割、チーム、マネージャー、勤務地、入社日を必須にします。スキルは最初は任意にしても構いませんが、自由入力ではなく管理された一覧を使います。「Excel」と「Microsoft Excel」が別々の検索結果にならないようにします。

次に、既存のスタッフ記録を取り込みます。会社がすでに使っているシステムからデータを出力し、重複した人、古いアカウント、一貫しないチーム名を整理してからインポートします。各人に1つの永続的な従業員IDを割り当てます。名前や役割は変わっても、IDは変えません。

公開前に、チームリーダーへ自分のグループを確認してもらいます。以前の契約社員、古いマネージャー情報、実際の仕事と合わなくなった役職名を見つけてもらえます。短い期限を設け、承認が必要な項目を明確にします。

最初のリリースは、装飾ではなく検索を中心に作ります。スタッフが名前、チーム、勤務地、役割、スキルで検索し、わかりやすいプロフィールページを開けるようにします。

AppMasterはこの用途に適しています。Data Designerで従業員データをモデル化し、ビジュアルのBusiness Process Editorで承認手順を作り、Web builderで画面を構築できます。アプリ全体を手作業でプログラミングする必要はありません。たとえば、マネージャーによる確認フローで、各リーダーに確認対象のプロフィール一覧を送り、プロフィールごとに承認日を記録できます。

プロフィール全体を固定された記録として扱うのではなく、項目ごとに確認日を設定します。役割やマネージャー情報は四半期ごとに確認し、スキルは半年に1回確認する方法があります。連絡先は変更があった時点で従業員が更新できます。

実用的な最初のリリースには、必須プロフィールテンプレート、整理済みのインポートデータ、永続的な従業員ID、役割とマネージャー項目に対するチームリーダーの承認、検索フィルター、項目ごとの確認日を含めます。まずは少人数に公開します。項目や画面を増やす前に、どの検索がうまくいかず、どの項目が無視されているかを確認します。

更新を通常業務に組み込む

社内従業員ディレクトリは、すでに行われている作業と一緒に更新すると正確な状態を保てます。新しい役職、チーム異動、オフィス移転があれば、短いプロフィール確認を開始します。全員が忙しい時期に年1回の依頼を送るだけでは、うまくいきません。

変更された可能性のある項目だけを従業員に確認してもらいます。現在の情報をあらかじめ入力し、すべてを再入力するのではなく、記録を修正できるようにします。

営業担当者がCustomer successへ異動したときは、HRまたはマネージャーが更新依頼を開始できます。従業員は新しい役割を確認し、部署を変更し、関連する製品スキルを追加して、フォームを送信します。これなら同僚が助けを求める前に、異動後の情報をディレクトリへ反映できます。

古い記録を見えるようにする

すべてのプロフィールに「最終確認日」を保存します。マネージャーはチームの記録を確認日順に並べ、6か月または12か月間確認されていない人を見つけられます。電話番号やスキルがまだ有効かどうかを推測するより、確実な方法です。

リマインダーは控えめに使います。スタッフ計画の前にスキルを確認するなど、役立つ作業と結び付いているときに効果を発揮します。一般的なメールを何度も送ると、依頼そのものが無視されるようになります。

リマインダーのスケジュールには、次のようなものを含められます。

• 役割、マネージャー、勤務地が変わった後のプロフィール確認
• オンボーディング時と、年1回の確認時点での確認
• リマインダーに1度回答がなかった後のマネージャーへの通知
• 未解決の記録をHR、IT、または別の項目担当者へ割り当てること

従業員は個人情報とスキルを管理します。マネージャーはチームへの所属と役割の正確さを管理します。HRは正式な雇用データを管理します。

AppMasterでは、スタッフの変更後に更新フォームを送り、確認日を記録し、依頼の期限が過ぎたときに適切な担当者へ知らせる業務プロセスを作れます。依頼は短くし、本人の仕事に実際の変化があったときに送るようにします。

シンプルなディレクトリの例

サポートマネージャーのMayaは、製品リリース前にヘルプセンターの画面を更新するデザイナーを探しています。チームはTorontoで働いており、北米の午後に重なる時間帯で対応できる人が必要です。Mayaには、適切な人と明確な連絡方法が必要です。

Mayaは社内従業員ディレクトリを開き、「UX design」のスキル、Productチーム、Americasの勤務地で絞り込みます。180人いた候補が4人に減ります。さらに、タイムゾーンが少なくとも3時間重なる人に絞り込みます。

1つのプロフィールだけで、Mayaは行動に移せます。

• 名前、役職、Productチーム
• UX design、Figma、アクセシビリティレビュー、ヘルプセンターコンテンツ
• 勤務地、タイムゾーン、通常の勤務時間
• 現在のマネージャーと、カスタマーエクスペリエンスグループをサポートできることについてのメモ
• 仕事用の連絡先と希望する依頼方法

プロフィールには次のように書かれています。「サポートフローとアカウント設定を設計します。顧客向け案内に影響するインターフェース変更について連絡してください。」Mayaはリリース日を添えて、Jordanに具体的な依頼を送れます。Jordanが対応できなければ、絞り込んだ結果に戻って次の人へ連絡できます。

これが、従業員プロフィールデータベースに個人的な更新ではなく実務情報が必要な理由です。スキルだけでは、特定の仕事を誰が担当しているかはわかりません。役職だけでは、勤務時間が重なるかどうかもわかりません。スキル、チーム、勤務地、連絡方法を組み合わせることで、最も役立つ情報になります。

使われなくなる原因

検索結果が信頼できないと、人はディレクトリを使わなくなります。適切な同僚を見つけ、役割を理解し、連絡できるようにすることが目的です。HRの全記録を複製する必要はありません。

HRの項目をすべてコピーすると、情報が増えすぎ、プライバシー上の問題も生まれます。給与データ、評価メモ、古い管理記録は除外します。名前、チーム、役割、勤務地またはタイムゾーン、仕事用の連絡先、関連スキルに集中します。

共有データを一貫させる

役職を自由入力にすると、すぐに混乱します。ある人は「Customer Success Lead」、別の人は「CS manager」、さらに別の人は古い役職名を使うかもしれません。検索で人を見つけにくくなり、マネージャーが記録の修正に時間を使うことになります。部署、役割の分類、オフィスの場所、一般的なスキルには管理された一覧を使います。標準ラベルで専門的な役割を説明できないときだけ、短い説明を追加できるようにします。

スタッフは各情報を1か所で更新できるようにします。電話番号をHR、別のディレクトリフォーム、メッセージツールでそれぞれ変更すると、どこかの記録が古くなります。データの種類ごとに情報源を決め、可能な場合はディレクトリが自動的に情報を受け取るようにします。

HRは雇用状況、マネージャー、法的な氏名、入社日や退職日を管理します。従業員は写真、名前の読み方、スキル、短い業務紹介を管理できます。チームリーダーは、責任が変わったときに役割とスキルラベルを確認します。ディレクトリ管理者は例外を処理し、重複したプロフィールをまとめます。

検索をフィードにしない

チャット、いいね、公開コメント、アクティビティフィードを追加しても、同僚を探しやすくなるとは限りません。管理も必要になります。会話は会社がすでに使っているツールで行い、ディレクトリには連絡方法を表示します。

退職者には明確な退出手順が必要です。HRが退職者を無効にしたら、通常の検索結果とチーム表示からプロフィールを外します。会社の方針で限定的な引き継ぎ記録を残す必要がある場合は、その目的を明記し、アクセスを制限します。

AppMasterでは、プロフィール用のビジュアルなデータモデル、役割変更の承認手順、各ユーザーに必要な項目だけを表示する権限を使って、こうしたルールを実装できます。

公開前の簡単な確認

全社に招待する前に、小さなテストを実施します。異なるチームの人に、名前、役割、スキル、チーム、勤務地で同僚を探してもらいます。「designer」や「sales」のような一般的な用語でも、役立つ結果が返る必要があります。

結果ページも確認します。フランス語を話せるアカウントマネージャーを探している人が、すべてのプロフィールを開かなくても、適切な人へ連絡できる情報を確認できるようにします。

管理責任と更新を確認する

必須項目には必ず担当者と確認日を設定します。HRは法的な氏名と雇用状況を管理できます。マネージャーはチーム、役割、報告先を管理できます。会社の方針が許せば、従業員は写真、スキル、希望する名前、短い自己紹介、連絡先を管理できます。

これらのルールをディレクトリに書きます。担当者のいない項目は、たいてい古いデータになります。

公開前に、従業員が承認済みの項目を数分で更新できるか、マネージャーが長い承認手順なしで誰かを新しいチームへ移せるか、確認担当者が対応の必要なプロフィールを見つけられるかをテストします。確認日前にリマインダーが届くこと、管理者が変更を記録しながら間違いを修正できることも確認します。

実際のアカウント種別でアクセスをテストします。従業員は、自分が編集できる項目と承認済みのディレクトリ情報を見られるべきです。マネージャーはチームの情報を維持するために必要な範囲を見られるべきです。HRやディレクトリ管理者には追加項目が必要かもしれませんが、それらは通常の検索結果に表示しません。

最後に短いパイロットを実施します。10人の従業員が、助けを借りずにプロフィールを更新し、同僚を探し、各項目の担当者を理解できるなら、ディレクトリを広く公開する準備が整っています。

小さく始めて改善する

全社で一度に公開すると、空のプロフィールや不明確な管理責任が生まれやすくなります。まずは、Customer supportやOperationsなど、すぐに人を探す必要がある1つの部署から始めます。そのチームに小さく使いやすいディレクトリを提供し、どのように検索するかを確認します。

従業員には実際の作業を試してもらいます。スペイン語を話せる人を探す、顧客対応プロセスの担当者を見つける、特定のオフィスで働く人を確認する、といった作業です。検索内容から、ディレクトリに必要な情報がわかります。役立つことが少ない項目は削除します。

毎週、いくつかのシンプルな数字を確認します。

• 役割、マネージャー、勤務地など、必須情報が不足しているプロフィール
• 確認日を過ぎたプロフィール
• 結果が少なすぎる、または多すぎる検索
• リマインダー後に完了した更新

これらの指標から、従業員プロフィールデータベースが役立つ状態を保っているかがわかります。ソフトウェアスキルを検索する人が多いのに、プロフィールごとに表記が違うなら、管理されたスキル一覧を追加します。誕生日や個人的な関心で誰も絞り込まないなら、その項目は入れません。

最初のチームが数週間にわたって記録を最新に保てたら、次の部署を追加します。確認のリズムは保ちつつ、新しいチームの仕事に合わせて調整します。営業には地域やアカウントの専門知識が必要かもしれません。ITにはシステムやオンコール対応の情報が必要になるでしょう。

AppMasterでは、プロフィール、承認ワークフロー、リマインダー、アクセスルールを1か所で管理できます。基本的な従業員フォームを作り、マネージャーに確認キューを用意し、プロフィールの確認日が来たらリマインダーを送ります。要件が変わっても、AppMasterはバックエンド、Webアプリ、モバイルアプリを生成できるため、古いプログラムを引き継がずに項目やワークフローを見直せます。

従業員が日々の検索で使う項目だけを追加します。現在のチームが記録を繰り返し催促されずに維持できるようになってから、対象チームを増やします。そうすれば、スタッフディレクトリは誰かに聞き回る前に確認するものになります。