外部連携、
どちら側が悪いのか
分からない。

外部連携で問題が起きると、 最初はどうしても 自分の実装を疑います。

コードが間違っていないか。

値が入っているか。

JSONが正しいか。

呼び出し方がおかしくないか。

もちろん、 そこが原因のこともあります。

でも、 外部連携は 自分のアプリケーションだけで 完結していません。

自分の外に出た瞬間、
見る範囲が一気に広がる。

だから、 「何が悪いか」 をいきなり当てにいくより、 どこまで正しいかを 一つずつ確認する方が早かったです。

外部連携を見るときは、 一つの処理として見るより、 いくつかの境界に分けるようになりました。

• 自分のアプリケーション
• Request
• 認証
• ネットワーク
• 相手側のサーバー
• 相手側の処理
• Response

一気に全部見ると、 どこから手を付けるか分からなくなります。

でも、 ここまでは正しい。

ここから先が怪しい。

と分けていけば、 見る範囲を狭められます。

最初に見るのは、 やっぱりRequestです。

URL。

HTTPメソッド。

Header。

認証情報。

Body。

コード上では合っているつもりでも、 実際に送られる内容が 違っていることがあります。

「設定した値」ではなく、
「実際に送る値」を見る。

ここで問題が見つかれば、 相手側を見る前に 自分たちで直せます。

呼び出し側のコードからだと うまく動かないとき、 APIを直接叩くこともありました。

Postmanなどから 同じ条件で呼び出してみる。

そこで正常に動くなら、 APIそのものより 呼び出し側の実装を疑う。

直接叩いても 同じエラーになるなら、 API仕様や認証、 相手側も含めて見る。

同じものを、
別の経路から試す。

これだけでも、 どちら側を見ればいいか かなり分かりやすくなります。

Requestを送ったら、 次はResponseを見ます。

Status Code。

Response Body。

エラーメッセージ。

ここには、 次に何を見るべきかの 情報が入っていることがあります。

400系なら、 Requestや認証を見る。

500系なら、 相手側の処理や環境も疑う。

ただし、 500だから必ず相手側だけが悪い、 というわけではありません。

こちらから送ったデータをきっかけに、 相手側で例外が起きることもあります。

Status Codeは、
犯人を決めるものではなく、
次に見る方向を決めるもの。

ここが、 外部連携で一番大きかったところです。

自分のコードだけを ずっと見ても、 分からないことがあります。

実際、 一通り確認したあとに 500が返ってきて、

「サーバー側で何か起きてるのか？」

と相手に確認したこともありました。

すると、

「あ、ごめん。 テストで一回止めてた」

と言われたり、

「スケジュール入れてなかったっけ？」

となったり。

テストサーバーにアクセスが集中して 落ちていて、 再起動が必要だったこともありました。

そこは、
自分のコードを何時間見ても分からない。

外部連携には、 相手側にしか見えない情報があります。

だから、 必要なところまで確認したら 相手に聞く。

それも切り分けの一部でした。

画面上では、 「エラーになった」 しか分からないことがあります。

そういうときは ログを見ます。

Requestを送る直前まで来ているか。

相手に送信できているか。

Responseを受け取っているか。

Responseを受け取ったあとに 自分側で例外が起きていないか。

相手側のログが必要なら、 そこは相手に確認します。

「どこで止まったか」が分かれば、
見る場所も変わる。

外部連携では、 ロジックが正しくても 動かないことがあります。

認証情報が違う。

接続先が違う。

権限が足りない。

ネットワーク的に到達できない。

テスト環境が止まっている。

SFTPなら、 HostやPort、 Key、 接続方式なども見ることになります。

こういう問題は、 Javaのコードを追うだけでは 解決しません。

「コードが正しい」だけでは、
外部連携は動かない。

相手に確認するとき、 「動きません」 だけでは 相手側も困ります。

なので、 こちらで確認した内容を ある程度まとめてから聞くようにしていました。

• どの環境か
• どのURL・接続先か
• 何時頃発生したか
• 何を送ったか
• どのStatus Codeが返ったか
• Response Bodyは何だったか
• こちら側ではどこまで確認したか

「そっち壊れてません？」ではなく、
「ここまで確認して、ここから分からない」

その方が、 相手側も確認しやすくなります。

外部連携では、 技術的な切り分けと 相手とのやり取りが かなり近いところにありました。

外部連携で問題が起きたとき、 自分の中では だいたいこんな順番で 見るようになりました。

1. 自分の処理が呼ばれているか
2. 接続先が正しいか
3. 認証情報が正しいか
4. Requestが想定どおりか
5. Responseが返っているか
6. Status CodeとBodyを見る
7. 必要なら直接呼び出して比較する
8. ログでどこまで処理されたかを見る
9. 相手側にしか見えない範囲なら確認する

毎回この順番というわけではありません。

でも、 最初から犯人を決めるより、 正しいところを一つずつ増やす方が 切り分けやすかったです。