1つ目の壁：技術的な要素（技術者の確保、セキュリティ）
技術的な壁には大きく分けて2つのカットから考える必要があります。それはAPIそのものを開発する側と、公開されたAPIを使った開発を行うユーザー側です。
多くの場合にプロダクトチームや経営者に認識されているのはAPIを開発する側の技術的な問題です。これまでDB 同士のデータ連携やファイル転送をベースにした連携に慣れていた技術者に、急にWeb APIを実装させることは容易ではありません。SaaSであっても内部ではRDBにデータを格納し、SQLで処理を行っているものが大半です。SasSベンダーだからAPIに慣れている訳ではないのです。JSON形式のデータ、RESTfulなエンドポイントのデザインにはある程度経験が必要です。
加えて、OAuth 2.0などの認証、レートリミット設定、ログやモニタリング機能など必要なセキュリティ・管理要件は多く、API公開の技術的ハードルは跳ね上がります。セキュリティや可用性などが注目される現在に、こういった機能をしっかりと実装できなければ、不正利用やサーバー負荷によって最悪API以外のユーザーインターフェースからサービスを利用している顧客の利便性を損ない、既存顧客が離れてしまう可能性もあります。
API開発を熟知した開発者は、DB同士のデータ連携やファイル転送をベースにした連携に慣れていたソフトウェアエンジニアに比べて、まだエンジニア市場に多くいません。API開発もサービス開発と同様で、一度開発して終わりということはなく、絶えざる追加開発とメンテナンスを必要とするため、人材の確保や育成がまず大きな壁となります。
なぜ標準仕様に注意を払うべきでしょう？ そもそもユーザー側のAPI実装のエンジニアリソースが多く、経験が高いと考えてはいけません。エンタープライズアプリケーション開発を行う多くのエンジニアのデフォルトは数十年の歴史を持つRDBとSQLであり、APIは新参者です。ユーザー側のエンジニアは新しいAPIを苦労して習得して扱わなければなりません。また実装を求められているAPIは一つではありません。その中で使ってもらえるAPIになるには、RESTなデザインや、認証、ドキュメントなどでできるだけ業界標準に追従する必要があります。
API管理ツールの活用
とはいえ、技術的なハードルは一番深刻な問題ではありません。API管理ツールを活用することで、技術的な問題の多くは解決できます。API管理ツールは、近年注目が集まっており、主要なIT ベンダーが自社、もしくは買収によってAPI管理ツール・サービスを提供しています。IBM、CA Technologiesが力を入れているほか、GoogleがAPIgeeを買収、OracleがApiaryを買収、Red Hatが3scaleを買収、TIBCOがMasheryを買収、近くはSalesforceがAPI管理を含む複合データ連携ベンダーであるMuleSoftを約7000億円で買収しました。私が所属するCData Softwareでも、CData API ServerというライトウェイトなAPI管理ツールを提供しています。これらのツールはワンストップでAPI開発・運用までの必要な機能を提供してくれます。
