物件マスタまで作ると、今度は、会社ごとの差が目立つようになりました。
私「同じものでもさ。」
A「うん。」
私「『物件』って呼ぶ会社もあれば、『現場』って呼ぶ会社もあるじゃん。」
A「あるね。」
私「予約の時間単位だって違う。」
A「15分とか30分とか。」私「休日の扱いも違うかもしれない。」
A「……だんだん名前の話じゃなくなってきたな（笑）」
最初は、単純に、表示する名前を変えられればいいと思いました。
物件。現場。
会社によって、普段使っている言葉に合わせる。
私「そのたびにコード直す必要ないじゃん。」
A「設定で変える？」
私「そう。だから、会社ごとに表示する言葉を変えられる文言変更モードを作った。」
A「『案件番号』を『工事番号』にするとか？」
私「そう。利用者が普段使ってる言葉に合わせる。」
（文言変更モード）
（黄色部分→変更可能）※全ページ対応
（案件番号→工事番号へ変更）
（変更反映）
A「それなら分かりやすい。」
私「この頃は、まだそう思ってた（笑）」
B「表示する文言を設定として持たせて、コードを書き換えずに切り替える。Configuration-Driven Design、設定駆動ですね。違いをコードへ直接固定せず、設定値によって表示や振る舞いを変える考え方です。」
私「当時は『毎回コード直すの面倒』だけ。」
A「原動力がずっと同じ（笑）」
でも、会社ごとに違うものは、名前だけではありませんでした。
カテゴリ。表示順。アイコン。予約時間単位。休日を含めるか。どの機能を表示するか。
（設定種別）
私「こういうのも会社によって違うじゃん。」
A「ねえ。」
私「何？」
A「『設定にすればいい』って、実装側からすると結構怖い言葉だよ（笑）」
私「いいじゃん、実装するのも自分なんだから。」
A「そういうことじゃない。」
そして、設定できるようにしたら、当然、何でも入れていいわけではありません。
例えば、予約の時間単位。
10分。15分。30分。60分。
ここまでは分かる。
では、0分。－30分。文字。存在しない選択肢。
A「止めるよね？」
私「止める。」
B「そこでバリデーションです。型・範囲・許容値を確認します。」
私「設定で壊れたら意味ないじゃん。」
A「そこは正しい（笑）」
でも、一個ずつの値が正しくても、まだ安心できません。
例えば、ある機能自体は、無効。
なのに、その機能専用の設定だけ、有効。
A「入力値だけ見れば、どっちも正常。」
私「でも組み合わせたら変。」
B「こうした複数項目の関係を見るのが、クロスフィールドバリデーションや整合性制約ですね。」
私「要するに、一個ずつOKでも全体でおかしかったら止める。」
A「設定画面作るだけだったよね？」
私「設定で壊れないようにしただけだよ」
A「その『だけ』をもう信用してない（笑）」
さらに、会社ごとに名称を変えるなら、別の問題もあります。
私「画面では『現場』って出す会社と、『物件』って出す会社があっていい。」
A「うん。」
私「でも、裏側まで別物になったら困る。」
A「確かに。」
例えば、会社Aでは、現場。
会社Bでは、物件。
画面に見える言葉は違う。でも、内部では、同じ種類のデータです。
私「表示名が変わったからって、別の物として保存したくない。」
B「そこで内部値と表示値の分離です。」
A「利用者には会社ごとの言葉。」
私「裏では同じ正式な対象。」
だから、保存や紐付けには、安定した正式IDを使う。
画面では、会社に合った表示名を使う。
私「表示文字そのものを保存の基準にしたら、名前変えたとき怖いじゃん。」
A「『物件』を『現場』に変えたら、紐付けまで変わるとか嫌だね。」
私「そう。」
B「**表示は変えられる。でも識別は変えない。**という分離ですね。」
A「じゃあ設定画面で、『物件』を『現場』に変えました。」
私「うん。」
A「管理画面は変わった。」
私「うん。」
A「一覧画面は？」
私「変わらないとダメ。」
A「予約画面は？」
私「そこも。」
※キャンセル待ちの仕組みや、順番・確定競合をどう守っているかは、第8弾で触れます。
A「検索は？」
私「同じ正式対象を見る。」
A「履歴は？」
私「同じ。」
A「……これ、設定画面だけ作って終わりじゃないじゃん。」
私「そうなんだよ。」
一か所で設定を変えたなら、実際にその設定を使う画面も、全部追従しなければならない。
設定画面だけ「現場」になっている。
でも、一覧には、昔の固定文字で「物件」が残っている。
私「それ、一番嫌なやつ。」
B「設定反映漏れや固定値の残存ですね。」
A「設定駆動にしたなら、固定UIが一個残ってるだけでも中途半端。」
私「後々、そこはかなり気にするようになった。」
A「一回整理しよう。」
私「はい。」
私「会社ごとに名称やカテゴリを変える。」
B「設定駆動。」
私「変な設定値は入れさせない。」
B「バリデーション。」
私「一個ずつ正しくても、成立しない組み合わせは止める。」
B「整合性制約・クロスフィールドバリデーション。」
私「会社ごとに表示名が違っても、内部では同じ対象。」
B「内部値と表示値の分離。」
私「保存や紐付けは正式ID。」
B「正式IDによる参照。」
私「設定を変えたら、実際の利用画面まで追従させる。」
B「設定反映・固定値残存対策。」
A「『会社ごとにちょっと変えたい』から、全画面の話になってる（笑）」
なお、ここでいう設定駆動化は、全画面・全文言から固定値を完全に排除できている、という意味ではありません。
固定実装が残っていないかは、現在も確認を続けています。
私「一回ちゃんと作れば――」
A「好きだねえ、それ（笑）」
私「まだ言い終わってない（笑）」
でも、会社ごとの設定が増えてくると、次に気になったのが、誰がその設定を触っていいのか。
私「ログインできたからって、誰でも会社の設定変えられたらまずいじゃん。」
A「来た。」
私「何が？」
A「設定の次は権限（笑）」
B「次は、『誰であるか』だけではなく、何を許可するかですね。」
次回
「ログインできたからって何でも触れたらまずいじゃん」で、認証より面倒な認可の沼に入った
管理者か一般かでは足りず、「誰が・誰に・何をできるか」まで判定することになった
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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の作業速度が人間のレビュー限界を超えた ※コードベース横断調査が便利すぎて、変更範囲・Git・差分・安全コミットが主役になった(近日公開予定)
- #15「テストこんなに通るじゃん」で安心しかけたら、“全部緑なのに間違ってる”が普通に出てきた ※横断テストで見えた、Interaction Bug・境界値・期待結果そのものの罠(近日公開予定)
- #16「人間＋AI＋Codex、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)