http://www.web-20.net/2007/05/post_54.html
個人でWebサービスを作る時に一番大変なこと
http://labs.unoh.net/2007/03/komagata_1.html
個人でWebサービスを作る時のポイント（＋）
http://dev.chrisryu.com/2007/03/web_3.html
「在庫探偵」をリリースしたばかりですし、特に3番目の記事にインスパイアされたので記事を作成して絡んでみます（笑）。
- クローン戦争には参加しない
- メモでアイディアを洗練する
- todoはテキストファイルで管理する
- 開発を効率化する
- リリースを怖がらない
クローン戦争には参加しない
orcutが流行ればSNS、Flickrが流行れば写真共有サイト、del.icio.usが流行ればソーシャルブックマーク、diggが流行ればソーシャルニュース、YouTubeが流行れば動画共有サイト、twitterが流行れば1行ブログサービス？が大量に作られることからもわかるように、ネットサービス業界はそのイメージに反して、意外と発想力が乏しかったりします。
もちろん、海外で流行っているけれどまだ日本語では使えないといった状態で、できるだけ早くクローニングするという戦略もある程度は効果があるでしょう。しかし、mixiやはてなブックマーク、ニコニコ動画といった成功例が現れるにつれ、多くの企業がこのクローニング戦略を採るようになってきました。数年前なら1年以上あった企業の参入までの期間も、いまでは1〜2ヶ月しかありません。
TechCrunch Japaneseをはじめとした翻訳ブログの増加も、この傾向に拍車をかけています。英語のブログを巡回して面白いアイディアを見つけても、数日後には翻訳されて多くの日本人に知れ渡ってしまいます。それが有望そうなアイディアなら、多くのネットサービス開発者が、クローンサービスの開発を当然検討し始めるでしょう。
さらに、ネットサービスの技術的な要素がコモディティ化するにつれ、技術的な要素以外のコンテンツやデザイン、操作性やプロモーションといった部分のレベルも次第に上がってきました。ブログサービス間の競争も、レベルアップに貢献したはずです。これが結果としてユーザーの期待値も押し上げることになり、きれいなデザインも優れた操作性も今ではすっかり「普通」です。いかにも「技術者が作りました」といった見た目のちょっと使いにくいようなネットサービスでは、よほどの特別なメリットでもない限り、ほとんど使ってもらえないでしょう。
つまり、海外で流行っているネットサービスをできるだけ早くクローニングするという戦略で成功するには、海外で流行し始めた1〜2ヶ月の間に一定以上のクオリティでリリースし、さらに続々と登場する同種のサービスとコンテンツやデザイン、操作性やプロモーションといった部分で勝負をしなければならないということです。おそらく企業として参入しても、小さなベンチャー企業程度では、この競争を勝ち抜くことはできないでしょう。かつてこの戦略が有効だったのは、単にこの分野があまり注目されていなかったからに過ぎないのです。
これを受けて先進的といわれるベンチャー企業の一部は、この戦略に最適化した開発体制を組み上げつつあるように見えます。開発合宿や50%リリースといった手法もそのための方法の1つでしょう。しかも彼らは本業として、それに全力をつぎ込んでいます。ここに本業を別に持ち、片手間で開発するしかない個人が切り込んで行ったとして勝てるでしょうか？リリース速度で勝ったとしてもすぐに追いつかれ、気がつけば「日本発の○○○」と名乗られるのがオチです。プロモーション力がまったくなければ、そもそもその存在さえ知られないまま終わってしまうかもしれません。
メモでアイディアを洗練する
このように、個人でクローン戦争に参加しても、ほとんど勝ち目はありません。空母やイージス艦の参加する現代戦に、矛槍もって傭兵として参加するようなものです。もし、ネットサービスの運営で一定以上の成果を上げたいのならば、なんとしても巻き込まれないようにする必要があるでしょう。つまり、現在注目されているアイディアではなく、注目されていないアイディアで勝負をする必要があるということです。
しかし、注目されていないアイディアということは、つまり、成功の確証のないアイディアということです。むしろ失敗する可能性のほうが高いでしょう。しかも、個人のリソースでは、すべてのアイディアを試してみることはできません。だとすれば、できるだけ多くのアイディアを検討し、少しでも見込みのあるアイディアで勝負するほかありません。
アイディアというのは単なる思い付きのことではなく、目標とそれを達成するための方法の組み合わせです。目標には一発で達成できるものもあれば、さまざまな問題を解決しなければ達成できないものもあります。しかし、一発で達成できるような目標なら、すでに誰かが達成しているはずです。現時点で達成する価値のある「良いアイディア」は、そのほとんどがさまざまな問題を解決する必要のあるアイディアだと思って間違いありません。
そのため、アイディアを形にするには、まず一度煮詰まるところまで考えて、さまざまな問題を浮かび上がらせる必要があります。次に、それぞれの問題を解決する方法を考えるのですが、ある問題を解決することでまた別の問題が立ち上がってくることもあります。それらの問題間を調整し、全体として整合性のあるアイディアにするためには、ある程度時間をおいて、アイディア全体の構造を頭に定着させる必要もあります。そして、それぞれの解決策は、外部から別の刺激によってふっと思いついたりするするものです。しかし、どのような刺激がどの部分の解決策を思いつくきっかけになるのかはわかりません。そのため、部分部分の解決策は、必ずしも順番通りには思い浮かびません。
もし、このときアイディア全体の構造やそれぞれの問題を忘れてしまっていたら、どうなるでしょうか？本当に記憶力のいい人ならわかりませんが、少なくとも自分にはこれらを覚えておく自信はありません。思考経過をメモに残しておかなければ、同じような問題を行ったり来たりするばかりで、いつまでたってもまとめることができないでしょう。
結局、アイディアというものは、プログラムと同じように、少しずつ改善されてゆくものなのです。ある時点では問題点が複数同時に存在し、その解決策は順不同で思いつきます。これを忘れないようにメモに書き加えてゆくことで次第にアイディアが洗練されてゆき、実装のイメージも薄ぼんやりと見えてくるようになります。この段階になってはじめて、単なる思い付きが、試してみる価値のあるアイディア（企画）になるのです。
todoはテキストファイルで管理する
アイディアがある程度固まって、実装のイメージが薄ぼんやりと見えてきたら、いよいよ開発に着手します。ただ、闇雲に作り始めても形にはなりません。まずはテキストファイルを用意して、必要な作業を思いつく限り書き出してゆきます。
このとき注意したいのは、最低限動作するところまでの作業を必ず入れることと作業の粒度を大きくしないことです。
最低限動作するところまでの作業を入れるのは、早い段階で実際に動作をさせながら開発できるようにするためです。プログラム開発においてある機能を本当実装できたかどうか確認するには、その機能を実際に動作させてみるしかありません。実際に動作させるまでは、その実装作業を完了させることができないのです。そして、中途半端に手をつけた完了していない作業が増えてくると、自分がどこまで作業したのかがだんだんわからなくなってきます。こういった事態を避けるためにも、早い段階でプログラムが動作するようにして、作業の完了を確認できるようにする必要があります。実装の完了を確認できれば、その作業のことはすぐに忘れて次の作業に没頭することもできるようになります。
一方、作業の粒度を大きくしないのは、小さな作業に次々と「X」をつけていったほうが気分がいいからです。また、1つの作業に手順の作業が含まれていると、ちょっとした中断で、自分がどこまで作業をしたのかわからなくなったりします。これを避けるためにも1つの作業は少なくとも1日で何とかなるサイズ、できれば数分〜数時間で何とかなるサイズにしておくのが良いでしょう。どうしても大きくなってしまうような場合には作業を分割します。
テキストファイルに作業をある程度書き出したら、今度はコピー＆ペーストで優先度順に並べ替えます。優先度の基準は、最低限動作できるようにするための作業かと、簡単に完了できるかです。たとえば、先日公開した在庫探偵では、HTMLでのページ作りと目撃情報の登録機能の実装をいちばん最初に行なうことにしました。
あとは、このテキストファイルにしたがって、実装を進めてゆくだけです。完了した作業については「X」と日付を書き込んで、上から順番に並べておきます。作業に「X」をつけるたびに、開発の進行を実感することができます。
このテキストファイルには、開発途中で思いついたアイディアや対応すべき不具合なども、随時書き加えてゆきます。それに応じて優先度付けも再検討し、不要になった作業には「△」をつけて完了した作業と同じように日付順に並べてしまいます。テキストファイルをアップデートすることで、開発段階にもアイディアを洗練させてゆくことができるというわけです。
最後に、先日公開した在庫探偵のtodoテキストファイルの内容を一部公開しておきます。
（前略。アイディアメモのコピペ）
X2007/01/17 開発開始
Xuser.html：ひとまずテキストのみで要素出し（見た目は後回し）
Xitem.html：ひとまずテキストのみで要素出し（見た目は後回し）
X01/28 目撃情報の追加
X01/28 ログイン/ログアウト
X01/28 ウオッチリストへの追加
X01/28 ウオッチリストから削除
X01/29 製品グループ別のページ
X01/29 出版社別のページ
ECSで複数の画像が取得できたとき、いちばん最後の画像URLが保存されてしまう（PS3 60GBとか）
パーサーを調整
↑最初の一枚のみ保存するようにした
アイテム情報の追加
（以下略）
開発を効率化する
すでに説明した通り、個人では企業の開発スピードに勝つことはできません。また、一定以上のクオリティを持ったネットサービスを開発するなら、ある程度の時間をかける必要もあるでしょう。
とはいえ、いくらでも時間をかけられるというわけでもありません。成功の確証のないアイディアで勝負をするなら、失敗のリスクもある程度限定しておきたいところです。
そこで行ないたいのが開発の効率化です。開発を効率化し、一定以上のクオリティを一定時間で実現できるようになれば、開発している間にアイディアが陳腐化したり、似たようなアイディアのネットサービスが先に注目を集めてしまうような事態を回避できる可能性も上がります。
開発の効率化のためには、Webアプリケーションのフレームワーク化や機能のライブラリ化、CSSや画像ファイルの流用が効果的です。たとえば、早起き生活や在庫探偵では、認証やテンプレートの読み込みと出力といった基本的な機能を実装した親クラスを作り、それを各スクリプトが継承するようにしています（MVCよりMFCのドキュメントビュー的なイメージ）。こうすることで、固有の処理とHTMLテンプレートを用意するだけで、新しいスクリプトを作成することができるようになっています。ログインやログアウトといった定型的なスクリプトなら、以前に作ったネットサービス用のスクリプトをそのまま流用することもあります。さらに、CSSや画像ファイルを流用すれば、最初からそれなりの見た目にすることも可能です。
おかげで、以前なら数ヶ月かかっていたようなネットサービスの開発が、1ヶ月程度で済むようになりました。その分リリースするネットサービスの数を増やせば、1つ1つの失敗もそれほど気にならなくなります。これは、このあとすぐに説明するリリースに対する恐怖を軽減することにも役立つはずです。
リリースを怖がらない
最後に、リリースすることへの恐怖心を克服する方法について説明しておきましょう。
個人で開発したネットサービスがリリースまでに至らない理由は「モチベーションが続かないからだ」と説明されることが多いようですが、実はもう1つ「リリースが怖い」という理由もあるのではないかと思っています。開発段階での失敗は何度やってもデバッグで取り返すことができるが、リリース後の失敗は取り返せないこともある的な。自分自身「早起き生活」をリリースするまでは、Webアプリケーションのような重いWebサイトをPCサーバ1台で運用できるのかとか、素人がWebアプリケーションなんか公開したら大恥をかくことになるんじゃないかとか、セキュリティが甘すぎて某TKG先生に怒られてしまうんじゃないか（笑）とか、いろいろ心配していたものです。
でも、実際にネットサービスを公開してみると、そのほとんどは杞憂でした。もちろん今でも気になることはいろいろあって、継続的な改良を加えてゆかなければならないとは考えているのですが、それらは公開前に想定していたようなものではなく、解決策もより具体的に考えられるようなタイプの問題です。そもそも、得体の知れない素人の作ったネットサービスなんて、登録者が100人も現れたら上出来でしょう？某TKG先生もいちいちかまってくれません。
むしろ、サーバのチューニングや、ネットサービスのプロモーション、ほかのネットサービスのアクセス規模の予測や成功度の判定など、実際にネットサービスを運営してみたからこそ身についたことの方が多いくらいです。
ただ、それでもリリースの怖さは理解できます。新しいサービスのリリース時には、今でも失敗することへの恐怖がふっと頭をよぎったりすることがあるからです。
そんなときは、実装する機能を絞り込み、できるだけシンプルな形でまとめる作業に入ることにしています。開発規模が大きくなればなるほど、不具合が入り込む可能性が増えますし、整合性を取らなければならない関係も増えます。さらに、できることが多ければ多いほど、何のためのネットサービスかがあいまいになり、企画的にも失敗する可能性が上がります。一方で、機能を絞り込めば、不具合が入り込む余地は減り、ネットサービスのコンセプトも明確になってきます。投入するリソースが減ることで、失敗してもあきらめがつきやくすくなるというのもメリットです。開発量が減れば早くリリースすることもできるでしょう。リリース後に別のネットサービスの開発に移れば、別のアイディアを試してみることもできるはずです。
以上、現時点で自分が考える個人でネットサービスを運営するときのコツをまとめてみました。思った以上に長く＆説教くさくなってしまったような……べつにたいした成功もしてないのにね。でも、文章にしてみたことで、また少し考えがまとまったような気がしました。
最後に忘れずに自分が個人で運営しているネットサービスの宣伝をしつつ、この文章のまとめとたいと思います。
早起き生活
http://www.hayaoki-seikatsu.com/
在庫探偵
http://ztantei.com/
週末クエスト
http://wequests.jp/
artrace - amazon ranking tracer
http://www.artrace.jp/
どれも「そうだよなぁ」と納得するものばかりで、面白く拝見させていただきました。
個人には個人の戦い方がありますよね。
※「早起き生活」の方だったんですね。
自分の知っているサービスの作者からトラックバックしていただいて、とても嬉しいです。
> 個人には個人の戦い方がありますよね。
と思いつつも、開発力競争にロマンを感じちゃったりすることがあったりしますね。どこまで通用するか試してみたい的な（笑）。
でも、最近は、個人といいつつ企業内で開発していることも増えてきているようです。あと、個人サイトのデザインもだんだんきれいになってきているような……開発力だけで勝負するのはますます厳しくなりそうです。
ユニークなアイディアのサービスを次々とリリースされるので感服しています。
ところで、このブログの文字の色はもう少し濃い方が読みやすいと思うのですが、どうでしょうか？
前から気になっていたのですが、今回のエントリーはいつもより長文なので余計にそう思いました。
もしよろしければご検討お願いします。
> ところで、このブログの文字の色はもう少し濃い方が読みやすいと思うのですが、どうでしょうか？
うぉっと！そこですカ！
このブログではSeeSaa組み込みのテンプレートを使っているので、あんまりいじろうという気にならないというか……
SeeSaa発のトラックバックは弾かれることが多いので、ブログもそろそろ自前ドメインに移したいとは思ってます。
興味深く読ませていただきました。
非常に納得のいくないようでした。
「リリースの怖さはシンプルにして出す」
ってところは本当に身にしみますね。
あとTODOでやり終わったものは日付を入れて、
やり終わったリストも見えるようになっているのは、かなり達成感がよさそうですね。
早速やってみようと思いました。
あとMVCとMFCの話ですが、momoseさんは3階層構造ではなく、2階層で実装してるって感じですか？
端的にいうと1View - 1Logicな意味合いかな？
その1Logicの前処理、後処理を親クラスで行わせたりして、共通化できる部分で補完してるというイメージでしょうか。
かなり面白い内容でした。
これからにも期待しています！
> あとMVCとMFCの話ですが、momoseさんは3階層構造ではなく、2階層で実装してるって感じですか？
アバウトそんな感じで、子クラスではonLoad()、onDraw()、onClickに相当するような処理をオーバーライドしてます。
最近の流行からすると少々キモいアーキテクチャですが、機能の追加や変更はしやすいんじゃないかと思ってます。