本日の構成

前回（4月）ご提案した業務基盤刷新の全体像を改めて共有し、現場の皆さまよりいただいたご意見への対応を、実際に動く画面でご覧いただきます。

製造特性が強い、多工程・多品種の事業

「変えたくても変えられない」基幹と分断

3層構成 — Zoho／カスタムアプリ／TKC

┌─ Zoho Suite（CRM Enterprise + Campaigns + SalesIQ）──────┐
│   顧客／商談／見積／受注／拠点別ダッシュボード            │
│   ＋ 製造進捗ウィジェット（CRM 画面内に表示）             │
└──────────────────┬───────────────────────────────────────┘
                   │ REST API（双方向）
┌──────────────────┴───────────────────────────────────────┐
│   秋江製造管理アプリ（カスタム Web アプリ）               │
│   製造指示／工程ボード／バーコード出荷・入庫／内職者／在庫 │
└──────────────────┬───────────────────────────────────────┘
                   │ FX クラウド API（または CSV）
┌──────────────────┴───────────────────────────────────────┐
│   TKC FX（会計・請求）※現行運用を継続活用                │
└──────────────────────────────────────────────────────────┘

紙ではなく、操作できるデモでご覧いただきました

• 商談→製造指示：受注商談からAPIでデータを呼び出し、商品・数量・工程・必要資材を算出して指示書化（ゼロ起票も可）
• 工程ボード：製造指示ごとの進捗をカンバン形式で可視化
• 内職者管理：ロット出し・預けロット・納期超過の状況
• バーコード出荷・入庫：スマホカメラで Code128 をスキャンして処理
• 在庫・資材・ガント／TKC連携：不足アラート・一括発注・スケジュール、出荷後に請求へ

つなぐ・気づく・解消する・渡す・育てる

1つの仕組みの上で、紙・電話・手入力なしでつなぐ

業務に即した5つのご意見

「めくる」をやめ、「絞り込んで出す」へ

1. 集約サマリを先に出す（工程×ステータスの件数）→ 全件をめくらない
2. 権限・担当・ステータスで初期フィルタ（見るのは常に自分の数十件）
3. 完了は自動退避し、動いているものだけ残す
4. 件数 → クリックで絞り込み一覧へドリルダウン

役割に応じて、見える範囲と初期画面を変える

受注横断で所要量を集約して発注

各受注の所要部品を積み上げ（A:ナイフ20 / B:50 / C:30）
        ↓ 共通部品で横断集計
[ナイフ 計100個 必要 / 在庫30 / 不足70]
        ↓ 発注点・安全在庫を加味
仕入先軸でまとめ発注（受注をまたいで1本の発注）

率直に — 相応の工数。だからPhase 1で数値化

• 新システムは標準的なテーブル構成で組み直し、現行の歪んだ持ち方を引き継がない
• Phase 1 でデータプロファイリング → 整備難易度を「感覚」から「数値」へ
• 整備の分担を明確化：当社（変換・移行プログラム）／秋江様（業務判断が要るクレンジング）
• 費用変動の前提を明言：Phase 1 完了時に確定見積をお出しします
• 当社は数万〜数十万件規模の移行実績。1万件規模は十分対応可能

最小構成から。主価値は「製造進捗の可視化」

• CRMは最小構成から。高度な商談管理は最初から作り込まない
• 主価値を「製造進捗のリアルタイム可視化」に絞る（前回も高評価の点）
• マーケ機能（配信・スコアリング）は必要になった時に足せる状態に
• 構成の自由度：CRMはZoho以外も技術的に接続可能（kintone/Salesforce等）。Zoho推奨だが固定ではない

「誰に出しすぎて、どれだけ帰ってこないか」が赤で分かる

[内職者A] 預けロット: 12 / 最長21日 ← 超過（赤）
[内職者B] 預けロット:  5 / 最長 6日 ← 通常
[内職者C] 預けロット: 18 / 最長25日 ← 超過（赤・出しすぎ＆滞留）
        ↓ クリック
[内職者C に出している全ロットと各納期・滞留日数の一覧]

自然な質問に、根拠データ付きで答える

読み取り専用・根拠付き・外部送信ゼロ

[質問（チャットUI）]
   ↓
[オーケストレーター]
 意図解釈・ツール選択
 (本番:LLM function-calling/MCP)
   ↓ 読み取り専用
[業務DB照会ツール群]
 製造/工程・内職/出荷
 資材/購買・受注/顧客・在庫
   ↓ 構造化結果
[自然文＋根拠データ表]

「ご意見 → すぐ動く改修」を要件定義中も回す

業務把握は「人が聞く」、要件まとめは「AIが助ける」

【集中フェーズ（合宿型）】          【構築と並行（定例）】
現地確認・課題抽出（人が聞く）  →   週次定例＋動く画面で確認・反映
        ↓                                  ↓
  AIが要件・仕様に整理 ──────────────→ 継続して整理・蓄積

• 立ち上がりは集中的に：現地確認・業務観察・課題抽出は当社担当者が直接ヒアリング（合宿型）。ここは人が現場に入る工程
• その後は構築と並行して定例へ：業務フローが見えたら、構築しながら週次定例＋動く画面で確認・反映
• AIの役割は要件のまとめ上げ：人が聞いた内容をAIが議事録・要件・仕様書に構造化しリポジトリへ蓄積

仕組みで品質を担保し、本番データは守る

AIが全フェーズを通貫、転記ゼロ

100名規模・販売／製造／経理の構築を要件定義〜実装まで

代表は MAツール「リストファインダー」で7年・1,000社以上の導入を主導／Salesforce→Zoho移行でライセンス1/3〜1/4削減多数／数万〜数十万件規模の移行実績。

従来型SIer比 1/3〜1/2

段階的アプローチ（目標：2028年春頃 本番稼働）

現地での集中検討（合宿型・1〜2週間）

• 週次ミーティングだと議論が途切れて遅くなるため、現地で午前は集中ヒアリング、午後は当社が反映
• 現場・現行システム（電脳工場の画面/マニュアル）を直接拝見
• 製造部長・各工程管理者のご協力時間をいただきたく存じます

主なリスクと対策

方向性のご承認から、要件定義へ