チームではじめるアジャイルメトリクス

2022年11月30日 23:35

こんにちは！back check でスクラムマスターをやっている山口です。
先日PHP勉強会@東京で5分LTをやらせていただいたので、そこで話しきれなかったことを含めまとめたいと思います。

ちなみにお写真は撮り忘れましたが、今回の会場はGMOさんのコミュニケーションスペース、GMO Yours フクラスにてオフライン開催しました。
とてもきれいなスペースで感動しました！

あと大人数の集まる勉強会での登壇は初めてだったので、めちゃめちゃ緊張しました。暖かく受け入れていただいた皆さんには本当に感謝です。

さて、本題にはいりますが基本的にはスライドにある内容については概要のみ触れます。

概要

back check ではチームの分割をきっかけに、自分たちの行動が良くなっていそうだけど定量的に可視化できない？ということで開発に着手してからリリースReadyになるまでのリードタイムを計測し始めました。

定量化した結果、チーム分割前のストーリーポイント1ptsあたりの平均リードタイム2.1日からチーム分割後は1.4日に短縮できていることがわかりました。
（この辺はデータ量の差などもあるので引き続きメトリクスの拡充もしながら観察していこうと思います）

というような内容のお話をしました。

一見よさそうな活動にみえますが、メトリクスの使い方によっては気をつけないと悪影響になってしまうこともあります。

大きく以下の事項に注意するとよさそうです。

そもそも開発チームの生産性を計測することはできないという風にマーチンファウラーも言っています。
なぜならソフトウェア開発のアウトプットの量と質に対して適切に評価・計測することができないからです。

また私たちの目標は顧客への価値提供をうまく行えるチームになることです。
これらをガイドするためのツールとして、リードタイム（提供速度）を計測するのです。なのでこれらのガイドがチームが改善のきっかけを見つけるためのチームによるチームのためのメトリクスとして機能していることが大切です。

もし気になるならチーム内だけで計測して、チーム外のマネージャー等には内容を共有しないということもひとつの手です。

カンバン仕事術の本で紹介されている言葉として「あなたが計測したものがテイに入る。間違ったものを計測すれば、間違った行動に繋がる。」というものがあります。

ここで紹介されている例としてコールセンターの電話の時間を計測し始めれば、顧客を支援するよりも電話をできるだけ早く切り上げることに集中するようになる。という例があります。

そのための解決策として、ひとつのメトリクスだけを集中的に計測するのではなく、複数の観点から計測して複合的な観点でフィードバックを得るということです。

たとえば、ストーリーの発案から本番でユーザーに触れる状態になるまでのリードタイムを計測したとして開発の速度に集中するあまりバグが大量に発生するようになったら元も子もありません。

また、開発に着手してからリリースReadyになる状態までのサイクルタイムを計測し改善した結果、アイディアを起票してからストーリーとして着手されるまでの時間に大量の待ちが発生してしまってもかえって逆効果です。

ですのでメトリクスを計測するときにはアイディアの吸い上げからユーザーが利用可能になるまでなどなるべく広い視点で、速度、品質など複数のメトリクスを設定することが大切です。

チームの成長のために導入したメトリクスの運用がつらくてチームの開発業務に影響がでてしまうようなことは避けましょう。
前述でも述べましたが、メトリクスはあくまでガイドです。定量的な指標を計測することは本質ではなく、自分たちの行動が改善されることが本当に大切なことです。

そこでチームの中で有意義なメトリクスが定義できたら、計測は自動化しましょう。
進め方としてはまずはざっくり手作業で集計してグラフに書き起こしてみる。これをチームで眺めて価値を確認できたら自動化する。といった流れが良いと思います。

今回は以上でおわります。
今後はよりフィードバックを得るためにはどうしたらいいか？という観点でチームと一緒に試行錯誤していけたらと思います。
また進展があったら随時ブログに書いていけたらと思うのでおたのしみに。

この記事が気に入ったらサポートをしてみませんか？