Feedback Loop

何かを試すとき、いきなり全体に適用するのではなく小さい単位でまずは動かしてみる。例えば誤りのあるデータを修正するスクリプトを書く場合、いきなり全件を対象にすると失敗したときの影響が大きすぎる。一人のユーザーとか一つの会社とか、限定された対象でまずは試す。それがうまくいくと分かって確認が取れてから全体に適用する。

昔宇宙兄弟という漫画が好きで、その中で限られた予算でとある装置を作るという話があった。他のチームは予算を目一杯作って作ろうとする中、物語の主人公の六太は予算の半分で作れる設計を探す。疑問をもったチームメンバーから聞かれると、予算を目一杯使うと失敗できなくなる。試行錯誤が大事だから二つ目を作れるように進めたい、と話す。どれだけ緻密に考えられたものでも実践投入すると気づかなかった綻びが見つかる。それをあらかじめ計画に織り込む。失敗してもゲームオーバーにならない座組を整えておく。

似たような話として、何か大きいものを作る時はいきなり作り出さないという話がある。事業であればいきなり全国展開するのではなく、特定の市区町村で小さく試す。システムであればいきなり仕組みを構築せず、まずは手探りでうまくいく部分を探す。スタートアップ向けのアドバイスで「スケールしないことをやれ」とよく言われる。例えばAIとチャットして美味しいレストランを探すサービスを企画し、作ることを考えてみる。AIのロジックがコアだと思って先に作ってしまいがちだが、実はその前にニーズを検証した方がよい。そのためにはシステムの裏側で人が待機して、ユーザーからの入力があったらその条件に合う店を食べログなどで検索して探し、AIのフリをして返事をすれば良い。これでユーザーが満足するか、感動する体験になるかは十分検証できる。それが確認できたらその時初めてAIのロジックに着手する。人間が対応するのはマンパワーが必要なのでユーザーが増えてくると回らなくなるが、数十人くらいならなんとかなる。スケールしないことをやることで、短い時間でサービスのヒット確率をあげる。AIのロジックを作るまでもなく、世の中に受け入れられるコンセプトかを確かめられる。

新しいサービスを作るときも、最初はユーザー数の拡大ではなく誰かに深く刺さる体験を探す。自分や友人、身近な困っている特定の誰かを助けるものを作る。それを磨いていってしっくりくるラインまで来たら拡大路線に入る。小さく試して、それから拡大する。このパターンは胸に刻んでおきたい。