たとえば、営業部門が受注状況をExcelで管理していて、担当者ごとにファイルの書式がばらばら、集計は月末に手作業でコピーして回している、という想定例を考えてみます。担当者から「そろそろシステム化した方がいいのでは」という声が出たとき、多くの企業がいきなり要件定義やツール選定に進みがちです。しかし、その前にやるべきことがあります。それは「どの運用を残し、どの運用を変えるか」を決めることです。
Excel業務をシステム化する目的は、ツールを新しくすることではなく、業務の負担や間違いを減らすことです。この前提を飛ばすと、システムを入れても結局Excelに戻ってしまう、という状態になりかねません。
現状の運用を「残すもの」と「変えるもの」に分ける
まず着手すべきは、現在のExcel運用を洗い出し、それぞれについて「このまま残してよいか」「変えるべきか」を判断することです。ここでいう運用とは、入力のタイミング、承認の流れ、共有の方法、集計や加工の手順などを指します。
判断の軸は次の2点です。
- その運用は属人的な工夫でなんとか回っているだけではないか
- その運用は業務の性質上、今後も柔軟な変更が必要か、それとも固定化してよいものか
担当者間でこの整理を進めるときは、次のような質問が有効です。
「このExcelの手順のうち、担当者が変わっても同じやり方で回せる部分はどこですか」
この質問への答えがあいまいな部分は、属人化している可能性が高く、システム化の前に運用そのものを整理する必要があります。
Aを選ぶ条件：既存サービスや運用改善で足りる場合
すべてのExcel業務がシステム開発を必要とするわけではありません。次のような条件に当てはまる場合は、既存のクラウドサービスや運用ルールの見直しで十分なことが多いです。
- 入力・集計・共有の流れが単純で、担当者や部署間で大きな差がない
- データ量が少なく、処理の自動化による時間短縮効果が限定的
- 今後半年〜1年程度で業務内容自体が変わる可能性がある（暫定運用でよい）
- 既存の表計算ソフトの共同編集機能やクラウドストレージの履歴管理で、共有や版管理の課題が解消できる
この場合は、まずファイルの置き場所を統一する、入力規則をシートに設定する、承認の順序を明文化するといった運用改善から始める方が、コストと導入の手間に見合う結果になりやすいです。
Bを選ぶ条件：システム化を検討すべき場合
一方で、次のような状態が複数当てはまる場合は、システム化の検討に進む価値があります。
- 複数のExcelファイルを手作業で突き合わせる工程があり、転記ミスや二重入力が起きている
- 特定の担当者しか更新方法がわからず、その人が不在だと業務が止まる
- データ量や関係者が増えており、Excelの動作が重い、ファイルが壊れるなどの技術的な限界が出ている
- 集計結果を他部署や経営層に定期的に報告する必要があり、手作業の集計に時間がかかっている
ここでいう「システム化」とは、必ずしも大規模な開発を意味しません。既存の業務システムに機能を追加する、社内向けの小規模なデータベースを作るなど、規模に応じた選択肢があります。重要なのは、システム化の前に「どの運用ルールを新しい仕組みに引き継ぐか」を決めておくことです。運用ルールを決めないままシステムだけを作ると、結局はシステムの外でExcelによる調整が発生し、二重管理になります。
要件定義に進む前にやっておくこと
運用の仕分けが終わったら、開発会社に相談する前に、残す運用について次の点を言語化しておくと、要件定義の精度が上がります。
- 誰が、いつ、何を、どの順番で入力・確認するか
- ミスが起きたときに誰がどう修正するか（差し戻しの手順）
- データを見る人は誰で、どんな形式で見たいか
これらが整理されていれば、開発会社側も「どこを自動化すべきか」「どこは人の判断を残すべきか」を具体的に提案しやすくなります。逆にこの整理がないまま「Excelをシステム化したい」とだけ伝えると、要件定義の段階で手戻りが発生しやすくなります。
着手前チェックリスト
- 現在のExcel運用を、入力・承認・共有・集計の工程ごとに書き出したか
- 各工程が特定の担当者に依存していないか確認したか
- 既存のクラウドサービスや運用ルールの見直しで解決できないか検討したか
- 転記ミスや二重入力など、実際に困っている場面を具体的に挙げられるか
- システム化後も人の確認を残すべき工程を洗い出したか
- 新しい仕組みで「誰が」「何を」「どう見る」かを言葉にできているか