マイ在庫や、現場共有在庫まで作っていた頃、在庫とは別の業務も、同じアプリに入れ始めました。
私「勤怠申請も、この中でできた方が楽じゃん。」
A「勤怠って、出勤・退勤まで全部？」
私「いや、そこは混ぜない。」
A「じゃあ？」
私「この頃の中心は、有給とかの勤怠申請。」
B「申請ワークフローですね。」
最初だけ見れば、そんなに難しく見えません。
申請内容を入力する。送る。上司側が確認する。承認する。
私「普通でしょ？」
A「問題があったら？」
私「差し戻す。」
A「差し戻された人は？」
私「直して、もう一回出す。」
A「もう“保存するだけ”じゃない（笑）」
同じ一件の申請でも、途中で状態が変わります。
申請中。承認済み。差し戻し。そして、差し戻された内容を修正して、再申請。
私「その状態によって、できること変わるじゃん。」
A「例えば承認済みなのに、もう一回承認。」
私「ダメ。」
A「承認済みから、勝手に申請中へ戻す。」
私「ダメ。」
A「差し戻されたから修正して再申請。」
私「それはあり。」
B「これがState Transition、状態遷移です。どの状態から、どの状態へ移れるかを決めます。」
A「でもさ。」
私「何？」
A「画面で承認ボタン消しとけばいい？」
私「第7弾でやったでしょ（笑）」
A「認可。」
私「そう。画面だけじゃなく、確定するときも見る。」
例えば、一般利用者が、申請を出すことはできる。でも、その人自身が、自分の申請を承認できたらおかしい。
私「承認できる人じゃないと、承認させない。」
A「部署とか役割も見る？」
私「使えるものは、もう作ってある組織情報を使う。」
B「ここで、それまで作ってきた組織情報と認可が申請へ乗ってきます。」
つまり、勤怠申請用に、また別の会社情報を作る。別の部署一覧を作る。別の社員名簿を作る。そんなことはしない。
私「同じ会社、同じ部署、同じ人なんだから。」
A「既存のものを使う。」
私「そう。」
B「共通基盤へ業務機能を載せることで、二重管理を減らすわけですね。」
さらに、申請では、今どうなっているかだけ分かればいいわけでもありません。
A「差し戻された。」
私「うん。」
A「誰が？」
私「残したい。」
A「いつ？」
私「それも。」
A「その後、再申請した。」
私「それも追いたい。」
B「そこで履歴管理が必要になります。」
私「後から『なんでこうなってるの？』ってなったとき、現在の状態だけ見ても分からないからね。」
そして、また前の問題が戻ってきます。
A「同じ申請を、管理側の二人が開いてる。」
私「うん。」
A「一人が承認。」
私「うん。」
A「ほぼ同時に、もう一人が差し戻し。」
私「第8弾。」
A「競合（笑）」
最初に承認されたのに、古い画面を見た別の人が、そのまま差し戻しを成立させる。逆もある。
私「だから今の状態を見ずに、そのまま状態変えたらダメ。」
B「承認／差し戻しの競合ですね。」
A「予約や在庫でやった話が、申請でも戻ってきた。」
私「そうなんだよ。」
二重承認も同じです。
一人が、すでに承認している。でも、別の人の画面には、まだ承認ボタンが残っている。
A「押したら？」
私「現在状態を確認して、もう承認済みなら成立させない。」
A「また画面の表示を信用するな、と。」
私「この辺から何回も出てくる（笑）」
A「一回整理する。」
私「どうぞ。」
私「有給などを申請する。」
B「申請Workflow。」
私「申請中、承認済み、差し戻しを勝手に行き来させない。」
B「State Transition。」
私「承認できる人を制限する。」
B「Authorization。」
私「会社・部署・人は、既存の組織情報を使う。」
B「共通マスタの再利用。」
私「誰が何をしたか残す。」
B「履歴管理。」
私「同時に承認や差し戻しが来たら、そのまま両方通さない。」
B「競合制御。」
A「……有給申請一個に、前までの技術かなり乗ってない？」
私「乗ってる（笑）」
B「業務システムでは、個々の技術が単独で存在するというより、一つの業務フローの中で組み合わさることが多いですね。」
A「この辺から、作る側かなり大変じゃない？」
B「かなり大変ですね。」
私「二人とも急に作る側の顔になるな（笑）」
A「だってさ。」
私「何？」
A「『有給申請作りたい』って、“画面一枚追加でしょ”くらいに思われてたら地獄じゃん（笑）」
私「俺は最初、その側だったけどね（笑）」
そして、この頃には、機能を一個増やすたびに、見るものも増えていました。
画面。権限。状態。既存の組織情報。競合。履歴。
A「前は『ボタン押したら保存』だったのに。」
私「だいぶ変わったね。」
B「機能数だけではなく、機能同士の依存関係が増えてきています。」
なお、この頃に考えていた業務を、全部「完成済み」とは扱いません。
例えば、日報は土台があっても、会社ごとの差をどう吸収するかは検討が残る。
企業間で扱う、作業伝票のようなものも考えていた。
私「考えてるものと、できてるものは分ける。」
A「混ぜるな危険！」
私「洗剤みたいに言うな（笑）」
そして、人を共通で管理するようになったことで、次に欲しくなったのが、資格情報。
私「現場だと、『この人この作業できる？』って確認するじゃん。」
A「資格。」
私「そう。」
A「資格一覧見れば？」
私「一覧全部見たいんじゃないんだよ。」
A「じゃあ？」
私「例えば、この人、今この作業やっていいの？って結果が欲しい。」
B「次は、資格管理だけではなく情報開示の仕方ですね。」
次回
「資格もQRで見られたら早いじゃん」で、“全部見せる”より“必要な答えだけ返す”方が難しかった
資格・個人QR・権限をつないだら、識別より情報開示の方が本題になった
連載公開分（クリックで開く）
- # 【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全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でも正しいとは限らない――機能間の不具合・境界値・回帰・期待結果そのものまで疑う横断テストへ(近日公開予定)
- #16｜「人間＋AI＋Codex、ここまで来たら完成でしょ？」――最後まで残ったのは“伝書鳩駆動開発”だった ※ 「こうしたい」の一言から、AIが複数JSONの整合性リスクを発見――CodexとCrash Recovery・回帰テスト・Git安全境界まで組み上げる開発へ(近日公開予定)
- ♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった ※ これからは趣味としての開発へ――単体テストはPASS、次は“全部つないで壊れないか”第2回横断テストへ(近日公開予定)