見出し画像
Photo by hidesanspiral

API戦略とAPIプロダクト

Sachiko Kijima

APIはソフトウェアとソフトウェアをつなぐもの、開発者向けのインターフェースなのですが、単純にAPIがあればステキなことが起こるかと言うとそうではありません。ステキなことはみずから起こさないと起きません。

すべてのソフトウェアはなんらか現状を変えるために作られたり機能追加されたりしています。企業で言うとコスト削減とか売上向上とか、なんらかのリスク対策などです。

そう言った文脈で開発をするAPIクライアントの開発者にとっては、対応すべき課題があり、候補となる解決策があり、解決策を用意するためのパーツとしてAPIを使うわけです。

API提供側がAPIクライアントの開発者の目的達成を効果的に支援することができると初めてAPIは大きな価値があると認識されます。
選ばれるAPIプログラムとは、APIクライアントの開発者が目的が達成できるよう、上手く作られています。

実際に非常にうまくやっているAPIプログラムの話をいくつかご紹介したいと思います。

William Hill

「自社の視点では出てこない新しいものを外部で作ってもらいたい」というAPI公開が少し前に流行った時期がありました。
これをうまく仕組み化したのがWilliam Hillです。

William Hillはご覧の通りオンラインカジノです。
オンラインカジノはインターネットが一般的になった直後からずっとあったので競争が激しく、目新しいゲームをいかに効率的にリリースできるかが売上を左右するそうです。

このためWilliam HillはAPIを公開されているのですが、面白いのは開発者のサポート体制です。

例えばAPI Glossary (用語集) や

セキュアなプロダクトを開発する秘訣

認証モデルなど

つまり、「目新しいアイデアを持っている人が必ずしも優秀なAPIクライアント開発者であるとは限らない」と言う前提に立っているわけですね。したがってアイデアはあるがAPIクライアントの開発の知見が足りない人へのサポートが提供されています。

Twilio

Twilioは電話回線をAPIを経由して使わせてくれるサービスです。例えばSMSや音声通話など。

TwilioはAPIの使いやすさに定評があり、広告キャンペーンでも「Ask your developer」キャンペーンがありました。電話回線をプログラムの中で使いたいならどこが良いかは開発者に聞け、ということですね。

ではどの程度使いやすいのか。

神戸市の事例

まずは事例です。この事例は大好きで、アジャイル化で目指したい姿としてご紹介することがあります。
以下にリンクしたニュースの音声による自動応答がTwilioを使っているそうです。6/5にリリースされたとのこと。

開発した経緯などはこちらのインタビュー記事が詳しいです。

給付金の配布がいつ決まったか覚えていらっしゃるでしょうか。GW直前なんです。あいにくと当時の給付金決定の記事は見つけられませんでしたが、GW明けには配布に関する条件などを公開したものが見つかっています。

GW明けから開発をしたとしても開発してリリースまでに1ヶ月です。でも実際は電話を受け始めてボリュームを確認してから対策をしていることがインタビューに記載されていますので、もっと開発期間は短かったはずです。

実際に自分で考えてみた

実際に自分でこれを作ることを考えながらTwilioのAPIを調べてみた時の記事がこちら。私はコールセンターのシステムの知見があるのですが、その状態でTwilioのAPIのドキュメントを調べると5分くらいで「なんとかなりそうだな」という感触を持つことができました。

"Ask Your Developer"

このようにAPIクライアント開発側が電話回線を使って何かをしたいと思った時に短時間で「できるぞ！」と思うようなインターフェースになっていることで、「では早速作ってみよう」と行動に移ることができるメリットがTwilioのAPIにはあります。

Twilioもそれを認識しているので「Ask Your Developer」といえるのです。

社内向けAPIの場合でも同じ

社内向けAPIでも同じです！

とある会社のシステムを分析したところ、基幹システムとのインテグレーションのためのコネクタが非常に複雑なロジックを保持していたことがありました。
周辺システムが20個あったら、単純計算して20回同じ機能が開発されており、それだけコストがかかっているわけですね。

また使いこなすにはAPIクライアント開発側はAPI提供元に何度も質問をして習熟しなければならない点も習熟コストとしてプロジェクト期間に影響しますし、API提供側としても対応要員をそれだけ確保しなければなりません。

社外に代替できるプロダクトがある場合は、「会社の中にあるはあるんですが、使い勝手が悪いので理由をつけて社外のものを使いましょう」という意思決定になることがあります。
実際自分が過去に所属していたプロジェクトもそうでした。限られたプロジェクト期間と費用を有効活用しようと思った場合、どうしても社内のプロダクトを選択することができませんでした。

つまり高コスト体質になるとか、せっかく作ったのに使ってもらえないとか、そういう結果になるわけです。

API as a Product & デベロッパーエクスペリエンス

「ワールドクラスの体験を」とまでは申しません。API設計の際にも、APIクライアントの開発側の事情や体験にも思いを馳せてみてください。

近年はAPIの設計にUXデザインの手法を取り入れようという動きが活発になっています。
JPMorganChaseでは自社の取り組みを発表されています。(プレゼンテーションのPDFはこちら。)
普通にAPIプログラム全体のプロダクト開発のベストプラクティスにのっとって実施されていることがわかります。

上手く取り入れることで設計の手戻りや後日のバージョンリリースの頻度を削減したり、使い勝手の悪さを効果的に防ぐことができます。おすすめです。


この記事が気に入ったらサポートをしてみませんか？