もはやAPIは技術要素ではなく、ビジネス価値を最大化する鍵
「APIは技術的な構成要素として誕生したが、今ではビジネスがどのように行われるかを定義するインタフェースと捉えることもでき、ビジネス的な意味で使われることも増えている」
こう手塚氏は語る。その背景にあるのは企業をとりまく環境の大きな変化だ。他業種からの新規事業への参入やグローバル化など、ビジネスの多様化、高速化が進んでいる。またIoTやAIなどによるモノ・コトのデジタル化、さらにはオムニチャネル化も進んでいる。「これまでは国内や自社業界のみのビジネスだったので、自社予測に沿ったシステム設計でよかったが、これからは他社に先んじて自社アプリを公開したり、他社と組んだりする必要がある。つまりスピード感を持ったエコシステムを作ることが、ビジネスにとって重要な課題になっている」と手塚氏は話す。
APIは他社とのパートナリング、マーケットや顧客に対するプロダクトの公開、社外リソースとの連携、社内システムの連携にも使われる。つまり「新たなビジネス価値を、他社よりも早く市場に届けるためには、APIをいかにうまく利用してうまく使わせていくかが大事になるのです」と手塚氏は提言する。
ビジネスエコノミーはもはや「APIエコノミーといっても過言ではない」と続ける手塚氏。APIはインタフェースではなく、アプリケーションの塊、プロダクトそのものであり、企業はバックエンドシステムをAPIの形で公開する。パートナリングや売り上げ向上のため、潜在的だったリソースを顕在化させる武器でもある。「エコシステムを構築し、ビジネス価値を最大化するためには、APIのうまい活用が非常に重要になる」と手塚氏は指摘する。
そのために重要になるのが、API公開後の運用である。APIライフサイクル管理はビジネス戦略を立ててAPIを設計するところから始まる。モックを作ってテストを実施し、実装、デプロイして、認証認可の仕組みなどを入れるなどセキュリティを担保する仕組みを入れて、管理する。公開されたAPIは、そのAPIを使いたい開発者によって発見され、利用され、それをモニタリングし、場合によっては課金する。「APIはエコシステムの根幹なので、公開して終わりというわけにはいかない。APIを作る輪と使わせる輪をくるくると回していくことが必要になります」（手塚氏）
だがこのようなライフサイクル管理を人の手でやっていくのは、非常に難しい。なぜならマイクロサービス化が進むことで、管理しなければならないAPIの数が増えていくからだ。「人力に頼らない仕組みを考えないと、作ったAPIが使われなくなり、ビジネスの価値を毀損することになる」と手塚氏は言う。
例えばインフラの世界では、パブリッククラウドの台頭により、ハイブリッドクラウドをはじめマルチ環境が当たり前になっている。そういう中で生まれてきたのが、「インフラ環境そのものをコード化する技術、Infrastructure as Codeです」と手塚氏は説明する。宣言的な手順をファイルに記載し、それを構築ツールに読み込ませることで、コードで記載された状態のインフラが構築される。これにより、ソフトウェア開発における品質管理のナレッジがインフラ管理にも適用できるようになる。つまりソフトウェアと同様にCI/CDで自動化が可能になるというわけだ。「Ansibleという自動化ツールであれば、宣言的ファイルがPlaybookとなり、Kubernetesならマニフェストファイルでリソースが管理できます」（手塚氏）
ちなみにCI/CDとはCI（継続的インテグレーション）とCD（継続的デリバリー/デプロイメント）の略語で、ソフトウェアの変更を常にテストして、自動で本番環境にリリース可能な状態にしておくソフトウェアの開発手法である。CI/CDを実践することで、バグを素早く発見したり、変更を自動で反映してリリースしたりできるようになる。「ユーザーに価値を届けるサイクルを早く回せるようにするためには、必須の技術要素です」（手塚氏）
APIをコード化し、自動で運用できる仕組みを構築
手塚氏は、このCI/CDとInfrastructure as Codeを、APIマネジメントにも適用した「API Management as Code」によって、APIライフサイクルを自動で回す仕組みを構築しようというのである。
設計、実装、テスト、デプロイ、公開、運用と流れていく一連のAPIライフサイクルをマネジメントする上で、どこからコードを取り込んでいくのか。その中でも重要な役割を果たすのが「OpenAPI Specification」。これを使って、APIの定義を行っていく。定義が決まったら実装し、テストをする。このテストを自動化するときにも、「OpenAPI Specification をうまく使うこと」と手塚氏は言う。さらにこういったテストやデプロイをCI/CDで安全に回していくためのプラットフォームとして、「コンテナを選択することが最近のベストプラクティスになっている」と手塚氏。公開時にはAPI管理製品を使ってAPIの整理やセキュリティのチェックが必要になるが、このAPI管理製品のコンフィグもコード化し、パイプラインから呼び出せるようにすべきだという。「設計から公開に関わる全てのリソースを、コードで定義できるようにし、かつGitでバージョン管理できるように実装していくこと。こういう仕組みが実現できれば、新規にAPIを公開するときはもちろん、APIの変更が頻繁に行われる世界になっても、安全に管理することができます」（手塚氏）
ここで手塚氏はCI/CDパイプラインでAPIをデプロイする際の5原則を紹介。この5原則の詳細は同社のブログ（英語）にも記載されているという。
1.コントラクトファーストなアプローチ（APIの定義から入っていくアプローチ）
2.テスト可能であること。特にAPIの性質上、対向するアプリケーションの開発者に受け入れてもらえる品質か、対向テスト（受け入れテスト）が非常に重要になる
3.セマンティックバージョニングを堅守せよ（メジャーバージョン、マイナーバージョン、パッチバージョンなどの定義をしっかり決めて運用に反映させる）
4.べき等性を保つこと（利用するAPI管理ツールのコマンドはべき等性が考慮されているか）
5.API Management as Codeの原則を適用すること（API管理に関する全てのリソースはGitで管理され、デプロイされる）
APIはコードから定義する場合だけではなく、コントラクトファーストレベルのインタフェースから定義するパターンもある。「マイクロサービスのように一つのAPIの独立性を担保させたい場合は、コントラクトファーストなアプローチが有用だと考えている。そういう意味でも、OpenAPI Specificationを使ったコントラクトファーストのアプローチで作っていくことを推奨しています」（手塚氏）
コントラクトファーストなアプローチを支援するツールも登場している。「Apicurio」はOpenAPI Specificationを作成するためのツール。ブラウザで起動し、GUIで簡単に作っていけるという。
対向テストに便利に使えるのがApicurio StudioとMicrocksの連携。これによりAPIのモックテストが簡単にできるようになる。加えて、CI/CDを実現するのに役立つ機能を提供するのが3scaleである。REST APIやCLIに対応しているツールに使うことで、APIゲートウェイでのAPI管理が容易にできるようになる。
「APIは企業や組織のプロダクトであり顔である。その価値を最大化するためにも、APIをコード化し、APIリリースサイクルを安全に回していくこと。APIの開発においては、このことを常に念頭に置いてほしい」と手塚氏は呼びかけた。
今回、手塚氏が登壇したのは、Women's Leadership Communityというグローバルで活動する同社コミュニティの日本のリーダー的存在の人にチャットで声をかけてもらったことがきっかけとなったという。レッドハットにはWomen's Leadership以外にもさまざまなコミュニティが活動を行っており、「登壇することでコミュニティや会社に貢献したいという思いがあった」と手塚氏は話す。
とはいえ、今回のような公開の場で話すのは勇気が必要になる。それを後押ししてくれたのが、レッドハットが大事にしているカルチャーの一つ「Courage：勇気」だったという。「常日頃から一歩を踏み出すという文化に触れていることが、登壇を後押ししてくれた」と語り、セッションを締めた。
