スキルマップのスキルは細くしてはいけない理由

プロジェクトマネージャでもマネージャでも、実はメンバが持っているスキルを知らないことが多いのですよ。「えーうそー！」とおもうかもしれないけれど、そんなものです。

キャリアシートのような経験してきた業務経歴では案件名と主な適用技術名しかかかれないですから。無論、ずっと一緒にやってきたメンバなら覚えていることもあるかもしれませんが、そうしたケースは稀です。マネージャもメンバも動いてこの瞬間、偶然一緒になっただけなのですから。

チームのスキルマップのスキルの軸細かくしない

スキルはロールを記号で表記する

ロールはマネジメントしたい単位以上に細かくしない

チームのスキルマップのスキルの軸は細かくしない
スキルマップはメンバの名前とスキルの２つの軸で表を構成します。メンバの名前はズバリのでそのままメンバの名前を記載します。考えて書きたいのはスキルの軸です。

	スキルA	スキルB	スキルC	スキルD
名前	◎	◯	△

このスキルマップを作る目的はなんでしたっけ。一人ひとりのマネージャにより、そのスキルマップの使い方は違うと思うのですが共通しているのは、

というように目的とそれを実装したら運用が伴うということです。スキルマップを作成した目的を達成すれば不要になりそうですが、人は動きますから少なくともマネージャ業務を担っている間は必要そうです。

続けられる程度にしておかないとスキルマップを維持すること自体が負担になるので、あったらいいな、のような目的と密接に関連しない情報は載せることはやめたほうが良いです。

なので、目的を横目で見ながらスキルの軸を決めていきます。そこでオススメなのがざっくりと括ってしまう、というものです。

スキルはロールを記号で表記する
メンバが持っているスキルは、ただ持っていると表記してもそれで作られた表にあまり価値はありません。どんなレベルのスキルレベルかまで表現しないとせっかく一覧化した目的が果たせなくなってしまいます。

それぞれのマネージャでスキルマップを作る理由はあるのでしょうけれど、少なくともスキルレベルを識別できなければ価値はそれほどないし、育成のプランを考えたり、育成を意識したアサイメントでは使えませんから。

	スキルA	スキルB	スキルC	スキルD
名前	◎	◯	△

なので、記号でスキルレベルを表記します。つまり、記号に意味を持たせる、ということです。そのときのレベルは定義が必要です。一覧表ですから、様々なスキルの種類が記載されることになるでしょう。そのときに、スキルごとの記号が違ったり、意味合いが違うと可読性悪くなりますから、記号の意味は一定に定義します。

スキルはマネジメントしたい単位以上に細かくしない
その記号で何を表すかはマネージャのスキルマップを作る目的によりますが、考慮したほうが良いのは、細くしすぎない、ということです。記号の種類も３種類くらいで表せるようにしたほうが良いでしょう。

凡例　◎＝プロジェクトマネージャ　◯＝リーダ　△＝数回の経験　なし＝未経験

スキルの列に役割を表記することに違和感があるかもしれませんが、スキルはビジネスのソリューションや業種に結びつくので、そうした案件と定義をすると理解しやすいでしょう。つまり、スキルを使ったビジネスがあったときにどんな役割を担えるか、という意味です。

マネージャならビジネスに紐付けられますし、プロジェクトマネージャなら機能分担で紐付ければ良いでしょう。なので、あまり細かくする必要もないのです。