「動く」と「ちゃんと出る」は、別だった

「エラーが出ない」を、「できた」と思っていないか

何かを作って、エラーが出ずに動いた。それを「できた」と読み替えて先へ進む。よくある合格判定です。今日は、その判定がどこで足りなくなるかを一緒に考えます。

前回は、自分が知っていることを先にAIへ渡す話でした。今回は、できあがったものを「確かめる」の、もう一歩手前の話です。コードがエラーなく通る。動く。私はつい、それで完成したことにしていました。けれど、実際に画面へ出てきたものを自分の目で見るまでは、ちゃんと出ているかどうかは確かめられていません。「動く」と「ちゃんと出る」は、地続きに見えて、実は別の合格です。

通ることと、出ることは、別だった

作っていたのは、診察のときに見せる、記録のまとめページでした。表とグラフを並べて、紙に印刷できるようにする。コードを書いて、文法のおかしいところが無いかを確かめると、ちゃんと通ります。エラーは出ません。動いている。

ここで私は、できあがったことにしていました。けれど、よく考えると、文法が正しいことと、見た目がちゃんとしていることは、別の話です。前者は、機械が読めるかどうか。後者は、人が見て読めるかどうか。エラーが出ないのは、機械にとっての合格でしかなくて、人にとってどう見えるかは、まだ誰も確かめていない。「動く」という一語のなかに、私は性質の違う2つの合格を、いっしょくたにしていたわけです。

整理すると、こうなります。文法が通る、というのは、機械が処理を最後まで走らせられた、という意味でしかありません。処理が走ったことと、その出力が目的にかなっていることは、別の事実です。プログラムが「正しく動いた」結果として、見当はずれな画面が出てくることは、ふつうに起こります。エラーは、機械が困ったときに鳴る合図であって、人が困るときには鳴りません。だから、エラーが出ないことは、人にとっての品質を1つも保証していない。ここを取り違えると、機械の沈黙を、人の満足と読み違えてしまいます。

「自分で見てる?」の一言

そのことに立ち戻れたのは、相棒のAIに、ふと問いをかけたからでした。これ、自分で実際の見た目を確かめてる? 軽い確認のつもりの一言です。

返ってきたのは、こういう答えでした。文法は確かめたけれど、実際に出した画面そのものは、まだ見ていません、と。これは、前に書いた「漏れはなさそう?」の一件と、構造がよく似ています。あのときは、コードの中身の穴でした。今回は、出てきた見た目の話です。点検にも種類があって、論理が正しいかを確かめる点検と、見た目がちゃんとしているかを確かめる点検は、別々に頼まないと、別々には走りません。動くことを確かめても、ちゃんと出ることまでは、自動では確かめられていなかったのです。

注目したいのは、私が「見て」と頼むまで、その点検が始まらなかったことです。AIは、頼まれた仕事、つまり文法を確かめる仕事は、きちんとやります。けれど、頼んでいない仕事、つまり出して見る仕事は、気をきかせて勝手にはやりません。これは性能の問題というより、依頼の範囲の問題です。指示が「文法を確かめて」なら、返ってくるのは文法の点検結果まで。見た目の点検は、その指示の外側にあるので、こちらが言葉にしない限り起動しない。しかも、見た目を確かめる工程は、人に見せるものを作るときには欠かせないのに、いちばん抜け落ちやすい。欠かせないのに抜けやすい工程は、依頼の側で意識して起こしてやる必要がありました。

実際に出してみたら、ずれていた

そこで、実際に紙に出したらどう見えるかを、画像にして確かめました。すると、いくつも、おかしなところが見つかりました。

まとめページの下半分が、すかすかに間のびしている。印刷したとき、本来は要らないはずのものが、ページの隅に紛れ込んでいる。グラフの並びも、思っていた収まりとは違っていました。どれも、文法の点検では、ぜんぶ素通りしていたものです。機械にとっては、何の問題もない。けれど、人の目で見ると、見せる資料として、明らかに整っていない。出して、見て、はじめて分かることばかりでした。直したあとも、また出して、見て、確かめる。理屈の上で「これで直ったはず」では足りなくて、もう1度、目で確かめる必要がありました。

それからは、見た目を変えるたびに、まず実際に出して、画像にして、目で見る、を一手間として挟むようにしました。直したつもりが直っていないことも、直した拍子に別のところが崩れることも、出してみれば一目です。逆に、出さずに「たぶん大丈夫」で進めると、崩れは次に開いたときまで気づけません。ここには、確かめる手間と、見逃す危険の交換があります。出して見る数十秒を惜しむと、その崩れは、人が見るまで誰にも見つからないまま残り、見つかる場所が「世に出したあと」へずれていく。見た目に関しては、頭の中で思い描くより、出てきた実物1枚のほうが、ずっと正確な答えをくれました。

目でしか分からないことが、ある

ここで考えたのは、世の中には、理屈をいくら積んでも分からなくて、見た瞬間に分かることがある、ということです。余白が間のびしているとか、文字が窮屈だとか、並びが落ち着かないとか。こういうものは、コードを上から下まで読んでも、たいてい気づけません。出してきた1枚を、ぱっと見たときに、ようやく「変だ」と分かる。読む点検と、見る点検は、はたらく感覚そのものが違うのだと思います。

考えてみれば、これは料理に似ています。レシピの手順が1つも間違っていなくても、できあがった皿を味見しなければ、おいしいかどうかは分かりません。手順の正しさと、味の良さは、確かめ方そのものが別ものです。コードも同じで、文法が通っているかと、見た目が整っているかは、別の確かめ方が要る。手順を読んで分かることと、皿を見て分かることは、はじめから別の窓口だと考えておくほうが安全です。

そして、見た目のずれには、やっかいな性質があります。論理の間違いは、動かないという形で、はっきり自分から名乗り出ます。けれど見た目のずれは、何食わぬ顔で動いてしまう。エラーも出さず、ちゃんと表示されているふりをして、人が見るその瞬間まで、見つからずに残る。自分から名乗り出る不具合は、放っておいても見つかります。名乗り出ない不具合は、こちらから出して見にいかない限り、向こうからは教えてくれない。だから、見た目のような「黙っている不具合」ほど、探しにいく工程をあらかじめ決めておく値打ちがあります。

AIは、理屈の世界がとても得意です。筋の通ったコードを、すらすら書きます。けれど、出てきた絵を見て「落ち着かないな」と感じることは、その絵を見ていない以上、できません。これは能力の限界というより、入力の不足です。見ていないものは評価できない。だからこそ、見た目を伴うものは、人が、あるいはAIにちゃんと絵を出させたうえで、実際に目で確かめる工程を、別に置く必要がある。動いたかどうかと、ちゃんと見えるかどうかは、最後まで、別々の問いでした。

あなたが「動いた」と思ったら

もしあなたが、何かを作って、エラーが出ずに動いて、「できた」と思ったら、その前に、1度だけ、実際に出てくるものを、自分の目で見てください。画面でも、印刷でも、書き出したファイルでも。動いたことと、ちゃんと出ていることは、別です。

機械の合格は、人の合格ではありません。文法が通っただけで満足すると、人が見た瞬間に分かるずれを、そのまま世に出してしまいます。理屈で確かめたことは、目で確かめたことの代わりにはなりません。最後にものを言うのは、たいてい、自分の目で見た1枚です。

今日からできるのは、何かが動いたら、すぐ次へ行かずに、出てくるものを1度だけ実際に見る癖です。スクリーンショットでも、印刷のプレビューでも、書き出したファイルでも。ほんの数十秒、見るだけ。その数十秒が、人が見た瞬間の「なんか変」を、世に出す前に拾ってくれます。もう一段ぶんを足すなら、AIに頼むときの言い方を「動かして」から「動かして、出てきた画面を見せて」へ変えておくと、見る工程が依頼のなかに最初から組み込まれます。急ぐ日ほど省きたくなりますが、見ずに通した代償のほうが、たいていずっと高くつきます。次回は、その「ちゃんとしたものを作る」の逆、あえて作らない、機能を削るという話を。足すより削るほうが、難しくて、効きました。

---

これは、自分の治療のために作っている自作自用版での話です。広く公開しているのは記録と集計に絞った carb-icr（無料・通信なし・ブラウザで動くPWA）。プロジェクトの概要は carb-icr のプロジェクトページ に。

本アプリは記録と集計の補助で、表示される値はすべて参考です。診断・治療、インスリン投与量の計算、治療パラメータの決定は行いません。投与量・治療方針は必ず主治医の指示に従ってください。