MA・CRMツールのエンジニアのフリーランス案件で求められるスキルと経験

MA・CRMツールのフリーランス案件で見られるのは、見込み客のデータの設計と名寄せ、配信のシナリオとスコアリングの設計、送信元の認証や配信停止などメール配信の技術、同意と配信停止の管理、CRMなど他システムとのデータ連携、効果の計測の6つの分野です。どこまで深く求められるかは、経験の段階と担う範囲で変わります。

ツールの操作を覚えることは入り口にすぎません。案件で差がつくのは、データと配信のルールを決め、その理由を営業・マーケティングの両部門に説明できるかどうかです。この記事では、分野ごとのスキルと、段階ごとに求められる深さを整理します。

経験の段階で求められる深さ

同じ分野でも、経験の段階によって任される判断が違います。

段階は年数ではなく、どの判断を自分で行ったかで決まります。運用の段階でも、ルールの不備に気づいて改善を提案した経験があれば、設計の段階へ進む材料になります。

分野ごとに求められるスキル

見込み客のデータ設計と名寄せ

MAとCRMの土台は、誰をどの単位で管理するかの設計です。個人と会社をどう結び付けるか、どの項目を持たせ、入力の形式をどうそろえるかで、後のシナリオやレポートの精度が決まります。

• 個人・会社・商談などの単位と、その関係の設計
• 見込み客の段階（ライフサイクル）の定義と、段階が進む条件
• 重複の判定のキー（メールアドレスなど）と、統合のルール
• 項目の命名と入力形式の統一、使われていない項目の整理

重複した見込み客が放置されると、同じ人に同じメールが届く、スコアが分散するといった問題が起きます。名寄せのルールを決めて運用に組み込んだ経験は、どの段階でも評価されやすい部分です。

シナリオとスコアリングの設計

配信のシナリオは、誰に、どのきっかけで、何を、どの順番で届けるかの設計です。スコアリングは、行動や属性に点数をつけ、営業に渡す時期を判断する仕組みです。

• きっかけ（資料のダウンロード、セミナーの申込み、一定期間の無反応など）と分岐の設計
• 配信の頻度の上限や、複数のシナリオが重なったときの優先順位
• スコアの付け方と、営業に渡す条件、渡したあとの戻し方
• 効果を見て条件を見直す運用の仕組み

ここで問われるのは、ツールの機能より、営業とマーケティングの合意を取りまとめる力です。施策の企画や戦略そのものは、マーケティングコンサルタントの領域として別に扱われることが多い部分です。

メール配信の技術

大量のメールを届けるには、送信元の正しさを受信側に示す設定が欠かせません。Googleの「メール送信者のガイドライン」では、2024年2月1日以降、個人用のGmailアカウントに送るすべての送信者に、SPFまたはDKIMの設定、有効な正引き・逆引きのDNSレコード、TLSでの送信、迷惑メール率を一定以下に保つことなどを求めています。1日5,000件以上を送る送信者には、SPFとDKIMの両方、DMARCの設定、送信元のドメインの一致、マーケティングメールでのワンクリックでの登録解除と、本文での分かりやすい登録解除のリンクが求められています（2026年10月時点）。

Yahooの送信者向けのページも、大量に送る送信者にSPFとDKIM、DMARCの設定、ワンクリックの登録解除への対応を求め、登録解除は2日以内に反映するよう示しています（2026年10月時点）。

こうした設定は、MAツールの管理画面だけでなく、DNSやメールのヘッダーの理解を伴います。設定の意味を説明でき、配信の不調が起きたときに認証の結果から原因を探れる人は、配信の土台を任されやすくなります。

同意と配信停止の管理

広告や宣伝のメールには、特定電子メール法のルールがかかります。条文では、営利を目的とする団体や営業を営む個人が、広告・宣伝の手段として送る電子メールを「特定電子メール」とし、次のことを送信者に求めています（2026年10月時点）。

• あらかじめ送信を求めた人や同意した人など、法律が定める相手にだけ送る（第3条第1項）
• 同意を得た場合は、同意があったことを証する記録を保存する（第3条第2項）
• 送信をしないよう求められたら、その意思に反して送らない（第3条第3項）
• 送信者の氏名や名称、受信拒否の通知を受ける連絡先などを表示する（第4条）
• 送信者の情報を偽って送らない（第5条）

総務省のページには、法律と施行規則のほか、送信に関するガイドラインや法律のポイントをまとめた資料が掲載されています。エンジニアに求められるのは、同意の取得の経路と日時を記録として残し、配信停止がすべての配信の仕組みに反映されるようにすることです。対象になるか、どの例外にあたるかといった判断は、発注側の担当者や専門家が行う部分です。

計測のタグや、閲覧履歴を外部に渡す仕組みには、電気通信事業法の外部送信規律や個人情報保護法の個人関連情報のルールも関わります。これらは広告・メディア業界の規制の記事で解説しています。

CRMなど他システムとのデータ連携

MAとCRMの同期、Webサイトのフォーム、基幹システム、データ基盤との連携は、案件の難しさを大きく左右します。

• 同期の向き（片方向か双方向か）と、食い違ったときにどちらを正とするかの決めごと
• 項目の対応表と、値の変換のルール
• APIの呼び出しの上限や、エラー時の再送の扱い
• 連携の失敗に気づくための通知と、記録の残し方

連携そのものの開発が大きい案件では、データの加工やバッチの設計の力も求められます。基盤側のスキルはデータエンジニアのスキルの記事、CRMとしてSalesforceを開発する場合はSalesforceのスキルの記事が参考になります。

効果の計測と報告

配信やシナリオの効果を、開封やクリックだけでなく、商談や受注までつなげて示せるかも問われます。どのデータを結び付けて集計するか、どの期間で比べるかを決め、部門の担当者が読める形でまとめる力です。

• 配信やシナリオの成果を、商談の発生や受注の情報と結び付ける集計の設計
• 流入の経路を見込み客に記録する仕組み（フォームの隠し項目や、計測のパラメーターの扱い）
• 数字が前の月と大きく違ったときに、データの欠けや同期の遅れを疑って確かめる習慣

数字の解釈や施策の評価は発注側が行う部分ですが、数字の土台になるデータが正しいことを示せるのはエンジニアです。

ツールが替わっても通用する力

MAやCRMの製品はいくつもあり、画面や用語はそれぞれ違います。それでも、見込み客の単位、段階の定義、同期の方式、配信停止の反映といった考え方は共通しています。新しいツールの案件に入るときは、まずデータの持ち方と連携の仕組みを確かめ、これまでの経験と対応づけると立ち上がりが早くなります。

ツールの認定資格は、知識の裏づけとして見られることがあります。資格の位置づけは、今後まとめる資格の記事で扱います。

よくある質問

DNSやメールの認証の知識は、どこまで必要ですか？

運用を担う段階では、設定が済んでいるかを確かめられる程度でも足ります。配信の土台を任される段階では、SPF・DKIM・DMARCがそれぞれ何を確かめる仕組みかを説明し、配信の不調のときに認証の結果を読める程度の理解が求められます。DNSの変更そのものは、発注側の情報システム部門が担うことも多い部分です。

特定電子メール法の対象かどうかは、エンジニアが判断するのですか？

判断するのは送信者である発注側です。エンジニアに求められるのは、同意の記録や配信停止の反映、表示の項目など、法律が求める仕組みが正しく動くように作り、変更で壊さないことです。解釈に迷う場面では、発注側の担当者や専門家に確かめてください。

Salesforceなど特定のCRMの開発経験は、MAの案件でも評価されますか？

評価されることがあります。MAとCRMの同期の設計や、CRM側の項目と権限の理解は、連携の案件で役に立ちます。そのうえで、見込み客の育成やスコアリングの考え方を足すと、MA側の設計にも関われるようになります。独立の進め方はMA・CRMツールのエンジニアがフリーランスになるにはをご覧ください。