連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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回横断テストへ
勤怠申請まで作ると、人に紐付く情報もかなり増えてきました。その中の一つが、資格。
私「誰が何の資格持ってるか、分かった方がいいじゃん。」
A「資格マスタ？」
私「そう、資格名を、人ごとに毎回手入力する場合もあるって、それ嫌じゃん。」
A「同じ資格なのに、表記揺れする。」
私「そう。」
例えば、正式には同じ資格なのに、書き方が少し違うだけで、別の資格みたいに扱われる。
B「そこで、資格そのものを資格マスタとして持ち、社員にはその正式な資格を紐付けるわけですね。」
さらに、資格によっては、持っているだけでは足りません。有効期限。現在有効なのか。
私「昔取った資格でも、今使えるとは限らないじゃん。」
A「じゃあ『持ってます』だけじゃダメ。」
私「そう。」
B「資格の存在と、現在時点での有効性判定を分ける必要があります。」
でも、現場で毎回知りたいのは、その人が持っている資格の一覧全部とは限りません。
私「例えばさ、目の前の人が、玉掛け作業していいのか確認したいだけだったら？」
A「資格一覧全部はいらない。」
私「やっていいかどうかだけ分かればいいじゃん。」
A「必要な結果だけ。」
私「そう。」
ここから、資格を登録して管理するだけではなく、必要なときに、必要な情報だけ確認できないか。そんなことを考えるようになりました。
A「でも、その人をどう特定する？」
私「QRとか。」
A「QRの中に資格情報を全部入れる？」
私「入れない。」ここは、かなり大事でした。QRコードそのものに、その人の資格名。有効期限。所属。その他の情報。それを全部固定的に入れてしまう。
私「それやったら、情報変わるたびにQR作り直すの？」
A「資格更新したら貼り替え。」
私「嫌でしょ。」
B「QRへ業務情報そのものを詰め込むのではなく、対象を識別するための入口として使うわけですね。」
A「じゃあQRの中には何があるの？」
私「その人の正式なデータへたどり着くための識別情報。」
A「QRを読む。」
私「うん。」
A「識別情報を受け取る。」
私「うん。」
A「正式な対象を探す。」
私「そう。」
A「そこから、許可された情報を返す。」
私「それ。」
B「技術的には、識別子による参照ですね。」
つまり、QRは、情報の保管場所ではない。正式な対象への入口。だから、資格情報が更新されても、QRそのものを作り直さなくていい。
A「同じQRから、その時点の正式なデータを参照する。」
私「そういう考え方。」
B「識別子と業務情報の分離ですね。」
でも、ここでまた問題が出ます。
A「そのQR読んだ人って、その人の情報全部見えるの？」
私「それも嫌じゃん。」
A「だよね。」
例えば、本人。現場担当者。管理者。一般利用者。同じQRを読んだからといって、全員に同じ情報を見せる必要はありません。
私「QR読めたからって、全部見せる必要ないでしょ。」
B「第7弾の認可が、ここでも戻ってきますね。」
A「QRを読めたことと、情報を見る権限があることは別。」
私「そう。」
でも、考えていくと、それだけでも足りませんでした。
私「そもそも、相手側に『必要な情報だけ取ってね』って任せるのも違う気がする。」
A「相手のシステム側で、必要な項目だけ取得するように設定すればいいんじゃない？」
私「それだと、何を取るか決めるのは相手側じゃん、自分のデータなんだから、自分でどこまで使わせるか決められた方が安全じゃない？」
B「データを取得する側ではなく、提供する側にも制御権を持たせるわけですね。」
ここで、QRの「用途」という考え方が重要になってきました。何のために、このQRを使うのか。単純にQRを表示したいのか。資格に関する情報を見せたいのか。将来的には、資格確認なのか。入場確認なのか。安全教育の確認なのか。
私「用途が違えば、必要な情報も違うじゃん。」
A「入場したいだけなのに、その人の情報全部はいらない。」
私「そう。」
A「でも、用途を毎回選ぶの面倒って言われない？」
私「たぶん言われる（笑）」
A「じゃあ自動でよくない？」
私「そこを全部相手任せにしたら、自分のデータを自分で守れなくなるじゃん。」
A「なるほど。」
私「ひと手間増えても、『今回は何のために使うのか』を自分で決める意味はあると思う。」
B「用途選択そのものを、単なるメニューではなく、情報利用の範囲を本人側で確定するための操作として考えるわけですね。」
もちろん、用途を選んだからといって、何でも自動的に相手へ渡すわけではありません。相手側から追加の情報を求められる場合もあります。
A「例えば？」
私「資格の確認で、相手がもう少し詳しい情報を見たいとか。」
A「その場合は？」
私「何を要求されてるか見て、自分で決めればいい。」
A「全部許可か、全部拒否？」
私「いや。一部だけ許可できた方がいい。」
例えば、相手から複数の情報について開示要求が来たとしても、必要だと思う項目は許可する。必要ないと思う項目は許可しない。
私「相手が欲しいって言ったから、全部渡す必要ないでしょ。」
A「本人が項目を選ぶ。」私「そう。」
B「選択的開示ですね。」
ここまで考えると、「QRを読めるか」だけではなくなってきます。誰がアクセスしてよいのか。何の用途なのか。どの情報まで利用してよいのか。追加で要求された情報のうち、本人が何を許可するのか。それぞれを分けて考える必要が出てきました。
A「権限とは同じ？」
B「完全には同じではありません。」
A「どう違う？」
B「認可は、そもそもその情報や機能へアクセスしてよいかという制御です。情報開示では、その許可された範囲の中で、実際に何を返すのかまで考えます。」
A「見せる・見せないだけじゃなくて、返す内容そのものを絞る。」
私「そういうこと。」
B「これはデータ最小化や最小限開示につながる考え方ですね。」
さらに将来的には、誰が読むか。何のために読むか。どこで読むか。いつ読むか。対象が今どんな状態なのか。そうした条件まで含めて、返す内容を変えることも考えられます。
B「そこまで広げると、コンテキスト依存の情報開示ですね。」
私「でも、それはまだ先。」
A「また将来構想（笑）」
私「実装してないものまで、できてるみたいに言いたくないから」
ここで、一度QRの考え方を整理しました。
A「QR、一回整理しよう。」
私「どうぞ。」
私「QRに資格情報そのものを固定で詰め込まない。」
B「識別子と業務情報の分離。」
私「QRから正式な対象へたどり着く。」
B「識別子による参照。」
私「QRを読めても、全部の情報を見せるわけじゃない。」
B「認証・認可との分離。」
私「用途によって、使わせる情報の範囲を考える。」
B「目的制限とデータ最小化ですね。」
私「追加で情報を求められても、全部許可する必要はない。」
B「選択的開示。」
私「必要以上の情報を出さない。」
B「最小限開示。」
A「QRって、『リンク開くやつ』くらいの話じゃなかった（笑）」
私「俺も最初はもっと簡単に考えてた」
ただし、ここも、現行と将来構想は分けます。今ある土台では、識別情報から正式な対象へたどり着き、権限や用途を意識しながら、開示する情報を制御する仕組みを作っています。そして現在は、その用途の一つとして資格確認までつながりました。
例えば資格確認なら、資格一覧を全部相手へ渡すのではなく、必要な条件を内部で確認して、「この作業をしてよい」という結果だけを返す。必要以上の元データそのものを渡さず、必要な判定結果だけを返す。
そこから先、入場確認。安全教育。車両利用。機器利用。講習受付。支給品受取。さらに、人だけではなく、物や場所へ広げる。そういう展開も考えられます。
例えば将来、入場確認なら、入場に必要な条件を内部で確認して、「入場可」という結果だけを返す。そんな使い方も考えています。
B「現行の土台と拡張可能性を分けるのは重要ですね。」
そして、正式な対象へ、正しくたどり着く仕組みを考えていたら、今度は逆方向の疑問が出てきました。
私「コンピュータ側は、正式な対象をちゃんと見てればいい。」
A「うん。」
私「でも使う人まで、正式名称を全部覚える必要ある？」
A「例えば？」
私「分かりやすい例えて言うと一輪車。」
A「うん。」
私「現場で『ネコ』って呼ぶ人いるじゃん。」
A「そうなんだ。」
私「『ネコ』で探して出ないの、不便じゃない？」
A「次は人間側の曖昧さか（笑）」
B「今度は、システム内部の厳密さを保ったまま、人間側の入口を柔らかくする話ですね。」
次回「一輪車を“ネコ”で探せないの不便じゃん」で、Canonical IDと人間の曖昧さを両立させることになった
人間には優しく、内部は厳密に――別名検索から正式IDへ収束させるまで
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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回横断テストへ