悪いのは向こう。でも、直したのはこっち。

「いつまでAPI仕様書が修正されるんですか」

担当者に言われた。

続けて、

「いつまで取り込み作業が発生するんですか」

とも言われた。

まあ、そうだよね。

僕も同じことを思っていた。

結合試験が始まってから、APIまわりの故障がずっと出ていた。

自チームで検知した故障だけで98件。

全部がIF起因ではないけど、感覚的には7割くらいがIFに関係していたと思う。

一つ直したら、また一つ見つかる。

仕様書が変わる。

設計を直す。

実装を直す。

試験する。

すると、また別の仕様が分かる。

また直す。

担当者からしたら、たまったもんじゃない。

申し訳ないな、と思った。

ただ同時に、

いや、俺に言われてもな……。

とも思っていた。

僕だって好きで仕様書を変えているわけではない。

みんな同じように振り回されている。

でも、担当者からしたらそんなことは知らない。

昨日直したものを、今日また直せと言われる。

しかもいつ終わるか分からない。

そりゃ、嫌になる。

そもそも、何がそんなにズレていたのか。

例えば金額。

API仕様書には、

「3桁、可変長」

と書いてある。

これを見て僕たちは、先頭の0は落ちて返ってくるんだろう、と考えていた。

例えば 001 ではなく 1 が返るイメージ。

でも実際は違った。

0がついた状態で返ってくる。

すると、その値を使って判定しているフロント側の処理が想定どおり動かない。

他にもあった。

区分値はコードで返るのか、日本語名称で返るのか。

データがない場合は空文字なのか、nullなのか。

日付はどういう形式で返ってくるのか。

細かい。

めちゃくちゃ細かい。

でも、システムってこういう細かいところで普通に壊れる。

当時の僕は、

「API仕様書にちゃんと書いてくれよ」

と思っていた。

というか、今もそこは思っている。

API提供側にも事情はあった。

今回のAPIは、後ろにある勘定系システムの値を基本的にそのまま返している。

だから、

「実際にどんな値が返るかは勘定系の仕様に依存します」

というのがAPI側の言い分だった。

一理ある。

一理あるんだけど。

じゃあ勘定系に聞いて、その結果をAPI仕様書に書いてくれよ、と思う。

こちらは、そのAPI仕様書を見て設計するので。

ただ、この「3桁、可変長」という記載。

今考えると、結構おもしろい。

API提供側からすると、別に嘘を書いているわけではない。

ゼロサプレスされるかは分からない。

でも「可変長」と書いておけば、少なくとも間違いとは言い切れない。

一方、利用する僕たちは、

「可変長って書いてあるなら、ゼロサプレスされるんだろう」

と読む。

どちらも、それなりに筋が通っている。

なのに壊れる。

ここで僕は、

分からないことを、それっぽく仕様にすると危ない

ということをかなり実感した。

「可変長」と書いてあることより、

本当は、

「ゼロサプレスされるか現時点では不明」

という情報の方が大事だった。

仕様って、分かっていることを書くものだと思っていた。

でも、

「まだ分かっていない」というのも、かなり重要な仕様なんですよね。

これはこの案件のあと、結構意識するようになった。

で、問題が出てくると次に始まるのが、

「どっちが直すんですか」

という話だった。

僕としては、かなりシンプルだった。

API仕様書から読み取れない。

API提供側も、実際に何が返ってくるか把握できていない。

じゃあ向こうが悪いでしょ。

正直そう思っていた。

なので感情だけで言えば、

「そっちで全部直してよ」

だった。

担当者も疲れている。

何回も修正させられている。

これ以上、自チームに余計な仕事を増やしたくない。

普通に理不尽だと思った。

でも、ここで少し困った。

実際のシステムを見ると、

API側を直すより、フロント側を直した方が安全だった。

APIは勘定系から返ってきた値を基本的にそのまま返している。

そこでAPI側に変換処理を入れると、影響範囲が増える。

一方でフロント側なら、例えば値をパディングしてからチェックするなど、比較的小さな修正で吸収できる。

こっちの方が現実的だった。

なので、

悪いのは向こう。

でも、直したのはこっち。

になった。

めちゃくちゃ納得したかというと、してない。

今でも普通に、

なんでこっちが直すんだよ。

とは思う。

ただ、プロジェクト全体で考えると、その方がよかった。

悔しいけど。

このときに、

「誰が悪いか」と「誰が直すか」は、同じじゃないんだな

と思った。

僕は昔、

原因を作ったチームが直すのが当然だと思っていた。

その方が公平だし、分かりやすい。

でも、システム開発では必ずしもそうならない。

相手が100％悪くても、自分たちで直した方が早くて、安全なことがある。

逆もある。

自分たちのミスだけど、相手システム側を直した方が圧倒的に合理的なら、相手にお願いした方がいい場合もある。

「誰が悪いか」で修正箇所を決めると、システムとして変なことになる。

ここは結構、仕事をしていて考え方が変わったところだった。

ただし。

じゃあ、

「こっちで直すので、もう大丈夫です」

で終わるかというと、それも違う。

ここはかなり大事にしている。

改修はこっちでやる。

でも、今回の原因が向こうにあるなら、

原因分析はやってもらう。

他にも同じ問題がないか調べてもらう。

仕様書も直してもらう。

再発防止も考えてもらう。

責任までこっちで引き取る必要はない。

たぶん僕は、

「誰が悪いか」

そのものに執着しているわけではない。

相手がミスすること自体は、そこまで嫌じゃない。

人間なのでミスはする。

僕もする。

一番嫌なのは、

そのミスのせいで、自チームがずっと理不尽に振り回されること

なんだと思う。

仕様が確定していないのに、とりあえず作る。

また仕様が変わる。

また直す。

また変わる。

それを、

「プロジェクトだから仕方ないよね」

で全部飲み込む。

これはあまり好きじゃない。

今回の担当者に、

「いつまで修正が続くんですか」

と言われたときに感じた申し訳なさも、たぶんここだった。

仕事が多いことより、

終わりの見えない仕事をさせていたこと

の方が嫌だった。

今なら、インプットとなる仕様が固まっていないなら、一度作業を止めると思う。

「仕様が決まっていないので設計できません」

と言う。

必要ならエスカレーションする。

昔は、止めることに少し抵抗があった。

止めると進捗が悪く見えるので。

でも、決まっていないものを作って、あとから全部やり直す方がよっぽど悪い。

この案件以降、IFの見方もかなり変わった。

以前は、

API仕様書がある。

レビューもされている。

じゃあ大丈夫だろう。

くらいだった。

今はあまり信用していない。

というと語弊があるけど、

IFはズレる前提で見る

ようになった。

APIを提供するチームと、利用するチームでグループ間レビューをする。

「こっちはこういう意味で読んでいます」

というところまで確認する。

実際にシステムをつなぐのは結合試験からだけど、その前の単体試験でもサンプルデータをもらう。

オフラインで一度確認する。

結合試験で初めて、

「え、この値で返ってくるんですか」

となるのを少しでも減らしたいからだ。

ちょっと乱暴だけど、この経験以降ずっと思っている。

IFはどうせバグるぞ。

API提供側が悪いという意味ではない。

フロント側が悪いという意味でもない。

境界だから。

自分のチームでは当たり前のことが、相手のチームでは当たり前じゃない。

仕様書を書いた人の「可変長」と、

それを読んだ人の「可変長」が、

同じ意味とは限らない。

だから早く確認する。

分からないものは、分からないまま流さない。

実物を見る。

一回つないでみる。

それでも、多分バグる。

まあ、バグるんだと思う。

だから最近は、

「IFは問題ないです」

と言われるより、

「IFなので一回ちゃんと見ましょう」

と言われる方が安心する。

システムとシステムの間って、やっぱり難しい。