Excel業務をアプリ化する方法と導入費用の考え方

Excelを使っていること自体が問題とは限りません。一人で扱う少量のデータや、その場の試算には向いています。アプリ化を考えたいのは、同時更新で情報が食い違う、同じ内容を転記する、承認の状況が分からない、集計が担当者しかできない、といった業務上の負担が続く場合です。

大切なのは、Excelの全機能を画面へ写すことではなく、誰が何を入力し、誰が確認し、どの結果を使うかを整理することです。本記事では、対象業務の選び方、データと権限の設計、費用を見積もる前提、移行とテストの手順を、顧客・見積管理を題材に説明します。以下の業務例は架空のものです。

アプリ化する前に、Excelの改善で足りるかを判断する

ファイル名がばらばら、入力項目が統一されていない、置き場所が決まっていないという問題なら、ルールの整理で改善する余地があります。一方、複数人が同じ情報を更新し、利用者ごとの閲覧範囲や履歴が必要な業務では、アプリ化を検討する理由が強くなります。

アプリ化の効果を説明するには、現在の作業時間と差し戻しの件数を先に記録します。「便利になりそう」ではなく、どの作業を減らし、どの確認を確実にするかを決めてください。削減時間は導入後に実測し、導入前の期待を実績として扱わないようにします。

最初の対象は一つの業務に絞る

最初から、顧客、案件、見積、受注、請求をすべて置き換えると、部署ごとの例外まで一度に決める必要が出てきます。まずは、入力から結果の確認までを一つの流れとして区切り、使う人と完了の状態が説明できる範囲を選びます。

例えば「営業担当が見積情報を登録し、上長が承認し、確定した内容を出力する」なら、入口と出口を決めやすくなります。請求への連携や過去データの完全移行は、初期版へ含めるか、次の段階に分けるかを判断できます。

優先順位は、発生頻度、作業時間、ミスの影響、利用者の協力を得られるかで考えます。最も複雑な業務から始めるより、担当者が試せて改善点を返せる業務を選ぶ方が、次の判断材料を集めやすくなります。

現在の手順を「入力・処理・確認・出力」に分ける

使っているExcelを渡すだけでは、表に現れない判断や例外が伝わりません。誰が、いつ、どの情報を受け取り、何を確認して次へ進めるかを書きます。メール、紙、口頭で補っている作業も対象です。

見積管理なら、依頼の受付、顧客の確認、明細の入力、値引きの承認、送付、変更、受注後の引き継ぎを並べます。「急ぎの場合は承認を後回しにする」「顧客によって書式が違う」といった例外も書き出し、初期版で扱うものを選びます。

業務の例外をすべて禁止する必要はありません。ただし、例外を許す人と記録の残し方は決めます。システム外で変更した内容が戻らないと、画面の情報と実際の仕事が再びずれてしまうためです。

シートの列から、管理するデータの単位へ考え直す

Excelでは、顧客名や住所が見積ごとに繰り返し入力されていることがあります。アプリでは、顧客と見積を別の単位として持ち、番号で関連付ける設計を検討します。同じ顧客名を何度も書く方法だけに依存しないことが、重複を減らす出発点です。

日付、金額、状態の意味もそろえます。売上日が受注日なのか納品日なのかで、集計結果は変わります。空欄が「未入力」「未確定」「該当なし」のどれなのかも整理してください。後から見ただけで意味を判断できない値を減らすことが大切です。

顧客番号や商品コードの先頭のゼロ、全角・半角、住所の表記揺れなどは、移行前に確認します。見た目を整えるだけでなく、元データをどの規則で変換したかを残せるようにしましょう。

画面は利用者が行う操作から決める

必要な画面は、登録、一覧、検索、詳細、承認、出力などの操作から考えます。シートが五枚あるから五画面にする、と決める必要はありません。同じ情報を見るだけの操作と、金額や状態を書き換える操作は分けて整理します。

一覧では、担当者、状態、期限など、仕事の判断に使う項目を優先します。すべての列を一画面へ詰め込むと、探したい情報が見つからない問題が残ります。現場の担当者に「朝、最初に確認するもの」「締め日の前に確認するもの」を聞くと、必要な表示が見えてきます。

入力時のチェックも決めます。必須項目、金額の範囲、存在しない顧客、重複する番号など、保存前に止めたいことを書き出してください。エラーの内容は、利用者が次に何を直せばよいか分かる表現にします。

権限と履歴を、開発の後回しにしない

誰でも閲覧・変更できる前提で作った後に、部署ごとの見せ分けを追加すると、画面やデータ取得の仕組みまで変わる場合があります。最初に、営業担当、承認者、管理担当などの役割と、それぞれができる操作を整理します。

例えば、営業担当は自分の見積を登録し、承認者は対象部署の見積を承認し、管理担当は顧客の重複を修正する、と決めます。誰がいつ金額や状態を変えたかを追う必要があれば、履歴も要件に入れます。

退職や異動に伴う権限変更、誤削除したデータの戻し方、管理者が不在のときの対応も確認します。ログインできることだけを権限テストの完了にせず、見えてはいけない情報を別の利用者が取得できないかまで確かめてください。

既製サービス・ノーコード・独自開発を比較する

業務が既製サービスの標準機能へ収まるなら、導入と運用を含めて比較します。自社の手順を一部変える方が、独自機能を作り続けるより負担が小さい場合もあります。逆に、承認や外部連携が自社固有なら、構築できる範囲を確認します。

ノーコードは、画面を作る操作だけで判断しないことが大切です。利用人数による料金、権限、外部連携、処理量、データの取り出し方、担当者が変わったときの保守まで確認します。短く試せることと、長期運用の負担が小さいことは同じではありません。

独自開発では、要件を合わせやすい反面、公開後の保守や運用を誰が担うかを決める必要があります。どの方法でも、初期費用だけでなく、外部利用料、変更、終了時の移管を同じ条件で比べます。比較の前提は業務アプリの見積もりを整理する記事も参考にしてください。

既存データの移行を一つの作業として見積もる

データ移行は、ファイルをアップロードして終わるとは限りません。使っている列の意味を調べ、重複や欠損を整理し、新しい項目へ対応付け、件数と金額を照合する仕事があります。移行する期間と、閲覧用に残す過去データを分けることも検討します。

作業用のコピーを使い、元データを保全してから、少量のデータで試します。顧客、見積、明細の関連が切れていないか、番号や日付が変わっていないか、合計金額が一致するかを確認してください。件数が一致しても、計算結果や関連付けが正しいとは限りません。

切り替えの日には、旧Excelの更新を止める時刻と、新しいアプリへ入力を始める時刻を決めます。両方へ自由に入力できる期間を長くすると、どちらが正しいか判断できなくなります。不具合で戻す場合に、切り替え後の入力をどう回収するかまで考えておきます。

導入前に確認するテスト項目

テストでは、開発者が操作できるかだけでなく、実際の担当者が普段の仕事を完了できるかを見ます。正常な入力に加えて、空欄、重複、権限不足、取消、差し戻し、締め日の変更などを試します。

• 入力、検索、修正、承認、出力まで一連の仕事を完了できる。
• 別の担当者や部署の情報について、許可した範囲だけを扱える。
• 同時に操作しても、意図しない上書きや二重登録が起きないかを確認する。
• 金額、税、日付、集計の基準を、業務の担当者が照合できる。
• データの書き出し、バックアップ、復旧の手順を確認できる。
• 障害や誤操作が起きた際の連絡先と、暫定的な業務の続け方が分かる。

テストで見つかった事項は、修正が必要なもの、運用で扱うもの、次の改善に回すものに分けます。何をもって公開できると判断するかは、開発を依頼する前から合意しておくと進めやすくなります。

切り替え当日と初月の運用を計画する

切り替え当日の確認例

説明用の例として、金曜の夕方に旧Excelの更新を止め、翌営業日からアプリへ入力する計画を考えます。事前に利用者へ停止時刻と問い合わせ先を伝え、最後の更新版を保全し、移行するデータを確定します。日程は自社の営業日と、停止できる時間に合わせて決めてください。

移行後は、顧客の件数、見積の件数、未承認の見積、対象期間の金額を照合します。差が出た場合は、抽出条件、重複の扱い、取消、端数の計算などを調べます。「ほぼ合っている」と処理せず、差の理由を説明できることを確認します。

最初の利用者が、実際に使う端末と権限でログインし、登録から確認までを試します。開発者の管理者権限で動いた結果だけを、全利用者の確認にしないでください。利用者を増やす前に、業務担当と技術担当の両方が開始の判断を行います。

切り戻しを判断する場合は、アプリに入力した新規データを回収し、旧Excelへどう反映するかを決めます。両方の更新を自由に再開するのではなく、どの時刻以降の情報を、誰がどの順番で照合するかを管理します。停止と復旧の手順にも担当が必要です。

初月の改善は、要望と不具合を分ける

公開後に「前より入力しにくい」という声が出たら、入力項目が増えたのか、表示が分かりにくいのか、必要な確認を省けなくなったのかを分けます。以前はチェックせずに進めていた作業を正しく確認する仕組みに変えた場合、単純な操作回数だけでは比較できません。

不具合は期待した動作との違いとして記録し、追加要望は新しく必要になった仕事として記録します。要望をすべて初期版の不具合と扱うと、範囲と費用の認識がずれます。利用者には、問い合わせ先と、改善の優先順位を決める人を案内しておきます。

効果の確認には、導入前と同じ仕事で測った時間、転記の回数、差し戻し、集計の確認にかかる時間を使います。忙しい月と通常月を無条件に比べず、件数や利用者の変化も添えてください。測定結果を見て、次に広げる業務を選ぶことが重要です。

一度に作らないものも残しておく

今回対象から外した帳票や連携は、削除した要望として忘れず、目的と見送った理由を記録します。利用が増えてから本当に必要かを確認できれば、先回りして作り込む費用を抑えやすくなります。将来の拡張を相談する際にも、当初の判断が材料になります。

見積もりに必要な情報と、公開後の進め方

見積依頼には、対象業務、利用者、画面で行う操作、既存データの量と状態、権限、連携先、出力、希望時期を添えます。不明な点を隠して確定額だけを求めるより、調査が必要な事項として示した方が、後の追加費用の理由を説明しやすくなります。

要件整理、開発、移行、保守の役割を整理する資料として、IPA「情報システム・モデル取引・契約書」も参照できます。ひな型をそのまま当てはめるのではなく、実際の開発範囲や進め方に合わせて確認してください。

この記事のまとめ

公開後は、入力にかかる時間、問い合わせ、差し戻し、手作業が残る箇所を記録します。一度の開発で理想の形を完成させるより、最初の対象業務を安定させ、その結果を見て次の業務へ広げます。パブロフの業務アプリ開発では、要件整理から公開後の改善までご相談いただけます。相談窓口には、実データではなく、現在の仕事と困りごとの概要をお送りください。