魔法のチョークで描いた窓

スキルマップ（星取表）が、なぜか「チームの雰囲気を悪くするツール」になってしまった。そんな経験はないでしょうか。今回は、スキルマップのあるべき姿を、ソフトウェア開発の現場目線で考えてみます。

スキルマップとは

スキルマップとは、横に各種のスキル、縦にエンジニアを並べ、星（点数）を付けていくことで、誰がどのようなスキルを持っているかを可視化する表です。チームの状況を見える化したい、などが導入の背景でしょう。

私自身、これまでのキャリアの中で何度もこの表を見てきました。しかし正直なところ、ポジティブな結果に結びついている場面はあまり多くありませんでした。むしろ、チームに微妙な空気をもたらしたり、明確な反発を招いたりする様子を目にしてきました。

スキルマップの誤用

問題は、スキルマップそのものというより、使い方にあるのだと思います。具体的には、次のようなことが起こります。

• エンジニアの性能表になってしまう
• エンジニア番付になってしまう

これでは、チームにとっても、各エンジニアにとっても、スキルマップを有用なものとは感じにくいでしょう。結局、目的が見えず、疑心暗鬼だけが残ってしまいます。

エンジニアの性能表

列挙する項目を間違えると、スキルマップはすぐに「性能表」になってしまいます。たとえば、次のような項目を並べたケースです。

• Java の Generics を使える
• React でカスタムフックが作れる

いかにも開発チームのスキルマップらしく見えます。しかし、これらの項目が、プロダクトを成長させるうえでなぜ必要なのかは見えてきません。そうなると、記入する側の関心も、チームにどう貢献するかではなく、自分をどう見せるかに寄っていきます。職務経歴書を書いているときと、あまり変わらなくなってしまうのです。

エンジニア番付

さらに、各エンジニアに星（点数）が付くことで、スキルマップはそのまま「番付」のように見えてきます。すると、これが公平な評価のためのデータとして使えそうだ、という誤解まで生まれます。実際には、自己申告による主観評価の寄せ集めにすぎないにもかかわらずです。

同時に、エンジニア側にも「これは評価に使われるのではないか」という憶測が自然に生まれます。こうした自己申告に慣れている人なら◎を連発するでしょうし、日本の組織に長くいる人ほど、むしろ控えめな自己評価を書きがちかもしれません。結果として、声の大きい人ほど優秀に見える、不公平な評価のためのエビデンスができ上がってしまいます。

スキルマップの本来の役目

ここまでに挙げた誤用の問題は、列挙する項目が一般的すぎることにあります。ここに置くべきなのは、一般的な「技術」ではなく、私たちのプロダクト作りに特有の「工程」です。言い換えれば、プロダクトを作り上げるためのそれぞれのステップです。

そうすれば、スキルマップはエンジニア個人の性能や序列を示すものではなく、各工程が属人化していないかを示すものになります。つまり、チームの「ボトルネック」が見えてくるわけです。

さらに、工程を定義するうえで、既存の組織図に縛られる必要はありません。周辺の工程まで含めれば、エンジニアが越境しながら活動領域を広げられているかどうかを知ることもできるでしょう。

何を促していくか

スキルマップは、プロダクトの制作過程にある制約を明らかにするものです。それを踏まえて、チームメンバーがより多くの工程を担えるようになることによって、チームとして困難を乗り越えていくためのものだと言えます。

ただ、この目的を実現するには、目的を唱えるだけでは不十分でしょう。もし、エンジニアの性能表を「悪気なく」作ってしまうカルチャーがあるのだとすれば、まずはそのカルチャー自体を変えていく必要があります。

チームで協力するという大原則を共有することが大事です。さらに、各メンバーに期待しているのは「Java10年」のような一般化された経歴ではなく、10年の人生経験であり、その人自身のパースペクティブなのだということが伝わっていなければなりません。一人の人間として尊重されていると感じられなければ、スキルマップに正直に協力しようとは思えないはずです。

おわりに

AIによって、エンジニアは自然に多能工化していくかもしれません。しかし、工程の定義や、人間がどこで意思決定し、何に責任を持つのかを明らかにしなければ、生産性と品質を維持することは難しいと思います。AIに何を任せ、何を人間が担うのかを考えるためにも、スキルマップはまだ有用な手段であり続けそうです。