こんにちは。去年買った春夏の洋服が窮屈に感じられる鈴木です。縮んでしまったのでしょうか。
さて、このたび弊社の各開発チームで「スキルマップ」を作ってみたので、その経緯や作って感じたことをお伝えします。

経緯/背景

以前からスキルマップの存在は知っていましたが、ryuzeeさんのブログ記事 ¹ やデブサミでの講演 ² を受け「作ってみよう！」と思い立ちました。

弊社では現在5つの開発チームがあり、それぞれに1つまたは2つの自社サービス開発を担当。各チームはフロントエンドエンジニア/バックエンドエンジニア/インフラエンジニアから構成され、すべてのチームが機能横断的であることを目指しています。期待されるスキルセットをチームとして備えていることが、スピーディな開発や自己組織化に必要と考えているからです。

新人さんの入社時や会社として新サービスを立ち上げる際にチームメンバーの出入りが発生します。「その出入りによるスキルセットの変化を見える化したい」ということが、スキルマップを作ろうと考えた第1の理由です。

どう作ったか

スキルマップを作るのは初めて。各チームにスキルマップを意識してもらいたかったので、以下のように段階を経て作っていきました。

1. エンジニア全員で集まり、各チーム別にスキル項目を検討/他チームと意見交換
2. 共通のテンプレート(Googleスプレッドシート)を用意(ほぼryuzeeさん記事のフォーマット)
3. 各チームで集まってスキル項目とスキル度合いを記入
4. 各チームのスキルマップを持ち寄り、今後の使い途などを意見交換

3.の「スキル度合いの記入」は、チームメンバーで集まって一緒に進めることをお勧めします。各自の自己申告で済ませることもできますが、スキル度合いの「差」に注目することがチームビルディングの機会になるからです。

作ってみて感じたこと

4.の意見交換で得られた感想を以下にまとめます。

メンバーの優劣を示すものではない

「人事評価には利用しない」と言われますが、メンバー間においても「優劣を示すためのものではない」という共通認識をとっておくべきだと思います。スキルマップは「チームに期待されるスキルセットを網羅できているか」「特定の人に依存しているなどのリスクがないか」といったチームの課題を共有するためのツールです。メンバーの優劣ではなく、チームが抱える課題に目を向けさせる必要があります。

積極的に差をつける

「優劣ではない」という認識を作った上で、積極的にスキル度合いに差をつけると良いのではないか？ と感じました。差があるということは、「Aさんにはできるけど、Bさんにはできない何かがある」ことの表現です。なあなあに「同じくらいのスキルだよね」とするのではなく「あなたが持っている〇〇スキルを私は持っていないので習得していきたい」というような意見交換をする方が、メンバー同士の良い関係づくりになるでしょう。³

マネージャーと定期的に共有する

メンバーから「定期的に見直すべきだけど、いつやろうか？」「チームにいるメンバーのスキル習得だけではどうにもならないことあるよね？」といった意見がありました。その通りで、「足りないスキルを持つ人を採用してほしい」「スキル習得のために一定の業務時間を充てたい」などマネージャーと相談すべき状況もあるでしょう。チームとマネージャーのコミュニケーションツールとして定期的に共有することが、継続的なスキルマップ運用に必要だと感じました。

終わりに

今回スキルマップを作ってみて、

• チームが機能横断的であるか確認する指標として
• チームビルディングのツールとして
• チームとマネージャーのコミュニケーションツールとして

有効であるという感触を得ました。4月にフロントエンドエンジニアが中途入社したので、そのチームからも「ちょうど新人さんが入ったので役に立った」という感想をもらっています。

当初気になっていた「スキルセットの変化」は今後の運用で見ていくつもりです。特に複数の開発チームを抱えている会社/組織で試してみてはいかがでしょうか。