EC担当者の社内提案が通らない理由｜数値分析を4項目に翻訳する型

社内提案が通らないのは、熱意でも数字の量でもない。決裁者が判断に使える形になっていないからである。必要なのは4項目だけ。現状の数字、原因、打ち手、そしてそれが決裁者の追っている数字のどれを動かすか。

• 決裁者は現場を見ていない。見ているのは判断できる形になった数字だけである
• 支援してきた側から見ると、落ちた提案に共通して欠けていたのは決裁者が負っているKPIへの接続だった
• 予算・タイミング・他部署の事情で落ちる提案もある。ただしその3つは、提案を出す前に確認できる

受注件数、1件あたりの処理時間、キャンセル率、SKUごとの在庫回転。現場の数字は、たいてい担当者の手元にある。RMSの受注一覧をCSVで落として、スプレッドシートに日次で積んでいる人も珍しくない。それでも会議で出すと「大変だね」で終わる。数字を出したのに、何も動かない。

この状態で多くの人が取る対処は、数字を増やすことである。集計期間を延ばし、グラフを足し、比較対象を増やす。それで通った例は、あまり見たことがない。この記事では、EC支援会社としてクライアント企業の決裁者に提案してきた側から見えている「落ちる提案に共通していたもの」と、その裏返しとしての型を書く。どの指標をどう見るかという分析手法は各論なので扱わない。扱うのは、手元にある数字を他人が判断できる形に翻訳する部分だけである。

数字を出しても通らないのは、量ではなく形の問題

部長がRMSの受注一覧を開くことはない。開いたところで、どの行が手作業でどの行が自動処理なのかは画面から読み取れない。セラーセントラルの注文管理も同じで、そこにあるのは注文の羅列であって、その裏で誰が何分使っているかは表示されない。決裁者が現場を見ていないというのは、怠慢の話ではなく、単に見えないという話である。

だから決裁者が判断材料にできるのは、現場そのものではなく現場について書かれた記述だけになる。提案の可否は記述の出来で決まる。「実際に見てもらえれば分かるのに」で止まると、ここから先へ進めない。見てもらっても分からない。分かる形に書き直すしかない。

作業量の数字は判断材料にならない

現場から出てくる数字は、たいてい作業量の数字である。「月間1,200件の受注処理をしている」「問い合わせが1日80件来る」「出荷指示を1日3回に分けて出している」。事実として正しいが、判断材料としては機能しない。1,200件が多いのか少ないのか、放置していいのかを、決裁者は判断できないからだ。

判断材料になるのは変化の数字、つまり「何が何になるか」である。同じ受注処理の話でも、次のように書き換わると性質が変わる。

• 作業量: 月間1,200件の受注処理をしている
• 変化: 受注CSVの取り込みからOMSへの登録までを手作業でやっているため、13時の出荷指示締めに間に合わない日が週2〜3日ある。締めに乗らなかった注文は翌日出荷になる

後者には「今こうなっている」と「このままだとこうなる」が入っている。決裁者はここで初めて、放置した場合のコストを見積もれる。前者にはそれがない。

ただし、落ちる理由の全部が形の問題ではない

ここは正直に書いておきたい。提案が落ちる理由には、記述と関係のないものが確実に混じっている。代表的なのは次の3つである。

• 予算がない — 期中で執行枠が残っていない。金額の大小ではなく、枠の有無で決まっている
• 今ではない — 基幹システムの入れ替えや大型セールの準備が走っていて、着手できる人がいない
• 他部署が動かない — 情報システム部門や物流側の工数が必要で、その部署の優先順位に入っていない

この3つに当たった提案は、書き方を変えても通らない。型の問題ではないからだ。ただし言い換えれば、この3つは提案を出す前に分かる。期初の予算資料に枠が書いてある。今期の優先プロジェクトは部門会議の冒頭スライドに載っている。他部署の工数は、担当者に「これ、依頼したらいつ頃着手できますか」と1回聞けば分かる。

確認せずに出して落ちたのなら、それは形以前の問題である。逆にここを潰しておくと、落ちた理由が「形」だけに絞られる。次に何を直せばいいかが分かるという意味で、事前確認は提案の精度を上げるより先にやる価値がある。

落ちた提案に共通して欠けていたのは、決裁者が追っている数字への接続だった

ここからが、この記事で一番書きたかったことである。

EC支援会社としてクライアント企業に提案していると、自社の稟議とは違う見え方をする。相手が変われば決裁者も変わるので、同じ型の提案を別の会社に出す機会が繰り返し発生する。その立場から、落ちた提案を並べて共通点を探したときに残ったのは、提案の完成度ではなかった。

「KPIに沿ったニーズに合う提案ができなかった」。これが、支援してきた側から見た共通項である。数字は入っている。原因の分析も筋が通っている。打ち手も現実的である。それでも通らない。理由は単純で、その打ち手が、目の前の決裁者が数字で追っているものに紐づいていなかったからだ。

断り書きを入れておく。これは一人の観察であって、統計ではない。何社中何社だったのか、通過率が何%変わるのかは測っていない。社名も実額も出せない。だから「提案が通らない原因はKPIとの不一致である」という一般法則としては書かない。書けるのは、落ちた提案を横に並べたとき、そこに共通して欠けていたのはここだったという観察までである。

「良い提案ですね」で終わる提案の正体

KPIに接続していない提案は、否定されない。むしろ好意的な反応が返ってくることが多い。「良い提案ですね」「たしかにそこは課題です」「持ち帰って検討します」。そして動かない。

決裁者の側に立つと理由がはっきりする。決裁者は自分が四半期ごとに上へ報告する数字を持っている。EC部門なら、売上、粗利率、広告費のROAS、在庫回転、返品率、あるいは人件費。それらのうちどれを、いつまでに、いくつにするかを負っている。提案がそのどれにも乗らないとき、決裁者の側では「反対」ではなく「優先度が最下位」として処理されているように見える。否決の連絡すら来ないまま滞留している提案は、この状態に当たる。

受発注業務の自動化はこの罠にはまりやすい。現場から見れば工数削減は明白な価値だが、決裁者が今期追っているのが粗利率だとすると、工数の話は直接には乗らない。

ここで「削減した時間を商品ページの改善に回せば売上が上がります」と書きたくなる。これは通りにくい。受注処理を担当している人がページ改善をできるとは限らないし、できたとしても粗利率が何ポイント動くのかは答えられない。決裁の場で「そのシミュレーションは」と聞かれた時点で止まる。

工数削減が確実に接続できる先は、そこではない。残業代、繁忙期のスポット人員費、外部委託の従量課金分。金額として実在する費目だけである。粗利率に接続したいなら、工数の話とは別に、粗利率に効く打ち手を出したほうが早い。接続先が見つからないときに無理やり接続すると、その提案は1回通っても、2回目の説明が難しくなる。

決裁者のKPIは、推測せずに拾う

ここで「上司の関心を読む」という話にすると、途端に精度が落ちる。読まなくていい。KPIはたいてい文書として存在している。

• 期初の部門方針資料 — 今期の重点指標がそのまま書いてある。多くの場合3つ以内に絞られている
• 定例会議の冒頭スライド — 毎回同じ項目が並んでいれば、それが報告義務のある数字である
• 上司がさらに上へ出している資料の項目名 — 見せてもらえるなら、これが一番早い
• 本人に聞く — 「今期、部として一番見られている数字はどれですか」は、聞いて角の立つ質問ではない

拾ったKPIに自分の打ち手が乗らないことも当然ある。そのときは「このKPIには効きません。効くのはこちらです」と書く。効かないKPIの名前を借りるより、効く相手を探し直すほうが速い。

提案は4項目で足りる

接続先が分かったら、書く中身は4項目でいい。増やすほど通らない。理由は2つある。1つは決裁者が資料に使える時間が短いこと。もう1つは、項目が増えるほど論点が割れて、本筋以外のところで質問と保留が発生することである。資料のページ数が増えるほど、「この数字の出典は」という質問が付く確率が上がる。質問が1つ付けば、決裁はその分だけ後ろにずれる。

項目	書くこと	欠けたときに起きること
1. 現状の数字	今どうなっているか。件数・時間・率のいずれか。測定期間と対象範囲を添える	「本当にそんなに困っているのか」の確認から始まり、次回持ち越しになる
2. 原因	なぜそうなっているか。工程名まで降りる。「属人化」「非効率」で止めない	打ち手が対症療法に見え、「他にも同じ問題が出るのでは」と論点を広げられる
3. 打ち手	何をするか。誰が、いつから、どの範囲で。初期費用と運用費用を分ける	検討はされるが実行担当が決まらず、議事録に残って終わる
4. 動くKPI	その打ち手が、決裁者が負っている数字のどれを、どちらの方向に動かすか	否定されずに滞留する。落ちた提案に共通して欠けていたのはここだった

4項目の順序には意味がある。1と2は現場にしか書けない部分で、3は現場と決裁者の共通言語、4は決裁者側の言語である。現場の言語から始めて、決裁者の言語で終わる。逆順に並べると根拠が後出しになり、信用されにくい。

5つ目を足すなら「崩れる条件」

4項目で足りるが、1つだけ足す余地があるとすれば「この打ち手が効かなくなる条件」である。前提が崩れたら効果が出ない、という条件を先に書いておく。

たとえば受発注の自動化なら、「SKUマスタのモール別商品番号が整理されていること」「月間受注件数が現状水準を下回らないこと」「導入作業が繁忙期と重ならないこと」。これを書いておくと、実行後に効果が出なかったときに「読み違い」ではなく「条件が崩れた」として扱える。2回目以降の提案が通り続けるかどうかは、たいていここで決まる。

ただし、これは4項目の代わりにはならない。崩れる条件だけ丁寧に書いてKPIへの接続がない提案は、慎重で誠実に見えて、やはり滞留しやすい。

4項目を、受発注の工数削減で埋めてみる

型だけ見ても書けるようにならないので、1つ埋めてみる。題材は、楽天・Amazon・自社ShopifyでSKUが重複している中規模のショップで、受注処理が手作業で回っている状態とする。以下に出てくる数値は、説明のために置いた仮の値であり、実在の案件のものではない。

1. 現状の数字

「大変です」ではなく、工程を分けて数える。手作業が発生しているのは、実際には前後2か所である。

• 前工程 — RMSの受注一覧からCSVをダウンロードし、セラーセントラルの注文レポートを別途取得し、Shopify Adminの注文を書き出して、3本を1つの出荷指示フォーマットに手で寄せてWMSへ渡す
• 後工程 — 倉庫から返ってくる出荷実績CSV（送り状番号つき）を、RMS・セラーセントラル・Shopify Adminにそれぞれ登録して出荷確定する

この2つは別の工程である。前工程が遅れると出荷そのものが翌日に落ちる。後工程が遅れると、荷物は出ていても各モール上の出荷確定が翌営業日にずれる。混ぜて「受注処理が大変です」と書くと、打ち手も効果も曖昧になる。数字は分けて出す。

• 対象期間: 平日40日間
• 前工程（受注取り込み〜WMSへの出荷指示）の手作業: 1日あたり平均2時間40分（担当2名分を合算した想定）
• 13時の出荷指示締めに間に合わなかった日: 40日中9日
• 後工程（出荷実績の取り込み〜各モールへの伝票番号登録）の手作業: 1日あたり平均50分
• 伝票番号の登録が翌営業日にずれ込んだ件数: 月間平均11件

ここで大事なのは、実額や業界平均を持ち出さないことである。自社で数えた値だけで足りる。むしろ出典の怪しい業界平均を1つ入れた瞬間に、質問がそこへ集中する。

2. 原因

「属人化しているため」では止まる。工程名まで降りる。

前工程の原因は、モールごとにCSVの列名と文字コードが違うことと、商品管理番号とモール別商品番号の対応表が担当者のローカルExcelにしか存在しないことである。だから取り込みのたびに突き合わせが発生する。新規SKUが追加されると対応表の更新が1人に集中し、その人が休むと止まる。

後工程の原因は別にある。倉庫から返ってくる出荷実績CSVの並びと、各モールが要求する取り込みフォーマットが一致していないため、送り状番号と注文番号の対応を毎回並べ替えている。ここまで書くと、打ち手が「頑張る」以外になる。

3. 打ち手

この場合の打ち手は、いきなりOMS導入とは限らない。第1段階として対応表をマスタとして共有領域に出し、モール別の変換テンプレートを前工程・後工程それぞれで固定する。第2段階でOMSまたはAPI連携（楽天のRMS Web ServiceやSP-API）による自動取り込みに移す、という二段構えにできる。

提案としては、第1段階を今回の決裁対象にするほうが通りやすい。金額が小さく、失敗しても戻せるからだ。そして第1段階で測った値が、第2段階の提案における「現状の数字」になる。

4. 動くKPI

ここが本題である。相手が誰かで書き分ける。

• 物流責任者が出荷リードタイムを負っているなら: 前工程を短縮すると、締めに間に合わない9日/40日が減る
• CS責任者が問い合わせ件数を負っているなら: 後工程を自動化すると伝票番号の登録が当日中に終わる。発送完了メールと配送状況の更新が当日に飛ぶので、「まだ発送されていないのですが」という問い合わせが減る
• EC部長が人件費を負っているなら: 前後合わせて1日3時間半前後の手作業のうち、一定量が空く。ただし「人を減らせます」とは書かない。空いた時間の行き先を書く

1つ目と2つ目は、似ているようで打ち手が違う。締めに乗らないのは前工程の問題、伝票番号の登録が翌日にずれるのは後工程の問題である。両方まとめて「配送が遅れます」と書くと、決裁者が打ち手を1つに絞れなくなる。どちらのKPIに効かせたいのかを先に決めて、その工程の数字だけを出す。

3つ目にも補足がいる。工数削減の提案で「削減」だけを書くと、決裁者は人員削減の話として受け取るか、「浮いた時間は結局別の作業で埋まる」と読む。どちらも決裁には向かわない。空いた時間の行き先（繁忙期のスポット人員を今年は入れない、レビュー対応を外注から内製に戻す）まで書いて初めて、金額として実在する費目に接続する。

同じ内容でも、決裁者の決裁範囲と制約で単位を変える

前章の最後でやったことを、一般化しておく。同じ打ち手でも、相手が決裁している範囲によって、出す単位が変わる。

相手	決裁している範囲	出す単位
現場リーダー	誰が何をやるかの割り当て。既存業務の順番の入れ替え	工数と当番。「月40時間」ではなく「Aさんの午前が空く」「締め後の残業が消える」
部長・部門長	部門予算の枠内での支出。他部署への依頼	金額と期間。初期費用と月額を分け、年額に直す。稟議区分に収まるかを先に書く
役員・経営	枠そのものの増減。事業の優先順位	利益率とリスク。粗利への寄与と、やらなかった場合に起きること

翻訳先を間違えた資料は、内容が正しくても止まる。現場リーダーに年額換算のコスト表を出しても、その人は金額を決裁できないので判断のしようがない。逆に役員に「Aさんの午前が空きます」と出しても、その人はAさんを知らない。どちらも、正しい情報を判断できない人に渡している。

単位の次に、相手が今置かれている制約を見る

単位を合わせても、タイミングで落ちることがある。決裁者は真空で判断していない。

• 予算期 — 期末に近いほど新規支出は通りにくく、期初は逆に枠が余っている。同じ提案が2か月ずれただけで結果が変わる
• 進行中の優先プロジェクト — 基幹入れ替え、モール新規出店、大型セールの準備。ここに人が張り付いている間は、いい提案ほど「後で」になる
• 過去の失敗 — 前に似たツールを入れて定着しなかった経験があると、同じカテゴリの提案は説明の出発点が変わる。効果ではなく「前回と何が違うか」から書く必要が出る

この3つは、提案書の中では1〜2行にしかならない。それでも、書いてあるかどうかで読まれ方が変わる。「今期は基幹の入れ替えがあるため、着手は下期を想定しています」の1行が入っているだけで、決裁者は「こちらの事情を分かっている人の提案」として読む。

なお、根回しや人間関係の作り方はこの記事では扱わない。型の話と人の話を混ぜると、どちらも精度が落ちる。ここで書けるのは、資料の形と単位までである。

一度落ちた提案を、もう一度出すために残しておくもの

提案は1回で通るものばかりではない。支援してきた側から見ると、通ったもののなかには2回目以降だったものが確実に混じっている。ところが再提案の準備をしている人は少ない。理由ははっきりしていて、1回目に落ちた理由を記録していないからである。

落ちた直後に残しておくべきなのは、自分の解釈ではなく相手の言葉そのままである。「効果が読めない」と言われたのか、「今期は枠がない」と言われたのか、「他部署の合意が先」と言われたのか。この3つは似た温度で発話されるが、再提案の設計はまったく別になる。

• 効果が読めない → 小さい範囲で実測を取る。1モール・2週間でいい。次は現状の数字が自社実測に変わる
• 今期は枠がない → 内容は直さない。期が変わるタイミングで、同じ資料を日付だけ更新して出す
• 他部署の合意が先 → 提案の相手が変わる。まず情報システムや物流に、決裁ではなく工数見積もりだけを取りに行く

解釈を挟むと、この分岐を間違える。「たぶん予算の問題だろう」とまとめてしまうと、実際には効果への疑問だった場合に、次も同じ理由で落ちる。だから聞いたままを書く。会議直後の5分で足りる。

もう1つ。再提案が通るとき、内容が良くなったからとは限らない。期が変わった、決裁者が変わった、同業が導入した、既存契約の更新月が来た。条件が変わったことが効いていた、と後から分かることがある。だとすれば、手元に「いつでも出せる状態の提案」を持っていることの価値が高い。作り直しから始めると、条件が変わった週に間に合わない。

提案時の4項目は、提案した時点にしか手元にない

ここまで、決裁者に向けた記述の話をしてきた。最後に、その記述の宛先をもう1つ増やしたい。話題を変えるのではなく、同じ主張の適用範囲を広げるだけである。

この記事の主張は「決裁者は現場を見ていない。見ているのは記述だけである」だった。この決裁者は、上司や役員に限らない。半年後の自分も、そのときの現場を見ていない。読めるのは、そのとき残した記述だけである。

数か月後に消えているもの

ここから先は、観察ではなく論理として書く。打ち手を実行して数か月経つと、手元に残っている情報は思っているより少ない。残りにくいのは主に次の3つである。

• Beforeの数字 — 実行前の工数を測ったスプレッドシートは上書きされている。受注データやアクセス解析には保持期間があり、遡って取り直せないことがある
• なぜその打ち手を選んだか — 検討して外した案と、外した理由を含む。OMS導入ではなくマスタ整備から始めたような判断は、決めた時点では自明なので、書き残す動機がない
• 動くと見込んだKPIと、実際に動いた数字 — 提案時に「これを動かす」と書いた指標が、実行後にどうなったか。追いかける担当が決まらないまま次の仕事に移ると、確認されずに流れる

提案の4項目と、5つ目の「崩れる条件」は、この3つと重なっている。現状の数字がBefore、原因と打ち手の組み合わせが選択の理由、動くKPIが3つ目の「見込んだ側」にあたる。実際に動いた数字だけは実行後にしか出ないが、それを何で測るかは提案した時点で決まっている。崩れる条件は「何を捨てたか」の裏返しとして、選択の理由に含まれる。つまり4項目は、提案した時点にしか揃わない情報の集合である。実行が終わってから集めようとしても、もう半分は残っていない。

書けないのは、経験がないからではない

実行後に自分の仕事を説明しようとすると、多くの人は「何をやったか」しか書けなくなる。受発注を自動化した、OMSを入れた、という工程の羅列である。読む側から見ると、それは作業量の数字と同じ性質を持つ。多いのか少ないのか、難しかったのか簡単だったのかが判断できない。

足りないのは経験ではない。Beforeと、選択の理由と、動いたKPIである。そしてそれらは、経験の量とは無関係に、提案時点で記録していたかどうかだけで決まる。職務経歴書が書けないという状態の一部は、経験の不足ではなく、提案時点の記録の不在として説明できる。これは筋の話であって、統計で確かめたわけではない。ただ、4項目が提案時点にしか揃わないことと、実行後に手元から消えることを並べると、この帰結は自然に出てくる。

社外に持ち出すときに書き足すもの

社内提案の読み手と、社外の読み手には決定的な違いが1つある。社内の決裁者は自社を知っている。SKU数も、モール構成も、繁忙期も、前提として共有されている。社外の読み手は何も知らない。

だから、社内向けの4項目をそのまま外に出しても伝わらない。とはいえ、書き足す必要があるのは前提の説明だけである。年商規模、SKU数、チャネル構成、チームの人数。この4つが冒頭に1〜2行あるだけで、同じ4項目が外の読み手にも判断できる形になる。型を作り直す必要はない。

逆に言えば、前提を足しても中身が「何をやったか」だけなら、外に出しても判断されない。社内で通らなかった記述が社外でだけ通る、ということもそう都合よくはいかない。判断できる形になっているかどうかは、宛先が変わっても同じ基準で効いている。

では、その記録に何を積み増せば評価が変わるのか。それはもう提案の型の外側にある話なので、別の記事に譲る。EC実務者はAI時代に何を学べばいいのかを先に読んでおくと、今から残す記録の粒度が変わるはずである。

よくある質問

数字が取れない業務は、どう提案すればいいか

取れないのではなく、まだ測っていないことが多い。問い合わせ対応や商品ページの修正のように記録が残らない業務でも、2週間だけ日次で件数と所要時間をメモすれば、それが現状の数字になる。業界平均を借りてくるより、期間の短い自社実測のほうが強い。それでも数値化できない場合は、件数ではなく発生した事故の回数（誤出荷、価格の設定ミス、在庫引当のずれ）で代替できることがある。

一度否決された提案を、再提案していいのか

問題ない。ただし、同じ資料をそのまま出すかどうかは否決の理由で決まる。予算やタイミングが理由なら、内容を直さずに期が変わってから出すほうがいい。効果への疑問が理由なら、小さい範囲での実測を1つ足してから出す。判断を間違えないために、否決の理由を相手の言葉のまま残しておく必要がある。

上司が数字を見ないタイプの場合はどうするか

数字を見ない決裁者でも、上へ報告する数字は持っていることが多い。本人が関心を持っている指標ではなく、本人が報告義務を負っている指標に接続すると届くことがある。それでも動かない場合は、資料の形ではなく人の側の問題になる。この記事の範囲を超えるため、ここでは扱わない。

提案が通ったあと、何を記録しておけばいいか

提案書そのものと、実行前の数字（測定期間と対象範囲つき）、検討して外した案とその理由、そして実行後に実際に動いたKPI。この4つを1枚に残しておく。実行が終わってからでは、外した案の理由が最初に消える。提案が通った週のうちに、提案書のコピーをそのまま保存しておくのが一番早い。

あわせて読みたい: EC売上の分析に、AIはどこまで使えるのか

あわせて読みたい：顧客をランク分けするところから数字を作りたい場合は、RFM分析を、ツールを買わずにスプレッドシートとAIで終わらせるで、注文明細3列だけで顧客ランクを出す手順を説明しています。

あわせて読みたい: CSV整形が毎回振り出しに戻る理由と、初回だけで終わらせる手順