この記事でわかること
「営業は前向きだが経理が止める」「情シスからリスク整理を求められた」——BtoB-EC導入の可否を実質的に左右するのは管理部門です。管理部門は売上や利便性ではなく、リスク・統制・整合性・コストで判断します。本記事では、経理・財務・情シスが実際に確認する5つの論点と、各部門が納得する設計の作り方を整理します。
なぜ管理部門が導入の可否を左右するのか
BtoB-EC導入は、受注業務の変革であると同時に、以下のリスクを新たに生む可能性があります。
- 与信限度を超えた注文が通ってしまうリスク
- 価格設定の権限が不明確になり、承認なしの値引きが発生するリスク
- ECシステムと基幹システムのデータがずれ、会計処理に誤りが生じるリスク
- 顧客情報・価格情報が外部に漏洩するリスク
- 初期費用以外の保守・改修コストが想定外に膨らむリスク
管理部門はこれらのリスクを評価する立場にあります。営業目線の「便利になる」「業務が減る」という説明だけでは、これらのリスクへの回答になりません。
管理部門が確認する5つの論点
論点① 与信管理と掛売リスク（経理・財務）
BtoB取引の多くは掛売り（後払い）です。FAX・電話受注では、担当者が与信状況を確認してから受注を通す運用が暗黙的に行われていることがあります。ECに移行すると、この「人による与信確認」が自動化される一方で、設計が甘いと与信限度を超えた注文が通過するリスクが生じます。
経理・財務が確認する項目と、設計での対応です。
| 経理・財務が確認する項目 | 設計で対応すべきこと |
|---|---|
| 与信限度額を超えた注文が通らないか | 顧客ごとの与信上限をECシステムに設定し、超過時は注文を止める（または警告を出す）ロジックを実装する |
| 現在の未収残高と与信上限の連動はどうするか | 基幹システムの未収残高をEC側に連携し、リアルタイムまたは日次で与信状況を更新する設計にする |
| 与信超過時の処理フローは明確か | 与信超過注文を担当者に通知し、承認または差し戻しの判断フローをシステムで管理する |
| 請求データはどう生成されるか | EC受注データから請求データを自動生成する設計にし、手入力・転記を排除する |
論点② 価格統制と承認フロー（経理・管理）
BtoBでは顧客別価格・数量割引・期間キャンペーン・特例値引きが日常的に発生します。管理部門は「誰が価格を変更できるか」「承認なしの値引きが発生しないか」を確認します。
| 管理部門が確認する項目 | 設計で対応すべきこと |
|---|---|
| 価格変更権限は誰が持つか | 価格マスタの変更権限を役割（ロール）で管理し、権限のないユーザーは変更できない設計にする |
| 営業が個別に値引きを設定できないか | 特例値引きには承認ワークフローを組み込み、承認なしに価格が変更されない設計にする |
| 価格変更の操作履歴は残るか | 価格変更・承認・却下のすべての操作をログに記録し、監査時に追跡できるようにする |
| 誤った価格での受注が発生した場合のリカバリーは | 受注前の価格確認画面・受注後の修正フロー・担当者への通知設計をあらかじめ決めておく |
価格統制の設計が適切であれば、EC導入前より内部統制が強化されます。FAX・電話受注では担当者が手動で価格確認していた部分がシステム管理になるためです。この点を管理部門に明示することが説得の鍵になります。
論点③ 会計処理との整合性（経理・財務）
ECシステムと基幹システムが分断されると、売上計上タイミングのずれ・二重入力・仕訳ミスが発生します。監査対応の負担も増えます。経理部門が最も嫌うのはこの「データの不整合」です。
| 経理が確認する項目 | 設計で対応すべきこと |
|---|---|
| 売上計上のタイミングはいつか（出荷時・検収時・請求時） | 自社の会計基準に合わせた売上計上タイミングをECシステムに設定し、基幹と一致させる |
| ECと基幹でデータが二重管理にならないか | 受注データをECから基幹に自動連携し、手入力・転記を排除する。どちらが「正」のデータかを明確にする |
| 消費税・課税区分の計算は正確か | 商品ごとの課税区分・顧客の税区分・適用税率をEC側で正確に管理し、基幹の仕訳と整合させる |
| 月次締め処理に影響はないか | ECの受注データが月次締め日の処理に与える影響を要件定義段階で整理し、締め後の修正フローも設計する |
| 返品・キャンセルの会計処理は | 返品・キャンセル発生時のEC側・基幹側双方の処理フローを設計する。片側だけ処理されるケースを防ぐ |
論点④ セキュリティと情報管理（情シス）
顧客情報・価格情報・受注データは重要な経営資産です。情シス部門はセキュリティ要件をシステム仕様レベルで確認します。「セキュリティは大丈夫です」という口頭説明では通りません。
| 情シスが確認する項目 | 設計・説明で対応すべきこと |
|---|---|
| 不正アクセス対策は十分か | 管理画面のIPアドレス制限・二段階認証・ログイン試行回数制限の実装方針を明示する |
| 権限管理は適切か | ユーザー権限の階層設計（管理者・一般・閲覧のみ等）と、権限付与・変更・剥奪のフローを説明する |
| 操作ログは記録されるか | 誰がいつ何をしたかを記録するログ機能の仕様と、ログの保存期間・アクセス権限を明示する |
| 通信の暗号化は | HTTPS/TLS対応・SSL証明書の管理方針・APIの認証方式を説明する |
| 障害・インシデント発生時の対応フローは | 障害検知の仕組み・エスカレーション経路・復旧手順・情シスへの連絡フローを文書化して提示する |
| 既存システムへの影響範囲は | 連携するシステムの一覧・連携方式・既存システムへの変更が不要か必要かを整理して提示する |
情シスへの説明で重要なのは「口頭の保証」ではなく「文書化された仕様」です。ベンダーから技術仕様書・セキュリティポリシー・保守SLA（対応時間・対応範囲）を取得し、情シスが確認できる状態にすることが合意形成の前提です。
論点⑤ 中長期コストと保守体制（財務・情シス）
財務部門は初期費用だけでなく、5年・10年のトータルコストで判断します。「初期費用○○円」の提示だけでは不十分です。
| 財務・情シスが確認する項目 | 説明で対応すべきこと |
|---|---|
| 月額保守費用と対応範囲は | 月額費用・対応範囲（バグ修正のみか、機能改修まで含むか）・対応時間・SLAを明示する |
| バージョンアップへの対応コストは | EC-CUBEやフレームワークのバージョンアップが発生した場合の費用感と対応方針を説明する |
| 機能追加・改修はどのくらい発生するか | 段階導入設計を示し、フェーズ2・3の概算費用と時期を提示する。「後から追加費用が無限に増える」懸念を払拭する |
| ベンダーが廃業・撤退した場合のリスクは | オープンソース（EC-CUBE）であれば他ベンダーへの引き継ぎが可能である点を説明する。ソースコードの所有権・引き継ぎ手順を契約に明記する |
| 5年トータルのコスト試算は | 初期費用＋年間保守費用×5年＋想定改修費用の合計を提示し、年間削減効果との比較で回収期間を示す |
管理部門を早期に巻き込む進め方
管理部門の合意形成で失敗するパターンは共通しています。「営業主導で要件が固まってから、最後に管理部門に説明しに行く」という進め方です。この順序だと、管理部門は「決まったことを覆せない」という立場に置かれ、反発が強くなります。
合意形成が進む会社の進め方は逆です。
- 1
要件定義の前に管理部門のヒアリングを行う
「導入した場合に経理・情シスとして確認したいことを教えてください」というヒアリングを設計工程の最初に行います。懸念を後から潰すのではなく、最初から設計に組み込む。この1ステップが合意形成のコストを大幅に下げます。
- 2
管理部門の懸念を「設計要件」に変換する
「与信超過を防ぎたい」→「与信上限設定と超過時のアラート機能を実装する」。管理部門の懸念をシステム要件に変換し、ベンダーへの提示資料に含めます。これにより管理部門が「自分たちの意見が反映された設計」と感じられます。
- 3
設計レビューに管理部門を参加させる
ベンダーとの設計レビューに経理・情シスの担当者を同席させます。「後で説明を受ける」より「設計の議論に参加する」方が、承認への納得感が高くなります。参加が難しければ、設計書のレビューを依頼するだけでも効果があります。
- 4
稟議資料に管理部門の懸念への回答を明示する
稟議資料に「経理・財務・情シスの確認事項と設計での対応」というセクションを設けます。管理部門が「自分たちの懸念が資料に反映されている」と確認できる状態を作ることで、承認のハードルが下がります。
あわせて読まれています
よくある質問
情シス部門がいない（または外注している）場合、セキュリティ確認はどうすればいいですか？
情シスが社内にない場合、セキュリティ要件の確認はベンダーに依頼することになります。この場合に重要なのは、ベンダーから「セキュリティ仕様書」「保守SLA」「インシデント対応フロー」を文書で取得することです。口頭の「セキュリティは大丈夫です」では経営責任者が判断できません。文書化された仕様を経営責任者が確認できる状態を作ることが、情シスの代替となる確認手順です。
基幹システムが古く、EC連携の技術的な実現性に不安があります。
基幹システムが古い場合でも、多くのケースでCSV連携（夜間バッチ）での対応は可能です。APIリアルタイム連携が難しい場合でも、日次CSVで在庫・価格・受注データを同期する設計から始めることで、BtoB-ECとして機能します。重要なのは「将来のAPI連携移行を前提にしたデータ構造で設計する」ことです。今の基幹システムの制約に引きずられて設計の余白を潰さないよう、ベンダーと連携方針を明確にしてから設計に入ってください。
管理部門のヒアリングで出た懸念がすべて設計に反映できない場合はどうしますか？
すべての懸念を初期設計に反映する必要はありません。「フェーズ1で対応するもの」「フェーズ2以降で対応するもの」「運用で対応するもの」「仕様上の制約により対応できないもの」に分類して管理部門に提示します。「言ったことが無視された」ではなく「言ったことが整理されて判断された」という状態を作ることが重要です。分類と理由を明示した上で合意を得るプロセスが、後の運用トラブルを防ぎます。
管理部門の懸念を設計に落とし込む作業、一緒にやります
「経理から与信管理の設計を求められた」「情シスにセキュリティ仕様を説明できない」——管理部門との合意形成に必要な設計整理から、ベンダーへの要件提示まで支援します。
投稿者プロフィール
- CEO
- 株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。
関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。
この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。
その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現（退任時：常務取締役）。
2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。
単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。
NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution
■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム（富野由悠季）
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン
