はじめに
フロントエンドは自社、バックエンドは他社という体制で、業務支援系のプロダクトを開発しました。
フロントエンド側はアジャイル開発の実践としてスクラムを採用していましたが、実際には「バックエンド待ち」や「API仕様の食い違い」による手戻りが重なり、スプリント進行に影響が出る場面もありました。
この記事では、私が実際に調整に関わった経験をもとに、フロントエンドとバックエンドの分離開発で起きたAPI連携の問題と、他社との依存関係（API）をどう整理し、解消したかを、実務ベースで解説します。
結論
今回の経験で特に重要だったのは、変更コストの大きいものと小さいものを分けて扱うことです。
別会社連携では、APIの利用用途・型・開放基準のような依存関係こそ、実装前に合意しておくべき対象でした。
想定読者
- フロントエンドエンジニア / Webエンジニア
- 他社ベンダーと連携して開発している、またはこれから予定している人
- 「アジャイルで進めているはずなのに、バックエンド待ちが多い」と感じたことがある人
プロジェクトの前提
開発体制
- フロントエンド：自社開発（Vue 3 / TypeScript）
- バックエンド：他社開発（REST API）
- フロントエンドはスクラム、バックエンドはウォーターフォール寄り
- API仕様書はSwaggerで共有
- プロダクトオーナーは別組織に存在し、フロント・バックエンドと合わせて三者で連携するトライアングル構造だった
私は開発者として参加し、加えて過去の経験をもとに他社調整も担当しました。
制約・前提条件
- リリース日は固定で、延期できない
- バックエンドの体制・プロセスには直接介入できない
- フロントとバックエンドは別リポジトリで並行開発
- フロントとバックエンドは、プロダクトオーナーとそれぞれ個別に契約しており、相互に再委託関係はない
- 両社間の直接的な取り決めは秘密保持契約のみで、仕様や責務を拘束する契約は存在しない
API仕様の食い違いで実際に起きていた問題
開発中は、Swaggerを見ながら「この前提で実装できそうだ」と判断して進める場面が多くありました。
ただ、APIは開放されるまで実際のレスポンスを確認できないケースも多く、前提がずれていてもその時点では見抜けません。
実際に開放されてから確認すると、次のような問題が見えてきました。
- APIの利用用途に認識齟齬があった
- 想定していた型と実際の型が異なっていた
- API開放の基準がフロントとバックエンドでズレていた
なぜここまで発見が遅れたのかを振り返ると、次の条件が重なっていました。
- API開放前に実レスポンスを確認する手段がない
- Swaggerは共有されていたものの、変更履歴や差分が追えない運用だった
- API変更の通知がSlackのテキスト連絡中心
その結果、API開放の段階で不確実性が一気に表面化しました。
実装をそのまま前に進めることが難しくなり、まず認識合わせを行ってから調整に入る流れとなりました。
API仕様を契約として扱えていなかったことが原因
この状態になった理由を振り返って整理すると、原因は次の4点に集約されました。
- API開放タイミングで仕様や型がまとめて変更されていた
- API仕様を契約として扱えていなかった
- 契約構造上、フロントとバックエンド間で仕様を拘束する仕組みがなく、合意の強制力が弱かった
- 「いつ、何が確認できるか」が不明確なまま進んでいた
こうしたズレを整理していく中で、問題の本質は単なる仕様不一致ではなく、
変更コストの高い領域の整理を後回しにしていたことにあると気づきました。
状況や原因の確認にもコストがかかり、開発以外の調整負荷がじわじわと増えていきました。
API連携を安定させるためにやったこと
原因が見えてきた段階で、「まず何を整えるべきか」を絞って対応しました。
- API開放の基準を明確化
- フロントから呼び出し可能で、本番同等に使用できる状態
- 開放されたAPIは、すぐにレビューとフィードバックを実施
- フィードバックが想定通りAPIに反映されているか、刈り取りを徹底
- フロントデザインの変更について、バックエンド側でも確認してもらう運用に変更
上記を踏まえて、進め方も変えました。
- 問題が起きてから調整するのではなく、齟齬が起きる前提で調整ポイントを先に置く
- 窓口担当だけでなく、開発者同士で直接確認する場を設ける
このように進め方を変えた結果、細かな齟齬は発生しつつも、
スプリント内で解消できるケースが増え、大きな遅延は発生しなくなりました。
また、バックエンド待ちで完全に手が止まる状況も減らすことができました。
「変更コスト」の観点で整理する
ここまでの経験を踏まえて、同じ苦労を繰り返さないために整理すると次の通りです。
変更しやすいもの
- UIや画面構成
- フロントエンド内部の実装
- 表示文言やレイアウト
変更コストが大きいもの
- APIの利用用途
- レスポンスの型・構造
- APIの開放基準・タイミング
特に他社が関わる部分ほど、後から変えるほど調整コストが大きくなると実感しました。
この経験から得た学び
特に初期段階で不十分だったと感じているのは次の3点です。
- APIの利用用途を明示的にすり合わせなかった
- API開放前の確認方法を決めていなかった
- 契約的に進める部分と探索的に進める部分を分けていなかった
結果として、変更コストの高い部分を走りながら決めてしまい、手戻りを招きました。
今振り返ると、APIまわりもUIと同じ感覚で扱ってしまったのが問題でした。
フロントは探索的に、バックエンドは契約的に進めるといった切り分けが必要でした。
まとめ
今回の経験をまとめると、次の3点に集約されます。
- 変更コストの大きいものは先に決めるべき
- アジャイル開発は「先に決めない開発」ではない
- フロント自社×バックエンド他社では、依存関係をどう扱うかが重要になる