Kindle で APIs: A Strategy Guide を読みました。 150ページ弱の洋書なので、あまり気負わずに読むことができました。
REST API の実装方法、みたいな書籍は多いですが、この本は API の実装ノウハウではなく、Strategy - 戦略についての本である点が珍しいと思います。 著者は３人ですが、その内のひとりは Apigee の CTO なので、技術的にも変なところもなく丁寧で読みやすかったと感じました。 組織として API ビジネスを考えるときに検討すべき事柄が網羅されていますので、 2011年の発行から２年ほどが経過しても、とても参考になる１冊でした。
API というと実際に機能を実装することに目がいきがちですが、 戦略を決定する人にこそ読んで欲しい書籍です。 ターゲットとする読者に関しては次のように書かれています。
this book is designed for the people who need to make the strategic decisions about whether an API is a good idea for their company.
今後数年間で API 経由で公開する／すべきデータは増えるでしょうから、 この本を参考にして API の方向性を考えていけると良いのではないでしょうか。
全体の構成
まず、目次は次のようになっています。
- １章： The API Opportunity
- ２章： APIs as a Business Strategy
- ３章： Understanding the API Value Chain
- ４章： Crafting Your API Product Strategy
- ５章： Key Design Principles for APIs
- ６章： API Security and User Management
- ７章： Legal Considerations for Your API Strategy
- ８章： Operating and Managing an API
- ９章： Measuring the Success of Your API
- １０章： Engaging Developers to Drive Adoption
- １１章： Epilogue: Just the Beginning
本書の最初の方では：
this book is not a programming manual but about a best practices manual
つまり、単なるプログラミングの教科書でありません。 API となぜ向き合っていくか、 その中で何を重要視するか、 そして、それをどのようにして運用していくか、という流れになっています。 ソフトウェアの機能だけでなく、法務面への配慮、評価方法、コミュニティ運営など、 非常に多岐にわたるチーム活動に言及されています。
なお、API とだけ言うとソフトウェア内のインターフェイスも指しますが、 本書では Web API を扱います。 ネットワーク越しにコンピュータが会話する方法のような意味合いです。
API の考え方
API を使う人は３種類考えられます。 "provider", "developer", "end user" です。 provider と developer を明確に分離することで、アプリケーションが粗結合になります。 アプリケーションの画面とそこに表示するデータを分離する、とも言い換えられます。 アプリケーションが粗結合になることで、複数のアプリケーションで共通のデータを利用できます。 これにより、パソコン用の Web ページとモバイル用に最適化されたページ、各 OS 向けのアプリケーションを平行して開発できるでしょう。 こうした事情により、アプリケーションと API には次の関係が成り立ちますね。
APIs can be thought of the "backend" of an app.
API のプロバイダーからすると：
They innovate on the frontend and we can innovate on the backend with our API as the content provider.
また、ビジネス上の戦略を達成するのみならず、システムアーキテクチャが改善されるという嬉しい副作用も期待できます。 これは、インターネットを介して API を公開 (Public) せずとも、社内のように閉じた空間 (Private) だけに制限した場合にも有効です。
しかし、注意も必要です。 そもそも API を介して何を公開するのかをよく検討しなければなりません。 書籍内では "Business Assets" と表現していますが、独自性や競争力のあるものでなければ、 せっかく公開した API が使われることはないでしょう。 API に対して何かしらのビジョンを持つ必要があります。
戦略を練る上では次の６つ：
- Business strategy
- Implementation strategy
- Technology strategy
- Operational strategy
- Promotional strategy
ターゲットに訴求する上では次の３つ：
- Why should a developer use your API?
- How is it different from other alternatives?
- Why should they use it?
こうしたことを念頭においてチームでビジョンを共有できると良さそうですね。 どんなに間違っても、「みんな」がターゲット、「あらゆる」アプリケーションのため、といった事態は避けましょう。
API を構築するには
技術的には様々な選択肢がありますが、実際問題として普及しているのは：
- 導入が容易である軽量な API
- REST, Pragmatic REST
- バージョニングできるようにしておく
いずれにしても次の基本原則が重要となります。 実装期限に追われているときはついつい曖昧な状態を残してしまいがちですが、 多くの人が携わるときは特に重要になる考え方ですね。
it is better to be incomplete than inaccurate
(不正確よりは不完全な方がマシ)
API は単に機能を提供すれば完了となるわけではありません。 様々なリスクを管理する必要があります。 quota をかけて流量を制限したり、セキュリティへの配慮も欠かせません。 場合によってはエンドユーザーの個人を識別する必要があるかもしれません。 扱うコンテンツによっては所有権や著作権も関わってくるでしょう。
こうした課題を解決する一助として、多様なフィルターを用意します。 本書では次の４つが挙げられていました。
- Query-level filtering
- Story-level filtering
- Asset-level filtering
- User permissions
さらに、作って終わり、ではありません。 継続的なサービスを提供するためには運用 (operation) も重要です。
operations is not only about technology - it's also about support and commnication.
(運用とは技術面だけを意味するものではありません。サポートやコミュニケーションも含みます)
契約形態によっては SLA (Service License Agreement) も必要でしょう。 どの数値を監視すべきか、障害発生時の連絡フローは？ といったことも事前に決めておきたいですね。 毎週、能動的に更新情報やコミュニティ活動を周知する (Publish a weekly dashboard) こともひとつの方法です。 エラー率、エラーの種別、システム稼働率、リクエスト処理の遅延状況やタイムアウトなどの報告があると嬉しいですね。 何と言ってもまずは可視化 (visibility) です。
you can't govern what you can't see.
(見えないものは管理できない)
それ以外に必要なもの
API を提供する上で大切なことは、単なる機能だけではありません。 開発者向けの導入資料だったり詳細なリファレンスも必要です。
Successful programs not only offer clear documentation but they also recognize that developers don't have a lot of time (or inclination) to sit down and reat it.
開発者向けのポータルサイトも必要でしょう。 API が何を提供するのか、どうやって使うのか、実際に使っている事例はあるのか、契約に関する事項はどこで確認できるか、 こうした情報はどんな種類の API にも必要なことですね。 もちろん見た目も重要です。Web サイトをデザイナーにお願いするのも有効な案でしょう。
これらは Public / Private を問わず大切なことです。 ある API が何にでも適用できる、そんなことはあり得ません。 どのような開発者に訴求するのか、そのためには何が必要なのか、 このような問いによって準備すべきものは変わってきそうです。
終わりに
APIs: A Strategy Guide を読みました。 Public にしろ Private にしろ、API はビジネス資産を表に出すものです。 ついつい技術的な手法にばかり目が行きがちですが、 そもそも何を目標としてどんなビジネス資産を扱うのか？ という問いは忘れないようにしたいものです。 戦略を実現する方策、価値を創造するツール、それが API の位置づけになっていくでしょう。
An API is a tactic for implementing a business strategy, a tool for creating business value.
今後はデータのオープン化の流れが進むでしょうから、企業だけでなく官公庁や自治体、公共機関にも API によるデータ提供が求められるようになるはずです。 本書や White House の例などを参考にして、DX (Developer Experience) の高い API が増えると良いですね。
0 件のコメント:
コメントを投稿