「とりあえず冗長化しておいて」。

そう頼まれて、機器を二重にして納品した。半年後の夜中、その片方が壊れた。切り替わるはずだった。けれど業務は 10 分止まった。翌朝、上司に言われる。「冗長化したって、言ってたよね？」——あなたは確かに二重にした。でも相手が困っていたのは「二重かどうか」ではなく、「止まらないこと」だった。

要件ヒアリングでいちばん危ないのは、相手の言葉が粒度の粗いまま通り過ぎることだ。「冗長化」「安定させて」「速くして」——どれも願いであって、そのままでは設計でも運用でも守れない。先に結論を言う。要件ヒアリングは、相手の希望を聞いて終わる場ではない。粒度の粗い要望を、あとで守れる一文に落とす場だ。

［図1：粒度の粗い要望「冗長化しといて」が、操作条件（何が止まらないか・どれだけで切り替わるか・誰が決めるか）の3点へ落ちる対比インフォグラフ（要生成）］

「冗長化」は、まだ何も約束していない

「冗長化しておいて」を、そのまま「機器を二重にする」と訳した瞬間に、危ない。二重にしても、片方が壊れてから切り替わるまでに 10 分かかるなら、相手の「止まらないでほしい」は守れていない。

ここで一拍止まって、聞き返す。「止まってもいい時間は、どれくらいですか」「切り替えは自動でいいですか、それとも誰かが判断して切り替えますか」。この一拍が、願いを操作条件に変える。冗長化という言葉は、構成の話に聞こえて、本当は業務がどれだけ止まってよいかの話だった。

VRRP は、自動切替を約束する技術語

聞き返した結果、相手が「自動で、数秒のうちに切り替わってほしい」と答えたとする。ここで初めて、技術語を出していい。

たとえば VRRP（Virtual Router Redundancy Protocol）。これは、複数のルータが 1 つの仮想的な IP を共有し、現用機が落ちたら待機機がその IP を自動で引き継ぐ仕組みだ。具体的には、現用機が定期的に「自分は生きている」という通知を出し、それが途切れると待機機が引き継ぐ。標準は RFC 5798 に定義されている。これを業務の言葉に戻すと、「現用機が落ちてから、待機機が同じ宛先を引き継ぐまで、おおよそ数秒。その数秒のあいだは通信が切れる」となる。

ここまで来て、はじめて約束が書ける。「数秒の切断は許容、自動切替」なら VRRP が候補になる。「一瞬も切れてはいけない」なら、VRRP では足りず、別の仕組みと追加コストの相談になる。技術語を出したのは、相手を煙に巻くためではなく、約束の精度を上げるためだ。

粒度の粗い要望を、守れる要件文に落とす

最後に、聞き取った内容を一文に畳む。「コア機器は VRRP で冗長化。現用機の故障時は自動で待機機へ切替、切断は数秒。計画停止やメンテ手順は別途」。

この一文は、業務（何が止まらないか）・時間（どれだけで切り替わるか）・担当（何が判断して切り替えるか）を含んでいる。「冗長化しました」より、ずっと守れる。そのうえで、まだ決まっていないこと——たとえば「一瞬の切断も許さない区間はあるか」——を、未確認として残す。決まっていないことを名指しで残すのも、立派な成果物だ。

明日、誰かに「とりあえず○○しといて」と言われたら、その○○を構成名へすぐ訳さないでほしい。止まってよい時間、切り替えの主体、許せない一線——そこを一拍で聞き返すだけで、あなたの納品は「言われた通り」から「あとで守れる約束」に変わる。