APIを持たない企業なんてインターネットにアクセスできないコンピューターのようなものだ
Pocket

いくら高速なプロセッサーと最高のディスプレイを備えたコンピューターでも、インターネットに接続できなければ使い物にならないと思われてしまう。近いうちにこれと同じようなレッテルが、デジタル社会に接続するためのAPI(Application Programming Interface:アプリケーション同士が通信するためのインタフェース)を持たない企業に対して貼られることになるだろう。

ソフトウェアが全ての産業を変えていく中で、接続性の不足は「欠陥品」と同義になりつつある。APIとはデータを通じて目的とプラットフォームをつなぐ導線であり、優秀なアプリケーションほど洗練されたAPIを数多く備えている。ソフトウェア開発者達をロック・スターに例えれば、APIとは彼らの音楽を奏でる楽器にあたるのだ。

この表現は若干オーバーに思われるかもしれないが、決してそんなことはない。私は自社の技術が孤立することなくあらゆるものと連携することで、人々の生活をもっと豊かにしてほしいと思っている。それがAPIの目的であり、他者との結合による利便性の向上なのだ。

あなたの企業も新たな結合のチャネルを模索しなければ、あらゆるものが接続されていく未来のデジタル世界では孤立して居場所がなくなってしまうだろう。無数のビジネス・プロセスを管理する企業ERPの話をしているわけではない。企業がAPIを導入することで様々な可能性が広がることを紹介したいのである。新しい顧客を開拓したり、手軽な支払い方法を増やしたり、迅速に人を雇ったりすることもできる。またAPIを使って大切な記録を残したり、写真や処方箋を近くのドラッグストアから注文することも可能になるのだ。

もちろんAPIは開発面でも大きな役割を果たしている。外国株の交換大規模なソフトウェア・プロジェクトの管理、新しい家電の開発など、様々なプロジェクトがAPI(および同類のソフトウエア開発キット)を通じて共同的に展開されている。開発者のコミュニティーは有機的な事業開発や研究開発チームを形成しており、参加企業とその技術を新しく刺激的な方向に導いてくれるのだ。

これまでの孤立した企業風土を脱却し、APIを導入したオープンなサービスを展開することは難しく感じられるかもしれない。これまで独自のサンドボックスに守られていた自社のサービスや情報を第三者に公開することは恐怖を伴うかもしれない。あなたの企業をこの問題に立ち向かわせるのに必要なステップを以下にご紹介しよう。

初期支援を獲得するため、ニーズを掘り起こす

外部との接触が増えることがメリットになるような部署を探し、そこの重役とミーティングをしてみよう。予め、「他部署や外部の戦略パートナーに対して自社の『コンテンツ、システム、データ』へのアクセス権を与えるプロジェクトを検討しているのでフィードバックが欲しい」と伝えておくと良いかもしれない。

ミーティングでは、自社の『コンテンツ、システム、データ』が公開されることによってどのような収入源が新たに期待できるかを話し合おう。重役から出た意見はメモしておき、その後フォローをすると良いだろう。企業の中枢にいる人物にAPIの可能性について理解してもらうことは非常に重要だ。

エンドユーザを定義し、それに合わせたプランを作る

公開されるAPIは社内で利用されるのだろうか?それとも社外か、あるいは両方か?また、公開の手順はどのようなものが良いだろう?次のようなプロセスは典型的な悪い例である。

1. 大きな会社ほど、APIを社内限定で使おうとする。部門間のシステムやワークフローの結合のみを前提としてAPIの設計を行う。

2. その後外部パートナーから相互の利益のためにそのAPIを使いたいとの申し出があるが、セキュリティー上の問題があるため第三者に公開できない。

3. 第三者用のエコシステムを提供するためにAPIを設計し直す必要に迫られ、わずかなカスタマイズのために数ヶ月を要してしまう。

4. 関係者は皆、何故最初から社外利用を視野に入れずにAPIが開発されたのだろうかと、ここで改めて不思議に思う。

自社APIを開発する際には、よほどはっきりとした理由が無い限り、当面の必要がないとしても外部連携を前提に作るべきである。

ステークホルダー(利害関係者)を増やす

自社の資源を外部に公開するのは恐ろしい。社内の恥をさらすことになるかもしれないし、抜け穴があればパッチする前に乱用されてしまうかもしれない。強力な支持者を見つけておき、困難に直面した際には助けてもらえるようにしたいものだ。ステークホルダー達には会社にとっての長期的なメリットを思い出してもらい、リリースに伴う問題に対しては事前に理解を得られるようにしておこう。APIはプロダクトとして扱うべきものなのだ。

管理用のポータルをセットアップする

他のソフトウェア関連プロジェクトと同様に、社内で開発するか外部の専門家に委託するかを議論する必要がある。今では様々な利用ケース(搭載、課金から利用レポートに至るまで)に対応した頼もしいAPI管理サービスも存在している。こういったサービスはわかり切ったことを最初から構築する手間を省いてくれるだろう。

加えて、こういったサービス提供者はポータルのホワイトレーベル化(自社のブランド持たず、委託元のブランドを利用できる)に対応しており、(developer.COMPANYNAME.comのようなドメインを使った)パブリックな開発プログラムの構築も可能だ。

ドキュメントとサンプル・コードを提供する

APIを使用するための、正確で完全なドキュメンテーションが開発者に提供されることも求められる。一般的な導入ケースでは、開発者が誰かに問い合わせたりしなくても提供された情報だけでツールの実装を完了できることが重要だ。さらに、開発者がより困難で特殊なコーディングに専念することができるよう、一般的な機能を実行するためのサンプル・コードが提供されていることが望ましいだろう。

専任担当者をアサインする

APIプログラムは「作って終わり」ではない。ドキュメントを絶えず更新し、サポートへの問い合わせにも答えていく必要がある。そして対象となる開発者コミュニティーに、プラットフォームの実装への正しい理解をもってもらうことが必要だ。これら全てを有効に行うには副業では難しいため、専任の担当者が必要となるだろう。

開発者とのコミュニケーション・チャネルを確立する

仮にAPIが社内専用だとしても、開発者の質問に答えられるようフォーラム・サイトを開設するべきだ。そしてフォーラム内の情報を利用してドキュメントの更新も行う必要がある。パブリックなAPIについては主要なアップデートとパートナーの採用事例などを包括的に共有できるよう、専用のブログとソーシャルメディア・アカウント(少なくとものツイッターのアカウント)を持っているべきだろう。

イベントを開催する

APIをただ作っただけでは使ってもらえない。開発者を増やすには、カンファレンスへの参加、ワークショップの開催、スポンサー付きの参加型ハッカソンやオンラインのチャレンジイベントなど、様々な戦略を組み合わせることが必要だ。社内用のAPIについても、社内でハッカソンを開催するなどして従業員たちがAPIの利用に挑戦すれば、会社の利益に繋がるはずである。

採用事例とマーケットプレイスを作る

人々は自分の仕事の功績を見てもらいたがるものだ。APIを使って作られた様々なアプリケーションを紹介するギャラリーを作ったり、アプリケーションのマーケットプレイスを通じたレベニューシェア(収益分配)を提供するといいだろう。成果物を見せることで他の開発者を触発し、APIのさらなる利用を促すこともできるはずだ。社内用のAPIであればプライベートなギャラリーを作ればいい。

成功を皆で共有する

自社のAPIが成功をおさめた暁には社内のあらゆる協力者たちと成功を共有してほしい。開発、マーケティング、商品開発などの他部門からの協力が、今後のAPIの躍進には欠かせないからだ。

ここで改めて問いたい。あなたの企業は制度の壁を取り払い、APIを通じてオープン化を実現できるだろうか。それともインターネットに接続できないコンピューターと化してしまうのだろうか。

編集者注:この記事はChallengePostの事業開発責任者であるブライアン・コールズ氏によって執筆されました。

Pocket