業務ツールが完成しても、現場で使えない5つの理由

「依頼した業務ツールは完成した。動作確認も終わった。それなのに、現場では使われていない」

こうした状況で、最初に疑うべきなのはプログラムの出来だけではありません。開発者の手元で正しく動くことと、担当者が毎日の仕事で問題なく使えることは、確認すべき内容が違うからです。

私が業務ツールの設計で重視したいのは、何ができるかだけでなく、誰が・どの環境で・どのデータを使い・失敗したときにどう戻せるかという点です。この記事では、完成したツールが現場で止まる典型的な5つの理由と、依頼前・納品前に確認したい事項を整理します。

例：請求書を自動作成するツールが、現場では止まる

架空の例として、売上データのCSV（シーエスブイ）ファイルを読み込み、請求書のPDF（ピーディーエフ）を一括作成するツールを考えます。

開発時のサンプルは、列名が「取引先コード」「金額」「請求日」で統一され、保存先のフォルダーも決まっています。この条件なら、ファイルを選び、実行ボタンを押すだけで請求書を作成できます。

ところが、現場では別部署から届いたファイルに「得意先コード」という列があり、請求日が空欄の行も混ざっています。保存先は担当者に書き込み権限のない共有フォルダー。しかも、請求書の作成途中で処理が止まると、どの取引先まで作成済みなのか分かりません。

サンプルどおりに動くツールでも、この状態では安心して本番業務に使えません。 問題は一つではなく、入力データ、利用環境、例外、運用手順が重なっています。

理由1：実際の入力データが、開発時のサンプルと違う

CSVの列名が少し変わる、空欄が混ざる、同じ取引先が重複する。人が目で確認していた作業には、こうした小さな揺れが付きものです。

例えば、ツールが「取引先コード」という列を必須としている場合、「得意先コード」という列しかないファイルは読み込めないかもしれません。処理の途中で止まるのか、事前に分かりやすいエラーを出すのかで、現場の負担は変わります。

対策は、サンプルを1ファイル渡して終わらせないことです。通常月のファイルに加え、空欄、重複、列名変更、0件などのパターンを確認し、許容する違いと、処理を止める条件を決めます。

理由2：担当者のパソコンでは実行できない

開発者のパソコンには必要なソフトが入っていても、会社のパソコンでは新しいアプリの実行やインストールが制限されている場合があります。

たとえば、Windows（ウィンドウズ）の実行ファイルでは、署名やアプリの信頼性によって警告・実行制限がかかることがあります。また、Excel（エクセル）のVBA（ブイビーエー）マクロは、ファイルの入手元や組織の設定によって実行がブロックされることがあります。

ここで、担当者にセキュリティ設定を一律に解除してもらうのは適切ではありません。社内の管理者に確認し、許可された方法で配布・実行できる設計にする必要があります。

加えて、利用者の権限で共有フォルダーへ保存できるか、社内ネットワークにつながるか、必要なソフトのバージョンが合うかも、実際の利用端末で確認したい項目です。

理由3：人が判断していた例外処理が、仕様に入っていない

業務の説明では「CSVを読み込んで請求書を出す」と一言で済みます。しかし実務では、返品によるマイナス計上、締日が異なる取引先、請求対象外の取引など、例外が存在します。

これまで担当者が見て判断していたものを、ツールが勝手に処理すると誤請求につながる可能性があります。だからといって、例外の全てを自動化する必要もありません。

例えば、通常データは自動処理し、例外データは「確認が必要な一覧」に分ける方法があります。自動化する範囲と、人が判断を残す範囲を分けるほうが、安全で扱いやすい設計になる場合があります。

理由4：操作の担当者と、日常の運用が決まっていない

「誰でも使える画面」を作っても、実行するタイミングや作成後の確認方法が決まっていなければ、仕事には組み込めません。

例えば請求書作成なら、どのフォルダーに当月のCSVを置くのか、誰が実行するのか、作成結果を誰が確認するのか、先月分をどう保管するのかが必要です。複数人で使う場合は、同じファイルを同時に処理したときの挙動も考えなければなりません。

操作マニュアルを数ページ増やすことが解決とは限りません。ファイル選択、実行、結果確認の3操作にまとめるなど、今の業務フローに無理なく入る構成にすることが重要です。

理由5：失敗した後の復旧方法が用意されていない

正常終了だけを確認したツールは、途中停止した際の扱いが不明になりがちです。処理が50件中30件で止まった場合、最初からやり直してよいのか。30件分は上書きされるのか。二重に請求書が作られないのか。

請求書を例にすると、ファイル名の重複を検出する、処理済みの一覧を残す、保存が完了してから処理済みと記録する、といった設計が考えられます。ただし、実際にどの方式が適切かは、業務とデータの管理方法によります。

最低限、エラーの内容、処理済み件数、再実行の手順、問い合わせ先を決めておくと、担当者は止まったときにも判断しやすくなります。

「完成」と「現場で使える」は、3段階で確認する

私は、納品前の確認を大きく3段階に分けて考えるのが分かりやすいと思います。

第1段階：機能の動作確認。 正しい形式のデータで、合意した結果が得られるか。空欄や不正な値で想定どおりのエラーになるか。

第2段階：現場での受入確認。 実際に使う担当者のパソコン、利用者権限、共有フォルダー、実際に近いデータで一連の作業を実行できるか。

第3段階：運用確認。 処理途中で止めた場合、担当者が不在の場合、翌月にファイル形式が変わった場合などに、誰がどう対処するか。

なお、全ての小規模ツールで大規模システム並みの試験が必要なわけではありません。個人だけが使う単純な変換ツールと、複数人が扱う請求業務のツールでは、失敗時の影響が違います。テスト範囲は、業務上のリスクに合わせて決めます。

依頼する前に伝えると、すれ違いが減る情報

完璧な仕様書はなくても構いません。少なくとも、次の内容が分かると設計の判断がしやすくなります。

・ 誰が使うか： 1人か複数人か。一般社員の権限で動かすのか。

・ どこで使うか： OS（オーエス）、Excelの有無、社内の実行制限、共有フォルダーの利用状況。

・ 何を入れるか： CSV・Excelなどの形式、列名、よくある空欄や例外。

・ 何を出したいか： 出力形式、ファイル名、保存先、確認方法。

・ 止まったらどうするか： 再実行、上書き、処理済みデータの扱い。

サンプルデータは、個人情報・機密情報を除いたものから準備すると相談しやすくなります。パスワードや認証情報を送る必要はありません。

依頼前に決めたいのは、機能の数より「合格条件」

「請求書を自動作成できるツール」という依頼に、「指定したCSVを選び、一般社員の権限で実行し、エラー行は一覧表示する。作成済みの請求書は再実行で重複させない」という条件を加えると、必要な開発内容と確認範囲が具体的になります。

もちろん、条件が増えれば設計・実装・テストの工数も変わります。一方、担当者が1人で使う簡単な集計ツールなら、そこまで複雑な仕組みは不要かもしれません。

ツールを作ること自体が目的ではありません。毎日の業務を、担当者が迷わず、無理なく、止めずに進められる状態にすることが目的です。

業務ツールの制作を検討する場合は、ココナラ内の出品サービスやプロフィールから、現在の作業手順と利用環境を添えてご相談いただけます。完成後の使い方まで含めて、どこを仕様に入れるべきか整理することが大切です。