会社ごとの設定を増やしていくと、当然、次の疑問が出ました。
私「これ、誰でも変更できたらまずいじゃん。」
A「ようやくそこ来たか。」
私「何が？」
A「権限。」
私「ログインしてるかどうかとは違うの？」
A「違う。」
B「ログインしている本人が誰なのか確認するのが認証（Authentication）。その人が何をしてよいか判断するのが認可（Authorization）ですね。」
私「当時はそんな区別知らないよ。『ログインできても、何でも触れたらダメでしょ』くらい。」
最初は、単純に考えていました。
管理者。
一般ユーザー。
私「管理者だけ設定変えられればいいじゃん。」
A「最初はね。」
私「その言い方やめろ（笑）」
例えば、会社設定。マスタ設定。利用者管理。
一般ユーザーには触らせない。管理者だけが操作できる。
ここまでは分かりやすい。
でも、実際の機能を見ていくと、それだけでは足りませんでした。
私「例えば予約って、一般ユーザーでもするじゃん。」
A「する。」
私「でも他人の予約まで勝手に消せたらダメじゃん。」
A「そう。」
私「自分の予約なら変更できる。でも他人の予約はできない。」
B「役割だけではなく、対象データとの関係まで見始めたわけですね。」
さらに、物件。
私「現場担当者なら、自分の担当現場についてはできること増やしたい場合あるじゃん。」
A「全社管理者じゃなくても？」
私「そう。」
A「じゃあ『管理者／一般』だけじゃ足りない。」
私「足りなかった。」
ここで、権限が単純な二択ではなくなりました。
誰が。
誰に。
何を。
どの範囲でできるのか。
B「Role-Based Access Control（RBAC）だけでなく、対象や関係性を含めた認可判定が必要になりますね。」
私「また名前あるの？」
A「あるよ（笑）」
そして、組織を複雑にしたツケも来ました。
A「第4弾で複数所属とか会社またぎまで作ったツケが来た（笑）」
私「大将、ツケ払いに来たよ！」
A「ツケが溜まりすぎて、店（システム）が傾きかけてんだよ！（笑）」
例えば、一人の人が複数部署に所属している。
別会社へ出向している。
グループ会社とも関係している。
私「この人、どこの権限で今操作してるの？ってなる。」
A「ほら（笑）」
B「所属情報が複数あるなら、認可時にどの所属コンテキストで操作しているのかも重要になります。」
私「一人に権限一個付ければ終わりじゃないんだよね。」
A「第4弾で自分から一人を複数にしたからね。」
私「あの時は便利だと思ったんだよ（笑）」
さらに、会社をまたぐなら、もっと怖いことがあります。
私「A社の人が、B社のデータ見えたらまずいじゃん。」
A「それはかなりまずい。」
B「テナント分離ですね。会社ごとのデータ境界を越えさせない。」
私「画面でB社を選べないようにすればいい？」
A「ダメ。」
私「なんで？」
A「画面にボタンがなくても、裏のAPIを直接叩けたら？」
私「……ああ。」
B「UIで非表示にすることと、認可することは別です。」
私「画面で触れなくても、裏から触れたら意味ないじゃん。」
A「そう。それ。」
だから、画面側だけではなく、サーバー側でも権限を確認する必要がありました。
誰がログインしているか。
その人は、どの会社に所属しているか。
どの対象を操作しようとしているか。
その操作を許可されているか。
B「サーバー側で認可判定を行う、Server-Side Authorizationですね。」
私「画面を信用しないってこと？」
A「そう。画面は操作しやすくするためのもの。最後に守るのはサーバー。」
そして、管理者にも種類が必要になりました。
私「会社全体を管理する人と、一部だけ管理する人って違うじゃん。」
A「また増やす？」
私「でも全部同じ管理者にしたら、権限強すぎる場合あるでしょ。」
B「最小権限の原則（Principle of Least Privilege）ですね。必要な操作だけ許可する。」
私「俺は『必要ないところまで触れなくていいじゃん』だけ。」
A「また技術名が後から追いかけてきた（笑）」
権限を細かくすると、今度は変更そのものも怖くなります。
例えば、管理者が自分自身の権限を変更する。
私「自分で自分を何もできない状態にしたら？」
A「管理者いなくなる可能性あるね。」
私「最後の管理者だったら？」
A「会社詰む（笑）」
B「権限管理では、自己変更や最後の管理者保護も重要な論点になります。」
私「権限を変更できる権限って、考え始めると面倒だな。」
A「認可が面倒って言っただろ（笑）」
A「整理するよ。」
私「はい。」
私「ログインしてる人が誰か確認する。」
B「認証。」
私「その人が何をしていいか決める。」
B「認可。」
私「管理者か一般かだけじゃなく、対象との関係も見る。」
B「RBAC＋対象・関係性による認可。」
私「複数所属なら、どの立場で操作してるかも見る。」
B「所属コンテキスト。」
私「別会社のデータを触らせない。」
B「テナント分離。」
私「画面で隠すだけじゃなく、裏でも止める。」
B「サーバーサイド認可。」
私「必要以上の権限を持たせない。」
B「最小権限の原則。」
A「『ログインできたからって何でも触れたらまずいじゃん』から、ここまで来た。」
私「でも全部、その一言の延長じゃない？」
A「使う側から見ればな（笑）」
そして、権限まで入れて安心した頃、もっと嫌なことに気づきました。
画面に、在庫が「残り1個」と表示されている。
二人が、ほぼ同時にその画面を見ている。
私「二人とも『1個ある』って見えてるじゃん。」
A「うん。」
私「二人とも同時に取ったら？」
A「……。」
私「2個出ていかない？」
A「やっと来たか。」
次回
画面には、「残り1個」と表示されている。
二人とも、その同じ画面を見ている。
どちらから見ても、まだ在庫はある。
だったら、先に押した方だけ成立させればいい。
最初は、それくらいの話だと思っていました。
――二人がほぼ同時に押すまでは。
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)