応募意思の回収・応募依頼
学生 → CA、CA → AgentBox → 事務員の依頼は、現在の業務として継続する。
AgentBox
理想像と開発ロードマップ
まず、応募に紐づくタスク管理と
双方向のやり取りをつくる。
01理想像
応募依頼と選考連絡の全体像
AgentBoxは、事務員への応募依頼と選考連絡の受け渡しを担う。企業への応募登録は、事務員がATS上で行う。
現状と、今回の開発対象
現行運用フェーズ1フェーズ2で検討
事務員によるATS操作
条件確認と企業への応募登録は事務員が担当。ATSの応募・選考管理を利用する。
JimuDeskの抽出・整形・手動入力
企業連絡を取り込み、現状はBacklogへ登録。既存の機能は再利用候補とする。
タスク管理・コメント返信
応募に紐づく依頼・回答・対応状況をAgentBox内で共有できる状態にする。
CA向け画面・事務員統合画面
共通DBのタスクを、自社の許可範囲と事務員の横断範囲に応じて表示する。
JimuDesk連携API・取り込みの実装先
JimuDeskを残してAPI連携するか、AgentBox内で取り込むかを比較して決める。
既存のチャット機能を確認し、タスク管理・統合表示に必要な追加開発と改修を行う。
02フェーズ1
最優先の開発応募に紐づくタスク管理システム
コメントによる双方向のやり取りをタスク管理に含め、依頼から回答・確認までを同じ場所に集約する。
01
応募とタスクの紐づけ
どの応募に関する依頼か、何が未対応かを共有する。
02
CA・事務員のコメント返信
依頼、回答、質問、確認を同じタスクに残す。
03
共通DBへの一元保存
各社用・事務員用にコピーせず、同じタスクを参照する。
04
Agency単位のアクセス制御
各社の情報を分離し、許可された範囲だけ取得・更新できる。
05
事務員の統合一覧
対応対象の全エージェンシーを横断し、依頼・回答を確認する。
各Agencyは自社分、ANCa事務員は全社分を閲覧・更新
ANCaAgencyとしての利用ANCaの情報のみ
SHiROAgencyとしての利用SHiROの情報のみ
CCareerAgencyとしての利用CCareerの情報のみ
↕閲覧・保存／更新
↕閲覧・保存／更新
↕閲覧・保存／更新
↕全社分を閲覧・保存／更新
ANCa事務員3社の応募・タスク・コメントを統合画面で管理
各Agencyと事務員は、AgentBoxを通じて同じデータを参照・更新する。会社別にDBを複製しない。事務員の「全社分」は、対応を許可された全パートナーの範囲を指す。
上段のANCaは自社情報を扱うAgency、下段のANCa事務員はパートナー各社を横断して対応する役割。タスクの所属先は、作成者ではなく対象応募のAgencyとする。
構造案：応募 → タスク → コメント。応募・タスクの単位は詳細設計で確定。
フェーズ1で目指す状態事務員が依頼を作る → CAが回答する → 事務員が確認する。双方が対応状況を共有できる。
事務員の統合画面と情報分離は初期開発に含む。画面・項目・状態・通知の詳細は仕様設計で確定する。
03フェーズ2
検討事項以下は未決定の設計論点。採用・既存流用・後回し・対象外を整理し、フェーズ1に必要な範囲を詳細設計へ引き継ぐ。
A応募・タスクの単位と必要項目
- 応募（企業 × 学生）を軸に、タスクと履歴を蓄積できる構造にするか。同じ企業の複数求人・再応募を区別する必要も確認する。
- 1応募に複数タスクを持たせるか。新しい依頼と、既存タスクへの追加連絡をどう分けるか。
- 必要項目はBacklogを踏襲するか。現行項目を確認し、担当・期限・対応状況・添付・元の連絡内容などの必要性を整理する。
- タスクとコメントをどう使い分けるか。コメント内で新たな依頼や期限変更をどこまで許容し、どこからタスク化するか。
- 選考状況とタスクの対応状況、学生向け案内と事務員の内部メモをどう区別するか。
BAgencyの組織構造・閲覧範囲
- Agency内に部署・チームなどの任意の区分を設けるか。区分を検索・集計だけに使うか、閲覧範囲にも使うか。
- 複数Agencyをまとめて管理するニーズがあるか。Liverty・Selectのようなケースを想定し、実際の関係と必要な横断範囲を確認する。
- 複数Agencyの管理を認める場合、データの所属は各Agencyに保ち、誰に横断閲覧・操作を許可するかを決める。
- ANCa事務員の統合管理と、パートナー側の複数Agency管理を区別して設計する。
Cデータの編集権限・変更履歴
- 担当者変更・学生情報変更を誰がどこまで行えるようにするか。不在時の引き継ぎも含めて整理する。
- 学生情報の変更を既存の応募・タスクへどう反映するか。ATSに登録済みの情報を訂正する際の事務員への連絡も整理する。
- タスク・コメント・添付の編集や削除、訂正・取消の範囲と、残すべき変更履歴を決める。
- 閲覧・編集の制限を、検索・通知・添付の取得にも一貫して適用する。
Dパートナー側マネージャーの管理体験・リマインド
- 通知とダッシュボードで、パートナー側のマネージャーが担当CA・チームの対応状況を確認し、フォローする負担を減らす。未対応・期限超過・誰の対応待ちかを把握できる表示を検討する。
- 新規依頼・返信・期限超過など、担当CAへの通知とマネージャーへの通知をどう分けるか。確認やフォローが必要な情報を集約し、通知による管理負担を抑える。
- マネージャーに許可された範囲で、部署・チーム・担当CA別に検索・絞り込みできるようにするか。複数Agencyを管理する場合の横断表示も検討する。
- 説明会リマインドはタスクと分けた独立機能にするか。通知先・日程変更やキャンセルへの追従・タスク化が必要な例外を検討する。
E企業連絡の取り込み方式
- JimuDeskのメール抽出・整形・確認を残してAgentBoxのAPIへ登録するか、AgentBox内にその機能を実装するか。
- ATS・Slack等の連絡を手動で整形・格納する機能を、どちらのシステムで提供するか。
- 既存のテンプレート・応募照合をどこまで再利用できるか。開発工数・保守・事務員の操作負担を比較する。
F誤登録・重複への備え
- 応募を特定できない連絡や、複数学生を含むメールをどう確認するか。
- 誤ったAgency・応募への登録を防ぎ、訂正・取消できる運用を決める。
- 再試行時の重複防止と、登録結果が不明な場合の確認方法を決める。
GBacklogからの切替・保守
- 既存案件をBacklogで完了させるか、未完了分をAgentBoxへ移すか。
- 一部パートナーで試行し、事務員とCAの双方で運用を確認する。
- 同じ依頼を二重管理しない切替ルールと、JimuDeskを残す／移植する場合の保守・障害対応を整理する。
フェーズ2は、検討を深める段階検討結果はフェーズ1の仕様にも反映する。実装時期は、採用範囲と優先度を踏まえて決定する。
04最終仕様設計へ
必須の大項目と検討結果を合わせ、採用範囲を確定してから詳細を設計する。
- 01フェーズ1・2を精査必須項目と論点を揃える
- 02採用範囲を確定採用・流用・後回し・対象外
- 03最終仕様設計データ単位・組織／権限・画面・業務ルール・受入条件
仕様確定後に工数・納期を見積もり、実装計画を策定する。
会議で確認すること
- 最優先を、コメント機能込みのタスク管理とする。
- 共通DB・Agency分離・事務員統合表示を基礎にする。
- フェーズ2の論点と、確認担当・残作業を整理する。