この記事でわかること
BtoB-ECの導入相談で両極端な判断をよく見ます。「将来を考えて最初から全部作りたい」と「コストを抑えてとにかく小さく始めたい」——どちらも間違いではありませんが、どちらも単独では失敗のリスクを持ちます。正しいのはその中間にある「設計は徹底・実装は段階的」という進め方です。本記事では、フェーズ分けの判断基準と各フェーズで決めるべきことを整理します。
2つの失敗パターン
BtoB-ECの導入設計には、対照的な2つの失敗があります。
| 失敗パターン | 典型的な判断 | 結果 |
|---|---|---|
| 作りすぎ | 「将来必要になるかもしれない機能も今のうちに」「抜け漏れがないよう全部入れたい」 | 開発期間の長期化・初期費用の膨張・使われない機能が増え保守負担が上がる・リリース後に「こんな機能は要らなかった」が発覚する |
| 設計省略のスモールスタート | 「コストを抑えて最低限で始める」「細かいことは後で考えよう」 | 価格ロジック・基幹連携・権限設計が後付けになり、構造変更を伴う改修が繰り返し発生する。後から直すほど割高になる |
どちらも「今の判断を最適化しようとした結果」という共通点があります。作りすぎは「今想定できることを全部やる」最適化。設計省略は「今のコストを最小化する」最適化。いずれも将来の変化を正面から設計していない点で同じです。
「設計は徹底・実装は段階的」の原則
この2つの失敗を避ける原則があります。
受注フロー・価格ロジック・例外処理・基幹連携・将来シナリオは初期に徹底的に整理する。ただしその全部を初期フェーズで実装する必要はない。「将来追加できる構造」で、今必要な機能から始める。
これが「正しいスモールスタート」と「設計省略のスモールスタート」の違いです。
| 設計省略のスモールスタート | 正しいスモールスタート | |
|---|---|---|
| 受注構造の整理 | 省略・後回し | 初期に徹底的に整理する |
| 価格ロジックの設計 | 「今のパターンだけ対応できれば十分」 | 将来の複雑化を前提にしたデータ構造で設計する |
| 基幹連携の方針 | 「CSVでいい」で固定 | CSV連携から始めるが、API移行できる構造で設計する |
| 初期の実装範囲 | 小さい | 小さい |
| 2年後の改修コスト | 高い（構造変更が必要） | 低い（追加・拡張で対応できる） |
なぜ「作りすぎ」が起きるのか
「作りすぎ」には構造的な原因があります。単なる慎重さや完璧主義の問題ではありません。
- 社内合意のコスト：関係部署が多いほど「あの業務はどうするのか」という声が出る。全員を納得させるために要件が膨らむ。「今回のスコープ外」と言い切れないまま進むと肥大化する
- 後から作ると高いという懸念：「今まとめてやった方が安い」という判断は一見合理的。ただし「今は不要な機能」を作るコストと「後から追加するコスト」を正確に比較できている場合は少ない
- 要件の出し方の問題：「現状の業務を全部洗い出す」アプローチをとると、レアケースも要件として上がってくる。頻出か否かの分類をしないまま要件一覧を作ると、自動的に肥大化する
- ベンダー側のインセンティブ：初期費用が大きいほどベンダーの売上は上がる。「全部まとめてやりましょう」という提案は、顧客の利益と必ずしも一致しない
フェーズ分けの判断基準
何をフェーズ1で実装し、何をフェーズ2以降に回すかの判断基準です。
| 機能・要件 | フェーズ1 | フェーズ2以降 | 判断の軸 |
|---|---|---|---|
| 受注の主要フロー | ◎ 必須 | — | これがなければECとして機能しない |
| 価格ロジック（主要パターン） | ◎ 必須 | — | 主要取引先が使える状態にする |
| 価格ロジック（拡張パターン） | 構造だけ設計 | ◎ 追加実装 | データ構造は初期から拡張前提にしておく |
| 頻出例外処理（月10件以上） | ◎ 組み込む | — | 運用補完コストが高いため初期から仕組み化する |
| レア例外処理（月1〜2件以下） | 運用対応 | △ 状況次第 | システム化のコストが運用コストを上回らない |
| 基幹連携（CSV） | ◎ 推奨 | — | API移行できる構造で実装すること |
| 基幹連携（リアルタイムAPI） | △ 件数次第 | ◎ 規模拡大後 | 1日100件超・在庫精度が重要な場合は前倒し検討 |
| 権限設計（基本ロール） | ◎ 必須 | — | 拡張できる構造で設計しておく |
| 権限設計（承認フロー・部署別） | 構造だけ設計 | ◎ 組織拡大後 | 取引先が増えてから必要になるケースが多い |
| 分析・レポート機能 | — | ◎ 運用安定後 | 稼働前は何を分析すべきか決まっていないことが多い |
判断の核心は「業務が回るために必要か」「後から追加するとコストが大きく変わるか」の2点です。後から追加してもコストが変わらない機能は、フェーズ2以降で十分です。
3フェーズの進め方と各フェーズで決めること
フェーズ1：コア業務の実装
目標は「主要取引先が主要商品を発注でき、それが基幹に反映される」状態です。完璧である必要はありません。
- 実装する：主要受注フロー・主要価格パターン・頻出例外処理・基本的な基幹連携（CSV可）・基本権限設計
- 設計だけしておく（実装は後）：拡張価格パターンのデータ構造・API連携の接続仕様・承認フローのロール設計
- スコープ外にする：月1〜2件以下のレア例外・分析機能・BtoC併用・多言語対応
フェーズ2：頻出例外と連携の強化
フェーズ1の稼働から3〜6ヶ月後が目安です。実際に運用して見えてきた問題を設計に反映します。
- 対象：フェーズ1で「運用でカバー」していた頻出例外のシステム化・注文件数増加に伴う基幹連携の強化・新たに必要になった価格パターンの追加
- 判断のポイント：稼働後の実データを見て「どの例外が何件発生しているか」「どの手作業に何時間かかっているか」を計測してから優先順位を決める
フェーズ1で設計の余白を作っておけば、この追加は低コストで実施できます。設計省略のスモールスタートとの差がここで出ます。
フェーズ3：高度化・分析・拡張
フェーズ2の安定後、事業の成長に合わせて必要なものを追加します。
- リアルタイムAPI連携への移行
- 承認フロー・部署別権限の追加
- 受注データの分析・ダッシュボード
- 新商材カテゴリ・新取引形態への対応
- BtoC併用・多言語対応（事業拡張の場合）
フェーズ3の内容は、フェーズ1・2の稼働実績と事業の方向性を見てから決めます。導入前に「フェーズ3でこれをやる」と固めすぎると、実態に合わない計画になります。
設計で先に決めておくべきこと
フェーズ分けが機能するためには、実装前の設計工程で以下を決めておく必要があります。実装フェーズを分けても、設計が省略されていれば後から直す羽目になります。
- 1
受注フローの全体像を書き出す
現在の受注フロー（FAX・電話・メール）を洗い出し、誰が何をどのタイミングでやるかを可視化します。この整理なしに設計に入ると、後から「聞いていなかった処理」が次々と出てきます。
- 2
価格ロジックを全パターン書き出し、将来の増加を前提に設計する
今の価格パターンを全件書き出した上で、「3年後にどう変化するか」を想定します。今は3パターンでも、将来10パターンになる構造なら、10パターンに耐えるデータ設計で初期から作ります。
- 3
例外処理を「頻出・レア・EC外」の3種類に分類する
月10件以上の頻出例外はフェーズ1で仕組み化。月1〜2件以下はフェーズ2以降か永続的に運用対応。ECの外で処理する例外（高度な交渉が必要なものなど）は明確にEC外と定義します。
- 4
基幹連携の将来方針を決めておく
フェーズ1でCSV連携を使う場合でも、「フェーズ2でAPI連携に移行する」方針なら、EC側のデータ構造をAPI連携前提で設計します。この方針を最初に決めておかないと、移行時に大規模改修が必要になります。
あわせて読まれています
よくある質問
フェーズ1の範囲はどうやって決めればいいですか？
「主要取引先（上位20〜30%）が主要商品（受注件数上位80%）を発注でき、それが基幹に反映される」状態をフェーズ1のゴールにするのが基本です。全取引先・全商品・全パターンに対応しようとするとフェーズ1が肥大化します。まず「これだけ動けば月次の業務が回る」という最低ラインを定義することから始めてください。
段階設計にすると、フェーズ1とフェーズ2の間で取引先に混乱が生じませんか？
取引先への影響は、フェーズ1でカバーする取引先の範囲設計で決まります。フェーズ1では主要取引先のみを対象にし、フェーズ2以降で対象を広げる進め方が一般的です。フェーズ1稼働後に機能追加・改善が入ることは、取引先に事前に伝えておくことで混乱を防げます。むしろ完璧を目指して長期化したリリースの方が、取引先への影響期間が長くなります。
「設計は徹底的に」というのに、具体的にどれくらいの時間をかけるべきですか？
プロジェクト全体の工程のうち、設計・要件定義に20〜30%程度かけるのが目安です（開発規模によって異なります）。感覚として、「受注フロー図と価格ロジック一覧が完成し、ベンダーと合意できている状態」になるまでを設計工程とみてください。この状態で開発に入れているかどうかが、後の改修頻度に直結します。
フェーズ分けをベンダーに提案したら「一括で設計した方が安い」と言われました。どう判断すればいいですか？
「フェーズをまとめると開発効率が上がる」は事実の面もあります。ただし「今は不要な機能」を含めた一括開発は、不要な機能のコストを先払いすることです。ベンダーの主張が「まとめると効率的」なのか「まとめると売上が大きい」なのかを見極めてください。「フェーズ2の機能を今作る場合と、6ヶ月後に追加する場合の費用差」を具体的に出してもらうと判断しやすくなります。
「どこまでフェーズ1で作るべきか」——一緒に整理します
受注構造の整理・価格ロジックの棚卸し・フェーズ分けの判断。「何から手をつければいいかわからない」段階でのご相談も歓迎します。構築の押し売りは一切しません。
投稿者プロフィール
- 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
上岡龍太郎 / ダウンタウン
