via IMG_0905 on Flickr – Photo Sharing!

今から7、8年前のベンチャーブームくらいの頃は、ベンチャーキャピタルから入ったお金をハードウェアにも潤沢にまわしている企業が多かったと思います。ハウジングでサーバを構える場合、複数台のサーバはもちろん、ロードバランサやSSLアクセラレータ、ルータなど様々なハードウェアを購入する必要がありました。

それから数年経って見返してみると、ハードウェアの進化は目覚ましいものでした。数年前に最高だと思ったパーツは陳腐化し、それよりも高性能なものが格安で手に入るようになっていました。DellやHPの台頭も大きかったように思います。

その頃のことを思うと、ハードウェアを購入するという選択はあまり良くないように思えます。技術の進歩は凄まじく、数年後がどうなっているのか分かりません。そうした中でハードウェア資産を無下に増やすのは得策ではありません。

では次にどういった選択があるでしょうか。

リースという選択肢もあります。小規模なベンチャーで、まとまったお金はなくとも、立派な機器を揃えられる可能性があります。ですが、これも先と同様の理由であまりお勧めできません。途中で止めることもままならず、陳腐化していくハードウェアに対して、当初の高い金額を支払い続ける必要があるからです。

そこで考えてみたいのがホスティングやVPSの類のサービスです。VPSは海外のものであれば相当格安で提供されるようになっています。また、日本でも数万円/月から提供されるものも少なくありません。

ハードウェアのスペックも上がってきています。セットアップ、ハードウェアのサポート、障害対応の要員等も考えると、それらを全てアウトソースしたと考えても悪いものではないと思います。

他にもAmazon EC2/S3を利用するという選択肢もあります。SSHは日本からでは若干遅めですが、OSの幅広い選択肢、セットアップの容易さ、堅牢性等を考えると個人的にはお勧めの選択肢です。他の専用サーバなどのサービスと異なり、初期費用がないのも利点です。

サーバ（インスタンス）を停止するとデータが消失するということがあるので、その運用には別な注意点が必要ですが、慣れてしまえば問題ありません。必要になったら即座にサーバを追加することもできます。

Webサービスではニーズやウォンツに合わせ、日々変化していくことが求められます。ハードウェアも同様に変化に柔軟になれる選択肢を考えるべきです。

via variation on Flickr – Photo Sharing!

先日、やらないことリスト（Not todo）が流行りました。やらなくとも良いもの、やらないことをリストアップすることで、逆にすべきことを明確にする効果があります。

同様に、Webサービスにおける消せるものリスト（Not need）を考えてみます。

今、開発しているサービスがあるのですが、こんな機能、あんな機能と考えているうちに入力項目が増えてしまいました。同様に会員登録フォームやアンケートなどでも、やたら入力項目が多いサービスもあるかと思います。ああいうものを見ると、入力する気さえ失せてしまいます。

そこで、現在の入力項目から消せるものを考えてみましょう。例えば氏名が分かれて入力できるようになっている場合。これは本当に分かれている必要があるのでしょうか。ただの印字上の問題や、何となく分かれていると後でデータ抽出ができるかも、なんて理由からだけではないでしょうか。さらに言えば、名字でサマリーして抽出、なんて行うわけもありません。

同様に住所もあります。都道府県別で抽出して何が起こるというのでしょうか。大抵、殆ど利用されないマーケティング待ちのデータです。これらのデータを全て一つのテキストボックスないしテキストエリアにしてしまえば、ずいぶんすっきりします。

男女や年齢、メールアドレスの2回入力、ユーザIDなども同様です。そもそもユーザ登録自体必要なのか考えた方が良いでしょう。相手の利便性、と言いながら実は自社のためになっている場合がたいていです。むしろそのユーザ登録のせいでユーザを逃がしていることのが多いのですが。

Googleが初期段階において支持されたのは、やはりテキストボックス一つのインタフェースと言うシンプルさです。シンプルであるということは、余計な説明を必要とせず、ユーザを混乱させることもストレスを与えることもありません。便利さを考えて作ったその機能が、本当に便利なのか（だと思い込んでいるだけでないか）、考えてみてください。

via I Know Who Dies! on Flickr – Photo Sharing!

が、ここで逆説的に考えてみます。あえて表示しておくメリットです。そして、個人的には予め表示しておく方が良いのではないかと思っています。

その理由は以下より。

Webというのは能動的なメディアです。ユーザが何らかの操作を行うことで、システムが変化します。ユーザがアクションを起こさない限り、何も起こりません。さらに、ユーザというのは意外なほど、情報を受け取っていないものです。

なので、一度何もない状態を見せてしまうと、次に機能を見せても分かってもらえない（そもそも見えていない）ことが多々あります。むしろクリックさせてログイン画面を表示して、「この機能を使うにはログインが必要なのか」と分からせる方が大事です。

また、画面遷移を起こすのがいやであれば、Ajaxを使って機能させれば良いことです。そうすれば「この機能にはログインが必要です」と表示して完了します。ユーザも理解しやすく、機能も把握してもらえます。

もう一つのメリットとしてキャッシュがあります。ログイン前と後で画面を変更すると、キャッシュが二つ必要になってしまいます。が、同じ画面で提供できれば一つで済みます。システム的にもシンプルになり、各機能できちんとログイン状態を確認することが必須になるので、ログイン状態で表示したもののセッションが切れてしまい、未ログイン状態で実行されてバグった、なんて自体もなくなります。

能動的メディアで、かつ口頭での説明もできないWebの世界にあっては、あえて見せてしまうことによるメリットの方が大きいのではないでしょうか。

via Share This Icon Concept #1 With Peers on Flickr – Photo Sharing!

コンセプトは端的で分かりやすく、誰でも理解できるものが理想です。後付けで決めたり、変化していくといい結果に結びつきません。

大抵、こうしたことは誰でも理解してくれるのですが、実際のプロジェクトでは明言されることはあまりありません。何となく雰囲気で伝わるだろう的な感覚だけで共有されてしまっています。熟したプロジェクトではそのような形でも良いのですが、新しいサービスを立ち上げようとする中ではお勧めできません。コンセプトは明言すべきです。そうしないとどういう基準で、誰をターゲットにサービスを開発すれば良いのか曖昧になってしまいます。

ではどういったことをコンセプトにすれば良いのでしょうか。

Wikipediaによると、コンセプトとは「物事の総括的・概括的な意味のこと」とあります。つまり○○というサービスは××です、と言い切れるくらいのものがベストです。ここで危険なのは、曖昧な表現はできるだけ避けることです。曖昧な表現は受け手によって感じ方が異なる可能性があり、意見が相反したりしやすくなります。また、「誰でも」「どこでも」「いつでも」といったような包括的な表現も避けた方が無難です。これはターゲット層が曖昧になる、主な活動時間帯が明確でない、状況が思い浮かべづらいといった問題があります。

逆に言えば、これらが明確になるようなものが良いコンセプトです。例えば「20代女性に新しい食事法を提案する」「OpenIDを普及させる」「健康法を皆で共有する」などと言った具合です。個人的にはサービスのアイコン化を目指すのが良いコンセプトだと思っています。それを見ただけで何なのか分かるくらい簡単なものです。

もしこの軸から外れる機能を考えたならば、それは別サイトにしてしまうくらいが良いのではないかと思います。そうしないと、サービスの履歴を知っている内部の人であればまだしも、新しく追加された機能がある状態ではじめてみたユーザには何のサイトなのか分からなくなってしまうからです。端的で分かりやすく、かつ類似サイトとの違いが分かるようなコンセプトを考えてみてください。

via IMG_6879.jpg on Flickr – Photo Sharing!

ということで、サービスを開発する際にネーミングセンスというのは非常に重要です。ネーミングセンスだけでサービスが流行るかどうかが決まると言っても過言ではないくらい。Webサービスはすぐに模倣できるので、同じようなサービスが二つあった時に、初見での面白そうな感じ、サービスの流行度、そしてネーミングは重要な要素です。

では日本語圏向けにサービスを提供する場合のネーミングはどのようにするべきでしょうか。

• 分かりやすい、そして覚えやすい
• ひらがなで書ける。横文字は使わない（使ったとしても中学生レベルの英単語のみ）
• 略せる。または別名が考えつく

などが大事かと思います。もちろんこれはターゲットユーザ層によっても変わります。アクティブシニアを対象に老とか、健康とかそういったイメージを与える言葉は危険です。むしろ旅行、遊び、海、太陽などの言葉を連想できる物の方が良いでしょう。

格好いいイメージを、なんて理由で横文字を並べるケースが多いですが、それは罠にもなります。ユーザにとって必要なのは安心感です。心にすっと入ってくるサービスほど好まれるというのを忘れないでください。

via Blue Keyboard on Flickr – Photo Sharing!

日本ではまだまだ囲い込みの意識が強く（囲い込みになっているかどうかは別として）、サービスを外部から変更できることに対する抵抗が少なくありません。そのため、データを外部に公開する＝Web APIであるという意識が根底にあります。これはWeb APIの第一人者でもあるAmazonやGoogleの初期段階におけるWeb APIが内部データの外部公開にあったからということもあります。

が、本来のWeb APIとはアプリケーションインタフェースのことであり、I/Oを決めたものではありません。また、最近の海外で見られるWebサービスはサービスのローンチと同時にWeb APIを公開し、さらに出力のみならず入力もWeb API経由で行っています。

これがどういった競争力を生み出すかというと、入力インタフェースを公開することで、サービス提供企業が考えているよりももっと手軽で便利なインタフェースがマッシュアップによって開発される可能性があります。が、それは全く問題ではありません。内部データの増大はコンテンツの増大を意味しますので、さらにユーザを引きつける原動力になります。その意味では、出力系のWeb APIよりも、入力系のWeb APIに力を入れるべきです。

入力系のWeb APIは、CGM系のサイトで特に威力を発揮します。Twitter、動画投稿サイト、ブログ、ブックマーク、写真共有などなど、Web2.0系と呼ばれるサイトでは大抵、入力系のWeb APIを提供しています。が、日本ではあまり見られません。

CGMは、コンテンツを集めてそれで集客、広告で稼ぐというモデルで考えるとこうした形式になりやすいようです。コンテンツをユーザから集うことでコストを下げようと言うのであれば、全くの失敗例です。むしろコンテンツを集めやすい、ユーザが投稿しやすいインタフェースを提供し続けることで、コンテンツの拡充のはかり、結果として集客効果を得られると考える方が自然です。

そのためにはサービス単体で全ての機能を提供するのではなく、Web APIを通じたデータを収集を考えてみてほしいと思います。

via Skype Reverie on Flickr – Photo Sharing!

これまで経験してきたプロジェクトでは、どちらかと言えば外部のリソースを使って最善の結果を得られたことの方が少ないように思えます。最も大きな原因は「プロジェクト」における両者のスコープの違いです。

外部のリソースにとってのプロジェクト管理とは、言わばプロダクト管理の範囲に収まります。つまり、開発して納品、検収をうけるまでがプロジェクト管理です。逆に内部の人にとってのプロジェクト管理とは、システムを実際に動かし、収益を黒字化することがプロジェクトになります。

外部のリソースにとってのゴールは、内部のリソースにとってみればスタートでしかありません。システムは箱であり、実際にそれを使わないと意味がないのです。その点の認識のずれが、プロジェクトの後半になるにつれてどんどん大きくなっていき、それが悪い結果につながることが多いです。

金額が大きくなればこのずれは埋められることもあるのですが、1,000〜5,000万円くらいの開発規模ですとずれの修正にかかるコストが大きく、どちらがそれを吸収するのかで外部と内部で軋轢を生みやすくなります。

Webの開発の場合、良きにせよ悪しきにせよ仕様の変更というのが良くおこります。数百億円のプロジェクトにおける数百万円の仕様変更と、1,000万円の規模における数百万円分の仕様変更ではうけるインパクトが大きく変わってきます。そして外部のリソースにおいては検収が第一になるので、とにかくはじめに決めた仕様でまずは検収をうけることが優先され、第一段階での仕様策定時からの市場の変化、状況の変化を見ないようになりがちです。

当たり前ですが、その結果作られたものは実際の運用にはあっておらず、使えない代物になります。内部の満足度も低く、お互いにとって嬉しくない結果に終わってしまうことが大抵です。

そういった事情をふまえると、個人的にはプロトタイプの作成は内部リソースで行うべきだと考えています。または柔軟に対応してもらえる外部リソースを求めるべきでしょう。そしてしばらく運用を積み重ねていった結果、見えてきた機能要件をまとめてから外部リソースを頼るべきだと思います。

とは言え、そうそう単純にいかないケースも多いとは思います。次回はそうした事情をふまえつつ、外部リソースの上手な使い方を考えてみたいと思います。