成功事例には興味がない

むかし会社の先輩からこんな事を言われて、とても共感した。「成功体験は共有する意味があまりない。なぜなら、成功原因がなにかなんて、わからないから」。ソフトウェア開発の世界では沢山の「成功事例」が発表されている。個人の情報発信が発達して、沢山の「成功」が世に溢れる。本当に大切な「失敗談」はどこにいけば知れるのだろうか。

成功要因は一般化できない。

ソフトウェア開発が成功したとして、その成功要因を特定して一般化することは難しい。新たな方法論の適用があったかもしれないが、じつは柔軟性の高いプロジェクトオーナーその人が成功の理由で、方法論は真の成功要因ではなかったかもしれない。もしくは、たった一人の献身的なエンジニアの働きが戦況を変えたのかもしれない。成功は、実力だけではなく幸運の賜物である。同じソフトウェア開発プロジェクトは二つとない。まったく同じように振る舞っても、成功を繰り返すことはできない。確実に成功するための処方箋―銀の弾丸―は存在しない。

(略)スピードの一段の加速が、次のような仮説が誤りであったことを浮き彫りにしつつある。「今年やってきた狼（ソフトウェア）はこの鉛の弾丸（ソフトウェア技法）でやっつけることができました。来年奴らの進化した子孫が現れたとしてもまた同じ弾丸でやっつけることができます」
アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～

失敗から学習する。

成功を模倣することは難しいが、失敗から「失敗しないための対策」を学習することは出来る。失敗の原因はなんであったか。プロジェクトのどのタイミングで失敗が組み込まれたのか。二度と失敗しないためにはどうすればよいのか。失敗から学ぶことによって、着実に「失敗しなくなる」。失敗から学ぶことが、成功への近道ともいえる。

とはいえ、自分のプロジェクト、自分のキャリアの中で失敗経験を積み重ねるのには限界がある。ならば人のプロジェクトに目を向けたらいいと思う。まわりのエンジニアの苦労話にこそ、価値のある失敗談が隠されている。

昔話の飛行機乗りは、格納庫で車座になって経験談を語り合ったという（少なくともエリア88にはそんなシーンがよくあったw）。そこで語られていたのは新しいハックではなく、苦労話なのだ。失敗談の共有で経験値を高める。他人の成功談ー美談ーを聞く暇があったら、近くの仲間と話をしたほうがいい。上司から、うまくいっていないあのプロジェクトの話を聞こう。

もし話を聞く相手がいないのだったら、こんな書籍を読むこともできる。現代的に言えば完全なデスマの伝説である。

闘うプログラマー[新装版]