クラウドと"Fail Fast"について

ちょっと前のエントリーで"Cloud Computing by Example"の表を作ってコメントを求めました。で、コメントをいただいたのに全然フォローしてませんでした。また、先日行なったグリッド協議会のワークショップでも質問をメールでいただいていたにもかかわらず答えていないという状況です。どうもすみません。と言うことで、ここでまとめて回答します。

まず、表にある"Fail Often, Fail Quick, Fail Cheap"の説明ですが、これは失敗した時に迅速に撤退できることを意味します。無理に失敗しろというわけではなく、失敗を許容せよ、ただし、失敗するなら迅速にかつあまりコストをかけるなという思想です。不確実性が高い環境においては、すべてのことが成功するとは限らない、かと言って絶対成功するように計画に時間をかけ過ぎていては機を逸してしまう。とりあえずやってみてダメだったらすぐやめて方向転換しましょうということです。"Faiｌ Fast"と言われることもあります。

以前、『イノベーションへの解　実践編』関連のエントリーで紹介した「創発的戦略」（emergent strategy）も同じような考え方です。

"Faiｌ Fast"の反対は「失敗が明らかになっているのにプロジェクトがずるずると続き、傷を深めている状態」、あるいは、「そもそも明らかに失敗なのに当事者だけが気がついていない状態」といえるでしょう。

先日のDreamforceイベントでもeBayやNetflixなどの成功したネット企業の担当者が社是として”Fail Fast”を挙げていました。

そして、クラウド・コンピューティングにおいて”Fail Fast”なビジネスをサポートできることは重要です。具体的には、コンピューティング資源が不要になった時に迅速かつ安価に規模縮小あるいは撤退ができるということです。

先日のエントリーでブロガー・アナリストのJames　Govenor氏の

>If you can’t deprovision in less than ten minutes… its not a cloud.

という意見を紹介しましたが、これも同じことを言っています。

テクノロジー的には動的な縮小はそれほど難しくないとは思うのですが、サービスの契約体系として最低使用期間などが定められていると”Fail Fast”の障害になるケースもあるかもしれません。

一般にクラウドのメリットとして迅速な規模拡大が挙げられることが多いですが、迅速な規模縮小が議論されることは少ないと思います。まあ、「本ソリューションでは仮にプロジェクトが失敗した場合でも迅速に撤退できます」などとアピールすると「失敗を前提に考えてるのか」と怒る人が出てくるかもしれないのでしょうがないかもしれません。しかし、hidden agendaとしては考えておくべきポイントと思います。

あと、メールで来た質問で「Web as a Chanell」と「Web as a Platform」の意味について聞いてきたものがありました。私が言いたいのはウェブは単なる画面を表示してユーザーからのキーボードから入力を受けるI/Oではなく、APIを公開してアプリケーションを開発したり他システムと統合するプラットフォームでなければいけないということです。ただし、この話は、クラウドが話題になる前からWeb 2.0のミームのひとつとして挙げられていた要素ですから、クラウドの話と無理に結びつける必要はないのかもしれません。