前回の投稿では、チームを独立させることの大切さについてお伝えしました。今回の投稿では、間違いを学びに変えていくことを、Indeed ではどのように奨励しているかについて触れていきたいと思います。
多くの組織では、間違いと言うのは、計画には絶対に含みません。計画は常に成功するものとして、設定されます。計画というのは、「これやあれがさっぱり間違っていた場合」なんていう段階を含まないのが普通です。ほとんどの場合、これは単なる癖によるものであったり、時には誰かのエゴがそうさせていたりします。
…このアイデアすごい冴えてるし、失敗なんてありえないよ。皆を集めて、素晴らしさを祝おうぜ。失敗しても、プロジェクトオーナーのせいにすればいいよね、絶対あいつらのせいだから。それとも、要件を理解できなくて、技術的問題を解決できるほど賢くなかったエンジニアのせいにしようか。いやいや、マーケティングチームとかセールスだよ。あいつら、競合も欲しがってたプロダクトを手に入れたくせに、こけたんだからさ…
NASAは、月に人を送る前に、何度失敗を重ねてきたのでしょうか。スペースXは、初めて帰還に成功するまで、いくつロケットを失ったでしょうか。これらの組織が成功したのは、間違いをおかさなかったからではありません。むしろ、どう間違えて、そこから学んでいくかというプロセスの定義をしていたからです。
Indeed では、間違いが学びに変わるように、間違いをプロセスに組み込んでいます。
- 推測を特定する 自問自答をし続ける代わりに、あなたのアイデアが失敗するものだと思っている人に相談してみましょう。このときお互いを説得しようとしないこと。（たいてい無理なので。）代わりに、科学的に、どこに真実があるのか実証するような、可能な限り最小の実験ができるよう摺り合わせてみましょう。
- テスト・フレームワークを使用する ビフォア・アフターの比較は、通常、多くの人が取る手段ですが、弱点もあります。外的要素はどうなるのか？複数の実験を、どうやって同時に行うのか？ Indeedでは本番に送るもの全てに対して A/B テストを使用します（優先度の高いバグを除く）。
- 出来るだけ細かいステップを踏む 一度に一つの事を変更しましょう。複数の推測や変数を同一の実験の中にいれるのは避けること。
- 責めない 本当の間違いは、何も学ばないことです。何かが上手くいかないとき、結論を出して、次の実験に移りましょう。素早く失敗すれば、間違いは、キャリアにとっても個人的な妨げには、なりません。
次は ?
次回の投稿では、冗長性や非一貫性として表される技術負債の一種である、統合負債 (consolidation debt) の管理についてお伝えします。