J-SHIP 公式LINE連携 Phase 1 Flow

MVPの芯

電話で関係構築した後、学生がLINE上で担当者の面談枠を選ぶ。

人が持つ判断

本番はkintone参照。暫定MVPは簡易台帳で担当者割当を持てる。

システムが持つ処理

空き枠提示、予約確定、サービスアカウント経由のカレンダー登録、リマインド。

先に決めること

kintone前提で進めるか、先にkintoneなしで予約基盤を検証するか。

Figure 1. Phase 1 の業務フロー

登録から初回面談まで。電話は残し、電話後の日程確定とリマインドを自動化する前提。

End-to-end

flowchart TB
  A[公式LINE追加] --> B[アンケート回答]
  B --> C[kintoneへ連携]
  C --> D[人が担当者割当]
  D --> E[担当者が翌日電話]
  E --> F[LINEで日程候補を送付]
  F --> G{学生が日時選択}
  G -->|選択済み| H[Googleカレンダー登録]
  H --> I[学生・担当者へ通知]
  I --> J[面談実施]
  G -->|未選択| K[催促リマインド]
  K --> F

確認ポイント: 三好さんの共有文では「電話で面談日程調整」と読めるため、要求書の「電話では日程を決めず、電話後にLINEで選択」と一致しているかを先に確認する。

Figure 2. LINEアカウント構成の分岐

学生が最初にどのLINEを追加し、担当者確定後にどこから通知するかで実装が変わる。

LINE design

flowchart TB
  A[学生の入口] --> B{最初に追加するLINE}
  B -->|共通公式LINE| C[アンケート・初期受付]
  B -->|担当者別公式LINE| D[担当者ごとに直接受付]
  C --> E[担当者割当]
  E --> F{通知元}
  F -->|共通LINEから通知| G[実装は単純・担当者感は弱い]
  F -->|担当者別LINEへ誘導| H[担当者感は強い・再友だち追加が必要]
  D --> I[担当者は明確・入口設計が複雑]
  H --> J[学生が追加しないと通知不可]

設計入力: 共通LINEのみでMVPを作るか、担当者別LINEを前提にするか。担当者別LINEを使う場合、学生をどう接続させるかを運用として決める必要がある。

Figure 3. kintone連携前の暫定MVP

kintone API開通前でも、簡易台帳と担当者マスタだけでLINE日程調整とカレンダー登録を先に検証する。

No kintone MVP

flowchart TB
  A[公式LINE追加] --> B[アンケート回答]
  B --> C[簡易台帳に登録]
  C --> D[人が担当者を入力]
  D --> E[担当者マスタを参照]
  E --> F[対象カレンダーを特定]
  F --> G[LINEで日程候補を送付]
  G --> H{学生が日時選択}
  H -->|選択済み| I[Googleカレンダーへ予定登録]
  I --> J[予約情報を簡易台帳へ反映]
  J --> K[学生・担当者へ通知]
  H -->|未選択| L[催促リマインド]
  L --> G

使いどころ: kintoneの対象アプリ、フィールド、API権限が未確定でも、日程調整UI・サービスアカウント経由のカレンダー登録・リマインドだけ先に動かせる。後で簡易台帳をkintoneへ差し替える。

Figure 4. データ所有と参照関係

kintone、担当者マスタ、Googleカレンダー、LINEのどこに何を持たせるか。

Data ownership

flowchart TB
  A[kintone 学生レコード] -->|担当者値| B[担当者マスタ]
  B -->|Googleアカウント| C[Googleカレンダー]
  B -->|通知元| D[LINE公式アカウント]
  C -->|空き枠取得| E[日程調整ツール]
  E -->|予約確定| C
  E -->|予約状態| A
  D -->|候補提示・催促| F[学生]
  E -->|担当者通知| G[担当者]

設計入力: 担当者マスタに「kintone上の担当者値」「Googleアカウント/カレンダーID」「担当者別LINEの有無」を持たせる。Googleカレンダーはサービスアカウントを発行し、対象カレンダーをそのメールアドレスに共有してもらう前提で進める。

Figure 5. 未選択・割当待ちの失注リスク

成功フローだけでなく、放置されやすい状態を見える化する。

Failure path

flowchart TB
  A[登録済み] --> B{担当者割当}
  B -->|未割当| C[割当待ち]
  C --> D[初動遅れ]
  D --> E[学生温度感低下]
  B -->|割当済み| F[電話実施]
  F --> G{日程選択}
  G -->|未選択| H[催促対象]
  H --> I{期限内に選択}
  I -->|選択| J[面談確定]
  I -->|未選択継続| K[担当者へアラート]

設計入力: 割当期限、未選択の催促タイミング、担当者へアラートする基準。ここを決めると「抜け漏れ防止」のMVP価値が具体化する。

Figure 6. サービスアカウント版カレンダー接続

個人ログイン情報ではなく、発行したサービスアカウントに対象カレンダーを共有してもらう。

Calendar setup

flowchart TB
  A[Google Cloudプロジェクト作成] --> B[Calendar APIを有効化]
  B --> C[サービスアカウント発行]
  C --> D[サービスアカウントのメールを共有]
  D --> E{共有対象}
  E -->|共通受付枠| F[共通カレンダーを共有]
  E -->|担当者別枠| G[各担当者カレンダーを共有]
  F --> H[予定の変更権限を付与]
  G --> H
  H --> I[担当者マスタへCalendar ID登録]
  I --> J[空き枠取得]
  J --> K[予約確定]
  K --> L[Googleカレンダーへ予定登録]

設計入力: 先方にはログインID/パスワードではなく、サービスアカウントのメールアドレスへ対象カレンダーを共有してもらう。予約登録まで行うため、共有権限は「予定の変更」が必要。

Figure 7. 初回面談後の採用進行

Phase 1は初回面談までだが、後続の説明会・面接・承諾まで同じ日程調整/リマインド構造が続く。

Recruiting flow

flowchart TB
  A[初回面談実施] --> B{次アクション}
  B -->|再面談| C[再面談の日程調整]
  C --> A
  B -->|企業紹介| D[企業説明会の日程調整]
  D --> E[説明会参加]
  E --> F[説明会後ヒアリング]
  F --> G{進行判断}
  G -->|面接へ進む| H[面接対策の日程調整]
  H --> I[面接の日程調整・リマインド]
  I --> J[面接後ヒアリング]
  J --> K{次ステップ}
  K -->|2次面接| L[2次面接の日程調整・実施]
  L --> M[2次面接後ヒアリング]
  M --> N{次ステップ}
  N -->|最終面接| O[最終面接の日程調整・実施]
  O --> P{承諾確認}
  P -->|承諾| Q[ゴール]
  G -->|別企業紹介| D
  K -->|不合格・意思変更| D
  N -->|不合格・意思変更| D
  P -->|辞退・保留| D

運用メモ: 後続フェーズでは、各ステップに「日程調整」「前日リマインド」「実施後ヒアリング」「別企業紹介への戻り」が繰り返し出る。Phase 1の予約基盤はこの反復業務へ拡張できる。

設計前にまず欲しい情報

アカウントやログイン情報より先に、作るものを決めるための入力に絞る。

LINE運用: 共通LINEか担当者別LINEか。学生の入口と通知元。
電話後の扱い: 電話で日程を決めるのか、電話後にLINEで選ばせるのか。
担当者マスタ: kintone担当者値、Googleアカウント、カレンダーID、LINEアカウント。
暫定台帳: kintone連携前に使うスプレッドシート/CSV/管理画面のどれで担当者割当を持つか。
面談受付枠: 曜日、時間帯、面談時間、バッファ、何日先まで出すか。
カレンダー共有: 共通受付枠か担当者別枠か。対象カレンダーをサービスアカウントのメールへ共有できるか。
対象範囲: 新規登録者のみか、既存約1,400名も対象か。

後続で必要な権限

設計が固まった後に接続検証で必要。現時点では取得を急がない。

LINE: Messaging API、Webhook設定、Channel secret、アクセストークン。
kintone: 対象アプリ、フィールド定義、APIトークン、テストレコード。
暫定台帳: kintone未接続で始める場合の入力/更新権限。
Google: Calendar API有効化、サービスアカウント発行、対象カレンダーの共有、予定変更権限。

先方確認の優先順位

最優先

電話後の日程調整でよいか電話は関係構築として残し、予約操作はLINEに寄せる設計で合っているか。

高

LINEの入口と通知元共通LINEから送るのか、担当者別LINEへ誘導して送るのか。

高

担当者マスタと面談受付枠空き枠提示のために必要な最小データ。カレンダーID、共有対象、共有権限も表でもらう。

高

kintoneなしで先に検証するかkintone権限が遅れる場合、簡易台帳で予約基盤を先に作ると着手が早い。

中

新規のみか既存も対象か既存学生を含める場合は、LINE再接続や案内運用が別タスクになる。