Satoshi Haradaの日記

Satoshi HaradaがAgileに関することを書き残していく日記

書籍「アジャイルメトリクス」を読み始めました

本書の概要

www.shoeisha.co.jp

開発に関わる全工程の詳細を定量化し

より強く、より高パフォーマンスなチームへ

　

【本書の内容】

本書はChristopher W.H.Davis, "Agile Metrics in Action",Manning Publications 2015の邦訳版です。

アジャイル開発は、その特性である「反復」によって、経験に基づく継続的な改善に最適な開発手法です。

この手法に、追跡システム、テストおよびビルドツール、ソース管理、継続的統合、およびプロジェクトライフサイクルといったさまざまなコンセプトとツールを援用することで、製品やプロセス、さらにはチームそのもののパフォーマンス改善できる豊富なデータを入手できます。

本書は、そういった実際に生成されるデータを計測し、結果を的確に分析し、効果的な対処法を指南してくれます。

パフォーマンスや進捗度合いなどを定量化することで、経験値による知見だけではなく、より合意しやすいチームへと組織や方法論を改善してくれることでしょう。

　

【読者が得られること】

・プロセスやタスクを定量化できるようになる

・定量化したデータから現状を正確に把握できるようになる

・コミュニケーション、生産性、透明性、士気を向上させる

・客観的にパフォーマンスを測定する

なぜこの本を読もうと思ったか

アジャイルが上手くいっているかどうかをどうやったら測ることができるのか、何かヒントが見つかるかもしれないと思ったためです。 アジャイルなチーム開発が上手くいっているかどうかの物差しは、ざっと以下のようなものが思い浮かびます。

  • PBIを実現していくスピード（ベロシティ）
  • スプリントで実現したタスクの数やその見積り数
  • デプロイの頻度
  • デプロイの待ち時間
  • リリースの頻度

しかし、これらの定量的な指標を運用しているチームはまだそれほど多くないように感じますし、ふりかえり（レトロスペクティブ）の場で定量的な値をもとに原因分析や改善Tryが行われることも少ないように感じます。 ふりかえりの場では、定量的な値を用いて改善策を出しているシーンよりも、定性的な印象・感想をもとに改善策を考えるシーンが多いと感じていたのです。

もちろん、ふりかえりは決まったルールがないので定性的な印象からもっとチームがよくなるアイデアが出てくることは尊いことですし、そこから改善が前に進むことも十分にあり得ます。 しかし、そこに定量的な測定値（メトリクス）が加われば、より効果的な改善点のアタリがつけやすくなるのではないかと期待しているのです。

読書メモと感想

対象の章

第1部　アジャイルチームを測定する

第1章　アジャイルパフォーマンスを測定する

第1部・第1章の読書メモ

  • フィードバックループ（収集・測定・対応・反復）の中でメトリクスを活用することで、コミュニケーションを改善する
  • メトリクスとは、アプリケーションのライフサイクルから得られるデータ
  • アジャイルチームの測定は、立場の違いによって何を良いとするかが異なるので難しい
    • 同じ道を走っていても、良いとする物差し（車のメーター）が異なる
  • 異なる物差しのまま良いかどうかの会話はできない。そのため、同じ物差しで見れるようにデータを変換することでコミュニケーションのギャップを埋める必要がある
    • アジャイルのメトリクスはツールであり、そのツールを用いてコミュニケーションをとることが大事
  • アジャイルメトリクスを理解する上で問題になりやすいポイントがある
    • アジャイルのメトリクス測定の定義は複数の考え方（思想）があり、混乱しやすい
    • アジャイルはプロジェクトではなくプロダクトに集中するので、ガントチャートのようなプロジェクトにフォーカスするツールは不向き
    • データがあちこちに散らばっているので、統一して表示できていない
  • フィードバックループの最初の一歩はデータ収集
    • プロジェクト管理ツール（Jiraなど）からデータ収集
    • ソースコード管理（GitHubなど）からデータ収集
    • ビルドシステム（CI,Jenkinsなど）からデータ収集
    • システムモニタリングからデータ収集
  • フィードバックループの次の一歩はデータの分析
    • 何を分析すべきか（重要なことは何か）を理解するために、マインドマップを利用する
    • データを可視化する
  • 実践しよう！
    • オープンマインドでいること
    • 物事をポジティブに考えること
  • オーナーシップ
    • 賛同を得る
      • データ収集やメトリクス把握は1人で始めることもできるが、理想的にはチームと協力して全員が共通認識を持っているのが望ましい
    • メトリクス否定派
      • 自身の仕事が測定されることに非協力的な人もいる
        • 未知への恐怖、支配者への恐怖、コントロールの欠如などが背景にある
      • ポイントは、自分自身の測定は自分自身で行うべき
        • 外部の人間やシステムから良し悪しを指摘されるべきではない
      • よくある反発
        • そもそも、人は測定"される"のが好きではない
          • 自分がすすんで提供するか、人から測定されるかの違い
        • メトリクスはプライバシーの侵害？
          • ではない。改善の一手法
        • メトリクスがプロセスを重くしている？
          • 逆。メトリクスはプロセスを改善する方法を特定するのに役立つ
          • 手動でメトリクスを作成している場合は、メトリクス収集とレポート作成は自動化したい
        • メトリクスは難しくて時間がかかりすぎる
          • 本書を読もう！

第1部・第1章の感想

  • メトリクスと聞くと堅いイメージがあるが、メトリクスを活用してコミュニケーションを改善してほしいというメッセージが示されているのは意外だった
  • アジャイルチームの測定が難しいのは、立場の違いによって何をよいとするのかが異なるためというのはその通りだなと思う
    • スクラムでいえば、Dev/PO/スクラムマスター/ステークホルダーという立場の違いで、何を良いとするか・そのために何を見たいかが異なってくる
    • そのため、一言に「チームの状況を見えるようにメトリクスの整備をしよう！」と言っても、立場の違いで見たいもの・見えるようにしたい背景が異なるために、一筋縄には進まないことが多い
  • メトリクス否定派に言及しているのが印象的
    • メトリクスと聞くと拒否反応を示す人が少なからずいるのは、日本に限った話ではないのかもしれない
    • メトリクスと聞くと「重厚」「大変そう」「動きが遅くなりそう」というイメージを私は持ってしまうが、本書はメトリクスはプロセスを改善する方法を特定するのに役立つと明言している。

この先を読み進めるのが楽しみです。