web api next challenge

38
Next Challenge Web API 2016年03月18日 株式会社ヴァル研究所 内田 学 第2回 WAVE@AWSJ

Upload: uchimanajet7

Post on 08-Jan-2017

183 views

Category:

Technology


3 download

TRANSCRIPT

Page 1: Web API Next Challenge

Next ChallengeWeb API

2016年03月18日 株式会社ヴァル研究所

内田 学 第2回 WAVE@AWSJ

Page 2: Web API Next Challenge

2ご注意‣ 2016年03月18日現在の情報です

‣ 資料内の表現や文言は変更される可能性があります

‣ WAVEでの発表なので個人的な考えや想いも入って

いるため今後発表される正式なものと異なる場合があります

‣ 正式版との差異があった場合、正式版が基準となりますのでご了承ください

‣ ご意見・質問がありましたらお気軽にお問い合わせください

Page 3: Web API Next Challenge

3自己紹介内田 学(うちだ まなぶ)

uchimanajet7

Spot Instances AWS SDK for Go

Support API Gateway

Page 4: Web API Next Challenge

4会社紹介

東京都杉並区高円寺北2−3−171976年(昭和51年)7月26日155名(2015年10月1日現在)

Page 5: Web API Next Challenge

5製品・サービス紹介

Page 6: Web API Next Challenge

6VAL Innovation Camp

https://youtu.be/VXHB3tLeYl8

Page 7: Web API Next Challenge

“Val Web Service”Next Challenge

Page 8: Web API Next Challenge

8Val Web Service‣ 「駅すぱあと Web Service」だけの単体サービ

スからAPIエコノミーを考慮した複合サービスへ

‣ 自社だけでなく他社のAPIもサービスライナップ

に加えていきたい

‣ ProgrammableWebやMashapeと言ったサービ

スと同様の考え方

‣ 当面は自社ドメインに特化したAPI Management

サービスを目指していく

Page 9: Web API Next Challenge

9Val Web Service

Page 10: Web API Next Challenge

10TIBCO MASHERY

https://www.pcp.co.jp/product/mashery

Page 11: Web API Next Challenge

11Val Web Service‣ なぜ「Val Web Service」なのか?

‣ 現状のAPIビジネスには課題が多い

‣ 利用者視点だと - どこにどんなAPIがあるのかわからない

- APIの利用方法がそれぞれ異なる

- APIのドキュメントもそれぞれ異なり煩雑

- 提供している会社ごとに契約や認証が必要 - 利用者が少ないAPIだと利用例を探すのが困難

Page 12: Web API Next Challenge

12Val Web Service‣ 提供者視点だと

- どうやって公開して認知させていくか - 公開にあたっての運用やセキュリティをどうするか

- 利用状況やパフォーマンスの計測をどうするか - データだけや非公開APIしかない場合にどう

やって公開するか - 課金やユーザー管理をどうするか

Page 13: Web API Next Challenge

13Val Web Service‣ こうした課題を解決し成長していくために ‣ 既存の顧客チャネルを相互で利用する仕組み

- セールスやマーケティングで成功事例を活用できる - 単純なチャネルの拡大、アップセル/クロスセル

- 利用規模が大きくなることによる囲い込みとフィードバックの増加

‣ 異なる領域でお互いの強みを最大限に活用できる仕組み - 未知の領域で予測を行うことが可能になる - 単一では提供することが難しい新たな解決方法 - 普段と異なる目線による新しい発見

Page 14: Web API Next Challenge

14導入事例

https://ekiworld.net/case

Page 15: Web API Next Challenge

15Val Web Service‣ シングルポイント化による効率化

- API利用時の認証が単一化

- ドキュメントや問い合わせについても、フォーマットの統一化や窓口の単一化

- 利用契約や支払いといった事務的な部分も単一化 - ユーザー管理やセキュリティといった重要な部分もMashery を利用することにより安心・安全に単

一化 - 利用者も提供者も煩雑な作業から解放される

Page 16: Web API Next Challenge

16Val Web Service‣ API連携による新たな可能性・付加価値の創造

- お互いの環境がAWS上に構築されている場合、非常に

柔軟かつ安全に相互接続可能 - データとAPIや非公開APIと公開APIなど条件が合えば連

携することが可能 - マスターデータ類を連携することにより、デファクトスタンダードとなり得る可能性

- 連携により新規開発しなくても実現可能となる可能性 - メインビジネスにフォーカスしながらもバリエーションを増やせる

Page 17: Web API Next Challenge

17AWS 導入事例

https://aws.amazon.com/jp/solutions/case-studies/val/

Page 18: Web API Next Challenge

18Val Web Service‣ 結果としてAPIエコノミー自体が活性化することが目的

‣ APIが便利に気軽に利用できるようになると、更にモノ

づくりのハードルが下がる ‣ これにより、新たなサービスやプロダクトが増えイノベーションの可能性が増えることが期待できる

‣ さらに、このような取り組みが増えていけばもっと大きな単位での連携が可能となる

‣ それぞれが得意分野・領域でAPIのホームセンターに

なっていくことで実現できると考えている

Page 19: Web API Next Challenge

“SkyBrain”Next Challenge

Page 20: Web API Next Challenge

20SkyBrain‣ 交通移動体の位置情報管理を目的として作成中のIoT

向けサービス ‣ 柔軟かつ安価に動作することを目標としている

‣ 通信プラットフォームは SORACOM Air を利用

‣ 機器はスマートフォンを利用してプロトタイピング中

‣ クラウド環境はAWSを利用

‣ S3、Lambda、API Gatewayといったフルマネージド

サービスを積極的に利用 ‣ 構築時間の短縮と構築後の運用負担を考慮している

Page 21: Web API Next Challenge

21事例紹介

http://www.slideshare.net/SORACOM/connectedt2soracom-beam-iot/

Page 22: Web API Next Challenge

22SkyBrain‣ データのアップロードはSORACOM Funnel or

Amazon Kinesis で行う

‣ データの取得についてはAmazon API Gateway を利

用してAPI化

‣ データの蓄積と活用が簡単かつ安全・安価に行える ‣ これによりほぼリアルタイムなデータを活用できるようになる

‣ リアルタイムなデータが加わることで、既存のデータやAPIが新たな価値を持つ

Page 23: Web API Next Challenge

23SkyBrain

Cognito

JavaScript SDK

Kinesis

Lambda

S3 API Gateway Users

SORACOM Air

SORACOM Funnel

Lambda

Page 24: Web API Next Challenge

24SkyBrain

Cognito

JavaScript SDK

Kinesis

Lambda

S3 API Gateway Users

SORACOM Air

SORACOM Funnel

Lambda

upload

Page 25: Web API Next Challenge

25SkyBrain

Cognito

JavaScript SDK

Kinesis

Lambda

S3 API Gateway Users

SORACOM Air

SORACOM Funnel

Lambda

活用

Page 26: Web API Next Challenge

“路線図 API”Next Challenge

Page 27: Web API Next Challenge

27路線図 API‣ 2005年から現在まで「路線図 ASP」として路線

図のサービスを展開中

‣ Windows版製品で使われている路線図を元にし

てサービスを開発 ‣ この時の路線図は入力補助>表示・表現 ‣ このため適度にデフォルメされており駅の位置関係はつかみやすい

‣ またできることが少ないのでそれが制約となり操作も単純である

Page 28: Web API Next Challenge

28ASP連携サービス

https://ekiworld.net/service/web/about.html

Page 29: Web API Next Challenge

29路線図 API‣ 近年はユーザー、デバイスが多種多様になった ‣ 求められる表現や品質も高くなり多様性を増している

‣ いま求められているのは入力補助 ≤ 表示・表現

‣ 一般的な地図サービスと同様の表示・表現が必要 ‣ ユーザーサイドでコントロールできる必要があるためAPIが必要

‣ いまの要望はいまのWebフロントエンド技術を使っ

て解決していきたい

Page 30: Web API Next Challenge

30新しい路線図

http://rosenzu.strikingly.com/

Page 31: Web API Next Challenge

31路線図 API‣ JavaScript ベースのAPIでの操作が可能

‣ 表示・表現するための機能を搭載

‣ Webベースでの表示となるため汎用性が高い

‣ これにより表示・表現方法の幅が広がりユーザーが希望する状況に応じて対応できるようになっている

‣ 地図と同じように日本全国をシームレスに表現 ‣ 適度なデフォルメをしているので見やすさ使いやすさはそのまま

‣ さまざまなデータを表示・表現できるサービスとしての位置付け

Page 32: Web API Next Challenge

まとめ

Page 33: Web API Next Challenge

33まとめ‣ 「Val Web Service」により、APIを普及

させて利用者を増やす

‣ 「SkyBrain」により、リアルタイムデー

タを取得してAPIで活用できるように

‣ 「路線図 API」により、データやAPIの結

果を柔軟で自由な表示・表現ができるように

Page 34: Web API Next Challenge

34まとめ‣ 変化への対応はできるところから素早くカイゼン

‣ APIそのものだけでなく、利用するデータ

や表示についても同様に継続していきたい ‣ 最終的にはこれらが相互に影響しあってより大きな波(WAVE)になることを期待し

ている

Page 35: Web API Next Challenge

35お問い合わせ

http://www.val.co.jp/contact/

Page 36: Web API Next Challenge

36Appendix‣ ProgrammableWeb

- http://www.programmableweb.com/

‣ Mashape

- https://www.mashape.com/

‣ 株式会社ソラコム

- https://soracom.jp/

‣ Mashery API マネジメント | ピーシーフェーズ

- https://www.pcp.co.jp/product/mashery

Page 37: Web API Next Challenge

37Appendix‣ 株式会社ヴァル研究所

- http://www.val.co.jp/

‣ 駅すぱあとワールド

- https://ekiworld.net/

‣ 駅すぱあと - YouTube

- https://www.youtube.com/channel/

UChsdHb4qHO5eFmSOhl0Udsw

‣ 「駅すぱあと」のあたらしい路線図

- http://rosenzu.strikingly.com/

Page 38: Web API Next Challenge

38Appendix‣ JAWS-UG 中央線

- http://jaws-ug.jp/bc/chuoline/

‣ JAWS-UG 京王線

- https://jawsug-keioline.doorkeeper.jp/

‣ uchimanajet7 - Pixelhub.me

- http://pixelhub.me/pixelhub1/index.php?

user=uchimanajet7