GTMエンジニアの最初のプロジェクトの選び方｜0→1で学習を実績に変える進め方と失敗回避

学習は進めたが「実績」がない——GTMエンジニアを目指す人の9割がここで止まる。突破口は大きな成果物ではなく、1つの営業課題を2週間で解いて数字で語れる小さなプロジェクトを1件完遂することだ。本記事は、最初のプロジェクトに向くテーマの条件、自社・知人企業・自主制作の選び方、スコープ設定から効果測定・ケース化までの5ステップ、初心者がつまずく落とし穴、そして完成物を実績として言語化する方法までを、実務目線で解説する。作品集としての見せ方はGTMエンジニアのポートフォリオ作成ガイドに、何を学ぶ順番はGTMエンジニアの学習ロードマップに譲り、本稿は「どのプロジェクトを・どう選び・どう完遂するか」の実行プロセスに絞る。

なぜ「最初の1件」がGTMエンジニアのキャリアを左右するのか

GTMエンジニアは、まだ職種として確立の途上にある。だからこそ採用側・発注側は「この人は営業課題を技術で解けるのか」を、資格や経歴ではなく具体的な成果物で見極めようとする。ここで効くのが、たとえ小さくても「0から1を完遂した」プロジェクトだ。

最初の1件が重い意味を持つ理由は3つある。

第一に、学習と実務の断絶を埋める唯一の橋渡しになる。 HubSpot Academyの動画を見てSQLの演習を解いても、それは「知っている」であって「できる」ではない。採用担当者や発注者が知りたいのは後者だ。1件のプロジェクトを最後まで通すと、教材では絶対に出てこない詰まり——データが汚い、要件が動く、想定通りに連携しない——を経験する。この経験こそが「できる」の証明になる。

第二に、2件目以降のハードルが劇的に下がる。 1件完遂すると「型」が身につく。スコープの切り方、効果測定の設計、ドキュメント化の順序——これらは2件目からほぼ同じ手順で回せる。逆に言えば、1件目でこの型を作れないと、何件やっても毎回ゼロから悩むことになる。「実績が実績を呼ぶ」構造の起点が、この最初の1件だ。

第三に、自分の適性と弱点が客観的に見える。 「CRM設計は面白いが、SQLは苦手だ」「自動化の構築は速いが、営業課題の言語化が弱い」——1件を通すと、こうした自己認識が具体的に手に入る。これは次に何を学ぶべきか（GTMエンジニアに必要なスキルセットのどこを補強するか）を決める最良の材料になる。

つまり最初のプロジェクトは、単なるポートフォリオの1点ではなく、キャリアの初速を決める投資なのだ。だからこそ「何を選ぶか」を軽く扱ってはいけない。

最初のプロジェクトに向くテーマの条件とは？

TL;DR: 良い最初のプロジェクトは「①1つの営業課題に絞れる ②2週間以内に完遂できる ③効果を1つの数字で語れる ④無料〜低コストで始められる ⑤中核スキルが1つ以上含まれる」の5条件を満たす。壮大なテーマほど未完成で終わる。

最初のプロジェクトのテーマ選びで失敗する人は、たいてい「大きく作ろう」とする。CRMを全オブジェクト設計し、自動化を10本組み、ダッシュボードも作る——こうした計画は9割が途中で力尽きる。そうではなく、小さく完遂して数字で語れることを最優先にする。具体的には次の5条件で候補を評価する。

このうち最も見落とされるのが ③ 効果を1数字で語れる だ。多くの人が「作ること」に集中し、「作った結果、何がどう良くなったのか」を後から説明できずに詰まる。着手前に「何の数字を、いくつから、いくつに変えるのか」を決めておくと、そのまま実績の言語化に直結する。

逆に、以下のようなテーマは最初のプロジェクトには向かない。

• 「AIエージェントで営業を全自動化」 — 下層のCRMやデータ整備が前提になるため、初心者が単独で完遂しきれない。GTMエンジニアとはで示した技術スタック4層の最上層であり、最初に手を出すと下層の不整合が全部跳ね返ってくる
• 「複数部署を横断するプロセス全体の設計」 — スコープが広すぎて2週間では終わらない。ステークホルダー調整に時間を取られ、技術的な成果が薄くなる
• 「新しいSaaSツールを網羅的に検証」 — 検証は成果物にならない。「触った」で終わり、営業課題を解いていない

最初のプロジェクトの3つの選択肢：自社・知人企業・自主制作をどう選ぶ？

テーマの条件が決まったら、次は「どこで作るか」を選ぶ。選択肢は大きく3つ——自社（今の職場）・知人企業・自主制作（架空企業）——で、実データの有無と守秘リスクのトレードオフで選ぶ。

選択肢A: 自社（今の職場）で作る

いま営業・営業企画・マーケの職に就いているなら、自社の課題を題材にするのが最も評価される。実データ・実課題・実運用がそろい、「絵に描いた餅」ではない成果が出せるからだ。

• メリット: 実データで効果を測れる。CRM入力率や商談化率など、リアルな数字で成果を語れる。上司の理解が得られれば実務経験として職歴にも書ける
• 注意点: 守秘義務が最大の壁。ポートフォリオに載せる際は企業名・顧客名・実数値をすべてダミー化・匿名化する。載せる前に必ず秘密保持契約（NDA）の範囲を確認する。判断に迷う箇所は「設計思想だけ示し、数値は比率に変換」で対処する（詳細はポートフォリオ作成ガイドの機密情報の扱い方を参照）

選択肢B: 知人・友人の会社で作る

営業組織を持つ中小企業やスタートアップに知人がいるなら、その会社の実課題を無償または低額で解かせてもらうのは強力な選択肢だ。実データと実運用が手に入り、しかも自分の裁量で設計できる。

• メリット: 実案件に最も近い経験ができる。「知人の会社でリード対応の自動化を構築し、対応時間を短縮した」は、面接でも副業提案でも通用する実績になる。うまくいけば最初の有償案件に発展する
• 注意点: 成果責任が発生する。実運用に載る以上、事故（誤送信・データ破損）を起こすと信頼を損なう。必ず本番と別の環境で検証してから反映する。範囲と期待値を口頭でもいいので合意しておく（「CRMの初期設計まで、運用改善は別途」など）

選択肢C: 自主制作（架空企業）で作る

実務経験がゼロ、または守秘リスクを一切負いたくないなら、架空企業のシナリオで一から作るのが最短で安全だ。実務経験がなくてもポートフォリオは作れる——採用側が見るのは実データではなく思考プロセスだからだ。

• メリット: 守秘リスクゼロ。自分のペースで作れる。HubSpot無料CRMやn8n Community Editionを使えば費用も実質かからない。「シリーズAのSaaS企業（従業員50名、営業10名）」といった具体的な設定を自分で作り、その課題に対して設計する
• 注意点: リアリティが問われる。架空でも「なぜその設計にしたか」の営業的根拠が薄いと見抜かれる。実在するB2B SaaSの営業プロセスを研究し、想定課題を具体的に書き込むこと。ダミーデータも「いかにも本物らしい」分布にする

結局どれを選ぶべきか（判断フロー）

Q1. いま営業・企画・マーケの職に就いているか？
  ├─ Yes → Q2へ
  └─ No  → Q3へ

Q2. 自社の課題を題材にする許可（または匿名化の目処）が立つか？
  ├─ Yes → (A) 自社で作る
  └─ No  → Q3へ

Q3. 営業組織を持つ知人・友人の会社があるか？
  ├─ Yes → (B) 知人企業で作る（範囲を口頭合意）
  └─ No  → (C) 自主制作（架空企業）で作る

迷ったら (C) 自主制作から始めるのが正解だ。1件を安全な環境で完遂して型を作り、その後に (A) や (B) の実案件へ広げる。最初から実案件でリスクを負う必要はない。

具体的にどんなテーマなら0→1で完遂できるのか

条件と場所が決まったら、いよいよ具体的なテーマだ。ここでは、どの選択肢（自社・知人・自主制作）でも成立し、無料〜低コストで2週間以内に完遂できる3つの鉄板テーマを挙げる。いずれもGTMエンジニアとはで解説したFETC（Find/Engage/Track/Convert）のうち、初心者が最初に触れるべき領域に対応している。

テーマ1: CRM初期設計（Track領域）

架空または実在の営業組織に対し、HubSpotでCRMの土台を設計する。GTMエンジニアの最も基本的な成果物であり、最初の1件として最も推奨できる。

• やること: コンタクト・企業・取引のオブジェクト設計、営業ステージ（パイプライン）の定義、カスタムプロパティの設計、必須入力項目の絞り込み
• 解く課題: 「CRMを入れても入力されない」——手入力を3項目に絞り、残りを既定値・自動化で埋める設計にする
• 語れる数字: 「必須入力項目を8個→3個に削減し、入力完了率90%を達成する設計」（自主制作なら想定値、実案件なら実測値）
• なぜ最初に良いか: 無料で完結し、オブジェクト設計という中核スキルを1件で示せる。上位のあらゆるプロジェクトの土台になる

テーマ2: 停滞案件の自動アラート（Track領域）

CRM上で一定期間動きのない商談を検知し、Slackやメールで担当者に自動通知する仕組みを作る。小さいが「営業課題を技術で解いた」感が明確に出るテーマだ。

• やること: n8n（またはHubSpot Workflow）で「最終更新から7日経過かつステージが商談中」の商談を検知 → Slack通知
• 解く課題: 「商談が放置されて失注する」——人が気づく前に自動で拾い上げる
• 語れる数字: 「停滞案件の平均放置日数を14日→3日に短縮する仕組み」
• なぜ良いか: Webhook・条件分岐・外部連携という自動化の基礎を1本のワークフローで通せる。図解が映えるためポートフォリオでも見栄えがする

テーマ3: リードの自動エンリッチメント（Find領域）

フォーム入力や名刺データの断片的なリード情報を、外部データで自動的に補完（エンリッチメント）する。ややレベルは上がるが、GTMエンジニアらしさが最も出るテーマだ。

• やること: Clay（無料枠）またはn8n＋公開APIで、会社名から業種・従業員数・所在地などを自動付与
• 解く課題: 「リード情報が薄く、営業が調べる時間を取られる」——調査を自動化する
• 語れる数字: 「リード1件あたりの手動調査時間を10分→0分に削減」
• なぜ良いか: データオーケストレーション層（GTMエンジニアの技術スタックのL2）に触れられる。ただしClayの無料枠は月100データクレジットと限られるため、検証は少量で行う

3テーマの難易度と推奨順は次の通りだ。

最初の1件は**テーマ1（CRM初期設計）**から入るのが定石だ。土台ができていれば、テーマ2・3は同じCRMの上に積み増せる。1件目・2件目・3件目を同じ架空企業でつなげば、それ自体が1つの「改善プロジェクトのケーススタディ」になり、ポートフォリオの中核に育つ。

3テーマ共通の「小さく始める」勘所

どのテーマでも、初心者が完遂率を上げるための共通の勘所がある。

• CRM初期設計の勘所: プロパティを最初から作り込まない。営業が本当に見る3〜5項目だけを必須にし、あとは運用しながら足す。「使わないプロパティ」が増えるほどCRMは腐る。命名規則（例: 顧客_業種、商談_失注理由）を最初に決めておくと、後の分析が一気に楽になる
• 停滞案件アラートの勘所: 通知条件を厳しくしすぎない／緩くしすぎない。「7日動きなし」から始め、通知が多すぎたら日数を延ばす。通知に必ず「次にやるべきこと」を1行添える——ただ「停滞しています」ではなく「◯◯社に再連絡してください」と書くと、営業が実際に動く
• リードエンリッチメントの勘所: 補完する項目を絞る。全部埋めようとせず「業種と従業員数だけ自動付与」から始める。無料枠（Clay月100データクレジット）を使い切らないよう、まず10件で仕組みを検証してから広げる

この「まず最小で通し、運用しながら足す」という進め方そのものが、GTMエンジニアの現場での基本動作だ。最初のプロジェクトは、成果物を作ると同時にこの動き方を身体で覚える機会でもある。

最初のプロジェクトはどう進めればいいのか（5ステップ）

TL;DR: 進め方は スコープ設定→データ整備→実装→効果測定→ケース化 の5ステップ。効果測定を最初に設計するのが最大のコツ。着手前に測る数字を決めておくと、完成がそのまま実績になる。

テーマが決まったら、次の5ステップで進める。この順序は2件目以降もそのまま使える「型」になる。

Step 1: スコープ設定——「完成の定義」を先に書く

最初にやるのは実装ではなく、紙に「何ができたら完成か」を書くことだ。ここで欲張ると必ず失敗する。

• 解く課題を1つに絞る（「リード対応が遅い」など）
• 「完成の定義」を1〜3行で書く（例:「新規リードが入ったら5分以内に担当者へ自動割り当て・通知される状態」）
• 測る数字を Before値付きで決める（例:「対応開始までの時間: 現状24時間 → 目標2時間」）
• 2週間で終わる範囲まで削る。終わらなそうなら課題をさらに小さく切る

このStep 1を飛ばして手を動かし始めるのが、初心者の最大の失敗だ。完成の定義がないと、いつまでも「もう少し機能を足そう」と際限なく広がる。

Step 2: データ整備——土台のデータを用意する

仕組みを作る前に、扱うデータを準備する。ここがGTMエンジニアの仕事の質を決める。

• 自主制作の場合: ダミーデータを作る。架空企業50社・リード200件など、リアルな分布（業種・規模のばらつき）で作る。ChatGPTやClaudeにダミーデータ生成を依頼すると速い
• 実案件の場合: 既存データを棚卸しし、重複・表記ゆれ・欠損を洗い出す。汚いまま自動化に載せると「スパム生成器」になる
• CRMのオブジェクトとプロパティを最小限で設計する。使わないプロパティを最初から作らない
• 入力ルールを固定する（必須項目、選択肢の値、命名規則）

Step 3: 実装——まず動くものを最小構成で通す

いよいよ実装だが、原則は**「まず一本、端から端まで動かす」**こと。細部を作り込む前に、全体が通ることを確認する。

• HubSpot Workflow / n8n / SQL のうち、テーマに合う手段を1つ選ぶ
• 最小構成（ハッピーパスのみ）で動作させる。条件分岐やエラー処理は後回し
• 動いたら、例外ケース（データ欠損時・重複時）への対応を足す
• 自動送信を伴うものは必ずテスト環境で検証してから本番に載せる。実案件で顧客に誤送信する事故は信頼を一発で失う

つまずいたら、教材ではなく公式ドキュメント（HubSpot Developers、n8n Docs）とコミュニティに当たる。この「詰まって自力で抜ける」経験そのものが実力になる。

Step 4: 効果測定——Before/Afterを数字で出す

Step 1で決めた数字を、実装後に計測する。ここが「作っただけ」と「実績」を分ける決定的な工程だ。

• 着手前に決めたBefore値と、実装後のAfter値を並べる
• 自主制作なら、想定シナリオでの改善幅を論理的に示す（「手入力8項目のうち5項目を自動化 → 入力工数62%削減」）
• 実案件なら、1〜2週間運用して実測する
• 営業マネージャーが意思決定に使える指標で語る（対応時間・入力率・工数・商談化率など）

「便利になった」では実績にならない。「対応時間を24時間→2時間に短縮」なら実績になる。この差が、面接や案件獲得の合否を分ける。

Step 5: ケース化——「背景→課題→設計→成果→学び」で言語化する

最後に、プロジェクトをドキュメントにまとめる。作って終わりにせず、必ず言語化する。

• 「背景→課題→設計→成果→学び」の型で1ページにまとめる
• CRM設計図・ワークフロー構成図・ダッシュボードのスクリーンショットを添える
• 機密はダミー化・匿名化する（実数値は比率に変換）
• Notion または GitHub Pages で公開し、PDF版も書き出す

このケース化の具体的な型・文字数配分・公開形式はポートフォリオ作成ガイドで詳述している。本稿の5ステップで作った成果物を、そのままガイドの型に流し込めば完成する。

5ステップを14日に割り付ける進行モデル

「2週間で完遂」を絵に描いた餅にしないため、5ステップを具体的な日割りに落とす。平日夜と週末を使う想定の、CRM初期設計を例にした進行モデルだ。

重要なのは、実装（Step 3）に最も日数を割く一方で、その前後を各2日以内に固定することだ。スコープ設定に凝りすぎたり、ケース化を「あとでやる」と先送りすると、この14日モデルは簡単に崩れる。最初はこの割り付け通りに一度やり切り、2件目からは自分の得意・不得意に合わせて調整すればいい。

最初のプロジェクトで初心者がつまずく5つの落とし穴

0→1を阻む典型的な失敗は、経験上ほぼ5パターンに収束する。着手前に頭に入れておくだけで回避率が上がる。

• 落とし穴1: ツールから入る — 「n8nを触ってみよう」と手段から始めると、解くべき課題が曖昧なまま作業だけが進む。課題→手段の順を死守する。ツールは課題が決まってから選ぶ
• 落とし穴2: スコープが肥大する — 「ついでにこれも」で機能を足し続け、完成しない。Step 1の「完成の定義」に書いていないものは次のプロジェクト送りにする。1件目は小さく閉じる
• 落とし穴3: 効果測定を後回しにする — 最も多く、最も致命的な失敗。完成後に「これで何が良くなった？」と聞かれて答えられない。Step 1で数字を決めるのが唯一の予防策
• 落とし穴4: 実データに固執する — 「実データがないから作れない」と止まる。採用側が見るのは思考プロセス。ダミーデータで十分始められる。実データは後から差し替えられる
• 落とし穴5: 作って満足する — 動くものができた時点で終わりにし、言語化（Step 5）を飛ばす。作った事実は誰にも伝わらない。ケース化して初めて実績になる

この5つはどれも「技術力」ではなく「進め方」の問題だ。だからこそ、最初の1件で意識すれば誰でも避けられる。

もし途中で手が止まったら、課題をさらに小さく切るのが唯一の正解だ。「CRM全体の設計」で詰まったら「リード1種類のパイプラインだけ」に、「自動化3本」で詰まったら「1本だけ」に削る。完遂しない大きなプロジェクトより、完遂した小さなプロジェクトの方が100倍価値がある。最初の1件は「立派さ」ではなく「やり切ったこと」そのものが評価対象なのだと、常に思い出してほしい。

費用はどれくらいかかる？無料で始める最小スタック

「有料ツールが必要では」と身構える人が多いが、最初のプロジェクトは実質ゼロ〜数百円から始められる。無料枠を組み合わせた最小スタックは次の通りだ。

※ 記載価格・無料枠は執筆時点（2026年7月）の情報です。正確な内容は各ベンダーの公式ページでご確認ください。

コストの実態を補足する。HubSpotは新規アカウントでコンタクト1,000件・カスタムプロパティ10個・多段階自動化不可という制約があるが、CRM初期設計の学習には十分だ。n8nはCommunity Editionを自己ホストすれば実行回数無制限で完全無料、かかるのはサーバー代（VPSで月数百円〜）だけ。Clayは無料プランが月100データクレジットと少ないため、エンリッチメントは「少量で仕組みを示す」用途に留めるのが賢い。

つまり、最初のプロジェクトに「お金がないからできない」は成立しない。止めているのは費用ではなく、着手の一歩だ。ツールの選び方の全体像はGTMエンジニアの主要ツール一覧にまとめている。

自主制作のリアリティはどう担保するのか

3つの選択肢のうち、実務経験がない人の多くが選ぶのが自主制作（架空企業）だ。ここで「架空だから評価されないのでは」と不安になる人が多いが、リアリティさえ担保できれば実案件に引けを取らない。担保するポイントは3つある。

1. 実在するB2B SaaSの営業プロセスを土台にする。 完全な空想ではなく、実在企業の公開情報（採用ページの営業職募集要項、IR資料、導入事例）を読み、その営業組織で起きていそうな課題を推定する。「シリーズAのSaaS、ARR3億円、営業10名、インサイドセールス中心」のように、実在のフェーズに寄せた設定にすると一気に本物らしくなる。

2. ダミーデータの分布を本物に寄せる。 リード200件を全部「株式会社サンプル」で埋めると嘘くささが出る。業種・従業員規模・流入経路にリアルなばらつきを持たせる。ChatGPTやClaudeに「日本のB2B SaaSのリードデータを、業種と規模の現実的な分布で200件生成して」と依頼すると、それらしいデータが手に入る。

3. 設計判断に「営業的な理由」を必ず添える。 架空でも「なぜこのプロパティを必須にしたか」「なぜこのステージ分割にしたか」に営業現場の理由を書く。ここが薄いと、いくら見た目が整っていても「作業しただけ」と見抜かれる。逆にここが濃ければ、実データがなくても「この人は営業を分かっている」と伝わる。

自主制作で1件を完遂したら、その設計思想はそのまま実案件に転用できる。架空企業で作った「停滞案件アラート」の設計は、知人企業の実案件でも8割そのまま使える。自主制作は、実案件の予行演習として最も安全で費用がかからない選択肢なのだ。

最初のプロジェクトの次は何をすればいいのか

1件目を完遂したら、次は「対応範囲の広さ」を見せにいく。2件目・3件目の選び方には原則がある。

• 2件目は1件目と別カテゴリを選ぶ — 1件目がCRM設計（Track）なら、2件目は自動化（Engage）やダッシュボード（Convert）にする。同じ領域を深掘りするより、GTMエンジニアの守備範囲の広さを示す方が採用・受注では効く
• 同じ架空企業の上に積み増す — バラバラの題材ではなく、1件目で作った架空企業のCRMの上に2件目・3件目を乗せる。3件つなげると「1社の営業組織を段階的に改善したケーススタディ」になり、単発の成果物より遥かに強い
• 2〜3点で止め、数より深さを磨く — 成果物は2〜3点あれば十分だ。5点以上並べると焦点がぼやける。それ以降は点数を増やすより、各案件の効果測定と言語化の精度を上げる方が評価が伸びる

この「1件目で型を作り、2〜3件で範囲を示し、あとは深さを磨く」というサイクルが、GTMエンジニアとしての市場価値を積み上げる王道だ。学ぶべきスキルの全体像と各領域の関係はGTMエンジニアに必要なスキルセットで確認できる。

完成したプロジェクトをどう「実績」として言語化するか

最後に、本記事の核心をもう一度強調する。作った事実は実績ではない。営業課題をどう技術で解いたかを、数字とともに語れて初めて実績になる。

同じプロジェクトでも、言語化の仕方で伝わり方が180度変わる。

違いは明確だ。左は「何をしたか（作業）」、右は「何が良くなったか（成果）」を語っている。採用側・発注側が知りたいのは常に右だ。

強い言語化には3つの要素が必要になる。

1. 営業課題から始まっている — 「ワークフローを作った」ではなく「対応が遅い課題を」から入る
2. 定量成果がある — 「改善した」ではなく「24時間→2時間」と数字がある
3. 設計判断の根拠がある — 「なぜその設計にしたか（なぜHubSpotか、なぜこの3項目か）」が説明できる

この3要素を、Step 5でまとめた「背景→課題→設計→成果→学び」のドキュメントに織り込む。1件目でこの言語化の型を身につければ、2件目以降は同じ枠に流し込むだけで済む。数字で語れることは、GTMエンジニアという職種の基本姿勢そのものだ。

補足すると、面接や案件提案の場では、この言語化がそのまま「対話の質」を決める。「HubSpotを使えます」と言う候補者には「では何ができますか」という質問が返る。一方「リード対応の遅延という課題を、自動割り当てで24時間→2時間に短縮しました。設計で迷ったのは通知の頻度で、多すぎると無視されるため◯◯という基準にしました」と語れる候補者には、「その基準はどう検証したのか」という一段深い議論が始まる。言語化の解像度が、相手の質問の深さを決めるのだ。最初の1件を丁寧に言語化しておくことは、その後のすべての選考・商談で効いてくる資産になる。

完成イメージの具体例：架空SaaS企業のCRM初期設計

抽象論だけでは動きにくいので、最初のプロジェクトの「完成形」を1つ、具体的に描いておく。自主制作（架空企業）でCRM初期設計を選んだ場合の例だ。

設定: 架空のB2B SaaS「Acme社」（従業員50名、営業10名、シリーズA、月間新規リード300件）。課題は「リードが入っても担当割り当てと初回対応が遅く、対応開始まで平均24時間かかっている」。

このシナリオに対して、次のような成果物を作る。

• オブジェクト設計: コンタクト／企業／取引の3オブジェクトを関連づけ、企業に「業種」「従業員規模」「流入経路」の3プロパティを設定
• パイプライン: 「新規→初回接触→商談→提案→受注/失注」の5ステージ。失注時は「失注理由」を必須にして後の分析に使えるようにする
• 必須入力の絞り込み: 営業の手入力を「企業名・担当者名・流入経路」の3項目だけに限定。業種・規模は自動エンリッチメントで補う設計にして入力負荷を下げる
• 自動割り当て: 新規リード発生時に、流入経路に応じて担当者を自動アサインし、Slackへ即時通知するワークフローを1本構築

効果の言語化: 「リード対応開始までの時間を、手動割り当て前提の24時間から、自動割り当て・通知により想定2時間へ短縮する設計。あわせて必須入力を8項目→3項目に絞り、入力完了率90%を目標にした」。

この完成形は、GTMエンジニアとはで示したFETCの「Track（追跡）」に的を絞った、無料ツールだけで2週間以内に到達できる現実的なゴールだ。ここまで作れれば、それは立派な「最初のプロジェクト」であり、ポートフォリオの1点目になる。大きさではなく、この「1課題を最後まで解いた」という事実こそが評価される。

この記事が役立つ状況

• 対象者: GTMエンジニアを目指して学習中の人／営業・営業企画・マーケから職種転換したい人／副業で最初の案件を取りたい人
• 直面している課題: 学習は進めたが実績がない、ポートフォリオに載せるプロジェクトが何もない、何から作ればいいか分からない、実務経験がなくて手が止まっている
• 前提条件: HubSpot・n8nなどの基本ツールに触れられる環境がある（無料で用意可能）。CRMや自動化の基礎概念を学習済み、または並行して学べる状態

あなたはGTMエンジニアのキャリア支援者です。私の「最初の実務プロジェクト」を1件、設計してください。

# 私の状況
- 現在のロール: [例: 営業 / マーケ / 学習中で未経験]
- 使える環境: [自社の課題がある / 知人企業がある / 自主制作のみ]
- 学習済みスキル: [CRM基礎 / iPaaS / SQL / なし のいずれか]
- かけられる期間: [1週間 / 2週間]

# 出力してほしいこと
1. 私の状況に最適なテーマ（CRM初期設計 / 停滞案件アラート / リードエンリッチメント から選定＋理由）
2. 「完成の定義」を1〜3行で
3. 着手前に測るべき数字（Before値の例と、目標After値の例）
4. スコープ設定→データ整備→実装→効果測定→ケース化の5ステップの具体タスク
5. 完成後の実績としての言語化文案（背景→課題→設計→成果→学び）

まとめ

GTMエンジニアの最初のプロジェクトは、大きさで勝負するものではない。1つの営業課題を2週間で解き、その効果を1つの数字で語れる——この小さな1件を完遂できるかどうかが、キャリアの初速を決める。

要点を振り返る。テーマは「1課題に絞れる／2週間で終わる／数字で語れる／無料で始まる／中核スキルを含む」の5条件で選ぶ。場所は自社・知人企業・自主制作から、実データと守秘リスクのトレードオフで選び、迷ったら自主制作から始める。進め方はスコープ設定→データ整備→実装→効果測定→ケース化の5ステップで、効果測定を最初に設計するのが最大のコツだ。そして完成物は「背景→課題→設計→成果→学び」で言語化し、作業ではなく成果として語る。

学習と実績の間には深い谷がある。その谷に最初の橋を1本架けるのが、この記事で示した最初のプロジェクトだ。作るべきものは決まった。あとは、今日その一歩目を踏み出すだけである。次に何を学び足すべきかはGTMエンジニアの学習ロードマップを、完成物の見せ方はポートフォリオ作成ガイドを参照してほしい。