◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB ECのスマホ利用とは、画面をそのまま縮小することではなく、現場で完結させる業務を切り出す設計です。
- 現場は店舗・倉庫・工事現場・移動中の4類型に分かれ、通信条件も端末の持ち主も異なります。
- 小さい画面で最初に削るべきは型番の手入力とログインであり、全機能を載せずスマホとPCの線を引くことが設計の土台になります。
目次
BtoB ECのスマホ利用とは、現場で完結させる4業務を切り出す設計
BtoB ECのスマホ利用とは、画面の縮小ではなく、現場で発注・在庫確認・承認・履歴照会を完結させる設計を指します。取引先や自社の担当者が事務所に戻らず、店舗・倉庫・工事現場・移動中といった業務の場でこの4業務を行える状態を目指します。
現場で切り出す業務は4つに絞る
「スマホ対応」を画面設計だけの問題として扱う記事が目立ちます。本質は業務の切り出しにあります。
現場の担当者がスマホで行う業務を、発注・在庫と納期の確認・承認・履歴照会の4つに絞り込むことが、設計の出発点になります。この4業務以外はPCに残すという線引きを先に決めておくと、機能の詰め込みを防げます。
事業者間取引の電子化は出荷額ベースで4割に達している
総務省「令和7年版 情報通信白書」によれば、事業者間(BtoB)の取引における電子商取引化が進展しています*1。出荷額ベースで見ると、2023年のEC化率は40.0%でした*1。取引の電子化そのものは、出荷額の4割という水準まで進んでいる段階にあると言えます。
事務所の外で働く形を制度として持つ企業は3割強である
総務省「令和6年通信利用動向調査(企業編)」は2025年5月30日に公表され、調査時点は2024年8月末です*2。常用雇用者100人以上の企業6,040社を対象に実施され、有効回答は2,330社でした*2。
テレワークを導入している企業(令和6年 n=1,102。nは比重調整後の導入企業数)の導入形態は、在宅勤務が90.9%と最も高い水準です*2。次いでモバイルワーク(オフィス以外の場所での業務)が32.4%でした*2。
この32.4%は、あくまで「テレワークを導入している企業」を母数とした導入形態の割合であり、BtoB ECのスマホ利用率そのものではありません。事務所の外で働く形を制度として持つ企業が一定数存在し、現場で発注する場面も同じ流れの延長線上にある、という背景として押さえておく必要があります。
店舗・倉庫・工事現場・移動中 ― 「現場」は4類型で通信条件も担当者も異なる
競合記事の共通の弱点は、「現場」や「外出先」をひとまとめに扱っている点です。実際には、現場ごとに担当者・端末の持ち主・通信条件・必要な業務が異なります。まず自社の対象を4類型のどれに当てはめるかを決めることが、要件定義の第一歩になります。
| 現場 | 担当者 | 端末の持ち主 | 通信条件 | 必要な業務 |
|---|---|---|---|---|
| 店舗・バックヤード | 小売・飲食の店舗スタッフ | 取引先の私物または店舗共有機 | 屋内Wi-Fi中心・比較的安定 | 定番品の再発注・在庫確認 |
| 倉庫・工場 | 受入・棚卸の担当者 | 共有端末が多い | 屋内だが電波が届きにくい区画あり | 在庫・入荷予定の確認 |
| 工事現場・屋外 | 建設・設備の現場担当者 | 私物スマホが中心 | 不安定・圏外が生じうる | 発注・納期確認・承認 |
| 移動中・訪問先 | 自社の営業担当者 | 会社支給または私物 | 移動中で片手操作になりやすい | 在庫・納期確認・履歴照会 |
現場業務の比率が高い産業でもクラウドの利用は進んでいる
総務省「令和6年通信利用動向調査(企業編)」は、クラウドサービスを利用する企業の割合を全体で80.4%と示しています*2。調査は常用雇用者100人以上の企業が対象で、有効回答は2,330社でした*2。
産業別では建設業が86.7%、卸売・小売業が82.9%、製造業が80.6%でした*2。現場業務の比率が高い産業でも、クラウド利用は8割前後まで進んでいます。なお本調査の対象は常用雇用者100人以上の企業で、中小規模の事業者は含みません。
建設業と自動車運転業務では時間外労働の上限規制が始まっている
厚生労働省によれば、建設業(工作物の建設の事業)と自動車運転業務への時間外労働の上限規制は、2024年4月から適用されています*3。建設業は原則として月45時間・年360時間以内です*3。臨時的な特別の事情がある場合の特別条項でも、年720時間・単月100時間未満・複数月平均80時間以内が上限です*3。
自動車運転業務は、特別条項付き36協定を結んだ場合の年間の時間外労働の上限が年960時間です*3。
この制度は労務管理の話であり、本記事はその解釈や運用を助言するものではありません。ただし、現場から一度事務所へ戻ってから発注するという前提は、稼働できる時間の面から見直されやすくなっています。この点は公的な制度の事実として押さえておく価値があります。
端末は「取引先の私物スマホ」であることが多いという前提を置く
4類型のうち、店舗・バックヤードと工事現場・屋外では、発注に使う端末が取引先の私物スマホであるケースが目立ちます。会社支給端末を前提に要件を組むと、実際の利用場面とのずれが生じやすいでしょう。専用アプリの導入・更新・審査という運用負荷が生じる点は、後述のアプリとブラウザの判断基準で扱います。
型番の手入力とログイン ― 現場で最初に削るべき2つの摩擦
現場で最初に削るべきは、型番の手入力とログインです。競合記事の多くはレスポンシブ対応止まりで、この2点まで具体化していません。
BtoBの発注は型番と数量の入力であり、ここが大きな摩擦になる
BtoBの発注は、商品名の選択だけでは完結せず、型番と数量の入力を伴います。小さい画面での英数字混じりの型番入力は、指の届きにくさと誤入力の両方を招きやすく、現場での離脱要因になりかねません。型番検索の表記ゆれ・部分一致といった検索仕様そのものは、商品検索の設計を扱う別記事に譲ります。
入力を減らす4つの方法
現場での入力を減らす方法4点/順位根拠:実装の着手しやすさ
- 発注履歴からの再発注機能を用意し、同じ型番の再入力そのものをなくします。
- お気に入り・定番リストを用意し、よく使う商品を一覧から選べるようにします。
- 数量の入力欄をステッパー(+/-ボタン)形式にし、数字キーの手入力を減らします。
- カメラでのバーコード読み取りを用意し、型番の手入力自体を代替します。
4点目のバーコード読み取りが成立するのは、商品識別が国際標準のコード体系に乗っているためです。一般財団法人流通システム開発センター(GS1 Japan)によれば、JANコード(GTIN-13)は「どの事業者の、どの商品か」を表す国際標準の商品識別コードで、標準タイプは13桁、短縮タイプは8桁です*4。商品パッケージにはJANシンボルというバーコードシンボルで表示されます*4。自社の取扱商品がこの体系でパッケージ表示されているかどうかが、カメラ読み取りを要件に含められるかの分かれ目になります。
ログアウトの頻度が利用を止める
現場での利用を止めるもう一つの要因が、頻繁なログアウトです。屋外での再ログインはパスワード入力の手間が大きく、次第に電話・FAXへ発注が戻る一因になります。
セッションを一定期間保持しつつ、金額や承認に関わる操作の前だけ再認証を求める線引きが実務的です。共有端末・私物端末を前提とした権限・アカウントの設計は、別記事で詳しく扱います。
1画面1タスクにする
現場での操作は片手・立ち姿勢が前提になりやすく、縦スクロールを基本にした1画面1タスクの設計が望まれます。タップ領域を十分に確保し、数量欄には数値キーボードが立ち上がる入力欄の型指定をしておくと、誤入力を減らせます。
自社の現場でどこまで削れるかを具体的に確かめるには、無料相談で要件を整理するのが近道です。
スマホで完結させる業務とPCに残す業務の線を先に引く
全機能をスマホに載せる設計は、開発負荷が増えるだけでなく、現場での操作をかえって複雑にします。先に線を引き、載せない機能を明確にすることが設計の土台です。
| 業務 | スマホで完結 | PCに残す | 理由 |
|---|---|---|---|
| 定番品の再発注 | ○ | - | 型番・数量の入力が単純で現場完結に向く |
| 在庫・納期の確認 | ○ | - | 参照のみで完結し操作負荷が低い |
| 出荷・入荷の通知確認 | ○ | - | 通知から確認するだけで完結する |
| 承認の可否判断 | ○ | - | 通知から1タップで到達させやすい |
| 履歴照会 | ○ | - | 一覧の閲覧のみで完結する |
| 新規取引先の登録 | - | ○ | 入力項目が多く誤登録のリスクが大きい |
| 商品マスタの編集 | - | ○ | 管理者向け操作で現場業務ではない |
| 複雑な見積の作成 | - | ○ | 条件分岐が多く小さい画面に不向き |
| 権限の設定 | - | ○ | 管理者向け操作で誤操作の影響が大きい |
| 帳票の一括出力 | - | ○ | 大量データの処理は画面サイズに合わない |
掛売・取引先別価格は「表示」だけをスマホへ持つ
掛売(かけうり、代金を都度回収せず一定期間分をまとめて請求する取引形態)や取引先別価格は、BtoB取引に特有の商習慣です。これらの設定・変更機能そのものをスマホに載せる必要はありません。現場では、自社に適用される価格や与信枠の残りを「表示」する範囲にとどめ、設定の変更はPC側に残す、という線引きが実務的です。
承認は通知から1タップで到達させる
発注の承認は、通知を受け取った時点から1タップで承認画面へ到達できる設計が望まれます。見積・承認のワークフローそのものの設計は、別記事で詳しく扱います。
現場からの早朝・夜間の発注は締め時間の設計と対になる
工事現場や倉庫からは、始業前や終業後に発注が行われる場面があります。この時間帯の扱いは、受注の締め時間設計と対になる論点であり、締め時間の詳細設計は別記事に譲ります。
ブラウザかアプリか ― 通知・端末機能・配布の3点で判断する
「アプリもあります」で終わらせず、通知・端末機能・配布と更新の3点で判断することが、取引先への負担を左右します。
| 方式 | 通知 | カメラ等の端末機能 | 配布と更新 | 取引先の負担 |
|---|---|---|---|---|
| ブラウザ(レスポンシブ) | 不可 | ブラウザの対応範囲に限られる | 配布不要・更新は自動反映 | 最小(URLのみ案内) |
| ホーム画面への追加 | 限定的 | ブラウザの対応範囲に限られる | 案内手順は必要・更新は自動反映 | 小(追加手順の案内が必要) |
| 専用アプリ | 可能 | カメラ等を利用しやすい | ストア審査・インストール案内・更新案内が必要 | 大(導入・更新のたびに手順が発生) |
取引先に導入作業を求めるほど利用率は上がりにくい
専用アプリは通知やカメラ機能を使える利点がある一方、取引先にインストールと更新の手間を求めます。取引先の担当者は複数の取引先ごとに異なるアプリを管理することになりやすく、導入作業の負担が利用の定着を妨げる要因になり得ます。
通信が不安定な現場での扱い
工事現場・屋外のように通信が不安定な場所では、送信中の通信断で二重発注が起きる懸念があります。送信前に入力内容を端末側に一時保存し、通信復帰後に再送する仕組みや、送信済みの注文番号を画面に明示して二重送信を防ぐ設計が必要です。
判断の順序は「まずブラウザで成立させる」
4業務がブラウザで成立するかをまず検証し、通知やカメラといった端末機能が業務上どうしても必要になった時点で専用アプリを検討する、という順序が現実的です。最初から専用アプリを前提にすると、取引先への導入負担だけが先に発生します。
現場で使われる状態にするための5ステップ
現場でのスマホ利用を軌道に乗せるには、機能を作り込んでから配ることを避け、小さく試して計測する進め方が有効です。
- 対象の現場と業務を1つに絞ります(例:倉庫からの定番品の再発注)。
- 端末・通信条件・端末の持ち主を確認します。前述の現場4類型に照らして確認します。
- 上位の取引先数社に限定して試します。全取引先へ一斉に配らず、影響範囲を小さく保ちます。
- 現場に同行して操作を計測します。発注1件あたりの操作時間・入力の詰まり・離脱箇所を確認します。
- 計測で見つかった詰まりを直してから対象を広げます。
計測するのは意見ではなく操作である
「使いにくい」という感想だけでは、どこを直すべきか分かりません。発注1件あたりの操作時間、型番入力でのやり直し回数、途中で離脱した画面を具体的に記録し、意見を画面と手順に翻訳することが改善の起点になります。
取引先への案内資料は別に用意する
現場での利用を求める前に、取引先向けの案内資料や手順書を用意しておくと、問い合わせの発生を抑えられます。教育・案内資料の作り方は、別記事で詳しく扱います。
利用が定着したかどうかの測り方は別記事に譲る
本記事は端末と画面の条件に絞って扱っており、定着したかどうかを測る指標や体制の設計は別記事のテーマです。
スマホ対応でつまずく5点と、手を打つ時期
スマホ対応のつまずきは、公開直前に気づくと手戻りが大きくなります。要件定義期・構築期・公開直前のどの段階で手を打つべきかを整理します。
PC画面をそのまま縮小して載せる(要件定義期)
PC向けの画面をそのまま縮小表示するだけでは、先に述べた「業務の切り出し」が行われません。要件定義の段階で、現場で行う業務を4つに絞る作業を先に済ませておく必要があります。
型番の手入力しか用意しない(要件定義期)
入力を減らす手段(再発注・お気に入り・ステッパー・バーコード)を要件に含めずに進めると、後から追加する改修コストが発生します。要件定義の段階で、先に挙げた4つの方法を検討しておくべきです。
ログアウトが頻発する設定にする(構築期)
セッション保持の設計を構築の終盤に見直すと手戻りが大きくなります。金額や承認に関わる操作の前だけ再認証を求める、という線引きは構築の早い段階で確定させます。
通信が悪い現場を想定せず、二重発注を防げない(構築期)
通信断からの再送・二重送信の防止は、構築の後半で追加しようとすると設計の作り直しになりやすい箇所です。工事現場・屋外を対象に含める場合は、構築期に組み込むことが原則です。
管理者向けの機能までスマホに詰め込む(公開直前)
公開直前になって「念のため」管理機能までスマホ画面に追加すると、先に引いた線が崩れ、現場での操作が再び複雑になります。線引きは公開直前まで維持することが大切です。
まとめ:スマホ対応は画面ではなく、切り出す業務で決まる
本稿では、BtoB ECのスマホ利用を「画面の縮小」ではなく「業務の切り出し」として設計する考え方を整理しました。要点を3つに集約すると、第一に、現場は店舗・倉庫・工事現場・移動中の4類型に分かれ、通信条件も端末の持ち主も異なるため、まず自社の対象を当てはめる必要があります。第二に、現場で最初に削るべきは型番の手入力とログインであり、再発注・お気に入り・ステッパー・バーコードの4方法とセッション保持の設計が実務上の要となるでしょう。第三に、スマホで完結させる業務とPCに残す業務の線を先に引き、全機能を載せない判断が定着を左右します。まず自社の現場を4類型のどれかに当てはめ、スマホで完結させる業務を1つ選ぶことが、次の一手になります。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
よくある質問
BtoB ECはスマホだけで発注まで完結できますか。
定番品の再発注であれば完結できます。ただし新規取引先の登録や複雑な見積の作成はPC側に残す設計が現実的です。スマホで完結させる業務とPCに残す業務をあらかじめ分けておくことが前提になります。
レスポンシブ対応をすれば現場で使える状態になりますか。
レスポンシブ対応だけでは不十分です。画面がスマホに合わせて縮小表示されても、型番の手入力やログアウトの頻発といった現場特有の摩擦が残るためです。業務の切り出しと入力負荷の削減を合わせて設計する必要があります。
取引先の私物スマホから発注してもらう場合、何を先に決めるべきですか。
端末の持ち主と権限の範囲を先に決めるべきです。私物端末では共有端末とは異なるログイン・セッションの扱いが必要になります。共有端末・私物端末の権限設計は別記事で詳しく扱っています。
専用アプリは用意すべきですか。
最初から用意する必要はありません。まずブラウザで発注・在庫確認・承認・履歴照会の4業務が成立するかを検証し、通知やカメラ機能が業務上必須になった時点で専用アプリを検討する順序が現実的です。
通信が届きにくい現場ではどう運用すればよいですか。
送信前に入力内容を端末側へ一時保存し、通信復帰後に再送する仕組みを用意します。あわせて送信済みの注文番号を画面に明示し、同じ内容を二重に送信しないよう防止することが必要です。
- *1 出典:総務省「令和7年版 情報通信白書」(2025年7月公表、https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd111220.html)
- *2 出典:総務省「令和6年通信利用動向調査(企業編)」図表3-2 クラウドサービスの利用状況(産業分類別)・図表4-4 テレワークの導入形態・調査の概要(2025年5月30日公表・調査時点2024年8月末、https://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR202400_002.pdf)
- *3 出典:厚生労働省「建設業・ドライバー・医師等の時間外労働の上限規制」(2024年4月適用、https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/roudoukijun/gyosyu/topics/01.html)
- *4 出典:一般財団法人流通システム開発センター(GS1 Japan)「JANコード(GTIN-13、GTIN-8)」(https://www.gs1jp.org/code/jan/about_jan.html)
画像の出典元
- BtoB EC スマホ 現場 利用のイメージ/Photo by Maxence Pira on Unsplash
- BtoB EC スマホ 現場 利用のイメージ/Photo by Abhijeet Gaikwad on Unsplash
- BtoB EC スマホ 現場 利用のイメージ/Photo by Andreas Haubold on Unsplash