連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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が必要になった
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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回横断テストへ