3つ目の壁：組織（ROIや予算が通りにくいAPI）
API公開および整備への意思決定には、大別して2つのルートがあります。（1）既存のサービスユーザーのデータ連携ニーズの依頼、（2）経営からのビジネス拡張のエンジンとして、という2つのルートです。社内での予算やリソース決定において、既存ユーザーからのAPI課金の難しさと、売り上げ目標を持つセールスチームとのセールスポイントとしての理解のしにくさからAPIはROIを出しにくい要件となりがちです。
既存ユーザーのリクエストによりAPIを提供し始めたからといって、既存ユーザーからAPI利用に対して課金できるケースは少ないです。CRM、グループウェア、MAなどのサービスの多くは顧客の自社データ利用へは課金していません。これでは取引の防衛にはなっても既存ユーザーからのライセンス収入が増える絵を描くことは難しいです。クラウドサービスの開発チームは、API開発や整備だけでなく、サービスの機能自体の実装要件を複数持っています。その中で当然新規顧客獲得につながる機能実装が優先されます。
一方、製品のセールスチームはこれまでサービスの機能をセールスのドライバーとしてきているので、理解しにくいAPIをセールスポイントにして翌期の売り上げをコミットすることは難しいという現状があります。
結果としてAPI開発は後回しにされてしまったり、既存ユーザーの要望の範囲でしか投資されず「APIファースト」に踏み出せない中途半端なものとなってしまいます。画面ではRead／WriteできるのにAPIはRead only、APIで合計値は取得できるのに明細が取れない、といった不完全なAPIの問題はこのような背景から生まれるのでしょう。
本来は、API開発・整備は既存ユーザーからのリクエストだけでなく、「API as a Product」的な考えでAPIとして独自のユーザーチャネルを開拓し、新規ライセンス収入を獲得していくというビジョンを起点に考えなければなりません。既存ユーザーからのAPI要件だけでは、もととなるサービスの補助的な機能にとどまってしまいます。APIで新しいユーザーチャネルを獲得していくためには、拡張利用のための機能デザインが必要です。そしてその収益見込みは既存のセールスやアライアンスパートナーに頼るばかりでは、飛躍ができません。それどころか、APIでの新規チャネル拡大は、既存の販売チャネルやパートナービジネスの脅威となることすら想定しなければなりません。
「API Product Manager」の設置
短期的には既存ユーザーの満足度向上、中期的にはビジネス拡張のエンジンになることを見据えたAPI戦略の策定、仕様の作成、予算・リソース取りと組織決定を行うために、組織の中でこれらのバランスを取りながらAPIをビジネスとして動かす「API Product Manager」を設置する流れが出てきています。
既存ユーザーと新規ユーザーという異なるターゲットのバランス、製品、技術、ビジネスの調停をしながらエッジの効いたAPIを世に出すことは、まさにProduct Managerが担うべき仕事です。これをもととなるサービスと同じProduct Managerが担ってしまったのではサービスの機能の一部ではない「API as a Product」を実現することは困難です。
このようにAPIは、重要性は理解されていながら、技術の壁、UXの壁、組織の壁により投資が進んでいないケースがあることを説明しました。ただし、後発であることは悪いことばかりではなく、ここ10年で進歩したツールや方法論を駆使して、より効率的にAPIビジネスを展開できるという利点があります。技術の壁は充実してきたAPI管理ツールの利用でリソースや時間の問題をクリアできるでしょう。UXの壁には「API as a Product」というコンセプトでのもととなるサービスとは異なるDX方針の策定、組織の壁にはAPI Product Managerによるリードにより、スピード感のあるAPIビジネス運営ができると考えています。
今回の記事では、APIエコシステム構築の難所とそれをクリアする考え方について説明しました。次回2回目は、公開したAPIのAPIエコシステムを整備するための具体的な打ち手であるAPIポータルについて説明します。
