API製品管理におけるプラットフォームの考え方

公開: 2022-03-11

パンデミックにより、組織がデジタルファースト戦略を採用する必要性が大幅に高まったことは周知の事実です。他の組織の目標を優先して優先順位を下げていたデジタルトランスフォーメーションは、前例のない緊急性を伴って、一夜にして最前線と中心にシフトしました。 2020年のマッキンゼーグローバルエグゼクティブサーベイによると、COVID-19による重大な課題にもかかわらず、企業は社内業務をデジタル化し、デジタル製品ポートフォリオを拡大する速度を数年加速させました。

これらのデジタルトランスフォーメーションの中心は、アプリケーションプログラミングインターフェイス（API）によって促進される統合です。かつてはソフトウェアシステム間でデータを送信する「メッセンジャー」または「仲介者」と単純に考えられていたAPIは、デジタルエコシステムの「結合組織」として認識され、APIを構築および活用する組織に無限の統合とビジネスチャンスを提供します。独自の潜在的なAPIが表すため、開発を監督する製品マネージャーは、潜在的な価値を解き放つアプローチを採用する必要があります。これは、完璧な統合エクスペリエンスを保証するための柔軟性と拡張性を強調するアプローチです。

より少ないコストでより多くのことを行う

過去前例のない年の前でさえ、組織にとってのAPIの価値は十分に文書化されており、API経済はしばらくの間繁栄していました。今日の統合の状況を理解するには、Best of Breed（BoB）哲学の起源を探るのに役立ちます。 1990年代以前は、ソフトウェアベンダーは、さまざまな組織の課題を解決しようとするエンタープライズリソースプランニング（ERP）スイートソリューションを販売していました。これらのスイートは、組織固有のユースケースに対応できなかったため、ますます面倒で実用的ではないと見なされるようになりました。その結果、ベンダーは、すべての人のためにすべてを実行しようとする大規模なスイートではなく、1つの機能領域の課題を解決するより焦点を絞ったツールの構築を開始しました。企業は、さまざまなより小さく、より専門的なツールから選択するというアイデアを歓迎し、特定のニーズに最適な個々のソリューションのコレクションを組み立て始めました。

ドットの接続

BoBアプローチが勢いを増すにつれて、統合は製品戦略の重要な部分になりました。ビジネスのある領域の問題を解決するのに優れたツールは、それと一緒に使用される可能性が高い他のBoB製品とうまく統合できなければなりませんでした。組織が販売パイプラインと顧客関係を追跡および最適化するために実装する販売およびCRMソフトウェアであるHubSpotを検討してください。 HubSpotは、顧客のエンジニアリングチームによる追加の開発を必要とせずに、DocuSign（デジタル署名）、Twilio（電子メール/ SMS通知）、Zendesk（顧客サポート）などの他のBoBソフトウェアと容易に統合できます。

相互にシームレスに接続するための補完的なツールの必要性は、システム間の相互作用を制限するのではなく、オープン性を受け入れることへの業界全体のシフトを伴いました。途中のどこかで、製品がサポートする統合の数は、マーケティングに値する指標になりました。

プラットフォームの提案

ただし、統合の真の価値は、異種のツールやシステムを調整する能力を超えています。最高の状態で、APIは製品をプラットフォームに変えるための集合的なメカニズムです。製品は、定義上、特定のアプリケーションを持つツールです。したがって、「アプリ」。彼らは、複数の価値提案、ひいては複数の収益源を生み出す能力に限界があります。一方、プラットフォームは別の方法で付加価値を提供します。つまり、多数の製品を構築できるインフラストラクチャ層を提供することです。

APIは、APIを活用するサードパーティの専門知識を活用することで、新しいビジネスチャネルを開きます。消費開発者は、GoogleMapsのPlacesAPIを使用してユーザーの家探しを支援する不動産アプリを設計したり、SkyscannerのFlightAPIとExpediaのHotelAPIを活用して、特定の場所への旅行に特化したエコツーリズムサイトを作成したりできます。これらの開発者と外部パートナーは、ビジネスに適応できる既存のデータとサービスにアクセスできるというメリットがあります。ExpediaなどのAPI所有者は、製品にホテルのみを掲載し続けた場合には存在しなかった範囲を拡大し、収益化できます。

モジュール化する

製品リーダーにとって、成功するAPI戦略を開発するには、製品思考からプラットフォーム思考への考え方の転換が必要です。これは、モジュール式のオープンエンド方式で製品を構築することを意味します。これにより、機能を再結合でき、消費する開発者の柔軟性を優先します。顧客がさまざまなニーズを満たすためにさまざまな方法で購入、組み立て、カスタマイズできるIKEAシェルフシステムを考えてみてください。優れたAPI製品マネージャーは、APIが何であるか、つまりビジネスを拡大し、価値のあるパートナーシップを構築するためのツールを理解しています。この可能性を認識することは、採用を確実にするためのベストプラクティスを実装することを意味します。

開発者を喜ばせる

堅実なAPI戦略の基本的な柱が1つあるとすれば、それは開発者エクスペリエンス（DX）です。 API統合の場合、製品マネージャーが喜ばなければならない「顧客」は、開発者を消費しています。これらは、最終的にAPIを呼び出し/統合するユーザーであり、製品からプラットフォームへのビジョンの実現を支援できる潜在的なパートナーです。彼らの経験に「UX」ではなく「DX」というラベルを付けることは、彼らが典型的なエンドユーザーではないことを認めています。彼らははるかに技術的に熟達しています。彼らに共感するためには、彼らの特定のニーズと期待を理解することが不可欠です。

ベストプラクティス

以下は、完全なリストを表すものではありませんが、消費する開発者に摩擦のない、一貫性のある、予測可能な統合エクスペリエンスを保証する一流のAPIを構築するための重要なプラクティスです。プロダクトマネージャーは、スケーラブルな方法でAPIを設計し、ベストプラクティスのフレームワークを定義し、チームが新しいAPIを構築するときに参照できるドキュメントとして公開する必要があります。

一貫した命名規則とエンドポイント

APIの性質と目的を明確に識別するAPIエンドポイントの一貫した命名規則を確立することで、あいまいさを取り除き、ポジティブで予測可能なDXに貢献します。すべてのAPIに共通のベースURLを選択し、専門用語や略語を使用しない末尾のURLのフレームワークを選択することをお勧めします。 Nordic APIは、エンドポイントに名前を付けるためのヒントの役立つリストを提供します。

詳細な成功と失敗の応答構造

開発者は、成功と失敗の応答のために、使い慣れたデータオブジェクトとステータスコードを望んでいます。つまり、成功シナリオの場合は2xxステータスコード、クライアント側の障害の場合は4xxコード、サーバー側のエラーの場合は5xxコードです。ただし、特異性が重要です。追加情報なしで4xx応答を返すだけの「電子メール送信」APIを呼び出すと、開発者のエクスペリエンスが低下します。これは、正確に何が問題だったかに関する追加情報を提供せずに、エラーがクライアント要求にあったことを確認するだけだからです。

 { "status": 400, "message": "incorrect request" }

対照的に、人間が読める形式と一意のエラーコードの形式で特定の詳細を提供する応答は、開発者がエラーシナリオを修正する方法をすばやく決定し、問題に対処するコードを記述し、API呼び出しを再試行するのに役立ちます。

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

最適なDXを実現するには、応答構造とステータスを伝達するキーがAPI間で一貫している必要があります。たとえば、上記のエラーコードフィールドは、一部のAPIでは「コード」、他のAPIでは「errorCode」ではなく、すべてのAPIで常に「コード」と呼ばれる必要があります。

構成可能なレート制限

レート制限は、ユーザーが1つの時間単位でAPIを呼び出すことができる回数を決定することにより、APIへのアクセス可能性を管理します。レート制限が高すぎると、システムが管理不能な数のリクエストでいっぱいになり、パフォーマンスが低下する可能性があります。一方、レート制限が不当に低いと、保留中のトランザクションがユーザーのシステムでキューに入れられる可能性があります。どちらもDXの質を低下させます。 APIを設計するときは、特定のビジネスケースや状況に基づいて調整できるレート制限を考慮するのが最善です。たとえば、大量の顧客は、APIをより頻繁に呼び出す必要がある場合があります。

適切なレート制限を最適に決定するには、最初にAPIを呼び出す頻度と量に応じて、意味のあるカテゴリにAPIをグループ化すると便利です。たとえば、主要な顧客データ（プロファイル/アカウントの作成）を構成するAPIはあまり頻繁に呼び出されず、より低いレート制限を処理できますが、トランザクションAPI（「注文の作成」、「電子メールの送信」）はより頻繁に呼び出されるため、より高いレート制限が必要になります。さまざまなユースケースのカテゴリまたは層を確立すると、より信頼性が高くスケーラブルなAPIが実現します。明確に定義されたレート制限の例については、SlackのAPIドキュメントを参照してください。

APIプロダクトマネージャーは、楽しい開発者エクスペリエンスの作成を目指す必要があります。

包括的なドキュメント

ドキュメントは、APIのユーザーマニュアルとして機能します。 APIの機能、使用方法、およびAPIに期待することを開発者に明確に示します。優れたドキュメントは、明確でアクセスしやすい言語で書かれており、詳細でインタラクティブであり、統合を簡単にするためのデモとコードスニペットが豊富に用意されています。このようにして、簡単なオンボーディングと迅速なTime to First Hello World（TTFHW）が容易になります。これは、開発者が最初のAPIをどれだけ迅速に呼び出すことができるかを表す重要な指標です。

ドキュメントでは、APIリクエストのどのフィールドが必須で、どのフィールドがオプションであるか、およびそれらのフィールドの最小および最大の長さとデータ型を明確に特定する必要があります。基本的に、期待を設定し、消費する開発者の障害を取り除くために必要なすべてのものを含める必要があります。たとえば、システムでデータベーススキーマを作成する開発者は、ドキュメントでパラメータが指定されていないため、後でテーブルの列の長さを調整する必要はありません。

APIドキュメントは、消費する開発者にとって信頼できるリファレンスとして機能するだけでなく、API自体のマーケティングツールとしても機能することで、採用を増やすことができます。多くの場合、APIドキュメントに最初に遭遇するのは、製品評価の初期段階でそれを閲覧するビジネス向けの利害関係者です。したがって、APIの技術的要素に関する詳細を含めるだけでなく、APIが可能にするビジネスユースケースを明確に表現する必要があります。

包括的なAPIドキュメントの生成を支援できるツールが市場に数多く出回っています。 Stripeのような高品質のドキュメントの例を確認することも役立ちます。

すべてをまとめる

統合は多くのコンポーネントを含む広大なドメインを表していますが、優れたAPIのコア原則を理解することは、堅実な戦略を開発するための基本です。 APIは、単なるシステムコネクタ以上のものです。これらは、広大なデジタルネットワークの構成要素であり、新しい収益源を開拓し、未開拓の価値を解放するための鍵です。このため、API戦略を成功させるには、製品を構築するだけではありません。それは可能性を構築することです。 API製品マネージャーは、プラットフォームの考え方を採用し、APIを採用して統合し、実行できる潜在的なパートナーの採用を円滑にする要因に優先順位を付ける必要があります。