EC・通販業界の経験をスキルシートで伝える書き方｜領域・注文の流れ・工程をそろえる

EC・通販の経験をスキルシートで伝えるときは、事業の形と規模、システムの領域、注文の流れのどこを担ったか、担当した工程の4点をそろえて書くのが基本です。「ECサイトの開発」だけでは、発注側は画面の改修なのか受注の連携なのかを判断できません。「複数モールと自社ECの受注一元化、在庫連携の設計と、出荷後キャンセルの例外処理の実装」まで書くと、経験の中身が伝わります。

同時に、ECの経歴は、売上の規模やブランド、セールの時期を書くだけで発注元が推測されやすい分野です。この記事では、4点のそろえ方、書かない情報の線引き、記入例を紹介します。スキルシート全体の構成はスキルシートの基本、守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここではEC・通販の経験に固有の書き方に絞ります。

要約の1行目で「表側か裏側か」を示す

EC・通販の案件は、サイトやアプリなど購入者から見える表側と、受注・在庫・基幹連携などの裏側とで、求められる経験がほとんど重なりません。スキルシートの冒頭の要約では、どちらが軸かを1行で示します。領域の分け方はEC・通販のIT案件の記事で説明しています。

• 軸の領域（例：自社ECのフロント開発と、注文手続きの導線の改善）
• 立場と工程（例：要件の整理からリリースまで、後半は小規模チームのリーダー）
• ほかに対応できる領域や技術（例：モールの注文取り込みのバッチ、データ基盤への連携）

両方を経験している場合は、年数の長い順ではなく、次に入りたい案件に近い順に並べると、読み手が判断しやすくなります。

プロジェクト欄は4点をそろえる

プロジェクトごとの欄では、使用技術に加えて次の4点を書きます。

3つ目の「注文の流れのどこか」は、受付、決済の確認、在庫の引当、出荷指示、出荷、売上の確定、キャンセル・返品のどこに関わったかを入口にすると書きやすくなります。流れの全体はEC・通販の業務知識の記事で整理しています。商材は「アパレル」「食品」「化粧品」など分野の名前までにとどめ、個別の商品やブランドは書きません。

成果は売上の実数でなく「何を、どう変えたか」で書く

ECの経験では、売上・コンバージョン率・会員数などの数字で成果を示したくなります。しかし、これらは取引先の経営の情報で、秘密とされていることが多い数字です。実数は書かず、次のような書き方に置き換えます。

• 変えたこと（例：注文手続きの画面を4画面から2画面に減らした）
• 測り方（例：A/Bテストで手続きの完了率を比べ、改善を確認した）
• 運用への効果（例：在庫数のずれによる注文キャンセルの問い合わせが減った）

率の改善幅も、組み合わせで事業の規模が推測されることがあります。迷う場合は「改善を確認した」「減った」と方向だけを書き、詳しくは面談で、話してよい範囲で口頭で説明します。

繁忙期の経験は「何に備えたか」で書く

セールや年末の繁忙期の対応は、EC・通販の案件で評価されやすい経験です。「セール対応」とだけ書かず、何に備えて何をしたかを書きます。

• 負荷試験の計画と実施、ボトルネックの調査
• 繁忙期前の変更の凍結と、リリース計画の調整
• 当日の監視の体制づくりと、障害時の切り戻し手順の準備

セールの名前や開催日を書くと、事業者が特定されやすくなります。「大型セール」「年末の繁忙期」などの表現にとどめます。

EC・通販の経歴で書かない情報

ECは、サイトそのものが一般に公開されているため、一つひとつは問題なくても、組み合わせると発注元が特定できることに気をつけます。商材の分野、カートの製品名、移行の時期、セールの名前が並ぶと、外から見て事業者を当てられることがあります。

特に、不正注文の検知の条件やセキュリティの対策は、書くこと自体が発注元の守りの弱点を示すことになりかねません。また、顧客の個人情報を含むデータの中身は、例としても書きません。個人情報保護法は、事業者に個人データの安全管理のための措置（第23条）や、委託先の監督（第25条）を求めています。委託を受けた立場で扱ったデータの中身を外に出すことは、取引先のこうした管理の外に情報を持ち出すことになります。

契約で秘密とされた範囲を書かないことが基準になります。参画した案件の業務委託契約や秘密保持契約で、経歴への記載について定めがある場合は、その定めに従ってください。不正競争防止法の営業秘密の考え方はスキルシートと守秘義務の記事で扱っています。EC・通販の案件で守るルールそのものはEC・通販の規制の記事をご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。

例1：受注一元化とモール連携

期間：20XX年〜20XX年（1年3か月）
案件概要：生活雑貨の通販事業者における、自社ECと複数モールの受注・在庫の一元化
規模・立場：開発チーム5名（自分は連携部分の設計と実装の担当、後半はサブリーダー）
対象の業務：各モールからの注文の取り込み、在庫の引当、各モールへの在庫数の反映、出荷後のキャンセル
担当した工程：現行の運用の調査、連携の基本設計、実装、結合テスト、本番切替
使用技術：PHP、MySQL、各モールのAPI、ジョブの管理ツール
工夫・成果：在庫数の反映の遅れで起きていた売り越しの原因を、取り込みの間隔と引当の時点に分けて調べ、反映の順番を見直した。切替後、売り越しによるキャンセルの問い合わせが減った

例2：自社ECのカート移行

期間：20XX年〜20XX年（10か月）
案件概要：アパレルの自社ECにおける、自社開発のEC基盤からSaaS型のカートへの移行
規模・立場：発注側のプロジェクトチーム（自分はPMOとして参画、外部の制作会社2社との調整を担当）
対象の業務：商品・会員・注文履歴・ポイント残高の移行、URLの引き継ぎ
担当した工程：移行計画、移行データの検証、受入テストの計画と実施、切替手順の作成
使用技術：SQL、表計算による照合、課題管理ツール
工夫・成果：ポイント残高の新旧比較の差を「端数の扱い」「失効日の計算」「移行の誤り」に分類する表を作り、運営担当者との確認の手戻りを減らした

どちらの例も、社名、ブランド名、製品名、時期の詳細、件数は書いていません。それでも、領域、注文の流れの位置、工程、工夫が書かれていれば、どの案件に合うかは読み手に伝わります。

面談で深掘りされやすい点

スキルシートで書いた内容は、面談で深掘りされます。EC・通販の案件で聞かれやすいのは、次のような点です。面談全般の準備は面談でよく聞かれる質問の記事で扱っています。

1. 担当した領域で、例外の扱い（出荷後のキャンセル、一部返品、決済の失敗）にどう対応したか
2. 外部サービスやモールの仕様変更、障害に、どう気づいてどう対応したか
3. 繁忙期に向けて、何を準備し、当日どう動いたか
4. 運営やマーケティングの担当者からの依頼を、どう整理して優先度をつけたか

4つ目は見落とされがちですが、EC・通販の案件では大事な問いです。事業部門との距離が近い案件ほど、依頼の受け方と進め方が評価に直結します。

よくある質問

売上の数字を書かないと、成果が伝わらないのではありませんか？

何を変えたか、どう測って改善を確かめたか、運用にどんな効果があったかを書けば、成果は十分に伝わります。発注側が知りたいのは、前の事業者の売上より、同じような課題に対してあなたがどう動くかです。数字の実数は契約で秘密とされていることが多いため、書かないのが基本です。

運用や保守の経験しかありませんが、どう書けばよいですか？

ECの運用・保守では、モールの仕様変更への追従、繁忙期の監視、在庫や注文のずれの調査など、評価される経験が多くあります。どの領域の、どんな変更や障害に対して、調査から修正、確認までのどこを担ったかを書きます。注文の流れの押さえどころはEC・通販の業務知識の記事が参考になります。

自分で運営しているネットショップの経験は書いてもよいですか？

書いてかまいません。仕入れから受注、出荷、返品対応までを一人で回した経験は、注文の流れ全体を知っている根拠になります。業務委託の案件と区別できるよう、個人の事業であることを明記し、使ったカートの種類や自分で作った仕組みを具体的に書きます。