薄々気がついていたけれど、自分は、大小を問わず"失敗"することを嫌う気質があると、最近ハッキリと自覚できた。 そして、これがWeb開発という領域において、致命的と思えるほどに悪癖になりうると気づきつつあって、向き合うためにここに書いてみようと思う。
きっかけは、TerraformによるAWS Fargateの構築でうまくいかなかったことがあり、人に相談してみたところ「とりあえずタスクを手動で実行してみたらどうですか？」と言われ、「え、そんなことしていいんだっけ？」と臆してしまったことにある。 彼から「いま失敗すると何か困ることあるんでしたっけ？」と言われて、確かに、まだそのプロダクトは本番環境で稼働しているわけではないので実害なんて出るわけないことに気がついた。
こんなことわざわざ言語化するまでもないのだが、現代のWeb開発において、失敗することによって得られるエラーはフィードバックの宝庫だ。 実際この件についても、細かく手動での実行を行い、そのエラーメッセージを見てのトライアンドエラーを繰り返すことで、なんとか不慣れな構築を行うことができた。 解決のための技術的なアドバイスに加えて、「フィードバックを得るために"早く失敗すること"を心がけるべき」と助言をしてくれた彼には感謝してもしきれない。
これ以降、くだらないことでも失敗を極度に嫌う自身の思考を省みることが増えた。
- 料理やってて、レシピの工程を1つ飛ばしたことにあとから気がついただけで、必要以上に落ち込んだり。(別に味の違いはなかった)
- 最近やってたゼノブレイド(RPG)、全滅によるデメリットがほぼない(最寄りのランドマークに戻されつつ、得られたアイテム/マネー/経験値は減らない)のに、ちょっとリスクある敵との戦闘はすごく消極的になってしまったり。
そして、こういう自分に気がついては「これくらいの失敗を恐れるべきでない」なんて理性的に考えたりする。 「失敗を恐れるべきでない」なんて手垢がついた言葉、こんなに自分が実践できていないだなんて思っていなかった。
また、ただ失敗するだけじゃなくて「早く失敗する」というのがより大事で、それを実現するには技術が必要だというのも感じている。 安全に早く失敗することには、リカバリが効くように影響を局所化しつつ、有効なフィードバックを得る方法を考える必要がある。 たとえば、アプリケーションの設計は実際に運用してみないと良し悪しがわからないことが多いので、早く失敗するには
- どの機能なら影響が小さいか
- どうすれば速やかに元の状態に戻せるか
- 何の指標でフィードバックを得られるか
- どういった手段でフィードバックを得るか
といったことに向き合うことになる。 これらを考えることは、長期的にメンテナンス可能なアプリケーションを設計するのと同じくらい重要なことと感じる。
こういった思考のクセみたいなものは一朝一夕では直せないとわかりつつ、こうやって言語化して向き合うことでもうちょっとマシになったらいいな。
