APIで未来のConnected carを創れ！API Days San Franciscoハッカソン

「API Days San Francisco 2014」は「API で未来の Connected car を創る」ことをテーマにしたカンファレンスです。Google や Apple といったシリコンバレーの企業が次々と Connected car 向けの API を公開し始めたことで、今や誰もが標準的な Web やモバイルの技術を使って Connected car のアプリを開発できる時代になりつつあります。このような大きな時代の転換期に開催された、本ハッカソンでは API 提供企業と開発者がお互いに知恵を絞りあって、アプリ開発が行われました。
本記事では、筆者がハッカソンに参加した際の模様や、カンファレンスの背景となっている技術トレンドを中心にご紹介いたします。なお、本「シリコンバレー滞在記 2014」シリーズでは、筆者がサンフランシスコ駐在中に経験したことや現地でのイベントの模様を中心にお伝えしています。合わせて他記事もご覧ください。

API Days San Franciscoとは

「API Days」は、「API で未来の ソフトウェアを創る」をテーマにしたイベントです。スポンサー企業による講演・展示だけでなく、実際にハッカソンでのプロトタイプを通じてアイディアの実現を目指します。対象とテーマは、その時の技術トレンドなどを考慮して開催ごとに設定されています。例えば、2013 年パリにて開催された第 1 回のテーマは「Internet of Things」、2014年6月13日に開催された今回のテーマは「Connected car」です。

私自身は現在「Connected car」に関係する業務に携わっているわけではありませんが、サンフランシスコに赴任する前は組み込みソフトウェア開発に携わっており、車載オーディオ機器開発に携わった経験があります。アプリケーションを開発する対象の 1 つとして自動車にも関心は持っていました。そして、次々と Connected car 向けの API が公開される中、現在の技術トレンドを知りたいと考えていました。また、以前から具体的な課題を通じてモバイル・Web・クラウドといった技術を習得することを検討していたため、その両者が重なる今回のイベントへ参加するに至りました。今回参加にあたっては新しい技術を 1 つ習得することを参加の目標に掲げました。

今 Connected car の API が注目されている背景

イベントの内容に立ち入る前に本イベント開催の背景となっている「API Economy」と「Connected car」という2つのトレンドをご紹介します。

API Economy

現在、ベイエリアでは「API Days San Francisco」の他にも API をテーマにしたカンファレンスが多数開催されています。その背景としては、日本の Web メディアでも取り上げられている「API Economy」というトレンドがあります。

現在、多くの企業がより新しい価値のあるサービス構築を目指して、多数の Web API を公開し、第 3 者企業とサービス連携を行っています。「API Economy」とは、このように API を中心として新たな経済圏が構築されている現在の状況を指します。API 公開によってサービスの応用範囲や収益性が向上する点は、Google、Twitter、Facebookといった企業によって証明されており、すでに多くの企業にとっては API を公開することは当たり前になっています。現在は、いかにより魅力的で使いやすい API および SDK を開発者に提供し、新しいアプリ・サービスを開発してもらうことで、自社サービスの競争力を確保するかを競っています。 また、各社がAPIを公開する事例が増えてきたことで、API 公開を支援するテストツール・管理ツールを提供する企業も増え、API が大きな市場になりつつあります。

例えば、以下は、今回のハッカソンで API を提供していたスポンサー企業の一例です。

Connected Car

もう 1 つのテーマである「Connected car」は自動車が常時インターネット接続することで、付加価値の高い運転体験を提供するサービス分野です。アメリカは自動車社会であり、多くの人が通勤に多くの時間を割いています。そのため、成熟しつつある従来のモバイルや Web に続いて、運転中に利用できるサービスから収益を得ようと、ベイエリアの多くの企業が Connected car 向けのサービスを提供しようとしています。Web やモバイルといった成熟市場を主戦場にしていた Google や Apple といった大手テック企業も参入を発表しました。

例えば、今回のカンファレンスで特に Connected Car に密接に関係するデモを行っていた企業としては以下のようなものがありました。

ハッカソンの流れ

ここからは実際にハッカソンでどういう活動が行われているのかをご紹介します。以下は、API Days San Francisco でのスケジュールですが、他のハッカソンでも同じようなプログラムで進行されています。

スポンサーにとってのハッカソン開催のメリット

スポンサー企業にとっての本イベントの開催目的は、自社 API を活用した新しいアイディアを生み出してもらうことで、自社のビジネスを活性化することにあります。そのため、各スポンサー企業からはチュートリアルやワークショップを通じて API の売り込みがあります。

参加者にとってのハッカソン参加のメリット

一方で、参加者側の目的は様々であり、以下のような理由で参加している人を見かけます。

• 技術習得の機会（筆者と同じ）
• 新しいトレンドを知る
• ネットワーキング
  • 転職先探し
  • スタートアップの仲間探し
• 新しい事業アイディアをアピールする

新しい事業アイディアをアピールしたい場合は、ピッチの場がアイディアを知ってもらう絶好の機会になりますし、実際にプロトタイピングすることでアイディアを洗練することもできます。また、ネットワーキングや転職先探しに参加している人にとっては、一緒にプロトタイピングをすることで、一緒に作業をし、スキルや相性を見極められた関係の深いネットワークを形成する絶好の機会となります。

実際に、私と同じテーブルで作業していた参加者同士が「最近、スタートアップを始めて、今、フロントエンドエンジニアを探しているんだけど、うちに来ない？」とハッカソン中にスカウトしている例も見かけました。面接をするより一緒に仕事する方が本人のスキルや相性を見極めることができるため、人材獲得には良い機会だと言えます。

自分のチームの取り組み〜駐車場の空き情報交換アプリの開発〜

ここからは筆者のチームの取り組みについてご紹介します。

チーム形成：インド人研究者と 2 人チームを結成

私自身は、一人で参加したため、開場後すぐに色々な人と世間話をして、一緒にチームを組めそうな相手を探してみました。アイディアピッチがひと通り終わり、いざチームメンバを探して30分ほど歩き回りましたが、すでにアイディアとメンバは決まっている人、別のチームに参加する人が多く、なかなか仲間を探せない状況が続きました。「やはりハッカソンのメンバーは事前に見つけておくべきだったか」と半ばチーム形成を諦めかけていました。

その時、筆者（写真・右）と同じくハッカソン初参加で、一人で参加しているというインド人のラマさん（写真・左）が一緒にチームを組めないかと話しかけてきました。私も一人だったので、即決で合意しました。ラマさん自身は、大手自動車メーカーで IoT や Connected car といった分野の研究をしていた方で、現在は前職を退職済み、就職活動の傍ら、新しい事業分野のアイディアを検討するため、ハッカソンに参加したとのことでした。

アイディアの検討：自動車の走行記録を活用した駐車場の空きスペース情報交換アプリに決定！

チームが決まった後、そのままアイディアの検討に入りましたが、メンバ二人とも具体的なサービスのアイディアを持ち込んできたわけではありませんでした。そのため、最終的な開発対象のサービスを決める段階が一番苦労しました。午後8時頃からアイディア出しを始め、案が3つほど出た後、ディスカッションを通じて最終的な案が決まったのは深夜 1 時を回ったところでした。

検討の際には、以下の表の通り、基本方針を 3 つを挙げ、方針ごとにブレインストーミングをして、開発対象のサービスのアイディアを出し、出したアイディアをまとめあげて、最終的なサービスの案にまとめていきました。

今回は、事前にスポンサー API の下調べやサービスの案出しができていなかったので、最終的なサービス案を決める上では、本当に技術的に実現可能なのかすぐには判断できませんでした。API のドキュメントを読んだり、簡単なサンプルを作って、うまくいきそうだと感触が得られた段階ですでに日付が変わっていました。

まず最初にチームメイトのラマさんから「自動車と実際に連携するアプリは未開拓分野でイノベーションの余地がある」という意見（上記表の（1））があり、イベントスポンサーのうち、自動車にガジェットを差し込み、走行記録を収集・サーバに蓄積するサービス Automatic をメインに活用するというアイディアは決まりました。Automatic は運転記録の API を公開しているので、データを取得・分析して、自分のサービスに活かせば、スポンサーの API を有効活用しているということで、評価対象になります（上記表の（2））。

2 人とも技術者ということもあって、このように技術シードをベースにしてサービスの技術要素を検討し、最後に技術要素に合う形のサービスを検討し始めました。最終的な開発対象のサービスを検討する段階では、「明確なアイディアを持ち込めていなかったので、これから凝ったアイディアを練り上げるのは難しいだろう」という意見が一致し、「身近なテーマをベースに考えよう」という話になりました（上記表の（3））。

その際、サンフランシスコに遊びに来る友達が駐車場の空きスペースを見つけられず、よく困っている様を思い出したため、駐車場の空き情報を共有できるアプリはどうかと提案しました。サンフランシスコ郊外は日本の都市部と比較して電車が発達しておらず、基本的に自動車でサンフランシスコ市内を訪問する方は多くいます。一方で、駐車場の供給が足りておらず、特にダウンタウン周辺を訪れる場合、空きスペースを探して、数十分彷徨うことすらあります。もし、駐車場に車を停めている人から、同じ地区の駐車場を探している人へ空き情報を迅速にシェアできれば、駐車場の空きを探す手間が省けます。

さらに、同様のアプリはすでに公開されているため、従来のアプリとの差別化要素として、Automatic の API から取得した自動車の運転記録を分析して、安全運転の度合いを「ドライブスコア」として点数化することを考えました。さらに、ドライブスコアが高いドライバに優先的に空き情報を提供するようにすることを考えました。これにより、以下の通り、ドライバと Automatic の両者にとってメリットが出せると考えました。

• 安全運転者ほど優先されるため、ドライバにとって安全運転のモチベーションが高まり、事故の可能性が軽減します。
• Automatic にとっては本アプリが自社の API 活用方法として対外的にアピールできます。

ハック：Backend as a service を活用して素早く Android アプリのプロトタイプを開発

おおまかにアイディアが決まった段階で、実装方法の検討に入りました。

チームメンバ二人とも現在メインで使っている言語が Java、モバイル・アプリの開発経験は浅いということで、クライアントは Java で開発できる Android を採用しました。

さらに、前節で紹介した通り、駐車場の空きスペースを共有するアプリを開発するため、ユーザ間で情報交換する機能をサーバ側で提供する必要があります。こういった機能を AWS や Heroku といった PaaS 上にスクラッチで構築しようとするとプロトタイプの本質的な部分以外の実装に時間がかかってしまいます。そこで、チームメイトのラマさんから、「あらかじめモバイルのバックエンドに必要な機能を提供してくれる BaaS ( Backend as a service ） というサービス群を使った方が良い」とのアドバイスを受け、BaaS の中でも機能が揃っており、ドキュメントやサンプルが豊富に用意されている Parse を選択し、開発を始めました。

左記の図は、最終的なプレゼンで使ったサービスの大まかなアーキテクチャです。

自動車の位置情報・運転記録・車体情報は自動的に Automatic のサーバに蓄積されます。

駐車情報の空き情報を交換できるようにするには、Automatic の情報およびユーザから提供された情報を組み合わせて、ユーザの要求に答える必要があります。この部分は、Parse 上に独自のバックエンドサービスとして実装しました（左記図の右下）。

今回は、Parse の SDK および Parse 上に独自の REST API を構築して主に以下の機能実装を目指しました。あらかじめ機能がParse上に用意されているため、実装する量は最小限で済みました。

ここで、2人のユーザがサンフランシスコ市立図書館を訪問した際に、駐車場を融通しあうシナリオを例に、ユーザがアプリから受けるメリット、および機能実現に使った技術について紹介します。

なお、チームメンバーがまだ慣れていない環境でプロトタイプ開発をするため、時間を節約するため、デモをする上で重要ではない部分は省略またはダミーデータの利用で代替する方針を取りました。具体的には、以下のような対策を取りました。

• ユーザ認証部分はデモでは不要のため実装していません。
• Parse と Automatic 間の連携はデモで実際に見せる必要はないため、Automatic のデータを JSON 形式で Parse に取り込むことで、サービス間連携をせずに、Parse 内のクエリで Automatic のデータを処理できるようにしました。

ピッチ：英語でのプレゼンに緊張するも、多数の質問・コメントに感激

イベントの最後にはプロトタイプを開発したサービスを参加者に説明する「ピッチ」の時間があります。今回、最終的にプレゼンで作った資料は SlideShare にアップロードしていますので、参照ください。

せっかくの英語で発表する機会ということで、プレゼン資料作成と発表は筆者が担当しました。発表においては、以下に気をつけて発表を行いました。

• ゆっくりと明瞭に話す。
• 分かりやすい論理構成で話す。
• 似たサービスとの差別化要素を明示し、自分のアプリの優位性を示す。
  • ここでは、SFPark というダウンタウンを中心に駐車場サービスを展開 している企業の事例を紹介しています。SFPark は個々の駐車スペースにセンサを設置し、利用状況を Web やモバイルで閲覧できるようにしていています。情報が正確である一方、SFPark が管理している場所の情報しか閲覧できない制約があります。
• 審査員が審査しやすいように、使っている技術を明示する（特にどのスポンサーのAPI を使っているか）。

発表最後に質疑の時間に入りました。もし、何も質問が出なかったらどうしようかと緊張しましたが、さすがアメリカです。質疑応答でもどんどん手が上がり、以下のようなアイディアを改善するためのフィードバックを多数いただきました。この反応の良さは、プレゼンをする側にとっても非常にうれしいことでした。

• （質問）GPSから得た位置情報は正確ではない。特にダウンタウン中心部でGPSの位置情報だけで駐車場を見つけるのは困難ではないか？
• （回答）ユーザに住所など詳細情報を入力してもらう必要がある。入力すると駐車場が見つけやすくなるなど何らかのインセンティブが必要かもしれない。
• （コメント）Automatic ならではなリアルタイムの走行データを活用する案があると良さそう。
• （コメント）SFPark 以外にも駐車場を融通し合うアプリは山のように存在するので、他のアプリとの差別化も考えてみると良いと思う。

表彰〜入賞は逃すも審査員特別賞は受賞〜

ピッチが終わると、しばらくの休憩時間の後、表彰に入りました。上位入賞者および筆者のチームの結果についてお伝えします。

1位 チーム Eagle 自動車向けの音声認識およびジェスチャー認識

1位のチームは、「Eagle」という名の個人で結成されたチームです。開発したサービスは、音声認識やジェスチャー認識を自動車用アプリ向けに応用するという内容でした。近年、運転手が運転中にスマートフォンを閲覧して注意散漫になってしまい、自動車事故が発生するケースが増えているとのことで、その状況を改善するため、以下をプロトタイプとして実装したそうです。

• 自動車のヘッドユニットにスマートフォンを接続。
• ヘッドユニット上のモバイルアプリに対して、音声認識やジェスチャー認識によるコマンドで操作できるようにした。（例）地図上でナビゲーションを表示する場合、声で「Navigation from San Francisco to San Jose」と話す、など。

このアイディアそのものは、Google Glass や Android Auto などでも取り入れられており、新しいアイディアではありませんが、プレゼンの導入部分やデモの分かりやすさ・完成度が評価されたようでした。デモでは、会場のプレゼン担当者と自動車に乗り込んだドライバの間で、テレビ会議を行い、自動車内での音声認識を利用してドアを開閉するデモを会場に中継する場面がありました。実際にアプリで自動車を動かせている様に会場からは歓声が上がりました。

2位 Drivemode コンテキスト認識技術による運転中のドライバへの情報提供

2位のチームは、Drivemode という日本人が創業したスタートアップが獲得しました。

本チームのアプリは、Context.IO というメールをモバイルアプリに統合する API を活用し、運転中にメールで届いた重要な外部のコンテキストを運転手に絵や音声で伝えるという内容でした。

具体的な活用例として、運転中に奥さんから送られてきたメールの内容から奥さんの機嫌を推測して、適切な応答を自動的にするというものでした。デモ中では、奥さんがかんかんに怒っていることをアプリが推測し、自動的に「I love you」とツイートするかなり実用的でバカバカしいデモに会場は大爆笑。やはりこれだけ受けているのを見ると、プレゼンにユーモアは大事だと痛感しました (^^;

筆者のチームは審査員特別賞を受賞！

最後に筆者のチームの結果ですが、残念ながら入手は逃したものの、API を活用した Automatic 社からは賞品（ガジェット、Tシャツ）、審査員からは特別賞として賞金を獲得しました。サンフランシスコでの開催は第 1 回ということで、ハッカソン参加チームが少ない中、最後のピッチまでやったことに対して、激励の意味を込めて特別賞を用意していただいたのだと思います。賞品・賞金をもらうことは目標としていませんでしたが、最後に賞をいただけたことは、徹夜してプロトタイプを作ったかいがあったなと充実した気持ちでいっぱいになりました。

所感

今回、ハッカソンに初めて参加しましたが、以下の点で有意義なイベントとなりました。

• 技術習得（Android、BaaS、サーバサイドJS）の目標が達成できた
• API や Connected car といった今盛り上がっている技術分野のトレンドを把握できた
• ハッカソン仲間ができた（インド人・ラマさん）

技術習得に関しては、当初はバックエンドは PaaS 上に実装することを想定してPaaSの勉強のつもりで臨みましたが、実際には モバイル + BaaS という構成で、よりシンプルにモバイルアプリを開発できると知れた点は非常に収穫でした。実際に、Parse 上に手を動かして REST API を構築したことで、基本的な使い方も習得でき、参加の目標は達成できました。今後とも BaaS には注目して技術習得する予定です。

技術トレンドに関しては、今、まさに Apple や Google が市場参入を表明し、これまでモバイル開発者が入り込めなかった自動車分野のドアが大きく開かれようとしている熱狂感を味わうことができました。我々のチームが取り組んだ自動車の走行記録のデータ分析を別のサービスに活用するというアイディアは、以前は大手自動車メーカーの開発者にしか開発できないシロモノでしたが、今では API が公開されたことで、普通の開発者でも取り組める分野に大きく変貌したことを感じました。自動車の走行データは、今後、多くのアプリで活用されるのではないかと思います。

最後に、ハッカソン仲間ができた点は大きな収穫でした。インド人・ラマさんはインド人にしては比較的物静かなタイプですが、まじめで、自動車分野に対してイノベーションを起こしたいという熱い志の持ち主です。今回、ハッカソンで偶然一緒のチームになり、意気投合したことで、9月に開催される「Code for Car and Home」をテーマにした AT & T 主催のハッカソンに一緒に参加することも決まりました。今回は、荒削りなアイディア・プロトタイプですが、次はもっと洗練したものを開発しようとやる気に満ちています。

おわりに

ハッカソンは、いろいろな目的を持った企業や個人が集い、一緒にサービスのプロトタイプを開発することで、新しいイノベーションの種を発見する場所です。そして、筆者のように新しい技術を習得したり、プロトタイピングを通じて新たな仲間を見つけることもできます。

もし、読者の皆様で本記事のような体験に興味がある方がいらっしゃれば、すぐにハッカソンに参加してみましょう。きっと貴重な体験が得られるはずです！