(cache) メトリクスによる「見える化」のススメ: エッセンシャル・リーン at DevLOVE関西

2015年3月7日（土）にDevLOVE関西さんにて、『メトリクスによる「見える化」のススメ: エッセンシャル・リーン』と題して、プロジェクトメトリクスに関するワークショップを実施させていただきました。

年度末かつ雨の土曜日にも関わらず、総勢24名の方にご参加いただき、約4時間の濃ゆ～いワークショップを実施しました！

なお、当日の様子をTogetterにもまとめておきましたので、こちらもあわせてご確認下さい～
メトリクスによる「見える化」のススメ: エッセンシャル・リーン at DevLOVE関西 : Togetter
http://togetter.com/li/792373

ワークショップの内容

基本的には、前回「ゆるぎー」さんで実施させていただいた内容をベースとしつつ、時間が90分ほど長いこともあり、ワークショップの内容を倍にし、キッチリ皆さんにプロジェクトメトリクスを「体得」してもらう内容としました。

◆セッション1（30分）

(1) 今回の参加目的を参加者に質問する　(約5分、2名)

アイスブレークを兼ねて、私と目のあったお二方に以下のことを質問させていただきました。

どういう目的意識・課題認識を持ってこのイベントに参加されたのか？
具体的に、いま何について困っているのか？

これは、この後の説明・ワークショップでどの辺りに力を入れるべきかを確認することも目的の1つでした。

(2) XP祭り2014のLT資料を紹介する（15分）

最初の導入として、プロジェクトメトリクス・見える化のイメージと意義を参加者全員で共有するために、既に公開中の下記資料を説明させていただきました。この内容が、この後のワークショップのベースとなります。

メトリクスによる「見える化」のススメ: エッセンシャル・リーン from Hiroyuki Ito

◆ワークショップ1（60分）

(1) チームづくり（説明5分＋実施5分)

まず参加者全員に、自分がマネージャ・デベロッパーのどちら寄りかを自己申告していただき、必ず各チームにマネージャ・デベロッパーの両方がいる形になるようにチームを作ってもらいました。今回は参加者が24名だったので、4-5名のチームが5つ。このチームで、終日協力し合っていただきました。

ちなみに今回は、マネージャ寄りの方が6割近くだったことも併せて付記しておきます。

(2) 1st Sprint（説明5分＋実施15分)

最初なので、次の3点をチーム内で共有してもらうこととしました。

自己紹介
自分が今課題だと思っていることは何か？
その課題は、どうすれば「見える化」することができるだろうか？

(3) 2nd Sprint（説明5分＋実施15分）

ここから徐々にガチ路線へ。

1st Sprintで出し合った課題のうちの1つを、そのチームの課題として取り上げる。
その課題に対して、どのようなメトリクスを取れば良いのかをチーム全員で考える。
- それを見えるようにするためには、何を使って何を計測していけば良いか？
考えたメトリクスに対して、それがマネージャ・デベロッパーそれぞれの視点から嬉しいものであるかどうか、また嬉しくなければどう改善すれば良いのかを話し合い、チームメンバー全員が合意するところまで持っていく。
発表できる形にアイデアを整理し、A3用紙にまとめる。

ポイントは次の２点。

単にプロジェクトメトリクスを見つけることだけに留めず、マネージャ・デベロッパー双方の視点をぶつけ合い、本質的に見ているものが違わないか？という気付きを得てもらうこと。
メトリクスを考えて終わりではなく、それを他者に「見せる」ことも視野に入れて行動してもらうこと。
- そもそも「見えるかのススメ」ですのでw

(4) トレードショー（説明5分＋実施5分×2）

よくProduct Owner研修などで行われるトレードショー形式で、各チームの考えたメトリクス案を見せ合うこととしました。具体的には以下の通りです。

チームのうち2名は、自分たちのチームのメトリクス案を説明する要員として残る。
他のチームメンバーは、他チームの説明を聞きに行く。

これは、自分たちのアイデアを説明してフィードバックを得ることと同時に、他チームからヒントを「盗んで」来ることも企図したものです。

◆セッション2（30分）

ここまでの内容を元に参加者から質問をいただいてそれに回答しながら、併せてAgile Japan 2015で発表予定の最新の知見も紹介しながら、私なりのメトリクス・見える化の勘所を説明させていただきました。これは、残りのワークショップのためのテコ入れが目的です。

※ちなみにここでいただいた質問とその回答は、後半にまとめています。

◆ワークショップ2（60分）

先のワークショップで作成したメトリクス案について振り返り＆改善を行ってもらい、徹底してメトリクスを洗練してもらい、実践で使えるものにしてもらいました。ある意味ここが本当の勝負。

(1) 3rd Sprint（説明5分＋実施15分）

以下の情報を元に、メトリクスを洗練する。
- 先のトレードショーの説明で他チームメンバーからもらったフィードバック
- 先のトレードショーで他チームから「盗んで」来た情報
- セッション2を受けての「気付き」
併せて、具体的な算出方法についても突き詰める。

(2) 4th Sprint（説明5分＋実施20分）

実際の現場で使えるものとして、メトリクスを完成させ、発表できる状態まで持って行く。

DoD（完了条件）は、A3用紙にメトリクスの内容・目的・算出方法を整理し、他者に説明できる状態にすること。
併せて、誰に何を伝えて喜ばせたいのかも明確化する。

(3) 成果発表（発表3分＋質疑応答2分をチーム数分)

最後にデモとして、全チームに自分たちの作ったメトリクスを発表してもらい、質疑応答を受けることとしました。

チーム１（メトリクス王子）

開発チームの成果を、「完了したチケットに対する感謝の割合」として算出したもの。
プレゼン資料では「感謝状」となっていますが、チケットに対する「いいね！」数など、他にも算出方法はあるかもとのこと。
併せて、ネガティブな情報も同様の仕組みで取れるかもとのこと。

チーム２

プロダクトの品質を経営陣・PMOらに見せる観点から、品質をどう見せるかに挑んだ意欲作。
そもそも情報を見せるべき経営陣・PMOに意見を聞けない状態でこの課題設定だったので、ワークショップ中はチームがほとんどフリーズ状態になっていて、正直心配しましたw
しかし、最終的に数値と計算方法にまで辿り着いたのは見事でしたね。

チーム３

営業などからの割り込みが多くて仕事が多い／仕事に集中し辛いという課題認識から、割り込み量と仕事量と売上の相関を見せられるようにしよう、というものです。
特にこのチームは、質疑応答の際も「割り込み時間をどう扱うか」（後述）を質問されていたので、よほどこの割り込みをどうにかしたかった様子。

チーム４

他チームを出し抜く、A3用紙4枚の大作！（確かにA3用紙を使えとは言いましたが、枚数までは指定していませんでしたからねw）
他チーム・メンバーのタスクがブロッカーになっていて自分の作業を進められないとフラストレーションを溜めているデベロッパーと、別に個々人がタスク量をこなすことよりもチーム全体でタスクが完了できれば十分というマネージャとの対話から、どのタスクが滞留しているかをチーム全体で見られるようにしようというのがポイント。

チーム５

チーム3と同様、他チームとの兼ね合いで割り込みが多くて仕事が多い／仕事に集中し辛いという課題認識から、仕事における割り込み率を見せられるようにしよう、というものです。
というか、そんなにみんな割り込みに苦しめられているのに、今まで誰もそれに手を付けられていなかったということか…！？

◆振り返り（15分）

チーム毎に、以下のことを振り返ってもらう。

今まで分からなかったことは何か？
今回のセッションで、何が分かるようになったか／分からなかったか？
自分たちが現場で行えるネクストアクションは何か？

質疑応答／Q&A

ここで、今回参加者の皆さんからいただいた質問とその回答を、覚えている範囲でまとめます。

割り込みタスクをどう扱うべきか？

そもそも割り込みタスクは発生するものなので、100%フルで働く前提の見積もりはせずに、バッファを用意した見積もりとする。
バッファの適量を考える上では、「Focus Factor」（私は「割り込み率」と訳してます）というメトリクスが役に立つでしょう。
- 「Focus Factor」は、Henrik Kniberg氏による名著『Scrum and XP from the Trenches』に明記されていますので、是非これを機会に確認してみて下さい。
  - 原著（英語版）
  - 日本語版

どのタスクが滞留しているかをJIRAで見つける方法

を、Atlassianの方から質問されましたよ！？w

「Control Chart」を使えば、チケットのステータス毎のサイクルタイムを調べることが可能です。
- https://confluence.atlassian.com/display/AGILE/Viewing+the+Control+Chart
Filterで以下のようなクエリ（JQL）を発行すると、ステータスが変わっていないチケットを調べることが可能です。（但し、JIRAにかなり負荷をかけるクエリなので、1分で20回くらい実行するとJIRAが落ちますw）

ステータスが「Resolved」のまま3日経っているタスクを見つける例
status was Resolved before startOfDay(-3d) AND status = Resolved

メトリクスをどうやって他チームにスケールして行けば良いのか？

例えば今回のワークショップで考えたメトリクスたちは、いずれも特定のコンテキストに依存して見つけ出したものです。従って、コンテキストが違う他のチームとの比較を行いたい場合、どうやって他のチームとメトリクスをすりあわせればよいのか？またメトリクス自体を他チームに広めていくためにはどういった工夫が必要なのか？という質問をいただきました。

以下、私の回答です。

そもそもメトリクスを取っているチーム自体がほとんど存在しないはずなので、現状他チームとの比較やスケールを気にする段階には無いのではないか？
むしろ、自分たちの考えたメトリクスをデファクトスタンダードにしてしまえば良いのでは？

いつどのタイミングで計測を始めるのか？

これは、「必要に応じて」というのが正直な答えです。

そもそも課題発見型の仕事では、やりながら見つけていかざるをえない。
- 課題を解決することで新たに必要になる／取得が可能になる、「実績開放型」のものもあるので、やり込みが必要です。
一方で、課題解決方法が見えている場合には、事前に仕込んでおいて成果を見せるというやり方もあるでしょう。
- この考え方は、振り返りのファシリテートをする際に活かせるかも知れません。

中村さんの好アシスト

Vagrantに苛立つ中村さん。

今回、ワークショップ中に中村さんからのアドバイス・指摘が非常に多く、「意義があるな」と考えたものは適宜採用させていただきました。具体的には以下のものが、中村さんからのアドバイスで実施したものです。

チームのアイデアは、A3用紙で全員に共有できるようにしよう！
- 自分のPCだけに情報をまとめて会話に参加している人が散見され、おそらくコミュニケーションロスが大きくなるだろうと思われたため。
もっとマネージャ役の人をけしかけて対立を煽っても良いのでは？
- 今回の参加者は良い意味で尖った人が少なかったため、メトリクスがチーム内で合意しやすく安易な結論に行き着く恐れがあったため。
XXチームが詰まっているので、手分けしてアドバイスしに行こう！

今回のワークショップの内容は、中村さん的には「当然の内容ですよね」とのことで、段々自分でも色々試したい衝動を抑えきれなくなったようです。

ちなみに、中村さんから「このワークショップを自分も主催してみたい」との相談をいただいたので、「私の名前をクレジットしてくれること」を条件にOK出しました！今後は中村さん色の出たプロジェクトメトリクスワークショップが開催されていくことでしょう。