こんにちは。Mackerel開発チームディレクターの id:daiksy です。
Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。
振り返りでKPTをやめた
Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。
チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。KPTとは、Keep, Problem, Tryの頭文字をとったもので、次のような手順で振り返りを行っていきます。
まず、Keep(継続したいこと・良かったこと)を洗い出します。Problem (問題・課題)よりも先にKeepの洗い出しをするのには理由があり、一般的にネガティブな議論よりもポジティブな議論を先行して行ったほうが、場が和やかになり、その後の問題点に関する議論も比較的穏やかに行えるようになると言われています。
Keepの抽出が終わったら、次にProblemを抽出。ここでいったんそれぞれの項目を深掘りし、議論していきます。KeepとProblemの議論が一段落したら、明らかになった課題を解決するための取り組み、Try(次にやること)を決めます。ここで決めたTryが、次のスプリントに取り組むべき具体的なアクションとなります。
KPTはあくまでも振り返りのための1つの手法に過ぎません。振り返りは、レトロスペクティブとも呼ばれ、以下の5つのフェーズで構成されるとされています。
- 導入
- 情報収集
- アイデア出し
- 次のチャレンジの決定
- 終了
本来、レトロスペクティブには、上記5つのフェーズに対してそれぞれ複数の手法が存在しており、チームやプロダクトの状況に応じて、それらを適切に組み合わせて行っていきます。つまり、レトロスペクティブ全体を設計する必要があるのです。
KPTはたいへん便利なフレームワークで、上記5つのフェーズの2から4までをこれ1つで包含しています。KやPを羅列することで、チームの状態についての情報を収集する(フェーズ2)。それぞれを深掘りしつつその対策を考えていく(フェーズ3)。次のスプリントのTryを決める(フェーズ4)。といった具合です。
このように、KPTをやれば、レトロスペクティブで定義されている振り返りの手順をだいたい漏れなく実施できるので、多くの現場で好まれて使われており、Mackerelチームでもこれを採用していました。
長らく続けていくうちに、ぼくはこのKPTに課題を感じるようになってきました。
KPTは毎回Problemを抽出する必要があります。それに対するTryも。ただ、チームで2週間ごとに振り返りをしていて、そんなにしょっちゅう重要な、すぐに解決せねばならないProblemは毎回あるものでしょうか?
毎回ProblemからTryを抽出し、次のスプリントの取り組みとします。しかし、他の優先度の高いタスクなどの影響を受けてTryに取り組めないスプリントが続き、結果としてチームにフラストレーションが溜まるといったことも起きていました。タスクの優先度によって処理されないTryなのであれば、実は深刻な問題ではなかったりするのではないでしょうか?
長く続けていくうちにKPTそのものがマンネリ化して、それに伴ってProblemを無理やりひねり出す、というような状況に陥ってはいないか。つまりチームとして、より本質的な課題と向き合って対処していくには、KPTは今のMackerelチームにとっては合っていないのではないか、といったことを考えました。ここでいう「本質的な課題」とは、KPTのProblemで刹那的に話題にあがるようなものだけでなく、プロダクトとして長期的に取り組まねばならないことも含みます。
そうして、Mackerelチームではレトロスペクティブを再設計することにしました。
書籍『アジャイルレトロスペクティブ』*1を参考に、まずは以下のアクティビティの組み合わせを設計しました。各アクティビティの詳細は、書籍を参照してください。
- 導入
- Check-in
- 情報収集
- Time Line
- アイデア出し
- Prioritize with Dots
- 次のチャレンジの決定
- SMART Goals
- 終了
- Appreciations
Mackerelチームは東京と京都の2拠点に別れたリモートチームです。振り返りもテレビ会議ごしにやっています。ですので、いったん丁寧にレトロスペクティブの原則に則って設計をしたあと、リモート用にアレンジをしました。最終的に、Time Lineを主軸に自分たちなりにアレンジしたレトロスペクティブは以下のようなものになりました。
Time Lineアクティビティは、"時系列"の名の通り、スプリント中に起きた出来事(事実)を客観的に記述します。正式にはちゃんと時系列順に並べたいのですが、模造紙と付箋などと違ってオンラインで項目を任意に並べ替えるのは大変なので、Mackerelチームでは時系列順にはあまりこだわっていません。スプリントの出来事がちゃんと出せていれば良しとしました。
上記スクリーンショットのようなGoogle スプレッドシートを共有し、オンラインのリアルタイム編集機能で各自記載していきます。
出来事を書いてもらい、その横に、その出来事についての自分の感情を書いてもらいます。リストから絵文字を選択できるようにし、選択された絵文字によって条件付き書式で背景色を変えています。
あとからシートを見返して、「このスプリントは黄色が多いからちょっと問題ありそう」「このスプリントは緑が多いから良いスプリントでしたね」のような概観をつかむことができます。また、洗い出した項目を深掘りする際にも、赤い色を注意して深掘りしよう、などの目安ともなります。
事実と感情の洗い出しが終わったら、議論したい項目を皆で投票します。1人3票。投票が終わったら、得票数順にソートし、上から順に深掘りをします。議論の内容もその場でスプレッドシートに記載し、具体的なアクションが提案されたらGithubのIssueを起票するなどもします。
実際にやってみると、KPTと比べて幅広い分野にわたって議論ができているという印象があります。また、感情を可視化することで、例えば障害対応などが発生したスプリントではシート上に黄色や赤が増えるため、今回は時間をかけて重点的に掘り下げねばならない、といった議論への力の入れ具合が明らかになった気がします。
結果としては、新しい振り返りは今のチームにとてもフィットしていると思います。ただ、これも長期間繰り返すとマンネリ化するので、定期的に設計をやりなおしてリフレッシュするのが良いのでしょう。レトロスペクティブの本来のお作法としても、チームの状況に応じて都度、手法は切り替えるべきであるとされています。
エンジニアスキルマップを導入した
続いて、エンジニアスキルマップについて。
Mackerelというプロダクトは、サーバー監視・管理サービスという性質も伴って、プロダクトが成長するに比例してエンジニアに求められる技術領域も拡大してきました。メインの開発言語も、Scala, Go, Pythonとマイクロサービス化されつつある各モジュールの特性に応じて使い分けられており、データストアもPostgreSQL, Redis, diamond(自作の時系列データベース)と特性に応じて多岐に渡ります。開発に必要な業務知識もとても幅広いです。
チームに在籍するエンジニアは、プロダクト開発に必要な知識・技術をすべて完璧に習得しているのが理想ではありますが、実際はエンジニア全員がこれらすべてを高い水準で維持するのは現実的ではありません。各個人の趣味嗜好や、得手不得手に応じて柔軟に人員配置がなされるべきです。
全員が完璧に全領域を習得することはできなくても、チームとして必要な領域が満遍なくカバーできる体制が維持できていれば、基本的には問題はないと思います。そのうえで、それぞれが苦手領域を克服したり、得意領域を掘り下げたり、各エンジニアのキャラクターやキャリアに応じて技術習得ができるのが健全なチームです。
こういった状態を管理・可視化するために「エンジニアスキルマップ」を作成しました。"Scala", "PostgreSQL", "ネットワーク" といった技術領域と、"監視設定", "プラン・決済まわり" といった業務知識的な領域とを組み合わせてマトリクス図を作成しました。
記号はそれぞれ、☆: エース級, ◯: 1人でやりきれる, △: サポートが必要, ↑: 習得希望, ー: 未習得 と定義。初回は他の人の入力に影響を受けないように、Googleフォームを作成して1人ずつ自己申告してもらいました。
「できる人の数」欄は☆と◯の数をカウントし、値が1以下になったらセルが赤くなるように書式設定しています。これをスプリントレビューのタイミングで棚卸しして、アップデートがあれば更新してもらっています。
注意点としては、スキルマップはあくまでも自分たちのチームの状態を可視化するためのもので、個人のエンジニアとしての能力を測るツールではないということです。同じシートを使ってチーム外のエンジニアと比較したり、期末の評価に使ったりしてはいけません。
こうやって可視化すると、チームの状態がとても良くわかります。メンバーの異動などが発生すると、チームの習得領域の分布状況が大きく変わってしまうので、そのうえでバランスがとれるように人員計画を立てたり、チームとしての弱みを克服するための手がかりとなります。
これらの項目を頻繁にアップデートし、習得者が0にならないように工夫することで、「いつのまにかチームから特定のテクノロジーが失われる」といった事態を防ぐことができます。
モブプロ枠を作った
スキルマップを運用していると、習得者の少ない業務知識などを横展開しようというモチベーションが生まれます。チームでも、自主的に知識習得者が勉強会を開催して、他のメンバーに伝授する、という取り組みがはじまりました。
そういった知見共有の場として、モブプロラミング枠が効果を発揮しています。
モブプロラミングとは、2人1組でプログラミングを行うペアプログラミングを、チーム全体にまで拡張する取り組みです。エンジニア全員と、プロダクトオーナーが1つのエディタを囲み、ドライバー(実際にコードを書く人)とナビゲーター(周囲からアドバイスなどをする人)とに分かれてプログラミングを進めます。ドライバーは適宜ローテーションしていきます。
Mackerelチームでは、毎週火曜日に1時間のモブプロ枠を設定。他のミーティングなどとブッキングしている場合はそちらを優先しつつ、その時間枠に体が空いている人は全員集まってモブプロに取り組みます。お題はスプリント計画時に、1時間ほどで収まるサイズの開発タスクを選んで、あらかじめラベリングしています。適度な実装タスクがない週は、ドメイン知識についての勉強会など、なにかしらチーム全員で取り組む活動をこの枠内ではやろうというルールです。
プロダクトオーナーも同席しているので、設計上の懸念点や仕様調整などはその場で素早く解決され、実装における意思決定がとてもスムーズに進みます。また、自分がこれまで触ったことのない部分のコードがテーマになった場合は、それについてチーム全員と共有されるので、知見共有の場としても非常に有効です。
チーム全員が1つの機能に取り組むのは、たしかにハイカロリーで効率が悪そうなイメージが先行しますが、仮にその日のモブプロが失敗して機能が完成しなかったとしても、せいぜい1週間のうちの1時間の枠内の出来事です。このくらいの規模感で気軽に新しい取り組みをするというのは、むしろ発見の方が多く、良い学習機会であると考えています。
朝会を昼会にしてみた (その後戻した)
新しいチャレンジが成功した、という話題が続いたので、次はチャレンジしてみたけど結局元に戻した、というのを紹介します。
Mackerelチームでは、毎朝10時15分から朝会をやっていました。いわゆるデイリースクラムです。"昨日やったこと", "今日やるつもりのこと", "困りごと" などをメンバー全員がそれぞれ簡単に共有します。会社の始業時間が10時なので、始業直後に朝会をしてからその日を開始する、というリズムとなっています。
とはいえ、はてなのエンジニア・デザイナーは裁量労働制なので、基本的にはメンバーは始業時間に出社しつつも、通院や家庭の都合などで出社時間がずれることがあります。チームメンバーの人数が増えるにしたがって、各人の個別事情などもあって朝会の時間に全員が集合する回数が減少傾向にありました。
そこで、デイリースクラムを昼に開催するというチャレンジをしてみました。昼休み明け直後の枠は別のチームの昼会で都合の良い会議スペースが空いていなかったので、お昼休み直前の15分にしてみました。
結論からいうと、昼の時間帯もミーティングなどで参加できない人がいるという事情には変わりがありませんでした。むしろ、昼休み直前の枠は、休憩を控えた時間帯ということもあって1on1などを開催するのに都合がよく、ミーティングのゴールデンタイム的な枠がデイリースクラムにブロックされてしまうことの方が困る、という意見もありました。
1スプリントほど試してみましたが、そのスプリントの振り返りで「元に戻そう」という結論がなされ、昼会は朝会に戻りました。これも、実際にチャレンジしてみたことで、検討時点では見えなかった事柄を学習し、スプリントの振り返りで素早く修正した、ということなので、チームのリズムが変化やチャレンジに強い体制であることを示しているのではないか、と前向きに考えています。
おわりに
ここに取り上げた事柄はあくまで一例で、現在チャレンジ中のものはたくさんあります。Mackerelチームのプロダクトオーナーである id:Songmu が以前社内Wikiに書いていた言葉を引用します。
業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く戻せばよい。
チャレンジをして、ダメだったら素早く戻せばよいのです。2週間に1度、振り返りの場で何らかのカイゼンを継続しているチームであるならば、チャレンジで得た学習を受けて進化をしていくはずで、完全に元に戻るパターンというのもおそらく少ないでしょう。
変化を恐れず、ダイナミックなカイゼンを重ねながら、チームとプロダクト両方を成長させていきたいものです。