フロントエンドとバックエンド間のギャップを埋めること。

フロントエンド向けのBFFのAPI仕様を決定
- フロントエンドのAPI仕様に基づいて、必要なデータやエンドポイントを定義する
- 成果物:
  - 要件定義書
  - API仕様書（YAML or JSONでも代用可能）
  - アーキテクチャ設計書
  - シーケンス図（業務ロジックが少ないので複雑なAPIのみ作成）
  - セキュリティ設計書
  - テスト計画書
  - 開発環境設定書
  - プロトタイプ
フロントエンドへのMock提供準備
- フロントエンドの開発が滞らないようにフロントエンド向けにBFFのAPI仕様に基づいたMockサーバやMockデータを提供する
- 成果物:
  - Mockサーバ設定（YAML or JSONから生成可能）
  - Mockデータファイル
BFFの設計書を作成
- BFFのAPI仕様を記載した設計書を作成する
- 成果物:
  - API仕様書（YAML or JSONでも代用可能）
BFFのAPIを開発
- API仕様を実現するため、バックエンドのAPIを適宜呼び出し、データを加工してフロントエンドに提供するBFFのAPIを実装・テストする
- 成果物:
  - プログラムファイル
  - 設定ファイル（YAML or JSON）
  - テストケース

やることと成果物は以上。
ただ、実際に開発を進めると思い通りに進まないことが多い。

事項からは現実的なBFFの仕様決定における立場と
その環境下での想定される現実的な開発の流れを考えてみる。

フロントエンドの機能を実現するため、フロントエンド、BFF、バックエンドのエンドポイントを決定する必要がある。
ただ、BFFはフロントエンドとバックエンドの間に位置し両者の仕様に依存するため、
BFFがエンドポイントを決める主導権を握ることは難しい。

想定されるエンドポイント決定の流れは以下の1～3のパターン。
一般的には3になることが多い。
ローコード開発やパッケージ開発により、
生産性が高い、変更への耐性が強い、API仕様があらかじめ決まっているなどの特性があれば1や2が採用されることもある。

フロントエンドからAPI仕様を決める:
フロントエンドの要件に基づいてAPI仕様が決まる。
この場合、フロントエンドの開発者が必要なデータやエンドポイントを定義し、その後バックエンドとBFFが実装される。
バックエンドからAPI仕様を決める:
バックエンドの要件に基づいてAPI仕様が決まる。
この場合、バックエンドの開発者が提供するデータやエンドポイントを定義し、その後フロントエンドとBFFが実装される。
フロントエンドとバックエンドが同時並行してAPI仕様を決める:
フロントエンドとバックエンドの開発者がAPI仕様を決定する。
両者の要件をバランスよく取り入れることができ、ボトルネックを回避しやすい。
また、仕様決定待ちによる開発のボトルネックを回避できる。

「フロントエンドとバックエンドが同時並行してAPI仕様を決める」場合における開発の流れを考える。

フロントエンド向けのBFFのAPI仕様を決定
終わりが見えず最も難しい作業。
API仕様の策定に必要なフロントエンドとバックエンドの要件を収集する。
要件に従いAPI仕様を策定する。
ただし、フロントエンドとバックエンドの要件は開発過程において
修正中やそもそも未作成など、仕様が未確定であることが多い。
その場合、なんとなくの入力と出力に基づいてAPI仕様を策定する。
フロントエンドへのMock提供準備
なんとなくの入力と出力に基づいた作成するMockになるので
フロントエンドのエンドポイント変更に対して迅速に最新を提供する。
BFFの設計書を作成
本来の設計書作成だけでなく、フロントエンドとバックエンドのAPI仕様の修正に合わせて
随時、設計書を修正する。
BFFのAPIを開発
本来の実装・テストだけでなく、フロントエンドとバックエンドのAPI仕様の修正に合わせて
随時、実装・テストを修正し、再テストを実施する。

BFFの開発で一番苦労するのは1. 仕様把握であると感じる。
仕様変更による手戻りは不可避と考えてBFFの開発では基本的なこと以外を用意するのが良さそう。

以下の対策を考えていきたいと思う。
「仕様変更の影響を受けにくい考え方」：
業務に依存しない非機能や絶対に変わらない機能の大枠でAPI仕様を作成。
「仕様変更に対応しやすい仕組み」：
仕様変更の対応手順の作成や補助ツールなどを用意して仕様変更にすぐに対応できる方法を用意。