開発したAPIを広めるために行っていきたい施策を紹介します。ただ漫然と公開すれば良いのではなく、より広めていくための活動を行ってこそ、APIを使ったビジネス化が実現できるようになるでしょう。
自分たちが率先して使う
開発したAPIを外部企業に使って欲しいと待っているだけではダメです。そのAPIを自ら使って新しいビジネスの可能性を見せなければなりません。少なくとも基幹システムの中で使ったり、サーバサイドのレンダリングだった部分をAPIベースに置き換えると言った利用が考えられます。
自ら使うことでAPIの問題点を知ったり、改善に繋げられるようになります。使い方によっては未知のエラーが発生したり、機能の過不足に気付かされることでしょう。
事例を作る
逆説的ではあるのですが、率先してリスクをとって挑戦していく企業は希です。多くは先鞭をつけた事例を見て、自社への適用法を考えることでしょう。そのため、事例がなければ誰もが躊躇してしまうはずです。
自社自ら事例を作ることもできますし、パートナーへ依頼して事例を作ってもらうこともできます。なお、その際には事例として掲載することを予め承諾を得ておくと言ったことや、事例化することによるメリット（メディアへのパブリッシングなど）を明確にしておく必要があります。多くの場合、APIを利用したという事例化によるクライアント側企業のメリットは多くありません。
頻繁な更新と機能追加
更新が途絶えたAPIは誰も使いたいと思わないでしょう。APIという特性上、あまり更新が頻繁なのも考え物ですが、それでもトレンドに合わせた機能追加やパフォーマンス向上をしていくべきです。
互換性の維持と機能追加は矛盾することもありますが、バージョン管理を意識した運用も考えるべきです。
ドキュメントの充実
APIの利用法は、内部の人にすれば常識的であったり、察するレベルだったりするかも知れません。しかし外部の開発者にとっては全くの未知なるもので、簡単なドキュメントを読んだだけですべてを理解するのは不可能です。
ドキュメントは徹底して充実させなければなりません。APIはシステム向けのものなのでついSwaggerなどで自動生成したものだけになりがちですが、他にもチュートリアルやサンプルなど、提供すべきドキュメントはたくさん考えられます。
使えるサンプルコードの提供
一言でサンプルコードと言っても多くのパターンが考えられます。まずHello World級の簡単なものが考えられます。これは基本です。次により実践的なコードが考えられますが、これが大きな問題になるでしょう。
あまり複雑なものは開発者が理解するだけでも大変であったり、本質的ではないコードも増えてしまいます。かといって提供側の視点だけでサンプルを書くと、あまり使い物にならないコードができてしまうでしょう。これは利用者の意見を聞きつつ、使えるコードは何かを考えていく必要があります。
利用開始までの敷居を極力下げる
多くの利用者が増えないAPIは利用開始までのステップがとても多いことが問題です。Slackはチャット連携アプリケーションが爆発的に増えましたが、その大きな要因となったのは利用までの手軽さだったと言えます。
複雑な仕組みが必要な場合は専用ライブラリであったり、SDKの提供が欠かせません。ただしその場合はソフトウェアの使い方を覚えたり、そもそもの開発コストがかかってしまうのが難点と言えます。
なるべくシンプルに、すぐに使い方を覚えられて使いこなせる、そんなAPIを開発すべきでしょう。
APIによるビジネス変化は待っていければ起きるものではなく、自分たちから率先してアクションを起こしていかなければなりません。開発が必要である以上、よほどのメリットがなければ利用しようと考えないはずです。
相手にとっての利便性を第一に考えた上で、APIの仕組みや利用までの手順、サポートなどを充実させていきましょう。
