具志ブログ(β版)

ピキーン!ときたフレーズや画像、動画なんかを俺のフィルタを通して紹介

14.できるだけ早く試作を作成する

スポンサーリンク

 できるだけ早く試作を作成する

スタートアップウィークエンドっていうイベントがあるんだけど知ってる?

nposw.org

たった3日間で商品やサービスを企画して作って売ってみよう、という結構無茶なイベントなんだけど、めちゃくちゃ面白い。

で、そこでやるべきと言われるのは「お金を払うであろう見込み客が実際に触れるものをさっさと作って、触らせてこい!」ってことなの。

いくら綺麗なパンフレットを作ってもダメ。

商品にお金を出させるには、現物を触らせてその反応を確かめるのが一番。

反応が悪けりゃ、どこが悪いのかを確かめるために、あちこち改良して、また実際に触らせて反応を確認しろ、という流れ。

机に座ってあれこれ話し合いやブレインストーミングに貴重な時間を使うな、さっさと手を動かせ!最低限の商品やサービスでいいから。

さて、これはプログラムでも同じことが言える。

どんだけ必要な機能や条件を「完璧に」リストアップしようとしても、それを作っている間に条件はどんどん変わっていく。

つまり、完璧になることは永遠にない。

だから、とりあえず「動くもの」を作って、それを使ってみる。

やりたいことが上手くできなければ、改良する。

今は上手くいってても、そのうち上手くいかなくなることも十分考えられるが、それはその時に対応すればいい。

ビジネスもプログラムも同じなら、もちろん、人間も一緒。

◯◯がやりたい、ってんなら、最低限の準備だけして動き出すこと。

できるだけ早く。

完璧に準備できることはないから。

そして、「やっぱりダメだった」でもいい。

直すべき点が明確化された、ということ。

人間による3つのシステム

この本では、プログラムの作られ方について「人間による3つのシステム」という、興味深いトピックがある。

  1. 追い詰められた人間が第一のシステムを作る
  2. 第二のシステムは委員会が設計する
  3. 第三のシステムの設計者には、ようやく「正しく」やることができる時間が与えられる

あるプログラムが、十分に成熟するまでのステップとして、三段階あるだろう、と。

第一のステップはこの定理でも挙げられている、「できるだけ早く」作られた、洗練はされていないが動いて使えるプログラム、ということ。

その洗練されていないプログラムを使った何名かが、次のステップの設計をする。

第一ステップではムダに見えるところを、委員会のメンバーの専門家たちがあれこれ知恵を絞って改善しようとする。

しかし、たいていの場合、この第二ステップでは改善というより、ムダを増やし、プログラムの実行を遅くしてしまう面も併せ持つ。

「こんなはずじゃなかった」と気づいた第二ステップのプログラムを使った人たちが、第三のステップを踏む。

そして、このステップで初めて、このプログラムは「何をするものなのか?」というシンプルな問いに明確な答えを持てるようになる。

この3ステップでプログラムは磨き上げられていく。

実は、ビジネスも人間もこの3ステップが最も効率が良い。

ある目標を仮で決めて、急いで動き出す。

何らかの反応が発生する。

その反応に対応しようとするが、それは、最初の目標に隠れていたマイナス面をあぶり出す。

あぶり出されたマイナス面を何とかしつつ、当初の目標も達成しようとする。

ちょっと弁証法的なこのプロセスが大事。

このステップを踏めば、既存の環境に「馴染む」ことができる。

つまりどれだけ早くスタートし、どれだけ早く失敗するか、が重要になってくる。

タイムリミットが過ぎてから失敗したら、取り返せないから。

子供の頃から、目の前の目標をガツガツクリアして、失敗していくことがものすごいアドバンテージになることが、この定理からわかるんじゃないかな。

じゃ、次の定理は「効率より移植性」ね。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学