在庫。予約。少しずつ機能が増えてくると、別の面倒が出てきました。
私「機能増えてくるとさ。」
A「うん。」
私「使いたい機能を毎回探すの面倒じゃん。」
A「自分で機能増やしたんだろ（笑）」
最初は機能が少ない。だから、トップ画面から目的の機能を探しても、そんなに困りません。
でも、在庫。予約。その先にも、いろいろな画面が増えていく。
私「毎日使う機能って、人によって違うじゃん。」
A「在庫ばっかり使う人もいる。」
私「予約ばっかり使う人もいる。」
A「じゃあ？」
私「よく使うやつだけ、お気に入りにできればいいじゃん。」
そこで、利用者ごとによく使う機能を登録できる、お気に入りを作りました。
A「会社全員で同じお気に入り？」
私「いや。これは個人。」
A「自分で選ぶ。」
私「そう。」
B「ユーザー単位のパーソナライズですね。」
でも、お気に入りをトップ画面に置くだけだと、まだ少し不便でした。
例えば、予約画面の奥まで入っている。そこから、今度は在庫を見たくなった。
A「一回トップに戻る？」
私「それ面倒じゃん。」
A「またそれ（笑）」
私「今いる画面から、そのまま飛べた方が早いでしょ。」
そこで、お気に入りをトップ画面だけではなく、固定フッターにも置きました。
画面の奥へ入っていても、下にはお気に入りが残る。そこから、別のよく使う機能へ直接移動できる。
私「予約見てて、在庫見たくなったらそのまま在庫へ。」
A「トップへ戻ってメニュー探して、を省く。」
私「そう。」
B「単なるお気に入り一覧ではなく、常時アクセスできるナビゲーションになったわけですね。」
A「今、お気に入り何個出してるの？」
私「4スロット。」
A「4個固定？」
私「いや。」
現状の表示は、4スロット。でも、表示スロット数そのものは設定できるようにしました。そして仕組みとしては、最大8スロットまで対応できる余地を持たせています。
（4スロット）
（設定画面）
（8スロット）
A「なんで8？」
私「今後もっと機能が増えることがあっても、すぐ上限に当たらないように。」
A「じゃあ将来8個表示するって決めてる？」
私「決めてない。」
A「今は4個。」
私「そう。8個は余裕を持たせてあるだけ。」
B「現在のUI仕様と、将来の拡張余地を分けているわけですね。」
A「でもさ。」
私「何？」
A「機能増やして、今度はその機能を探すのが面倒になって、お気に入りを作った。」
私「うん。」
A「機能を増やした結果、機能を探す手間を減らす機能まで増えたの？」
私「……そうなるね」
A「自分で問題作って自分で解決してる（笑）」
私「でも使いやすくはなるだろ」
そして、固定フッターを作ったことで、別のことも気になり始めました。
私「これ、各画面に同じフッターを別々に書くのも嫌じゃん。」
A「また同じもの何回も作りたくない病。」
私「だって一個変えるたびに全部直すの？」
A「確かに。」
例えば、お気に入りの表示方法を変える。アイコンを変える。メニューの扱いを変える。それなのに、画面ごとに別々のフッターを持っていたら、変更するたびに全部の画面を確認しなければならない。
私「だったらフッター自体を共通にした方がいいじゃん。」
A「出た。」
私「何？」
A「“一回共通にすれば後が楽”のやつ（笑）」
こうして、単なるお気に入りから、共通フッターという考え方へ広がりました。
B「ここから共通UIコンポーネントの考え方が強くなっていきますね。」
私「当時は『同じフッター何個も作る必要ないじゃん』だけ。」
A「いつも技術名より先に面倒が来る（笑）」
そして、共通化すると、今度は逆に、共通にしていいものと、個人に任せるものを分ける必要があります。
A「フッターそのものは共通。」
私「そう。」
A「でもお気に入りの中身は？」
私「利用者ごと。」
A「全員同じにしない。」
私「使う機能違うからね。」
B「共通UIの上にユーザー固有設定を重ねる構造ですね。」
A「じゃあ整理。」
私「はい。」
私「よく使う機能を自分で登録する。」
B「ユーザー単位のパーソナライズ。」
私「トップだけじゃなく、画面の奥からでも使えるようにする。」
B「固定ナビゲーション。」
私「現在は4スロット表示。」
A「でも？」
私「表示数は設定可能で、仕組みとして最大8スロットまで対応できる余地を持たせた。」
A「8個使うと決めたわけではない。」
私「そう。」
私「各ページで同じフッターを別々に持たない。」
B「共通UIコンポーネント。」
A「最初は？」
私「機能増えたら毎回探すの面倒じゃん。」
A「そこから共通UIまで行った（笑）」
そして、お気に入りが使う機能を増やすほど、もう一つ、同じことを何度も登録する面倒が見えてきました。
予約する人。在庫を使う人。現場を担当する人。
私「これさ、同じ人を機能ごとに登録するのおかしくない？」
A「次は人？」
私「会社とか部署も。」
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、ここまで来たら完成でしょ？」で、開発体制そのものをプロにダメ出しされた ※完全な、ど素人から辿り着いた現在地−−でも最後まで人間が働きすぎだった(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※やっぱりプロのエンジニアは凄いですね。(近日公開予定)