
仕様は紙に書ける。思いは行間に沈む
形・真・理という流儀
判断に迷ったとき、自分の中で一度立ち止まるための言葉がある。
形・真・理
最初にこの言葉を意識したのは、アニメ『モノノ怪』だったと思う。
薬売りという男が出てくる。
彼の持つ剣を抜くには、三つを示さなければならない。
形
真
理
それが揃わないまま剣に手をかけても、ものごとは何ひとつ動かない。
ただ目の前の現象だけを見てもだめで、起きた理由だけを追ってもまだ足りない。
そこに関わったものの思いまで届かなければ、本当には終わらせられない。
自分は、そう受け取っている。
「流儀」という言葉も、昔触れた作品から自分の中に残ったものだ。
誰かに説明するための思想というより、自分が作業机の端にずっと置いている、小さな道具に近い。
気づいたら、その二つが混ざっていた。
形は見える、真は掘れる、理は黙っている
自分の解釈では、形は結果だ。
画面に出たエラー。
消えたファイル。
棚卸しの数字のズレ。
ユーザーから返ってきた「使いにくい」という言葉。
目に見えるもの
記録に残るもの
表に出てきたもの
真は、その結果に至るまでの工程だ。
どの変更がいつ入ったのか。
どの順番で操作されたのか。
誰がどこで判断したのか。
どのログが、どの現象につながっているのか。
これは調べれば出てくる。
面倒ではあるけれど、掘ればだいたい何かは見える。
問題は、理だ。
理は、そこに関わった人たちの思いだと思っている。
そのコードを書いた時の自分の意図
ユーザーが言葉にできずに飲み込んだ違和感
その設計を選んだ時の迷い
本当は面倒だと思っていたけれど、誰も言わなかった空気
「こうするしかない」と思わせた現場の事情
形は見える
真は掘れる
理は黙っている
だから自分は、ここで一度止まる。
仕様書には、だいたいのことが書ける

業務アプリを作っていると、仕様書には大体のことが書ける。
フィールド名
必須項目
画面遷移
エラーメッセージ
データ型
保存先
権限
入力ルール
形は書ける。
真も、ある程度までは書ける。
けれど、どうしても紙に落ちないものがある。
たとえば、フィールド名を一つ決めるだけでもそうだ。
現場の人が緊張せずに入力できる呼び方はどれか
事務所の言葉ではなく、現場で自然に通じる言葉はどれか
硬すぎると誰も触らなくなる
砕けすぎると、今度は仕事の道具として信用されない
その間で、三十分くらい迷うことがある。
でも仕様書には、たぶんこう残る。
「項目名:加工担当者」
それだけだ。
エラーメッセージの語尾も同じだ
「入力してください」にするのか
「入力が必要です」にするのか
「未入力です」にするのか
どれでも機能としては同じかもしれない。
けれど、受け取る側の感じ方は少し違う。
現場で急いでいる人に、画面がどう声をかけるか。
そこには、小さな配慮がある。
でも仕様書には、こう残る。
「未入力時にエラー表示」
それだけだ。
行間に沈んだもの
「ここ押せない」
そう言われたことがある。
最初は、本当にボタンが押せないのだと思った。
でも見てみると、ボタンは押せる。
処理も動く。
バグではない。
では何が起きていたのか
画面の位置が悪い
手の流れと合っていない
急いでいる時間帯に、目線が一瞬迷う
押せるけれど、押せるように見えない
つまり「押せない」は、現象の名前ではなかった
その人が、その場で出せる一番短い言葉だった。
こういうものは、仕様書の表には出てこない。
コードにも直接は出てこない
ログにも残らない
議事録に書いても、たぶん薄まる
その人の横に立って、同じ画面を見て、
同じ時間帯の空気を吸って、ようやく分かることがある。
仕様書の行間に沈んでいるものは、そういうものだと思う。
形と真は、紙に書ける。
理は、行間に沈む。
自分が立っている場所
自分は専属のエンジニアではない。
昼の時間の大部分は、精密板金の現場にいる。
コードを書くのは、その日の最後の数時間だったり、夜だったり、休日だったりする。
だから、専属で開発している人たちと比べれば、不利なところはいくらでもある。
書ける量
知識の幅
新しい技術への追従
設計の経験値
そこをごまかしても仕方がない。
自分より速く、深く、きれいに書ける人はたくさんいる。

ただ、一つだけ、自分の身体が先に知っている場所がある。
現場だ
朝のミーティングで、誰がどんな顔をしていたか
棚卸しの数字を入力するとき、隣の人がどこで手を止めたか
「お疲れ様です」と書く時の、あの儀礼的な間
紙の日報の最後の余白に、何が書かれていたか
誰が面倒くさそうにして、誰が黙って合わせているか
そういう情報は、仕様書にはほとんど出てこない。
けれど、アプリを作るときには効いてくる
かなり効いてくる。
自分は、現場の身体を持ったまま、コードを書く側にも回れる。
そこが、自分の立てる場所なのだと思う。
組織の階段を一段降りないと聞こえない声がある。
自分は、たまたまその声の近くにいる。
それだけのことだ。
でも、自分にとっては大きい。
現場仕事を続けている意味を、ようやく少しだけ言葉にできるようになってきた。
AIが進むほど、残るもの
AIとコーディングエージェントは、形と真を扱うのがどんどん上手くなっている。
エラーを読ませれば、原因の候補を出してくれる
ログを渡せば、起きたことを時系列で整理してくれる
コードの差分を見せれば、どこが危ないか指摘してくれる
自分が三十分かけて追うものを、数秒で並べて見せることがある。
正直、これはかなり助かる。
変に張り合うところではない。
ただ、理は少し違う。
AIが苦手というより、そもそも材料が少ない。
誰も書き残していないものは、AIにも拾いにくい
仕様書に書かれなかった迷い
コミットメッセージに残らなかった判断
現場で飲み込まれた違和感
言葉になる前の「なんか使いにくい」
それは、データになる前のものだ。
ここに、人間の仕事がまだ残っていると思う。
大げさに「AI時代の人間の価値」などと言いたいわけではない。
ただ、AIが形と真の整理を助けてくれるなら、
自分はもっと理を拾いに行ける。
現場に立つ
横で見る
黙っている違和感を聞く
出てきた言葉を、そのまま信じすぎず、でも軽く扱わない
それをコードに、設計に、仕様書の言葉に戻す
たぶん、自分がやりたいのはそれだ。
AIに任せられるところは任せる。
そのぶん、現場に立つ人間が持ち帰れる材料を取りに行く。
それが、自分にとっての仕事になっていく気がしている。
一度立ち止まるために
形・真・理は、自分にとって小さな確認の癖だ。
形だけを見て、すぐ直さない
真だけを見て、すぐ誰かを責めない
理に触れるまで、判断を少し遅らせる
これは技術というより、作法に近い。
技術なら、いつか誰かが体系化してくれるかもしれない
けれど作法は、自分で続けるしかない。
急いでいると、形だけで片づけたくなる
原因が見えると、真だけで裁きたくなる
「こういうことだろう」と決めつけたくなる
でも、そこで一度止まる。
形は何か
真は何か
理はどこに沈んでいるか
そう考えてから手を動かす。
だから、自分はこれを流儀と呼んでいる
形と真は紙に書く
理は、聞き続けるしかない
自分の流儀は、たぶんそれだけだ
明日もまた、現場で誰かの行間を聞きに行く。