fat startとか

「small start」の対義語として「fat start」ってのを定義してみる。

404 Blog Not Found:たった一つの冴えたやり方@IT - lingr to stop lingeringのブクマ

で気になったコメントがあった。
Googleもモバゲーも最初は「small start」のはずだし、それは認識不足じゃないかな、と。

エンタープライズが「fat start」になりがちなのは、発注元自体が高い質を要求しているから仕方ない、というのもある一方、SIer側の都合も大きい、だとは思う。
初期開発でどかっと人を投入して、保守フェーズに入れば、人を減らせるだけ減らす逃げ切りパターン。
あとは企業の予算主義もあるよね。
計画的にしか費用投入できないから、局面に合わせて流動的にシステムを変えていくということがなかなかしにくい。

「fat start」のデメリットとして以下の2点。
1. 初期でお金を使いきってしまう為、継続的変更に費用をさけない。
2. 初期の事業計画のハードルが高過ぎる為、現実と乖離しすぎてしまい、事業継続のコンセンサンスがとりにくくなる。

1は分かりやすいのだけど、2のパターンも割と多いよね。
例えば、ユーザ数と連動して収益を上げられるようなモデルの場合、ユーザ数がS字カーブの急勾配に差し掛かる前に、計画未達が甚だしいということで、事業ストップを余儀なくされるとか。

泥縄って言ってもさ

こういうのは、成功例だけをピックアップすれば正しいように見えるけど、実はその後ろに泥棒を逃がしまくっている失敗例が沢山あるようにも思える。成功する秘訣というよりは、失敗しても傷を負いづらいやりかたと言うだけなんではなかろうか。


まぁ確かに不完全なシステムをロンチしてしまった為に最初のインパクトがそのまま後に引き摺るってことはよくあるけどさ。
ただ完全な準備というのもありえないわけで、システム改修の為の反応速度を如何に上げるか?ってところに注力すべきではないのかね。

なんというか、

1. 10人の為に準備したけど、実際には100人もきたラーメン屋
2. 100人の為に準備したけど、実際には10人しかこないラーメン屋

の場合、1は嬉しい失敗で収益もとりあえず達成できるだろうし、その後も改善していけばいいんだけど、2は収益が赤の状態で金をかけなければいけないだろうし、下手すればそのまま店自体が潰れてしまうんだよね。

って書くと、「企業は個人が始めるWebサービスには勝てない」って思われそうだけど、「企業レベルでないと品質の継続を担保できないWebサービス」というのもまたあるわけで、だからまぁそれは別問題。

それから個人的話。
過去に、

2. 初期の事業計画のハードルが高過ぎる為、現実と乖離しすぎてしまい、事業継続のコンセンサンスがとりにくくなる。

でうまくいかなかった事例に制作スタッフとして幾つか立ち会ったことがあるけど、
愛情があればあるほどそれは本当に悔しいし、
「もっと違う形で始めてたらもっと続けられたのではないか?」
とも思ったり。
だから、本当に嫌なんだよね、fat startって。