MA・CRMツールのエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

MA・CRMツールのエンジニアのスキルシートは、プロジェクトごとに「どのツールで」「どの範囲を担い」「何とつないだか」をそろえ、見込み客の定義や同期の方式をどう決めたかまで書くと伝わります。MA・CRMの経験は、配信の作業から全体の設計まで幅が広く、読み手はまずその中のどこを担った人かを確かめるからです。

この記事では、MA・CRMならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルはMA・CRMのスキルの記事で解説しています。

「MAツール経験◯年」だけでは伝わらない

よく見かけるのが、スキル一覧に「MAツール（3年）」「CRM運用（2年）」とだけ書かれている形です。同じ3年でも、毎週のメール配信を担ってきたのか、シナリオとスコアリングを設計してきたのか、CRMとの連携を開発してきたのかで、まったく違う経験になります。

読み手が確かめたいのは、次の3つの組み合わせです。

• ツール：どのMA・CRMを扱ったか
• 担う範囲：運用、シナリオ・スコアリング設計、データ連携・開発、全体設計のどれか
• つないだシステム：CRM、Webサイトのフォーム、基幹システム、データ基盤など

スキル一覧は、この組み合わせが見える形で書くと、読み手が案件の条件と照らし合わせやすくなります。

ツールの名前は、実際に扱った製品の正式な名称で書きます。上の表のツール名は、書き方を示すための架空の表記です。

担当内容は具体的な言葉で書く

「設定を担当」「連携を担当」とだけ書くと、深さが伝わりません。MA・CRMのシートでは、扱った仕組みを具体的な言葉で書くのが基本です。

それぞれに、自分が設計から担ったのか、決められた設計どおりに作ったのかを添えると、任せられる範囲が伝わります。

つないだシステムとデータの規模を書く

MA・CRMの案件の難しさは、つなぐ先の数とデータの量で大きく変わります。プロジェクト欄には、次の項目を丸めた数で書いておくと、読み手が難しさを想像しやすくなります。

• 管理していた見込み客・顧客の規模（数万件、数十万件など桁が分かる程度）
• 動いていたシナリオの数
• 連携していたシステムの数と、同期の向き
• 配信の頻度（週に数回、月に数回など）

実際の件数や取引先の名前は、社外に出せない情報にあたることがあります。どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

シナリオとスコアリングは「決めた理由」まで書く

担当内容の欄に「シナリオ構築を担当」とだけ書くと、作業をしたのか、設計をしたのかが伝わりません。シナリオやスコアリングは、条件をどう決めたか、決めたあとにどう見直したかまで書くと、設計の力が伝わります。

記入例（架空）：導入のプロジェクト

工程：新規導入（要件の整理〜運用の立ち上げ、約6か月）
案件概要：法人向けのソフトウェア会社。展示会と資料請求で集めた見込み客を、表計算ソフトの管理からMAツールに移した
規模：見込み客は数万件規模、CRMと双方向に同期
役割：MAの設計担当（チーム4名のうち、データ設計とシナリオ設計の主担当）
担当内容：見込み客の段階の定義と、営業に渡す条件の取りまとめ。重複の判定のルールと統合の手順の設計。資料請求後のシナリオとスコアの付け方の設計
判断した点：営業部門は「資料請求した人はすべて渡してほしい」、マーケティング部門は「関心が高まってから渡したい」と考えが分かれていた。両方の過去の商談のデータを並べ、渡す条件を2段階に分ける案で合意を取った
成果：営業が受け取る見込み客の基準がそろい、渡したあとの対応の状況をCRMで追えるようになった

これは書き方を示すための架空の例です。業種、規模、判断の内容は、ご自身の経験に置き換えてください。

配信の安全管理の経験を書く

MA・CRMの案件では、配信の誤りを防ぎ、ルールを守る仕組みを作れるかも見られます。運用の担当者であっても、次のような経験があれば、項目を分けて書いておくと評価につながります。

• 配信停止の申し出が、すべての配信の仕組みに反映されるように整えた
• 同意を得た経路と日時を記録する項目を設け、記録を残す運用にした
• 送信元のドメインの認証設定（SPF・DKIM・DMARC）の見直しに関わった
• 配信前の確認の手順（テスト送信、件数の確認、承認の記録）を決めた

記入例（架空）：運用改善のプロジェクト

工程：運用改善（約1年、週3日の稼働）
案件概要：通信販売の会社。複数の部署がそれぞれメールを配信しており、配信停止の扱いがそろっていなかった
役割：MAの運用と改善の担当（1名、発注側の担当者2名と協働）
担当内容：部署ごとの配信リストと停止の扱いを調べて一覧にした。停止の情報を一か所で管理し、すべての配信で除外する形に組み替えた。配信前の確認の手順書を作り、承認の記録をチケットに残す運用にした
成果：配信停止の扱いが一つにそろい、部署をまたいだ配信の重なりも把握できるようになった

これも書き方を示すための架空の例です。

成果の数字の扱い

開封率やクリック率、商談につながった件数などの数字は、発注側の社外秘にあたることが多くあります。具体的な数字を書けない場合は、「配信停止の扱いを一つにそろえた」「営業へ渡す基準を決めた」のように、何が変わったかを言葉で示すほうが安全です。数字を書く場合も、どこまで出してよいかを確かめてからにしましょう。

数字が書けないことは、評価を下げる理由にはなりません。面談では、数字よりも、どうやって変化を確かめたかを聞かれることのほうが多い傾向があります。

他の経験の書き方

Web開発やデータ基盤、CRMの開発の経験がある方は、それを別のプロジェクトとして書きつつ、MA・CRMの案件に生きる要素を一行添えます。たとえば、APIの開発経験は連携の案件に、データベースの設計経験は見込み客のデータ設計に、営業部門での業務経験は引き渡しの条件の設計に結び付けて書けます。

要約の欄では、MA・CRMの経験を上に置き、他の経験は補足として書くと、応募の軸がぶれません。よくある失敗はスキルシートの失敗例の記事にまとめています。

よくある質問

配信の運用の経験しかありません。どう書けばよいですか？

運用の経験も、扱った配信の種類と、自分で工夫した部分を分けて書けば十分な判断材料になります。リストの抽出条件を見直した、配信前の確認の手順を作った、といった改善があれば、設計寄りの案件にも出しやすくなります。

複数のツールの経験は、どの順番で書けばよいですか？

応募する案件で使うツールに近いものを上に置くのが基本です。そのうえで、ツールごとの違いを、データの持ち方や同期の仕組みの違いとして一行で書き添えると、別のツールへの移りやすさが伝わります。

準委任の案件と請負の案件で、書き方は変わりますか？

書き方の型は同じですが、請負の案件では、自分が担った成果物と、その範囲を明確に書いておくと読み手に伝わりやすくなります。契約の形の違いは準委任と請負の違いの記事で解説しています。