二つの自動化を統合しようとして、営業と従業員管理を再び分けた

✨ GPT-5.6 Solの要約

すでに稼働していた営業・SMS業務を維持しながら、インバウンド対応と従業員管理まで拡張できる運用自動化の構造を考えた記録。

すでに動いている二つのプログラムがあった

社内には、すでにそれぞれ異なる方向へ発展した二つの自動化プログラムがあった。

一つは、前任者が先に実装していたSMSベースの年次有給休暇管理プログラムだった。従業員ごとの有給休暇を計算し、取得促進のSMSを送り、SMSで届いた申請を解釈して承認や却下までつなげるサービスだった。Web、backend、DB、業務用Android端末まで、すでに一つの流れとして動いていた。

もう一つは、私が継続して改善してきた公開データ収集と営業自動化だった。施設と連絡先を集め、Voxのアウトバウンドにつなぎ、実際の営業活動へ引き渡す構造だった。

最初は、二つのプロジェクトを一つのリポジトリに移せば統合できると思っていた。だが、これから追加したい機能を考えると、単にフォルダをまとめるだけでは足りなかった。

• 既存のアウトバウンドとつながるインバウンド対応
• 従業員の依頼を受け、管理業務へ引き渡す流れ
• 在職証明書を自動で作成し、届ける機能
• 従業員・契約・現場情報を基準に権限を分ける機能
• 失敗、承認、再処理、監査記録を一か所で確認する運用画面

そこから、問いは「二つのコードをどう統合するか」から「これから増えていく業務をどこに置くべきか」へ変わった。

既存のプログラムを捨てないことにした

SMSベースの有給休暇管理プログラムを見て、作り直したい気持ちは強かった。古い構造や暫定的な設定も見え、今の基準で設計し直したい部分も多かった。要件だけを取り出して新しいコードへ移せば、もっときれいになりそうだった。

だが、資料を一つずつ見ていくほど、そのプログラムにはコードより重要なものが入っていることが分かった。

• 実際に従業員へ提示していた有給休暇の計算結果
• 入社日を基準に有給休暇を計算する方法
• 取得促進の対象者と送信時期
• SMSでの申請を日付と半休として解釈するルール
• 申請、承認、却下、結果通知の順序
• 業務用Android端末がSMSを送受信する方法
• 運用担当者がすでに使っていた画面と例外処理

これらを数枚の文書にまとめて最初から作り直せば、新しいコードはきれいでも、既存の利用者が受け取る結果は変わってしまうかもしれない。前任者が実際に完成させた縦の流れを、私の設計上の好みだけで消すわけにはいかなかった。

そこで、まず既存のサービスをそのまま再現し、画面と計算結果を回帰基準として残してから、問題のある部分を機能ごとに置き換える方向へ変えた。新しいシステムは既存のプログラムを消して始めるのではなく、既存の仕事を失わないまま、より大きな構造の中へ入らなければならなかった。

営業と従業員管理は同じアプリではなかった

プロジェクトを一つにまとめるからといって、DBとRuntimeまで一つにすれば、別の問題が生まれる。

営業自動化は公開データ、連絡先、通話対象、営業結果を扱う。従業員管理は従業員情報、文書発行、有給休暇、承認、メッセージを扱う。二つの領域は運用画面で一緒に見せることはできても、データの性質も権限も、障害が及ぼす範囲も異なっていた。

営業DBのmigrationが従業員管理のデプロイを止めたり、有給休暇サービスの障害によって営業用のデータ収集まで止まったりする構造にはしたくなかった。アカウントとcredential、queue、backup、rollbackも業務ごとに分ける必要があった。

最終的に、リポジトリは一つに保ちながら、営業と従業員管理を独立したアプリに分けることにした。運用画面では二つのアプリを一か所からたどれるが、DBを直接読むことはなく、各backendが自分のデータと権限に責任を持つ。

外からは一つの統合運用画面に見えても、中まで一つの巨大なサービスにする必要はなかった。

アウトバウンドからインバウンドと管理業務へ

既存の営業自動化は、外へ電話をかけるアウトバウンドの流れに近かった。15日には、ここへインバウンドをどうつなぐかについても長く考えた。

電話がかかってきたという理由だけで、すべての依頼を通話システムの中で処理する必要はなかった。通話は依頼を受け取り、適切な業務へ引き渡す入口になればいい。在職証明書の依頼なら本人確認と発行業務へ回し、発行された文書は別の受け渡し手順を通さなければならない。Webやモバイルから同じ依頼が届いた場合も、最終的には同じ管理業務へ合流する必要があった。

在職証明書から始めることにした理由もそこにあった。依頼受付、従業員の基準情報の確認、文書生成、承認、交付、失敗処理、監査まで、運用自動化に必要な流れを一度に確認できる最初の機能だった。

一つの機能をうまく作るだけではなく、その後ほかの従業員管理業務が加わっても、同じ境界を再利用できなければならなかった。

基準情報を作り直してはいけなかった

会社ではすでに別のシステムで従業員、契約、現場への配置を管理していた。自動化にはその情報が必要だが、こちら側に従業員のマスターをもう一つ作れば、すぐに二つのシステムの値が食い違う。

外部システムが引き続き基準情報を所有し、こちら側は必要なデータを読み込み、検証済みのsnapshotとして残す方がよかった。マスターを変更する機能と、その情報を使って管理上の事案を処理する機能は分けなければならなかった。

問題は、実際にダウンロードされるファイルの形式も、安定した従業員識別子も、まだ確認できていなかったことだ。画面に表示された番号を社員番号と呼んだり、ダウンロード機能を確認もせずにExcelと書いたりすれば、その後の設計はすべて誤った前提の上に積み上がる。

だから、分からないことは未決定のまま残した。その日は多くの答えを作った日でもあったが、分からないことを知っているふりをしないために、何度も文を直した日でもあった。

統合はフォルダをまとめることではなかった

15日はコードをほとんど書かず、プロジェクト名、アプリの境界、データの所有権、既存サービスを移行する順序、運用画面の役割を整理し続けた。

前任者が作ったプログラムを尊重しながらも、そのまま凍結するのではなく、私が作った営業自動化も現在の構造に閉じ込めない方法を探したかった。既存のVoxアウトバウンドからインバウンドへ、さらに従業員管理と文書自動化へ広げられる必要があった。

二つのプロジェクトを同じフォルダへ入れるのは簡単だった。難しかったのは、何を残し、何を分け、どこから拡張するかを決めることだった。15日は、異なる二つの自動化を一つの運用構造として見直し始めた日だった。