$30 off During Our Annual Pro Sale. View Details »

メメメメメメメメメメトリクス!!

 メメメメメメメメメメトリクス!!

皆さん日々どんなメトリクスとってますか?メトリクスをとった後何してますか? メトリクスを使ってチームや自分の行動を変える時、とりあえず計測するだけして、放置されていることってありませんか? なんならメトリクスを取ること自体が目的化しちゃって本来の目的が横に置かれていることありませんか? 私はあります! コーチングなんていう、人にあれやこれや気づいてもらう事をしていても、油断をすると手段が目的化してしまうことがあります。 今回はそんな経験から、どうやってそこに気づいていくか?そしてどうやってメトリクスと付き合っていけばいいかについてお話しようと思います。

Ryo Tanaka

July 01, 2023
Tweet

More Decks by Ryo Tanaka

Other Decks in Business

Transcript

  1. View Slide

  2. メトリクス作ってますか?
    取ってますか?   管理してますか?

    View Slide

  3. 私はうまく出来る時もあれば、うまくいかない時もあります。
    今日は短い時間にギュッと濃縮して、
    どうやってメトリクスと付き合っていけばいいかの話をしたいと思います。

    View Slide

  4. NOT TODO LIST
    メトリクスの取り方の話
    定性的・定量的の話
    これだけとればOKというハック的な話

    View Slide

  5. 正直これだけ取ればチームの状態がわかるメトリクスなんてないし、
    スクラムをちゃんと適用すればより各チームが有機的に動く中で、
    銀の弾丸的な解決方法はやはり無い。
    でも、それ を求められるんですよね。無いのに。
    じゃ、何をベースに考えていけばいいのかって話を、変化変容フェチの私として話し
    ていこうと思います。

    View Slide

  6. 自己紹介
    リョー(田中亮)
    株式会社yamaneco
    アジャイルコーチ
    システムコーチ(ORSC®)
    趣味:ゲーム、ランニング、カメラ

    View Slide

  7. "それ"を求める人たちを見ていて
    メトリクスのうまいやり方を教えても意味がなさそうだ
    そもそものメトリクスを使う態度が間違えてるような気がする
    コーチ側から見えてる基礎的な内容をシェアしたほうが効果が高いのでは?

    View Slide

  8. あるチームの話。
    ファーストリリース2スプリント前、突然POが外部QAをチームに連れてきた。
    リリースのために品質を上げたいというのだ。
    その人によって大量のバグ報告書が投稿される。私の観点から正直に言うと、ファー
    ストリリースには影響しない程度のバグだが、その数は100を超えていた。
    そのバグ報告書があるステークホルダーの手に渡って状況が変わった、
    「これはいけない修正してもらわないとリリースを許可できない!」
    それまで、問題ないと言い続けていたPOの態度も変わった、
    「残念だが全てのバグを潰さないとリリースできない!」
    色々あったが開発者も覚悟を決めた
    「全部修正してリリースする!」

    View Slide

  9. 1スプリントが経過した。
    バグ修正に集中するために見積をせず、きたバグをただ潰すというスプリント方針だ
    った。
    当然ベロシティは0、バグの残数は100を超えたまま。
    なぜならバグを潰す速度よりもはやくバグが報告されていた。
    POがプレッシャーからかチームの反対側に立った。
    「バグが全然減らない、チームが機能していない、ベロシティ0にしているのにバグ
    数が減らないのはおかしい」
    スクラムマスターは萎縮してPOのフォロワーになっている。
    開発チームはがんばりますとしか言わなくなった。

    View Slide

  10. 色々あがいたけど、アジャイルコーチとしての私が最終的にやったことは、
    ベロシティやユーザーストーリーのライフサイクル追跡指標などをすべて廃止して、
    前日減った
    バグ数
    残バグ数
    増えたバグの数
    だけをホワイトボードに書いて更新し続けた。
    ラッキーなことにチームの眼の前にでっかいホワイトボードが余っていた。

    View Slide

  11. 減ったバグの数はチームに自信を、
    増えたバグの数はPOに本来の仕事を思い出させた。
    バグを増やすことと、減らすことにのみ集中していたチームは、
    改めて「リリース」を目標に設定し直し、バグのトリアージをはじめ、
    無事にリリースは完了した。

    View Slide

  12. ELA(体験学習アプローチ)的に捉えてみる
    体験 → 学習 → 活用方法

    View Slide

  13. チームは2つの状態を行き来している
    変化期と安定期
    それぞれの状態でメトリクスへの向き合いかたも変わる

    View Slide

  14. 変化を捉え、メトリクスと向き合う

    View Slide

  15. 変化とは?
    人の集団の変化を取り扱った理論
    U理論
    インテグラル理論
    エッジ理論

    View Slide

  16. U理論
    オットー・シャーマー
    個人、もしくは集団が変化する際の過程、流れ
    を紐解いた理論
    新発見というよりは学習する組織などで見つけ
    たシステム思考を通した集団の変化に対する理
    解、再現性の向上を狙っている
    変化を理解する上では必修理論だが、実践無し
    で本だけ読むと難解

    View Slide

  17. インテグラル理論紹介
    ケン・ウィルバー
    万物を説明する理論と現代哲学の巨人が打ち出
    した超難解理論
    別書「万物の歴史」と合わせて読むと理解が深
    まるか、より沼る
    万物とは何か?世界の捉え方にヒントをくれる
    良書
    ティール組織の基礎理論

    View Slide

  18. エッジ理論紹介
    アーノルド・ミンデル
    プロセス思考心理学の祖が人の変化に
    重点を置いた理論
    非常に理解しやすく、単純明快な理論
    故に誤解をされやすいので、本だけで
    理解しようとせず、プロセスワークを
    やっている人やシステムコーチと対話
    して理解を進めて欲しい
    理論が単純過ぎて、それだけでの本が
    無いのが難点

    View Slide

  19. エッジ理論紹介(補足)
    番外編紹介
    エッジ理論をサクッと読みたいならこっちの本
    の方が手に入りやすく、安価
    書いてるのはシステムコーチングの祖マリタ
    システムコーチングは、ミンデルのプロセスワ
    ークをコーチングの世界に落とし込んだもの
    (U理論やインテグラル理論も入っている)

    View Slide

  20. ざくっとまとめる
    変化前と変化後は違う世界になる (U/I/E)
    変化前に有用だったものは、変化後に有用とは限らない (U/I)
    変化している最中は、その変化すること自体にエネルギーが必要になる (U/I/E)
    集団の一部が変化しても、他の一部が変化しないことが常である (I/E)
    集団の19%は最後まで変化しないが、全体として変化は完了する (E)

    View Slide

  21. ちょっと詳しく
    変化は不協和から感じろ
    ■ 変化の要因(インテグラル理論より)
    変化の四要因「達成」「不協和」「洞察」「自己開放」。
    変容時には「不協和」が起こる必要がある。新しいものが現れようしている一方で、
    過去のものが必死にしがみついている
    過去のものは大事であると感じるが、それは過去大事だったもの。
    新しい段階には必要がないと捨てる勇気が大事。
    もし新しい段階でも必要なのであれば、それは自然と復活する。

    View Slide

  22. ちょっと詳しく
    変化の最中は、変化することに集中
    ■ 転換―針の穴を通り抜ける(U理論 プレゼンシングの原則より)
    古いものを手放し未知のものに委ねる。
    針の穴とは、そこを通り抜けるには必要ではないすべてを捨てなければならない敷居のこと。
    変化にはそれ自体にエネルギーが必要なので、安定期と同様に「ちゃんと」する必要
    はない。
    変化が終わってから「ちゃんと」し始めても大丈夫。

    View Slide

  23. ちょっと詳しく
    集団の変化のグラデーション
    ■ チームのエッジを理解し行動を起こす(エッジ理論より)
    変化とは感情を伴う旅路だと肝に銘じよう
    変化をする集団の中には、さっと変化する人(leaper)、変化を見守る人(bridge
    builder)、そして伝統を見守る人(tradition holder)と様々な類型の人がいます。
    leaperは集団の変化が終わったと勘違いして行動しがちです。
    また、集団の変化は大多数の人間のふるまいで規定されるので最後まで変化できない
    人がいることも覚えておきましょう。

    View Slide

  24. メトリクスとは?
    目標(ありたい姿、理想の状態)と
    行動を繋げるもの
    目標=ドリーミングレベル
    行動=合意的現実レベル

    View Slide

  25. まとめ
    チームは変化と安定を繰り返している、
    変化期と安定期、また変化後ではそれぞれ目標や行動に変化が見られる
    目標と行動から作られるメトリクスを変化させなていかないと役に立たなくなる

    View Slide

  26. 実践編
    1. 変化を捉える
    2. 今までのメトリクスは捨てる(もしくは重要視しない)
    3. 一つのメトリクスにフォーカスする(残すか、作る)
    4. うまくいかないならそれも捨てて、新たに1個
    5. 変化の終わりを捉える
    6. 使うメトリクスを増やして、安定期を支える

    View Slide

  27. 変化をとらえるのが難しい?
    頭だけでなく
    体でとらえろ
    違和感を使え!
    理論で客観性を補強しろ!

    View Slide

  28. ありがとうございました!

    View Slide