APIを製品として扱うという考え方は、API業界で急速に普及しており、組織はAPI開発において製品管理の原則を適用することのメリットをますます認識しています。このアプローチでは、チームが提供する他のソフトウェア製品と同様に、APIポートフォリオにも同じレベルの注意と計画を適用します。
これは、最近開催されたNordic API Austin API Summitでも人気の高いコンセプトでした。会議では、このトピックに関する多数の講演が行われました。これには、Vanick DigitalのPete Clare氏による「APIの価値を引き出す鍵としての製品化」や、PaypalのRahul Dighe氏による「API as a Product文化の組み込み」が含まれます。
SmartBearは3日間のイベントの誇り高いスポンサーであり、私は多くの講演者や参加者とこのトピックやAPI分野の他の多くのトレンドについて話す機会がありました。このインタビューでは、APIVistaのCTOであるChris Busse氏に話を聞きました。彼はクライアントがAPIを設計、公開、サポートするのを手伝っています。2年前にChrisと同様のインタビューを行ったので、再び彼と連絡を取り、前回話してから彼が得た新しい洞察を見るのは素晴らしいことでした。
Chrisは、APIへの製品アプローチの長年の提唱者であり、このアプローチに伴う課題と機会について直接学びました。会話の中で、私たちはAPIを製品として扱うことの重要性、「デザインファースト」API開発の役割、およびAPIVistaでの彼の仕事を通して彼が観察した他のトレンドについて議論します。
以下の完全な会話を視聴し、お読みいただけます
APIVistaのCTOであるChris Busse氏をお迎えできることを嬉しく思います。Chris、これまでの会議はいかがでしたか？
素晴らしかったです！セッションで特に高く評価したのは、APIを製品として扱うことに重点が置かれていたことです。それは私の心に非常に近いものです。それは、クライアントとの仕事でも、以前の仕事でも、API設計にアプローチする方法です。
「地滑り」という言葉が適切かどうかはわかりませんが、このコンセプトに関する議論がますます増えており、APIを製品として扱うという理論を共有するだけでなく、実際に成功を共有できる人が増えているのを目にしています。
「こうすべきだ」と言うのは一つのことです。しかし、「私たちはこのようにして成功を収め、そこから学んだことを共有します。私たちが苦労したことを踏まえて、皆さんが適用できること、そしてより早くそこにたどり着く方法をご紹介します」と言うのはまた別のことです。
あなたは「契約ファースト」、または「デザインファースト」のAPIアプローチを強く提唱していると承知しています。デザインファーストの考え方が製品アプローチにどのように適用されるか、詳しく教えていただけますか？
デザインファーストの考え方は、APIへの製品アプローチにおいて非常に重要だと思います。なぜなら、誰のためにデザインしているのかを知る必要があるからです。過去1年間、APIVistaで開発者を募集し、成長する中で学んだことの一つは、API開発者は大きく3つのグループに分類できるということです。
最初のカテゴリは、もしかしたらフルスタックで働いている人です。彼らが構築しているそれらのAPIは、本当に彼ら自身のためです。Angularフロントエンドに公開するためか、モバイルフロントエンドのためかもしれませんが、彼らがAPIを構築しているのです。その分野だけで働いている開発者は、APIを製品として捉えるという概念についてあまり意識していないかもしれません。
その進捗における次のレベルは、APIを構築している開発者で、おそらくユーザーインターフェースやフロントエンドは担当していませんが、すぐに振り返って話せる人がいます。この場合、APIは彼らが知っている人々のためのものであり、理解するためのケアやドキュメントのレベルは必要なく、価値は口頭で伝えることができます。APIを製品として扱う際にしばしば話されるような、精度のレベルを必要としないかもしれません。
3つ目のタイプは、身近な人以外の人のためにAPIを構築する場合です。それは、組織図のどこに位置するのかさえ知らない大企業の誰かかもしれませんし、まったくの部外者であるパートナーかもしれません。
APIを製品として考えるとき、人々は一般的にAPIという言葉を使い、「APIは製品であるべきだ」と言いますが、私には、その製品化には時と場所があると思います。そして、見知らぬ人のためにAPIを構築している場合、そのときこそ製品思考が重要になります。最終消費者が今や私たちの顧客なのです。
消費に関するコンテキストを持つことも重要です。最終消費者は開発者ですが、その開発者はあなたのAPIを別の顧客のために使用しています。したがって、その点についても認識を持つ必要があります。APIをパートナーに公開しているクライアントの一部で使い始めた言葉は、「共同創造」という概念です。私たちは、顧客のために何かを一緒に共同創造しているのです。
ですから、私はあなたがどのように私のAPI製品を消費するのかを理解する必要があるだけでなく、それがどのようなビジネス価値をもたらすのかを知りたいと思っています。あなたがユーザーのためにどのようなユーザーエクスペリエンスを創造しているのか？そうすることで、私も「それによって私のバックエンドシステムにどのような影響があるのか？」と考えることができます。そして、それはインターフェースに関係していますが、パフォーマンスやそれらのAPIの非機能要件も含まれます。
その最終消費者のビジネスサイクル、つまりビジネスサイクルに季節性があるのか、トラフィックの急増があるのかを知っているだけでも、提供するもののあらゆる側面と、APIが公開する必要のある機能を考えるのに非常に役立ちます。
APIの製品思考には多くの労力が必要であり、その思考の影響を最大化したいものです。それは、それを考える非常に興味深い方法であり、製品思考を適用するためのフレームワークも提供してくれると思います。
製品を持つためには、顧客が必要です。もし自分自身のために構築しているなら、はい、あなたは自分自身の顧客です。自分が何をしたか、なぜそれを行ったかについてメモを取る必要があるかもしれませんが、顧客と一緒に活動しているわけではありません。ですから、私はAPIを製品として扱うことに興奮しているのと同じくらい、常に最も価値のあるところに労力を費やすことを忘れないようにしたいと思います。
デザインファーストの考え方は紙の上では素晴らしいものですが、企業はプロセスの実際の導入において現実的な課題に直面しています。あなたの経験から、デザインファーストの導入における最大の課題は何だと思いますか？
それは大変な作業です！以前、クライアントの一社では驚くほど上手くいったケースがありました。そこでは、いくつかのチーム間に既に強固な関係が構築されていました。彼らはビジネス目標に関して非常に足並みが揃っていました。このケースでは、私たちは皆、共通の「北極星」目標に沿っていました。そのため、ユーザーインターフェースチームとミドルウェアチームまたはAPIチームが構築する共通のAPI契約があっただけでなく、彼らがビジネスとして認識している共通の「北極星」目標があり、両者が同じ目標に向かって取り組んでいました。その逆を考えると、人々が少しサイロ化しすぎている場合です。
世の中には、成功をバックログストーリーの完了と見なす組織があります。しかし、それは日々の作業から顔を上げ、成功とはビジネス価値と顧客価値を提供することであるということを思い出すことです。
そのとき、人々が本当に「北極星」の目標に沿って、契約ファーストのアプローチがそれを可能にし、調整と高品質の製品を可能にするツールであると認識するならば、そのアプローチでの成功が見られるでしょう。
以前お会いした会議で、クライアントのユースケース例についてお話しされていたと記憶しています。もう少し詳しく教えていただけますか？
その例では、バックエンドが構築されているのと同時に、モックAPIに対してユーザーインターフェースが並行して開発されているという話でした。チーム間には、最終的に両者が連携して正しく動作するという大きな信頼がありました。顧客を理解し、その後全体をMVPとして構築する方が、より多くの成功を収めています。これが、API公開の観点から見て、より一般的なユースケースだと思います。
Chris、ありがとうございました。これらの教訓を共有するために時間を割いてくださり、本当に感謝しています！
お読みいただきありがとうございます！さらにAPIリソースをお探しですか？Swaggerニュースレターを購読してください。最高のAPI記事、トレーニング、チュートリアルなどが毎月メールで届きます。 購読する