「集計するだけ」で食い違う？小さな業務ツールほど仕様確認が大切な理由

「毎月のCSVを読み込んで、売上を集計するツールが欲しい」。こんな相談は、一見すると単純です。ファイルを選ぶ、集計する、結果を保存する。画面に置くボタンは一つでも済むかもしれません。

ところが、その「集計する」の意味が、依頼する人と作る人で同じとは限りません。完成してから「キャンセル分は除いてほしかった」「毎月、列の順番が変わるんです」と分かれば、画面の作り直しがなくても処理の変更が必要になります。

小さなツールほど大切なのは、仕様書を厚くすることではなく、最初に認識の違いを見つけることです。 今回は、依頼前にどこを確認すればよいか、具体的なCSV集計を例に整理します。

「売上を合計するだけ」でも、答えが変わる

次の3行が入ったCSVを想像してください。説明のための架空データです。

・ 注文001：店舗A、10,000円、通常

・ 注文002：店舗A、3,000円、キャンセル

・ 注文001：店舗A、10,000円、通常（重複行）

単純に金額列を足せば、結果は23,000円です。しかし、キャンセルを除き、同じ注文番号を一度しか数えないルールなら、店舗Aの売上は10,000円になります。

プログラムの計算が間違っているわけではありません。何を売上として数えるかが、まだ決まっていないことが問題です。こうした違いは、ボタンを押した後ではなく、開発を始める前に確認しておく必要があります。

最初にそろえたい6つの確認項目

私は、小規模な業務ツールを考えるとき、まず「入力・処理・出力」に加えて、例外・使用環境・完成条件を分けて整理するのが有効だと考えています。

1．入力：何を受け取るのか

CSVなのかExcelなのか、どんな列名・日付形式なのか、ファイルが毎回同じ形なのかを確認します。CSVでも、文字コードや見出し行の有無が異なる場合があります。「サンプルでは動いたのに本番で動かない」を避けるには、実際に近い形式の確認が役立ちます。

2．処理：どう計算・判定するのか

今回の売上なら、税込・税抜のどちらを使うか、キャンセルを除くか、店舗別か月別か、重複注文をどう扱うかが対象です。ここは「売上を集計」とだけ書かず、具体的な3〜5行のデータと期待結果を並べてみると、認識の違いが見つかりやすくなります。

3．例外：想定外の行があったらどうするか

金額が空欄、日付が不正、列が不足、同じ注文が二重登録。こうした場合に処理を止めるのか、該当行だけ飛ばすのか、エラー一覧を出すのかで実装は変わります。特に、間違った合計を黙って出すことは避けたいところです。

4．出力：何ができれば仕事が終わるのか

画面に合計を表示するだけでよいのか、Excelファイルを保存するのか、保存先やファイル名まで決めるのか。利用者がその後に何をするかによって、必要な出力は異なります。集計結果を別の帳票へ転記するなら、最初からその形式に合わせる方が効率的なこともあります。

5．環境：誰が、どこで使うのか

一人のWindowsパソコンで動けばよいのか、複数人で使うのか。Excelマクロが使用可能か、社内のソフトウェア導入制限があるかも確認したい項目です。同じ機能でも、利用環境によって適した実装方法が変わります。

6．完成条件：何を確認したら納品とするのか

「動いたら完成」では判断が分かれます。例えば、指定したサンプルを読み込んで店舗Aが10,000円となり、重複行を記録し、指定形式で保存できること。こうして確認可能な条件にすると、依頼者も開発者も完成状態を判断しやすくなります。

小さな仕様メモの例

数ページの設計書が必要ない案件でも、次のような一枚のメモは役立ちます。これは説明用の例で、実際に納品・動作検証したツールの仕様ではありません。

・ 目的：月末の店舗別売上集計を手作業から置き換える

・ 入力：決めた列構成の sales.csv（注文ID・店舗・金額・状態）

・ 計算ルール：キャンセル行を除外。同じ注文IDは最初の1行だけ採用し、重複件数を記録する

・ 例外時：金額の空欄・不正値があれば処理を止め、該当行を知らせる

・ 出力：店舗別売上を report.xlsx に保存する

・ 完成条件：上記3行の例では店舗Aが10,000円となり、重複1件を確認できる

ここまで書けば、「想定していた機能」と「今回の開発範囲」を話し合いやすくなります。反対に、出力帳票を後からもう一種類追加したい場合は、新しい要望として費用や納期への影響を確認できます。

もちろん、実務では注文IDが一意なのか、重複時にどの行を採用するのかなどもデータの性質に合わせて調整します。このメモは完成仕様のひな型であり、あらゆる案件にそのまま使える万能なルールではありません。

「不具合の修正」と「仕様変更」を分けるためにも必要

当初「キャンセル行を除く」と合意していたのに、キャンセル行が集計されるなら、合意した仕様との不一致です。一方、当初は店舗別集計だけを決めていたところに「担当者別の一覧も作ってほしい」と追加するなら、基本的には機能追加の相談になります。

この違いを最初に整理しておくと、納品後に「どこまで直してもらえるのか」を判断しやすくなります。依頼時には、初期不具合の修正期間と、追加・変更が別見積りとなる条件も確認しておくと安心です。

仕様書がなくても、相談は始められる

依頼する側が、専門的な要件定義書を自力で作る必要はありません。むしろ、最初に役立つのは「今どんな操作をしていて、どこが面倒で、終わったときにどんな表が欲しいのか」という業務の説明です。

相談前には、現在の手順を短く書いたメモ、個人情報や機密情報を取り除いた入力サンプル、希望する出力の見本の3点があれば、検討しやすくなります。サンプルが準備できなければ、列名と数行の架空データから始める方法もあります。

一度きりの計算や既存のExcel関数で済む仕事なら、新しいツールを作らない判断も合理的です。一方、毎月同じ処理を繰り返す、例外処理が多い、複数のファイルを扱うといった場合は、業務に合った仕組みを検討する価値があります。

「小さい仕事だから説明を省く」のではなく、「小さい仕事だから決める項目を絞って明確にする」。 これが、使いやすい業務ツールを無理なく作るための出発点です。仕様がまだ固まっていない場合も、ココナラのプロフィールや関連する出品サービスから、現在の作業と希望する結果を整理するところから相談できます。