API・外部システム連携の要件定義。つなぐ前に知っておくべき「技術的・費用的」な制約
最近の IT化 プロジェクトでは、「自社システムと会計ソフト（freee等）を連携させたい」「CRM と LINE を繋ぎたい」といった、外部システムとの連携要件がほぼ確実に入ってきます。
しかし、 ITリーダー が注意すべきは、 「連携できる」というベンダーの言葉には、多くの『ただし書き』がついている という点です。要件定義の段階でこの細部を詰め切らないと、開発の後半で「実はリアルタイムでは繋がらない」「連携のたびに別途費用がかかる」といった問題が噴出します。
1. 連携の「向き」と「タイミング」を定義する
外部連携において、最もトラブルになりやすいのが「いつ、どちらからデータを送るか」です。
- 一方向か、双方向か: A から B に送るだけなら比較的シンプルですが、 B で更新された内容を A に戻す（双方向同期）となると、開発コストとバグのリスクは 3倍 以上になります。
- リアルタイムか、バッチ（定時）か: 「ボタンを押した瞬間に反映」させるリアルタイム連携は、通信エラー時のリトライ処理などが必要になり、非常に高価です。実務上は「 1時間 に 1回 」「深夜に 1回 」で十分なケースが多いので、過剰な要件になっていないか精査してください。
2. API の「制約」を事前に確認させる
相手が有名な SaaS であっても、連携には必ず制限があります。
- 回数制限（レートリミット）: 「 1日に 1,000回 まで」といった制限がある場合、大量のデータを一度に送ろうとするとエラーで止まります。
- データの項目不足: 「名前は連携できるが、住所のフリガナは相手側の API が対応していない」といった、項目レベルの不一致が必ず起きます。
ITリーダー は、ベンダーに対して「相手側の API 仕様書を確認し、自社の要件が 100% 満たせるか調査してください」と、要件定義の初期段階で指示を出すべきです。
3. 「保守コスト」という落とし穴
外部システム連携の最大の懸念は、 「相手側の都合で突然動かなくなる」 リスクです。
- 会計ソフトがバージョンアップして、連携仕様（API）が変わった。
- 連携先のサービスがメンテナンスで停止した。
これらが発生した際、誰が、どのくらいの速さで対応するのか。また、それによる改修費用はどちらが持つのか。この「運用・保守フェーズの責任分界点」を要件定義書に含めておかないと、リリース後にベンダーとのトラブルを招きます。
まとめ：連携は「疎結合」に考える
外部連携は便利ですが、依存度が高すぎると自社のシステムが他社の都合に振り回されることになります。
「どうしても自動連携が必要な項目」と「CSV の書き出し・取り込み（手動）で構わない項目」を冷静に仕分けること。連携要件を最小限に絞り込み、システム同士が 「つかず離れず（疎結合）」 の関係を保てるように設計するのが、賢い ITリーダー の仕事です。