【Quipperブログ】異動のおともにスキルマップ

こんにちは。Quipper採用担当の鈴木です。今回の記事は、エンジニアの@wozaki による「異動のおともにスキルマップ」です！是非、ご覧ください！

こんにちは、Web Engineer の @wozaki です。

今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。

　　　　　　　　　　スキルマップの例引用スキルマップ作成のすすめ | Ryuzee.com

概要

チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった
個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した
結果
- 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った
- スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった
- 個人の志向性は、スキル伝承時の期待値調整にも利用できた

スキルマップ導入の背景

スキルマップ導入には、3つの背景がありました。

スキル増加と、不明瞭なオンボーディング
メンバーの離籍と、スキル喪失
個人の志向性の多様化と、それが考慮されない割り振り

スキル増加と、不明瞭なオンボーディング

ブランド名をスタディサプリにしてから4年目を迎え、プロダクトの成長に比例して開発に必要なスキルが増えてきました。また、2018年8月から11月の間に新メンバーが4人参加し、1年以上在籍している既存メンバー3人と合わせて7人のチームになりました。

チームで必要なスキルを一覧化していなかったので、新メンバーにとって、何のスキルを期待されているのか不明という課題がありました。

メンバーの離籍と、スキル喪失

新メンバー参加前は、チームの人数は2、3人だったので、個人の裁量が大きくスキルが属人的になりがちでした。そのため、メンバーが離籍するとキャッチアップに苦労することが多かったように思います *2。

ドキュメント化が難しいスキルも存在する、またドキュメントを最新に保ち続けることも難しいため、在籍中に伝承できると効率的なのですが、チームで必要なスキルと、チームメンバーのスキルレベルが不明なので、伝承すべきスキルが不明という課題がありました。

他方、スキルを属人化させることで、チームの学習効果、パフォーマンスを高めるトランザクティブ・メモリーという考えもあります。

・「組織のメンバー全員が同じことを知っている」ことではなく、「組織のメンバーが『ほかのメンバーの誰が何を知っているのか』を知っておくことである」というものです

・ヒト一人の知識のキャパシティーには限界があります。それなのに全員が同じことを覚えていては、効率が悪いはずです

・組織の本来の強みとは (中略) それぞれの専門知識を持って、それを組織として組み合わせることにあるはずです

引用入山章栄. ビジネススクールでは学べない世界最先端の経営学

ただし、スキル喪失のリスクをケアしつつ、トランザクティブ・メモリーを実践するためには、チームで必要なスキルと、チームメンバーのスキルレベルが明確である必要があります。

個人の志向性の多様化と、それが考慮されない割り振り

チーム人数の増加により、スキルの得意不得意、趣味嗜好の多様性が生まれました。

日々の開発はスキルを伸ばす機会でもあるのですが、個人の志向性(どのスキルを伸ばしたい/伸ばしたくない)が考慮されずに割り振られることもありました。 各々が志向性を明示していないので、お互い把握できていないことが原因でした。*3

ユーザへ価値を素速く提供することを優先としつつ、個人の志向性も尊重したいと思っています。なぜなら、ユーザへ中長期的に価値を提供し続けるためには、個人の志向性、中長期的なキャリアに沿ってスキルを伸ばせる環境が必要だからです。*4

他社の事例とカスタマイズした点

同じような課題は他社でも存在し、その対策としてスキルマップを導入しているそうです。

これらの事例を参考にしつつ、個人の志向性について詳細に表現できるようにカスタマイズして導入しました。

伸ばしたいスキルだけでなく、伸ばしたくないスキルも表現できる
スキルのレベルと、志向性を同時に表現できる

スキルマップ詳細と運用方針

導入したスキルマップの詳細と運用方針をご紹介します。

管理対象スキル
- チームで必要なものに絞って選定する
- 問い合わせ対応、決済知識、プログラミング言語など
スキルレベルの評価基準
- ☆: 業界レベルで強い!
- ◎: 他人をサポートできる
- ◯: 一人でできる
- △: 助けがあればできる
- ×: できない
リスクの可視化
- 他人をサポートできる人が、二人以下のスキルは色を変える
志向性の表現(スキルレベルに上乗せして表現可能)
- 緑: 伸ばしていきたい
- 紫: 伸ばしていきたくない
公開範囲
- 心理的安全性を配慮して、チームメンバーのみに限定して公開
スキルレベル見直しのタイミング
- 不定期。個人に任せる
ツール
- Google スプレッドシート

運用結果

運用結果をチームで振り返ったのでご紹介します。

運用期間
- 2018年12月から現在
チーム人数
- Web Engineer 7~9名
- Product Manager 1~3名

オンボーディングについて

良かったこと

チームメンバーとして必要なスキルが明確になった。チームの役割の理解に役立った
チームの守備範囲がなんとなくわかって newbie 的には安心できる
スキルが詳しい人は、Slackで聞けば誰かが答えてくれるし*5、詳しい人にリダイレクトしてもらったので困らなかったが、リダイレクトしてもらう申し訳無さが減った

課題

あくまでもオンボーディングプロセスの一つ。スキルマップを含めたオンボーディングは別途設計する必要がある*6

スキル喪失リスクの対策について

良かったこと

喪失リスクがあるものは勉強会を開いてスキル習得をサポートした
一定数スキルをもったメンバーが存在し、普段の開発で関連が低いスキルは、伝承しない判断もした
スキル伝承後、伝承したメンバーのスキルレベルの変化を、理解度の参考にした

課題

スキル喪失リスクは無いが、コードレビューが回らないスキルは可視化できなかった
- レビューワーの人数が決まっている場合は、その人数を下回ったら可視化する
人によって◯のレベルが違う
- 自己評価が低いメンバーに対して、上位レベルの評価を促してもいいかもしれない
- 評価に関して、ある程度のあたりを付けるくらいの共通認識がなかった
スキルレベルを定期的に見直す機会を設けないと廃れる
- 定期的チームで見直す機会を設ける
完全に理解したので ◎ を付けたが、数日後△になる
理解しているか検証する機会がないと、スキルの評価が妥当か分からない*7。1年に1回くらいの頻度で必要になるスキルは、伝承できない可能性が高そう
- そのようなスキルになる可能性が高いものは、ペア/モブプログラミングで取り組むのがいいのかもしれない

個人の志向性の配慮について

良かったこと

タスク割り振り時に、志向性が予め分かっていると調整が楽
スキルを伸ばしていきたいメンバーが存在すると、勉強会開催の心理的ハードルが下がった
伸ばしていきたい/伸ばしていきたくないスキルの傾向が分かった
- 伸ばしていきたいと評価されたスキルの例
- - 自分が苦手としているスキル
  - 直近の開発で必要なスキル
  - 十分に習得しているが、更に伸ばしたいスキル
- 伸ばしていきたくないと評価されたスキルの例
- - トイル、サービスにとって必要な定常的な手作業
  - 廃れ気味の技術
  - 十分に詳しい業務知識(◎以上かつ伸ばしていきたくないの組み合わせは、積極的に伝承したい気持ちの現れ)
伸ばしていきたくないスキルを書かないメンバーもいることが分かった
- まんべんなく ◯ を目指す志向性
チームで伸ばしたいスキルが少ないということは、チームが挑戦していない兆候を検知することに使えるかも