こんにちは。ContractSでバックエンドエンジニアをしている毛見です。
弊社がAPIファースト開発を取り入れた背景や利点、実際のアプローチを整理してブログにしました。
契約ライフサイクル管理 (CLM: Contract Lifecycle Management) は、単なる電子契約、契約書の保管という枠を超え、営業、法務、財務、購買などの多様な業務との連携によって業務の統制や効率化を図ります。昨今の企業では、業務ごとに専用のSaaSや基幹システムを導入しており、これらのシステムとシームレスに連携することがCLMに求められています。
私たちは、この連携を柔軟に実現するために APIファーストのアプローチを採用しています。この記事では、その利点や実践内容、得られる効果についてご紹介します。
APIファーストとは？
APIファーストとは、システムやサービスの設計・開発において 「まずAPIを定義することから始めるアプローチ」 です。このアプローチでは、APIを単なる技術的なインターフェースではなく、システム全体の基本構造として捉えます。
参考: Postman What is API-first?
APIファーストの利点
利用者視点のインターフェース設計
APIの定義を先に行うことで、フロントエンド、他システム、外部の開発者の視点を意識した設計が可能になります。それにより他システムやパートナーとの連携が迅速で容易になります。
ノーコード／ローコードでシステム構築ができる世界を実現する
APIの定義において、RESTやOpenAPI（Swagger）などの業界標準を採用することで、ノーコード／ローコードでの連携が可能になり、外部システムやSaaSとの連携がスムーズになります。
柔軟なユースケース対応
ビジネス要件に応じてAPIを再利用・組み合わせることで、多様なユースケースに柔軟に対応できます。新しい製品やサービスを迅速に立ち上げる際にも、APIファーストの設計は大きな強みとなります。
APIファーストをどのように取り入れているか？
設計フェーズと実装フェーズ
APIの仕様書を作る方法として、実装後にコントローラーから生成する方法があります。それに対し、APIファーストの開発では、まず設計フェーズでAPI仕様をOpenAPIで記載します。記載したAPI仕様について開発者、プロダクトオーナーで合意し、テストケースを作成します。この時点で、外部サービスとの連携、既存のWebサービスで利用できるAPIとなるように検討を済ませます。その後に実装フェーズに移ります。
既存のWebアプリケーション用のバックエンドからストラングラーフィグパターンで移行する
ContractS ではAPIファーストを取り入れる以前のWebアプリケーション用のバックエンドサービスが存在します。そのバックエンドサービスには仕様が蓄積されていますが、外部サービスとの連携を考慮していないため、APIとして公開できません。そのため、公開も可能なAPIサービスとして作り直す必要があります。そこで、機能ごとにストラングラーフィグパターンで新たなAPIに移行をしました。既存のバックエンドサービスは移行先のAPIを呼ぶようにし、BFF(backend for frontend)として振る舞うことで、フロントエンドへの影響を最小限にとどめながら移行が可能になります。
テストと品質保証の自動化
実現の途中ではありますが、CI/CDによってAPIのE2Eテストを自動化し、相互運用性の担保を行います。これによりWebアプリケーションだけでなく、連携先のAPIに対しても品質を保証することができます。
ビジネス的な効果
顧客への導入提案において、Webアプリケーションだけでは実現が難しい要求に対し、API連携を利用した実現方法を提案できるため、「APIを使ってできます」と言えるようになります。 また、他システムとの連携について詰めていく中で、想定外の要件がでることもあるかと思います。そういった時に、特定のユースケースのためのAPIではなく、汎用的なAPIとして設計してあれば、それを組み合わせるだけで追加開発の必要なく要件に対応することができます。
最後に
契約ライフサイクルは、さまざまなシステムとの連携なしには成り立ちません。そのため、私たちは APIを核に柔軟な連携基盤を構築しています。これにより、顧客の多様な業務要件に応え、契約管理の効率化を推進しています。
実現途中のAPIのE2Eテストについてもブログ化を検討していますので、楽しみにしていただければと思います。
ContractSでは一緒にプロダクトを進化させていくエンジニアを募集中です。
