[#TiDD] チケットの属性とデータ収集

先日のつぶやきが予想外に評判が良くて驚きました。

データ収集をする際は、その結果がフィードバックされなければいけない。収集だけが目的なら協力が得られないし、いい加減なデータしか集まらない。チケットのフィールドも同じはず。 #TiDD

— さかば (@sakaba37) 2014, 5月 15

前半は1990年代後半のCMMブームのときにプロセス改善について語られていたことですし、後半は開発リポジトリからメトリクスを収集するEPM(Empirical Project Monitor)という環境の説明会でお話ししていた内容です。

これらの背景にあるのは、チケットの属性に限らず、データを収集する際に大切なことで、見える化、改善、成長の視点です。

問題の見える化であること

データを集めようとすると、ついついアレもコレもと思いがちです。しかし、闇雲に集めても意味がありません。見える化はただの可視化でなく、問題の見える化であるべきです。

無駄のないデータ収集には、GQMが有効です。ターゲットとなる問題に必要なメトリクスだけを収集すれば、効率的なデータ収集が可能でしょう。

参考：[#TiDD] ツール・技法の導入法

改善活動であること

問題を見える化している場合でも、それが管理を目的としていたのでは、その効果は限定的です。得られたデータに基づいて、QCD(品質、コスト、デリバリー)を改善しないと意味がありません。

良くない兆候を早期に発見し、早めに対策を打つことが効果的です。後になって大きな手戻りがない様に、フロントローディングしましょう。どのような時に問題が生じ易いかを予め開発者と共有しておけば、手戻りが小さくなるようにプロセスが改善されるでしょう。

参考：[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない

成長を支援すること

データを収集したなら、その結果だけでなく、分析結果をフィードバックして、組織の成長につなげましょう。技術の導入を優先する場合も(ライトウィング)、より良い社内文化を優先する場合も(レフトウィング)、最適な状態に向けて成長しないといけません。データを分析することでより本質的な解決策を見つけ出し、プロジェクトの成長を支援します。

たとえば、試験項目数が一定の比率以下だとうまくいかないことがわかった場合、単に試験項目数が少ないと指摘するのでは、無駄な試験が増えるだけです。もし、うまくいったプロジェクトを調査すれば、テスト設計に向けて必要な観点を整理していることや、試験項目レビューのチェックリストがあることがわかり、より良い開発の方法がわかるかもしれません。

収集したデータを分析して組織全体が成長できるように活かすことができたなら、無駄なデータを強制することによって形骸化することなく、ごまかしのないデータが収集でき、組織全体で良い方向に向くことができるでしょう。

参考：[#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」