API 主導の接続性アプローチにおける 3 つの層 — エクスペリエンス API、プロセス API、システム API — のどこであっても、 API (アプリケーションプログラミングインタフェース) はアプリケーション開発の基本です。API を利用することで、企業は、ビジネス、技術、組織の目標達成に向けて柔軟に対応できるようになります。
「新しい API が追加されたこと」や「既存の API がアップデートされたこと」を関係者に知らせるため API 通知プロセスを自動化すれば、当該 API と接続しているアプリケーションやシステムの開発者や利用者は、いちいち API の更新情報にアクセスする必要がなくなります。つまり、新しいビジネスプロセスやビジネス機会を自動的に入手できるようになるため、新しい収益源をうみ出す (創造的な) 業務により多くの時間を費やすことが可能になります。
さらに自動化することで、「人為的ミスの発生リスクの削減」と「繰り返し作業に費やす時間の短縮」により、関係者は別の業務に専念することができます。
API の変更通知に自動化を活用
MuleSoft の『接続性ベンチマークレポート』によると、ほとんどの企業 (90%) がインテグレーションと API に関して明確な戦略を策定しています。また 25% の企業は「すべてのプロジェクトにおいて、『全社的な API インテグレーション戦略』を遵守するようにリーダーが要求している」と述べています。
では、『API エコシステム』の管理、拡大、コミュニケーションをサポートするためにはどうすればよいでしょうか？
2 つの解決策が挙げられます。
1 つ目：MuleSoft が提供する『Universal API Management』を使用することにより、社内で利用しているすべての API の管理とガバナンスを一元的に行なうこと。
2 つ目：API の変更やアップデートを API エコシステムの全関係者に効果的に通知する方法を採用すること。
API の変更を通知するための 4 つのステップ
API はアプリケーション開発の基本です。
新しいアプリケーションの開発や既存アプリケーションの改良を続けるにつれ、API が新しく作成されたり、既存の API がアップデートや変更されたり、非推奨になったりすることはよくあります。
こういった API の情報を効果的に通知するためには、以下に挙げる 4 つのステップを踏襲しなければなりません。
- (API 変更を) 通知するオーディエンスを知る
- コミュニケーションチャネルを確立する
- API 変更の種類を見極める
- 通知メッセージを決める
1.（API 変更を）通知するオーディエンスを知る
API の変更を通知するうえで重要なのが、「オーディエンスを知る」ということです。このオーディエンスとは、新しく作成した API や既存 API のアップデートや変更によって影響を受ける可能性がある「全員」になります。開発者やマネージャー、経営者などの関係者や API の利用者が該当することになるでしょう。
API 利用者は、ビジネスパートナーかもしれませんし、プラットフォームイノベーターかもしれません。ビジネスパートナーなら、自社のアプリケーションを貴社のプラットフォームと統合できるでしょう。イノベーターであれば、API を利用してビジネスチャンスを創出し、新たな収益源をうみだせます。
API のオーディエンスが誰であるかを知ることは、API の変更を効果的に通知するための第一歩となります。オーディエンスは、これらの通知をさらに展開・拡散する窓口にもなってくれるでしょう。
2. コミュニケーションチャネルを確立する
API のアップデートや変更、追加は、コミュニケーションチャネルを通じてオーディエンスに通知されます。コミュニケーションチャネルでは、目的に応じた API 情報 (名前、説明、場所など) を配信。アクティブモードとパッシブモードの両方をサポートしています。アクティブモード (proactive notification) は API の変更が既存のアプリケーションに影響を与える場合に送信され、API 利用者はアプリケーションに不具合が起きないよう、このイベントに対応しなければなりません。パッシブモード (passive notification) は、情報提供を目的とするケースが多く、すぐに反応する必要はほとんどありません。
コミュニケーションチャネルを確立するためには、①コラボレーションプラットフォームの採用、②ポータルソフトウェアの利用、③コードの記述、という 3 つのアプローチがあります。これらのアプローチにより、オーディエンスへの通知やメッセージの配信、API ドキュメンテーションへのアクセスが可能になります。
コラボレーションプラットフォームは、オーディエンス (開発者、API 利用者、マネージャーなど) 間のコミュニケーションや共同作業を可能にします。Slack がその良い例でしょう。Slack を利用することで、オーディエンス同士がリアルタイムで簡単にやり取りしたり、自動化されたワークフローを組み込んだりすることができます。
ポータルソフトウェアは、ユーザーがコミュニティとして集まり、情報（新しい API や既存 API の変更などの詳細) にアクセスするための中心的なプラットフォームとして機能します。『Anypoint Community Manager』はこの機能を備えており、API コミュニティメンバーのポータルとして効果的に利用できます。さらに『Anypoint Exchange』から API ドキュメントを自動入力することも可能です。
アプリケーション内のコードは、APIの変更を通知するのに役立ちます。開発者は、API に警告ヘッダーを記述したり、共通のサービスを呼び出して API の状態を確認したりできます。さらに、今後の API 変更イベントを知らせるメールを設定・送信することも可能。オーディエンスには、API が変更または非推奨になることが通知されます。このアプローチと自動化の組み合わせにより、コミュニケーションの強化とオーディエンス体験の向上が実現できるのです。
3. API 変更の種類を見極める
API を変更する理由は沢山あります。
新機能の追加やビジネスプロセスの変更、アーキテクチャや設計の改善などが API 変更の一般的な理由でしょう。こうした API の変更は、「破壊型」と「非破壊型」に分類されます。
- 「破壊型」の API 変更とは、アプリケーションの不具合を引き起こすような API の変更を指し、環境を破壊してしまう可能性を持っています。破壊型の API 変更の例としては、必須のクエリパラメーターの追加やデータ形式の変更、API リソースの名称変更などが挙げられます。
- 「非破壊型」の API 変更は、API 利用者への影響がなく、情報提供の意味合いが強いです。新しい操作の追加や、任意のデータ属性の追加などが挙げられます。
API の変更を通知する場合は、オーディエンスがすぐにそれを認識できなければなりません。そうすることでオーディエンスは、すぐに変化に気づき、必要な対応を取ることが可能になります。これにより、API をデプロイするときのリスクを低減し、オーディエンスに信頼感を与えられます。なぜなら、オーディエンスにアプリケーションの変更や潜在的な影響について情報提供するプロセスがあることを、実感してもらえるからです。
4. 通知メッセージを決める
API 変更の通知メッセージは、受け手にとって分かりやすくなければなりません。そのためにオーディエンスをセグメント化し、それぞれのセグメントに必要なコンテンツを明確化します。コンテンツは必要十分かつ有益でなければなりません。
オーディエンスのタイプ別にミーティングを行い、重要かつ具体的な要件を洗い出しましょう。最も大切なのは、「適切なメッセージを適切なタイミングで伝える」ということです。それにより、情報過多を防ぎ、混乱を避け、メッセージが (自分に) 強く関係していることを伝えることができるのです。
すべてをまとめる
API の変更を通知するための 4 つのステップが明確になったたところで、利用するテクノロジーをおさらいしておきましょう。
- Slack：共同作業や (リアルタイム) コミュニケーション、オーディエンスのワークフローの自動化に使用。
- MuleSoft Anypoint Community Manager：ポータルとして使用。API を中心としたコミュニティを形成し、API のドキュメントをオーディエンスに提供できます。
- MuleSoft Anypoint Exchange：API と API に関するサービスや情報をカタログ化。『Anypoint Exchange』からの情報は『Anypoint Community Manager』に自動入力されます。API に警告メッセージを埋め込み、オーディエンスに変更を知らせることができます。
上記の製品や機能、サービスを統合し自動化することで、API の変更を通知する柔軟度の高いソリューションを構築できます。
これにより、オーディエンスとの信頼関係を築き、API エコシステムのリスクを軽減するための確実なアプローチです。
