2つ目の壁： APIのUXを再定義する「API as a Product」というコンセプト
APIを考えるうえで見落とされがちな点が、APIのユーザーエクスペリエンス（UX）です。今までAPIは「サービスに付随する1機能」だと思われてきました。その考えではエコノミーを広げるAPIとはなりません。APIは「API as a Product」つまり、API自体が製品として捉え直され、APIのUXが考え直される必要があります。
もととなるサービスを画面から利用するユーザーは、BtoCサービスであれば個人のユーザーであり、BtoBであれば非エンジニアである業務部門である場合が多いです。Product Managerはユーザーのニーズをくみ取り、ユーザーの問題を解決する製品を作り、UIを作り、ユーザーが目にする媒体で広告を打ち、購入、サポートを含めたUXを設計します。一方、APIのユーザーは誰でしょうか？ 多くの場合、APIのユーザーは「ソフトウェアエンジニア」です。エンドユーザー企業の中のエンジニアや、さまざまなサービスを組み合わせたマッシュアッププロダクト企業のエンジニアがAPIのユーザーです。にもかかわらず、もととなるサービスのUXに引きずられて、エンジニアにとって良くないUXでAPIを提供してはいないでしょうか？ 英語圏では既にAPIのUX（ユーザー体験）には、DX（Developer Experience、開発者体験）という表現もされているほどに重要なポイントです。
筆者は仕事上、非常に多くのAPIを実際に触っています。私が技術ディレクターを務めているCData Softwareは100を超えるSaaS、データストアのAPIをJDBCやODBC ドライバーとして提供するため、普段からそれらのAPIを高いレベルで触っています。また多くのソフトウェアエンジニアとも意見交換をして、おぼろげながらAPIの望まれるDXについてイメージを持つに至りました。APIの技術的なDXについては次回深堀りすることにして、ここでは非技術的なDXの例を取り上げます。
APIの使用開始までのプロセスの簡素化
DXの手始めに、APIを使う前のプロセスは極力簡素化すべきです。例えば、SalesforceのAPIを試すことは非常に簡単です。Salesforceの開発アカウントをWebで申請して取得し、サービスにログインしてAPIを使うための認証トークンを発行すれば、もう開発アカウントでAPIを試してみることが可能です。ソフトウェアエンジニアの方であれば、30分もあればAPIを触ってみることができます。
一方、サービスによっては、以下のようなAPI利用開始プロセスが必要な場合があります：
- 試用版・トライアルアカウントがWebからは申請できない
- APIは公開してはいるが、ドキュメントはサービスベンダーに個別依頼
- APIドキュメントやAPIキーの発効に審査や紙の契約書
- 自社データの利用や検証目的だけでもAPI利用が有償
こういった利用開始プロセスは、ソフトウェアエンジニア向きではないことは明らかです。普通に行えば、これらのAPIの利用開始には数日～数週間がかかります。
このようなプロセスは、実はもととなるサービスの利用開始プロセスをそのままAPI開始プロセスに当てはめていることが原因となっているようです。もととなるサービスは有人チャネルで丁寧な訪問説明を行うことで契約を獲得してきたものが多いのではないでしょうか。そのようなサービスでは開発ツールを販売するような「Webサイトに掲載しているから仕様を読んでダウンロードしてください。気に入ったら買ってください」というプロセスを取ることはできません。もちろん、APIの試用を制限する理由はそれだけではなく、Webサイトから簡単に情報を取得できるようにすることでAPIの仕様漏洩による不正アクセスの懸念、APIのサポート負荷、API利用者情報の収集、APIの早期収益化などさまざまな理由はあります。しかし一番の理由として、もとのサービスにAPIの利用プロセスが引っ張られていて、そこに疑問を抱いてすらいないというケースが多いです。
一方、ソフトウェアエンジニアの多くは、「これが実現したい」というニーズがあればWebで検索し、使えそうな製品やサービスを探します。探したら次のアクションは試用・検証です。アジャイルな考え方では、「不確実性」を早い時点で潰していくことが必要です。このようなUXを期待しているソフトウェアエンジニアに対して上記の数日～数週間かかるプロセスは間違っています。APIの使用開始プロセスは、開発者ツールの使用開始プロセスを目指すべきです。目安としては、Webから直接申請してすぐに使えるか、最長でもWeb申請から1日というところでしょう。
使い始めるまでのプロセスは、あくまでDXの一つの例です。ほかにもAPIの仕様書の充実、Webで検索できるかなど非技術的なDXポイントがあります。APIによってビジネスを飛躍的に伸ばそうと考える企業・そしてプロダクト担当者は「API as a Product」として、もととなる製品戦略には大きく従いつつも、独自の製品戦略を持って運営されなければなりません。そして、API戦略にしたがい、機能、UI、マーケティング/セールス、サポートなどのUXを再定義する必要があります。そうでなければAPIの直接の利用者であるソフトウェアエンジニアやITプロに訴求力のあるDXを提供することができません。
