脱Excelの運用ルール設計で決めること｜誰が入力し、誰が確認するか

先に結論

脱Excelの運用ルール設計で決めるのは、新しい仕組みの使い方 です。
画面や機能を細かく決める前に、次の5つを整理します。

• 誰が入力するか
• 誰が確認するか
• 誰が修正できるか
• 例外時にどう処理するか
• どの会議やレポートで使うか

つまり、運用ルール設計は 新しい仕組みを現場で回すための約束を決める段階 です。

ここを飛ばすと、ツールを入れても「結局、会議前だけExcelに戻る」「例外時だけ別ファイルで管理する」という状態になりやすいです。

全体の流れを先に見たい場合は、親記事から戻ると整理しやすいです。

脱Excelの進め方ガイド

前のフェーズである To-Be 設計がまだ曖昧なら、こちらも先に読むとつながりやすいです。

脱Excelのあるべき姿はどう描く？何を残し、何を移し、何をやめるか

運用ルール設計はツール選定の前にやる

脱Excelの話では、つい早めにツール比較へ進みたくなります。

• kintone がよいのか
• Notion で足りるのか
• Google スプレッドシートに寄せるのか
• 専用システムを入れるべきか

もちろんツール選定も大事です。
ただ、その前に どう使う前提なのか が決まっていないと、判断軸がぶれます。

たとえば、同じ案件管理でも、

• 営業が毎日更新するのか
• 週次会議の前だけ更新するのか
• 事務担当がまとめて整えるのか
• 承認後は営業が触れないようにするのか

で、必要な機能は変わります。
使い方が決まらないまま機能を比べても、正しい比較になりにくい のです。

まず決めたい5つの運用ルール

最初から細かいルールブックを作る必要はありません。
まずは、次の5つを言える状態にするだけで十分です。

1. 誰が入力するか

最初に決めるのは、入力責任者 です。

よくある失敗は、「気づいた人が更新する」という決め方です。
一見柔軟に見えますが、実際には誰も責任を持たず、情報が古くなりやすいです。

たとえば案件管理なら、

• 新規案件は営業担当が登録する
• 受注確度は担当営業が更新する
• 請求予定日は事務担当が確認する
• 完了日は責任者が締める

のように、項目やタイミングごとに分けても構いません。
大事なのは、誰が入れる情報なのかを曖昧にしない ことです。

2. 誰が確認するか

入力者と確認者は、必ずしも同じでなくて構いません。
むしろ、重要な情報ほど 確認する人 を分けた方が安定します。

たとえば、

• 金額は営業責任者が確認する
• 請求に関わる項目は事務担当が確認する
• 顧客名の表記ゆれは管理担当が整える
• ステータスの更新漏れは週次会議前に確認する

という形です。

確認者が決まっていないと、データの正しさを誰も保証できません。
見る人は多いのに、確認する人はいない という状態は、Excel運用でも新しい仕組みでも起きます。

3. 誰が修正できるか

脱Excelでは、修正権限も大事です。

Excelでは、共有ファイルを触れる人なら誰でも直せることが多いです。
その手軽さが便利な一方で、次のような事故も起きます。

• 金額がいつの間にか変わる
• 過去のステータスが上書きされる
• 誰が直したのか分からない
• 会議後に数字が変わっている

新しい仕組みに移すなら、誰でも直せる状態をそのまま引き継ぐか は見直した方がよいです。

たとえば、

• 担当者は自分の案件だけ更新できる
• 金額確定後の修正は責任者だけできる
• 顧客マスタは管理担当だけが直せる
• 締め後の修正は履歴を残す

のように決めます。
修正できる人を絞ることは、現場を疑うことではなく事故を減らすこと です。

4. 例外時にどう処理するか

運用ルール設計で一番抜けやすいのが、例外処理です。

通常フローはきれいに描けます。
でも実際の現場では、次のようなことが起きます。

• 金額がまだ未確定
• 顧客名が正式決定していない
• 担当者が途中で変わる
• 締め後に内容修正が入る
• 承認前に急ぎで対応が必要になる

ここを決めないまま始めると、現場は一番慣れている方法に戻ります。
多くの場合、それがExcelです。

たとえば「金額未確定なら空欄にする」のか、「未確定として登録する」のかだけでも、後の集計は変わります。
例外時だけExcelに戻る運用を放置しない ことが、定着の分かれ目です。

5. どの会議やレポートで使うか

最後に、新しい仕組みの情報を どこで使うか も決めます。

ここが曖昧だと、入力は新システム、会議資料はExcelという二重運用になりがちです。

たとえば、

• 週次会議ではステータス別の一覧を見る
• 月次報告では担当者別の受注見込みを見る
• 経営会議では確度別の売上見込みを見る
• 請求確認では完了案件だけを抽出する

のように、利用場面まで決めます。

入力先だけでなく、見る場面まで設計する と、運用はかなり安定します。

通常フローと例外フローを分けて考える

運用ルール設計では、業務フローを1本のきれいな線で描かない方がよいです。
実務では、通常フローと例外フローがあります。

たとえば案件管理なら、通常フローは次のように描けます。

1. 営業が案件を登録する
2. 商談後にステータスを更新する
3. 受注確度と見込み金額を更新する
4. 週次会議で確認する
5. 受注または失注で完了する

一方で、例外フローは別に考えます。

1. 顧客名が未確定のまま相談が始まる
2. 見込み金額が途中で大きく変わる
3. 担当者が異動や休職で変わる
4. 会議後にステータス修正が必要になる
5. 失注後に再提案へ戻る

この2つを分けるだけで、設計の見え方はかなり変わります。
通常時だけでなく、乱れたときの戻し方まで決める のが運用ルール設計です。

案件管理で考える運用ルールの例

ここでは、Excelで案件管理をしている会社を例に考えます。

案件管理をExcelで続ける限界については、こちらの記事でも整理しています。

案件管理をExcelで続ける限界

たとえば、運用ルールは次のように決められます。

決めること	例
入力する人	営業担当が商談後、その日中に更新する
確認する人	営業責任者が週次会議前に確認する
修正できる人	担当営業は自分の案件、金額確定後は責任者のみ修正する
例外時の扱い	金額未定は空欄にせず「未確定」として登録する
会議での使い方	週次会議では担当者別、ステータス別、確度別に見る

この程度でも、Excelから新しい仕組みに移すときの判断がかなりしやすくなります。

たとえば「商談後その日中に更新する」と決めるなら、スマートフォンから入力できる方がよいかもしれません。
「週次会議前に責任者が確認する」と決めるなら、未確認の案件が分かる仕組みが必要かもしれません。

つまり、運用ルールが決まると、必要な機能も自然に見えてくる のです。

よくある失敗

運用ルール設計でよくある失敗も押さえておきます。

1. 入力項目だけを決めてしまう

「案件名」「顧客名」「金額」「確度」のような項目を決めることは大切です。
ただし、項目だけ決めても運用は回りません。

必要なのは、

• 誰が入れるか
• いつ入れるか
• 誰が確認するか
• 間違っていたらどう直すか

まで決めることです。

項目設計だけでは、運用設計にはならない と考えた方がよいです。

2. 確認者を決めない

「みんなで見るから大丈夫」という状態は危険です。
見る人が多いほど、逆に誰も確認しないことがあります。

特に、

• 金額
• 請求予定
• 顧客名
• 契約ステータス
• 完了日

のように後工程へ影響する情報は、確認者を決めておく方が安全です。

3. 例外時だけExcelを残す

例外時にだけExcelへ戻す運用は、最初は便利に見えます。
でも、それを続けると新しい仕組みが正本になりません。

結果として、

• どちらが最新か分からない
• 会議前にまた転記が必要になる
• 例外が増えるほどExcel側が正しくなる
• 新しい仕組みを信じられなくなる

という状態になります。

例外処理こそ、新しい運用の中で受け止める ことが大事です。

4. 会議資料だけ別で作り続ける

入力は新しい仕組みにしても、会議資料をExcelで作り続けると二重運用になります。

もちろん、すぐにすべての資料をなくす必要はありません。
ただし、最低限「会議で何を見るのか」「どの情報を正本にするのか」は決める必要があります。

会議で使われない仕組みは、現場でも軽く見られます。
会議や報告で使うところまで含めて運用を設計する と定着しやすくなります。

運用ルール設計が終わった状態の目安

運用ルール設計が一段落したと言えるのは、次の質問に答えられる状態です。

• 新しい情報は誰が登録するか
• いつ更新するか
• 誰が確認するか
• 誰が修正できるか
• 例外時はどこで受け止めるか
• どの会議やレポートで使うか

ここまで言えると、次の要件定義へ進みやすくなります。
逆に、ここが曖昧なまま要件定義へ進むと、機能要望だけが増えやすいです。

誰が見ても同じ回し方を説明できる状態 を目安にするとよいです。

まずやるなら現行Excelの使われ方を書き出す

最初から理想のルールを作ろうとすると、話が大きくなります。
まずは、今のExcel運用で実際に起きていることを書き出す方が早いです。

たとえば、次の順番で整理します。

1. 今のExcelに誰が入力しているかを書く
2. 誰が確認しているかを書く
3. 会議前に誰が加工しているかを書く
4. 例外時にどのファイルへ逃げているかを書く
5. 新しい運用でも残す作業とやめる作業を分ける

この作業をすると、運用ルールとして決めるべきところが見えてきます。

いま実際に回っている仕事を見ずに、理想のルールだけ作らない ことが大切です。

具体例で見る運用ルール設計

以下は、イメージしやすくするための架空の例 です。

失敗例: 東浜設備サービス株式会社（従業員38名 / 設備保守）
この会社では、保守案件の管理をExcelから新しい管理ツールへ移しました。
入力項目はきれいに整理され、一覧画面も見やすくなりました。
しかし、誰がいつ更新するかを決めていなかったため、現場担当は作業後すぐには入力せず、事務担当が月末にまとめて確認する状態になりました。
さらに、急ぎ対応や金額未確定の案件は「あとで整える」としてExcelに残されました。
結果として、会議前には新ツールとExcelの両方を見比べる必要があり、以前より確認作業が増えました。
失敗の原因は、項目設計はしたが、入力責任と例外処理を決めていなかったこと でした。

成功例: 北川産業機器株式会社（従業員46名 / 産業機器販売）
この会社では、営業案件の正本をExcelから共有管理へ移す前に、運用ルールを先に決めました。
新規案件は担当営業が当日中に登録し、金額と確度は週次会議の前日までに更新します。
営業責任者は会議前に未更新案件を確認し、金額確定後の修正は責任者だけが行うルールにしました。
金額未確定の案件は空欄にせず「未確定」として登録し、会議では未確定案件だけを別に確認します。
会議資料もExcelへ転記せず、共有管理の一覧をそのまま見る前提に変えました。
うまくいった理由は、ツールに移す前に、誰が入力し、誰が確認し、例外をどう扱うかを決めたこと でした。

まとめ

脱Excelの運用ルール設計で大事なのは、細かいルールブックを作ることではありません。
新しい仕組みを現場でどう回すかを決めること が中心です。

押さえておきたいのは、次の5点です。

• 入力責任者を決める
• 確認者を決める
• 修正権限を決める
• 例外処理を決める
• 会議やレポートでの使い方を決める

ここまで決まると、次の要件定義では「どんな機能がほしいか」ではなく、この運用を支えるには何が必要か という話ができます。