Producing Web

ビジネスは100%うまくいくという保証はありません。これはWebに限らず当たり前のことでしょう。うまくいくはず、と信じることは必要ですが、絶対ではありません。そうした不安定な中で、ハードウェアに関してはどう対応すべきでしょう。

via IMG_0905 on Flickr - Photo Sharing!

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

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

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

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

Read the rest of this entry »

via variation on Flickr - Photo Sharing!

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

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

Read the rest of this entry »

例えば未ログイン状態では機能せず、ログインしてはじめて機能するものがあるとします。ブログ記事を編集するためのリンクや、Twitterでフォローするための機能などです。未ログイン状態からそうしたものを見せてしまうと、ユーザを混乱させる可能性があります。なので、ログイン前と後の判断をして、表示/非表示を切り替えているサイトが多いです。

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

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

その理由は以下より。

Read the rest of this entry »

Webサービスにおいてコンセプトは重要です。また、このコンセプトは一番最初に決められるべきものです。全ての作業はコンセプトを軸にして行い、そこから外れないように注意深く決めていく必要があります。

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

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

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

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

Read the rest of this entry »

OpenIDが日本で普及するかどうか。RSSがなぜ普及しないのか。ごく簡単に言えば、どちらも横文字だから普及しないだろうというのが持論です。Blogが流行ったのは、ブログという片仮名表記が三文字で気持ちよかったから。また、日本人特有の略して言うのに「モバイル＋ブログ＝モブログ」というのがちょうど語感が良く、携帯文化ともマッチしたからでしょう。Web Diary → ウェブダとか言っても流行らなかったでしょうね。

via IMG_6879.jpg on Flickr - Photo Sharing!

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

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

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

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

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

日本ではまだまだ少ないのですが、海外ではWeb APIについてもどんどん双方向性が進んでいます。フィードを配信する、独自のXMLやJSONでデータを受け取れるようにするだけではなく、データを登録、更新、削除するのもWeb APIから可能になっています。

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に力を入れるべきです。

Read the rest of this entry »

Webサービスを新しく構築する際に、外部のリソース（SIerなど）と内部のリソースを使うのとどちらが良いのでしょうか。

via Skype Reverie on Flickr - Photo Sharing!

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

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

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

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

Read the rest of this entry »