アジャイル開発はメトリクスが取りやすい

アジャイル開発はメトリクスが取りやすいのではないか、というアイデアについてメモ。

【1】日本のWF型開発では、メトリクスは特にテスト工程で重要な意味を持つ。
バグ密度、テスト密度、コード行数(LOC)などの品質目標をテスト計画時に立てて、その品質目標をクリアしたという判定によって、リリースOKの決定が下される仕組みにあるから。

しかし、WF型開発では必ず結合テストでビッグバンテストになって火を噴く。
障害が多発して、その分テストケースも増えてしまい、バグ密度やケース密度も当初の品質目標を大幅に超えてしまう時が多い。
すると、その品質評価が良かったと結論付けるために、プロジェクトリーダーは四苦八苦しながら、テスト報告書を書く羽目になる。

【2】アジャイル開発では、メトリクスは次のイテレーションへの予測として使われる。
例えば、XPが見つけてScrumがフレームワークとして組み込んだメトリクス「Velocity」は、開発チームのイテレーション単位の平均開発規模だ。
つまり、Velocityは開発チームの開発ペースに相当する。

Scrumでは、4週間の1スプリントで、ストーリーポイントで計測した開発規模によって、開発した実際の開発規模を得る。
それが、Velocityになる。
すると、次のスプリントでは、直近のスプリントのVelocityから、かなり精度の高いVelocityを予測することができる。
そこから、次のスプリントでも、同じくらいの開発規模を作れるだろう、と予測できる。

リーン開発では、1機能を開発チームが受け付けてリリースするまでの時間をサイクルタイムとして計測する。
サイクルタイムが短いほど、顧客の要望を素早くリリースできることにつながり、売上やROIを高めることに貢献する。

かんばんを使って、1機能を1枚のPostItに書き、受付日とリリース日を記録すれば、簡単にサイクルタイムを採取することができる。
サイクルタイムを短くするために、仕掛り中の作業の数(WIP)を制限したり、バックログに組み込まれるストーリーカードを減らす、などの是正対策を取ることになる。

WF型開発のメトリクスは、テスト工程というプロジェクト後半にならなければ、バグ密度、テスト密度、コード行数(LOC)などが得られない。
そこで得られたメトリクスも、本番リリースが終わってしまえば、プロジェクトも収束し、プロジェクトにかかわったメンバーも散り散りになるために、そのメトリクスを次の2次開発で使ったとしてもあまり精度が高いとは言えない。

アジャイル開発の方がWF型開発よりも、直近のメトリクスを収集しやすく、そのメトリクスを直後のイテレーションで試すから、精度はかなり良いだろう。

【3】そもそも、なぜそんなメトリクスが必要なのか？
WF型開発では、メトリクスはリリース判断基準として使われる。
アジャイル開発では、メトリクスは次のイテレーションの開発規模の予測として使われる。

だが、メトリクスの本来の使用目的は、PDCAによるプロセス改善に使うべきものだ。
すなわち、メトリクスという指標によって、開発の現状のどこに問題があり、どの部分を改善すべきかを診断するために使うべきだ。

メトリクスは、健康診断のようなもの。
例えば、コレステロールが高い、血圧が高い、血液検査の一部の値が悪い、などの指標(メトリクス)を定期的に計測することで、健康状態をよくするための処置を施す。
同様に、アジャイル開発やリーン開発では、Velocityやサイクルタイムを1イテレーションという定期的なタイミングで計測することで、開発チームの生産性や品質を評価できる。
それによって、開発チームの問題点を目の前にさらし、メンバーに改善を促す雰囲気を生み出すことができる。

WF型開発では、プロジェクトの最後でしか本番リリースしないために、メトリクスを採取するタイミングが遅く、採取したメトリクスを開発チームにフィードバックするタイミングがとても短い。
どうしても、開発チームを改善していくというスタイルになりにくいように思える。

【4】メトリクスに関しては、他にもいろいろ問題がある。
メトリクスを定期的に収集して評価することで、メンバーの行動を局所最適化してしまうという「メトリクスの罠」が有名。
メトリクスは、メンバーの行動をより良い方向へ向かわせるのではなく、都合の良い評価になるように、本来の目的と違った行動にしてしまう悪影響が多い。

また、従来の開発環境では開発プロセスのメトリクスを計測しにくいという弱点もあった。
メンバーに予定・実績工数を入力させたり、障害票を入力させたりするのは、Excelや紙ベースだった時代は大変だったはず。
同様に、プロジェクトリーダーが入力された予定・実績工数をメンバー単位、期間単位、プロジェクト単位に集計したり、テスト消化曲線や信頼度成長曲線を作成するのは、従来は大変だったはず。

しかし、Redmineによるチケット駆動開発というインフレがあれば、そんなメトリクスはすべてチケット集計機能で置き換えることができる。
それによって、メトリクスを使ってプロセス改善に適用するというやり方も、もっと手軽に行える。
メトリクスの罠は、アジャイルチームにおける自律的なチームを目指せば解決できると考えている。

「メトリクスを使ってプロセス改善する」という古くからのやり方は、現代のIT化のトレンドの中で、もう一度、その形式をブラッシュアップすべきだろうと思っている。