そうですね。あと心がけたところとしては、ユーザーに公開するサービスは自社開発でないとうまく行きにくいというところです。契約で縛った形で外部に委託すると、そこがボトルネックになることが多い。ユーザーの使い方に合わせて動的にどんどん変えていくという作り方をしていくことで、より受け入れられる形に軌道修正していくことができました。
「ニコニコ動画(仮)」に関しては、ウェブのフロント部分は(ドワンゴ 第二開発部 ポータル機能開発セクション セクションマネージャーの)鈴木慎之介に主に作業してもらいました。ただ、コードに関しては共同所有で、問題を見つけたら勝手に直しちゃおうということで合意していました。担当者にやってもらうんじゃなくて、自分でやってしまうのが一番早い。競争のような形で作ったところはありますね。
サービスの見え方について、どんどんプロデューサーから要求が降ってくる。それをうまく取捨選択して、簡単にできるタスクをどんどんやるという方針をとっていましたね。時間がかかることは後回しにしていきました。
すぐに結果が見えないものは、リクエストした時点では面白そうだと思っても、その後に状況が変わっていることもあるし、気が変わっていることもあります。時間をかけて大変な作業をして、やっとできたと思ったときにはもう使えない物になっているということがあるので、そういう危険があるものは最初から避けて、すぐに結果が分かるものを選んでどんどん出していく。
たとえば、見せ方をちょっと工夫するとサイトが一気に変わるようなものは、作業に対してコストパフォーマンスがいい。それに対して、裏方の管理系システムは、すごい手間がかかるのに見た目はほとんど分からない。そういうのは、やらなくて済むならやらない。できるだけ、コストパフォーマンスのいいやり方を選ぶ。
「こういうのが欲しい」と言われたときに、ほんのちょっと要求を変えると実装が劇的に楽になるというのはよくあるんですが、そういう話もすぐにしていました。
それから、大前提として、どういうものを目指すかという議論はよくしていたので、考え方が共有されて、こういう方向を目指しているんだったらこう提案されたものでなくても同じ結果が出せると考えて作るということもありました。
プロデューサーも元々ネットの住人なので、開発作業をするときにはネット上でよくやりとりをしていました。「こんなのが欲しい」と言ってきたら、その場ですぐ更新作業をして、「リロードしてみて」と言って見てもらう、という形で24時間体制でやっていましたね。
フィードバックが早いとインスピレーションが持続する。これは、良いものを開発するためにはかなり欠かせない要素になるんですよね。ですので、少なくとも見た目に関しては、思いついたときすぐにそれが見られるように心がけてはいました。ご飯を食べていても連絡が来たらその場ですぐに実装する、ということをリリースまでの間1カ月くらいはやっていました。
その当時、さすがにここまでくるというのはプロデューサー以外は思っていなかったと思うんですけど(笑)。本人は「これはすごい数のユーザーが来る」と力説していて、そのため大人数がアクセスしてもどんどんサーバを増設して対応していけるような基本設計には最初からしていました。それはかなりうまく効いていますね。「ニコニコ動画(β)」の頃に爆発的にユーザーが増えたので、それに応じきれたというのは良かったと思っています。
機能を増やさないこと、少ない機能を維持することが重要だというのがポリシーでした。ユーザー側の行動の選択肢が増えると、『そのどれも選択しない』という選択肢まで増えてしまうんです。ユーザーが逃げるというか、迷ってしまうところがある。誰もが見てすぐに使い方が分かることを目指したので、できることを絞るという点に注意しました。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
ものづくりの革新と社会課題の解決
ニコンが描く「人と機械が共創する社会」
住環境に求められる「安心、安全、快適」
を可視化するための“ものさし”とは?
ZDNET×マイクロソフトが贈る特別企画
今、必要な戦略的セキュリティとガバナンス