本ページは、業務概要からのモデル駆動開発の概要と、生成したアプリケーションの操作マニュアルを、利用者の役割ごとにまとめたものです。画面名・ボタン名は実装に合わせており、画面ショットはデモデータで撮影しています。

• 対象アプリ: 営業管理システム（商談の進捗管理）
• 構成: フロントエンド（React + TypeScript + Vite + Tailwind CSS）＋ バックエンド（TypeScript + Express の REST API）
• 設計トレース: 業務概要 → 業務シナリオ（SSoT）→ アクティビティ図 / ユースケース / クラス図 / 状態遷移図 / シーケンス図 → 実装（UC-001〜UC-030、BR-001〜BR-017 は設計書と共通）

01業務概要からの生成

入力は、営業管理システムの一般的な概要文書です。主な利用者と役割、顧客管理・リード管理・商談管理・営業活動・見積と受注・パイプラインと売上予測・レポート・共通基盤の8領域の機能、商談の進捗管理の業務の流れ、導入の効果と運用上の留意点が書かれています。

概要文書の「運用上の留意点」も、業務ルールとしてモデルに取り込んでいます。たとえば「入力負荷の軽減」は外部ツールからの取り込みと活動から作る日報の下書き（BR-016）に、「フェーズ定義の明確化」はフェーズごとの完了条件（BR-005）になっています。

エンティティの型・状態遷移表・権限表・エンドポイント×ロール表・業務メソッドの一覧は、生成器がモデルから機械生成します。業務メソッドはすべて共通の実行枠を通り、状態を変えたのに監査ログに記録しなかった操作は失敗させて巻き戻します。

02はじめに

利用者は5つの役割に分かれ、役割によって使えるメニューと見えるデータの範囲が変わります（BR-014）。

03起動とログイン

# ① バックエンド（REST API / ポート 4000）
cd app/backend && npm install && npm run dev
# ② フロントエンド（画面 / ポート 5173）
cd app/frontend && npm install && npm run dev
# または Docker（http://localhost:8090）
cd app && docker compose up --build

ブラウザで http://localhost:5173/ を開きます。デモ利用者（営業担当者3名・営業マネージャー2名・営業事務2名・経営層・システム管理者）のパスワードはすべて Sales-Demo-2026! です。5回続けてパスワードを誤ると、30分間ロックされます。

サイドバーには、ログインした役割で使えるメニューだけが表示されます。多くの画面は左に一覧、右に詳細・入力欄の構成で、一覧の行を押すと右側に詳細と操作ボタンが表示されます。

04ホーム・通知

ホームには、自分の閲覧範囲の進行中の商談を次回アクションの期日が近い順に表示し、停滞している商談には「受注予定日超過」などの印を付けます。通知には、承認依頼・承認結果・停滞アラート・日報のフィードバック・受注連携エラー・更新案件・引き継ぎなどが届きます。

05リードと取引先（UC-001〜006）

5.1 リード

• 登録 — 会社名・氏名・流入経路（展示会・Web 問い合わせ・セミナー・紹介・名刺交換）を入力します。同じ会社名・氏名のリードがあると既存のリードが示されます（BR-012）。「名刺管理」「MA」から候補を取り込むこともできます（BR-016）。
• 評価・商談化・不適格 — 評価スコア（0〜100）の高い順に並びます。「商談化する」を押すと取引先・担当者を名寄せし、「初回接触・アプローチ」の商談を作ります。このとき次回アクションと期日の入力が必須です（BR-001）。

5.2 取引先

社名・所在地で重複をチェックして登録します。取引先を開くと、取引履歴（商談・受注・活動・契約の時系列）、担当者（決裁への関与度＝決裁者／影響者／窓口）、取引先情報（取引区分・親会社と子会社の関係）のタブがあります。閲覧範囲外の商談・活動は表示されません。

06パイプラインと商談（UC-008）

閲覧範囲内の進行中の商談を、フェーズごとの列（カンバン）で表示します。列の見出しには件数と見込み金額の合計が出ます。カードを別のフェーズの列へドラッグすると「進捗を更新」画面が開き、移行できる列は緑の枠で示されます。

商談詳細には、フェーズ・見込み金額・受注確度・加重予測額（見込み金額×確度 / BR-011）・次回アクションと、活動履歴・フェーズ履歴（BR-004）が並びます。

1. 「移行先フェーズ」を選びます。前進だけでなく、提案→ヒアリングなどの後退もできます。
2. フェーズの完了条件（例：BANT の必要性を確認済み）を満たしていないと警告されます。条件を満たすか、移行理由を入力すれば移行できます（BR-005）。
3. 受注確度は空欄ならフェーズの標準確度を使います（BR-003）。次回アクションと期日は必須です（BR-001）。

07見積と受注・失注（UC-009〜013, 016）

1. 作成 — 商品・数量・単価（空欄なら標準価格）と値引き率・特別条件を入れて作成します。
2. 承認申請 — 値引きが商品の値引き上限を超える、または特別条件があると「上長承認が必要」と表示され、値引き理由を入れて申請します（BR-007）。承認前は PDF 出力も提示もできません。
3. 提示 — 見積書 PDF を出力し、「顧客に提示」で提示済みにします。商談が「提案」のときは「見積提示」フェーズへ進みます。
4. 改訂 — 版を上げて改訂し、前の版は履歴として残ります（BR-008）。差し戻された版は再申請できず、修正して版を上げます。

• 受注登録 — 提示済みの見積を選んで登録します。受注は進行中のどのフェーズからでも登録でき、使った見積は「採用」、ほかの未完了の見積は「不採用」になります。受注は「連携待ち」として営業事務へ通知されます。
• 失注記録 — 失注理由（価格・機能・競合・時期・予算凍結）を必ず選びます（BR-006）。

08営業活動・日報・契約更新（UC-007, 017, 023）

• 営業活動 — 訪問・電話・メール・Web 会議・デモを、取引先・商談・面談した担当者に紐づけて記録します。カレンダーやメールから当日の予定を候補として取り込めます（BR-016）。記録すると商談の最終更新日時が更新され、停滞の判定から外れます。
• 日報 — 対象日を選ぶと、その日の活動記録をまとめた下書きが作られます。所感・課題を追記して提出すると上長へ通知されます。
• 契約更新 — 更新時期の30日前（設定で変更可）に、スケジューラが更新商談を自動で作り、担当営業へ通知します（BR-010）。

09営業マネージャーの操作（UC-011, 018〜022, 029）

9.1 値引き承認

部下から申請された承認待ちの見積を開き、上限を超えた明細と申請理由を確認して承認・差し戻しします。承認・差し戻しができるのは、見積作成者の上長だけです（職務分掌）。

9.2 停滞案件

一定期間（既定90日）更新がない、受注予定日を過ぎた、次回アクションが未設定の商談を、毎日のスケジューラが自動で検知します（BR-002）。指導内容を記録し、次回アクションと期日を指示すると停滞の判定が解除されます。

9.3 営業会議（予実）とファネル分析

営業会議の資料は自動で作られます。目標・受注実績・加重予測・着地見込み・差異、フェーズ別と予測区分別（確実／見込み／可能性あり）の金額、次回アクション未設定の印つきの案件一覧を表示します。

ファネル分析では、受注率・平均商談期間・平均受注単価と、フェーズ別の到達件数・移行率・平均滞留日数・失注件数を表示し、移行率が最も低いフェーズをボトルネック候補として示します。

9.4 商談の引き継ぎと日報へのフィードバック

自チームの担当者の間で、商談を活動履歴・見積・フェーズ履歴ごと付け替え、新旧の担当者へ通知します（BR-013）。部下の日報にはコメントでフィードバックし、追記のたびに担当者へ通知されます。

10営業事務の操作（UC-014, 015, 024, 030）

• 受注の補完と基幹システムへの連携 — 連携待ちの受注の不足情報を補完し、販売管理・会計の受注登録 API へ送ります（BR-009）。失敗すると「連携エラー」として記録・通知され、再連携しても同じ受注は二重に計上されません（冪等キー）。
• 受注の訂正・取消 — 連携後の金額・受注日の訂正や取消を、理由とともに記録します（BR-017）。取り消した受注は売上実績から除かれ、商談は失注（受注取消）に戻ります。
• 契約の登録・商品と価格マスタ — サブスクリプション・保守契約を登録し、商品の標準価格と値引き上限を管理します。

11経営層の操作（UC-027, 028）

売上予測ダッシュボードでは、期間・部門・商品を選ぶと、全社の受注金額・目標達成率・パイプライン金額・売上予測（実績＋加重予測）・活動量を表示し、部門別の行から個別の商談・受注までドリルダウンできます。定型レポート（担当者別・商品別・顧客別・地域別の売上、受注率、失注理由）は CSV・Excel に出力でき、出力は監査ログに記録されます。

12システム管理者の操作（UC-025, 026）

• 利用者と閲覧範囲 — 役割・閲覧範囲（自分の商談のみ／チーム／全社。役割ごとの上限まで）・上長を設定します。上長を変えるときは、承認待ちの見積・提出済みの日報の宛先への影響を確認できます。役割・範囲を変えると、その利用者のセッションは無効になります。
• 商談フェーズ・システム設定 — フェーズごとの表示名・標準確度・完了条件・必須入力項目を設定し、停滞判定期間と更新案件作成リードタイムを変更します。
• 監査ログ — すべての登録・変更・削除の履歴を追記専用で記録し、ハッシュ連鎖で改ざんを検知します（BR-015）。個人情報はマスクして表示します。

13業務ルールと状態遷移

13.1 商談フェーズ

                              （後退：提案→ヒアリング、交渉→見積提示）
 初回接触・      ヒアリング      提案        見積提示       交渉・        内示・
 アプローチ ───▶          ───▶      ───▶          ───▶  条件調整 ───▶ 最終決裁待ち
     │              │          │            │            │              │
     └──────────────┴──────────┴────────────┴────────────┴──────────────┘
          どのフェーズからでも ──▶ 受注   ／   ──▶ 失注（失注理由が必須）

 受注 ──（受注の取消：UC-030）──▶ 失注（失注理由：受注取消）

13.2 見積と受注（基幹システム連携）

 見積:  作成中 ──申請──▶ 承認待ち ──承認──▶ 承認済み ──提示──▶ 提示済み ──受注に使用──▶ 採用
          │                 └──差し戻し──▶ 差し戻し済み（修正は版を上げて新しい見積で）
          └──提示（値引きが上限内）──────────────────────────▶ 提示済み

 受注:  連携待ち ──連携成功──▶ 連携済み（訂正できる）
           └──連携失敗──▶ 連携エラー ──再連携成功──▶ 連携済み
        （連携待ち・連携エラー・連携済みから「取消」で取消済み）

13.3 主な業務ルール

14品質とトレーサビリティ

14.1 テスト

すべて合格しています。テスト名にユースケース・拡張・業務ルールの ID を含め、30ユースケースの主成功シナリオと48の拡張（代替フロー）すべてをテストで確認しています。

14.2 トレーサビリティ行列

概要文書の行から、SSoT・モデル・コード・テストまでをつないでいます。

15制約事項

• データはメモリに保持しています。バックエンドを再起動すると、デモデータの状態に戻ります。本番では RDB と追記専用の監査テーブルに置き換える想定です。
• ログインはローカル認証です（設計上は社内 IdP（OIDC）と多要素認証）。MFA_ENFORCED=true で、多要素認証と、承認・連携・受注の訂正取消の前の再認証が有効になります。
• 基幹システム（販売管理・会計）は模擬 API です。受注の訂正・取消は基幹システムへ送信しません。
• 名刺管理・MA・メール・カレンダーは模擬データです。通知のメール・チャット配信も模擬で、アプリ内の「通知」画面に記録されます。
• 画面はブラウザ（PC）向けで、スマートフォンではレスポンシブ表示のみです。