Feedback Loop

学校生活で正解を求めてきた私たちは「わからなさ」の前では立ち尽くしてしまう。社会人になって仕事を始めると、最初の頃は分かりやすい正解が目の前にある。上司に認められる仕事、取引先に喜ばれる仕事。良いと思う先輩の真似をすればある程度評価される。しかしある程度の期間が経つと自分なりの答えを出していく段階に移行する。例えば後輩との接し方。細かく仕事を教えるのか、目的だけ与えて自由にやらせてみるのかに正解はない。自分が正しいと思い、後悔のない選択をしていくことになる。

「わかる」仕事をやっている場合、ゴールまでの道がある程度見えている。「考えすぎフラグメンツ」の最新回ではこれをトンネルと表現する。入り口に一度入れば、道を正しく進めば出口に必ず辿り着く。一方で「わからない」仕事の場合、これは松明をもって洞窟を歩くのに近しい。この道を行こう、という選択に意味はなく、微かな光を頼りに少しずつ道を見つけながら前進する。トンネルで壁に当たると事故だが、洞窟では壁にぶつかって得られるフィードバックは道の輪郭を写し出し、前進するヒントになる。わからなさを怖れて身動きが取れなくなるのではなく、どうしたら少しずつ周りを照らしていけるかを考えるマインドチェンジが必要になる。

Webサービスを作っていて「これをやれば必ず売れる」という正解の道は今や存在しない。そうではなく「これが良いと信じている」という気持ちで出発する。数年間作り込んでからリリースしようとすると大体失敗する。これはその数年の間に世の中が変化するし、結局のところユーザーに受け入れられるかどうかは出してみないとわからないから。どうすれば少しずつ周囲を照らせるか？コアとなるコンセプトの部分だけを作り込み、早い段階でリリースして反応を見る。本当に必要とされるものなら出来が悪くても反応がある。逆に無反応であれば、細かい部分を作り込むよりコンセプトの検証が先に必要になる。

こうした小さく始める動きはWeb界隈で主流になっている（Minimum Variable Product = MVPと呼ばれる）。小さく仮説検証するのは正しいが、小さすぎては検証の土台にも立てないことに注意が必要だ。例えば可愛いデザインに特化したTodoアプリを作るとする。タスクの登録とチェックを入れられる機能だけ作り、デザインを作り込んでリリースしてもおそらく反応は得られない。これはTodoアプリに最低限必要とされる機能（フォルダ分けやリマインダー、通知など）がないと比較の土台にも立てないから。作り込みすぎるのは危険だが、スタート地点に立てないクオリティのものを出しても風は吹かない。良いフィードバックを得られるだけの品質はキッチリ作り込む。「早めにリリースしてOK」は楽ではなく、むしろ頭を捻り続けないといけない厳しい道のりに感じている。