連載公開分（クリックで開く）

# 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた全16弾無邪気な実装 vs 架空エンジニア2人の容赦なきツッコミ ※便利かなと思ってどんどん追加しちゃうんだよね
#1「在庫が見たいだけ」だったのに、引き算ひとつから在庫引当と多目的最適化まで始まった ※ 総在庫・予約在庫・有効在庫を分けた瞬間、ただの在庫表示が別物になった
#2「予約機能もこのアプリ1個にまとめれば便利じゃん」で、“時間”が一気に牙をむいた ※時間重複・境界条件・時間粒度・スマホ操作まで、空いてる時間を選ぶだけでは終わらなかった
#3 「機能増えたら毎回探すの面倒じゃん」で、お気に入りから共通UI設計まで広がった ※機能を増やした結果、「何を作るか」より「どう辿り着くか」が問題になった
#4「普通の組織図でいいじゃん」で一人を複数部署に入れたら、“多対多”が始まった ※兼務・複数所属・部署別役職・過去履歴が一気に絡み始めた
#5「どこの現場で使うかも持てばいいじゃん」で、物件マスタが在庫・予約・人を全部つないだ ※機能ごとにバラバラだった情報が、共通マスタを境に一つのシステムへ変わり始めた
#6「会社ごとにちょっと変えたい」で、設定駆動とバリデーションが殴り合いを始めた ※柔軟にしたら、「自由に設定させすぎない仕組み」の方が難しくなった
#7「ログインできたからって何でも触れたらまずいじゃん」で、認証より面倒な認可の沼に入った ※管理者か一般かでは足りず、「誰が・誰に・何をできるか」まで判定することになった
#8「二人とも空いてる画面を見てたら、どっちが勝つの？」でRace Conditionが牙をむいた ※在庫も予約も、画面に表示された「空き」を信用しただけでは守れなかった
#9「自分の在庫も持てた方が楽じゃん」で、“場所・所有・利用範囲”が全部別問題だった ※マイ在庫・現場在庫・共有在庫を分けたら、在庫数よりスコープ管理が難しくなった
#10「申請もこの中でできた方が楽じゃん」で、CRUDの裏に状態遷移が増殖した ※申請・承認・差し戻しを入れた瞬間、「保存できる」だけでは何も足りなくなった
#11「資格もQRで見られたら早いじゃん」で、“全部見せる”より“必要な答えだけ返す”方が難しかった ※資格・個人QR・権限をつないだら、識別より情報開示の方が本題になった
#12「一輪車を“ネコ”で探せないの不便じゃん」で、Canonical IDと人間の曖昧さを両立させることになった ※人間には優しく、内部は厳密に−−別名検索から正式IDへ収束させるまで
#13「機能増えすぎて説明する方が面倒」で、“どれが今の正解？”問題がコードの外まで広がった ※ヘルプ・仕様・会話・引き継ぎがズレ始め、Single Source of Truthが必要になった
#14「Codexなら全部見てくれるじゃん」で、AIの作業速度が人間のレビュー限界を超えた ※ AIがリポジトリ全体を調べられるほど変更範囲が怖くなる――Gitで差分・ステージ・既存変更・コミット境界を守る開発へ
#15「テストこんなに通るじゃん」で安心しかけたら、“全部緑なのに間違ってる”が普通に出てきた ※ テストがPASSでも正しいとは限らない――機能間の不具合・境界値・回帰・期待結果そのものまで疑う横断テストへ
#最終回【AIの尻拭い】JSONのまま押し通したら、AIたちが「最小トランザクションジャーナル」まで考え始めた ※「こうしたい」の一言から、AIとCodexが複数JSON更新の整合性リスクを発見し、Crash Recovery・回帰テスト・Git安全境界まで組み上げる開発へ
#エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※ 単体テストはPASS、次は“全部つないで壊れないか”第2回横断テストへ

前回、QRでは、入口が何であっても、最後は正式な対象へたどり着く、という話が出ました。そこで逆に、人間が検索するときのことが気になりました。

私「コンピュータは正式IDで厳密にやればいいじゃん。」

A「うん。」

私「でも人間まで、正式名称を完全に覚える必要ある？」

A「例えば？」

私「一輪車。」

A「うん。」

私「現場で『ネコ』って呼ぶ人いるんだよ。」

A「そうなんだ。」

私「じゃあ『ネコ』って検索して、一輪車が出ないの不便じゃん。」

B「そこでAlias、エイリアス・別名管理ですね。」

私「当時は『普段の呼び方でも探せればいいじゃん』だった。」

ただし、ここでやりたかったのは、単純な、「ネコ＝一輪車」という共通辞書だけではありません。

A「違うの？」

私「もっと個人寄り。」

例えば、Dさん。Dさんは、一輪車のことを「ネコ」と呼んでいる。
だから、Dさんが自分のアカウントで、一輪車に「ネコ」という自分用の呼び名を付ける。
その後、Dさんが、自分のアカウントで「ネコ」と検索する。
すると、一輪車が出る。

A「ここまでは分かる。」

私「じゃあEさん。」

Eさんは、なぜか、脚立のことを「ネコ」と呼んでいる。

A「ややこしい人だな（笑）」

私「あくまで例えだよ」

Eさんは、自分のアカウントで、脚立に
「ネコ」という呼び名を付ける。
そして、Eさんが、自分のアカウントで
「ネコ」と検索する。

A「一輪車？」

私「違う。脚立。」

A「同じ『ネコ』なのに？」

私「そう。」

つまり、Dさんのアカウント
「ネコ」
↓
一輪車

一方、Eさんのアカウント
「ネコ」
↓
脚立になる。

A「なるほど。」

私「システムが『ネコとは一輪車です』って決めてるわけじゃない。」

A「じゃあ何を持ってる？」

私「この人が、この正式な物に、この呼び名を付けたっていう対応関係。」

B「つまり、利用者＋別名＋正式対象のマッピングですね。」

私「それ。」

A「これが今回の芯だな。」

A「でも、別名を増やせるならさ。」

私「何？」

A「正式名称そのものを変更したい場合は？」

私「それは別。」

A「Alias追加とは一緒にしない？」

私「しない。」

B「Canonical Nameの変更とAlias追加は別操作ですね。」

例えば、正式名称そのものが変更された。その場合は、正式名称を変更する。必要なら、昔の正式名称を、別名として残す。

A「昔の名前で検索する人もいるから。」

私「そう。」

A「『名称変更』と『自分の呼び方を追加』は意味が違う。」

私「そこは分ける。」

そして、ここからは将来構想。この辞書の考え方を使えば、多言語表示にも広げやすいと考えています。

私「例えば外国人実習生が、アプリ自体を母国語版で使ってるとするじゃん。」

A「うん。」

私「でも現場で、『これ日本語だと何？』って知りたいときあるじゃん。」

A「その場で毎回AI翻訳？」

私「それだけに頼らなくてもいい。」

同じ正式な対象に、日本語名称。英語名称。必要な他言語の名称。を辞書として紐付けておく。

私「だったら表示する言語を切り替えやすいでしょ。」

B「将来的には、同じCanonical IDへ言語別表示名を持たせるLocalized Layerですね。」

例えば、普段は母国語表示。でも、日本人の担当者へ説明するときだけ、日本語表示を確認する。

私「自分の言葉で使えて、必要なときは相手の言葉でも見せられる。」

A「その場で毎回訳すというより、登録済みの辞書から同じ物の日本語名を見る。」

私「そういう構想。」

ここは、現在のエイリアス機能と、将来の多言語表示を混ぜません。

A「今もう全言語切り替えできる、って話じゃない。」

私「そこは将来構想。」

A「整理するよ。」私「どうぞ。」

私「自分が分かる呼び方で探せる。」
B「Alias・別名管理。」
私「Dさんの『ネコ』は一輪車。」
B「利用者＋別名＋正式対象のマッピング。」
私「Eさんの『ネコ』は脚立。」
B「利用者コンテキストを含む別名解決。」
私「正式名称も一緒に画面へ出す。」
B「個人語彙と正式語彙の併記。」
私「別名ごとに新しい商品は作らない。」
B「Canonical IDへの集約。」
私「正式名称変更と別名追加を分ける。」
B「Canonical NameとAliasの分離。」
私「将来的には言語ごとの表示名にも広げたい。」
B「Localized Layer。」

A「表では『ネコで探したい』だけなのに。」

私「うん。」

A「裏ではCanonical IDとかName Resolutionとか（笑）」

私「俺の言い方だと、自分の好きな呼び方で探しても、同じ物は同じ物として扱ってほしい。」

A「それでいい（笑）」

こうして、正式名称。表示名。個人の別名。会社ごとの呼び方。将来の多言語。

扱う表示が増えてくると、今度は、別の面倒が目立つようになりました。

同じことを説明しているはずなのに、ヘルプ、仕様書、会話、引き継ぎで、少しずつ内容が違う。

私「……で、今の正解どれ？」

A「また面倒なの見つけたな（笑）」

次回

「機能増えすぎて説明する方が面倒」で、“どれが今の正解？”問題がコードの外まで広がったヘルプ・仕様・会話・引き継ぎがズレ始め、Single Source of Truthが必要になった

連載公開分（クリックで開く）