なぜ世界の開発現場では｢失敗｣を重視するのか 生産性低い日本人が知らない｢Fail Fast｣の価値

私がアメリカであるお客さんとディスカッションをしていて驚いたことがある。リュックを1つだけ背負ったその兄ちゃんが、私と上司のダミアンに会いに来て1時間ぐらい話をしたあと、「うん。やろう」と言って、500人規模のハックフェストをその場で決定して帰っていった。

これが日本なら、まずベンダーが提案して、顧客がそれを見てExcel で質問票をつくり……といったやり取りを数カ月行って、結局はやめたみたいなことがしょっちゅう起こる類の案件だ。

これはベンダーにとっても顧客にとっても大きな損害で、工数を使って結局は何も生み出せていない「ノーバリュー」の仕事なのだ。

机上の検討を積み重ねても現実に即応できない

でも1時間で物事が決まって、実際にハックフェストを実施すれば、本番環境の検証がわずか数日でできてしまう。

Excel でいちいち質問票をつくっている時代ではない。そんな暇があったら、実際にハックして確認したほうが100倍確実な成果に結びつく。

今の時代、検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に銘じてほしい。やらないほうが必ず失敗する確率が増えるのだ。

机上でいくら慎重に検討しても、実際市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーが適切に動作するかは、実施するまではわからない。

だから少なくとも変更がしやすいソフトウェアの世界は、アジャイルのように早く実装して、早くフィードバックを得る方式のほうが合理的だ。

でも、「早くやるのはいいけど、ちっとも進歩せず、同じ失敗ばかりを繰り返す人（チーム）もいるじゃないか」と思う人もいるかもしれない。ごもっともな指摘だ。

そこへの回答は「評価」だと思う。