【導入事例】販売管理システムを、Webアプリで構築するか kintone で組むか。2つの構成案のメリット・デメリットを比べて提案したサービス業G社の検討の裏側
見積から請求、会計ソフトへの連携、レポートまでの販売管理を、表計算のファイルなどから一つの仕組みに移したいと考えていたサービス業G社。当社は、kintone で組む案と、当社が社内で使っている業務システムの土台を流用して Webアプリで構築する案を並べ、費用の形、権限と承認、会計ソフトとのつなぎ方、運用の持ち方などのメリット・デメリットを比べて提案しました。仕組みはまだ稼働していない、検討の段階の事例です。
本事例は、当社が実際にお出しした提案をもとに構成しています。企業名と、お客様の環境にある製品の名前は伏せ、業種・規模・時期は一般化して記載しています。仕組みはまだ稼働していないため、結果ではなく、並べた2つの構成案と、比べた点を紹介します。販売管理の仕組みを Webアプリで構築するか kintone® で組むかを検討する際の参考にしていただければ幸いです。
業種：サービス業
ご相談：見積から請求、会計ソフトへの連携、レポートまでの販売管理を、表計算のファイルなどから一つの仕組みに移したい
段階：2つの構成案を並べて提案し、お客様が比べて決める段階（仕組みはまだ稼働していない）
提案した構成：kintone で組む案（標準の機能、帳票とメールのプラグイン、会計ソフトとの API 連携）と、Webアプリで構築する案（当社が社内で使っている業務システムの土台を流用）
見積から請求・集計までが、道具ごとに分かれていた
G社は、見積・受注・請求・仕入・集計を、いくつもの道具に分けて回していました。見積は表計算のファイルで作り、承認は紙と、それとは別の申請で回します。受注と請求は別の仕組みに入力し直し、売上は会計ソフトにファイルで取り込み、入金の状況は担当者どうしの連絡で共有していました。レポートは、月の締めを待ってから、データを取り出して加工していました。
困っていたのは、同じ内容を何度も入力すること、承認が二度に分かれて待ちが出ること、仕入先からの請求書が届いたかを追いにくいこと、締めを待たないと担当者ごとの数字が見えないことです。見積の段階で売上・仕入・粗利を見て承認したい、見積から請求書や売上の記録を作りたい、部門ごとに見せる範囲を分けたい、といった要望も受けていました。
見積と承認：表計算のファイルで作り、紙と別の申請で承認
受注と請求：別の仕組みに入力し直す
会計と入金：売上はファイルで取り込み、入金の状況は担当者どうしで共有
集計：月の締めのあとに、データを取り出して加工
同じ業務の範囲を、2つの作り方で組んだ
当社は、同じ業務の範囲を2つの作り方で組んだ案を並べました。どちらの案も、取引先・仕入先・品目・部門と社員の台帳、案件・見積・受注と売上・請求・発注と仕入の記録、予算の10の業務の単位で作り、見積から承認、帳票と送付、受注と請求、会計ソフト、レポートへとつなぎます。
2つの案に共通する業務の流れ
入金の消し込み、支払いの申請、経費精算は、どちらの案でも会計ソフトに残す
図：構成を簡略化して描いています（画面や実際のデータではありません）。
一つめは、kintone の標準の機能で組む案です。見積の明細は表の部品に入れて粗利を計算し、承認はプロセス管理、見積から受注への引き継ぎはアプリアクションで作ります。kintone の標準の印刷は、帳票のレイアウトを変えられません。そのため、見積書・請求書の PDF と取引先へのメールはプラグインで補い、会計ソフトとは、連携のプログラムを動かす中間のサーバーを置いて API でつなぎます。プラグインや API での連携を使うには、kintone のスタンダードコース以上が要ります。
二つめは、当社が社内で使っている業務システムの土台を流用して、お客様専用の Webアプリとして構築する案です。顧客・案件・請求・予実の部品は今あるものを使い、見積（明細・仕入・粗利）と受注・売上（計上する月ごと）を新しく作ります。業務ごとのアプリを一覧から開く画面、案件の一覧の表示の切り替え、コメントと変更の履歴、アプリをまたいだ集計の画面も、今ある部品を使えます。会計ソフトとは、システムのサーバーから直接つなぎます。
2つの構成案の組み立て
案1
kintone で組む
- 10の業務の単位を kintone のアプリで作る
- 帳票とメールはプラグインで補う
- 会計ソフトとは中間のサーバーを通して API でつなぐ
- 動かす環境はサイボウズのクラウドサービス
費用の形：作る作業に加え、kintone とプラグインの利用料、中間のサーバーの費用、保守
案2
Webアプリで構築する
- 当社が社内で使っている業務システムの土台を流用
- 見積と受注・売上を新しく作る
- 会計ソフトとはシステムのサーバーから直接つなぐ
- お客様専用の環境を当社が運用する
費用の形：作る作業に加え、小さな修正を含む月々の保守と、サーバーの費用
業務の単位と、稼働までの工程の骨組みは、どちらの案も同じ
図：構成を簡略化して描いています（画面や実際のデータではありません）。
2つの案のメリット・デメリット
2つの案を、次の点で比べました。費用は、金額ではなく形で比べています。
| 比べる所 | kintone で組む案 | Webアプリで構築する案 |
|---|---|---|
| 費用の形 | 初期は作る作業。月々は kintone とプラグインの利用料、中間のサーバーの費用、保守 | 初期は作る作業。月々は小さな修正を含む保守と、サーバーの費用 |
| 人数と利用料 | 使う人の数に応じて kintone の利用料が増える | 人数に応じた利用料は見積もりに入れていない |
| 画面 | 標準の画面の形の中で作り、足りない所はプラグインや JavaScript で補う | 今ある部品を使い、足りない画面は作る。自由に作れる分、作る費用と手入れがかかる |
| 権限と承認 | アプリ・レコード・フィールドの3つの段で権限を設定できる。ただし表の部品の中の項目には設定できない。金額などで承認の経路を分けるのは標準の設定で、変更の履歴も残る | 同じ3つの段で権限を持つ。状態の移り変わりをすべて記録に残す。金額で承認の経路を分ける仕組みは無く、要るなら新しく作る |
| 会計との連携 | 中間のサーバーを置いて API でつなぎ、その月々の費用がかかる | システムのサーバーから直接つなぐ。入金の状況と取引先の取り込みは今ある仕組みを使い、売上の登録は新しく作る |
| 集計 | グラフや集計表は、そのアプリのレコードを集計する | アプリをまたいだ集計のレポートと、ダッシュボードがある |
| 運用 | 動かす環境はサイボウズのクラウドサービス。レコードの控えはアプリごとに書き出す | 専用の環境の監視、障害への対応、復元の演習を当社が受け持つ |
| 直せる人 | アプリは画面の設定で作れ、社内でも直せる。JavaScript の部分は書いた人か引き継いだ人 | 開発する側が直す。生成AIを使った開発の道具と組み合わせて改修を進める |
| 補助金 | IT導入支援事業者が登録した ITツールとして申請できる形なら使える | この提案では、補助金を使わない前提 |
| 稼働までの工程 | 要件定義・基本設計、構築、受入テストと研修、並行稼働 | 同じ工程に、専用の環境の試作と、提供の条件・運用の受け入れの確認が加わる |
kintone の案から考えたいのは、使う人の数がそれほど多くなく、承認や権限の決まりを kintone の標準の設定で表せて、作った後に社内の人が設定を直していきたい会社です。仕組みを動かす環境の監視やバックアップを自社で持たずに済み、補助金を使える形も探せます。Webアプリの案から考えたいのは、使う人が多く人数に応じた利用料が重くなる会社、画面や承認・記録の決まりを細かく作り込みたい会社、アプリをまたいだ集計を画面で見たい会社、会計ソフトとの連携を中間のサーバーなしでつなぎたい会社です。その代わり、専用の環境の運用と、作った後の改修は、作った会社に任せることになります。
提案で決めたこと
kintone の案の見積もりは、4つに分けました。販売管理として一般的に要る機能の「基本要件」、要件の資料と見積書の見本から分かる、その会社に固有の機能の「追加要件」、会計ソフトとの API 連携や入金の状況の取り込み、並行稼働と切り替えの支援のように、こちらから勧めた「追加提案」、要件定義・基本設計、進行の管理、テストの支援、マニュアルと研修の「共通作業」です。どこがその会社に固有で、どこを外せるかを、受け取った側が見分けられるようにするためです。今の仕組みからのデータの移し替えと、kintone・会計ソフトの利用料は、含めないと書きました。
見積もりの分け方
最初から要るもの
基本要件
- 販売管理として一般的に要る機能
その会社に固有のもの
追加要件
- 要件の資料と見積書の見本から分かる機能
こちらから勧めたもの
追加提案
- 会計ソフトとの API 連携や並行稼働の支援など。外せる
全体に掛かるもの
共通作業
- 要件定義・基本設計、テストの支援、研修など
図：提案の見積もりの分け方を簡略化して描いています（金額は載せていません）。
期も分けました。第一期は、見積から請求・仕入までの日々の業務と、取引先ごと・担当者ごとの売上の表です。前年比や、予算と実績の差のような分析は、第二期に回しました。前の期のデータの取り込みと、予算を何の単位で持つかが決まってからでないと作れないためです。
補助金（デジタル化・AI導入補助金）を使う場合に備えて、使うときの順番も提案に書きました。事務局の公募要領では、IT導入支援事業者が事前に登録した ITツールを選び、その事業者と一緒に申請します。交付決定より前に契約・発注したものは補助の対象にならず、交付決定のあとに契約・発注、導入、支払いを済ませて実績を報告し、補助金は報告のあとに交付されます。そこで、交付決定の前に始めたい要件定義と基本設計は、申請に含めない別の契約にし、補助の対象は第一期の構築にする組み方にしました。稼働の日と当社の作業の範囲は、補助金を使うかどうかで変えていません。
補助金を使うときの順番
図：事務局の公募要領と手続きの案内をもとに、順番を簡略化して描いています。
いまの段階
この事例は、まだ提案と検討の段階です。仕組みは稼働しておらず、どちらの案で進めるかも決まっていません。当社は、お客様が費用の形や運用の持ち方を比べて決められるよう、同じ業務の範囲を2つの作り方で組んだ案を並べて提案しました。これから決めていただくのは、どちらの案で進めるか、補助金を使うかどうか、要件定義をいつ始めるかです。
仕組み：まだ稼働していない
提案：kintone で組む案と、Webアプリで構築する案を並べて提案
これから：進める案、補助金を使うかどうか、要件定義を始める時期を決める
kintone を含む業務ツールでの作り方の比べ方は、業務ツール導入・活用支援のページで紹介しています。
※本事例は、当社が実際にお出しした提案をもとに構成しています。企業名と、お客様の環境にある製品の名前は伏せ、業種・規模・時期は一般化して記載しています。仕組みはまだ稼働していません。kintone は、サイボウズ株式会社の登録商標です。
