スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。
チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。
作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。
このスキルマップの効用と運用について見ていきましょう。
効果：スキルの見える化
長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきますが、新しく作ったチームだったり新しいメンバーがチームにどんどん入ってくるような状況だと、誰が何をできるのかは意外とわからないものです。一方でこのように見える化されていると、困ったときに誰に聞けばよさそうかがすぐに分かります。とくに新しくチームの入った人が課題に遭遇したときには、チケットなどで聞いたりする以外に対面やDMで質問することになりますが、そのときにムダが少なくなります。 また得意なのかそうでないのかが分かっていることで、レビューの粒度や頻度を変えることもできるでしょう。
効果：リスクの見える化
この図をみてみると、この仮想プロジェクトではFluentdを利用していることが分かりますが、それに対処できるのは1人しかいないことが分かります。プロジェクトの重要な箇所でないのであれば構わないのですが、これがもしFluentdに非常に依存したプロジェクトであった場合、その1人が急病になってしまったり会社を辞めてしまうとプロジェクトの進行自体のリスクになってしまうことが分かります。いわゆるSPOF(Single Point Of Failure：単一障害点)のようなものです。この場合はプロジェクトのリスクを低減するために早めにこのスキルを持った人をプロジェクトに入れるか他のメンバーがそのスキルを身につける必要があります。
効果：人前で宣言することによる学習速度の向上
この例では「・」をつけると今後学習したい、というのを示しています。人間の特性として人前で宣言すればやらざるを得なくなるというのがあるので、学習を進める効果もあります。トヨタの場合は多能工星取表というものがあり、それを全部埋めていくことでより多くのことができるエンジニアとして認定されていきます。
運用：フィードバックプロセスを短いサイクルで回す
このスキルマップは一度作ったら終わりではありません。1か月単位くらいで常時更新をかけていきます。プロジェクトではどんどん変化がおこり場合によっては新しい要素技術が必要になるかもしれません。また人のスキルも日々向上していきます。それを反映していないと、そのうちなんの役にもたたなくなります。 また、例えば毎月更新するのにあわせてメンバーのスキルを1:1の会議などで確認することで、学習がどれくらい進んでいるのか、プロジェクトでどのくらいスキルを発揮できそうかが明らかになっていきます。
運用：人事評価とからめない
スキルが見える化されるとマネージャーはどうしてもそれを人事評価に使いたがりますが、それは避けるべきです。特に具体的基準値が不明であればあるほど、評価が下がるのを嫌がって過大申告してくることもあり、それによって効果が失われてしまいます。これは例えばコミットした回数、書いたコードの行数、さばいたチケットの数によって人事評価をしてしまった場合と同じような弊害があります。
運用：全社共通のスキルマップにしない
これは上に書いた話とほぼおなじです。プロジェクトを円滑に推進し、リスクを減らし、個人のスキルを高めるためにやるのであり、「全社標準エンジニアスキル」みたいにしてしまうとプロジェクト固有の情報がどんどん見えなくなっていきます。また全社共通というのは評価を意図しているケースが多いものなのでその点でもダメでしょう。
運用：項目はチームで決めて形式も変えてよい
前述の通りチームのものなので、必要に応じて項目を追加したりフォーマットを変えて構いません。たとえば表の例では、Gitはほぼ全員が習得しているので敢えてこの表で見える化されている必要はないかもしれません。また例では技術的な項目が多くなっていますが、見積りとかドキュメント作成とか他にもプロジェクトに必要なスキルは沢山ありますので、必要だと思うものを入れてください。
ということで…
まずは一度やってみると良いと思います。
著作
著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕
出版社：インプレス( 2014-09-19 )
定価：￥ 4,320
Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説
Chef実践入門 ~コードによるインフラ構築の自動化 (WEB+DB PRESS plus)
著者／訳者：吉羽 龍太郎 安藤 祐介 伊藤 直也 菅井 祐太朗 並河 祐貴
出版社：技術評論社( 2014-05-22 )
定価：￥ 2,992
スタンドアロンでのChef Soloの利用から始めて、クックブックの書き方や注意すべきポイント、さらにはクックブックのテスト、継続的インテグレーションなど幅広いトピックを解説
著者／訳者：西村直人 永瀬美穂 吉羽龍太郎
出版社：翔泳社( 2013-02-13 )
定価：￥ 2,520
スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
著者／訳者：Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
出版社：アスキー・メディアワークス( 2013-03-08 )
定価：￥ 1,680
スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
How to Change the World 〜チェンジ・マネジメント3.0〜
著者／訳者：Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
出版社：達人出版会
定価：500円
どうすれば自分たちの組織を変えられるだろう？それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック
寄稿
著者／訳者：原田騎郎, 吉羽龍太郎, 山口陽平ほか
出版社：技術評論社( 2014-10-24 )
定価：￥ 1,598
特集の「強いチームの作り方」を寄稿。刻々とニーズが変化する近年のソフトウェア開発では、既成観念にとらわれない新しいアイデアが不可欠ですが一方で意見の対立がメンバーの衝突を引き起こすことも多くあります。本特集では、意見の違いをメンバーどうしが受け入れ、新しいアイデアへつなげていけるチームの作り方を解説しています
著者／訳者：Mitchell Hashimoto
出版社：オライリージャパン( 2014-02-21 )
定価：￥ 2,808
Vagrantの概要やマシン設定から、プロビジョニング、ネットワーク、ボックス、さらにはプラグインによる拡張までを網羅した開発者自身による解説書。日本語版限定で「Vagrantプラグイン」と「Packer」について寄稿。また伊藤直也さんによる描きおろしも含まれている
100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊
出版社：翔泳社( 2012-02-22 )
定価：￥ 1,944
ソフトウェア技術者のための名著案内。国内最大級の開発者向けカンファレンス「DevelopersSummit」のベストスピーカーを中心とした、100名の執筆陣が書籍を選定・紹介。アジャイルプラクティスについて寄稿