第3回『オープンソースと開発手法』『今後のCGMビジネスの行方と関連技術』
第3回のセミナーの様子をここでご紹介いたします。
以下セミナーのレポートとなります。
2月10日(土)に開催された第3回WAZA CTOセミナーの内容をまとめてアップさせて頂きます。
第3回WAZA CTOセミナー
2月10日に「第3回WAZA CTOセミナー」が開催され、インターネット関連企業のCTOの方々を中心に50名近くの方々に参加して頂いた。講師は今回、以下の方々にして頂いた。
『オープンソースと開発手法』
牧 大輔 有限会社endeworks 代表取締役
土井英範 コミュニティエンジン株式会社 リリースセクション チーフエンジニア
中嶋謙互 コミュニティエンジン株式会社 代表取締役
『今後のCGMビジネスの行方と関連技術』
猪子寿之 チームラボ株式会社 代表取締役
小川敏一 株式会社アイスタイル システム企画部 部長
貝畑政徳 面白法人カヤック 最高技術責任者
山田進太郎 ウノウ株式会社 代表取締役
目次
セミナー内容は長文となるため、ここではインデックスのみ紹介させて頂き、各詳細に関しては、タイトルをご参照の上、各々の記事をご覧頂ければ幸いです。
前半部：講演 ～オープンソースと開発手法～
会社におけるオープンソース開発の提案（endeworks牧氏）
コミュニティエンジンにおける開発体制1（コミュニティエンジン土井氏）
コミュニティエンジンにおける開発体制2 （コミュニティエンジン中嶋氏）
後半部：パネルディスカッション ～今後のCGMビジネスの行方と関連技術～
各社CGMビジネスの紹介
CGM発信側とWATCH側
CGMサイト設計時のスタンス
欧米と日本のCGMの違い
盛り上がるCGMサイトの条件
講師が普段利用しているCGMサイト
最近気になるCGMの分野
気になる関連技術
CGMサイト企画時のプロセス
PCとモバイルのコンバート
企画時にCGMを意識しているか
高速なリアルタイムサービスができるとしたら……
CGM投稿促進の方法
前半部：会社におけるオープンソース開発の提案（endeworks牧氏）
perlの世界でクローラーのプログラミングや、バインディングなどを行っております。今回は技術的な話はあまりしません。哲学・コミュニティが全体としてオープンソース。一般的にビジネス的な話が多いが、お金・作業効率・TCOなどは重要ではあるが、あまり好みのネタではない。仕事場でオープンソースに参加しやすい環境を今回は提言したい。それによって技術力の底上げにつながる。社内からまわってくる仕事は受身になりがち。それはしょうがない面もあるし、自己保身という面がある。確立した技術を使って保険をかけがち。こんなことばかりしているとスキルがなかなか上がらない。研修も一般的な内容が多い。じゃあ、どうするかというと、僕は技術者＝職人だと捉えている。エンジニア＝職人と捉えたときに、職人の技は授業で教わるのではなく、修行して覚えるものである。だからこそ会社で修行しやすい環境を作ることが大事。僕は会社でオープンソースに参加することを奨励している。
もともと自分はずぶの素人。ものづくりはしたいと考えていた。父が理系の大学にしかお金を出してくれなかった。不真面目なので、落第したりしていた。オープンソースの世界でいろいろやってきて、エンジニアとして食べていけるようになったので、オープンソースの効果はあるはず。会社ではQA部隊でテストをするためのツールを作っていた。自分でモジュールを書かなければならず、ウェブで検索していたら、cpanに出会った。パールで書いたモジュールを配布するための仕組みで、便利だ。これらを使って開発していた。時々バグもあるし、問題ある。時々は実装が気に入らなかったりする。開発者に直接連絡して、文句を言っても「俺はやる気ないけどやる気あるならどうぞ」といわれる。しょうがないから、自分でやり始めた。これが私のオープンソースとの出会いです。
当時いた会社では寛容で、必要ならどうぞと言ってくれた。初めてパッチを作って、XMLを処理するライブラリ用のエンコーディング修正パッチを作った。何も分からなかったが、パッチの作り方から聞いて始めた。皆意外と親切に教えてくれた。オープンソースは敷居の高いとこだと思っていたが、大した志がなくてもできると思った。それからソースコードを見るようになった。深みにはまっていった。作り方がだんだんわかってきて、一からやってみようと思い始めた。perlの日付計算のライブラリに参加。今日の日付はマヤ暦でいうと何日なのかなどを計算するモジュラーだった。和暦は誰も実装してなくて、自分がやることになった。日本の旧暦は天文学が必須。太陽の緯度や月の緯度なども使用しないといけない。MLで天文学について質問して、本を紹介してもらったりした。とにかくその本を読んで、勉強しネットでも情報収集した。そして、MLでディスカッションを繰り返した。そして、コミュニティに検証を手伝ってもらった。フィードバックを受けて、バグを潰しての繰り返し。これは仕事の合間に２ヶ月で作った。自分が触れることがなかっただろう天文学に触れられてためになった。縁でその他のプロジェクトにも関わっていった。すごい意気込みがなくても縁でオープンソースには関わっていけた。報酬はなかったが、仕事に１００％還元できたと思っている。純粋に技術力はあがった。そのためには優れたエンジニアのソースコードを手本にして、MLでのフィードバックでソースコードの書き方を教わった。任意精度計算（天文学で）もできた。Cの勉強もできた。ソースコード管理を試せたのは、今コードを管理する側になって、良かったと思っている。
オープンソースの学んだことはソーシャルスキル。見知らぬ人と一緒に開発することになるのでオープンソースでは対人スキルが重要である。どんなに優れたアイディアでも営業力がないと駄目。自分が何をしたくて、皆にどんなメリットがあるのかを説明しなければいけない。オープンソースのエンジニアは基本的にはみんなパートタイマーだから、だれかが率先しないと停まっちゃう。リーダーシップが重要。一癖もふた癖もある人と渡り合えるようになる。コードできる人に限って、皆開発についてこだわり持っている。そういう人たちとうまくやってはじめて成功できる。
これらの経験を通して、悪い例もたくさん目の当たりに出来る。会社の中だと悪いコードだと言えなかったりするが、オープンソースでは癖のある人がはっきりとコードの悪さを指摘してくれるので、どこが悪いのかがすぐ分かる。オープンソース参加で学べることは、技術力は前提として総合的なスキルが学べる。だからこそ、とってもよい修行の場である。また、オープンソースは失敗してもいい開発でもある。試行錯誤して行き詰ってもOKなのである。社会還元もできて、うまい構造になっている。万人にできるかというと、できないかもしれないが、部署で奨励はするべきである。会社としてプラスになる。雇用する側の人はオープンソースの特性を理解して、しやすい環境を作ってあげるべきである。１，２時間オープンソースの時間を与えるべき。そこで環境や著作権などでちょっと逃げ道をつくってあげるべき。結局はwin-winになる。是非参加してみてください。雇用している人はオープンソースに参加させてあげてください。
質疑応答
Q.endeworksではオープンソース奨励にどんなルールがあるか？
A.使うものを制限していないので、使えるものはどんどん使ってください。ということで奨励している。
Q.特許はどう扱うべき？
A.難しい問題ですね。会社として基本ソースコードは会社のもので、合意のもとで、リリースしていくという形が現実的。一旦、審査をするところを設けておけばいい。そういうプロセスでリリースしたコードもあるが、オープンソースは汎用性の高い部分なので、著作権に関連するような部分はリリースされないので、現実的にはそれほど問題ない。
Q.ときめきメモリアルでGPLのコードを逆にコピペする問題などあったが、権利で他に気をつけるべきこと？
A.権利に関しては、エンジニアの性格によるが、僕のチームは全てのコミットをみているので管理できる。大企業に関しては正直考えていない。
Q.オープンソースの開発は遠くから見ている立場だが、オープンソースに入るのにこんなことからしたらいいというアドバイスはありますか？
A.メーリングリストを眺めているのが一番いい。関わる製品でプレーヤーの性格違っている。例えば、一人カリスマ的なプログラマーがいる場合や、明確なプロセスがある場合など。
Q.perl周辺だとどういう技術や人が必要か？
A.perlの新バージョンのところに人が必要。10年近く開発されているのに、なかなか出てこないので新しいものつくりたい人にはおすすめ。言語の規格から仕様の実装まで一通りできるので。しばらくメーリスを見てどういう人がいるか把握して、次にソースコードの取得方法も出てくるので、それを眺めていくと流れが分かるので頃合を見て自分も参加していけばいいのではないか。
Q.得意分野PHPとあるがパール以外のオープンソースコミュニティには参加しないのか？
A.昔はJAVAでブラウザを作ろうというプロジェクトがあったが、途中で頓挫してしまった。さっき話したXMLの処理ライブラリももともとはCで出来ているライブラリの上にPerlがあったので、その辺りには手を加えたことがある。ただ、基本的にはパール周りが多い。
Q.最初にXMLパッチを作ったとき、同じ会社でオープンソースに携わっている人多数いたのか？
A.ほとんどいなかった。いても両手で数えられるくらい。
Q.その際にオープンソースで開発していくことに関して会社側からの抵抗なかった？
A.テスト部分だったこともあって、抵抗はなかった。テストできればそれでいいというスタンスだった。半分くらいできていたテスト用のフレームワークがPerlで書かれていたので、そのまま続けられた。
Q.オープンソースにコミットして成長できるという部分と参加には資質が必要に矛盾を感じるのですが？
A.プログラマーには変わり者が多く、中には他人とはやっていくのが面倒くさい人も多いので、それを考えた上での資質ということです。また職業プログラマーでやりたくてやっているわけではない人もいるので、できればやってくださいということ。少し興味あれば、そんなに壁はないので見てくださいという主旨です。
前半部：コミュニティエンジンにおける開発体制1（コミュニティエンジン土井氏）
弊社のシステム作りについて話します。オープンソースで優秀なものはコミュニティがしっかりできていると思う。今回は会社としてそのコミュニティ形成をどうやっていくかをコミュニティエンジンの実例を基に話していきたい。流れとしては以下の3点。
・開発プロセス上の問題を解決する方法としてジョエルテストの紹介。
・コミュニティエンジンについて
・開発プロセス改善でおこなってきたこと。
・開発プロセス上の問題を解決する方法としてジョエルテストの紹介
ジョエルテストという簡単なテスト。開発環境をチェックする12項目のクオリティチェックリストを紹介します。
○がいくつかチェックしてみてください。
・ソース管理をしているか。
・ワンステップでビルドができるか。
・デイリービルドしているか。
・バグデータベースがあるか。バクの発見と解決などをデータベース化しているか。
・新しいコードを書く前にバグ直しているか。
・アップデートされているスケジュールあるか。スケジュールを立ててから動いているか
・仕様書あるか。
・プログラマーは静かな環境で作業しているか。
・手に入る最高のツールを使っているか。
・テスターはいるか。QAの品質保証の作業を行うスタッフがいるか。
・採用面接でコードを書かせているか。
・ユーザビリティーテストをしているか。
コミュニティエンジンでは昨年1月時点では6点だった
ジョエルテストによると１０点以下は深刻な問題。コミュニティエンジンは去年まずい状態でした。
コミュニティエンジンについて
実際に起こった問題と解決のプロセスをお話しします。
まずコミュニティエンジンでは、vce、mmsuite、gumonjiを運営している。現在はvce2を開発していて、まもなくリリース予定。また中国のコミュニティエンジンでテストを行っている。vce2とは、ネットワーク通信ミドルウェアでマルチプラットフォーム対応ソケット通信ライブラリです。応用分野としてMMOなどの大規模ネットワークゲームや高速のWebサーバに応用が考えられている。
Vce2の開発について
最初は一人で行っていたが、質をあげるためにスタッフ追加。QAが考えられていなかったのが、エンジニアを追加して、リリース担当者の配置も行った。チームにスタッフを追加する際の問題がでてきた。
・一人の仕事を分割するのに、モジュール間の結びつきが強いので、開発者同士のコミュニケ ーションを密にとらなければいけないということが起きた。
・また仕様やスケジュールなどチーム内の情報共有の方法の問題がでてきた。
・QAの面では開発側と連携して作業を行わなければいけいない。
・人材不足。ミドルウェアのテストにおいてはライブラリを実際にリンクして実行させてテストしな ければいけないので、コードたくさん書かなければならなかった。
・リリース面での問題。複雑な流れを人で行っていては人為的なミスが発生しやすくなる。
解決策として行ってきたこと
1.プロジェクト管理システムの導入
2.中国コミュニティエンジンでテストを行う
3.自動化するためのビルドシステムを開発する
1.プロジェクト管理システムの導入
このシステムに必要な要素として、以下がある。
・作業内容の管理。
・バク管理。
・スケジュール管理。
・進歩管理。
・チーム内コミュニケーションの補助（仕様の共有など）
・分かりやすい
・使いやすい
条件を満たすシステムとして、オープンソースで開発されているtrac（http://trac.edgewall.org/）を使用した。
・ｗｅｂベース
・高いカスタマイズ製
・チケットベースのタスク管理 ＊チケット：一番小さい作業単位
・ソース管理ツール
・マイルトーンスケジュール管理
・進捗管理
・wiki
導入した結果、会議の方法とコミュニケーション方法が変わった。まず会議に関しては、trac画面を投影して会議をするようになった。このことによって、時間が短縮して、その分を、問題解決、決定に時間をつかえるようになった。コミュニケーション方法に関しては、チケットという言葉が会話にでてくるようになった。話の前提がチケットという単位におかれている状態でコミュニケーションが始まるので、円滑になる。tracをいれると他の人の動きが見ることができるのでチームの連帯感が強まった。ただし、ツール導入だけではうまくいかない。使う上でのルールをしっかり決めないと進まない。
2.中国コミュニティエンジンでテストを行う
次に人材不足に関して、中国のコミュニティエンジンでテストを行うことを決めた経緯に関して。QAとは製品の質（ユーザビリティやバグなど）を上げるために行う。またQAで行うこととして、テストを行ってバグを出すこと、テストケースやテストコードを管理すること、製品全体の品質に責任を持つこと。
QAは責任を持っているから気づくことがある。ユーザビリティとかはいい例で、お客さんの立場にたった意見がでてくる。またコミュニティエンジンでは設計段階からQAが参加。なぜかというと、仕様を熟知している必要があるし、仕様テストに関してのスケジュールの見積もりもあるので、初期の段階から情報を仕入れてテストケースを作成してもらっている。またQAの視点からコスト判断に関してフィードバックがある。
・中国とのコミュニケーションでは同じtracを日本と中国で使った。
・ソースコード管理ツールもネット上でソースコードをやりとりした。
・計画的なテストプランを作る。スタッフのやりとりに時間かかるので、計画をしっかりたてた。
結果として、以上を共有するまでは時間がかかったが軌道にのると順調に進むようになった。中国から機能に関してフィードバックがくるようになり、場所に関らずチームとして連帯感が生まれた。
3.自動化するためのビルドシステムを開発する
vce2のコンパイルからパッケージの作成まで１００の手続きがある。人為的なミスが入る可能性が高くなるので、自動化する必要が出てきた。プロセスの中で問題が起こったとき、どこで起こったか分かるようにシステム開発した。開発した結果、テストのライブラリ製品のようなものがテストプログラムを動かすので、それを自動化のプロセスに入れ込むことが出来た。デイリービルドを行うことで、最低でも一日以内に問題を発見することが出来る。更にコミットビルドというレポジトリを検出した時点でテストを行いレポートすることで一時間以内に問題を発見できるようになった。失敗したところにマウスを当てるとコンパイルエラーが出る。結果として、開発者が意図しないエラーの早期発見可能になった。また、自動化によって意識することが減って、時間的心理的余裕ができるようになった。
以上のような改善を行ってから、再びジョエルテストを行うと、○と言えるところが増え、12点満点になった。12点をどう見るかだが、ジョエルテストではプロジェクト運営で表層化しやすい問題を扱っている。ルールやシステムは維持されなければならない。今後の課題としては他のプロジェクトへ今回行ったことを導入すること。ノウハウの共有、開発プロセスへの意識を伝達が重要で、コミュニティエンジンでは一対一のミーティングを設けている。
『良いシステムやルールは会社や人や製品の質を上げ、コミュニケーションの力を最大限に引き出すことができる。』
前半部：コミュニティエンジンにおける開発体制2（コミュニティエンジン中嶋氏）
経営の視点から仕事をどう見るかというお話をします。経営者としてしたことは、決めること、スタッフに何度も言うこと、投資家にプロセスを直すために投資をすると説明、最もできるエンジニアをプロセス改善にコミットさせる、コミュニケーション時間増やす、設備投資の決定などがある。
投資前は2人だったが、結果、いつ完成するか不明で、顧客にせかされ続け、売ってもサポートしきれなかった。
投資後、プロジェクトマネージャーをおき、開発者、通訳、テストエンジニアなどをおいた。計画通りに完成できる状態になった。顧客をせかせるようになった。今は営業がボトルネックになった。確かに初期コストはかかった。４0人中弱の会社で、7人がプロセス改良に専念した。株主に説明するときに、納得度は高かった。計画的に渉外が出来るようになった。技術ロードマップに関しても確信を持って取り組めるようになった。スタッフをいきなり入れても駄目で、リーダーになるスタッフ必要で、人を増やすための一時的な資金も必要だった。この辺りが今回たまたまコミュニティエンジンでは条件が揃った。また大前提として開発がボトルネックになっていて、お客さんがいる状況で必要性がある状況は必要。
これらの決定をする上で、最高のエンジニアをプロセスに回すことで新しいものを作れなくなるのではないかという素朴な疑問がある。必ずしもそうはならないと考える。QA担当が仕様の段階から突っ込みを入れられる体制をとることが出来ることで、レベルの高い指摘を作る前に入れられる。インターネットアプリケーションが当然になってきていることによって、コーディング能力やアルゴリズムの駆使で解決できることは減少方向にある。それよりも情報収集や分析や試行したりすることが重要になってきているので、社内にコミュニティを作っていくことが大切。開発プロセス改善に最高レベルの人を割り当てるときには、必要な地盤を整えてから次に進んで欲しいということなのでちゃんと話し合っていれば、そんなに問題ではない。新しいものを作る前に準備をちゃんとすべき。次の課題としては営業と人材不足と中長期計画の作成があります。最初は暗闇への跳躍と思ってやってみたら、発展への次のステップが見えて良かった。また来年にはどうなったか報告します。
質疑応答
Q.テストケースはどのように作ったのか。
A.テストケースといってもミドルウェアだから技術的な仕様を深く理解していないと作れない。まずは担当の開発者が大まかなプランを作って、その上で中国のテストエンジニアが細かいテストケースを作るという順番を踏んだ。
Q.例えば新しいものを作ったとき、自動ビルドにテストケースを入れつつ、開発が期間までに終わっている必要性があるが、それはうまくできるものなのか。
A.きちんとコンポーネントごとにスケジュールを組んで、コンポーネントのコードがFIXしてからテストを行うといった地道なこと。
Q.自動ビルドシステムの開発は１からフルスクラッチで行ったのか？
A.中身的には、メイクやMSビルドを上のレイヤーで呼び出す必要だった。それぞれが勝手にビルドでテストすると合わせの作業必要となってしまう。実装の方法は単純でウィンドズのWSHというスクリプトをマスターにして、そこからシグウィンのコマンドラインを呼び出して、リモートテストやリモートビルドをオープンソースのツールを使ってシステム全体を組み立てた。
Q.プロセス改善に舵を切ることが挑戦だったということだが、開発メインからプロセス改善にシフトするタイミングはどういうタイミングいいのか？
A.チームで開発することが肝。作ろうとしている製品が一人で出来ないときが、やるべきときであると思う。
1人でやっていて客がいない場合は必要ないが、2,3人でやるなら、なんかしらの開発プロセスについて考えながらやるべき。合宿の場合も、最初の何時間は議論して今日どういうプロセスにするか話してから開発を行うとうまくいった。
Q.テスト工程を中国にやらせた背景と、中国の今後のプランは？
A.理想的には面と向かって話ができるほうが良いので日本が良かった。たまたまかなり出来るエンジニアを中国でみつけたので、スケジュールを重視して中国にお願いした。コスト面では中国だからそこまで安いわけではない。
Q.ジョエルテストで仕様書から行動があったが、仕様書はいろんなレベルがある。細かくやり過ぎるとソースコードと紙が一致しないなど問題が起こる。どのレベルでテストするのか？
A.機能仕様書と技術仕様書を分けて考えている。変更に耐えられるようなシステム作ることが大切。最初にしっかり決めるが、変更がうまく出来ることも大切。予め設計できることは全てするというスタンス。
後半部：各社CGMビジネスの紹介
チームラボ猪子氏
お客様のサイトを作ったり、自社プロダクトで作って販売したりしている。IZA!（http://www.iza.ne.jp/）は産経新聞社の新しいニュースサイトですがニュースに対してブログで解説つけれたり、辞書を作れたり、例えば世界というジャンルで、一般の人が発信するニュースに対するブログもつけれる。また3年以上前からレッツエンジョイ東京（http://www.enjoytokyo.jp/）というサイトを行っている。ちょうど写メールが出てきた頃で、みんなで作る東京ガイドみたいなサイト。
自社サービスで Bon Sagool（http://bon.sagool.jp/）というソーシャルリーダーのようなサービスを行っていて、ソーシャルブックマークを登録していると自分の気に入るソーシャルブックマーカーたちのホットリンクがわかるサイト。個人が自分で作った音楽を配信するWacca（http://wacca.tv/）というサイト。無料でも有料でも、著作権でも出せる。売れたら70％くらいアーチストにお金が入るが、だいたいみんな無料でやる。月500曲だしてる。
アイスタイル小川氏
＠cosme（http://www.cosme.net/）を開発運営している。化粧品情報口コミレビューを行うサイト。世の中のほとんどの化粧品データを持っている。それに対して口コミをすることができる。7割方、利用者から登録されている。嘘の口コミや登録情報を精査するために、社内の運営グループが正しい情報にアップデートしている。ユーザーとの共同作業で商品DBを作っている。7年くらいやっていて、老舗。今までの口コミも452万件に上っている。1月10日リニューアルして、コミュニティ機能追加した。mixiみたいだといわれている。先人の知恵を学ぶと似てきてしまう。もともと＠コスメはコミュニケーションを推進するものではなく、中立的な立場で化粧品の情報を集めて、DB化してマーケティングをしていこうという位置づけだった。しかし、ユーザーニーズとして、コミュニケーションがあった。だからやってみた。意外に相乗効果があって面白い。
カヤック貝畑氏
カヤックは経営理念として、作る人を増やす。もの作りは人を幸せにする。というのがある。
ART-Meter（http://www.art-meter.com/）という素人の絵を売るサイトがある。面積で単価を決めて売るテーマでやっている。絵を書くのをやめた人や、学生が参加できる。
T-Select（http://www.t-select.com/）というサイトがある。Tシャツを売るサイト。デザインを一般人から集める。一定人数が集まると製作される。デザイナーとバイヤーで成り立っている。コミュニティでコメントを付け合う。
湘南Clip（http://www.shonan-clip.jp/）。地域特化のサービス。ブログ、SNS。
モビゾー（http://www.movizo.com/）ブログパーツに力入れている。IAM。SNSに入らなくてもブログ自体で、コミュニティを作ることが出来る。なぜか日本語版しかないのに中国でブレイクしてしまった。
ウノウ山田氏
右脳から名前が来ている。芸術性、想像性をつかさどる。日本から世界に向けてのサービスを目標としている。株式会社にしてからは、まだ2年くらい。最初は一人でやっていた。株主はインターネット系の事業会社が多い。今19人で13人エンジニア。主に事業内容は３つ。
映画生活（http://www.eigaseikatu.com/）。映画の感想をいろんな人が書いて、それが、ランキングになる。作品自体や俳優の情報もみんなでWikiを使ってデータベースを作っていける。独立系映画サイトでは最大規模。
フォト蔵（http://photozou.jp/）がある。一年半くらいやっている。写真や動画で、SNSの機能。グルーピング機能できるので、家族や同僚などを分けてパーミッションを分けることができる。
最近、携帯版のyoutubeみたいなサイト(ビデオポップ、http://vpop.jp/)をやっている。まだ規模はいいが、先月70万PVくらいで伸びはいいので強化している。会社としてはCGM的なものをたくさんやっていこうという会社です。
後半部：CGM発信側とWATCH側
Q.積極的に発信している人とWATCHの人はどれくらいの割合でしょうか
チームラボ猪子氏
ニュースサイトでは99％以上見ている人。音楽サイトは95％以上が音楽を作っている。最終的にはwatchを増やしたいが、新しい音楽、新しいクリエイティブに出会いたいという人が少ないのか、音楽興味とインターネットの相性は悪いかもしれない。
アイスタイル小川氏
口コミは2万人投稿。月間のユニークユーザーは95万人なので、全体の２％くらい。2万人は少ない。質を上げようとしてくれる人が2万人くらい。
カヤック貝畑氏
投稿する人にインセンティブを持たせている。湘南サイトでは、3割の人がインセンティブ目当てで投稿してくれている。
ウノウ山田氏
サイトによって違うが、フォト蔵だとユーザー10万人でPV1000万人くらいなので、１％程度が平均的。ただカリスマ的な人だと、一日1万人のアクセスがある。クリエイティブなことをしてくれる人が少ない中でどうやっていくかが重要。
後半部：CGMサイト設計時のスタンス
Q.CGMサイトを運用される際に、発信する人、Watchする人どちらを重視して設計するのか
ウノウ山田氏 どっちも重要。最初の時期は、発信してくれる人は重要度が高い。情報が集まってきた段階では、UIや見せ方の部分が大切になってくる。ぱっと来て、そのサイトを使う気にならないと駄目だから、いかに捕まえるかが大切なので、テーマ設定が重要。やってみようというインセンティブの強さが重要。
カヤック貝畑氏
完全にwatchメイン。見る人の機能がどこまで充実させるかが大切。PVで広告費とかを取っている。投稿する人にはインセンティブでクリアしているので、基本はwatchメイン。
アイスタイル小川氏
二元論ではない。サイトの利用形態にはどれくらいよくサイトを使うかは大きく3つに分かれる。それぞれに使いやすさ使いにくさがある。初期は、メーリングリストから始まっている。情報発信に反響があったので、99年くらいからその流れをデータベース化した。初期では発信する側重視だった。
チームラボ猪子氏
比較的、発信する人が使いやすいように設計している気がする。パーセンテージの割には。
後半部：欧米と日本のCGMの違い
Q.欧米と日本のCGMの違いは？
ウノウ山田氏 欧米は英語圏だから、ユーザー数が圧倒的に多いので、CGMでティッピングポイント越えるのが重要だが、サイトを作ったとき、人の集まる人数が違う。欧米はチャレンジングなサイト、マイノリティー向けが多い。お金集めやすいので多産多種。数が違う。日本では、欧米を参考にして作る印象はあるが、最近は日本オリジナルも生まれている。 チームラボ猪子氏 Q.どうぶつの森は海外でうけると思いますか？ A.どうぶつの森は、労働が喜び。長期的には、あんなものがうけていく。 Q.サイト運営者から見て、盛り上がるCGMサイトの条件は？（情報の分野、仕組みなど） ウノウ山田氏 カヤック貝畑氏> アイスタイル小川氏 チームラボ猪子氏 Q.自社以外で普段利用しているCGMサイトは何ですか？ チームラボ猪子氏 アイスタイル小川氏 カヤック貝畑氏 ウノウ山田氏 Q.最近気になるCGMの分野は何ですか？ チームラボ猪子氏 アイスタイル小川氏 カヤック貝畑氏 ウノウ山田氏 Q.CGM関連で気になる技術は？ アイスタイル小川氏 カヤック貝畑氏 Q.CGMサービスを開始する経緯は開発者主体なのか？ニーズ主体なのか？ ウノウ山田氏 ユーザーニーズはない。CGMは今までなかったものなので、想像のできないものは創造できない。だからといって開発者主体というわけでもない。エンジニアリングをわかっている企画を出来る人が重要。両方出来るバランスが重要。自社のプロジェクトは、エンジニアだけど、企画を立てたいという人から出てくる。mixiとかはてなでは企画がエンジニア出身じゃない人がいたりして、どっちがいいのかはわからない。仕組みとしてエンジニアから出てくるようにもしているし。 カヤック貝畑氏 アイスタイル小川氏 チームラボ猪子氏 Q.PCとモバイルで２つのメディアをコンバートするときに気をつけていることは？ チームラボ猪子氏 アイスタイル小川氏 カヤック貝畑氏 ウノウ山田氏 Q.楽しいものができたらCGMっぽかったっていうのが正しいのではないか。CGMという感じで作ろうと思ったものはありますか？ チームラボ猪子氏 カヤック貝畑氏 アイスタイル小川氏 ウノウ山田氏 Q.高速なリアルタイムのサービスが実現できるとしたら何をしたいですか？ ウノウ山田氏 カヤック貝畑氏 アイスタイル小川氏 チームラボ猪子氏 Q.投稿を促進するために、演出、機能で成功したもの教えて下さい。 アイスタイル小川氏 カヤック貝畑氏 ウノウ山田氏 チームラボ猪子氏
使われ方が違う。欧米だと、パブリックに対して配信する興味が強い。日本は、そうではなく、友達5人に配信していたりする。パブリックに配信したい要求が少ない。自分の相対的な関係性の中で配信している。例えば、Waccaでは、チームラボの曲をアップしてくれている。音楽は比較的パブリックなのものであるが、実は日本人は、短歌を一人に送る歴史的背景があり、茶室のデザインも来る人だけにわかればいいといったような伝統があるので、あまりパブリックへの関心がない。
一番すごいインターネットサービスはどうぶつの森（http://www.nintendo.co.jp/ds/admj/）。後半部：盛り上がるCGMサイトの条件
ある程度の数の人に、びびっとくるのが最初はとても重要。CGMはコンテンツをユーザーが作るので、最初はコンテンツがない。「こういうことをやったらいいんじゃない？」ということに関して、共感してくれる人がいなければならない。最初のところでの引きが大切。逆にいうとCGMで盛り上がっていないのは、最初で失敗している。ぱっと見て面白そう、便利そうというのが重要である。日本はユーザーが少ないからやりづらい。
「共有」がゴール。最終的に勝負するのは、コンテンツを作り出す仕組み。ニッチなサービスでも競合はいて、コンテンツの集め方、サイトの特徴を打ち出しながらやっている。サイトを作っても人は集まらない、主旨の意思表示が大切。コンテンツを見て、レベルの違いで人が集まらなかったりする。その辺の誘導、操作に注意してやっている。
コンテンツを溜める仕組みが重要。掲示板はCGMにはなりにくい。＠コスメでは、星で評価する。それは典型的なフォーマット。それにフリーワードで加えられる。情報を溜める形式を明確に提示する。書きやすさが見やすさに繋がっていれば尚良い。
「分野」。シェアするニーズがあって、現在サービスがない分野で盛り上がる。ただ任天堂だけが仕組みだけで盛り上がっちゃっているのはすごい。後半部：講師が普段利用しているCGMサイト
正直は１つもない。サイトにあんまり触れていない。サイトだけではなく、テレビや新聞などのメディアにも昔から触れない。漫画だけ。ジャンプだけ。
あんまり見てない。敢えて言うと、言葉をあまりしらないので、ウィキペディア。CGMも知らなかったので、調べた。言葉の定義にはこだわらない主義。
一つも使っていない。情報が集まって、そこから質の高い情報だけを知りたい。口コミ際とならいちいち探さなければならない。社員にお願いする。社員が質の高い情報を抽出してくれる。そこまで高度の情報を抽出してくれる自動化されたものがあれば使う。
ライブドアリーダー。RSSをたくさん読んでいて、情報収集をしている。はてなブックマークのお気に入りに何人か登録していて、尊敬する人がなにを登録しているかチェックしている。ネットおたくなので、そういう情報が好き。中国に行って一番辛かったのは、そういう情報が手に入らなかったこと。台湾地震で回線が切れてしまっていた。ウィキペディアも使う。後半部：最近気になるCGMの分野
コミケとエロ。後はメーラーがホット。私はメールが使えない。自分の脳がメールの情報量に追いついていない。追いつく範囲で見ていく。メーラーとブログとメッセンジャーとかの境界線がもっと曖昧になったらいいと思う。
タグ付け。タグが増えるとタグが氾濫するので、タグ検索の精度をどうあげるとか、気になっている。アントロジーも気になっている。メタデータの領域面白い。
大量情報からいかに本質的情報を引き出すか。ソーシャルブックマークは近いものがある。更にブログなり口コミなりで効果測定を絡めて言って、書き込んだ情報がどう影響するかも表していけたらもっといい。kizasiやテクノラティに興味がある。
ひとつあげるならば、今インターネットはソフトだと思うが、ハードもCGMっぽいものができてくるのではないか。何かはわからない。みんなで作るハードみたいな。ハードとソフトの融合に興味がある。後半部：気になる関連技術
情報をどう分類して、どう探索可能性を高めるかっていう技術。
既存の技術ではGoogle Baseが気になっている。ユーザーがグーグルのネットワークの中で商品を売ったり、検索結果と連動したりする。これも一種のCGMではないのか。決済系がでてくるとより完成された世界ができるのではないかと、びくびくしている。後半部：CGMサイト企画時のプロセス
ユーザーニーズではない。技術者主導は失敗している。それは技術先行でニーズを捉えきれず失敗している。運営・投稿が循環していないといけない。そこまでイメージしていないと成功しないので、技術者主導ではないことが多い。
開発者主導ではない。主宰の山田に賛同した消費者が多かったが、その後は市場構造を変えたいという思いが強かった。なので、消費者の声大切にして、頂いた要望に真摯に向き合う。プロデュースを出来る人がいて、それを統合しながらさらに一歩先を見るプランニングが多い。
ユーザーニーズをリサーチしたことはあまりない。どっちかというと、開発者主体でやる。ただ曖昧で明確な線引きはない。プランナーという職種はない。みんなプランするし、みんな手を動かす。後半部：PCとモバイルのコンバート
どっちかに集中したほうがいい。両方やるにしても、どっちかを意識して、どっちかは補助的にした方がいい。PCとモバイルでユーザー層が違うので、両方同じようにやるのは難しい。
＠コスメの場合はPCが最初で、後から携帯ができた。デバイス依存によってのユーザビリティの違いは感想であることは間違いないから、今までは区別をしてない。ただモバイルの市場環境が変わってきているので、PCと共に成長できるのかという視点で、差別化・区別化はこれから必要になってくる。だから＠コスメを成長させることと、携帯サービスを別のサービスとして、構造化していっているところ。今PCと携帯の使用状況は半々くらい。
PCとモバイルと利用者層違う。サービスの質によってPCか携帯選択。携帯で作ったものは利便性が重視されているのでPCには対応しない。PCで作ったものを携帯で使うときはおまけみたいな確認用として。
モバイルあまりやってきていない。携帯でどういうユーザーがどういう使い方をするのか、試しているというか勉強しているところ。後半部：CGMを意識しているか
ない。
CGMという言葉ができる前にサイトを作った。情報共有などをゴールと考えて、自然に達した。
ない。おっしゃる通り。
インターネットができた段階で理論的にはCGMは可能だった。マスになった段階でウィキペディアなどが生まれてきた。例えば、97年くらいからHTMLで日記を書いていたので、ブログが出てきたときはなんで必要なのかと思ったが、簡単に出来るということは素晴らしいこと。理論的には初めからできたが、今になって、そういうものの可能性が広がってきている。後半部：高速なリアルタイムサービスができるとしたら……
VC2で何ができるかということだと思うんですが、MMOみたいなことにはすごく興味がある。セカンドライフ的なMMOによって集合知的なものが生まれてくるんじゃないかという期待がある。それができるミドルウェアがあるのならばMMO的なもので可能性を追求していきたい。
効果測定。これからどんどん増えていく情報を解析するツールを作りたい。例えば、ブログパーツをつけてくれたものに、見ている皆のPC上のFLASHの中にアルゴリズムがあって、そのブログパーツを見ている皆がなにかしら計算をしているプロジェクトをやってみたい。そういった無限の情報の解析をやってみたい。
情報を構造化、有機化するパワーとして使えたら面白い。イメージは具体的に持っていないが、サービスというより、ミドルに近いのでは。
マッチングエンジンを作っているが、計算が重くて、リアルタイムで出来ない。そこをリアルタイムやパーソナライズにしていきたいと思っている。後半部：CGM投稿促進の方法
マイページで、口コミ数によって、色が変わる。10件超えるとキラキラしたりする。細かい話だが、これらの積み重ねで、常に変化を与えてあげるのが重要。
どう情報をアップした人の情報を永続的にするか。すぐ消えないように、情報の再利用をしっかりする。例えば、ブログでアップした記事を、お店のDBとして補完的に再利用する。他のところで、自分の情報が使われているという実感を与えたことで工夫として効果があった。
映画のサイトでは、最初は掲示板を設置してみたが、全然盛り上がらない。今上映している映画のもページを作った途端、みんな書くようになった。テーマを決めると人間は喋れるもの。漠然としすぎないで、何かについてどうですかという具体的な提示。
愛だと思う。
愛。