スキルマップ(スキルマトリクス)は、行に人、列に具体的なスキルを置き、チームとして対応できる業務と、練習や代替要員が必要な業務を整理する表です。まず実際に必要な業務を選び、各評価の意味を決めます。肩書きだけで判断せず、最近の実務で何ができたかをもとに記入しましょう。
評価の根拠をチームで話し合うときは、離れた場所からも共有できるチーム用ホワイトボードが役立ちます。表を埋めることは出発点です。対応が手薄な業務を見つけ、どう補うかを具体的に決めてこそ、スキルマップを活用できます。

スキルマップの記入例
4人のカスタマーサポートチームが、メンバーの休暇に備えて担当体制を確認する場面を考えます。代わりに対応できる人がいる業務と、まだ支援が必要な業務を把握したい状況です。「コミュニケーション力」「技術力」のような大きなくくりではなく、日常的に行う4つの業務を表にします。
| メンバー | アカウントにアクセスできない問題の解決 | 請求内容の不一致の調査 | 製品の不具合の再現 | ヘルプ記事の公開 |
|---|---|---|---|---|
| Maya | 3 | 2 | 1 | 2 |
| Leo | 2 | 1 | 3 | 1 |
| Priya | 1 | 0 | 2 | 3 |
| Jon | 2 | — | 1 | 1 |
| 1人で対応できる人数:評価2または3 | 3 | 1 | 2 | 2 |
このチームでは、次の基準で評価します。
- — 未評価:評価を決めるための情報が足りない。
- 0 — 未経験:その業務をまだ行ったことがない。
- 1 — 支援があれば対応できる:一部はできるが、安定して完了するには助けが必要。
- 2 — 1人で対応できる:合意した範囲の業務を完了でき、上位担当者などに判断を求めるべき場面も分かる。
- 3 — 指導できる:1人で対応できるうえ、ほかの人がその業務を習得するのを支援できる。
これは、このチームで使うために決めた簡単な尺度です。「未評価」と「未経験」は区別します。Jonの請求調査欄は、まだ確認できていないという意味であり、その業務ができないことを示すものではありません。

実際の行動で確認できるスキルを選ぶ
列には、実際に行っているところを確認できる業務を書きます。「顧客対応が得意」ではなく、「アカウントにアクセスできなくなった際の復旧手順を説明できる」とします。「製品に詳しい」なら、「報告された不具合を再現し、その手順を説明できる」のように具体化します。
次の業務期間で必要になるスキルを選びましょう。休暇に備えるサポートチームなら、サービスを続けられる担当体制が重要です。新しい種類の成果物に取り組むプロジェクトチームなら、まだ慣れていない手法を整理する必要があるかもしれません。将来必要になる可能性があるスキルをすべて同じ表に入れると、今補うべき不足が見えにくくなります。
各列には短い定義を付けます。この例の「請求内容の不一致の調査」は、関連するアカウント情報と請求記録を見つけ、違いを説明し、専門担当者の承認が必要な場面を判断することです。評価2の人なら誰でも返金を承認したり、取引方針を変更したりできる、という意味ではありません。
スキルと、勤務状況や権限は分けて扱います。業務ができる人でも、休暇中かもしれません。手順を理解していても、最終承認の権限がない場合もあります。その違いを評価点で調整せず、表の横に制約として記録します。
空欄のスキルマップテンプレート
次の表を土台に、4つのスキルの見出しをチームの業務に置き換えてください。人数に合わせて行を増減し、評価基準は表の近くに置いて、いつでも確認できるようにします。
| メンバー | スキル・業務1 | スキル・業務2 | スキル・業務3 | スキル・業務4 |
|---|---|---|---|---|
| メンバーA | — | — | — | — |
| メンバーB | — | — | — | — |
| メンバーC | — | — | — | — |
| メンバーD | — | — | — | — |
| 1人で対応できる人数 | 評価2・3の人数 | 評価2・3の人数 | 評価2・3の人数 | 評価2・3の人数 |
表の横には、対象範囲、話し合った日付、評価の根拠も記録します。例えば、「アカウントへのアクセス:標準的な復旧ケース。ペアでのサポート対応中に確認」と書けば、何をもとに判断したかが分かります。広く共有するボードに、顧客の非公開情報を貼り付ける必要はありません。
チームで根拠を確認しながら記入する
各メンバーに、自分が該当すると考える評価と、最近の具体例を挙げてもらいます。同じ業務の定義に照らして話し合いましょう。「研修を修了した」と「案件を1人で対応した」は、異なる種類の根拠です。
本人と確認者の評価が違う場合は、どこが食い違っているかを特定します。一方は通常のケースを、もう一方は特殊な例外を想定しているのかもしれません。業務の範囲を絞るか、改めて実務を確認する必要があると記録します。2人の意見を平均した点数にしても、違いを隠すだけで解決にはなりません。
色だけでなく、評価の意味が分かる表示も使います。緑色のセルだけでは、1人で対応できるのか、指導もできるのかが分かりません。また、色の違いを見分けにくい人もいます。小さな表なら、数字と近くに置いた凡例で十分に伝えられます。
社内で承認された能力評価の枠組みがある場合は、その定義を使います。例えば、SFIAでは専門スキルと責任のレベルを定義しています(英語)。SFIAのレベルを、この例で使っている簡単な習熟度の尺度とそのまま置き換えることはできません。
個人の順位ではなく、チームの対応体制を見る
まずはスキルの列を縦に読みます。記入例では、アカウントへのアクセスに関する業務は3人、不具合の再現とヘルプ記事の公開はそれぞれ2人が1人で対応できます。一方、請求調査はMayaだけに頼っています。
そのため、Mayaの休暇前に請求調査の体制を話し合う価値があります。ただし、どのチームでも請求調査を最優先で育成すべき、という意味ではありません。業務の発生頻度、対応できる人がいない場合の影響、ほかのチームがすでに代行できるかも考えます。
行の数字を合計して、メンバーの順位を付けるのは避けましょう。スキルによって難しさ、業務との関係、経験を積む機会が異なります。専門的な業務を担う人は合計点が低くても、ほかの人では代替できない役割を果たしている場合があります。
高い評価は、追加業務を引き受けられるという約束でもありません。指導を頼む前に、その人に時間があるかを確認します。そうしないと、負担を減らすための表が、頼りにされている1人の仕事をさらに増やしかねません。
1つの不足を具体的な育成計画にする
このサポートチームでは、Leoはすでに支援を受けながら請求案件に対応しています。全員を幅広い研修に参加させるのではなく、ペアで取り組む業務を絞って計画します。
| 項目 | 具体例 |
|---|---|
| 必要な状態 | 通常の請求内容の不一致を、1人で調査できる人がもう1人いる。 |
| 実践すること | LeoがMayaと代表的なケースに取り組み、使用した記録を説明し、専門担当者の承認が必要な場面を見分ける。 |
| 進歩を確認する根拠 | 合意した通常ケースを、Leoが手順ごとの指示なしで対応し、どの場面で上位担当者などに判断を求めるかを説明できる。 |
| 必要な支援 | Mayaがペアで取り組む時間を確保し、練習に適した記録を用意する。 |
| 次の確認時期 | ペアでの実践後、休暇中の代行をLeoに任せる前。 |
評価を変えるのは、適切な根拠が得られたときです。予定の日付になっただけで上げるものではありません。Leoが特定のケースでまだ助けを必要とするなら、その範囲を記録し、次に練習する機会を設けます。
Boardmixでスキルマップを作成・更新する
Boardmixのボードの中央に、人とスキルを対応づけた表を置きます。横に業務の定義と評価の凡例を並べ、選んだ育成活動のための小さな領域も用意します。基本的な表の配置や書式については、Boardmixのホワイトボード上の表の作り方(英語)も参考になります。
ボードは、話し合いと合意した計画の共有に使います。個人に関する機微なフィードバックを見せる相手は適切に限定し、非公開の根拠資料は本来の保管場所で管理しましょう。実務経験を積んだ後、担当業務が変わったとき、新たな業務上の必要が生じたときに見直します。日付だけを新しくするための更新は必要ありません。
Boardmixのボードを開き、まずは1つのチームと、そのチームで繰り返し行う重要な業務から始めましょう。最初に目指すのは、すべてのセルを緑色にすることではありません。「どの業務に代わりの担当者が必要で、その人が対応できるようになるには何をすればよいか」が分かる状態です。