【増永】 開発しながら、いろいろと問題点も出たのではないでしょうか。
そうなんです。インスタントメッセンジャーはお互いにやりとりが活発になっていくと、文字ベースでは伝わりにくい部分が出てきます。
端的に用件だけを文字で伝えると、逆にあっさりしすぎてあまり印象がよくない。それはちょっとまずいなと思い、お互いにやりとりをしながら癒しも追求できる、そんな方向に持っていくにはどうしたらいいだろうと考えた結果、キャラクターでもつけてみようか、と。非常に安直な発想ではありましたが、改良を考え始めました。
実際に出来上がってリリースしてみると、ダウンロード数も増えて先ほど申し上げたとおり、約10万人の会員をもつ巨大なコミュニティーになったのです。
その後キャラメの成功に伴ない、これをいろいろとビジネス化してみようと動きました。CZ-1プロジェクト（株式会社シーライツ、株式会社ザッパラス、株式会社第一通信社）と提携して、手塚プロダクションさん、講談社さん、秋田書店さんのキャラクターを提供したりしました。
BIGLOBEでもキャラメが利用されていました。当時流行っていたキャラクターがPC上で動いたり、やってみるとけっこう楽しめるんです。
しかし順調に進んだ無料会員の増加は嬉しかったのですが、同時に設備投資に対して収益バランスを上手く保つことが難しい状況となってきたのです。そこで「キャラメのコンシューマー向けビジネス展開は厳しいね」という話になり、企業向けに転換したわけです。
● 10万人の会員をお持ちだったとのことですが、システム的にはどのように対応されていたのですか。
その点で非常に重要だったのが、クライアントサイドのOS状態にあります。当時はOSのバリエーションが豊富で、たとえばwindows98 シリーズだけでもいくつもあったんです。
だから実際にキャラメを使用するクライアントのアプリケーション環境は、統一されていませんでした。よって利用者全員つまりは、すべてのOS環境に対して、常に安定したサービス提供をするという技術は非常に高度なものでした。
あらゆるバージョンのPCを、何台も用いてその場でテスト検証をしていく―それを何度も何度も繰り返して、改善・改良を試みました。
そうした改善の結果、どうにか安定するようになったんですね。そしてさまざまなOS―プラットフォームに対応できるような技術を習得していきました。
また10万人が利用していたので、それらのトランザクションやトラフィックも膨大になります。何千というアクセスが同時に集中するため、サーバーの冗長化をはかるなど負荷集中を回避するような技術―これらをクライアントサイドとサーバーサイドの両方で併せ持つ技術を社内に蓄積していきました。
当時の開発環境では、LAMP（Webアプリケーションのプラットフォームとなるオープンソースソフトウェアの組み合わせ）だけで大規模構成をすることは非常に珍しいケースだったと思います。
2007年3月19日 vol.533 
