Fault Line

障害報告の第一声が「それはうちの責任範囲じゃないです」だったことがある。

言いたいことはわかる。だがユーザーから見れば、サービスは一つだ。どこで障害が起きていようが関係ない。あのとき揉めたのは、責任の境界が曖昧だったからだ。

OSI参照モデルは7つの層で責任を分けた。物理層はケーブルの話、データリンク層はフレームの話、ネットワーク層はルーティングの話。各層は自分の仕事だけをやり、上の層には口を出さない。美しい分離だ。そしてこの分離があるから、L3の障害をL7の担当者に問い合わせても無駄だとわかる。責任の境界が明確だから、問題の切り分けができる。

APIのインターフェースも同じ構造を持っている。リクエストを受け取る側と送る側の間に線を引く。この線から先はあなたの仕事、この線の手前はわたしの仕事。引数の型、レスポンスの形式、エラーコードの定義。すべては「ここで責任が切り替わる」という宣言だ。

モノレポかマルチレポかという議論も、突き詰めれば責任分岐点の話だ。リポジトリを分ければ、チーム間の境界が明確になる。モノレポにすれば、境界は曖昧になるが全体の整合性は取りやすくなる。どちらが正しいかではなく、どこに線を引きたいかの問題だ。

責任分岐点が明確なプロジェクトは、障害が起きても切り分けが早い。バグが見つかっても、どこを直すべきかが見える。逆に境界が曖昧なプロジェクトでは、全員が全部を気にして、誰も何も決められない。チーム間で暗黙の貸し借りが発生し始めたら危険信号だ。

技術の話をしているようで、これは組織の話でもある。マイクロサービスの境界はチームの境界だし、APIの設計はチーム間の契約だ。コンウェイの法則は正しい。システムの構造は組織の構造を映す。つまり責任分岐点を設計するということは、組織を設計することと同義だ。

エンジニアとしてキャリアを重ねると、どこで線を引くべきか、経験がタブ補完のように候補を出してくれるようになる。しかしひとたび仕事を離れると、何を叩いても補完はきかない。