根拠なき自信は普通、希望的観測に基づいている。これは、予想した現実と実際の現実がかなり乖離しているかもしれないが、ある期間、すべてを制御できていると感じる状態だ。アジャイル開発にはこのようなチームが根拠なき自信を支えにして最終的には失敗してしまうことが多い。
Mike Griffiths氏はMalcom Gladwell氏が根拠なき自信のレベルは得られた情報のレベルに関係することを示したセッションを引用している。氏は精神科医が患者についての情報を得ることを事例に挙げる。ひとつのパラグラフ分の情報がある場合、自信のレベルは25%くらいになり、評価の精度も25%くらいになる。反対にデータが徐々に増大して10ページ分くらいになると、精度はわずか29%に上昇するだけだが、自信は90%に達する。
氏はビジネスに必要な自信を作り出そうとしている会社があることを指摘している。仕様や文書、プロセスを何か寄りかかれるものとして利用するのだ。しかし、この支えがひどくおかしくなることは何もないという根拠なき自信を生み出すのだ。
文書や何かを使って自信を生み出すとき、おそらく間違っている仮定(仮定は現実がはっきりしていくと崩れ去ってしまうのが常です)に自分を縛ってしまうのが問題なのです。記録済みのノウハウがあると安心できるかもしれませんが、それが、間違いだったらどんな意味があるのでしょう。
テストについても同じことが言える。J.B.Rainsberger氏は"結合テストは詐欺だ”と言っている。このように感じるのは、結合テストの書かれ方に依存するが、チームは根拠なき自信を感じる可能性がある。Mark Needham氏によれば単体テストでも同じことが当てはまる。
確実に実務上役に立つ単体テストを作ることが重要です。そうしないと、テストのコーディングとメンテナンスのコストがテスト実施から受けられる利益を上回ってしまいます。
同じように、Doug Rathbone氏は多くのチームが自動ビルド環境があることに満足していると指摘している。しかし、鍵は自動ビルド環境があることではなく、ビルドと配置を自動的にできる能力を持っていることだ。
自動でビルドしたものを配置できなくても、人間の失敗に対する依存状態をもっと製造工程の下流の方に持っていくだけです。そして同時にプロジェクトの成果を簡単に出荷できる能力に対する根拠なき自信がうまれます。
また、コード凍結という概念が利害関係者に根拠なき自信を与えている。Jonathan Leffler氏はコードを凍結するふりをすることで生まれる根拠なき自信が生み出す価値について興味深い疑問を投げかけている。
このような状況のことを"コード凍結"と呼ぶのはある種の意図的な二重思考であり、これが利害関係者に根拠なき自信を与えていると思います。あるいは、スクラムでは各スプリントの後には出荷可能なソフトウエアの一部が出来上がり、それがスクラムに対する期待になっているので、"コード凍結"のふりをしているのかもしれません。なので、実際にそれが意味することの代わりにスクラムが期待することとして言葉にしてしまうのです。
また、仕様書も根拠なき自信の構築に大きく関連する。Mikeによれば、
仕様書は見積もりの失敗を生み出しやすいものです。仕様の収集、検証、代替案と例外の詳述に多くの時間をかけると自然に自信が生まれます。
根拠なき自信は生み出すものの、価値を生まないあなたのプロジェクトではどんな支えがあるだろうか。
Design and Code &qu