見積管理の脱Excel・システム移行事例｜24帳票の見積もり自動化

結論は3つです。

 

1. 転記をなくす鍵は、機能ではなくデータの持ち方にある
2. 様式の分岐は、作り込まなくても項目の出し分けで再現できる
3. 最初に着手すべきは製品選びではなく、帳票パターンの棚卸しである

 

1つ目は、転記をなくす鍵が機能ではなくデータの持ち方にあることです。予定一覧と見積書を別々のファイルで管理している限り、入力画面をどれだけ使いやすくしても転記はなくなりません。今回は、提出先・件名・見積日・納期・明細といった共通の情報を上流から下流へ自動で受け渡す設計にし、打ち直す工程そのものをなくしました。

 

2つ目は、様式の分岐が、個別に作り込まなくても項目の出し分けで再現できることです。今回は見積書・注文書・注文請書の3種類が、直販か特約店か、新規か更新か、割引の有無で分かれ、全24通りありました。これらは帳票テンプレートの設計と、どの項目を表示して隠すかという制御だけで組み立てています。

 

3つ目は、最初に着手すべき作業が製品選びではなく帳票パターンの棚卸しだということです。ここが決まらないまま設計に入ると、途中で何度も前の工程に戻ります。

 

この進め方には、向いている業務と向いていない業務があります。

 

向いている業務：

・帳票のパターンが数十通り以内で、レイアウトの型は共通していること。

・明細の行数が案件によって大きく変わらないこと（今回は9行で固定）。

・承認が1〜2段階で済むこと。

・参照するマスタが1本で、拠点ごとの違いがないこと。

 

向いていない業務：

・明細の行数が案件ごとに数十行まで変わること。

・帳票のレイアウトそのものが取引先ごとに異なること。

・基幹システムとリアルタイムで双方向にデータをやり取りする必要があること。

 

 

---

この記事で扱う範囲と扱わない範囲扱う範囲

見積管理という1つの業務を対象に、帳票パターンの棚卸しからデータ構造の設計、マスタ項目の決め方、断念した設計判断までを、実際の要件定義・基本設計の内容から記録します。

 

扱わない範囲

次のテーマはそれぞれ独立した記事にまとめていますので、本記事では深追いせず、該当記事へご案内します。

 

・Excelそのものの限界とマクロの属人化

　→ エクセルマクロはもう限界？

・「最新版はどれか」というファイル版管理のルールづくり

　→ Excelファイルのバージョン管理トラブルと解決策

・Excelを入力画面として残す「活Excel」という選択肢

　→ 「脱Excel」はなぜ失敗するのか

・マスタの一元化と表記ゆれ・二重管理の解消

　→ マスタデータ管理（MDM）とは？

・承認ルートの型と分岐の設計論

　→ 承認ルート設計の実務ガイド

・要件定義書そのものの書き方と項目

　→ 要件定義書の必要項目と書き方

---

 

ここでは、Excel全般の限界ではなく見積業務に特有の状況に絞ります。自社に当てはまるものがないか確かめながらお読みください。

見積管理をエクセルで回している組織に共通する3つの状況

1. 予定一覧と見積書のあいだに転記が残っている
2. どの様式を使うかを担当者が記憶で判断している
3. 更新期日に関して一覧表を目視で追っている

 

1つ目は、予定一覧と見積書のあいだに転記が残っていることです。一覧に入力した提出先や件名や納期を、見積書を作る段階で打ち直します。この工程がある限り、件数が増えるほど取り違えのリスクも作業の滞留も大きくなります。

今回も、ライセンスの価格改定で見積作成が例年より大幅に増えた時期に、営業メンバーが見積作業だけで月の稼働時間の8割を占められ、本来の営業活動に稼働を割けなくなるところまで転記の工程がボトルネックとして表面化しました。契約更新の見積は期日が動かせず緊急性が高いため、結局は営業の稼働を削って作業時間を捻出するしかありませんでした。

 

2つ目は、どの様式を使うのかを担当者が記憶で判断していることです。判断の基準をまとめた資料はなく、本人の頭の中にしかありません。そのため担当者が休むと、どの帳票をどのシートで作るのかを誰も判断できず、見積の発行が止まります。

 

3つ目は、更新の期日を目視で追っていることです。ライセンス更新のように期日が決まっている案件では、契約終了日の90日前・60日前・31日前といった節目を一覧表で自分で確認する運用になりがちです。見落とせばそれまでで、提示が期日ぎりぎりになる案件が出てきます。

この3つはいずれも、Excelの性能ではなく見積業務のデータの持ち方が原因です。

24通りの様式が担当者の記憶に残り続ける構造

様式の分岐は、誰かが意図して増やしているわけではありません。新しい取引形態が出たのでシートを1枚足す。割引の案件のために少し違うテンプレートを作る。1回ごとの判断は理にかなっていますが、積み重なると全体像を把握している人がいなくなります。

 

問題は、増えていく過程で「これが正しい一覧です」と言える資料が作られないことです。分岐は現場で1件ずつ生まれるため、一覧にまとめる動機が生まれません。その結果、判断は毎回担当者の頭の中で行われ、どこにも記録されません。属人化は、情報を抱え込むから起きるのではなく、判断を記録する場所が業務にないから起きます。

 

なお、この業務の承認は「起案（決裁）」と「押印」の2段階に分かれ、原価が100万円を超えるかどうかで回覧先（承認ルート）が変わる設計です。承認そのものより、そこに至るまでの転記と様式選択のほうが工程を滞らせています。

 

ここからが本題です。製品を選ぶ前の作業として、帳票パターンの棚卸しを手順に落とします。要件定義書の書き方は別記事で解説しているため、帳票の分岐だけを扱います。

分岐軸を4つに分解して帳票パターンの総数を確定する

「様式がたくさんある」という認識のままでは設計に入れません。何によって分かれているのかを軸に分解します。今回は次の4軸でした。

 

1. 帳票種別：見積書・注文書・注文請書の3種類
2. 販路：直販か特約店かの2区分
3. 案件区分：新規か更新かの2区分
4. 割引：割引があるかないかの2区分

 

帳票種別3に販路2と案件区分2を掛けて12通り。これに割引の有無を掛けて全24通りです。このように数えられる形に分解すると、この業務は「様式が無数にある」状態から「24件のリスト」に変わります。設計の見通しも工数の見積もりも、ここから先は具体的に進められます。

 

軸を立てるコツは、レイアウトが変わる要因と、入る値だけが変わる要因を混ぜないことです。前者は分岐の軸、後者は項目として扱います。混ぜるとパターン数が実際より多く見えてしまいます。

現物のテンプレートから差分表を作る手順とチェックリスト

軸が決まったら、実際のファイルを開いて違いを書き出します。ここで多くの現場がぶつかるのは、「これが正しいテンプレートの一覧です」と言える資料が存在しないという事実です。今回も、1つずつ開いて書き出す以外に方法はありませんでした。

 

書き出した内容は次の5列の表にまとめると、そのまま設計までつなげられます。

 

1. 分岐軸：どのパターンにあたるか
2. 表示する項目
3. 表示しない項目
4. 文言の差：宛名の敬称、注記文など
5. レイアウトの差：欄の位置、行数、押印欄の有無など

 

着手前に、以下の2つのチェックリストで自社の業務要件とシステム選定の観点を整理しておくと、その後の設計がスムーズになります。

 

検討チェックリスト

□取引先、仕入先とのデータ授受が必要か？

□自社内で営業や経理等の役割が分担されているか？

□承認フローが必要か？

□商品マスタや取引先マスタ等の自社独自のマスタ管理が必要か？

□管理番号を採番するか？

□帳票作成には計算式が必要か？

□取引先/仕入先と帳票のデータ授受を行うか？

□システム内/外でデータ連携が必要か？

 

システム選定のポイント

□スモールスタートができるか？

□ユーザ課金かトランザクション課金か？

□プラグイン必須で高額にならないか？

□カスタマイズが必須か？

□データ連携はルックアップ機能になっていないか？

□取引先、仕入れ先とのデータ授受は可能か？

□システム内、システム間のデータ連携できるAPI機能があるか？

 

今回も、24通りの棚卸しと差分定義には相応の時間がかかりました。ここは短縮せず、最初から時間を確保すべき工程です。

項目の桁数と値域を過去データから決めておく

もうひとつ、着手前にやると後が楽なのが、項目の桁数と入りうる値の範囲を実データから決めておくことです。

 

今回は、項目名35文字、提出先20文字、エンドユーザまたは部署名15文字、数量0から100、金額0から10,000,000という範囲で設計しました。特徴的なのは保守IDで、1件で最大5,000文字まで入ります。こうした事情は過去のデータを見ないと上限が分かりません。

 

桁数を後から広げると、帳票レイアウトの作り直しがついてきます。今のExcelに入っている文字数や金額の上限を、着手前に実データで測っておくことをお勧めします。

 

要件定義書の書き方、未決事項の扱い、非機能要件の記述については、要件定義書の必要項目と書き方で詳しく解説しています。

 

---

見積管理の棚卸しから始めたい方へ

見積管理をはじめとする部門固有の業務を、個別開発なしでどう組み立てるのか。本記事の設計の元になった機能と構成を、資料にまとめています。着手前の検討材料としてご覧ください。

 

---

 

見積もりの自動化というと入力作業の自動化を思い浮かべがちですが、実際に効くのはデータの持ち方です。設計の中身を、できたこととできなかったことの両方から見ていきます。

見積予定と見積書を1つのデータ構造で持つと転記は消える

今回は、データを3つの層に分けています。案件の予定を管理する「見積予定一覧」、見積書の内容を持つ「見積」、発行済みを管理する「見積書管理」です。上流に入力した提出先・件名・見積日・納期・明細は下流の見積へ自動で受け渡されるため、見積書を作る段階で同じ情報を打ち直す必要がありません。

 

設計上のポイントは、データを受け渡す条件を担当者から見える項目にしたことです。「見積へ登録済みか」「見積書管理へ登録済みか」の2項目を置き、どの状態で次の層へ流すのかを画面上で確認できます。裏側で勝手に動く仕組みにしなかったため、案件の進み具合が一覧で分かります。

入力を減らす4つの参照方式の使い分け

転記をなくしたうえで入力そのものを減らす仕組みが4種類あります。

 

1. マスタ参照

あらかじめ登録した一覧から選ぶ方式です。品目を選ぶだけで項目名が入り、手入力が不要になります。

 

マスタ設定内容

 

入力時はマスタから選択

 

マスタから標準単価がセットされ、数量入力後に標準金額に自動入力

 

 

2. マスタ参照（オートコンプリート）

1つ選ぶと関連項目がまとめて埋まる方式です。拠点を東京か大阪か選ぶだけで、郵便番号・住所・電話・FAX・部署名が自動で入り、書き間違いもなくなります。

 

マスタ設定内容

 

入力時はマスタから選択

 

オートコンプリートで住所などの情報が自動入力

 

 

3. ディクショナリ参照

あらかじめ決めた選択肢から選ぶ方式です。件名を「新規」「更新」「数量倍増」「数量削減」の4区分から選ぶ形にしました。当初は自由入力でしたが、区分ごとに集計できるよう変更しています。

 

マスタ設定内容

 

入力時はマスタから選択

 

 

4. 自動採番

登録すると番号が自動で振られる方式です。販売管理簿管理No、見積No、見積書管理Noに適用しました。番号の重複や抜けがなくなり、案件を番号1つで追えます。

 

新規登録時は見積書管理No.が自動採番

 

この4つは、担当者が覚えていることをシステムが持つ状態に移す仕組みです。属人化の解消とは、つまりこの移し替えのことです。

 

---

マスタを1本に寄せる考え方そのものについては、マスタデータ管理（MDM）とは？を参照してください。本記事では、見積業務で実際に持たせたマスタの中身に絞ります。

---

 

実際のマスタ項目例と、決めておくべき型と桁数

マスタと3つの層の関係、項目の決め方は次のとおりです。

 

 

表1 マスタ項目例

分類	名称	代表項目	項目タイプ	桁数・値域
カスタムマスタ	SA_項目マスタ	項目名	文字列	40桁
		標準単価／原価	整数	―
カスタムマスタ	SA_拠点情報マスタ	拠点（東京／大阪）	文字列	3桁
		郵便番号	文字列	9桁
		住所	文字列	40桁
		電話／FAX	文字列	各15桁
		部署名	文字列	30桁
ディクショナリ	SA_件名	新規／更新／数量倍増／数量削減	ディクショナリ	4区分
トラン	見積予定一覧トラン	販売管理簿管理No	自動採番	―
		直販／特約店	選択文字参照	直販;特約店
		提出先	文字列	20桁
		エンドユーザor部署名	文字列	15桁
		件名	ディクショナリ参照	SA_件名
		更新90日前／60日前／31日前	日付	―
		保守ID	文字列（複数行）	5,000桁
		項目1〜9（項目）	文字列	各35桁
		項目1〜9（数量）	整数	0〜100
		項目1〜9（標準単価・提供単価・原価）	整数	0〜10,000,000
		見積トラン登録	選択文字参照	済;未済（連携トリガー）
		備考	添付ファイル	―
トラン	SA_見積トラン	見積No	自動採番	―
		東京／大阪	ユニークキー	SA_拠点情報マスタ
		郵便番号・住所・電話・FAX・部署名	オートコンプリート	SA_拠点情報マスタ
		小計・合計（標準金額／提供金額）	整数	直入力（「¥0」表記回避）
		帳票作成	選択文字参照	未作成;作成;作成済
トラン	SA_見積書管理トラン	見積書管理No	自動採番	―
		見積書添付	ファイル	―

出典：SaaS販売BO業務_見積管理 要件定義・基本設計書より抜粋

 

見ていただきたいのは項目の数ではなく決め方の細かさです。「金額を持つ」ではなく「0から10,000,000の整数で円記号あり、3桁区切りあり」まで決める。「件名を持つ」ではなく「4区分から選ぶ形式」まで決める。ここまで要件を具体化しておけば、24パターンの複雑な出力もシステムの設定のみで対応可能です。しかし要件が曖昧なままだと、最終的に個別での追加開発が発生するか、Excelを使った手作業での修正作業に戻ってしまいます。

 

実際に運用している帳票のレイアウトは次のとおりです。

 

 

 

データを次の層へ受け渡す仕組みは、データフロー機能で解説しています。

ここは稟議や社内説明に直結します。今回の事例で何を検討し、何を理由に見送ったのかを記録します。

却下理由を費用と期間と機能範囲の3軸で書き分ける

稟議で必ず問われるのは「なぜそれを選ぶのか」ではなく「なぜ他ではないのか」です。実際に行った対応が1つと、同種の業務でよく比較される選択肢が6つあります。

 

1. 他部門からの応援による一時的な増員（実際に行った対応）

繁忙期はメンバーを増やしてしのぎましたが、これは一時的な対応にとどまり、応援が終われば元の体制に戻ります。どの様式を使うかの判断は依然として担当者の記憶に残ったままで、引き継ぎも完全にはできていません。属人化そのものは解消しませんでした。

 

2. 基幹システムの改修（比較されやすい選択肢）

一般に、帳票パターンが多いほど改修の費用と期間は膨らみやすく、見送られやすい選択肢です。

 

3. CRMの見積機能（比較されやすい選択肢）

原価や利益率まで管理する設計になりやすく、営業支援機能としては過剰になりがちです。商談の管理は既存のまま残す前提で考えます。

 

4. ExcelのVBAやAccessによる内製（比較されやすい選択肢）

属人化を別の属人化に置き換えるだけになりやすく、保守できる人が1名に集中する構造は変わりません。

 

5. RPAによるExcel操作の自動化（比較されやすい選択肢）

転記そのものは自動化できても、様式の選択や証跡管理までを担わせる作り込みは難易度が上がります。

 

6. BPO（業務の外部委託）（比較されやすい選択肢）

単価や原価など社外に出しにくい情報を含む業務では、対象にしにくい選択肢です。

 

7. 現状維持（比較されやすい選択肢）

更新期日の管理漏れと転記ミスのリスクを抱えたままになります。

コツは、実際に行った対応の限界も、比較されやすい選択肢を見送る理由も、費用・期間・機能範囲のいずれかに紐づけて書くことです。「合わなかった」ではなく「この機能がこの範囲まで必要で、満たすには費用と期間がこれだけかかるため」と書けば、決裁者が判断できる材料になります。

既製の見積管理システムやアプリで足りるのはどんな場合か

既製の見積管理システムやアプリで十分なケースもあります。

 

1. 帳票の様式が1〜2種類で、取引先ごとの差が宛名と明細に収まる場合
2. 承認が1段階で、証跡もメールで足りている場合
3. 原価や利益率を見積段階では管理せず、売上金額だけを扱えばよい場合
4. 案件の検索が発行月と取引先名でできれば足りる場合

 

これらに当てはまるなら、既製品を検討したほうが早く費用も抑えられます。

しかし、「入力フォーマットの条件分岐が何十通りもある」「見積もりの段階で原価から利益まできっちり管理したい」「部署ごとに独自の期限管理がある」といった場合は、市販ソフトの標準機能では対応しきれません。

 

そのようなとき、基幹システムを大がかりに改修する前に、「今の業務にピッタリ合わせた仕組みを専用で作る」という選択肢が考えられます。

 

製品ごとの比較軸と選定の進め方は、見積管理システムの導入で承認フロー高速化と利益率向上へにまとめています。

 

ノーコードで内製する場合の体制づくりは、ノーコードアプリ開発で業務システムを内製化する実践ガイドを参照してください。

社内で挙がった懸念にどう答えたか

社内で次のような懸念の声が出ました。

 

Excelで作っている見積書と同じものを、本当にシステムから出せるのか？

この懸念には、24通りの棚卸しと差分定義の結果を見せて対応しました。最初の工程を丁寧にやることが一番重要なポイントです。

 

使いやすいのか？

この懸念には、マスタ参照とオートコンプリートで入力そのものを減らした設計を、実際の画面で見せながら説明しました。

 

かえって手間が増えるのでは？

この懸念には、増える項目よりなくなる転記の工程のほうが大きいことを、実際の作業時間を示しながら説明しました。

 

懸念に対して「やってみれば分かる」と答えずに、根拠や実際の画面を見せながら説明すると効果的です。

今回の事例はソフトウェアの販売チームですが、業務の型は製造業や商社の営業管理部門と重なります。営業部門とBO部門で見積管理にあたる担当者の言葉を、検証時点でのヒアリング内容のままご紹介します。実際にやってみて苦労したことです。

 

---

「Slopebase側に要件を伝えて、製品の仕様を理解しながらすり合わせていく作業には苦労しました。Excelにはなかったデータの型を1つずつ定義する必要があり、手間はかかりましたが、やった後はデータ入力が厳格化できたのは良かったです。」

---

検証時点での実感です。

 

---

「Slopebaseの構築はまだ途中ですが、メンバーの一部引き継ぎが進み、営業に稼働を割けるようになり始めている」といいます。運用が本格的に始まれば、さらに時間の余裕が生まれると見ています。

---

今回スコープ外とした機能は5つです。CRMとのシステム連携、更新期日の自動通知、Web請求とWeb受領、基幹への売上連携、注文書と注文請書の承認ワークフロー化。いずれも「PDFの出力まで」と最初に線を引いた結果です。次のステップとして、見積の起案（稟議）をあげるところまでの自動化に取り組む予定だといいます。

 

---

「いきなり構築へ進むのではなく、事前にデモ（PoC）でSlopebaseの機能やイメージをつかんでおき、そのうえで要件を詰めていくほうが現実的です」というのが、同じ課題を抱える現場への助言です。

---

 

同社の他部門における導入事例をはじめ、様々な業種・規模の事例は、導入事例一覧でご覧いただけます。

 

段階的に導入を進める方法そのものは、バックオフィスDX「スモールスタート×アジャイル」導入ガイドにまとめています。

 

---

自社の業務で同じ形が成立するかを確かめる

本記事の設計は、製品を選ぶ前に帳票の分岐と項目を棚卸しするところから始まっています。同じ手順を自社の業務に当てはめ、「載る条件」に収まるかどうかを一緒に確認するところからご相談いただけます。ご用意いただくのは、現在お使いのExcelと帳票のサンプルだけで構いません。

 

---

 

Q1 見積管理はエクセルのままでも運用できるのに、なぜデータ構造から作り直す必要があるのですか?

A.一覧表と見積書のあいだに転記が残る限り、取り違えを構造的に防ぐ手段がないためです。チェックを二重にしても人の注意力に頼る対策であり、繁忙期に最初に崩れます。今回はデータの持ち方を変え、転記の工程そのものをなくしました。なお、Excelを入力画面として残し裏側だけをシステム化する「活Excel」という別の解もあります。

 

Q2 帳票の様式が20通り以上あっても、個別開発なしで本当に再現できますか

A.分岐が項目の出し分けと表示の有無に収まるなら再現できます。今回の24通りは、帳票テンプレートの設計と表示項目の制御で組み立てました。一方、レイアウトそのものが取引先ごとに異なる場合や明細行数が数十行まで変わる場合は収まりません。判定は、分岐軸を立てて差分表を作れば着手前に付きます。

 

Q3 単価の改定やマスタの追加は、情シスに依頼しないと直せませんか

A.今回は、品目マスタの単価改定などの保守を、Slopebase側のCS担当1名と、営業部門・BO部門それぞれ1名の担当が確認しながら進める体制です。マスタ参照とディクショナリ参照で持たせた項目は、エンジニアでなくても画面から操作できる設計ですが、自社の担当者だけで完全に自走できるかは検証時点ではまだ見極めがついていません。社内に情報システム部門はなく、保守は営業部門・BO部門の実務担当が兼務で担う想定のため、不在時や退職時の代替も含めた体制づくりが、本番移行前の課題として残っています。

 

Q4 見積書をPDFでメール送付する運用に、法令上の注意点はありますか

A.見積書・注文書・注文請書は国税関係書類にあたり、原則7年間の保存が必要です。またPDFをメールで授受する形は電子帳簿保存法上の電子取引に該当し、保存要件と検索要件への対応が必要です。詳細は国税庁の公表資料をご確認のうえ、個別の判断は所轄税務署または専門家にご相談ください。

見積管理の脱Excelで最初に着手すべきは、製品選びではなく帳票パターンの棚卸しです。

 

分岐の軸を立てて総数を確定し、実際のファイルから差分表を作ります。転記をなくす鍵はデータの持ち方にあり、見積の予定と見積書を1つの流れで持てば打ち直す工程が消えます。自動化できない箇所は隠さず、いつ、なぜそう決めたのかを設計書に残します。自社に向いているかは、帳票の分岐数・明細の行数・承認の段数・マスタの持ち方の4つで判定できます。

 

---

見積管理の業務構築について、資料と個別相談をご用意しています

本記事で紹介した業務概要・業務フロー・業務ポイント・マスタ設計は、実際の要件定義と基本設計の内容にもとづくものです。同じ形式で自社の業務を設計するとどうなるのか、資料でご確認いただくか、個別にご相談いただけます。現状のExcel運用の整理からご一緒します。

 

 

---