API を成長させるには、エンジニアの心をつかもう。 「API は一機能ではなく製品」という考えを紹介。 API as a Product で、API 戦略、API PM、からUX 全般の再定義を。

1. API x PM #01
API as a Product
2017/07/03
疋田 圭介

2. API x PM #01
About Speaker
疋田 圭介
• CData Software Japan 合同会社 代表社員
経歴
• 業務データ活用一筋10年+
• 金融機関10年（内、インドネシア5年）
• コンポーネント開発の海外オペレーション
• CData Software の日本オペ立ち上げ
@cdatajapan (占拠中）
@keisuke.hikita.5
https://qiita.com/jonathanh

3. API x PM #01
About CData Software
Bi-directional Access to Live App, Database, & Web API Data Through Standard Drivers
・CData Software, Inc. / Started: 1994 (/nsoftware)
・Location: Chapel Hill, NC a spin-off of /n software
・CData Japan: 2016/6 (JV with Infoteria)
・20年以上にわたりデータ関連コンポーネントを提供
・100+ 対応データソース
・「API を使いやすく」をミッションにクラウドデータ接続を標準化

4. API x PM #01
業界最多級のデータソース
Drivers for NoSQL, Big Data, & SaaS Connectivity
CRMおよびマーケティング自動化
会計システム
コラボレーションおよびERP
オンプレミスおよびクラウドDB
ドキュメントおよびファイル形式
ソーシャルネットワーキングネットワーキングおよび認証
電子商取引
その他

5. API x PM #01
RDB⇔ Web API 変換でAPI を使いやすく
Enable real-time data integration with hundreds of applications, databases, and Web APIs
Data Drivers
Web API をJDBC/ODBC/ADO
（標準SQL）で使いやすく
API Server
RDB/NoSQL/file からREST API
を簡単に作成

6. API x PM #01
今日のはなし「API as a Product」
• API を提供する目的は？
• API ユーザー≠元のサービスのユーザー
• 「API as a Product」の考え方とは？

7. API x PM #01
何のためにAPI を提供しますか？

8. API x PM #01
1. 提供しないと既存ユーザーが困る
• マスター同期
• ワークフロー
• バックアップ
• UI 選択
• DWH・分析
• AI/Intelligent Cloud
• セキュリティ
「ブラウザ画面からコピペしろ」とは言えません。

9. API x PM #01
競合がすでにAPI 出してる

10. API x PM #01
2. コア部分の開発に特化できる
• スモールスタートのために
• 全てを1つのサービスで提供することは困難。莫大なリソースが必要。
• 特色のある機能を提供するサービスならスモールスタートが可能
• はじめからAPI を提供すれば、足りない機能は顧客が実装
• 大きな企業でも顧客ニーズ全部にはこたえられない
• 顧客毎に異なるニーズに全部応えたら、製品がぐちゃぐちゃに
• コアの部分を実装して、マイナーな要件は顧客が実装
• 他社のAPI を使ってデリバリーを早く
• 車輪の再発明は不要

11. API x PM #01
3. 別チャネルのユーザーを増やしたい

12. API x PM #01
API 公開すれば、使ってもらえるワケではない

13. API x PM #01
考えて：API のユーザーはエンジニア
もとのサービスユーザー
非エンジニア（ホワイトカラー）
API のユーザー
エンジニア
• ブラウザから
• 決まった作業をやる
• 目で見て判断⇒キーボード叩く
• 基本手動
• トップダウンの製品導入
• 安定・信頼
• コードでアクセス
• 新しい使い方
• スキーマ読んで⇒機械が判断
• 基本自動化したい
• 速い検証サイクル
• 変化・新技術

14. API x PM #01
ペルソナが違えば、UX は異なる
• UX の再定義しましたか？

15. API x PM #01
「API as a Product」
近年提唱されている「API はそれ自体が製品である」という考え方
• API を製品として扱い、Product Owner を置く
• クライアントのエンジニアが使いたくなるようなシンプル、総合的、使いやすいAPI
• 能動的にAPI を長きにわたって維持・メンテする
• 顧客フィードバックをプロダクトに活かし、高品質のサポートを提供
https://opensource.zalando.com/restful-api-guidelines/出典：
https://restful-api-guidelines-ja.netlify.com/和訳あった：

16. API x PM #01
「API as a Product」なら
• API 戦略を設定しよう：
• 既存ユーザーの利便性向上がフルスコープ？
• それともユーザー増加を狙う決め手？
• ちゃんとエッジ立ってる？
• 戦略立てて、リソース取って、製品宇宙を支配します。

17. API x PM #01
「API as a Product」なら
• API Product Manager を置こう
• もとのサービスと同じ人がPM だと独立が難しい
• 製品仕様、UI、マーケ・営業、サポートに渡る権限を
• 戦略と一緒に独立予算を持とう
• 既存ユーザーとAPI で獲得するユーザーの機能要望のバランス

18. API x PM #01
「API as a Product」なら
• API のUI を整備しよう（もとの製品に引きずられない）
• 開発者ポータル
• 整備されたドキュメント（当然Web）
• ちゃんとSEO する
• SDK
• Driver
• 使いやすいAPI
• REST （特にこだわりない場合は）
• 今ならOpenAPI Initiative
• メタデータの提供

19. API x PM #01
「API as a Product」なら
• API プロモーションやチャネルを再定義しよう
• 既存のプロモーションチャネルは基本的には使えないと思った方がよい
• Web で情報が見つからないのはNG
• 紙の申請書とか止めよう
• 営業人員の手を介すやり方でいいのか？
• すぐにトライアルできる環境
• サンプルやナレッジ記事
• セールスよりもコミュニティ

20. API x PM #01
「API as a Product」なら
• API ユーザーをサポートできる体制を作ろう
• 既存のサポート/CS がエンジニア向けのAPI のサポートができるとは考えない
• API サポートを同じルートにするか別ルートにするか？
• 逆に電話サポートとか訪問は減らせそう

21. API x PM #01
最後に：もとのサービスと違ったUX でいいんだ
• API は別の製品として捉えた方が良い（まとめ）。
• API 戦略、API PM、独自予算、独自リソースをいきなり得ることは組織
上、難しいかもしれない。
• 一番重要なことは、「API のUX はもとのサービスと違ってもいい」という意
識を持つこと。

22. API x PM #01
ありがとうございました。