営業チーム向けウェブアプリを作る：リード、商談、パイプライン

目的と対象ユーザーを定義する

画面を一つ作る前に、あなたの営業ウェブアプリが何を解決するためのものかを定義してください。営業チームが失敗するのは機能不足ではなく、誰が何を担当し次に何が起きるのか、数字を信頼できるかが不明確なことが多いです。

アプリはどんな問題を解くべきか？

日常的な痛みと結びついた短いゴール文から始めましょう：

• 可視性： スプレッドシートやSlackを追いかけずに「今パイプラインに何があるか」を誰でも答えられるか？
• フォローアップ： タスクが作られずリードや商談が停滞するのではなく、着実に前に進むか？
• 予測の信頼性： マネージャーは予測を信頼できるか、それとも古い更新と曖昧なステージに基づいているか？

上位2〜3の問題があげられないなら、誰も使わないCRMクローンを作るリスクがあります。

誰が使うか（各役割の必要事項）

主要ユーザーと、1分以内に達成すべきことを書き出してください：

• 営業担当： リードを素早く取り込み、判定し、活動を記録し、商談のステージ／次のアクションを更新してフォローアップを逃さない。
• マネージャー： パイプラインの健全性を確認し、停滞した商談を発見し、文脈を添えてコーチングし、手作業の修正なしで予測を行う。
• 管理者： 役割ベースのアクセス、必須フィールド、パイプライン段階、データ品質ルールを管理する。
• セールスオペレーション： リード管理の一貫性を保ち、ルーティング／割り当て、レポート定義、CRM連携を扱う。

多くの意思決定は“主要ユーザー”を選ぶことで簡単になります。採用がすべてを左右するため、主要ユーザーは営業担当であることが多いです。

測定可能な成功指標を定義する

「出した」だけでなく実際の行動を反映する指標を選んでください：

• 採用率： 週間で商談を更新するアクティブな営業担当の割合；システムに記録されたリードの割合。
• フォローアップの減少： 期限超過タスクやX日後に放置されたリードの減少。
• 更新の高速化： ミーティング／通話から商談ステージ更新までの時間；週末の一括編集の減少。

各指標を、タスク・リマインダー・ステージルール・ダッシュボードなど、出す予定の機能に紐づけて何が効いているか確認できるようにします。

初期に避けるべきこと

採用やワークフローの妨げになる一般的なミス：

• フィールドが多すぎる： 必須フィールドが増えるほど離脱が増える。最小限で始め、レポートに本当に必要なときだけ追加する。
• 曖昧なパイプライン段階： 同じステージを二人の営業が違う意味で使っていると、レポートと予測がノイズになる。
• ツールの重複： 営業がアプリと別のトラッカーの両方を更新する必要があるとアプリは使われなくなる。何を真のソースにするか決め、他は連携する。

タイトなゴール、明確なユーザー、測定可能な成果があれば、その後のすべての決定（データモデル、パイプライン段階、ダッシュボード）に確かな基盤ができます。

MVPの範囲：必須とあると良いもの

MVPは、ワークフローがエンドツーエンドで機能するかを証明する最小のアプリです。営業担当が新しいリードをクローズに持っていくのに回避策が必要ならMVPは小さすぎます。メール同期やAI提案、フルレポートを導入前に作るのも大きすぎます。

コアユースケースから始める

日常的に使うアクションをサポートするのが目標です：

• リードを追加（手動入力＋基本バリデーション）
• リードを判定（ステータス＋メモ＋ソース）
• 判定済みリードから商談を作成（金額、想定クローズ日）
• 商談をステージ間で移動（簡単な履歴付き）
• 商談をWon/Lostでクローズ（理由必須）

明確なMVPラインを引く

実用的なMVPには通常、リード／商談レコード、パイプライン段階、基本検索／フィルタ、活動ノートが含まれます。

検証前に後回しにできる機能例：

• メール／カレンダー同期
• AIスコアリングや次ステップ提案
• 高度な自動化とシーケンス
• カスタムレポートビルダーや複雑な予測
• 多通貨、テリトリー管理、コミッション

ユーザーストーリーを平易な言葉で書く

短くテスト可能にします：

• “営業担当として、自分にリードを割り当てられるのでフォローアップが明確になる。”
• “マネージャーとして、ステージ別に商談を見られるのでボトルネックを把握できる。”
• “管理者として、スプレッドシートからリードをインポートできるので早く立ち上げられる。”

データソースを早めに合意する

立ち上げ時に何がシステムに流れるかを決めます：ウェブフォーム、CSVインポート、必要なCRM連携など。MVPは少なくとも一つの信頼できる入力経路を持ち、新しいリードがテスト時だけでなく常に入るようにします。

データモデルを設計する（リード、商談、連絡先、活動）

画面を作る前に、アプリが何を保存しどう関連づけるかを決めます。きれいなデータモデルはリード管理と商談パイプラインの一貫性を保ち、成長に伴う混乱を防ぎ、営業レポートを簡単にします。

必要な主要オブジェクト

ほとんどのMVPは次の5つで始められます：

• リード： まだ判定されていない個人や会社
• 企業／アカウント： 販売対象の組織
• 連絡先： 個人（通常は企業に紐づく）
• 商談／オポチュニティ： パイプライン上の収益対象の活動
• 活動： 通話、メール、ミーティング、メモなどの記録でリード／連絡先／商談に紐づく

活動はセールスワークフローを追跡可能にする接着剤です。

CRMの基本を保つ関係性

単純で現実的な関係を使います：

• 1つの企業 → 複数の連絡先（Acmeには複数の関係者がいる）
• 1つの企業 → 複数の商談（更新やアップセルは別商談にすることがある）
• 1つの商談 → 複数の活動（通話やミーティングを一箇所にまとめる）
• リードの変換： リードは連絡先（通常は企業も）に変換され、商談を作ることがある

実用的なルール：連絡先は商談なしで存在できるが、商談はほとんど常に企業と主な連絡先に紐づくべきです。

最低限のフィールド（初めは短く）

本当に使うものだけに絞ります：

• リード： 名前、メール／電話、会社名（自由記述）、ソース、ステータス、所有者、作成日
• 企業： 名前、ドメイン（任意）、業界（任意）、所有者
• 連絡先： 名／姓、メール、電話、会社（リンク）
• 商談： 名前、会社（リンク）、金額、想定クローズ日、ステージ、所有者
• 活動： 種類、日時、メモ、関連レコード（リード／連絡先／商談）

一度採用されたフィールドを削除するのは難しいので、追加は慎重に。

重複とマージルール

重複は避けられません—早めにルールを決めます：

• メールで一致（連絡先／リード）と会社ドメイン／名前で会社を一致
• インポート時は作成をブロックせず「可能性のある重複」を表示
• マージ優先ルールを定義（例：最新の活動＋空でないフィールドを優先）し、必ず監査ログを残す

この基盤があれば、ダッシュボードや連携を組む前にデータの混乱を防げます。

パイプライン段階と営業プロセスルールをマッピングする

パイプラインは商談が何を意味し次に何をすべきかの共通の基準です。ステージが曖昧だと予測とコーチングは推測になってしまいます。

エントリー／退出基準が明確な標準ステージを定義する

チームの実際の販売方法に合う少数のステージから始めます。一般的な例：New、Qualified、Demo/Discovery、Proposal、Negotiation、Closed Won、Closed Lost。

各ステージに対して2つの短い定義を書きます：

• エントリー基準： そのステージに入るために満たすべき条件（例：「意思決定者が特定されている」）
• 退出基準： 次に進むための証拠（例：「デモが完了し次回の打ち合わせが予約された」）

基準は観察可能なものにし、勘に頼らないようにします。これによりパイプラインレビューが速く一貫します。

データ品質を保つステージルールを追加する

営業アプリは営業が完結かつ使えるレコードを作る方向に誘導すべきです。ステージを進める際に軽いバリデーションを加えます：

• 前進前の必須フィールド（例：金額、クローズ日、次のステップ）
• 商談が停滞しないよう次のステップ日を必須にする
• 後戻り時のガードレール（許可するがメモを必須にする）

こうしたルールで不完全な「グリーン」パイプラインを防げます。

複数パイプラインのサポート（任意）

チーム、製品、地域でプロセスが異なるなら別パイプラインを検討します。目的は複雑化ではなく正確性です。定義が本当に異なる場合のみ分け、それ以外は「製品ライン」等のフィールドで対応してください。

クローズ理由（Won/Lost）を取得する

商談がクローズしたら理由（任意で競合）を必須にします。時間が経つとこれがレポート、コーチング、より現実的な予測を生み出します。

ユーザー体験とコア画面を設計する

営業アプリは、人々が「新しいリード」から「次のアクション」へどれだけ速く移れるかで生死が決まります。日々の習慣に基づいて設計してください：今日のタスク確認、パイプラインのスキャン、レコードの更新、次へ進む。

ナビゲーションの必須要素

メインナビはシンプルかつ一貫させます：

• Leads： 取り込み、判定、変換
• Deals： アクティブな商談と次のステップ
• Pipeline： ビジュアルなステージ移動と合計
• Tasks： 個人とチームのフォローアップ
• Reports： パフォーマンスと予測
• Settings： ユーザー、役割、フィールド、連携

項目が増える場合はトップレベルメニューを広げるのではなく「More」の中に隠します。

最初に設計すべきコア画面

人々が毎時間触る画面から始めます：

• 一覧ビュー（Leads、Deals、Contacts）：並べ替え可能な列、明確なステータスバッジ、目立つ「追加」ボタン
• 詳細ページ： サマリーヘッダー（所有者、ステージ／ステータス、金額）とメモ／活動／メール／ファイルのセクション
• パイプラインボード： カードをドラッグ＆ドロップで移動、クイックプレビューと各列の合計表示
• クイック追加： 軽量なモーダルやヘッダーボタンで現在の画面を離れずにリード／商談／タスクを作成

手間を減らす速度機能

営業チームはレコードを素早く見つけ更新する必要があります：

• 高速検索（オートコンプリート：名前、会社、メール）
• フィルタ＋保存ビュー（例：「自分のホットリード」「今月クローズ予定の商談」）
• 一括アクション（割り当て、ステージ／ステータス変更、エクスポート）
• リストやカードでのインライン編集（所有者、ステージ、次のステップ、クローズ日）

キーボード向け操作（例：Nで新規、/で検索フォーカス）も追加し、パワーユーザーの効率を高めます。

認証、役割、データアクセスの設定

認証とアクセス制御は、アプリが信頼できるかリスクがあるかを決めます。最初はシンプルにしつつルールを明確にして「みんなが何でも見られる」状況を避けてください。

小さな役割セットから始める

多くのチームは3つの役割で十分です：

• 営業担当： 自分のリードと商談を扱う
• マネージャー： チームの業務を見てパフォーマンスをレビューし商談を支援する
• 管理者： 設定、ユーザーの管理、データガバナンスを行う

初期に役割を増やしすぎないこと。余分な役割は不明確なプロセスを隠すだけです。

オブジェクトとフィールドごとの権限

権限は二層で定義します：

1. オブジェクトレベル権限（Leads、Deals、Contacts、Activities）：閲覧／編集／削除／エクスポート
2. フィールドレベル権限（例：金額、マージン、割引、顧客電話）：誰が特定フィールドを見たり編集できるか

これにより重要情報をノートやスプレッドシートに隠すような回避策を防げます。

実際の営業に合った可視性ルール

レコードを以下に分けます：

• プライベート（所有者と管理者のみ）
• チーム共有（所有者＋マネージャー＋チーム）
• 全社共有（通常はマネージャー／管理者に限定）

一般的なアプローチ：リードはチーム共有、商談はデフォルトでプライベートにして「チームと共有」オプションを用意する。

重要な変更の監査履歴

数字に対する信頼は必須です。ステージ変更、金額編集、所有者再割当など重要な更新は誰がいつ何を変えたかの監査履歴を残し、パイプラインチェック時に簡単に確認できるようにします。

リードの取り込み、割り当て、判定を構築する

リード管理はアプリが時間を節約するか手間を増やすかを決めます。目標はシンプル：新しいリードを素早くシステムに入れ、適切な人にルーティングし、次に何をすべきかを明確にすることです。

リード取り込み：摩擦を最小にデータを得る

最初は信頼できるいくつかのソースをサポートします：

• ウェブフォーム： フォームは短く（名前、メール／電話、会社、ソース）。マーケティング起点のパラメータは隠しフィールドで持たせる。
• 手動入力： 営業が1分未満でリードを追加できるように。共通フィールドのオートコンプリー トやデフォルトの保持。
• CSVインポート： 寛容に扱う。プレビュー表示、カラムマッピング、重複警告を出す。

実務ルール：すべてのリードに少なくとも所有者、ソース、ステータスを付けないと埋もれます。

割り当てルール：次のアクションの所有者を決める

複雑なルーティングは不要ですが一貫性は必要です。一般的なパターン：

• ラウンドロビン（公平性と速度）
• テリトリー割り当て（国／地域、業界、会社規模）
• 手動キュー（未割当の受信箱に入り、マネージャーが割り当てる）

所有権が変わるときは誰が何の理由で変えたかをログに残してください。フォローアップ漏れの混乱を防げます。

判定ワークフロー：ステータスを実用的にする

営業が実際にやることに沿った少数のステータスを使います：

• New： 取り込み済み、未接触
• Contacted： 最初の接触を試みた／完了
• Qualified： 費用対効果／ニーズ／タイミング等で条件を満たす
• Disqualified： 適合しない、連絡不可、重複

不適合にする際は短い理由を必須にしてください。レポートに役立ちます。

変換：リードを実際の商談データに変える

ワンクリックの変換フローを定義します：

• リード → 連絡先 + 会社（アカウント）（存在しなければ作成）
• 必要に応じて商談を即作成（初期ステージと金額付き）または営業が選べるようにする

変換時に重複チェック（同じメール、ドメイン、会社名）を実行し、顧客履歴が分断されないようにします。

商談管理とパイプライン移動を作る

商談管理はアプリが単なるデータベースから日常作業ツールに変わる部分です。目標は、商談作成を簡単にし、動かし続け、"次に何をするか"を見逃させないことです。

商談作成：ゼロから、または判定済みリードから

2つの入り口をサポートします：

• ゼロから商談を作成（インバウンド紹介やパートナー案件）
• 判定済みリードからワンクリックで商談を作成（連絡先／会社、ソース、主要メモを継承）

変換時にレコードを重複作成しないよう、商談は既存の連絡先／企業を参照すべきです。

パイプライン移動：ボードとドロップダウン

人によって好みが違うので両方を用意します：

• ドラッグ＆ドロップのパイプラインボード（カンバン）で迅速に更新
• 商談ページのステージドロップダウン（アクセス性、モバイル向け）

商談がステージを変えたら自動でログを取ります（誰が、いつ、どこから→どこへ）。これはコーチングと予測に必須です。

商談の停滞を防ぐための次のステップ必須化

商談作成や前進時に必須にする2つのフィールド：

• 次のステップ（短いテキスト、例：「価格送付」「技術デモを予約」）
• フォローアップ日（次のステップの期限）

これがないと移動できないようにし、ステージごとの一般的な次ステップを提案して親切に促します。

商談に紐づく活動タイムライン

各商談には時系列のタイムラインが必要です：

• 通話、メール、ミーティング
• メモやファイルリンク
• ステージ変更や主要フィールドの編集

これにより引き継ぎがスムーズになり「この案件の文脈は？」というやりとりを減らせます。どこからでも活動を追加して該当商談に紐づけられるようにするとさらに便利です。

タスク、リマインダー、シンプルな自動化を追加する

タスクはパイプラインと実際の作業をつなぐ接着剤です。これがないと商談はアプリ上で動いているだけで実働は遅れるか停滞します。シンプルで素早く使えてリードや商談に直接紐づく設計にします。

タスク種類、期限、日次アジェンダ

最初は実際の作業に合う少数のタスク種類に絞ります：Call、Email、Meeting、Demo、Follow-up。各タスクは期限日時、所有者、リードまたは商談へのリンク（関連連絡先含む）を持ちます。

Daily Agendaビューを追加し「今日やるべきこと」を一目で示します：

• 今日のタスク（期限順）
• 期限超過タスク（上部に固定）
• 今後7日分のタスク（計画のため）

無視されないリマインダー

リマインダーは予測可能で調整可能にします。いくつかのデフォルト（15分前、1時間前、期限時）を用意し、ユーザーがタスクごとにオプトアウトできるようにします。会議後に追いつけるよう通知の「受信箱」スタイルも用意します。

シンプルな自動化：ステージからタスクを作成

影響が大きい1ルール：商談がステージに入ったらタスクを作る。例：

• ステージ「Demo Scheduled」→ 「アジェンダを送付し出席者を確認する」タスクをデモ24時間前に作成

自動化テンプレートは管理者が管理できるようにして販売プロセスの一貫性を保ちます。

ノイズにならない通知

収益に関わる重要なシグナルに絞ります：

• 期限超過タスク
• X日間活動がない商談（idle）
• 次のステップがない高額商談のクローズ期日直前

新規リードのSLAルール

スピードが重要ならSLAを設定します：「新規リードはX時間以内にコンタクトする」。リードにSLAタイマーを表示し、期限が近づいたら所有者にアラート、違反時はマネージャー通知や再割当てでエスカレーションします。これによりベストプラクティスが習慣化されます。

ダッシュボード、レポート、予測機能を設計する

ダッシュボードとレポートは日常の質問に素早く答えるべきです：「パイプラインに何がある？」「今週何が変わった？」「目標達成に向けて順調か？」。最初はシンプルに保ち、チームが実際に使うと分かったときに深めます。

営業ダッシュボードの基本

まずはマネージャーと個人の両方に使える「パイプライン概要」ビューを用意します。

コアウィジェット例：

• パイプライン合計値： オープンステージの商談合計（所有者やテリトリー別に分けることも）
• ステージ別件数と金額： 各ステージの商談数と金額
• 勝率： 選択した期間の（Won / Closed）の比率
• 新規／移動／停滞： X日で作成、進展、変化のない商談数

フィルタは明白に：日付範囲、所有者、チーム、パイプライン、製品ライン。"自分のパイプライン"へはワンクリックで飛べるようにします。

予測：実用的な2つの選択肢

軽量なアプリでも複雑なAIなしに実用的な予測は提供できます。

加重パイプライン：各商談金額にステージ確率を乗じる（例：Proposal 50%、Negotiation 75%）。説明しやすく傾向の把握に向きます。

Commit／Best-case：レップが商談をCommit、Best-case、Pipelineにタグ付けし、マネージャーが週／月単位で保守的と楽観的な集計を比較します。

加重予測を使う場合はステージ確率をパイプラインごとに設定できるようにします。

行動を促す活動レポート

基本的な活動（通話、メール、ミーティング）を追跡しレポートします：

• 個別レップ： 活動数と最終活動日
• 期間別： 日次／週次の合計で勢いを把握
• 活動と成果の比較： （任意だが有効）勝ち案件と負け案件の活動量を比較

これによりマネージャーは監査ではなくコーチングができます。

エクスポートと定期レポート

すべてのテーブルレポート（パイプライン一覧、活動ログ、クローズドWon案件）でCSVエクスポートを提供します。必要なら定期メールレポート（例：月曜のパイプライン要約）もサブスクライブ式で提供し、ライブレポートへのリンクを付けます。

レポートは保存済みビューにしてユーザーがフィルタ設定を使い回せるようにします。

連携とデータフローを計画する

連携はアプリが時間を節約するか追加作業を生むかの分岐点です。何をあなたのアプリで作成し、何を外部から同期するかを決め、各フィールドの“ソース・オブ・トゥルース”を定義してください。これがないと無音の上書きや重複が起きます。

メールとカレンダー：二重入力なしに活動を取得

営業は受信箱とカレンダーで仕事します。主要な活動（送信メール、開催済みミーティング）を自動で、またはワンクリックで記録できることを目指します。フル同期が重ければMVPでは：メール転送で活動作成、カレンダーイベントのインポート、「通話／ミーティングをログ」アクションなどの軽い方法を検討します。

リードソースとエンリッチ（データ品質チェック付き）

リードソースを列挙します：ウェブフォーム、チャットウィジェット、ウェビナー、広告、パートナーリスト。到着時に何をするかを決めます：

• 自動でリードを作成しソース／キャンペーンをタグ付け
• 任意でエンリッチ（企業情報、SNSプロファイル）を実行
• データ品質を検証（有効メール、正規化電話、メール／ドメインでの重複チェック）

エンリッチは判定改善に直接つながらない限り“あると良いもの”扱いにします。

クローズドWonの会計／契約ツールへの引き渡し

商談がクローズドWonになったら渡すべき情報を定義します（法的実体、請求連絡先、製品、支払条件）と、いつ送るか（即時、または承認後）。"Sent to finance"のようなステータスとタイムスタンプで引き渡しを監査可能にします。

連携アプローチ：API、Webhook、フォールバック

読み書きにはAPI、リアルタイムイベントにはWebhookを推奨します。エッジケースや移行、回復のためにインポート／エクスポート（CSV）をフォールバックに残します。

これらの決定を文書化する簡単な方法として、内部ページ（例：/blog/data-flow-checklist）を作ると便利です。

技術方針を決め、テストとロールアウトを行う

技術選択はトレンドを追うことではなく、チームが無理なく出荷・サポート・改善できることが重要です。

シンプルで実績のあるアーキテクチャ

多くの営業アプリは次の3つの部分で始められます：フロントエンド、バックエンドAPI、データベース。

• Webフロントエンド： レップが使う場所（パイプライン、商談ページ、タスク、ダッシュボード）
• バックエンドAPI： ビジネスルール（ステージ変更、割り当てロジック、権限）を集中管理
• データベース： リード、連絡先、商談、活動、監査履歴を構造化して保存

この分離で保守しやすく、後から連携を追加しても全体を作り直す必要が少なくなります。

初期の動作版を早く出すなら、Koder.aiのようなvibe-codingプラットフォームが実用的な近道になることがあります。チャットでワークフローを説明すると、Reactフロントエンド、Goバックエンド、PostgreSQLデータベースのような生産準備のスタックを生成する手助けをしてくれます（設計モード、ソースコードエクスポート、スナップショット／ロールバックなどの利便性付き）。

外せない非機能要件

早めに合意しておくべき基本：

• パフォーマンス： パイプラインや商談画面の許容ロード時間
• 稼働率期待： 小さなチームでも障害時の対応とメンテナンス時間を計画
• バックアップと復旧： 毎日の自動バックアップ、復旧テスト、保持ルール

セキュリティの基本

営業データは機密情報です。次を最低限実施します：

• 通信の暗号化（HTTPS）と可能なら保存時の暗号化
• デフォルトでの最小権限（レップ、マネージャー、管理者）
• セッションの保護：短寿命トークン、CSRF対策、パスワード変更時のログアウト

複数地域で提供する場合はデータのホスティング場所も計画します。Koder.aiなどはAWS上でグローバルに動き、各国でデプロイできるためデータ所在要件に便利な場合があります。

実際の営業業務に合ったテストとロールアウト

テストはパイプラインの実使用を模した内容にします：

• ログイン、リード取り込み、商談作成のスモークテスト
• 役割／権限テスト（レップが他チームの商談を見られない、マネージャーは見られる等）
• パイプラインルールテスト（ステージ遷移、必須フィールド、クローズ理由）

ロールアウトはパイロットチームから始め、短いトレーニングチェックリストと週次フィードバックループを回します。改善は予測可能なサイクル（1〜2週ごと等）でリリースし、営業がアプリが継続的に改善されると信頼できるようにします。