Google の Developer Advocate とはどんな仕事なのか？

僕の仕事は Google の Chrome Developer Advocate です。
Google Japan では先週 (2013 年 4 月) からこの Chrome の Developer Advocate を募集開始しました。他にもGoogle+、YouTube、Android など同種の担当者も募集しているのですが、よく聞かれるし、リクエストもありましたので、この機会に Developer Advocate がどんな仕事をしているのか、ご説明したいと思います。

Developer Relations とは

上記一連のお仕事ですが、すべて Google 内の Developer Relations チーム (以下 DevRel) という部署に属します。おそらく Google の中でも、開発者の皆さんが一番接触する機会の多いチームではないかと思います。DevRel はさらに Chrome や Android といった、プロダクトごとのチームに分かれています。

業務内容は名前から想像できる通り、Google と外部開発者との関係を築いていくことを中心としています。職種は Program Manager、Developer Programs Engineer、Developer Advocate、Technical Writer などがありますが、僕が担当しているのは Developer Advocate です。
Advocate という言葉だけで仕事の内容がピンと来る人はほぼいないと思いますが、学校で教わるような単語ではないので当たり前ですね。他社で言うところの Evangelist が一番近い仕事かと思います。それでも分からない方には、「Google のテクノロジーを外部の開発者の方にも使って頂けるよう啓蒙活動する仕事」という説明をすることが多いです。

Developer Advocate という言葉の由来はこんな感じ：
Evangelist という言葉は元々宗教の伝道師に使われる言葉です。しかし Google で Evangelist に類する仕事が作られた際、開発者の方に一方的に伝えていくだけでなく、対話やフィードバックから Google 自身も学び成長していくという意味を込めるため、Advocate という言葉が選ばれました。

以下、具体的な仕事内容に触れて行きますが、本記事は僕が担当している Chrome 周辺について述べているものであり、他のプロダクトについては必ずしも当てはまらない点を予めご了承下さい。今取り組んでいる仕事の一部を怒られないであろう範囲で書いてみます。

啓蒙活動

DevRel の仕事は、「Google のプロダクトをプラットフォームとしたアプリを使ってもらいたい人のお手伝いをする」のがメインです。Chrome に関して言えば、「Chrome をプラットフォームとしたアプリ、つまりウェブサイトやウェブアプリを制作する人を手伝う」言い換えると「Chrome だけでなく HTML5 を含めたウェブ全体、特にフロントエンド周りを盛り上げる」というのがミッションになります。非常にざっくりしてますし、はっきり言われたことはないですが、僕は勝手にそんなイメージを持って仕事しています。

講演

おそらくこれが一番業務として目立つ部分だと思いますが、外部で開催されるイベントで講演を行います。内容は大抵 Chrome の技術を紹介するものか、HTML5 の機能を紹介をするものです (ちなみに最近は HTML5 より Open Web Platform、OWP という言葉を使う機会が多いです)。当然資料も自分で作成するので、事前のインプットがかなり必要ですし、ある程度質問も想定して準備をするため、結構な時間が割かれます。地方で講演する場合は出張も伴います。

ソーシャルメディア

ブログや Google+、Twitter などのソーシャルメディアを使って最新の情報を流します。これは見られている方も多いと思います。

HTML5Rocks

HTML5Rocks の記事を書いたり、サイトのメンテナンスをしたりします。HTML5Rocks 自体がオープンソースですので、Pull Request も受け付けていますし、記事のレビュー、それから日本語の翻訳を頂いた場合のレビューもしたりします。

Google Developers Live

毎月YouTube Liveを使って生放送しているウェブ番組が Google Developers Live (GDL) です。ご覧になったことがある方はご存知だと思いますが、ゲストを呼んで技術セッションをして頂く内容です。スタジオの準備などは手伝ってくれるスタッフがいますが、その他の部分、ゲストの手配や内容の選定、番組の司会進行などはすべて自分でやります。アメリカとイギリスの GDL では、ゲストではなく Advocate が直接セッションをやっていますが、日本では今のところゲストの方にお願いしています。

せっかく作ったコンテンツをどう広げていくか考えるのも、Advocate の仕事です。過去にこんなブログ記事を書いたこともありました。これは見てくれる方々にとっても、コンテンツを作っている我々にとっても嬉しい、良案だったのではないでしょうか。

StackOverflow

フォーラム的な場でのサポートも業務のひとつです。日本語であれば Google Groups を使った質問の回答なども行なっていますが、グローバルでは StackOverflow を公式にサポートの場にしています。Google Code ではなく github にオープンソースのコードを置いてしまうところもそうですが、Google の (というより DevRel の？) 自前のシステムに拘らないところとか、合理的でよいと思いません？

コミュニティ

DevRel は全世界で 200 名程度 (日本では現在 4 名) しかおらず、スケーラビリティが重視されます。そこで、外部コミュニティの一部となってテクノロジーを盛り上げる場面も多々あります。

Google Developers Expert

ご存知の方は多いと思いますが、Microsoft でいうところの MVP のような、優秀な外部の開発者を認定する Google Developers Expert という制度があります。GDE の皆さんとの情報交換も重要なお仕事です。

これは以前 Google API Expert と呼ばれていたもので、元々日本発のプログラムが、昨年から全世界共通のプログラムになりました (Naoki Ishihara と Fumi Yamazaki のおかげです！)。ちなみに僕も入社前は OpenSocial の API Expert でした。 

コミュニティとのお付き合い

日本の DevRel で Chrome 担当は僕だけですので、当然やれることは限られてきます。そこで、上記 GDE を含め、志を同じくする開発者コミュニティと協力し合い、時には一部となってお手伝いをするのも重要な仕事です。コミュニティを盛り上げるために何ができるか考えるのは、かなり楽しいです。

イベント運営

コミュニティのお手伝いの一環として、Google の会場や設備を提供し、人員としてお手伝いするのも重要なお仕事です。勉強会などのイベントを開催する、プロダクトに関わるエンジニアに講演してもらう、など。2011 年には html5j とコラボで Chrome+HTML5 Conference を開催しました。Chrome Tech Talk Night は既に 5 回を数えています。6 月には Test The Web Forward というイベントの開催も予定しています。

パートナー、インプット、Hacking、etc

実際はもっと雑多な仕事がありますが、上記に分類されない仕事としては主に以下のようなものがあります。

パートナーとのお付き合い

オープンな一般開発者向けの仕事が占める割合はかなり大きいですが、表からは見えないパートナー向きの仕事もあります。何かプロダクトを作ってもらうための交渉をすることもありますし、コンフィデンシャルな情報を含む技術的問題を受けて、Chrome 自体の機能を改善したりといったこともあります。技術的にパートナーとの間を取り持つのも、Developer Advocate の重要な役割です。

インプット

ここまであまり技術的な話がなかったですが、もちろん最先端の技術力も求められる仕事です。インプットなしにアウトプットなどできる訳もありませんので、常に最新情報にキャッチアップしていることが求められます。

Hacking

理屈だけインプットしていても仕方ありませんので、実際の開発も行います。大きなものを作る機会はそれほど多くありませんが、技術の啓蒙に直接繋がるデモや、社内向けのツールを作る場合もあります。

今まで作ったものとしては、東京の Chrome エンジニアチームが担当している範囲のものをテーマにして、WebSocket、Forms、最近は FileSystem 関連のデモも。後は趣味と実益を兼ねて Chrome Extension や Chrome App を作ったり。コードは github で公開しています。
基本的にプロダクションレベルのコードを自分で書くことはないですが、同僚の中にはパッチを送り続けて WebKit (今は Blink ですが) の committer になっちゃった人もいます。

Chrome Experiments

また、過去に話題になった Chrome Experiments の中には日本発のものもあることをご存知でしょうか？例えば先日発表された World Wide Maze もそう。ああいったプロジェクトにテクニカルなサポートを行うのも、Developer Advocate が担当します。

エンジニアとのやりとり

Google 東京オフィスの Chrome エンジニアチームはそれなりの規模です。先述のように、 WebSocket や FileSystem、Forms、WebComponents周りなど、主に OWP 機能を実装しています。W3C や IETF のサイトに載る標準仕様を自分の手で書いている人も少なくありません。そんなエンジニアたちと外部開発者の橋渡しをするのも、僕の仕事です。GDL や講演を通じてエンジニア自ら啓蒙してもらうこともあれば、外部開発者のフィードバックを届けることもあります。

仕事の楽しさ

日常業務は上記のような感じです。ただ、これはあくまで僕の例であって、Developer Advocate 全員に当てはまるものではありません。同じ Chrome DevRel のメンバーは、本社のある Mountain View を中心に、日本を含めて世界 7 カ国に散らばっていますが、それぞれに得意分野を持ち、異なる仕事をしています。

Google では、仕事は与えられるものではなく、自分で作り出していくものです。そのため、人によってやってることが全く違うのは、ごく自然なことなのです。いいと思ったことは何でもやれるし、それでもちゃんと評価もしてもらえる。

僕が過去にやった思い出深い仕事をふたつ挙げます。
ひとつは、2011 年の GDD での Developer Link です。2 つのセッションやキーノートなどに加え、企画から制作、パートナーとの交渉まで含め、イベント当日までにサービスを完成させるべくプロジェクトをリードしました。コードも一部書いてます。

もうひとつは現在進行形ですが、Web Music Developers Japan の活動です(仕事というより趣味ですが)。元々音楽好きでブラウザでシンセサイザーが作れる Web Audio API に大興奮していた身としては、それを通じて開発者はもちろん、過去であれば無関係だった業界の有名人と関われたりするのは、役得だなあと思います。Web MIDI API が登場してくれば、今後ますます面白いことをしかけていけるんじゃないかとワクワクしています。

難しい所

周囲がハイレベルで、正直ついていくのに必死です。技術的にも、仕事のやり方的にも。
加えて、上記のような仕事が常に同時進行している感じなので、時間配分や集中力の管理も難しい部分です。

それに拍車をかけるのが、Regional (本社から離れている) であることです。Chrome DevRel で日本担当は僕だけですので、チームメンバーとのコミュニケーションは基本メールか Hangout。Hangout は便利ですが、テクノロジーで時差は超えられません (今だと日本の朝 9 時が本社の 17 時、日本の 17 時が London の朝 9 時)。メールは文字情報だけなので、相手の表情は見えないですし、空気が伝わって来ません。

そこで出張ということになる訳ですが、今度は対面コミュニケーションに苦労します。言語そのものというよりも、自分の性格だったり、カルチャー的な部分の方が大きいかもしれませんが、話が長くなりそうなので、この辺はまた別の機会に。

環境

これまで何社か渡り歩いてきましたが、働きやすさという意味では群を抜いて快適な会社です。無料のランチ (実は朝食と夕食もある) が取り沙汰されることが多いですが、産休は父親 (Paternity Leave)、母親 (Maternity Leave) ともに取ることができますし、休暇も柔軟で、まとめて 1 ヶ月休んじゃう人も少なくありません。チームでのコミュニケーションを充実させるためのアクティビティも頻繁にありますし、社内ではしょっちゅう Tech Talk や部活動が行われていて、とてもよい雰囲気です。こればっかりは、入ってみないとわからないと思います。

求めている人材

Chrome DevRel で募集している人材は 先日も書いたように、「英語、日本語が堪能で交渉力、技術力、講演、イベント開催に自信のある方」です。この言葉の意味が今回の記事で少しはお分かり頂けたのであれば、書いた甲斐があったというもの。

もちろん、ここでの話はあくまで「僕の場合」であり、新しく担当する方に同じような仕事をして欲しいと思っていませんし、むしろその人なりのやり方を生み出して欲しい、生み出すべきです。

自分で仕事を作り、こなしていける人。コミュニケーション能力が高く、色んなことをグイグイと、楽しみながら前に進められる人に来てもらえたら、嬉しいな。

その他の職種について

今回は主に僕と一緒に仕事してくれる方をターゲットに、仕事内容について説明しましたが、最後に DevRel で募集しているものを、他の職種も含めてご紹介しておきます。

Developer Advocate - Chrome

こちらが今回紹介した僕と同じ仕事です。

Developer Advocate - Google+

僕と同じ Developer Advocate で Google+ を担当します。

Developer Advocate - YouTube

こちらも Developer Advocate で YouTube を担当します。

Developer Programs Engineer - Android

Developer Programs Engineer は Developer Advocate よりもテクニカル寄りな仕事です。パートナーやコミュニティとのコミュニケーションよりも、コードを書いたりオンラインサポートをしたりするのが中心になります。ちなみに昨年末米国に転籍となった Takashi Steveland Matsuo は現在 AppEngine の DPE です。

Program Manager

こちらは米国に転籍した Fumi Yamazaki が以前担当していた仕事です。Program Manager は特定のプロダクトを持ちません。日本の DevRel の代表者としてチームをまとめ、予算、コミュニティ、イベントなどの管理を行います。高い交渉能力と英語力、リーダーシップが必要とされます。
というわけで、皆さんからの応募をお待ちしております :)

関連記事

• Google の Developer Relations について
• 渡米することになりました

Googleに転職します

今の会社に勤め始めて、はや4年8ヶ月が経過しました。

ポータルサイトをまるごとソーシャル化したいとの野望を持って入社し取り組んだプロジェクトでは、サービスを跨いだプロフィールやソーシャルグラフの共有、日本初のPC向けOpenSocialコンテナの実装など、他の会社ではなかなかできないであろう体験をさせてもらいました。またその間、OpenSocialのGoogle API Expert就任とコミュニティの運営、Shindigのコミッター就任、SocialWeb Japanの運営など、ディベロッパー・エヴァンジェリストとしての活動も並行して行って来ました。まさにソーシャルウェブ馬鹿な数年間だったと思います。

一方世間はというと、日本では昨年からmixiやモバゲー、GREE、Yahoo!といった巨大サイトが次々とソーシャルアプリに対応、市場も生まれ、まさにゴールドラッシュ。海外ではFacebook Connect、OpenID Connect、Distributed SocialWebなど、こちらも着々とソーシャルウェブの次のステップに向けて進んでいます。

翻って自分の今後の方向性を考えた時、今の立ち位置で本当にやりたいことをやれるのか、世間に影響を与えられる仕事をしていけるのか、疑問を持ち始めました。そんな時にもらったのがこの話です。

6月1日よりGoogleに転職します

ポジションはDeveloper Advocate。いわゆるエヴァンジェリストです。今後はChromeやHTML5の技術を普及する立場に身を置きます。

周囲の方から、なぜGoogleなのか？なぜソーシャルウェブ担当じゃないのか？必ず聞かれるので、備忘のためにもここで理由をまとめておきます。

• GoogleはOpenSocialをはじめとした、インターネットのオープン化、標準化を力強く進めてきた。


• Google API Expertとして関わってきた経験からも、その魅力に間違いはないと確信していた。


• 国際色豊かな企業なため、世界中のディベロッパーを相手にし、経験を積んで行くことができると考えた。


• HTML5とブラウザという、インターネットに関わる全ての人が知っておくべき基礎となる技術を、表舞台に立って啓蒙できる事を、エキサイティングであると感じた。


• ブラウザとソーシャルは今後、切っても切れない関係になって行く。その動きの一端を担う事ができると考えた。


• 20%ルールの中でソーシャルウェブに取り組むことを認めてもらえた。

他にも細かい理由は挙げればキリがないですが、この辺りが主なものです。今の自分にとって、文字通りこれ以上は存在しないであろう選択肢を取ることができたのは、実にラッキーだったと思っています。

運営コミュニティの今後について

これまで運営してきたコミュニティについても、簡単に触れておきます。

SocialWeb Japanについては、可能な限り今後も自分で運営を続けていきたいと考えています。まだ5回しか勉強会を開いていませんが、取り上げたいテーマは日々積み上がってきているので、ずっと気にしています。(スタッフを継続で募集しています。興味のある方は、ご連絡ください。)

Google Buzz API Japanについては、Hackathonなど開きたいところですが、時間的余裕ができるか分かりませんので、しばらく様子を見させてください。

OpenSocialのAPI Expertのポジションは、当然ですが卒業します。代わりに別の優秀な方を推薦しようと思っていますので、俺かな？と思った方は、楽しみにしていてください :)

ご存じない方が多いかもしれませんが、開発者のための英語学習コミュニティEIGOBUは、自分のためにも継続していくつもりです。

最後に

今まで僕の活動やわがままに付き合ってくれた前職のチームの皆さん、僕を支えてくれた家族に感謝したいと思います。

特に妻は、僕がバイトをしながら職業作曲家をやっていた時に婚約し、ウェブの世界に入って就職した後も会社買収・転職といった紆余曲折を一緒に乗り越え、子育ての最中にGoogle転職というひとつのマイルストーンに辿り着くまで、信じて支えてきてくれました。

これから何がどうなっていくのか、僕にもまだ分かりません。ただ、Googleで働くことが楽しみでしょうがなく、これが僕にとって、人生の最大のターニングポイントになるであろうことは間違いなさそうです。

今後も、日本のウェブをより良くするために貢献していければと思います。

北村　英志

gihyoにGoogle Buzzに関する記事を寄稿しました

先日GoogleからGoogle Buzzというサービスが公開されました。

いわゆるフィードアグリゲータで、見た目は日本で言えばGREEかgooホーム、海外で言えばFriendFeed、Cliqset、Facebook辺りが近いでしょうか。タイムライン上のエントリにコメント、お気に入りが付けられるという構成の、一見実にステレオタイプで、あまり個性のないサービスです。

特徴といえばGmail上で展開されていること、Google Profileでも表示されること、その他5つくらいステージで言われていました。僕もリアルタイムで中継を見ていたのですが、これを流行らせるのは難しいかもな、という印象。

しかし、同時に公開されたAPIドキュメントページを見て、Buzzが単なるフィードアグリゲーターサービスを狙ったものではないことを読み取りました。また、これがいかに野心的で壮大、かつ僕がこの3年以上夢に見てきた理想のサービス像の具体的な答えであることに気付き、興奮を抑えられませんでした。

「流行るか流行らないかは割とどうでもいい」とTwitterでつぶやいたのには、実は深い意味があります。それを解説するために書いた記事をgihyo.jpさんに掲載していただいたのがこちらです。

ソーシャルウェブテクノロジーに見るGoogle Buzzの本当の意味

ちょっと難しい話も含まれていますが、Google Buzzを使ってみて、流行るわけない、つまらない、という意見を持った方は、ぜひ一度読んでみてください。見る目が変わると思います。

Google Docsのストレージ化が持つ意味

日本時間で13日未明、SpreadsheetやDocs、Presentationなどのこれまでのフォーマットに加え、あらゆる形式のファイルが無料で1GBまで、1GB/$0.25/年で足せる、実質的なストレージ機能がGoogle Docsに追加されることが発表されました。

今回はクライアントソフトこそ発表されませんでしたが、既にAPIは公開されていますので、Google謹製であれ、他社製であれ、いずれはDropboxライクの強力なクライアントソフトが各種プラットフォームに登場することは間違いないと思います。楽しみですね。

ところでこのGDriveとも言うべきGoogle Docsストレージ、ソーシャルウェブにとってものすごく重要な意味がありそうです。

ソーシャルウェブとアクセスコントロール

僕は以前からウェブはOSの役割を果すようになり、ソーシャルウェブはその一躍を担うと主張してきました。ソーシャルウェブに関する持論はいくつかあります。

• ソーシャルウェブはいずれ、意識する必要がないほど当たり前の存在になる


• あらゆるサービスで利用できるアイデンティティが必要となる


• ソーシャルグラフはアイデンティティと紐付けて持ちまわることができるようになる


• ソーシャルグラフは携帯電話やテレビ、家電製品でも利用可能になる


• ソーシャルグラフは共有や招待に加え、アクセス管理にも用いられるようになる


• いずれはファイルシステムもソーシャルグラフを用いたACL機能を持つ

このうち、最後のACLについては、OSレベルの話なのでまだまだ先だとばかり思っていたのですが、、、

Google Docsの持つACL機能

実は今回のGoogle Docsストレージには、このソーシャルグラフを用いた強力なACL機能が備わっているようです。Google Docsを使っている方はよくご存知と思いますが、それはもともとGoogle Docs自体がアクセス管理機能を持っていたからに他なりません。



Google Docsでは、ファイルを作成すると、基本はプライベート、そこから操作で一般公開、グループへの公開、メールアドレスを指定して共有、などをすることができます。メールアドレスで指定する際はもちろん、Googleが誇るGmailのコンタクトリストというソーシャルグラフからオートコンプリートすることができます。各共有相手ごとに、閲覧・編集のアクセス権を分けることもできます。

この強力なアクセス管理機能が、Google Docsストレージに保存された画像や音楽、映像など、他の種類のファイルにも適用され、自分のローカルフォルダで管理できるとしたらどうでしょう？ファイルは常にクラウドと同期し、アクセス権は世界中のアイデンティティを相手に管理できる世界・・・便利だとは思いませんか？

これぞまさに、ウェブOSの世界だと思うのです。

まとめ

よくGoogleはSNSを持っていないから、、というような論調を見かけますが、それはあくまでアプリケーションプラットフォームとしての話でしかありません。今回のGoogle Docsストレージを例にとっても、Googleはそれを上回るウェブOSプラットフォームを着々と築き上げつつあるようです。

今後これらのサービスにChrome OSが加わり、GoogleのウェブOSはさらに強力なものになっていくでしょう。いずれFacebookやTwitterも、所詮はGoogleの手のひらの上、という状況になってしまう日が来るかもしれません。

Google Developer Day 2009の動画が公開されました

先日行われたGoogle Developer Day 2009の動画が公開されてます。基調講演に一瞬と、パネルディスカッションに登壇した動画もありますので、よろしければご覧下さい。

基調講演 vol.4 OpenSocial

OpenSocial パネルディスカッション

Google Developer Day 2009

6月9日にパシフィコ横浜にてGoogle Developer Dayが開催されました。
僕は基調講演に一瞬と、OpenSocial Panel Discussionのセッションに登壇させて頂きました。

基調講演デモ

基調講演では、先日一般ユーザー向けにも公開したgooホームのOpenSocialを使って、goo地図ガジェットとフォトビューアーガジェットがPhotomemoのガジェットに連動して動く、というソーシャルウェブ・ポータルというコンセプトを打ち出したgooホームならではのデモをお披露目しました。基調講演では言いそびれてしまったのですが、このアイディアは元々、先日行われたHackathonでディベロッパーの1チームが見せてくれたものを元にしています。

実装としては、OpenSocialに含まれるpubsubというフィーチャーを使っています。pubsubは、任意に作成されたチャンネルに対してオブジェクトをpublishすると、同じチャンネルをsubscribeしているガジェットのコールバック関数が呼ばれオブジェクトが届く、というかなり単純な仕組みです。pubsubについては、近いうちにgoo Developer's Kitchenの方にもドキュメントを追加します。

また、今回のデモを行うため、PhotomemoチームにPhotomemoガジェットとフォトビューアーガジェットを開発して頂きました。ご協力ありがとうございました。

OpenSocial Panel Discussion

もうひとつ参加させて頂いたのがPanel Discussionでした。今回は先日のデブサミでもご一緒させて頂いたリクルートの川崎さんに加え、mixiの川岸さん、そしてGoogleの及川さんとのディスカッションになりました。

内容については、OpenSocialというよりはSocialWebを広い観点で捉え、その中で現状使えるOpenSocialというピース、およびこれから広がっていくSocialWebの世界に関して。僕の中でもmixiアプリとgooホームガジェットの目指す所がまるっきり違うことに気付いたのは割と最近なので、その辺りが分かりやすく伝わるようにお話しさせて頂きました。

まとめ

Panel Discussionの場でも言いましたが、日本のSocialWebという世界観にまだまだ伸びしろがあると感じています。海外に比べると実名が好まれなかったり、最大のSNSがクローズドだったりと、海外のそれを単純に輸入できないことは十分理解していますが、必ず近いうちに求めらる技術になっていくと思います。

共感された方はぜひ、SocialWeb Japanにご参加下さい。

Google FriendConnectについてgihyo.jpに寄稿しました

Google FriendConnect対応ガジェットが完成

FriendConnectのメンバーが友達を紹介し合う文章が書けるFriend Introducerというガジェットを公開しました。このブログの画面左側に表示していますので、メンバーになってくれている方はぜひ、遊んでみてください。(なっていない方はメンバーになって遊んでください！)

FriendIntroducerとは

主に3つのビューが存在します。1つはブログ上で表示されるprofileビュー。



FriendConnectメンバーの紹介文を最大5件表示します。ページングが可能で、それぞれのメンバーに書かれた紹介文がランダムで表示されます。

メンバーのサムネイル画像をクリックするとdetailビュー(OpenSocial的なビューではないですけどね)に切り替わります。(※誤解を招きそうなので修正。detailビューは僕が勝手にそう呼んでいるだけで、OpenSocial的にはprofileビューです。)



一人に対して複数の人が紹介文を書いている場合がありますので、detailビューでは、その人に関する紹介文をすべて閲覧することができます。

ガジェット上部のボタンをクリックするとcanvasビューに切り替わります。



canvasビューでは、ログインユーザーの友達の紹介文を書くことができます。友達がいない方は、同じFriendConnect上の誰かを友達に加えてください。

FriendIntroducerをブログに貼付けるには

まずはこちらでFriendConnectに登録してください。サイト登録済みの状態で・・・



Social gadgetsをクリックします。



一番下にあるCustom gadgetリンクをクリックします。



Gadget URLをhttp://devlab.agektmr.com/OpenSocial/FriendConnect/FriendIntroducer.xmlとしてください。

ガジェットの横幅を調整し、Generate CodeをクリックするとHTMLコードが出力されますので、これをブログ等に貼付けます。

所感

以前のエントリにも書きましたが、FriendConnectガジェット作成のミソは：

• OWNERはブログという仮想人格


• requestNavigateToでcanvasビューとprofileビューを行き来できる


• canvasビューのバックグラウンドは、サイト作成時に取り込んだcanvas.htmlをいじることで変更可能

といったところでしょうか。

今のところOpenSocialにコミュニティ的な考えはないのですが、FriendConnectはちょっとひねったコミュニティ的な応用、と思うと分かりやすいかもしれません。

また、FriendConnectの面白いところは、複数のSNSからインポートした友達リストをマージして利用できることです。例えば僕はorkut、Google、Plaxo、Twitterをインポートしていますが、同じブログに登録している人がこれらのSNS上で友達であれば、FriendConnect上でも友達になります。

いつかGoogleがiGoogleをSNS化する際、これらの友達リストがそのまま利用できるようになるかもしれませんね。

FriendConnect実験中

本ブログ左サイドバーの下の方に、Friend Introducerという以前作ったOpenSocialガジェットをFriendConnect用に若干修正して追加してみました(2008/12/9時点)。



元々このガジェットは、キャンバスビューで自分の友達の紹介文を書き、プロフィールビューでその人に書かれた紹介文が読める、というものでした。Orkutやhi5等のsandboxで試していたものです。

しかし今回FriendConnectでガジェットを試して明確に分かったことがいくつか。

• ブログは1面しかありません。そのためビューはprofileまたはcanvasから選択。FriendConnectのSocialGadget設定画面で決めることができます。


• friendconnectフィーチャーというものがあるようです。具体的に何をするものなのかは不明。


• Ownerはサイト。そういえば、FriendConnectガジェットを入れた時点では、自動的に自分がメンバーになったりはしていませんでした。Ownerは貼付けたサイトという仮想人格が担うようです。

ビューに関しては、profileビューにするとサイトがOwnerとして表示されるので、よくわからない状態。APIでプロフィールを取得するとどうなるかは未検証です。現在はcanvasビューで表示していますが、おかげさまで自分で自分の友達の紹介文を書くだけで、誰にも見せられないというしょーもないガジェットになっています(--;。

そういえば他のFriendConnectガジェットは右上にキャンバスビューに移行するボタンがありますね。どうやってこれを使うことができるんでしょう？時間があるときにでも追いかけてみたいと思います。

Google FriendConnect一般公開

事前にプレビューを申し込んでいた人にはインビテーションが配布され始めたようです。

早速このブログの左側にも貼ってます。Join!してみてくださいね。

iGoogleの進化に見るGoogleのソーシャル化

iGoogleはこれまで複数のガジェットを1ページに表示するスタイルでしたが、最近「canvasビュー」が追加され、1つのガジェットを画面いっぱいに表示して利用できるようになったことは記憶に新しいと思います。canvasビューを使うことで、特にGmailやGoogle Readerのガジェットでは、単体サービスのかなりの機能がガジェット上でそのまま利用できるようになり、大幅に利便性が向上しました。





このiGoogleの変化は、既に明言されてはいますが、iGoogleのOpenSocial対応を予感させ、将来的にGoogle全体がソーシャルネットワークになっていくことを示唆しています。実は既にGoogleがそれ自体をソーシャルネットワーク化していく方向性は随所に見られます。

Googleのソーシャル化

Gmail連絡先(コンタクトリスト)

ソーシャルネットワークを形作る上で最も重要になるソーシャルグラフを、GoogleはGmail/Google Talkに持ってきました。当然と言えば当然。この連絡先(コンタクトリスト)はAndroidケータイ上にもインポートされ、電話帳としても利用されており、いやでもリアルなソーシャルグラフになる点が特徴と言えます。

Google Mapsプロフィール

最近プライバシー問題で話題のGoogle Mapsには実はプロフィール機能がついており、画面上部の「プロフィール」リンクをクリックすると、自分のプロフィールを作成/表示することができます。これは後述のGoogleプロフィールと連携しています。

Google Readerの共有機能

Google ReaderはRSSリーダーですが、気になった記事をボタン一つで友達に共有できる機能があります。その際利用されるのがGmailの持つ連絡先のソーシャルグラフで、ここでも活用されています。

Googleプロフィール

いつのまにか、ひっそりと作られた感のあるのがGoogleプロフィール。これが今後どう充実して行くかは要注目です。



画面左上にユーザーの写真とニックネーム、住所が表示され、その下にはプロフィールの詳細情報が表示されます。今のところ住所や過去に住んだことのある場所、通った学校、勤めた会社、略歴に加え、Googleを使っても見つけられないもの、超能力(?)など一風変わった項目もあり、この画面から編集を行うことができます。



そして「リンク」。今のところ本当にただのリンクですが、利用している外部サービスを登録することができます。面白いのは、例えばFriendFeedを登録すると、自動的に他のサービスも登録候補にずらずらっと表示されるところ。なるほど、ここでGoogle Social Graph APIを活用しているようです。確かに、FriendFeedにはrel="me"といったmicroformatが埋め込まれています。

メッセージ機能

Googleプロフィールに最近メッセージ機能が追加されました。英語版でしか存在を確認することはできませんが、プロフィールページからメッセージを送ることができるようです。これもOpenSocial対応を意識したものでしょう。

Googleは今後どう変わって行くのか

Googleがソーシャル化していく上で、今後どのような部分に変化が見られるのか予想してみました。

Googleプロフィールにガジェット

まず間違いなく、Googleプロフィールにもガジェットが追加できるようになるでしょう。

OpenSocialにはhomeビュー、canvasビュー、profileビュー、previewビューの4つがあらかじめ定義されていますが、ガジェット追加確認用のpreviewビューを除けば、一般的なSNSにおけるマイページ(homeビュー)、ガジェットのみを表示するcanvasビューが既にiGoogleで用意されているので、残りはプロフィールページ(profileビュー)となるのは自然な流れと言えます。

GoogleプロフィールのiGoogle統合

GoogleプロフィールとiGoogleの統合はあり得ない話ではありません。今もiGoogleのSandbox環境では自分のGoogleプロフィールの内容を確認することができますが、例えば簡単に画面遷移ができたりすることで、他者との距離を近づけ、iGoogleがソーシャルなものであることを意識できるようになるかもしれません。

アクティビティストリーム

iGoogleのSandboxでは既に片鱗が見えますが、OpenSocialのアクティビティストリームという機能がもう少し明確に、姿を現すはずです。アクティビティストリームとは、ユーザーの行動履歴のようなもので、mixiで言えば友達の日記やコミュニティの最新情報に当たります。

OpenSocialではガジェットからアクティビティを登録する機能が規定されていますが、iGoogleではこれに加えてリンクしたサービスのフィードも自動的に混ざる、FriendFeedライクな機能を追加してくるのではないでしょうか。MicrosoftがWindows Live Homeで追加した機能にも同様のものがあります。

まとめ

Googleプロフィールをネタに記事を書き始めたのですが、なんだかんだ話が広がり、結構大きい話になってしまいました。しかしGmailを中心として着実に、潜在的にソーシャルグラフを広げているGoogleが、完全なソーシャルネットワークの形態をとった時にどれほどの影響力を持ったものになるのか、正直想像もつきません。果たしてGmailを作った時点でここまで考えていたのか？今後の動向から目が離せません。

FriendConnectから垣間見える未来のソーシャルウェブ

今更ですが、先日サンフランシスコで開かれたGoogle I/Oに参加してきました。

その中でも特に印象に残ったのが、PlaxoのJoseph Smarr氏によるOpenSocial, OpenID, and OAuth: Oh My!というセッション。僕が見たセッションの中ではダントツの人気で、部屋に用意された椅子はもちろん、立ち見で人が溢れ返るほどの盛況ぶり。

内容は、ソーシャルウェブの未来について。現在はOpenSocialというソーシャルグラフを所有するサービスに閉じた世界が中心となりつつありますが、少し未来のウェブはOpenSocial, OpenID, OAuth, PortableContacts等の技術によって、よりグローバルな意味でのソーシャル化が図れるようになる、というものです。

詳細はGoogle Codeにビデオとスライドがアップされていますので、ご覧ください。かなり早口ですが、大変面白い内容です。

OpenSocialとFriendConnectの持つ意味

OpenSocialにはv0.7まで、JavaScriptのAPIしか存在していませんでした。これはOpenSocialコンテナにとっては外部サービスからガジェットとしてアプリケーションを追加してもらい、そのOpenSocialコンテナが持つソーシャルグラフに閉じた形で利用されるものでした。アプリケーション開発者はOpenSocialのJavaScript APIを使い、ガジェットが置かれているコンテナサイトの友達リストを取得し、そこでアプリケーションを動かすことができます。もちろん、ガジェットを自分のサービスドメイン上でホスティングすることも可能ですが、ガジェットはコンテナ上でしか動作せず、友達リストを外部サービスとしてインポートしたりといったことも不可能で、実質的に囲い込みサービスしか生まれないものと言えたでしょう。

それがOpenSocial v0.8 + FriendConnectによって一気に世界を広げます。ユーザーはFriendConnect対応サイトを利用するに当たり、OAuthを使って自分が利用したいSNSサービスを選ぶ権利が与えられています。同時に、そのサイト上での活動内容は連携を選択したSNSサービスに戻されます。

ここでソーシャルサービスの要素を思い出してください。

1. アイデンティティ


2. ソーシャルグラフ(友達リスト)


3. エントリの公開範囲の制御(プライバシー)


4. フィード

FriendConnectはアイデンティティをOpenIDで、ソーシャルグラフをOpenSocial v0.8のRESTful APIで、エントリの公開範囲の制御をOAuthで、フィードをActivity Streamで解決しようとしています。

これらの意味するところを深く見つめて行くと、未来のソーシャルウェブが自ずと見えてきます。

Joseph Smarr氏(Plaxo)による未来のソーシャルウェブ論

FriendConnectのイメージをさらに深めるため、Joseph Smarr氏が、PlaxoのFriendConnect対応に際してアップしていたブログエントリをご紹介します。

Plaxo and FriendConnect are now Best Friends

Plaxoが完全にFriendConnectと連携した。FriendConnectとは、あらゆるサイトをソーシャル化する、Googleによるウィジェットベースのツールである。これにより、FriendConnectに対応していれば、どんなサイトでもPlaxoアカウントに安全に接続し、サイト上に自分の友達がいるかを確認したり、友達を招待したりといったことができるようになる。何よりも素晴らしいのは、そのサイトでの活動内容をPulseに流し込むことができるようになり、Plaxoでの友達がウェブを跨いであなたと連絡を取り合うことができ、あなたが発見した新しいサイトを知ることができる点だ。

これは本当に便利でわくわくする連携機能だ -- これはユーザーが自分のアイデンティティと関係をウェブ上のどこでも利用できるようにし、新しいサイトで知人を見つけ出し、活動内容を既存の友達に共有し、よりソーシャルな発見と共有という徳の高いサイクルを生み出す、シームレスソーシャルウェブエコシステムにさらに近付いたと言える。これこそソーシャルウェブの進むべき道だ -- (現在あるほとんどのサービスがそうだが)新しいソーシャルサイトを使い始める度に最初からやり直さなければならないなんてとんでもない。あなたの新しい体験全てが、他の人をも魅了すべきだ。

これはサービスがユーザーに自分の持つデータの制御を与え、オープンスタンダードを使って安全なアクセス権を提供することによってのみ成り立つ。そしてこれこそまさに、PlaxoがFriendConnectを使ってやりたかったことだ。Plaxoアカウントを接続する際、我々はOAuthを使う。そのため、Plaxoのパスワードを渡す必要もないし、後で接続を断つことも可能だ。FriendConnectを使ってあなたが活動内容をPulseに共有する際は、OpenSocial 0.8 RESTful Activities APIを利用する。オープンスタンダードではない連携はアドレス帳APIのみであり、我々はこのスタンダードについても取り組みを開始している。我々はアイデンティティプロバイダとして、ソーシャルグラフプロバイダとして、そしてコンテンツアグリゲータとしての役割を果たしていると強く信じている -- つまり、我々はユーザーが自身のデータと関係性をウェブ上のどこにでも持ち回り、どこからでも共有できるようにしている -- これはユーザーにとっても、Plaxoにとっても、ウェブ全体にとっても有益なことだ。だが、まだこの取り組みは始まったばかり -- FriendConnect対応サイトから活動内容を共有する際、家族や友達、仕事関係など、共有相手をより細かい粒度で制御するなどの、更なる拡張を楽しみにしていて欲しい。

下のスクリーンショットはPlaxoとGoogle FriendConnectの連携したものだ -- FriendConnectを利用しているサイトでも体験してもらうことができる。

画像は実際のページをご覧下さい。

まとめ

ガジェットコンテナとしてのOpenSocialには正直、懐疑的な部分があったのですが、FriendConnectの描く未来を想像し、またわくわくしています。今後もこの辺りの動向を追って行きます。

追記

似たような話題に触れた記事を見つけたので追記し、トラバっておく。(失敗したので断念○|￣|＿)

グーグルが見たソーシャルネットワーキング--その3つの傾向:スペシャルレポート - CNET Japan

ついにiGoogleがOpenSocial対応へ

今日から、OpenSocial機能提供に向け、iGoogleでsandboxの利用が可能になりました。これは明白に、Google自身がソーシャルネットワークを基盤とした仕組みになっていくことを意味しています。以前Maka-Makaと呼ばれるプロジェクトが存在し、Google独自のSNSサービスが始まるという話題がありましたが、それがOpenSocialというオープンな形を取り、予想していたとはいえ、iGoogleという形で現実のものにされると、さすが、としか言いようがありません。

で、早速試してみました。

まずはサインアップ。こちらからできます。(言語設定は英語にしておかないと、サインアップしてもsandboxが利用できないようです。)



http://code.google.com/apis/igoogle/docs/anatomy.html

これが新しいiGoogleの画面。



画面左にあるのがインストールしたアプリケーション/ガジェット。これをクリックするとキャンバスビューが開きます。



画面右側にはUpdateとしてアクティビティストリーム(行動履歴)が表示されるとのことですが、まだ確認できていません。SNSですから、友達リストがあってもおかしくないのですが、sandboxでは友達なしの状態からスタートし、sandboxに登録しているユーザー同士でなければ友達になれないとのこと。どうやって友達になれるかは、まだ不明。実際のサービス時はGoogle Talk/Gmailのアドレス帳からスタートすることは容易に想像できます。

また他にも、ガジェットごとの設定項目の表示方法が変更されているようです。

で、せっかくのsandboxですから、早速以前作ったFriendIntroducerを試してみました。OpenSocialとはいえ、コンテナごとにビュー名は若干違うよね、ということで、ガジェットXMLにhomeビューを追記し、Developerガジェットから追加。



んー。友達がいないので、当然こういう表示になってしまいますが、動いていることは確認できました。やはりそこはOpenSocial。

まとめ

あくまで基盤とはいえ、Googleは本当に恐ろしい存在です。すべてのウェブサービスを飲み込めるくらい、地を這ってる。auやlivedoorのGmailしかり、Google App Engineしかり。何でもかんでもGoogleに乗っけてしまえってくらい。

そしてGoogleにはAndroidもあります。そう、携帯電話のアドレス帳もこの友達リストに接続できるようになるでしょう。そうすると、友達のブログ更新をメールで受け取ったり、そのままケータイで閲覧したりといったことがユーザーに何のストレスも与えずに可能になります。

あと足りないのはプロフィールビューでしょうか。Google MapやGoogle Groupsで部分的に実現されてはいますが、これがどういう形で結実していくか、見物です。