小さな失敗を許容するチームは、結果を求めずに何を得れば良いのだろう

これまで、プロジェクトなどの仕事の中で

「小さな失敗をしよう」

と何度か書いてきました。仕事で失敗をするなんて、と思うかもしれないけれど、失敗することを嫌っていたら、今の確実に仕事を捌ける確立された仕事の手順でしか成果を出せない、ということになります。

これ、とてもエンジニアとしては危険なシグナルを自ら発していると気づいて欲しいです。

確立された手順は楽チンだけど

仕事を進める上で、確立された手順があるということはとても楽です。同じ環境構築をするにしても、構成情報だけが違うのであれば単なるパラメータ違いでしかありませんから、既存の手順にインプットするパラメータだけ確認しながら作業すればいだけです。

楽ということはそこに学びがありません。楽ばかりしていると技術スキルは陳腐化し、技術価値は低下します。これも毎度言っていることですけど。手順化できるということは、機械化で置き換えられる可能性がとても高いです。置き換えられるということはより低価格の人的リソースに置き換えが発生するかもしれませんし、そのまま機械化され易い部分であるということです。

小さな失敗の「小さな」

小さな失敗とは担当するタスクの中で、プロセスや技術的な変更を試みる行為です。

なぜ、小さな失敗と「小さな」とつけているかと言えば、プールしている工数の中で失敗をしてもリカバリできる範囲で検証すると歯止めを掛けるためです。

小さな失敗の意義

小さな失敗は小さな失敗をするために行為をするわけではありません。仕事やプロジェクトの中で現状に課題があり、解決するための手段や期待する効果を得られるかを検証するために行うものです。

その検証結果では解決できないことがわかったり、期待したほど効果が得られなかったりした場合が「小さな失敗」なのです。

つまり、