2021/2/4 20:30-23:00に開催された分散アジャイルチームについて考える会の
「スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話」に参加してきました。

参加した際のメモ記事です。

アジェンダ

背景
メトリクス化するために考えたこと
実際にやったこと
結果

背景

本部レベルでスクラムの支援／促進をしていくことになった。
支援／促進のせいかって、どうやって測るの？ってなった。

支援活動と改善した／しなかったことの相関関係ってあるの？ってなった。

そもそもなんでスクラムの支援・促進してるんだっけ？

スクラムはあくまでhow
アジリティを上げるために組織としてスクラムを選択している
↓
アジリティが上がっていることを確認したい

どうする？

アジリティが上がっている状態を定義する
それを定量で図れるようにしたい
↓
メトリクス化したい！

メトリクス化するために考えたこと

世の中にはどんな物があるか？を調べてみた
→scrum.orgがEBMというプラクティスを提供しているらしい

現在の価値

現時点でプロダクトが提供している価値
ここが大きければプロダクトは成功していると言える
- 従業員満足度
- 顧客満足度
- 仕様指標

プロダクトが提供している価値なら測れる？
→No!

その他前で支援の成果を見るための指標としては何が取れるだろう？

市場に出すまでの時間（T2M: Time-to-Market）

迅速に提供する組織の能力
これを最小化すれば価値を持続的に提供する能力がある

市場に出すまでの時間なら取れる？

チームの能力を計測するための指標？
→No!
支援の成果を見るための指標としては難しい

他の２つのエリア

イノベーション能力
未実現の価値
- 未来に対して投資できるかの指標

支援の成果として計測するにはやっぱり適していない。。。。

メトリクスで気をつけたいこと

なにか指標を決めることで一部に集中してしまい、部分最適が起こりやすい
計測しないといけないのであれば、一点だけでなく複数組み合わせたい
EBMの指標が良くなっていれば、組織の目標位迎えているんだろうか？

結果いい指標は見つからなかった
困った

これと言った指標がない。。。。。。

実際にやったこと

アジリティの向上を定義した
- ステークホルダーのニーズをキャッチアップして正しく理解し、本当に必要なものを提供するサイクルを素早く回し続けられるようになっている

行動を図ってみる？

アジリティを上げるための行動ができていないとだめだよね
その行動ができているかどうかは測れるかも

ロールごとの行動を考えてみる

PO,SM,Devで必要な行動のチェックリストを作成
- PO：チームにビジョンを伝え優先順位を明確化する
- Dev:自分たち自信をマネジメントして成果を出す
- SM：スクラムの理解促進／支援をする役割

チェックリストを作る

叩きを作成
１チームでお試し
項目の見直し
レビュー
完成

チェックリスト

それぞれの役割で２５項目程度を出した。

チェックリストの段階づけ

最低限のスクラムのルールに沿ってスクラムを使用している（やるべき）
- 一定のサイクル速度で優先順位をつけて機能をデリバリーできる
スクラムを有効に活用できるようにスクラムを使用している（やろうと思えばできる）
- 最低限の時間で最小の価値の機能を一定のサイクル速度でデリバリーできる
スクラムを有効に活用できている（難しいけど努力次第）
- 一定のサイクル速度で機能をデリバリーしながらユーザーのプロダクト価値を上げていける

チェックリストのチェックの仕方

チェック段階
- ○、△、✕
クリア項目基準
- バツが１つもない、かつ○が２つ以上
STEPクリア
- STEP内の全項目がクリア基準に達している

実際にチェックリストを実施してみる

全チームにチェックしてもらった。
ステークホルダーにもチェックしてもらった。（わからないという選択肢も用意）

チェック結果を集計してフィードバック

このチームは今こうなってそう。こういう風に変えてみると良いかも。
ということを伝えた。

チーム内の認識のずれを感じる材料にしたり。

結果

今まで見えてなかったところが見えるようになった

組織ごとの傾向
チームごとの強み・弱み

↓

組織底上げの仕組み
チームごとの成長プランに

に繋げられそう

「POがチームのhowに干渉していない」ということを実践できていないチームがおおい。
「担当者のアサインを任せている」、「チームのカイゼン成長に協力している。」というチームは多かった。

↓
次の行動につなげていった

上位チームの具体的な取り組みをヒアリングし、事例を紹介していく
NGのチームがOKのチームに取り組みをヒアリング・相談できる場を作る

スクラムの側面と成果の側面でギャップを感じる

進捗・品質の作り込みに課題が見られた

スクラムを実施しているだけでは難しい
テクニカルプラクティスの導入も必要（XP, CI/CD, DevOpsなど）

　チェックリストをマネージャーのツールにする

回答率を改善したい。
ただ、「お願いする」 or 「トップダウンで落とす」をするとやらされ感が生まれてしまう
↓
マネージャーが組織をより良くするためのツールへ

個別フィードバックとは別にガイドを作成

教えてほしい、フィードバックほしい、という待ちな状態になるチームが出てきた。

各項目で見たいこと、やりたいこと、どうするべきという意図かをガイドにして配布
ガイドを使ってチームごとに取り組んでもらえるよう配慮

ガイドの例

項目
- プロダクトバックログがPOの考えのもとに優先順位付けされるように支援している
ガイド内容
- する理由
- しないとどういう困ったことが起こるか

今後やっていくこと

スクラムと成果の相関関係を今後探っていきたい。

チェックリストのOK数
チームの障害数
満足度

成果指標の最適化は随時行う

おわりに

スクラムでは透明化は大事だと言われる。
自分が何をして、その結果チームにどんな影響が出て、
何をしたから、どうなったのか。っていうのを可視化するのはコーチの立場としても大切なのではないか？
「こうすればいいよ」って言うのは簡単だけど、「どういう状態で、なにをして、結果がこうなった」というのを定量的に可視化できるのが大事だと考えている。

大事だよ　見える化すること　でも難しい

QA

今はスクラムの推進が業務の中心で、エンジニア業をほとんどやってないっておっしゃってましたけど、支援する上での難しさとか悩みとかありませんか？
- 前職の際はエンジニア業をしていたので、一応わかっています。
- ただ、技術的な話で議論をするより、むしろ「そういう細かいこと知らないんで」くらいでいたほうがコーチ業としてはいいかもしれない。
チェックリストをやっていて、チームからリスト項目の疑問とか是非とか上がってきたこととはあるんでしょうか？（そういう議論が巻き起こってたら面白そうだなと思って）
- チェックリストの叩きを見せたときに「これってなんですか」「これってなんのためにするものですか？」と聞かれた。
- フィードバックをもらえて嬉しかった
- 「こう考えているんだけどどう思う？」と会話できた
アジリティの定義が計測方法を考えながら”安定して運用されるサービスが早さとバランスを取りながらリリースされて行くこと”に徐々に固まっていったようなイメージでしょうか？
- 計測方法を考えた結果定義を決めていったわけではない
- 依頼者が組織のマネジメントそうだった。
- そういう人たちが求めているアジリティ向上はなんだろう？を考えていった結果の定義
- 現場によって定義は異なるかもしれない
チェックリストの回答内容が本当にあっているのかの確認を、されたりしていますでしょうか？
- なんでも「できてます！」って回答はきているけど、正当性を確認したい。という事はある
- ステークホルダーがよくわからないまま○にすることもあると思う
- バランスはどうにかとっていきたいなと思っている
- チームがユーザに価値を届けられているか？という観点でも回答内容を突き合わせる必要があると思う
ダニング＝クルーガー効果みたいなことは起きたりしないのだろうか
- ある種バイアスが掛かって高い評価をつけてしまうようなこともあるかもね
- チェックリストでそれを防ぐのは難しいかもしれない
「最低限のスクラム」という言葉がありましたが定義はありますか?
- 「最低限スクラムの定義に沿ってスクラムをやっているか？」
- 「スクラムを初めてみたけど合わないのでレビューのやり方をこう変えました」みたいになっていないか。
- まずは規定されている通りの進め方をしているか。

感想

「生産性向上」なんかも同じだと思いますが、定量的な評価が難しいというのはすごい共感しました。
ステークホルダーに成果を示すという目的でのスタートではありましたが、メトリクスの可視化によって「なんかとりあえずやってみる」という状態から、「うまくまわっている！」という状態になり、不安感の払拭や自信にもつながると感じました。
キーとなるメトリクスが発見されようものなら、泣いて喜ぶ人がいると思います。（メトリクスを追い求める奴隷にならないように注意はしないと）