業務系チャットサービス『co-meeting』が「JavaとRailsの二層構造」を採用したワケ
チームの"今"をリアルタイムに共有するコラボレーションツールとして、2012年4月に正式リリースされたライブテキストサービス。
最大の特徴が、一文字単位でリアルタイムにテキストを伝達するライブタイピングチャットだ。オンライン上でつながっている仲間と話し合いをしたければ、それぞれが『co-meeting』上でめいめいの考えをテキストとして打ち込んでいけば良い。
打ち込まれたすべてのテキストは、そのまま『co-meeting』上に反映・保存され、リアルな会議さながらの"話し合い"の場が作られる。
すべての会話は階層型のスレッドにより構成され、複数議論の同時に進めることができる。「いいね」、「イマイチ」、「疑問」、「Todo」、「脱線」といったアイコンも用意されているため、後で複数の議論を体系的にまとめ見ることも可能だ。
議事録作成はメンバー全員で同時に行えるため、従来のリアルな会議の議事録よりもメンバー間の齟齬はない。まさに「今までの会議を超えた会議」を、『co-meeting』は実現しようとしている。
『co-meeting』開発の直接的なきっかけとなったのは、co-meetingの2人が起業準備中に感じたというストレスだ。
「仲間と起業準備に入り、どんな新しいサービスを立ち上げるか議論していた時、グループでディスカッションをしたくても、時間的、地理的な制約で会うのが難しいことが多々ありました。そんな場合、メーリングリストやメッセンジャー、『Skype』や『Yammer』といったツールを利用していたんです。しかし、どれも使いづらい上、長時間に渡って複数の問題について複数の関係者が議論していると、引用だらけで時間軸や意見がぐちゃぐちゃになってしまったりすることがよくあったんです」（木村篤彦氏）
2012年4月、米Lifehackerに『Google Wave』後を担うサービスとして取り上げられた『co-meeting』。海外ユーザーが増えた
そんな現状を変えたいと思い、始まった『co-meeting』の開発。当時、Googleが提供していた『Google Wave』が2012年4月末でサービス終了することになっていたことも、『co-meeting』開発の後押しとなった。
「ご存知の方も多いと思いますが、『co-meeting』の機能のキモである一文字単位のライブタイピングチャットは、『Google Wave』がすでに実現していました。ただ、利用者が増えないという理由で、Googleは2010年の8月時点で開発を中止を発表。それなら僕らでより良いサービスを作ってやろうと考えたんです」（吉田雄哉氏）
一般的にWebサービスは、一つのプログラミング言語で書かれる。しかし、『co-meeting』は2つの言語から成り立つ二層構造だという。なぜ、このような変則的な開発手法を採用したのか。
開発言語だけでなく、クラウドサーバに関してもNifty CloudとAmazonの"二刀使い"だ
「『co-meeting』の根幹を担う、ライブタイプチャットのためのエンジンを開発する上で、選択肢は3つありました。1つ目が、『Google Wave』の開発が打ち切られた後、オープンソースという形で存続していたApache Waveを利用する方法。2つ目が、Apache Wave同様、リアルタイムに共同編集できるテキストエディタとして公開されていたEtherPadを利用する方法。最後に、ゼロからスクラッチで開発する方法です」（木村氏）
どの方法が『co-meeting』の開発に最適だったかが分からなかったため、「とりあえず、それぞれの方法である程度まで作りました。あれが一番憔悴した時期でしたね（笑）」と笑う吉田氏。
それぞれに一長一短あったものの、ライブタイプチャットの面に関しては、Apache Waveが他よりも一歩先んじていたため、Apache Waveを採用することになった。
「Apache WaveはJavaで書かれているので、ライブタイプチャット部分はJavaで開発を行いました。一方、ミーティングのメタ情報の管理やログイン機能といった、管理系はRuby on Railsで書かれています」（吉田氏）
2つの言語による二層構造と聞くと、両者を連携させるのが大変なイメージがあるかもしれない。しかし、実際は特に大きな問題が発生することもなく、むしろ効率的だった。
その理由は、エンジン部分の開発をする時の要件と、ユーザー管理機能の開発における要件はだいぶ違っていたから。
「例えばユーザーを管理したい場所と、テキストを入力するところの画面の作り方一つとってもまったく違う。そういった要件定義がしっかり分けられていて、かつ書いている言語も違うので、 『片方の機能だけを強化させる』なんてことが比較的簡単にできるんです」（吉田氏）
『Google Wave』は機能オリエンテッドゆえ使いにくかった
サービスのキモとなる機能が共通する『co-meeting』と『Google Wave』だが、『Google Wave』がユーザー数の増加に伸び悩み、開発が終了してしまったのは前述の通り。同様の事態に陥らないための勝算が、『co-meeting』にはあったのか？
「多機能であること＝使いやすい、ではない。むしろユーザーに行動を迷わせてしまう可能性が大きい」（木村氏）
「『Google Wave』は良くも悪くも『何でもできてしまう』サービスでした。テンプレートをはじめ、多種多様のアドオンやプラグインが用意されていて、いろんなことをできる基盤であるということはよく分かったんですが、裏を返せば、『何に使うサービスなのか』がよく分からなかったんです」（木村氏）
そこで、『co-meeting』はライブタイプチャットというコア機能を軸に、「何に使うサービスなのか」をまず明らかにした。
そこで出てきたキーワードが「会議」だった。
「オンライン上で会議ができるライブタイプチャットサービス」といえば、必要な機能のアイデアはおのずと湧いてくる。普段の会議での行動を思い浮かべ、それを実現する機能を盛り込めば良いからだ。しかも、最初に「会議」という場面を設定しているため、ユーザーに使い方を迷わせかねない余分な機能が付くこともない。
「だから、『co-meeting』の機能はすごくシンプルなんですよ。コアだけで言えば、一文字一文字反映されていくリアルタイム系機能と、話が混ざらないようにするマネジメント系機能の2つだけです」（木村氏）
「ユーザーへの説明もしやすいですしね。『会議』っていうキーワードが一つあるだけで、人は『何人かの人たちが机を囲んで、議論していて......』といったイメージをふくらませることができる。同じことがオンライン上でできるのが『co-meeting』ですよ、と言えば、細かい機能の説明などなくても、全員がだいたい同じものを思い浮かべてくれるわけです」（吉田氏）
『Google Wave』が機能オリエンテッドなサービスだったとすれば、『co-meeting』はユーザー・エクスペリエンス（UX）オリエンテッドなサービスだといえる。それこそが同サービスの強みであり、『Google Wave』との最大の違いなのだ。
自らの強みを突き詰め、BtoB向けサービスに照準を絞った
『co-meeting』のスターティングメンバーには、一つ大きな強みがあったという。それが、「エンタープライズ畑出身」ということだ。
Public Cloud Evangelistとしても有名な吉田氏だが、開発当初は「何から始めるべきか分からなかった」と話す
起業を決意した当初こそ、パーソナルブランディングのプラットフォームや、電子書籍関連の事業を考えたりもした。
しかし、結局は「その業界に詳しくなかったので、何から始めればいいのかがよく分からなかった」（吉田氏）ため、早々に自分たちの強みを活かすことができる方向で事業を考えることに。
この判断が功を奏した。
「昨年（2011年）は多く立ち上がったWebサービスのほとんどがBtoCサービスでした。一方、僕らはエンタープライズの世界しか知らない。だからBtoBサービスを作ったわけですが、今思えば、エンタープライズの世界を知っているというのは大きな強みなんですよ」（木村氏）
エンタープライズ畑で大規模システムの構築に携わっていたからこそ、ビジネスの現場でどのようなサービスが求められているのか、『co-meeting』を導入しようとしている企業はどのようなフローを経て決済を取るのか、企業がどういったところを見てサービス導入の可否を判断するのか、などが手に取るように分かる。
「学生でスタートアップを起業した人には、企業の行動原理なんて知りません。それを僕たちは知っている。だから、企業を相手にしても攻めることができるんですよ。例えばプランニング一つとっても、どういう時期に予算申請があって、それを踏まえてどう行動すべきかっていうようなことが分かっている。この差って大きいと思うんですよ」（吉田氏）
2012年9月4日には、SSL対応やエクスポート機能などを強化したビジネスユーザー向けの有償プランの提供を開始し、マネタイズとサービス拡大の大きな一歩を踏み出した『co-meeting』。「会議と言えばPC上でやるもの」という認識が当たり前になる日も近いかもしれない。
取材・構成／桜井祐（東京ピストル） 文／くわ山ともゆき（東京ピストル） 撮影／竹井俊晴
関連リンク
