書籍『アジャイルメトリクス』をエンジニアとビジネスサイドで輪読会してみた
こんにちは、Findyの@dai___youです。
本記事は、開発生産性 Advent Calendar 2022の14日目の記事です。
13日目の記事は、アンドパッド VPoE @gessy0129 さんの『ANDPADが考える生産性を語る上で大切にしたい3つの考え方』でした。
今回は、”書籍『アジャイルメトリクス』をエンジニアサイドとビジネスサイドで輪読会してみた”というテーマで書きたいと思います。
本記事で伝えたいことを一言でまとめると、「友よ！本書を読もう」です（本書からの抜粋）
過去のnoteにも書いたのですが、本書はアジャイルチームの潜在的な能力を最大限発揮できるように、”何をどの分野で、どの頻度で測定すべきかという定義から、誰を対象にどのようなメトリクスで測定すべきか”まで理論から実践を通して示してくれます。また、”数字をどのように収集し、どのツールを使ってそれらを統合し、どのように行動に移すか”までを説明してくれる書籍です。
以下のような日々ソフトウェア開発に携わる方々の活動の参考になれば幸いです（友よ本書を読もう！）。
誰向けの記事か？
開発生産性に興味がある方
アジャイルチームをよりよくしていきたいと思っている方
輪読会の概要は？
なぜ輪読会をやるのか？
Findy Team+という開発生産性可視化ツールの提供元として、顧客価値提供のために行う
自身の活動に活きる学びを得る
“開発組織のパフォーマンス測定と向上とは“を考え、意見を交わし、プロダクト企画・開発・Sales・CSに活かすTipsを得る
ビジネスサイド × エンジニアサイドでディスカッションを交わし、開発プロセスにおける可視化に関する共通認識を深める＆解像度を高める
実施形態は？
参加者
企画・開発・営業・CSそれぞれ1〜2名
1時間の輪読会 X 3回実施
第1部・第2部・第3部から、Findy Team+の事業運営に活かせそうな章を選定して、3回に分けて実施しました
輪読会の進め方（60分）
30分黙読とメモ
『アジャイルメトリクス』の該当箇所を黙読
miroに気になったTipsをメモ
人ごとの付箋カラー決め、その色を使用
30分ディスカッション
気になったTipsに関して共有し、相互に質問・ディスカッションする
それでは、輪読会内であがったTipsとディスカッション内容（一部抜粋）をまとめていきたいと思います。
第1回：第1部アジャイルチームを測定する
✏️まとめ
・ステークホルダーが抱えるお困りごと・”問い”を起点にデータを収集し、メトリクスを通してコミュニケーションをギャップを埋めることが重要
・開発プロセスにおいては複数のツールがまたがるケースが多いため、複数ツールのデータを組み合わせることで、より価値あるメトリクスを測定することができる
第1章アジャイルパフォーマンスを測定する
💡気になったTips
ソフトウェア業界の改善の中で見落とされているのが「測定」（本書に寄せて）
メトリクスを測定する前に、そもそも測定すること自体をステークホルダー間で合意形成する必要があるが、それがかなり難しいケースがある
メトリクスに関する改善（開発生産性向上）から得られる価値とメトリクスを収集（開発生産性を可視化）するためのコストを上回るかどうか、を示す必要がある
念の為ではなく、”困り事・解決したい事を整理”した上でメトリクスを設定する
どのような問いに回答できるか？から開発プロセスにおけるメトリクスを設定する
🗣️ディスカッション
下記ステークホルダーの困りごとを”問い”として、開発プロセスの中で生成されているデータを、チームが今どんな状況にあるかを示すメトリクスに変換することで、お互いのコミュニケーションのギャップを埋めることができる
経営層⇔開発組織
Bizサイド（PM・PO）⇔開発組織
開発組織：EM⇔メンバー
第2章生きたプロジェクトを観察する
💡気になったTips
経営へのレポーティング
ベロシティを基準にしつつ、バグや手戻り率をチェックするとよい
🗣️ディスカッション
複数のツール・プロセスにおけるデータを統合することで、得られるインサイトは異なってくる
経営への報告内容はチケットレベルの粒度感でデータが見える化されていると伝えやすそう
第2回：第2部チームのデータ収集と分析
✏️まとめ
・プロジェクト管理においては、ベロシティのの速さ・タスクの完了度に起因するメトリクスを収集するとよい（バグ数や手戻り数など品質観点のメトリクスも有効）
・ソースコード管理においては、まずはプルリクにフォーカスするだけでも、得られるインサイトは多い
第3章プロジェクト管理システムからのデータ傾向
💡気になったTips
プロジェクト管理においてよくでる基本的な”問い”
ベロシティの速さは？
タスクの完了度合いは？
チームの仕事量は増えているか？
パフォームしているメンバーは誰か？
品質の問題はないか？
🗣️ディスカッション
経営へのレポート内容はイシューレベルの報告が開発の全体感は共有しやすい
イシュー・タスクの消化度（ベロシティ）を基準としつつ、バグ数・手戻り数の推移を表示できるとよい
第4章ソースコード管理
💡気になったTips
ソースコード管理においてよくでる基本的な”問い”
開発チームの共同作業は順調か？
見積りは正確か？
タスクのサイズは適切か？
チームの実際の作業量はどの程度か？
コードの変更に対する”問い”
最も頻繁に変更が発生しているのはどこか？
最も時間を費やしているメンバーとモジュールは誰でどれか？
最もコードを変更しているのは誰か？
🗣️ディスカッション
”問い”に答えうる情報として、まずはプルリクにフォーカスしてしており、コメント・プルリク・コミットの時系列変化を見ている
単純にアウトプットが多い・少ないだけでは、良い・悪いが判断できないので、データを組み合わせて示唆出しできるといい
第3回：第3部メトリクスをチーム・プロセス・ソフトウェアに適用する
✏️まとめ
・経営陣・マネージャー・開発チーム内のそれぞれのお困りごとに対する共通認識をもつ
・メトリクスはステークホルダーの抱えるお困りごと＝”問い”とセット
・良いソフトウェア・良いチームを考え、プラクティスを実践したときのメトリクスの変化をモニタリングする
第7章収集したデータの扱い
💡気になったTips
データを見る前に、組織内で、よいソフトウェア、チームはなにか？を定義し共通認識を持つ必要がある
”良い”ソフトウェア・チームを測定するには、”良い”メトリクスを持つ必要がある
すでに持っているデータをつかって開発サイクルの中で、何が良くて繰り返す価値があるのか、を定義する
マインドマップで良いソフトウェア・良いチームと作るための”問い”が大事
🗣️ディスカッション
良いチームを定義するうえで、良い事例、悪かった事例をチーム内で認識を合わせることから始めると良さそう
チーム内で開発がうまくいっていた期間のメトリクスをみたり、ベストプラクティスを試してみた結果メトリクスがどのように変化したのか、をモニタリングする
第9章メトリクスの公開
💡気になったTips
ステークホルダーが抱える”問い”から始める
経営陣・マネージャー・開発チーム
経営陣が見るべき指標は「リリース回数・リリースごとの機能数」「顧客目線での品質評価の移り変わり」「開発コスト」
マネージャーが見るべき指標はチームが長期的にどのように機能しているのか、個人がチームの中でどのように機能しているのか、に係る指標
🗣️ディスカッション
ステークホルダーの問いに沿って、マインドマップ作成する！
お困りごとに沿って、どのようなメトリクスが必要になるかの全体像を整理するとよさそう（本書で紹介されているマインドマップの図解が非常にわかりやすいので自社でもディスカッションして具体化する）
3回の輪読会を通して（総評）
参加者からの学びを抜粋して貼り付けます。
他部門間で同じテーマで議論する機会は大事だと感じました。
本書を通して得たTipsを通して、マインドマップを作成しよう、というネクストアクションが決まったので、それを作成し、Findy Team+の企画・UI/UX・開発・営業・CSに活かしていきたいと思います👍
さいごに
本書をぜひチェックしてみてください！
記事内で取り上げたFindy Team+のメンバーも募集中です
15日目の記事は、@miyatomo さんの『プロダクトマネジメントを改善したらFindy Team+のCSにめちゃくちゃ褒められた件について』です。
ではでは〜
この記事が気に入ったらサポートをしてみませんか？