この10年以上、組織はデジタルトランスフォーメーションを加速するため、APIに多額の投資を行ってきた。APIは、企業がデータを公開し、システムを接続し、パートナーシップを可能にし、デジタル製品を提供するための仕組みとなっている。
だが、APIが企業全体により深く組み込まれるにつれ、新たな課題が浮上していると筆者は見ている。もはや難しいのはAPIを構築することではない。大規模組織全体でAPIデリバリーをスケールさせることだ。
多くの組織は、少数のエンジニアリングチームからAPIへの取り組みを始める。コミュニケーションは直接的で、責任範囲は明確であり、デリバリーサイクルは迅速に進む。各チームは何を誰が所有しているかを把握し、アーキテクチャ上の意思決定は素早く行え、依存関係も管理可能な範囲にとどまる。
しかし、組織が成長すると、このシンプルさは失われる。
新たな事業部門がAPIを立ち上げる。追加のエンジニアリングチームがエコシステムに加わる。プロダクト部門は独自の標準やデリバリープロセスを整備する。時間の経過とともに、数十、場合によっては数百のチームが組織のAPI環境に関与するようになる。
その段階で課題は、APIの作成から、大規模なAPIデリバリーの調整へと移る。
成長が摩擦を生む理由
APIデリバリーのスケーリングは主に技術的な問題だ、という誤解に筆者はしばしば出会う。
組織は、ガバナンスの追加、レビューの増加、承認プロセスの厳格化によって一貫性が高まると考えがちだ。ガバナンスは依然として不可欠だが、過度な統制はしばしば逆の結果を生む。
関係者が増えるほど、デリバリーは遅くなる。
チームは、承認ワークフローへの対応、依存関係の調整、複数のレビューグループとの整合に、より多くの時間を費やすようになる。一部の組織では、エンジニアがAPIを提供する時間よりも、APIについて議論する時間の方が長くなることさえある。
その一方で、組織内では重複が生じ始める。似たような機能が別々のチームによって開発される。ドキュメントは断片化する。発見可能性は低下する。チームは、自分たちが必要とするサービスがすでに社内の別の場所に存在していることにさえ気づかない場合がある。
その結果として生じるのが、チームが増えるごとに膨らんでいく「調整のコスト」だ。
プラットフォーム思考への移行
APIデリバリーを最も効果的にスケールさせている組織は、必ずしも最も多くのガバナンスを持つ組織ではない。
むしろ、プラットフォームに投資している組織である。
すべてのチームに同じ問題を個別に解決させるのではなく、こうした組織はAPIデリバリーを簡素化する共通機能を提供する。共通の設計標準、再利用可能なテンプレート、自動化された品質管理、開発者ポータル、CI/CDパイプライン、セルフサービス型ツールが、すべてのチームが活用できる共通基盤をつくる。
このアプローチは、中央のAPIチームの役割を変える。門番として振る舞うのではなく、実現を支援する存在になるのだ。その目的は、もはやすべてのAPIに関する意思決定をレビューすることではない。良い意思決定をしやすくすることである。
この違いは重要だ。
中央集権型のチームがスケールできる範囲には限界がある。プラットフォームは組織全体にスケールできる。
中央集権化なき標準化
組織が犯す最大の過ちの1つは、一貫性には統制が必要だと思い込むことだ。
実際には、成功しているAPIプログラムは標準化と自律性のバランスを取っている。
チームには、共通の実践、共有ツール、明確な期待値が必要だ。同時に、サービスを独立して提供し、自らの事業領域が求めるペースで動く柔軟性も必要である。
目標は、APIの所有権を中央に集約することではない。
実際、そのモデルが企業規模で成功する例を筆者はほとんど見ない。
最も効果的な組織は、複雑性を減らし一貫性を高める共有インフラを提供しながら、各チームが自分たちのAPIの所有権を保持できるようにしている。
これにより、ボトルネックを生むことなく足並みをそろえられる。
セルフサービスが競争優位になる
APIエコシステムが拡大するにつれ、セルフサービスの重要性は増していく。
開発者は、手作業による介入を待つことなく、APIを発見し、ドキュメントにアクセスし、連携をテストし、サービスをデプロイできるべきだ。チームが中央集権的な承認プロセスに依存すればするほど、デリバリーの速度を維持することは難しくなる。
可視性もまた重要になる。
チームは、どのAPIがすでに存在し、誰が所有し、どのように進化しているのかを理解する必要がある。明確な所有権と発見可能性がなければ、重複は増え、組織の知識は断片化する。
この問題を効果的に解決する組織は、開発者体験を後付けではなく戦略的能力として扱っている。
API成熟度の次の段階
長年にわたり、APIリーダーは設計標準、ガバナンスフレームワーク、ライフサイクル管理に注力してきた。
こうした領域は今も重要である。だが筆者は、API成熟度の次の段階は別のものによって定義されると考えている。すなわち、ますます複雑化する組織全体でデリバリーをスケールさせる能力だ。
もはや問いは、組織がAPIを構築できるかどうかではない。数十、あるいは数百のチームが、不要な摩擦を生むことなく、ともにAPIを構築できるかどうかである。
成功する企業は、最も多くの統制を持つ企業ではないと筆者は考えている。おそらく成功するのは、チームが足並みをそろえながらも独立して動ける環境をつくる企業だろう。
結局のところ、APIデリバリーをスケールさせることは、チームを統制することではない。チームを可能にすることだ。
そしてAPIがデジタル製品、インテグレーション、事業運営を支え続けるなかで、その違いは、組織が築き得る最も重要な優位性の1つになるかもしれない。
