案件管理をExcelから移す｜項目・状態・担当者の設計

案件管理をExcelから移行するときは、列をそのまま業務アプリの画面へ写す前に、何を1案件と数えるかを決めます。そのうえで、案件担当者を「現在の状態」「次回行動」「次回行動日」の更新責任者に定めます。

同じ顧客への別提案は別案件なのか。商談を重ねるたびに案件を増やすのか。元表の1行が何を表すかを曖昧にしたまま移すと、こうした判断も画面へ持ち越します。案件の単位をそろえた後、顧客情報と対応履歴を分けて関連付けます。

以下は案件の数え方、項目の置き場所、状態と更新責任を決めるための架空の設計例です。実在する顧客の事例や、Cotomuの導入実績・効果を示すものではありません。製品仕様は2026年9月22日に確認しました。データ整理から切り替えまでの全体像は、Excelからシステムへ移行する全体の段取りで確認できます。

案件管理をExcelから移すときの起点は「1案件」の定義

業務アプリで1件として管理するデータをレコードと呼びます。kintoneもレコード単位でデータを管理し、それを構成する項目をフィールドと説明しています（「アプリとは」サイボウズ株式会社）。

Excelの1行を1レコードにすればよいように見えます。けれども、元表の1行が顧客情報と直近の対応内容まで兼ねていたらどうでしょう。同じ会社への異なる提案が上書きされたり、電話や訪問のたびに案件そのものが複製されたりします。

架空の条件例では、同じ顧客であっても「提案対象または契約判断の機会」が異なれば別案件とします。

最後の「要確認」を残したまま一括で取り込むと、移行後に案件数と関連履歴を修正する作業が残ります。先に元表の各行へ案件識別子を割り当てられる状態にすることが、この表の合格点です。

1枚の案件表を「顧客・案件・活動履歴」に分ける

1案件の境界が決まっても、会社名や住所を全案件に持たせれば、顧客情報の修正先が増えます。一方、対応内容を案件の1項目へ追記し続ければ、誰がいつ対応したかを1件ずつ扱えません。そこで、元の列を三つの記録単位へ分けます。

この配分案は、架空条件から導いたものです。製品共通の固定項目ではありません。受入条件は、顧客情報を1か所で直せること、そして1案件に活動履歴を追加しても案件レコードが増えないことです。

分けた記録は、業務で使う画面から参照できる必要があります。kintone公式ヘルプには、顧客管理アプリから条件が一致する活動履歴を一覧表示する例と、顧客ごとに案件情報をまとめて表示する例があります（「関連レコード一覧」サイボウズ株式会社）。識別子で関連付けたあと、必要な画面で関係する記録を参照できるかまで確かめます。

必須項目は「登録時」と「進行時」を分ける

すべてを登録時必須にすると、次回行動がまだ決まっていない案件を登録できません。だからといって任意項目ばかりにすれば、担当者も現在地も分からない案件が残ります。必須にする時点を分けると、この衝突を避けられます。

受入条件は、一覧を見るだけで担当者、現在地、次にすることを判定できることです。必須条件は、入力欄の充足ではなく、日々の判断に必要な情報の充足で評価します。

状態だけでなく、更新する人と操作を決める

状態の選択肢を作れば進捗管理になるのでしょうか。状態を変える人が決まっていなければ、表示されている現在地が正しいかを誰も引き受けません。

架空の運用条件では、案件担当者を、状態・次回行動・次回行動日の更新責任者とします。担当者の変更時には、この更新責任も新しい案件担当者へ移します。

kintoneのプロセス管理も、処理状況を示す「ステータス」、その状況で作業を任された「作業者」、別の状況へ進める操作である「アクション」を組み合わせます。一つのステータスに複数のアクションを設定でき、フィールド値による実行条件も付けられます（「ステータス、作業者、アクションとは」サイボウズ株式会社）。

この三つを案件管理に置き換えると、状態名に加えて決める対象が見えます。遷移元、操作名、実行者、遷移先、その時点で必要な項目を1行ずつ決めます。

失注・再開を消さない状態遷移表

失注した案件で商談が再開したとき、状態を単に「進行中」へ書き換えると、過去に失注した事実まで消えたように見えます。反対に失注のまま固定すれば、現在地と次回行動が分かりません。過去の記録を保持しながら、現在の状態だけを進める必要があります。

「再開」の扱いも、1案件の定義に従います。提案対象と契約判断の機会がどちらも以前と同じなら、架空条件では同じ案件を進行中へ戻します。それらが異なるなら別案件です。再開という言葉だけで同一案件かどうかを決めないことが重要です。

同じ案件が再開後に再び失注した場合も、前の失注日や理由を上書きしません。現在の状態は案件に持たせ、状態変更は案件ID、変更前後の状態、日時、理由、操作者を一件ずつ履歴へ追加します。

月別の「失注案件数」なら、対象月の失注履歴を抽出し、案件IDの重複を除いて数えます。「失注回数」なら、その月の失注履歴の行を数えます。現在の状態が失注の案件数とも異なるため、集計名にどの数え方かを明記します。

受入時は同じ案件で失注・再開・再失注を実行し、初回の理由と日時が残ること、現在地と次回行動が更新されることを確かめます。この履歴保存と集計は独自の設計案です。kintoneの標準機能だけで希望する集計までできるかは、別に確認します。

移行前に合意する判定項目

• 元表の各行を、迷いなく一つの案件識別子へ対応付けられるか
• 同じ顧客でも、提案対象または契約判断の機会が異なる場合を別案件にできるか
• 会社名・住所を顧客、案件名・担当者・状態・見込金額・次回行動を案件、対応日時・対応者・対応内容を活動履歴へ配分できるか
• 顧客情報を1か所で直し、案件を重複させずに複数の活動履歴を追加できるか
• 登録時と進行中へ移す時で、必須にする項目を分けられるか
• 案件担当者が、状態・次回行動・次回行動日の更新責任を持つか
• 再失注しても過去の状態変更履歴が残り、失注案件数・失注回数・現在失注中の案件数を区別できるか
• 各状態の遷移元、操作、実行者、遷移先、必須項目に空欄がないか

この判定を満たしてから、画面や製品を選びます。選択肢の違いを整理する場合は、SaaS・kintone・スクラッチ開発の比較も判断材料になります。

移行前の案件表で、同じ顧客の別提案と、失注後に再開した案件を確認します。それぞれに案件識別子を割り当て、担当者が状態と次回行動を更新できるかを試すと、項目表だけでは見落とした運用の違いを確認できます。

自社業務に合わせたWebアプリを検討する場合、Cotomuでは受発注、申請承認、作業報告など、困っている業務ひとつから相談できます。初期開発と運用保守は個別見積もりで、連携・移行・権限・データ出力の範囲は契約前の確認事項です。業務アプリの相談から、現在の案件表と判断条件を共有してください。