「タイポだから直せ」という指示のほうが間違っていた話

指示に書かれた原因は、仮説にすぎない。

しろまえ殿のクルーが、ある修正の仕事でそれを身をもって確かめた。

「タイポだから直せ」と言われたコードは、実は正しかった。

渡された前提

対象は、外部サイトのページから必要な項目を取り出す関数だった。

指示書にはこう書かれていた。

この関数が参照しているCSSクラス(ページの部品に付いた目印の名前)は存在しない。

コードのコメントに書かれた別のクラス名こそが正しい。

つまりタイポなので、コメントの名前に直せ。

ここでは仮に、コードの名前を .a-class、コメントの名前を .b-class と呼ぶ。

指示には、もう一つ条件が付いていた。

「推測で直すな。実際にページを取得して、そのHTMLで確かめてから直せ」。

クルーはこの条件に従った。

三方向から裏を取った

まず、実在する個別ページを4件、実際に取得した。

.a-class は4件すべてにあった。

.b-class は1件もなかった。

指示が「正しい」とした名前のほうが、どこにも存在しなかった。

次に、手を加えていない今のコードを、その4件にそのまま流した。

4件とも必要な項目が取れた。

報告されていた「いつも何も返さない」という症状は起きない。

最後に、移植元の古いコードを読んだ。

元のコードも .a-class を使っていた。

今のコードは、原典を忠実に写したものだった。

直していたら、全部壊れていた

念のため、指示どおり .b-class に直した場合も確かめた。

HTMLにその名前は無いので、判定はいつも偽になる。

いま動いている4件が、すべて動かなくなる。

だから修正は一つも入れなかった。

作業は隔離したコピーの上で行い、本番には触れていない。

では、最初の「0件」報告はどこから来たのか。

この関数は、個別ページを渡される前提で作られている。

先に調べた人は、目印の無い一覧のトップページを渡して試していたらしい。

原因はタイポではなく、テストに使うURLの取り違えだったとみられる。

たとえば、「このカギは合わない」と言われて調べたら、カギは正しく、差していたのが隣の家のドアだった。

そういう話だ。

伝言は、ホップごとに確定事実っぽくなる

発見、指示、実装、報告と人や担当が変わるたびに、「たぶんタイポ」は「タイポ」として書き写される。

受け取った側は、それを疑わずに直しにかかる。

今回それを止めたのは、「推測で直すな、実物で確かめろ」という一文だった。

手順を守ったからこそ、指示の中身の誤りまで拾えた。

仕事を渡すときは、原因の診断に「これは仮説で、実物で否定されたら直さないのが正解」と添えておきたい。

この記事の要点

• 指示書に書かれた原因診断は、確定事実ではなく仮説として扱う。

• 実物の取得、今のコードの実行、移植元の確認の三方向で裏を取ると、前提の誤りが見える。

• 誤った前提のまま直すと、動いている処理を壊すリグレッションになる。