スキルマップ
https://gyazo.com/6974668ebab2a1930840e3993ac1b922
長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきますが、新しく作ったチームだったり新しいメンバーがチームにどんどん入ってくるような状況だと、誰が何をできるのかは意外とわからないものです。
一方でこのように見える化されていると、困ったときに誰に聞けばよさそうかがすぐに分かります。
とくに新しくチームの入った人が課題に遭遇したときには、チケットなどで聞いたりする以外に対面やDMで質問することになりますが、そのときにムダが少なくなります。 また得意なのかそうでないのかが分かっていることで、レビューの粒度や頻度を変えることもできるでしょう。 この図をみてみると、この仮想プロジェクトではFluentdを利用していることが分かりますが、それに対処できるのは1人しかいないことが分かります。 プロジェクトの重要な箇所でないのであれば構わないのですが、これがもしFluentdに非常に依存したプロジェクトであった場合、その1人が急病になってしまったり会社を辞めてしまうとプロジェクトの進行自体のリスクになってしまうことが分かります。 この場合はプロジェクトのリスクを低減するために早めにこのスキルを持った人をプロジェクトに入れるか他のメンバーがそのスキルを身につける必要があります。
効果：人前で宣言することによる学習速度の向上
この例では「・」をつけると今後学習したい、というのを示しています。
トヨタの場合は多能工星取表というものがあり、それを全部埋めていくことでより多くのことができるエンジニアとして認定されていきます。 1か月単位くらいで常時更新をかけていきます。
プロジェクトではどんどん変化がおこり場合によっては新しい要素技術が必要になるかもしれません。
それを反映していないと、そのうちなんの役にもたたなくなります。
また、例えば毎月更新するのにあわせてメンバーのスキルを1:1の会議などで確認することで、学習がどれくらい進んでいるのか、プロジェクトでどのくらいスキルを発揮できそうかが明らかになっていきます。
スキルが見える化されるとマネージャーはどうしてもそれを人事評価に使いたがりますが、それは避けるべきです。
特に具体的基準値が不明であればあるほど、評価が下がるのを嫌がって過大申告してくることもあり、それによって効果が失われてしまいます。
これは例えばコミットした回数、書いたコードの行数、さばいたチケットの数によって人事評価をしてしまった場合と同じような弊害があります。 これは上に書いた話とほぼおなじです。
プロジェクトを円滑に推進し、リスクを減らし、個人のスキルを高めるためにやるのであり、「全社標準エンジニアスキル」みたいにしてしまうとプロジェクト固有の情報がどんどん見えなくなっていきます。
また全社共通というのは評価を意図しているケースが多いものなのでその点でもダメでしょう。
運用：項目はチームで決めて形式も変えてよい
前述の通りチームのものなので、必要に応じて項目を追加したりフォーマットを変えて構いません。
たとえば表の例では、Gitはほぼ全員が習得しているので敢えてこの表で見える化されている必要はないかもしれません。 また例では技術的な項目が多くなっていますが、見積りとかドキュメント作成とか他にもプロジェクトに必要なスキルはたくさんありますので、必要だと思うものを入れてください。