失敗を認めて頑張るべきところと失敗のない安全性を重視すべきところ

あるいは Kanazawa.rb meetup #76 に行ってきたよ の話。

割といつも言ってることと同じなんだけど、まぁせっかくなので。

エンジニアが集まると

なんでそんなものになってしまったのか？

みたいな話で割と盛り上がれるわけですよ。

それ要る!?

みたいなやつ。

そういうのを避けるために自分は「インフラは持つべきではない、全部PaaSかフルマネージドにしろ」という選択を数年前にしたんだけど、最近は「バックオフィス業務で独自に開発はすべきでない、そもそも開発を外部に依頼するのは難しいし、独自に作らなきゃいけないものなんてほとんどない」と思っている。

で、これって、結局「余計な失敗をしない」ということなのだろうなぁと思っている。

何か作れば、何かやれば、それには失敗がつきものだ。避けようがない。そしてその失敗をなくすためには実はかなり大きな、時に測定不能なコストが発生する。

なぜか人は何かをやる時にこの「余計な失敗を抑え込むためのコスト」を甘く見積もり、結果として恒常的にリソース不足になっていたりする。そして自分がやってきた自動化は要するにこれらをなくすためのものなんだなぁと思うようになってきた。deploy の自動化、provisioning の自動化、テストの自動化。¹

これらはそれ単体では実はそんなに価値はない。でもここで余計な失敗をしないことで何回でも安心して実行できる。上記の何かを「実行する」ということは「何かを新しく作ったり変更したりしている」ということだ。

その「何かを新しく作ったり変更した」結果、それが失敗だったり成功だったりするかもしれない。例えば思ったより全然便利じゃなかったり、思ったより面白くなかったり、そういうことだ。しかし成功だった場合はそれが「価値」になる。この「価値」を生んだり大きくしていくことが事業としての「開発」において最も大切なことだが、その「価値」を見つけるのは実は容易なことではない。

2C なら Consumer, Customer が喜んで使ってくれる、遊んでくれる何かが「成功」だが、それを見つけるには何回も何回もチャレンジが必要だ。そのためには新機能はすぐに追加できてすぐに取り外せた方がよい。

2B なら目先の課題がただの全体の歪みの一部が表出された何かでしかない場合がよくある。本当は全体の歪みの原因を見つけるまではやはり同じように何回でも変更できるようにしたり、まずは既存のシステムに乗せて「実際にやってみることで課題を洗い出す」ということが必要だったりする。既存のシステムに載せるということは、その部分で「開発そのものの失敗をなくし」「本当の要件の抽出の失敗をなくす」ことである。

やってみたこともないのに何が必要で何が不要かを決めるのは実はとてつもなく高度なことで、それそこ失敗して当然である。だからその失敗を許容するために、その他の要らぬ失敗を排除することが大切になる。

で。

最近よく思うのは、こういう話、実際に作り手になったことがない人には通じないんだよなぁということ。結果として、「いやいや、できた結果ダメだったってなったら単に余計なコストが上乗せになりますよ？」という話、全然想像できないどころか、相手の話を真剣に聞いていない場合は想像する必要すら感じてなかったりする。

でもさ、余計な開発は余計なランニングコストを生みますよ。見て見ぬふりしたいかもしれないけど、作っちゃったらもうゼロ円は無理なんですよ。それよりはアリモノを Subscription で使った方が結果安かったりするわけです。

ということで、これからも仕事では「価値を生まないモノ、価値を生まない作業」にコストを掛けすぎてはいけない、それが「本当に価値を生むモノや価値を生む行為」を阻害しないようにすることを意識して、コードを書いたり書かなかったりしていこうと思いましたとさ。

ま、当たり前の話ですね。