データ収集は、将来のコスト予測を助け、プロジェクトや組織の現在の状況を評価し、経営、プロセス、または技術の変更が及ぼす影響を評価する、といったことのために、極めて重要である。その一方で、データ収集を押し付けがましいやり方（例えば、そのためにソフトウェア技術者がかなりの時間、余計に働かなくてはならない）で実施すると、そのやり方自体がデータに影響を与えるので、集めたデータに意味がなくなる。その上、そのようなデータをとることを望まない開発者から集めたデータは、非協力的な開発者が意味のあるデータを提供するとは考えられないので、役に立たないものになる可能性が高い。
データ集めの最良の方法は、開発者が煩雑な仕事をさせられていると感じることがない、自動的に集めるやり方である。いつもデータばかり集めているわけにはいかないのは明らかなので、できる限りデータの収集を自動化すべきである。
（２０１の鉄則：原理１４３＜管理の原理＝押し付けがましいデータの集め方をするな）
ソフトウェアの開発で、この種のデータの収集は殆ど行われていないのではないかと思われます。開発者にとって、まさに事務的な作業に見えることが、一つの原因でしょう。また、そのようなデータを集めることの意義を認識していないことも原因でしょう。さらには、そのようなデータを集める方法がうまく考えられていないことも原因かと思います。
デマルコの言葉に「計測されないものは改善されない」というのがあります。つまり、計測されてそれが見えるようになって初めて、プロジェクトの状況や組織の状況が分かります。たとえば、そのチームはマイルストーンを３回も遅らせていて、遅延の幅は、合計で３８日に達するとか。
また、レビューは実施しているが、後で報告されたバグ統計の中で、その工程に属するものが１５７件もあり、それに対してレビューで指摘されたのは１５件しかないというところから、レビュー効率が見直され、レビューの仕方やその際の成果物のあり方などが検討されたりして、適切な対応策を講じることも出来ます。
テスト結果としてのバグの統計や、ソースの書き替え回数、時間あたりの設計作業や実装作業の生産性などから、適切な設計が為されているかということも見えてきます。ハードに限らず、設計の善し悪しは、その後の実装作業やテスト作業のコストに大きく影響してきます。
そして欲を言えば、このとき「プロセスの定義」が行われていれば、状況が分かるだけでなく、どのプロセスが原因かということも見えてきます。
一般に、設計者にとっては、設計作業以外のことをやることには抵抗があるものです。設計者が、データ収集のメリットを享受していない状態では、そのような「文化」が広がることを避けるのは難しいでしょう。そのような状況で、何らかの協力を求めるには、集めようとしているデータの種類、その目的、そして収集方法を分かりやすく説明しなければなりません。
このとき、一般に設計者は批判的な姿勢になっていますので、目的とデータの種類に合理性が認められないとか、データの収集方法に無理があるようだと、抵抗にあう可能性があります。そして、一度拒否されると、しばらく再提出は難しくなりますので、最初に取り組む際は、準備を整えて慎重にやる必要があります。
もちろん、そこに存在する文化とは別に、組織のトップから強制する事も可能ですが、その場合、表面的には従っているように見えても、本心は批判的な状態にある可能性があり、そのしわ寄せが成果物であるソフトウェアの方に出てしまう危険性もあります。
現状では、まずは、この種のデータを収集する意義を、広く知らせる所から入るべきでしょう。設計者も、現状を良しとは思っていません。今のやり方のどこが悪くて、どこを改めればよいのか知りたいのです。そして現実の作業を進めながら、そのような転換が出来るかどうかも知りたがっています。ただ、そのときそれまでの自分が非難されることは恐れています。
今日の時代の状況を考えれば、いつまでも同じようなバグを出し続けていては、自分の存在そのものが危うくなるということは感じているのです。そのような不安定な心理状態の状況にあって、今まで以上に負荷がかかることには防衛反応から、攻撃的な対応に出てしまいます。昨日までは、このままではいけないと思っていてもです。データ収集の提案は、多くの場合、このような状況の中で行われることになるということを、関係者は認識しておく必要があります。
従って、データ収集は、設計者が乗りやすいように、最初の数段のステップは低くしておく必要があります。もちろん、低くてもそれなりの効果が得られるものはあります。実際、殆どの組織では、バグ情報の“収集”は行われています。そこには、設計者が“原因”と思しき状況を説明していて、これを加工することで、設計者にフィードバックできる有効な情報は手に入ります。このとき、バグへの対応の際に、もう少し書き込んでもらう情報を追加したり、そのデータのばらつきを減らすためのマニュアルを作って説明することも有効でしょう。そうして、この種のデータ収集に協力した方が、結局は自分たちにとってプラスになるということが分かれば、設計者も協力してくれます。
そこで必要なことは、収集に無理がなく、乗りやすいということであり、その結果、自分たちにとって有効な情報が得られるということを理解してもらえるように、収集データとそれを加工することで得られる情報を明確にしてあげることです。
また、できるだけ設計者の負担にならないように、データ収集を自動化することも有効です。ネットワークが普及してきたことや、進捗会議の資料も、プロジェクターなどの普及に伴って最近では紙に出さなくなりましたので、設計者に負担をかけずにデータを集めることが出来ます。一方では、構成管理ツールの普及によって、ソースの更新状況が見えますので、そこから作業の効率に関連するデータが集まります。必要なら収集のためのソフトを作っても良いのですが、既存のツールを少し改良するだけでも、良質のデータが手に入ります。
このとき、重要なことは、収集したデータを個人の評価に使ってはならないということです。あくまでも、プロセスの改善に使うということに注意が必要です。これを間違えると、データの収集が出来なくなるだけではく、これまでなら収集への協力を拒否すれば済んだものが、収集が日常業務の中で自動化されていく状況では、この対応を間違えると、日常の開発業務そのものが停滞することになります。