直したのは一文字だった。壊れていたのは二十一記事だった

記事の書き出しに、書いた覚えのない二文字が出ていた。
直した箇所は一文字。それなのに、同じ壊れ方をした記事が二十一本あった。

朝、自分のブログを開いたら、記事の書き出しのいちばん後ろに「\n」という二文字がそのまま出ていた。
文章の一部ではない。
どう読んでも、僕が読ませるつもりで書いた文字ではなかった。

直すのは一分で終わる話だと思った。
実際、直した箇所は一文字だった。
それなのに、その日いちばん時間を使ったのは直す作業ではなくて、同じ壊れ方をしている記事がほかにいくつあるのかを数える作業だった。

改行のつもりで書いた記号が、文字として残っていた

書き出しの文章には、途中で一度改行を入れたかった。
プログラムの世界には、改行を「\n」という二文字で書き表す古い決まりがある。
キーボードのエンターを直接打ち込めない場所でも、この二文字を置いておけば「ここで改行」という合図として読んでもらえる、という約束事だ。

やっかいなのは、その約束が有効な場所とそうでない場所があるところで、僕は境目を踏み間違えた。
文章をデータベースへ流し込む命令文の中では、「\n」は合図として通じる。
ところが僕は、記号を記号のまま扱うときに使う打ち消しの一本を、その手前によけいに足していた。
一本足したせいで合図が合図でなくなり、「そういう二文字の文章」として素直に保存された。

機械はまったく間違っていない。
書いたとおりに保存しただけで、書いたものが違っていた。

一本ではなかった

ここからが本題になる。
その書き出しは、僕が手で一本ずつ打ち込んでいるものではない。
毎日の投稿を組み立てる仕組みが、同じ手順で同じ形に作っている。

つまり、間違った書き方をしていたのは僕の頭の中の一か所なのに、その一か所を通って出てきたものは全部、同じ壊れ方をしている。
数えたら二十一本あった。
四つのブログにまたがっていて、いちばん古いものは二週間ほど前のものだった。

二週間、僕は毎日そのブログを開いている。
それでも気づかなかったのは、書き出しの文章が画面のかなり上のほうに小さく出る部分で、目が本文のほうへ先に行ってしまうからだと思う。
自分の作ったものほど、見ているつもりで見ていない。

直す前に、数えた

見つけたときにいちばんやりたくなるのは、その場ですぐ書き換えることだ。
今回はそれをやらずに、まず「どれが壊れているか」を一覧で出した。

やったことは単純で、保存されている文章の中に問題の二文字を含むものを探して並べただけだ。
数が出ると、いくつか分かることがある。

ひとつは、直す範囲がはっきりすること。
二十一本だと分かっていれば、直したあとで「二十一本が○本になったか」を確かめられる。
数えずに直すと、直った実感はあるのに直りきったかどうかは分からないままになる。

もうひとつは、直してはいけないものが混ざっていないかを目で見られること。
文章の中で「\n」を説明として書いている記事があったら、それは壊れているのではなく、そう書きたくて書いている。
一覧を見ないで全部いっぺんに置き換えると、正しいほうまで一緒に消える。

書き換える命令を先に打って、あとから数えるのは順番が逆だ。
これは板場にいた頃に「切る前に数えろ」と言われていたのと、たぶん同じ話だと思っている。

機械は、間違いも同じ速さで配る

今回いちばん考えたのはここだった。

手で一本ずつ書いていたら、たぶん一本目で気づいている。
書いて、見て、変だと思って、直す。
被害はその一本で止まる。

自動で作るようにすると、書いて、見ないで、次の日も同じものが出てくる。
速くなるのは正しいものを配る速さだけではなくて、間違ったものを配る速さも同じだけ速くなる。
自動化の話をするとき、たいてい前半しか語られない。

だからといって手作業に戻すのが答えだとは思わない。
戻したら毎日は続かない。
そのかわり、増えるのは「速さ」ではなく「同じものが並ぶこと」だと分かったうえで使いたい。
同じものが並ぶ仕組みは、正しいときはとても頼りになるし、間違ったときはとても静かに広がる。

いまやっていること

三つ決めた。

一つめは、仕組みを直した日は一本目を必ず目で見ること。
全部を見る必要はなくて、一本目だけでいい。
一本目が正しければ、あとは同じものが並ぶ。

二つめは、直す前に数えること。
書き換える命令の前に、探して並べる命令を必ず一回はさむ。
件数と中身を見てから手を動かす。

三つめは、書き出しのような「小さくて目が滑る場所」ほど、確かめる手順のほうに入れておくこと。
本文の見出しが消えていたら誰でも気づくが、二文字は気づかない。
気づかないものは、気づく気持ちではなく手順で拾うしかない。

以前、毎回手で確認していたのをやめてプログラムにテストをさせる話を書いた。
あのとき自分が確かめる対象にしていたのは、動くか動かないかだった。
今回の二文字は、動いてはいたし、エラーも出ていない。
壊れていたのは見た目のほうで、そこは自分で見るか、見る手順を決めておくかしかない。

あとから読み返して思ったのは、変数の名前で半年後の自分に泣かされた話と根っこが似ているということだった。
どちらも、その場では一文字か二文字の話でしかない。
小さいから軽い、とは限らない。
小さいものほど、気づかれないまま遠くまで運ばれていく。

スタンプラリーに挑戦する 行った場所・気になる場所は、現地チェックインでスタンプに残せます。 みんなのコースを見てみる 会員が作ったスポット巡りのコースを都道府県から探せます。自分だけのコースも作れます。 運営者の個人noteも書いています AI活用やサイト運営で気づいたことを、もう少し個人の視点で掘り下げています。

※運営者が個人で書いているnoteです。

技術ブログ一覧へ戻る