API提供でよくある7つの失敗施策

API提供をしているのに、なかなか利用が伸びずに悩んでいるというケースを聞くことがあります。総じて提供側に問題があることが多いのですが、なかなか中の人では気付きづらいようです。

そこで今回はAPI提供におけるよくある問題点を挙げてみたいと思います。

APIだけ提供する

これはよくあるケースですが、APIを提供すれば勝手に利用が伸びていくと思っているケースです。実際にはそんなことはありません。例えば各言語向けのライブラリであったり、サンプルコードがないと、使ってみたいと思えないはずです。

ライブラリやSDK、Developer Kitと呼ばれる類のソフトウェアについてはなるべくオープンソースで公開しましょう。そうすることで何か困ったことがあってもコードを見つつ、開発者が自己解決できるようになります。

ドキュメントの不整備

APIの最低限のドキュメントしか用意されていないケースも問題です。ドキュメントはどれだけあってもありすぎると言うことはありません。すべてを見る人は多くなく、実際には検索エンジンで探してきてくれることの方が多いはずです。

これはライブラリについても同じで、ライブラリのクラス/APIドキュメントも用意しましょう。これらはJavaDocやPHPDocumentorといったツールから自動生成されるものを使うと良いでしょう。

質問できない

どんなによくできたAPIであっても使っていると質問が出てくるものです。そんな時に聞ける場所が用意されていないのは大きなマイナスです。なるべくオープンな場所で聞けるようにしてあげましょう。

そして質問が来たら放置せず、中の人が積極的に答えるようにしましょう。Q&A形式でのナレッジの蓄積は個々だけでなく、それを閲覧している人にとっても大きなコンテンツとなっていくはずです。

汎用性がない

APIを見て、どう考えても一つしか使い方の考えられないものも数多くあります。提供側の意図はAPIを通して見えてくるもので、自社の利益ばかり考えるようなAPIは誰も使いたいと思わないでしょう。

かといって、あまり汎用性が高すぎる（何でもできる）のも問題です。中のエンジニアとしての設計技量次第かも知れません。

更新されない

APIは作って終わりではなく、定期的なメンテナンスが欠かせません。それを止めてしまったAPIは開発者からもあっという間に見放されてしまうでしょう。

定期的な開発を可能にするのは、APIにビジネス的メリットが見いだせるかどうかにかかっていると言えます。自社と開発者のメリット、そのバランスがとれてこそAPIとしての成功が見えてくると言えるでしょう。

独自仕様

認証が独自仕様であったり、開発が面倒なものを誰が使いたいと思うでしょうか。世の中にはすでにデファクトになる技術がたくさんありますので、そういった流れに乗ったAPI設計を行うべきです。

独自仕様の場合は使いやすくするライブラリが必須と言えます。デファクトがなかったとしても、認証やフォーマット、セキュリティ周りなどにおいて標準仕様を取り入れることはできるはずです。

利用制限が厳しい

ビジネス用途でもない限り、利用制限はなるべく撤廃しましょう。もちろん無制限に使える必要はありませんが、1日に数十人が使ったらリミットになってしまう程度では面白くも何ともないでしょう。

ビジネス用途のAPIにおいてもパートナー契約しなければ仕様すら見られないというのでは問題があります。サンドボックス環境を用意するなど、試せる環境は用意すべきです。

APIは通常のWebサービスとは異なり、広め方に苦労することがあるかも知れません。そのためにもまずアンチパターンはなくすべきです。

自社の提供するAPIがこれらに引っかかっていないか、ぜひ見直してみてください。

画像はCrossroads: Success or Failureより。