社員5〜30名の会社がExcel業務をWeb化する前に避けたい3つの失敗

社員5〜30名ほどで、同じ内容を複数のExcelへ転記したり、担当者しか分からない集計が残ったりしている会社向けの記事です。

「紙やExcelで管理している業務を、Webアプリにすれば効率化できますか？」

多くの場合、改善の余地はあります。ただし、今の業務をそのまま画面に置き換えるだけでは、使いにくさまでデジタル化してしまいます。

Webアプリ開発の前に避けたい3つの失敗を整理します。

■ 1．悪い業務を、そのままシステム化する

紙の申請書に20項目あるから、画面にも20項目作る。Excelが5ファイルあるから、5つの管理画面に分ける。

これは現状の再現であって、業務改善とは限りません。

今の項目や手順には、昔のルール、担当者だけが分かる確認、使われていない集計が残っていることがあります。

開発前に、

・何のための入力か

・誰が使う情報か

・その情報で何を判断するか

・同じ内容を別の場所でも入力していないか

を確認します。

不要な工程を消してからシステム化するほうが、開発費も運用負担も小さくなります。

■ 2．通常の流れだけを要件にする

打ち合わせでは、理想的な一日の流れが説明されがちです。

しかし現場で困るのは例外です。

・入力内容が後から変わった

・承認者が不在

・同じ顧客が重複登録された

・締切を過ぎた

・添付書類が足りない

・一部だけ取消になった

・過去データを確認したい

通常処理だけで作ると、例外が起きるたびにExcelや紙へ戻ります。結果として「システムと手作業の二重管理」が始まります。

要件定義では、うまくいく流れより、止まる場面、戻す場面、やり直す場面を具体的に聞きます。

■ 3．現場を知らない人だけで決める

経営者や管理者は、全体の目的と課題を把握しています。一方、日々入力する人は、細かな手間や例外を知っています。

どちらか一方だけで決めると、

・管理者には便利だが入力が大変

・現場では使いやすいが集計できない

・権限が曖昧で見せてはいけない情報が見える

といった問題が起きます。

目的を決める人、実際に使う人、データを確認する人、それぞれの視点を入れます。

■ 最初に作るのは画面ではなく、業務の地図

開発前に、次の内容を一枚に整理すると判断しやすくなります。

・業務の開始点と完了点

・担当者と承認者

・入力する情報

・判断条件

・例外と差戻し

・作成される帳票や通知

・既存システムとの関係

この地図があると、必要な機能と後回しにできる機能を分けられます。

■ 最初から全部作らない

業務アプリは、小さく作って現場で試すほうが安全です。

たとえば、

1．申請と一覧

2．承認と通知

3．集計と帳票

4．外部サービス連携

のように段階を分けます。

最初の利用で分かったことを次へ反映できるため、使われない機能へ費用をかけずに済みます。

■ 効率化の指標を決める

「便利になった」だけで終わらせず、

・入力時間

・転記回数

・確認や差戻し件数

・月次集計にかかる時間

・問い合わせ件数

など、改善前後で比べる指標を決めます。

Webアプリ化の目的は、紙をなくすことではありません。

人が判断や顧客対応へ時間を使えるようにし、ミスや属人化を減らすことです。

■ 5〜30名規模で起きやすい「Excelが基幹システム」問題

小規模企業では、Excelが柔軟で安く、担当者がすぐ直せるため、業務に深く入り込みます。

問題はExcelそのものではありません。

・最新版がどれか分からない

・共有フォルダにコピーが増える

・同じ顧客を複数ファイルへ転記する

・数式を上書きしても気づかない

・作成者しかマクロを直せない

・月末に複数表を手作業で集める

という状態です。

この段階では、表計算の改善で十分な範囲と、Webアプリに分ける範囲を見極めます。

一人だけが使う計算表までWeb化すると、操作が遅くなり費用も増えます。複数人が同時に登録し、履歴や権限が必要な部分は、Web化の効果が出やすくなります。

■ Web化を判断する6つの質問

1．同じ情報を複数人が編集するか

2．最新版や変更履歴が問題になるか

3．外出先や複数拠点から使うか

4．権限で見せる情報を変えるか

5．定型の通知・承認・集計が多いか

6．入力ミスが売上、顧客、法令へ影響するか

該当が多いほど、共有データベースとWeb画面の価値が高くなります。

反対に、利用者が一人で、計算が中心で、頻繁に自由な分析をするなら、Excelを整えるほうがよい場合があります。

DXは、何でもアプリに置き換えることではありません。適した道具へ役割を分けることです。

■ 実例として考える「見積りから請求まで」の分断

営業が見積りExcelを作り、受注後に事務が顧客台帳へ転記し、現場が別の進行表を作り、月末に経理が請求表へ再入力する業務を考えます。

一件の受注情報が4回入力されます。

顧客名の表記が少し違い、金額変更が一つの表にしか反映されず、請求漏れが起きるかもしれません。

Web化するなら、画面を4つ作るのではなく、一つの案件データを、営業、事務、現場、経理が役割ごとに更新します。

営業は見積り、現場は進捗、経理は請求情報だけを触る。変更履歴を残し、請求予定を自動集計する。

この発想が「Excelの再現」と「業務の再設計」の違いです。

■ データ項目は、画面より先に定義する

同じ「顧客名」でも、法人名、屋号、請求先名、担当者名を混ぜると後で集計できません。

開発前に、

・項目名

・意味

・入力形式

・必須か任意か

・誰が入力するか

・いつ変更できるか

・どの帳票で使うか

を定義します。

自由入力を減らしすぎると例外に対応できず、増やしすぎると検索・集計できません。

住所、電話、日付、金額、ステータスなど、後で使う項目ほどルールを決めます。

■ 権限は役職名だけで決めない

「管理者」「一般社員」だけでは、実際の業務に合わないことがあります。

営業は自分の案件を編集できるが、他担当の粗利は見られない。経理は全案件の請求を見られるが、営業メモは変更できない。経営者は集計を見られるが、日常入力はしない。

役職ではなく、データごとに、見る・作る・変える・削除する権限を整理します。

削除は特に慎重にします。消す代わりに無効化し、履歴を残す設計が必要な業務もあります。

■ データ移行を最後に回さない

既存Excelからデータを移す場合、表記ゆれ、空欄、重複、数式結果、結合セルなどが問題になります。

完成後に全部入れようとすると、アプリ側の項目と合わず、手作業が増えます。

早い段階でサンプルデータを確認し、

・何年分を移すか

・過去データは編集するか閲覧だけか

・重複をどう判定するか

・移行しない情報は何か

・元ファイルをいつまで保管するか

を決めます。

すべてを移すことが正解ではありません。現行業務に必要なデータと、監査・参照用に残すデータを分けます。

■ MVPは「機能が少ない版」ではなく「一つの業務が完了する版」

ログイン、顧客一覧、案件一覧だけを作っても、仕事が最後まで終わらなければ現場はExcelを併用します。

MVPでは、範囲を狭くしながら、開始から完了まで一つの業務を通します。

たとえば「案件登録→承認→完了→月次一覧」までを作り、在庫連携や高度な分析は次へ回します。

現場が実際の一件を処理できることが重要です。

■ 導入時は、システムより運用変更が難しい

新しい画面を作っても、担当者はこれまでのExcelを残したくなります。

切替日、入力責任者、旧ファイルの扱い、問い合わせ先を決めます。

最初の数週間は、操作ミスより「どちらへ入力するか」の混乱が起きます。

テスト担当だけでなく、普段PCが得意ではない人にも触ってもらい、言葉、ボタン、エラー表示を確認します。

■ 開発費の前に、削減できる工数を試算する

一件5分の転記を月300件行えば、月25時間です。

確認・修正に月10時間、集計に月8時間かかるなら、合計43時間です。

Web化で半分にできると仮定した場合、月約21時間を別の仕事へ使えます。

ここに人件費、ミスの損失、対応速度を加えて、開発・保守費と比較します。

数字を大きく見せるためではなく、どの工程を優先して自動化するか決めるための試算です。

■ 成功条件は「現場が使う」だけでは足りない

導入後は、

・入力時間が減ったか

・転記が減ったか

・差戻しやミスが減ったか

・月次集計が早くなったか

・担当者不在でも処理できるか

・顧客への回答が早くなったか

を確認します。

利用回数が多くても、仕事が増えていれば成功ではありません。

Webアプリ化で大切なのは、画面を納品することではなく、業務の流れを変え、効果を確認できる状態を作ることです。

石井DXスタジオでは、画面を作る前に現場の業務を伺い、経営者と利用者の両方に合う仕組みを整理します。

紙・Excel業務のWebアプリ化はこちら

https://coconala.com/services/4344424