チームのアジリティはスキルマップのどこに表れる？
はじめに
安ヶ平です。普段はSIerでスクラムマスターとして働いています。
メンバのスキルを星取表の形で可視化するスキルマップ。チーム発足時のメンバのスキルの可視化、離任によるリスクの可視化、学習モチベーションの向上などを目的に作成、運用しているチームは多いのではないでしょうか？
スキルマップの運用について考えていた際、実はスキルマップにチームのアジリティ*1が表れていて、それを認識した上でスキルマップを運用することで、チームのアジリティを向上させることができるのでは？という仮説が浮かんだので、この記事で説明します。
スキルマップ自体の説明は、ryuzeeさんのブログエントリスキルマップ作成のすすめをご覧いただくのが良いと思います。
私なりのスキルマップの作り方
私はスクラムチーム発足時に、インセプションデッキ作成などと共にチームでスキルマップを作成するので、基本的にはPOっぽいスキルやSMっぽいスキルもスキルマップに入れて、POと一緒にスキルマップを作ります。そうすると私のチームのスキルマップは、図のように、DEVっぽいスキル、SMっぽいスキル、POっぽいスキルにゾーンが分かれたスキルマップになります。
スキルマップの運用で難しいところ
私はスキルマップを作成した後、ふりかえりの場などを活用して定期的にチームで話し合って、スキルマップを更新しているのですが、このとき難しいと思うことがあります。
それはSMっぽいスキル、POっぽいスキルの更新です。DEVっぽいスキルの部分は、項目自体が細分化されたり（例えばAWSという項目は早い段階で細分化される気がする）、スキル度合いもぐんぐん向上していくはずなので、チームの会話は弾みながら更新できるのですが、SMっぽいスキルやPOっぽいスキルの部分は、ついつい更新をおざなりにしてしまっていました。
理由としては、DEVは複数名いるのに対して、POやSMは基本一人なので、話し合いの中での優先順位を下げてしまっていたというのと、私がスキルマップの主な目的を「DEVのスキル可視化」と捉えていたというのが正直なところです。
チームのアジリティ
唐突に話が変わるのですが、私はチームのアジリティは、メンバがお互いのロールについてどれだけ共通認識を持っているかによって決まると思っています。
DEVがPOに提案しても、POが開発のことをわかっていなかったら、説明に時間がかかります。
POがSMと会話しようにも、SMにPOを支援する度量がないと、バックログ作成が進みません。
SMがDEVにアジャイルマインドを伝えようとしても、DEVが興味なかったら開発は進みません。
チーム発足時に上記の状態だったとすると、それはチームのアジリティが低い状態だと思います。
その後チームで会話を重ねてお互いのロールについて理解することで、チームのアジリティは向上すると思います。
チームのアジリティはスキルマップのどこに表れる？
さてここまでの内容で、「チームのアジリティはスキルマップのどこに表れる？」に対する私の考えがわかったでしょうか。
私は下図の通り「メンバが自分以外のロールのスキルをどれだけ有しているか」にチームのアジリティが表れると思います。
他のロールのスキルについて、高いスキル度合いを有する必要はないと思います。
ただDEVであれば、POがバックログの説明を聞いて、その裏にある業界知識や業務をイメージできる程度のスキルがあるといいし、POであれば、DEVがテストの自動化を訴えてきたときにその優先順位を判断できる程度のスキルがあるといいと思います。
目指したいスキルマップの運用
スキルマップを使って、メンバが他のロールのスキルをどれだけ有しているかを可視化することで、それぞれのロールに対して理解が足りないところは勉強会で補うことができ、結果としてチームのアジリティが向上すると考えているので、今後はこの点をチームメンバに伝えた上で、スクラムチーム一丸となって、改めてスキルマップを運用していきたいと思います。
さいごに
この記事では、スキルマップを見たときに「メンバが他のロールのスキルをどの程度有しているか」を評価することで、チームのアジリティを可視化・向上させることができるのでは？という仮説を説明しました。実践して学びを得たら、また記事にしたいと思います。
*1:この記事において「チームのアジリティ」とは、メンバが何かを提案してから、チームとして合意して具体的なアクションに繋げるまでの期間を指しています。この定義は私の勝手なイメージなで出典はないので、一般的なイメージと異なっていたらすみません。。。なおチームのアジリティという考え方は、広木さんの「2つのDX」とDX Criteriaのお話を聞いていて思いついた考え方です。
