Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Api as a product

1,317 views

Published on

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

Published in: Software
  • Be the first to comment

Api as a product

  1. 1. API x PM #01 API as a Product 2017/07/03 疋田 圭介
  2. 2. API x PM #01 About Speaker 疋田 圭介 • CData Software Japan 合同会社 代表社員 経歴 • 業務データ活用一筋10年+ • 金融機関10年(内、インドネシア5年) • コンポーネント開発の海外オペレーション • CData Software の日本オペ立ち上げ @cdatajapan (占拠中) @keisuke.hikita.5 https://qiita.com/jonathanh
  3. 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. 4. API x PM #01 業界最多級のデータソース Drivers for NoSQL, Big Data, & SaaS Connectivity CRMおよびマーケティング自動化 会計システム コラボレーションおよびERP オンプレミスおよびクラウドDB ドキュメントおよびファイル形式 ソーシャルネットワーキングネットワーキングおよび認証 電子商取引 その他
  5. 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. 6. API x PM #01 今日のはなし「API as a Product」 • API を提供する目的は? • API ユーザー≠元のサービスのユーザー • 「API as a Product」の考え方とは?
  7. 7. API x PM #01 何のためにAPI を提供しますか?
  8. 8. API x PM #01 1. 提供しないと既存ユーザーが困る • マスター同期 • ワークフロー • バックアップ • UI 選択 • DWH・分析 • AI/Intelligent Cloud • セキュリティ 「ブラウザ画面からコピペしろ」とは言えません。
  9. 9. API x PM #01 競合がすでにAPI 出してる
  10. 10. API x PM #01 2. コア部分の開発に特化できる • スモールスタートのために • 全てを1つのサービスで提供することは困難。莫大なリソースが必要。 • 特色のある機能を提供するサービスならスモールスタートが可能 • はじめからAPI を提供すれば、足りない機能は顧客が実装 • 大きな企業でも顧客ニーズ全部にはこたえられない • 顧客毎に異なるニーズに全部応えたら、製品がぐちゃぐちゃに • コアの部分を実装して、マイナーな要件は顧客が実装 • 他社のAPI を使ってデリバリーを早く • 車輪の再発明は不要
  11. 11. API x PM #01 3. 別チャネルのユーザーを増やしたい
  12. 12. API x PM #01 API 公開すれば、使ってもらえるワケではない
  13. 13. API x PM #01 考えて:API のユーザーはエンジニア もとのサービスユーザー 非エンジニア(ホワイトカラー) API のユーザー エンジニア • ブラウザから • 決まった作業をやる • 目で見て判断⇒キーボード叩く • 基本手動 • トップダウンの製品導入 • 安定・信頼 • コードでアクセス • 新しい使い方 • スキーマ読んで⇒機械が判断 • 基本自動化したい • 速い検証サイクル • 変化・新技術
  14. 14. API x PM #01 ペルソナが違えば、UX は異なる • UX の再定義しましたか?
  15. 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. 16. API x PM #01 「API as a Product」なら • API 戦略を設定しよう: • 既存ユーザーの利便性向上がフルスコープ? • それともユーザー増加を狙う決め手? • ちゃんとエッジ立ってる? • 戦略立てて、リソース取って、製品宇宙を支配します。
  17. 17. API x PM #01 「API as a Product」なら • API Product Manager を置こう • もとのサービスと同じ人がPM だと独立が難しい • 製品仕様、UI、マーケ・営業、サポートに渡る権限を • 戦略と一緒に独立予算を持とう • 既存ユーザーとAPI で獲得するユーザーの機能要望のバランス
  18. 18. API x PM #01 「API as a Product」なら • API のUI を整備しよう(もとの製品に引きずられない) • 開発者ポータル • 整備されたドキュメント(当然Web) • ちゃんとSEO する • SDK • Driver • 使いやすいAPI • REST (特にこだわりない場合は) • 今ならOpenAPI Initiative • メタデータの提供
  19. 19. API x PM #01 「API as a Product」なら • API プロモーションやチャネルを再定義しよう • 既存のプロモーションチャネルは基本的には使えないと思った方がよい • Web で情報が見つからないのはNG • 紙の申請書とか止めよう • 営業人員の手を介すやり方でいいのか? • すぐにトライアルできる環境 • サンプルやナレッジ記事 • セールスよりもコミュニティ
  20. 20. API x PM #01 「API as a Product」なら • API ユーザーをサポートできる体制を作ろう • 既存のサポート/CS がエンジニア向けのAPI のサポートができるとは考えない • API サポートを同じルートにするか別ルートにするか? • 逆に電話サポートとか訪問は減らせそう
  21. 21. API x PM #01 最後に:もとのサービスと違ったUX でいいんだ • API は別の製品として捉えた方が良い(まとめ)。 • API 戦略、API PM、独自予算、独自リソースをいきなり得ることは組織 上、難しいかもしれない。 • 一番重要なことは、「API のUX はもとのサービスと違ってもいい」という意 識を持つこと。
  22. 22. API x PM #01 ありがとうございました。

×