スキルマップ
概要
複数チームで1つのプロダクトを開発する場合、開発対象であるコンポーネントでチームを分けるのではなく、各チームが複数コンポーネントを扱うことができ、単独で価値を提供できるフィーチャーチームを組ませる方が良い。 フィーチャーチームがうまく機能しない場合、原因の一つにスキルの偏りが考えられるため見える化して対策をうつとよい。
詳細
作り方
- チームの開発に必要な技術をリストアップする
- 開発言語(C/C++/C#)、ミドルウェア(DB, Webフレームワーク)、ネットワーク知識(HTTP )、構成管理(Git)、テスト関係、ファシリテーションなど
- チームメンバのそれぞれに、各技術に対する自信度を記入してもらう
- ◎:得意、○:一人でできる、△:助けてもらえばできる、・:今後頑張りたい、空欄:できない など
- チームメンバの見える所に置く。印刷して貼るなど。
- 定期的(数ヶ月に1度とか)にスキルマップを更新する。
効果
- 質問相手が探しやすくなる。得意・一人でできる メンバに聞きに行けば良い。
- チームに不足してるスキルが明確になる。得意・一人でできる人数を数えればトラックナンバー1を早期に発見することができる。
- チーム分けを行う際にスキルの偏りがわかりやすくなる
注意点
記入者の意見を尊重する・人事評価を絡めない
「得意・一人でできる」など客観的な基準ではないので、記入してもらった後に評価を上げたり下げたりしない。 「各人の現状認識の共有、過去の記入結果との比較、今後学習したいと考えている項目の宣言」ぐらいに扱う。
また「スキルを幅広く身につけている人が優れている」ことはないので、人事評価にも利用しないこと。
チームの成長に必要な技術をリストアップする。
開発に必要な知識・技術はスキルマップに表しきれないほどあるかもしれないが、全員が一人でできると回答している基本技術や、今現在の開発に必要のない技術は項目として選ばない方がよい。
FAQ
各自の技術を見えるようにして貼り出すと嫌がる人がいるのでは
アジャイル開発・スクラムに取り組んだことがない人がよく挙げる懸念事項。 チームで開発を進めるうちに各人の得意・不得意分野、力量は互いにつかめてしまうもの。
TIPS
- 「今後習得したい」の記号を「↑」で表現するとやる気が表せていい感じ。
- スキルマップの下部に「◎:得意、○:一人でできる」の数を集計して表示するとまさに「トラックナンバー1」があぶり出される。目で記号を見ていても深刻に感じないので実際に集計してみた方が良い。
