「そちらで何か対応は必要ですか？」共通基盤と連携先の責任分界を、問い合わせ対応から整理する

はじめに

「システムのメンテナンスで連携を止めます。そちらで何か対応は必要ですか？」

共通基盤の担当者であれば、こうした問い合わせを受けたことがあるのではないでしょうか。一見すると丁寧な事前連絡ですが、よく読むと「何が必要かを、そちらで考えてほしい」という依頼になっていることがあります。

親切に答えているうちに、いつの間にか判断まで引き受けていた。そんな経験に覚えがある人も多いと思います。

私はPjMとして、複数のシステムが関わるプロジェクトに携わってきました。この記事では、共通基盤とそれを利用する連携先の間で起きがちな責任分界の曖昧さについて、架空の例をもとに整理します。

1. 共通基盤への問い合わせで、何が起きているか

共通基盤には、利用するシステムからさまざまな問い合わせが届きます。仕様の確認や障害の切り分けのように、基盤側が答えるべきものも多くあります。

一方で、次のような問い合わせが混ざることがあります。

連携先が、自分たちの作業による影響の洗い出しを基盤側に求めている
連携先が管理している設定について、基盤側に判断を求めている
標準の手段に対応していないため、個別の特別対応を求めている

基盤側は仕組みをよく知っているので、答えようと思えば答えられます。ただ、答えられることと、答える責任があることは別だと思います。

基盤側が答え続けると、連携先には「基盤に聞けば何とかしてくれる」という前提ができていきます。その結果、基盤が本来の範囲を超えて、事実上の責任者になっていくおそれがあります。

2. よくある場面：受け口を止めたい、という連絡

ここからは、架空の例で考えてみます。

ある会社に、各サービスに代わってメールを配信する共通の通知基盤があるとします。通知基盤は、配信の成功や失敗といった結果を、Webhookで各サービスに返しています。結果を受け取る受け口は、各サービスが自分たちで用意し、管理しています。

通知基盤は、受け口が応答しない場合に一定回数まで再試行します。再試行を使い切った結果も一定期間は保存していて、再取得用のAPIを使えば後から取得できます。これが、基盤として用意している標準の手段です。

あるとき、連携先のサービスから次のような連絡が届きます。

「サーバ移行のため、数時間Webhookの受け口を止めます。そちらで何か対応は必要ですか？」

基盤の担当者は、つい頭の中で確認を始めます。

受け口が止まっている間、通知基盤は何回まで再試行するのか
再試行を使い切った結果は、どこに残るのか
再開後に、連携先はたまった結果を処理しきれるか
結果の届く順序が前後しても、連携先は正しく処理できるか

このうち、再試行の回数と、使い切った結果の扱いは、基盤側が答えるべきことです。どちらも通知基盤の仕様だからです。受け口を止めるかどうか、再開後にどう取り込むか、順序をどう扱うかは、受け口を管理する連携先の判断になります。

さらに、こんな相談が続きます。

「止めている間に受け取れなかった結果を、あとで個別に送り直してもらえませんか」

前述のとおり、通知基盤には取りこぼした結果を後から取得するための再取得用のAPIがあり、ほかのサービスではすでに使われています。ところが、この連携先はそのAPIに対応していませんでした。標準の手段があるのに、それに乗らずに個別対応を求められる。基盤側としては、引き受けるかどうか迷うところです。

3. 問い合わせを受けたときに確認したい4つのこと

この例のような場面では、問い合わせを受けたときに次の4つを確認しておくと、判断の主体を取り違えずに済むと思います。

① 持ち物：その仕組みは誰が管理しているのか

まず、問われている仕組みを誰が管理しているのかを確認します。

例でいえば、再試行の仕様は通知基盤の持ち物で、受け口は連携先の持ち物です。基盤側は自分の持ち物については正確に答え、相手の持ち物については相手に判断を委ねます。全部に答えるのでも、全部を突き返すのでもなく、持ち物で線を引くことがポイントだと考えています。

② 判断の主体：止めるかどうかを決めるのは誰か

次に、誰が判断するのかを明確にします。

作業をするのは連携先です。影響の洗い出しと対応案の提示は連携先が主体になり、基盤側はその内容をレビューして、気になる点があれば指摘します。基盤側が先に答えを出してしまうと、レビューする側とされる側が入れ替わってしまいます。

ただし、基盤側が何もしなくてよいわけではありません。基盤の仕様や、停止中に基盤側で何が起きるかを説明すること、対応案を技術的にレビューすることは、基盤側の役割です。基盤側が引き受けないのは、連携先のシステムへの影響の分析と、どう対応するかの最終判断です。

③ 標準の手段：基盤として用意しているものは何か

続いて、基盤として用意している標準の手段を示します。

例でいえば、再取得用のAPIがそれにあたります。標準の手段に乗れない事情があることは理解できます。ただ、個別対応を一度引き受けると、それが前例になり、次回以降も同じ対応を求められやすくなります。まずは標準の手段を案内し、乗れない場合の対応は連携先で考えてもらう。そのうえで、中長期的には標準の手段への対応をお願いすることを意識したいところです。

なお、標準の手段に乗れない原因が基盤側の仕様や制約にあるなら、話は別です。その場合は連携先だけの責任とは言えず、基盤側の改善課題として受け止めるべきだと思います。

④ 記録：誰が何を合意したかを残す

最後に、やり取りを記録に残します。

標準の手段を案内したこと、個別対応は難しいと伝えたこと、連携先がどう判断したか。これらをチケットなど、後から追える形で残しておきます。実際に取りこぼしが起きたとき、「手段は提示済みで、どう対応するかは連携先の判断だった」と経緯をたどれるようにするためです。

この4つは、連携ごとに次のような表にしておくと、問い合わせのたびに考え直さずに済みます。

項目	担当	例での内容
再試行の仕様	共通基盤	再試行の回数と間隔、使い切った結果の扱い
仕様の説明と情報提供	共通基盤	停止中に基盤側で起きることの説明
受け口の管理と停止の判断	連携先	移行中に受け口を止めるか
停止の影響分析と対応案	連携先	再開後の取り込み方、順序の扱い
対応案のレビュー	共通基盤	連携先の案に技術的な懸念がないかを確認
標準リカバリの提供	共通基盤	再取得用のAPI
取りこぼし時の対応判断	連携先	標準の手段に乗るか、自前で対応するか

4. 答えすぎずに、判断を相手に戻す伝え方

とはいえ、問い合わせに「それはそちらの責任です」とだけ返すと、関係を損ねるおそれがあります。基盤側としては、協力する姿勢を見せながら、判断の主体を相手に戻す伝え方を意識したいところです。

たとえば、次のような言い方があります。

「影響範囲と対応案を共有いただけますか。こちらでもレビューします」
「受け口の停止は貴システムの管理範囲のため、要否はそちらでご判断ください。基盤側の仕様で確認したい点があれば、お答えします」
「標準のリカバリ手段はこちらです。対応が難しい場合は、どのように対応される予定かを教えてください」
「今回の個別対応は難しいのですが、中長期的には標準の手段への対応をご検討いただけると助かります」

断るだけで終わらせず、「次に何をすればよいか」を相手に渡すことに意味があるのだと思います。

5. まとめ：判断の主体を正しい場所に戻すことが、共通基盤を担う役割の価値

共通基盤は、多くのシステムから頼られる存在です。頼られること自体は悪いことではありませんが、何でも答えていると、責任の境界はすぐに曖昧になります。

共通基盤の役割は、すべての問いに答えることではなく、判断の主体を正しい場所に戻し、標準の道を示し続けることだと考えています。

「そちらで何か対応は必要ですか？」と聞かれたとき、すぐに答えを探す前に、「それを判断するのは誰か」と一度立ち止まる。その一つの問いが、基盤と連携先の関係を健全に保つことがあります。

会議の場で前提を揃える話は、記事「そもそも目的は何ですか？」持ち帰りで終わりかけた会議を、一つの問いで立て直すに書いています。

※本記事の事例は架空のものです。