プロダクトチームにおけるスキル維持の難しさ
プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。
これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが、あまり手が入らない領域は時間とともに記憶から消えていきます。ドキュメンテーションをしっかりすることである程度防げますが、それでも失われる暗黙知は存在します。また、異動や退職などによって人がチームから去ることもあります。異動や退職の際に、ほとんどの現場では引き継ぎが行われると思います。しかし、引き継ぎによって余すところなく知識やスキルが、残ったメンバーにすべて伝わっているさまを、わたしは見たことがありません。数か月ほど経ってから引き継ぎ漏れがあったことに気がついて、苦労した経験は一度や二度ではありません。
残念ながらプロダクトに関する知識やスキルを、未来永劫維持しつづける方法は存在しませんが、いくつかの工夫によってそれを最小限に留めたり、失われたものを後から獲得しなおしたりすることはできると思っています。今回は、わたしが所属している、サーバーの監視・管理サービスである「Mackerel」というサービスの開発チームで実際に行っている工夫として、「スキルマップ」と「ソフトウェア式年遷宮」をご紹介しようと思います。
スキルマップ運用のコツ
「スキルマップ」はチームが保有すべき知識やスキルを、マトリックス図で表現したもののことを言います。チームとして維持すべき知識・スキルを洗い出し、誰が、どの程度それを保持しているのかを明らかにします。詳しくはRyuzeeさんのブログ記事が詳しいので、ご存知でない方は一度そちらを参照してみてください。
スキルマップのコツは難しく考えずにまずやってみる
本稿では、スキルマップを運用するためのコツを紹介したいと思います。
実際にスキルマップを運用しはじめると、スキルマップそのものの維持が思いの外難しいことに気づかされます。まず、最初のコツは、スキルマップで可視化すべき項目について、最初から完璧を求めない、ということです。
スキルマップでどの項目を一覧化するか、というのはなかなか難しい問題です。扱っているプログラミング言語、ミドルウェア、インフラ、クラウドプラットフォーム、業務知識など、分類や粒度がまちまちなものを扱うことになるからです。例えば、Javaを扱っているチームがそれをスキルマップに表現するとして、アプリケーションフレームワークやライブラリについての知識などをどこまで可視化するべきか。何ができるようになれば、Javaについての知識を習得している、とみなしてよいのか、など細かいことを考え始めると身動きがとれなくなってしまいます。この場合は、最初はあまり難しいことを考えずに、スキルマップにはとりあえず"Java" とだけ書いて運用をはじめてしまいましょう。
スキルの習得度も、深く考えずに自己申告で良いです。そして、運用しながら、例えばSpring BootはJavaとは分けて保有スキルとして記載したくないだろうかなどをチームで議論しながら細分化したり、または細かすぎる粒度をひとまとめにしたり、メンテナンスしていきましょう。
スキルマップを維持するコツ
スキルマップを維持するコツの中で最も重要なのは、どのようにして継続してメンテナンスをするかです。
いざチームメンバーがチームを離れることになったとして、その結果をスキルマップで見てみようと思っても、それが1年前に作られてから一度もメンテナンスされていなければ何の役にも立ちません。おすすめは、定期的なふりかえり会のアジェンダにスキルマップのメンテナンスを入れてしまうことです。例えば、毎週とか隔週とか期間を区切って、定例会としてその期間のチームの状況をふりかえる会を設定します。そのふりかえり会の一環として、スキルマップをメンテナンスしましょう。保有スキルにアップデートがないか、チームとして維持すべきスキルに増減はないか、などをスキルマップに反映しましょう。あとから遡って見られるように、メンテナンスのたびにもともとのスキルマップをコピーして、履歴を残しておくのもおすすめです。
わたしのチームでは2週間おきにふりかえり会を実施します。Googleスプレッドシートにスキルマップを作成しているので、会議室のプロジェクターにそれを投影しながら、シートをコピーして新しいシートを作成します。それをメンバーに手元の端末で一斉に編集してもらいます。Googleスプレッドシートのリアルタイム編集機能によって、プロジェクターに投影されたスキルマップがどんどん更新されていくので、それを眺めながらディスカッションなどを行います。
2週間おきくらいであれば、スキルマップにそれほど大きな変化はありません。しかし、その変化が蓄積していくと、気がつかないうちに大きくアップデートされていきます。チームからメンバーが離れる、というときがスキルマップの真骨頂です。ふりかえり会の場で、プロジェクターに投影されたスキルマップから、離脱するメンバーの行を削除してみましょう。場合によっては、チームから驚くほど知識やスキルが失われることに気づくことがあります。
例えば、フロントエンドに強いエンジニアが離脱すれば、当然チームのフロントエンドのスキルは一時的に低下します。そのような分かりやすいスキルであれば、わざわざスキルマップを用いなくとも自明なのですが、スキルマップで細かく可視化していると、実はスキルマップを運用していなければ、それを失ったことにすら気がつかないスキルがあり得たかもしれない、ということを発見することがあります。このようなスキルを可視化することで、本来人知れず失われるおそれのあったスキルに着目し、意識的な引き継ぎやスキルの継承に取り組むことができるのです。
