◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB ECの運用体制は、6つの役割に業務を割り当てることで設計できます。
- 専任6人を置く発想ではなく、兼務を前提に役割を割り当てる考え方です。
- 人材不足の背景には、人材像や評価基準を「決めていない」という空白があります。
- 電子取引データの保存とセキュリティは、体制表には担当枠を設けます。
目次
BtoB ECの運用体制とは何か——導入体制との違い
BtoB ECの運用体制とは、受注処理・商品情報の維持・取引先対応・システム連携の保守・データの保存を役割単位で分担する仕組みを指します。これらは稼働後も継続して発生する業務です。IPAの調査では、DX推進人材の「量」が不足している企業の合計が85.5%*1にのぼり、体制の見直しは急務となっています。
受注処理・マスタ更新・データ保存——運用体制が扱う業務の範囲
運用体制が扱うのは、システムが稼働した後に繰り返し発生する業務です。受注確認や商品マスタの更新、取引先からの問い合わせ対応、基幹システムとの連携維持、そして電子取引データの保存までが対象です。
これらの業務を「誰が」「どれくらいの工数で」担うかを役割ごとに定めることで、初めて運用体制として機能します。担当が曖昧なままでは、日々の業務のどこかに抜けが生じやすくなります。
導入体制と運用体制は別物です
システムを選定し構築するまでの「導入体制」と、稼働後に業務を回し続ける「運用体制」は目的が異なります。導入体制は要件定義から稼働開始までの、期限を区切ったプロジェクトであるのに対し、運用体制は稼働後も継続する組織機能です。
導入の進め方そのものは別記事で扱っています。本記事では、稼働した後にどう回し続けるかに範囲を絞って解説します。
運用体制の設計は情報システム部門だけの仕事ではありません
IPAの調査では、経営者・IT部門・業務部門の協調が「十分にできている」「まあまあできている」の合計は48.9%(2025年度)*1にとどまります。DXの成果が出ている企業では72.9%に達する一方、成果が出ていない企業では37.1%*1にとどまるという差が生じているのが実情です。
この差は、運用体制を情報システム部門だけの課題として閉じていないかどうかに関わっていると考えられます。次節では、体制設計の起点を「人数」ではなく「定義」に置く理由を見ていきます。
人員設計でつまずくのは人数ではなく「定義」である
DX人材の「量」が不足している企業は85.5%、大幅不足は50.1%へ推移
IPAの調査で、DXを推進する人材の「量」について「やや不足している」「大幅に不足している」と回答した企業の合計は85.5%(2025年度)*1でした。この数値は、DXに取り組んでいる企業を母集団とした割合です。以降、本記事が引用するIPA「DX動向2026」(2025年度調査)の割合は、断りのない限り「全社戦略に基づき全社的に/一部の部門において/部署ごとに個別でDXに取り組んでいる」と回答した企業を母数とする設問の数値です*1。
内訳を見ると、「大幅に不足している」と回答した企業は2023年度62.1%、2024年度58.5%、2025年度50.1%*1と推移しています。深刻な不足感はやや解消傾向にあると言えるでしょう。
人材像を周知している企業は16.2%、評価基準がない企業は76.1%
DXを推進する人材像を「設定し、社内に周知している」企業は16.2%(2024年度20.4%)*1にとどまります。「設定していない」「わからない」の合計は約5割*1に達しました。
DX人材の評価基準についても「基準はない」と回答した企業が76.1%*1を占めます。人数を数える以前に、誰をどう評価するかという物差しが用意されていない実態がうかがえます。
必要スキルを把握できていない企業は52.8%、把握状況と不足感には関連がある
必要なスキルを「把握できていない」と回答した企業は52.8%*1にのぼりました。スキル把握状況別に見ると、人材の「質」が「大幅に不足している」と答えた割合は、把握している企業で40.6%、把握できていない企業で64.0%*1でした。
この調査結果は、スキルの把握と不足感の間に関連があることを示すものであり、把握すれば不足が解消するという因果関係を示すものではありません*1。とはいえ、まず役割とスキルを定義することが、次の一手として理にかなっていると言えます。
役割・スキル・評価の定義が、次の一手になります
ここまでの数値が示すのは、不足感の強さそのものではなく、その手前にある「決めていない」という空白です。人材像の周知率16.2%、評価基準なし76.1%、必要スキル未把握52.8%という数値が、その空白の大きさを裏づけています*1。
採用や外部委託を検討する前に、まず自社の運用業務をどんな役割に分けるかを決めることが、遠回りに見えて近道になります。次節では、その役割分けに使える公的な型を紹介します。
BtoB ECの運用業務を6つの役割にまとめる
デジタルスキル標準ver.2.0が定める6つの類型
IPAは2026年4月に「デジタルスキル標準ver.2.0」*2を公表しました。DXの推進に必要な人材の役割やスキルを整理した公的な指針で、DX推進に必要な役割群を6つの「類型」として定義しています*2。ビジネスアーキテクト・デザイナー・データサイエンティスト・データマネジメント・ソフトウェアエンジニア・サイバーセキュリティの6つです*2。
各類型の中には2〜4つの「ロール」が置かれています*2。この型を使えば、BtoB ECの運用業務も役割ごとに整理できます。
専任6人を置く話ではなく、1人が複数ロールを兼ねる前提です
同標準は「1つの部署が1つの類型を担う場合や、1つの部署が複数の類型を担うことも想定」すると明記しています*2。加えて「1人の人材が複数のロールを兼ねる場合や、複数の人材で1つのロールを担うことも想定」するとも記載しています*2。
つまり6類型は「専任者を6人採用せよ」という基準ではなく、既存の担当者に役割を割り当てるための枠組みです。中堅・中小規模のBtoB EC事業者にも、そのまま適用できます。
BtoB EC運用体制を設計する優先順5点(順位根拠:着手順序)
- 自社の運用業務を洗い出し、6類型に当てはめて担当を確認します。
- 担当が空白になっている類型があれば、既存の担当者への割り当てを検討します。
- 各業務の発生頻度と所要時間を棚卸しし、月間の総工数を可視化します。
- 締切のない業務(マスタ整合確認・権限棚卸し・データ保存確認)に代行者を決めます。
- 電子取引データの保存とセキュリティの担当を体制表に明記します。
6類型×BtoB EC運用業務の対応表
次の表は、6類型をBtoB ECの運用業務に翻訳したものです。類型名は*2の表記のまま用いています。
| 類型 | BtoB EC運用での業務 | 典型的な担当部門 | 兼務の可否 | 空白のときに起きること |
|---|---|---|---|---|
| ビジネスアーキテクト | EC化する業務範囲と優先順位の決定。取引先展開の計画と効果の確認。 | 営業企画・経営企画 | 兼務可 | 展開の優先順位が場当たりになります。 |
| データマネジメント | 商品マスタ・取引先マスタ・価格の維持と整合。 | 業務部門・情報システム部門 | 兼務可 | 価格や在庫の情報にずれが生じます。 |
| ソフトウェアエンジニア | 基幹連携の保守と障害の一次対応。 | 情報システム部門 | 外部委託と併用しやすい | 障害発生時の対応が遅れます。 |
| サイバーセキュリティ | アカウント管理・権限設定・インシデント対応。 | 情報システム部門 | 兼務可(技術対策は外部委託と併用) | 退職者のアカウントなどが放置されます。 |
| データサイエンティスト | 受注データの集計と改善材料づくり。 | 営業企画・マーケティング | 中小規模では後回しになりやすい | 改善の判断材料が蓄積されません。 |
| デザイナー | 画面・帳票・操作案内の分かりやすさの維持。 | 業務部門(外部委託になりやすい) | 外部委託になりやすい | 操作の問い合わせが増えます。 |
担当が空白のまま稼働すると、表の右端に挙げた症状が現れやすくなります。自社のどの担当者がどの類型を兼ねているか、この表に当てはめて確認してみてください。
6類型に収まりにくい「取引先対応」は独立した枠に
BtoB EC特有の業務として、取引先からの電話・メールでの問い合わせ対応と、掛売り・締め請求まわりの経理連絡があります。これらは*2の6類型そのものには含まれない、BtoB EC固有の業務です。
6類型を無理に7つに増やすのではなく、「取引先対応」を体制表に独立した枠として明示的に置くことをおすすめします。取引先別の価格条件を維持する仕組みについては、別記事で扱っています。在庫連携の担当範囲については、こちらでも触れています。
何人必要かを決める前に、業務量を数える
棚卸しの単位:業務・頻度・所要時間・件数・担当
「何人必要か」を決める前に、まず業務量を数える必要があります。棚卸しの単位は、業務名・発生頻度・1件あたりの所要時間・月間件数・担当者の5項目です。
次の表は、その型をそのまま示したものです。自社の数字を当てはめて、月間の総工数を算出してみてください。
| 業務 | 発生頻度 | 1件あたりの所要時間 | 月間件数 | 担当 |
|---|---|---|---|---|
| (例:受注確認) | 日次 | (記入欄) | (記入欄) | (記入欄) |
| (例:商品マスタ更新) | 週次 | (記入欄) | (記入欄) | (記入欄) |
| (例:取引先からの問い合わせ対応) | 不定期 | (記入欄) | (記入欄) | (記入欄) |
見落とされやすい定常業務:新規取引先の登録から連携エラーの確認まで
棚卸しで見落とされやすいのは、新規取引先のアカウント発行、価格改定の反映、商品マスタの追加・廃番、受注の例外対応です。取引先からの操作問い合わせや、基幹連携エラーの確認も定常業務に含まれます。
これらは発生頻度が不定期であるため、棚卸し表に載らないまま特定の担当者へ集中しがちです。表の「発生頻度」欄には、月次だけでなく「不定期」という選択肢も残しておく必要があります。
稼働直後に一時的に増える業務:案内・初期データ投入・二重運用
稼働直後は、取引先への案内と操作説明、初期データの投入、旧経路との二重運用が一時的に発生します。これらは平常運用より工数が大きくなりやすい期間です。
電話・FAXでの受注から移行する場合、二重運用をどう回すかが特に負荷の高い論点になります。
「◯人必要」と断定せず、判断軸として使う
本記事では、業務量から算出される必要人数の目安を具体的な人数として示しません。取引先数・商品点数・受注件数によって必要な工数は大きく変わるためです。
大切なのは、棚卸し表で自社の総工数を可視化し、既存の人員でまかなえる範囲かどうかを判断できるようにすることにあります。
この工数を洗い出した結果、自社の商習慣に合わせて標準機能でどこまで吸収できるかを確かめるには、無料相談で要件を整理するのが近道です。
兼務を前提に割り当てる——落ちやすい業務から守る
兼務は前提です。ただし締切のない業務から落ちます
デジタルスキル標準ver.2.0が想定するとおり、兼務は例外ではなく前提です*2。ただし、兼務体制で最初に落ちるのは締切が明示されていない業務だと考えられます。
マスタの整合確認、権限の棚卸し、データの保存確認などがこれに当たります。締切がある受注処理は後回しにできない一方、これらの業務は気づかないまま放置されがちです。
落とさないための2つの仕掛け:代行者と月次点検日
落とさないための仕掛けは2つです。1つは、各役割に代行者を1人決めておくことです。承認者が不在で業務が止まる問題は、見積承認のワークフロー設計そのものと合わせて検討する必要があります。
もう1つは、締切のない業務を確認する月次の点検日をあらかじめ決めておくことです。点検日を先に決めてしまえば、業務の抜けに気づく機会を仕組みとして確保できるでしょう。
属人化の見分け方は「休むと止まる業務」の件数
属人化しているかどうかは、担当者が1週間休んだときに止まる業務が何件あるかで見分けられます。件数が多いほど、代行者の設定が急がれます。
育成予算は増えていません。既存人員の役割定義が現実的です
DX推進人材を育成する予算を「大幅に増やした」「やや増やした」と回答した企業の合計は25.6%(2024年度23.8%)*1にとどまります。「変わらない」と回答した企業は約半数を占めます*1。
育成予算が大きく増える前提は置きにくいのが実情です。だからこそ、新たに人を育てる計画よりも先に、今いる人員の役割を定義し直すほうが現実的な一歩になります。
部門をまたぐ設計にする
データ利活用体制で最も多いのは部門をまたいだ連携45.0%
IPAの調査で、データ利活用のための体制整備として最も回答が多かったのは「部門をまたがった連携」45.0%*1でした。次いで「経営層の関与」44.2%(2024年度から約16ポイント増)*1が続きます。
「必要なスキルを持つ人材の確保・育成」は36.8%(2024年度52.7%)*1で、前年度から低下しています。推測:これは育成が完了した結果ではなく、体制整備の重点が部門連携や経営層の関与へ移ったことを反映していると考えられます。なお、この設問はデータ利活用に取り組んでいる(過去のみ・関心のみ・予定なしを除く)企業を母数としています*1。
利活用が進む企業ほど専門部署の設置と部門連携が進んでいます
同調査では、データ利活用がすでに進んでいる企業ほど「専門部署の設置」「部門をまたがった連携」が進んでいる傾向が見られます*1。運用体制の設計を情報システム部門だけに閉じない姿勢が、成果につながっている可能性があります。
決めることと決める人の対応表
部門をまたぐ設計では、「何を」「誰が」決めるのかを先に整理しておくことが欠かせません。次の表は、その対応関係を示す型です。
| 決めること | 主担当 | 承認者 | 決めないまま進めた場合の症状 |
|---|---|---|---|
| EC化する業務範囲 | ビジネスアーキテクト役 | 事業責任者 | 展開の順序が場当たりになります。 |
| 価格・掛売りの条件 | データマネジメント役 | 営業責任者 | 取引先ごとの価格に不整合が生じます。 |
| マスタの正本 | データマネジメント役 | 情報システム責任者 | どのデータが正しいか分からなくなります。 |
| 障害時の連絡順 | ソフトウェアエンジニア役 | 情報システム責任者 | 障害対応の初動が遅れます。 |
| 取引先展開の順序 | ビジネスアーキテクト役 | 事業責任者 | 対応できる取引先数を超えて案内してしまいます。 |
マスタの正本(どのシステムのデータを正としてほかに反映するか)を誰が持つかは、基幹システムとの連携設計にも関わります。要件を整理する段階からこの対応表を意識しておくと、後戻りが少なくなります。
現場に使ってもらうための施策は、体制設計とは別の論点です
体制を整えても、現場が使いこなせなければ効果は出ません。ただし「使ってもらうための施策」は、本記事が扱う「誰が何を担うか」という体制設計とは別の論点です。
現場を巻き込む具体的な進め方は、別記事で解説しています。本記事では、担当が決まっていないために業務が落ちるという体制側の症状に絞って扱います。
内製と外部委託の線引き
外部に任せやすい業務:画面改修・基幹連携の実装・監視
画面や帳票の改修、基幹連携の実装、システムの監視、セキュリティの技術的対策は、外部に任せやすい業務です。専門知識が体系化されており、仕様さえ明確であれば社外のパートナーでも対応できます。
自社にしか決められないこと:商習慣・例外処理・価格判断
一方で、自社の商習慣、例外処理を認めるかどうかの判断、取引先ごとの優先順位、価格の判断は自社にしか決められません。これらを外部委託先に丸投げすることはできません。
委託しても残る自社の仕事には専門知識と工数が必要です
外部委託を選んだ場合でも、要件の説明、成果物の受け入れ確認、取引先への説明という仕事は自社に残ります。これらを内製で行うには、EC業務の理解に加えて、基幹システムの構造を把握する専門知識が必要です。
要件の説明や受け入れ確認を1人が兼務する場合、他の定常業務と工数が競合しやすくなります。委託範囲を決める段階で、残る自社側の工数も合わせて見積もっておく必要があります。
参考:AI活用のリーダーシップは「IT部門の長」が46.0%で最多です
やや性質の異なる参考値として、AI導入・利活用のリーダーシップ体制に関する数値を紹介します。IPAの調査では「IT部門の長」が46.0%*1と最も高い割合でした。「CAIO(最高AI責任者)」は2.9%、「CAIO以外の専任者」は9.8%*1という結果でした。これはAIを「導入している」「試験利用をしている」「利用に向けて検討を進めている」と回答した企業を母数とする設問の数値です*1。
これはAI活用に関する設問の結果であり、BtoB EC運用の体制そのものを示す数値ではありません*1。新しい役割ほど専任は置かれず、既存部門の長が兼ねる傾向は、運用体制の設計を考えるうえでも参考になります。
運用体制に欠かせない2つの業務——データ保存とセキュリティ
電子取引データの保存は法令上の義務です
所得税(源泉徴収に係る所得税を除く)および法人税の保存義務者が、取引情報を電磁的方式により授受する取引(電子取引)をした場合を対象とする規定です*3。その場合、取引情報を電磁的記録により保存しなければならないと定められています*3(電子帳簿保存法第7条)。
BtoB ECの受発注データは、この電子取引に該当し得ます。担当者と保存先を体制表に明記しておかないと、稼働後にこの義務が抜け落ちる恐れがあります。
個別の該当判断は税理士・所轄税務署に確認してください
自社の取引が電子取引に該当するかどうか、保存要件を具体的にどう満たすかといった個別の判断は、税理士または所轄の税務署に確認することをおすすめします。本記事は制度の概要を紹介するものであり、個別の判断を代替するものではありません。
セキュリティ対策ガイドライン第4.0版が6か条に拡充されました
IPAは2026年3月27日、「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開しました*4。情報セキュリティ5か条に「バックアップを取ろう!」を加えて6か条とし、中小企業のセキュリティ人材の確保・育成を支援する付録を追加しています*4。
セキュリティを体制の枠として明確に置くことが、このガイドラインが示す方向性と一致します。技術的な対策の中身そのものは、別記事で扱っています。
アカウント・権限の棚卸しを誰がいつ行うか決めます
退職者・異動者のアカウントが残ったままになっていないか、権限が業務内容に見合っているかは、月次の点検日に合わせて確認するのが実務的です。担当をサイバーセキュリティ役として明示し、点検の頻度を体制表に記載してください。
運用体制の立ち上げ——最初の90日にやること
立ち上げ期に行う5つの手順(目安90日)
運用体制を立ち上げる際は、次の5つの手順で進めます。番号は着手順序を示しています。各手順に添えた日数は、公的な基準ではなく、稼働準備の期間として本記事が置いた編集上の目安です。自社の取引先数や商品点数に応じて調整してください。
- 運用業務を棚卸しして工数を数えます(1〜30日目の目安)。
- 6つの役割に業務を割り当て、代行者を決めます(31〜60日目の目安)。
- 決めることと決める人を対応表にまとめます(31〜60日目の目安)。
- データ保存とセキュリティの担当を明記します(61〜90日目の目安)。
- 月次の点検日と、体制の見直し時期を決めます(61〜90日目の目安)。
体制表のひな形
次の表は、体制表として社内で提出できる型です。工数の具体的な数値は空欄にしてあります。自社の棚卸し結果を反映してください。
| 役割 | 担当者 | 代行者 | 想定工数(月) | 点検頻度 |
|---|---|---|---|---|
| ビジネスアーキテクト | (記入欄) | (記入欄) | (記入欄) | (記入欄) |
| データマネジメント | (記入欄) | (記入欄) | (記入欄) | (記入欄) |
| サイバーセキュリティ | (記入欄) | (記入欄) | (記入欄) | (記入欄) |
体制を見直すタイミング
取引先が増えたとき、商品点数が増えたとき、担当者が異動するときは、体制表を見直すタイミングです。段階的に事業を拡大する場合は、拡大の段階ごとに体制を厚くする考え方が参考になります。
体制表は一度作って終わりではなく、事業の変化に合わせて更新し続けるものとして運用してください。稟議や社内説明の資料に体制表を載せる場合の書き方は、別記事もあわせてご確認ください。
まとめ——BtoB EC運用体制を決める3つの判断軸
本稿では、BtoB ECの運用体制と人員設計の考え方を整理しました。要点を3つに集約すると次の通りです。第一に、不足感の正体は人数ではなく、人材像・評価基準・スキルの「定義」の欠落にあります*1。第二に、デジタルスキル標準ver.2.0の6類型は、専任者の増員ではなく既存人員への割り当てを前提にした型です*2。第三に、電子取引データの保存*3とセキュリティ*4は、体制表に担当枠を設ける必要があります。
足りないのは人数ではなく定義です。棚卸し表と体制表のひな形は、今日から書き始められるはずです。まず本記事の6類型対応表に自社の担当者名を書き入れ、空白になった類型を洗い出すところから着手してください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
よくある質問
BtoB ECの運用担当は専任を置くべきですか。
必須ではありません。デジタルスキル標準ver.2.0は、1人が複数の役割を兼ねることを前提としています*2。まず自社の業務量を棚卸しし、兼務でまかなえる範囲かどうかを確認することが先決です。
情報システム部門がない場合、誰が運用の責任者になりますか。
情報システム部門の有無にかかわらず、事業を所管する部門の責任者が担うケースが一般的です。参考として、AI導入・利活用のリーダーシップ体制では「IT部門の長」が46.0%と最も多く報告されています*1。自社の組織体制に応じて判断してください。
運用体制はいつまでに決めておくべきですか。
稼働開始前に、少なくとも6類型への担当割り当てとデータ保存・セキュリティの担当を決めておくことをおすすめします。詳細な工数配分は、稼働後の実績を見ながら調整しても構いません。
担当者が異動・退職しても回る体制にするには何を残しますか。
業務の手順書に加えて、各役割の代行者と決めることの対応表を文書として残すことが有効です。属人化の解消は、個人の記憶ではなく体制表という形に落とすことから始まります。
運用の一部を外部に委託する場合、契約前に決めておくことは何ですか。
委託しても自社に残る仕事(要件の説明・受け入れ確認・取引先への説明)を先に洗い出しておくと、契約後の認識のずれを防げます。委託範囲と自社側の残存工数は、契約前にすり合わせてください。
- *1 出典:独立行政法人情報処理推進機構(IPA)「DX動向2026」(2026年)
- *2 出典:独立行政法人情報処理推進機構(IPA)「デジタルスキル標準ver.2.0」(2026年4月)
- *3 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】」(令和8年7月)
- *4 出典:独立行政法人情報処理推進機構(IPA)「「中小企業の情報セキュリティ対策ガイドライン」第4.0版を公開」(2026年3月27日)
画像の出典元
- 運用のイメージ/Photo by Tim Cooper on Unsplash
- 導入のイメージ/Photo by ThisisEngineering on Unsplash
- よくある質問のイメージ/Photo by Kelly Sikkema on Unsplash
- よくある質問のイメージ/Photo by Fiona Murray-deGraaff on Unsplash
- 運用のイメージ/Photo by Huy Phan on Unsplash
- 導入のイメージ/Photo by Lee on Unsplash