http://martinfowler.com/bliki/AnecdotalEvidence.html

ソフトウェア開発分野で不満なのは、いくつかある技術やツールの中からひとつを選ぶのが難しいという点である。 この話題になると、その技術やツールが他の選択肢よりも優れているという「確かなデータ」を見せろと言う人が必ずいる。 それはもっともな要望だ。しかしそれは、絶望的な要望でもある。 なぜなら、CannotMeasureProductivityだからだ。

確かなデータがなければ、事例証拠に頼ることになる。 実際、私はこれまで事例証拠の分析に基づいた考えを広めることに費やしてきた。 客観的に計測できる事象には劣るかもしれないが、事例証拠を無視するのは賢明ではない。 そもそも、事例証拠以外に我々は何から学べるというのだ？ 我々は自身の経験から多くのことを学ぶ。 それに他の人の経験が加われば、情報源に厚みが増す。

こんなことを言うのは、自分自身の経験をレポートする人たちを見るのが好きだからだ。 それが特殊なものであろうが、計測によって裏打ちされたものでなかろうが、構わない。 読者はレポート内容の限界を理解し、自分の環境にその教訓を適用できる場合に、自分たちのできることだけ採り入れるだろう。

昨年、あるカンファレンスのプログラム委員会に参加し、3本の論文のレビューを行った。 いずれの論文もソフトウェア開発を向上させ得るアイデアについて述べていた。 致命的な欠点は、著者がそのアイデアを実行していないということだった——ただの一度もだ。 よって、私はすべての論文に対し、「却下」に一票を投じた。

この考えをさらに進めている人もいる。 複数のプロジェクトで散見されるまで、その考えについて述べてはいけないのだそうだ。 これは素晴らしい考えだと思うが、複数のプロジェクトで散見されることが必ずしも必要なことだとは思わない。 ひとつのプロジェクトで発見された特殊な事例のレポートも有用である。 他の人にとってそのレポートが「原材料」となるからだ。 他の誰かがあなたと同じような立場にいるかもしれない。 そんなとき、あなたのアイデアが足がかりとなる。 他の誰かがあなたと同じようなことを既にやっているかもしれない。 そうであっても、あなたのレポートを元にしてレポートを書くことができる。

以上のアプローチ——ある人が事例をレポートし、他の人がそれを（成功してようがいまいが）真似をするアプローチ——は、プロの学習方法のバックボーンとなる。 事例だからといってうまくいかないということはない——結局のところ、経済システムというものは、どのようにビジネスを経営すればよいかという他人の事例に頼った「人」の上に築かれるものなのだ。