No FLOP! 失敗できない人の失敗しない技術を読んだ

最近、『Google×スタンフォード NO FLOP! 失敗できない人の失敗しない技術』という、新規事業の失敗についての本を読みました。

この本は、スタートアップで成功してきた人がはじめて失敗した時に、なぜ失敗したのかを考えたものをまとめたものです。

読んでいて特に印象に残ったのは、「失敗をしないために失敗をする」という考え方でした。

大きく作ってから失敗するのではなく、作る前に小さく試して、そもそもの仮説が合っているかを確かめる。そのための考え方や実践方法が紹介されています。

この本で学んだことは、主に次の3つでした。

失敗をしないために失敗をする
- データを集める際に、作るのと同等のデータを集める
そもそもを間違えないために、xyz仮説を立てる
- これによって予想と仮説を立てることができて、データによって裏付けることができる。作らなくても検証できる
データは調べるのではなく、自分でデータを集める
- 身銭を切ったユーザーのデータを集める。作らなくても、擬似的に試したり、裏側は人がやっているような検証でデータを集めることができる。プレトタイピングと呼ばれる実践が紹介されていた

特に「作らなくても検証できる」という考え方が面白かったです。

新しいものを考えると、「とりあえず作ってみよう」となりがちです。もちろん作って初めて分かることもありますが、完成したものを作らないとユーザーの反応が分からない、というわけではない。

たとえば、実際にはまだシステムがなくても、人が裏側で処理することでサービスがあるように見せたり、ランディングページだけを作って本当に登録する人がいるのかを確認したりする。

「欲しいですか？」と聞くのではなく、実際に時間やお金を使うかを見ることで、かなり本番に近いデータを集められるという話でした。

この本を読んで、自分の仕事でのソフトウェア開発にもかなり近い話だと思いました。

エンジニアをしていると、問題があるとまず「どう実装するか」を考えてしまいます。

処理が遅いなら高速化する。機能が足りないなら追加する。運用が大変なら自動化する。

でも、その前に「そもそも、この機能は必要なのか」「仕様を変えれば解決できないか」「本当にコードを書く必要があるのか」と考える余地がある。

以前、仕事で重いクエリによる負荷の問題に向き合ったことがありました。

普通に考えれば、クエリを改善する、キャッシュする、処理を分ける、といった方法を考えます。ただ、その機能自体を見直してみると、数年ほとんど使われておらず、効果もそこまで大きくなさそうでした。

PdMに相談すると、そもそも削除して問題ない機能として認識されていて、結果的に機能を消すことで負荷問題を解決できました。

エンジニアとして派手な最適化をしたわけではありません。でも、プロダクトとして考えると、かなり健全な解き方だったと思います。

この本で出てくる「そもそもを間違えない」という話も、それに近いと感じました。

作り方を考える前に、作るものが合っているかを確かめる。

良いコードを書くことはもちろん大事ですが、もしかすると良いコードは、書かなかったコードなのかもしれないと思いました。

必要のない機能を作らない。検証だけならプロダクトを完成させない。仕様で解けるならコードを書かない。

コードを書くこと自体が目的ではなく、ユーザーの問題を解決することが目的なら、0行で解決できることも一つの良いエンジニアリングだと思います。

最近はAIによって、実装するコストがかなり下がってきています。

以前なら数日かかっていたものが短時間で作れるようになり、「とりあえず作ってみる」のハードルも下がりました。

これはすごく良いことだと思います。一方で、作るのが簡単になればなるほど、必要のないものまで簡単に作れてしまうとも感じます。

だからこそ、作れるかどうかよりも、「そもそも何を作るべきか」「作る前に何を確かめられるか」を考えることが、今まで以上に大事になるのかもしれません。

失敗をしないために、小さく失敗する。

そもそもを間違えないために仮説を立てる。

そして、作らなくても検証できるなら、まずは作らずに試してみる。

『NO FLOP!』を読んで、ものづくりでは「どう作るか」だけでなく、作るべきかどうかを考えることも同じくらい大切なんだと改めて感じました。