キーポイント
- Identify which approach to your API program makes the most sense for your team and the benefits/drawbacks of each approach.
- The most important thing is to ensure positive experiences for all stakeholders including the end-user, the developer and the company (a design-first approach and customer-centric language is key to this).
- Viewing your API as a product saves time, expands revenue opportunities, increases collaboration and innovation.
- A focus on decentralized governance, increased automation and consistency through style guides will improve your API program by minimizing complexity for API consumers.
- There are guidelines and patterns for taking a design-first approach to API development
世界の名作について、ちょっと考えてみましょう。
シェイクスピアの"ハムレット"。ダビンチの"モナリザ"。フランク・ロイド・ライトの建築美である"落水荘(Fallingwater)"。ビバルディの"四季(Four Seasons)"協奏曲。まだまだあります。私としては世界最高のピックアップトラックなども含めたいところですが、このくらいにしておきましょう。
これらの名作に共通するものがひとつあります — デザインを第一に考えて作られた、"デザインファースト"である、ということです。設計図なしで家を建てられないように、ダビンチもまた、何の準備もせずに"モナリザ"は描けなかったに違いありません。
"デザインから始める"というのは新しい考え方ではなく、世界中の偉大なクリエータたちが世代を越えて実践してきたことなのです。しかしながら、アプリケーションプログラミングインターフェース(API)の"デザインファースト"アプローチは、そうではありません。
"何だって？"と思われるかもしれませんね。説明しましょう！
ディジタル経済の爆発的な発展により、世界には現在、2,700万人のソフトウェア開発者がいます。この数は、2030年には4,500万人を優に超えるだろうと言われています。今日、これら開発者中の1,900万人はAPI開発者です。アプリケーション開発ソフトウェアの市場規模は、2027年には現在の196パーセントにまで成長すると予測されています。読者の皆さんはどうか分かりませんが、私はこれを重要な市場だと考えています。
このようなAPI産業の急速な発展の中では、より多くの開発者や技術リーダたちが、API開発を成功させる方法について知る必要があります。これら重要な役割を担う人たちには、ビジネス価値を高めるような、堅実で、よくできた、スケーラブルなAPIプログラムの構築に必要なものを理解することが、これまで以上に求められているのです。
では、何から始めましょうか？考慮すべき、最も重要なファクタは何でしょう？
複雑な部分は確かにありますが、ここで私が伝えたいのは、デザインファーストのアプローチでAPI戦略を始めることが最も重要なファクタである、ということです。次の名作APIは、開発者である私たちの手中にあります — まずは、それをデザインしなくてはなりません。
API戦略へのアプローチ
ビジネスに有用なAPIのすばらしいアイデアが手元にあります — さて、次は何をしましょうか？
まずAPIに関するビジネス要件を書き上げて、次にコード開発に進む、という方法もあります。あるいは、OpenAPIのような仕様言語でAPIを記述する、ということを最初に決めるかも知れません。自分のアイデアをAPIファーストなプロダクトにするように、会社に働きかけることもできるでしょう。どれにしますか？
では、最も一般的なアプローチ — コードファースト、APIファースト、デザインファースト — について、それぞれの利点と欠点を確認してみましょう。
- コードファースト: 開発者がAPIを早く提供する必要のある場合は、ビジネス要件を受け取った後、すぐにコーディングに取り掛かることで、APIのデプロイメントをスピードアップできます。APIのエンドポイント数が少なければ、これが最も手っ取り早い選択肢となることもあります。コードファーストは、言ってしまえば、完全に開発者本位で、他の潜在的APIユーザには無関心な方法です。
コードファーストのアプローチが問題なのは、この方法で優れた設計のAPIが開発できたとしても、最終的には失敗する運命にあることです。APIの成功は、より多くのユーザによって採用され、利用されることに基づくものだからです。APIの採用が進むにつれて、新しいユーザの大半は、開発者や技術に関心のある人たちではなくなります — ただ、問題を可能な限り早く、効率的に解決しようとする人たちが占めるようになるのです。APIが直感的でなく、そういった人たちの状況に適さないものであれば、一般的な人には使用してもらえないでしょう。
- APIファースト: 最近多く使用されるようになったアプローチです。基本的には、APIが組織運営上の重要なビジネス資産であることを理解した上で、APIをコアフォーカスとして扱う、ということを意味しています。このプロセスは、OpenAPIなどのAPI仕様言語で記述されたコントラクトから始まります。この方法自体には何の問題もありません。プラットフォームやプロダクトセット全体を標準化するのは賢明な方法です。問題なのは、選択した言語とその特殊性が、企業の将来的な拡張性や構築能力を支配し、さらには制限してしまう点にあります。APIが最重要事であるならば、そのAPIを開発する人たち、あるいは使用する人たちは、一体どんな存在なのでしょうか？
- デザインファースト: このアプローチは基本的に、すべてのAPI作業が — プログラム内のひとつであれ、多数であれ — 設計プロセスから始まることを意味します。このモデルでは、人とコンピュータの両方が理解できる方法で、APIを反復的に — コードを書き始める前に — 定義します。その目標は、すべてのチームが同じことばを話し、使用しているすべてのツールが同じAPI設計を活用することです。APIファーストアプローチとの大きな違いは、APIを最重要視しながらも、デザインプロセスにすべてのステークホルダが関与することによって、全員のニーズが開発時に満足される、という点です。
デザインファーストはまず、API(あるいはAPIセット)の目的と機能を定義するコントラクトを記述するプロセスに、関係する技術者と非技術者の両方が参加することから始まります。当然ながらこのアプローチには、事前にある程度の時間をかけてプランニングを行う必要があります。このフェーズは、コーディングを始める段階になった時に、開発者が書いたコードを後で破棄して改めて書き直すようなことにならない、ということを保証するためのものです。これは価値のあるAPIを反復的に開発する上で有用であって、その結果が全体として、拡張性のある優れたAPIを、さらにはビジネス価値を生み出すことにつながるのです。
どのアプローチを選択するにしても、何よりも優先して考慮しなくてはならないのは、エンドユーザ、サードパーティあるいは社内開発者、さらには社内で役割を持つかも知れない他の人々も含むステークホルダに対して、ポジティブなエクスペリエンスをいかに提供するかということです。内部接続と外部接続のネットワークを構成するという意味から、私は、APIは"テクノロジ・アンバサダ"だと考えています。その意味からもAPIは、企業が提供する他のプロダクトやサービスと同じように、細心の注意を払って設計し、作成しなくてはなりません。
よくできたAPIプログラムは、早い段階からユーザの協力を獲得し、デザインプロセスに参加してもらうことによって、ユーザの期待に沿った開発を可能にしています。内部APIでも外部APIでも、このプロセスは同じように重要です。デザインプロセスに関わるユーザの多くはアーリーアダプタになることで、初期段階においてプロダクトが受け入れられ、使用されるようになるための推進力になります。
API開発におけるデザインファーストアプローチの利点
'でも、Steve！'と、読者の皆さんは言うかも知れません。'このアプローチは開発者やエンドユーザ、社内パートナなどに対しては、どのようなメリットがあるのだろう？' — よい質問です。最も価値のあるAPI開発資産 — 開発者から話を始めましょう。
- 開発者エクスペリエンスの改善: デザインファーストアプローチには多くのメリットがありますが、その中でも特に重要(あえて言えば、最もバジー(buzzy))なのは、ポジティブな開発者エクスペリエンスの創造です。私自身が開発者としてのキャリアを歩んできた者のひとりとして言えるのは、出来の悪いAPIを修正する仕事は悪夢である、ということです。
意図を持った設計がなければ、開発プロセスはカオスで不格好な、つながりのないものになりかねません。開発者、セキュリティ、ガバナンス、ドキュメントの各チーム間に断絶が生じます。結果として、API開発を最後まで遂行しようとする開発者の肩には、大きなプレッシャが圧し掛かることになるのです。
デザインファーストアプローチを採用すれば、API仕様、ガバナンス、デザイン、開発、ドキュメントが同じページから始まり、同期を確保してメンテナンスされるようになります。このような連携を組み込むことで、開発者はソリューションに集中できるようになり、APIをクリーンアップする作業による開発速度の低下を避けることができるのです。デザインファーストは開発者フレンドリでもあります。出来の悪い、一貫性を欠いたAPIに開発を邪魔されたり、作業が遅れたりすることなく、成果に向けて労力を集中し続けることが可能になるからです。最終的には、開発者の幸せ = ハッピーなAPIプログラムなのです。
- エンジニアリング効率とコスト削減: デザインファーストアプローチを使用した品質の高いコンポーネントが開発され、メンテナンスされれば、今後のAPIで再利用することができます。それぞれのコンポーネントを一度だけ開発すればよいので、開発チームの時間と費用の大幅な削減が可能になります。コスト削減だけではありません。すべてのコンポーネントに再利用性があれば、新しいAPIの市場投入も速くすることができます。
- APIのセキュリテイ向上: APIはここ数年で開花したテクノロジですが、その公開性と、設計上の欠陥や脆弱性の多さから、ハッカーやマルウェアの恰好の標的になっているのも事実です。設計が適切でなければ、公開されたAPIエンドポイントはハッカーにたやすく悪用されてしまいます。私はテクノロジリーダとして、セキュリティを常に最大の関心事に置いています。セキュリティをゼロからAPI戦略に組み込むためには、それを意図した設計を行うことが必須です。
- 内部チーム間の連携の強化: 大規模でクロスファンクショナルなチームは連携が難しい、とよく言われます。その間にステークホルダを加えて、全員が同じ意見を共有するのは、さらに困難です。このアプローチでは、関係するステークホルダが最初から関与することによって、API開発に自らの意見を反映することが可能になります。非技術者のAPIユーザも含むすべてのステークホルダを対象とすることによって、APIが包括的であり、考え得るすべてのニーズに対応できることが保証されるのです。
- イノベーションと成長機会の拡大: APIは成長、イノベーションの進展、ユーザエクスペリエンスの向上を促進する存在です。高価で非効率なプロセスを脱して、開発者とユーザにとって、さらには最終的な成果の面で、より効果的なプロセスに移行することは、思うほど難しいものではありません。Developer Surver 2020のレポートによれば、今日の大企業の40パーセント以上が、250を超えるAPIを運用しています。その継続的な成長の機会は増える一方で、2,000件の新たなAPIが日々公開されていると推測されています。
APIが幅広く開発されるようになったことで、現在では世界中のあらゆる産業、分野、地域に影響を与えるようになりました。APIはテクノロジ間の(その名の通り！)統合ポイントとして、自動車メーカから医療に至るまで、あらゆる企業に普及しています。例えば、当社の最大ユーザ中の一社は世界的なビール会社なのですが、"後難を顧みず"に言ってしまえば、APIの設計や開発のリーダとして真っ先に思い描くような企業ではありません。
私たちは、イノベーションの最も重要な機会の多くが — 業界や官民の区別を問わず — APIを通じて与えられている、ということを、冗談抜きで知っています。そのためにも、APIが成長に合わせて拡張できるように、正しい設計をすることが重要なのです。
デザインファーストは本当に機能するのか？
なるほど、"デザインファーストがAPIプログラムのゲームチェンジャである"という、私のことばを信じたくないのかも知れませんね。ですが、それを物語る実例はいくつかあります。
Transactは、キャンパスサービステクノロジ企業です。同社は、APIプログラムにデザインファーストアプローチを採用することで、APIの開発時間を80パーセント削減しました。(ほら、先程話した時間効率とコスト削減の話、覚えていますか？)
"開発時間の削減にも増してすばらしいのは、デザインファーストアプローチを使うことによって、他のチームとのコラボレーションが充実したことです。フィードバックを早く得られるようになりましたし、結果もより洗練されたプロフェッショナルなものになりました"と、TransactのシニアエンジニアリングマネージャであるPaul Trevino氏が教えてくれました。
もうひとつ、ミーティングスケジューリングソフトウェアのCalendly(実を言うと、私も使っています)にはAPIチームがあって、デザインファーストアプローチを使って、まったく新しいAPIプラットフォームを開発しています。
"私たちにとってデザインファーストアプローチは、高品質な実装、一貫性、ガバナンス、そして、常に最新のドキュメントを実現してくれるものです。これはAPIの開発側と利用側、両方の開発者に対して間違いなく言えることです — 常に最新で高品質、かつ詳細な、成熟したプラットフォームに期待されるメリットをすべて備えたドキュメントを提供してくれます"と、同社アプリケーションアーキテクトのDmitry Pashkevich氏は説明しています。
デザインファーストアプローチの実践方法
さて、ここまで長々と私の話にお付き合い頂いたということで、読者の皆さんはおそらく、この素晴らしいデザインファーストアプローチのひとつを自分自身の組織にどうやって導入すればよいのか、という話題に移る準備ができていると思います。分散型ガバナンス、オートメーションの拡大、スタイルガイドのようなツールを通じた一貫性といったものは、デザインファーストへの道へとあなたを導くと同時に、APIコンシューマに対する複雑性を最小化することによるAPIプログラムの向上を実現してくれるでしょう。
一貫性とグッドガバナンスから始めよう
名声や評価がなくても、少なくとも一貫性を持つことは可能だと言われます。Starbucksのような企業が成功するのには理由があります — 期待できるものは何か、分かっているからです。世界中のどの店舗に入ってもエクスペリエンスが予測可能である、というのは快適です。
Starbucksのような現実のヒューマンインタフェースで真実であることは、APIでも真実です。APIのデザインを一定に保つことは、予測可能なエクスペリエンスを持つ、ということなのです。Stoplightなどの企業が言うように、単なるAPIの寄せ集めと、ひとつのプラットフォームと感じられるものとの大きな違いは一貫性です。
一貫性を確保して、十分に考え抜かれた設計を維持するためには、API戦略にガイドラインを導入することによる標準化の実施が有効です。APIスタイルガイドラインは、開発者あるいは開発チームがAPIの開発や運用を行う上で必要なすべての関連情報について、簡単に利用できるように説明した手順書です。一般的なスタイルガイドリファレンスでは、APIの基本的な理解や概要に加えて、組織においてAPIを開発、導入、適用するためのベストプラクティスを提供しています。
一貫性とともに必要となるのが、APIプログラムに対する強力なガバナンスです。ガバナンスを考慮した設計を行わなければ、標準化はすぐに頓挫してしまうでしょう。APIガバナンスとは、APIに説明やコントラクト、デザイン、プロトコル、レビューといったルールとポリシを適用することです。APIの設計におけるこのような標準化は、多くの開発者が設計や開発に携わった場合において、APIの一貫性を確保する上での一助となります。効果的なガバナンスプログラムは、API数の多寡に関わらず、すべてのAPIの品質と検出性を担保する上でも有用に機能します。
プロダクトとしてのAPI
デザインファーストアプローチを適用する次のステップは、APIをプロダクトとして認識することです。API・アズ・ア・プロダクトは、すでに確立されたソフトウェア開発コンセプトで、その認知も広がりつつあります。本質的には、誰かが使用する他のプロダクトと同じような視点でAPIを運用する、という意味になります。APIもプロダクトと同じように、簡単に利用できて、積極的なメンテナンスやサポートを行うことが必要なのです。
API設計のプロセスには、プロダクト開発で行うようなプランニングやアーキテクチャ判断が含まれています。API設計がユーザエクスペリエンスを定義するものであることや、優れた設計原則が初期の要件を満足すると同時に、一貫性と予測性を持った動作を継続するものであることも、プロダクト設計と同じです。
ステークホルダの支持を得る
デザインファーストアプローチの最も重要な部分のひとつが、関係するステークホルダの支持を得ることです。デザインファーストアプローチを運用する上で、これは大きなポイントになります。APIプログラムの基礎を作るには、開発者の支持、経営層の支持、初期エンドユーザからのフィードバック、APIに関与する可能性のあるパートナや社内関係者の意見、といったものが必要になります。
ビジネスリーダを説得するために私がお勧めするのは(意外な話ではないでしょうが)、ビジネス価値を重視すること、理想的には、確実な基準と概念実証を含むことです。当初は最小限のデータしか示せないとしても、そこからの連鎖を手繰ることで、時間を掛けて改善していけばよいのです。その勢いが、ボールを転がすように自らを語ってくれるでしょう。支持を得られたならば、この使命をどうやって組織変革へとつなげていくか、そのために必要なキーパーソンは誰か、といったことを考えましょう。
開発者を説得するには、彼らが安心して意見を述べられる場や、動作を確認できる場を(当然ですが、ガイドラインを設定した上で)提供することです。開発組織の中で影響力を持ったステークホルダを探して、自分のAPI戦略について彼らとコラボレーションする方法を確立しましょう(恐縮ですが、それには"API Design"ツールを使うのがベストです)。APIプログラムチームは、幅広い経験とユースケース、そしてスキルを備えた、多能的なチームでなければなりません。
そして最後に、アーリーアダプタやエンドユーザから、APIを実際に使用したエクスペリエンス(全体)についてのフィードバックを受け取ることを忘れないでください。APIは使用されて初めて役に立つのだ、という点を忘れてはなりません。そのためには、肯定的なエクスペリエンスであることが必要です。開発者は時にエンドユーザエクスペリエンスの視点を見失うことがありますが、デザインファーストのアプローチによって、このことを常に念頭に置くようになります。
納得して頂けましたか？
デザインファーストの発見に参加して頂いて、ありがとうございました。健全で、堅牢で、拡張の容易な — さらに言えば、あなたの傑作である — APIやAPIプログラムを実現する上で、デザインファーストが要であることを理解頂けたならばと思います。(私の忠告に耳を貸さないというのであれば、デザインファーストアプローチに従わないとどうなるかを説明しましょう。)
その上で、もし何らかのガイドが必要であるならば、(僭越ながら)StoplightのAPI設計に関するリソースをお勧めします。
総論として、APIは今や世界を席巻しており、多くの人たちが自身のビジネスを改革し、成長させるプログラムの構築方法を探っているのですが、ここまでの説明で、デザインファーストでなければAPIの傑作は生まれない、ということを理解頂けたと思います。
私個人は、開発者を世界最高のデザイナであり、クリエータであると思っています。デザインファーストアプローチを念頭に置くことで、次にどのようなものが開発されるのか、楽しみでなりません。