mybook

成長ロードマップ — 30日・90日・180日・1年の計画

「ソウタ、FDE の成長は偶然じゃ起きない。意図的に設計するんだ」

カイがホワイトボードに4つの大きなブロックを描いた。Arclight AI の新人FDE向けオンボーディングを刷新するプロジェクトが始まっていた。ソウタ自身の1年間の経験を元に、再現可能な成長ロードマップを作る——それがカイからの依頼だった。

「自分が苦労したからこそ、次の人には地図を渡したい」

ソウタはノートを開いた。あの混乱の1年目を、構造化された計画に変換する。


ロードマップの全体像

Loading diagram...

カイは説明した。

「FDE の成長には4つのフェーズがある。Survival、Independence、Value Creation、Leadership。各フェーズで求められるスキルセットがまったく違う。焦って飛ばすと、後で崩れる」

INFO

このロードマップは「平均的な成長速度」を前提にしている。個人差はあるが、各フェーズを飛ばさないことが重要。基礎が弱いまま複数案件を持つと、品質が崩壊する。


フェーズ1: 基礎固め — Survival Phase(30日)

Week 1: プロダクト完全理解

ソウタが入社初日に感じた最大の不安は「プロダクトを知らない」ことだった。

「顧客に質問されて答えられない恐怖。あれが一番きつかった」

カイのアドバイスは明快だった。

「最初の1週間で、自分がプロダクトの一番の"パワーユーザー"になれ。エンジニアとして中身を知るんじゃない。ユーザーとして全機能を触り尽くすんだ」

# Week 1 の学習トラッカー(社内ツールのモデル)
class OnboardingTracker < ApplicationRecord
  belongs_to :fde_member
 
  WEEK1_CHECKLIST = [
    'api_endpoints_tested',      # 全APIエンドポイントのハンズオン
    'demo_env_explored',         # デモ環境で全機能を操作
    'success_stories_read',      # 既存顧客の成功事例10件
    'architecture_diagram_drawn', # 自分でアーキテクチャ図を描く
    'competitor_demo_watched',    # 競合3社のデモ動画視聴
    'internal_docs_read',        # 社内ドキュメント通読
    'product_roadmap_reviewed',  # プロダクトロードマップ確認
    'release_notes_3months',     # 直近3ヶ月のリリースノート
    'support_tickets_10cases',   # サポートチケット10件分析
    'dog_fooding_setup',         # 自分の業務でプロダクトを使う
  ].freeze
 
  def week1_completion_rate
    completed = WEEK1_CHECKLIST.count { |item| send(item) }
    (completed.to_f / WEEK1_CHECKLIST.size * 100).round(1)
  end
 
  def week1_complete?
    week1_completion_rate >= 80.0
  end
end

WARNING

「ドキュメントを読んだ」だけでは不十分。必ず手を動かして全APIを叩く。curl でもPostmanでもいい。レスポンスの構造を体で覚えることが、後のデモ力に直結する。

Week 1 チェックリスト

#項目完了基準
1全APIエンドポイントのハンズオン主要20エンドポイントを自分で叩いた
2デモ環境で全機能を操作画面キャプチャ付きで記録した
3成功事例10件の読了各事例の要約を1段落で書けた
4アーキテクチャ図を自分で描く先輩にレビューしてもらった
5競合3社のデモ動画視聴差別化ポイントを3つ挙げられた
6社内ドキュメント通読疑問点をリスト化した
7プロダクトロードマップ確認次3ヶ月の開発予定を把握した
8直近3ヶ月のリリースノート主要変更点を説明できた
9サポートチケット10件分析よくある質問パターンを整理した
10ドッグフーディング設定自分の業務で1機能以上使い始めた

Week 2: 社内ネットワーク構築

「FDE は一人では戦えない。社内に"味方"を作るのが Week 2 の仕事だ」——カイ

Loading diagram...

ソウタは当初、社内ネットワークの重要性を過小評価していた。

「技術力さえあれば、一人でなんとかなると思っていた。実際は、セールスが案件の背景を教えてくれないと、的外れなデモをしてしまう。プロダクトチームと関係がないと、バグ修正の優先度が上がらない」

1on1 スケジュールテンプレート

対象頻度目的聞くべきこと
セールス(AE)週1案件パイプラインの把握「今どの案件が技術検証フェーズ?」
プロダクトマネージャー隔週ロードマップと顧客要望の照合「顧客からの要望で多いものは?」
サポートチーム週1よくある問題の把握「今週一番多い問い合わせは?」
先輩FDE週2回シャドウイングとフィードバック「次の顧客コールに同席していい?」
エンジニアリング隔週技術的な深掘り「この機能の内部実装を教えて」

Week 3-4: 初回顧客対応

最初の顧客対応は、必ず先輩FDEの同席で行う。

# 初回ディスカバリーコールの準備チェッカー
class DiscoveryCallPrep
  PREP_ITEMS = {
    company_research: '企業の事業内容・規模・業界を調査',
    stakeholder_map: '参加者の役職と意思決定権限を確認',
    tech_stack_guess: '推定技術スタックをリストアップ',
    use_case_hypothesis: '想定ユースケースを3つ用意',
    demo_env_ready: 'デモ環境にサンプルデータを投入',
    questions_prepared: '質問を最低10個用意',
    backup_plan: '技術トラブル時の代替手段を確認',
    recording_setup: '録画・録音ツールの動作確認',
  }.freeze
 
  def initialize(call)
    @call = call
    @completed = {}
  end
 
  def ready?
    PREP_ITEMS.keys.all? { |item| @completed[item] }
  end
 
  def readiness_score
    completed_count = PREP_ITEMS.keys.count { |item| @completed[item] }
    (completed_count.to_f / PREP_ITEMS.size * 100).round(0)
  end
 
  def missing_items
    PREP_ITEMS.reject { |key, _| @completed[key] }
  end
end

30日チェックポイント: 自己評価

ソウタはカイと一緒に、30日目の振り返りフォーマットを設計した。

Loading chart...

「30日目で全部5である必要はない。大事なのは、自分の現在地を正直に把握すること。"わからないことがわかっている"状態が、30日目のゴールだ」——カイ

この時期にありがちな壁

壁1: インポスター症候群

「先輩FDEは顧客と堂々と話しているのに、自分は何もわからない」

乗り越え方: 全員が通る道。30日目で完璧な人は存在しない。「1日1つ新しいことを学ぶ」を積み上げる。

壁2: 情報過多によるパニック

「プロダクト、顧客、技術、社内ツール……覚えることが多すぎて頭がパンクする」

乗り越え方: 優先度を絞る。Week 1はプロダクトだけ。Week 2は社内だけ。一度にすべてをやろうとしない。

30日目の推薦リソース

書籍なぜ今読むべきか
『SPIN Selling』顧客への質問力の基礎
『The Mom Test』顧客インタビューの罠を知る
『プロダクトマネジメント ビルドトラップを避ける』プロダクト思考の基礎

フェーズ2: 自立 — Independence Phase(90日)

Month 2: 初めてのソロ案件

Loading diagram...

ソウタが初めてソロでリードした案件は、医療系スタートアップ「MedFlow」だった。

「カイが『裏で待機してるから、困ったらSlackで叫べ』と言ってくれた。安全ネットがあると知っているだけで、思い切って動けた」

ソロ案件のMEDDICスコアリング

# MEDDIC スコアリングの実装
class MeddicScorecard
  CRITERIA = {
    metrics: {
      question: '顧客が測定可能な成果を定義しているか?',
      weight: 20,
    },
    economic_buyer: {
      question: '経済的意思決定者を特定・接触できているか?',
      weight: 25,
    },
    decision_criteria: {
      question: '意思決定基準を把握しているか?',
      weight: 15,
    },
    decision_process: {
      question: '意思決定プロセス(期間・承認フロー)を理解しているか?',
      weight: 15,
    },
    identify_pain: {
      question: '顧客の根本的な課題を特定しているか?',
      weight: 15,
    },
    champion: {
      question: '社内チャンピオン(推進者)がいるか?',
      weight: 10,
    },
  }.freeze
 
  def initialize(deal)
    @deal = deal
    @scores = {} # 各項目 0-5 のスコア
  end
 
  def total_score
    CRITERIA.sum do |key, config|
      score = @scores[key] || 0
      (score.to_f / 5 * config[:weight]).round(1)
    end
  end
 
  def deal_health
    total = total_score
    case total
    when 80..100 then :strong
    when 60..79  then :moderate
    when 40..59  then :at_risk
    else :critical
    end
  end
 
  def weak_areas
    CRITERIA.select do |key, _|
      (@scores[key] || 0) <= 2
    end.keys
  end
end

カイとの1on1で使う質問テンプレート(Month 2)

カテゴリ質問
案件進捗「MedFlowのPoCで一番リスクが高いポイントはどこだと思う?」
スキル開発「デモ中に想定外の質問が来た時、どう切り返すべきだった?」
キャリア「この1ヶ月で一番成長を感じた瞬間は?」
社内連携「プロダクトチームにフィードバックを出す時、どうまとめると動いてもらいやすい?」
自己ケア「出張が増えてきたけど、ペース配分は大丈夫?」

Month 3: 本番デプロイ経験

本番環境へのデプロイは、FDE のスキルが試される最大の試練だ。

# デプロイチェックリスト(AWS環境)
class ProductionDeployChecklist
  CHECKS = {
    # デプロイ前
    pre_deploy: [
      { id: 'backup', desc: 'データベースバックアップ取得', critical: true },
      { id: 'rollback_plan', desc: 'ロールバック手順書の準備', critical: true },
      { id: 'stakeholder_notify', desc: '顧客IT担当に事前連絡', critical: true },
      { id: 'maintenance_window', desc: 'メンテナンスウィンドウの確認', critical: false },
      { id: 'monitoring_ready', desc: 'CloudWatch アラーム設定確認', critical: true },
    ],
    # デプロイ中
    during_deploy: [
      { id: 'health_check', desc: 'ヘルスチェックエンドポイント確認', critical: true },
      { id: 'smoke_test', desc: 'スモークテスト実行', critical: true },
      { id: 'performance_check', desc: 'レスポンスタイム確認', critical: false },
    ],
    # デプロイ後
    post_deploy: [
      { id: 'customer_verify', desc: '顧客に動作確認を依頼', critical: true },
      { id: 'monitoring_24h', desc: '24時間モニタリング', critical: true },
      { id: 'retrospective', desc: 'デプロイ振り返り記録', critical: false },
    ],
  }.freeze
 
  def all_critical_passed?(phase)
    CHECKS[phase]
      .select { |c| c[:critical] }
      .all? { |c| @results[c[:id]] == :passed }
  end
end

90日チェックポイント: 360度フィードバック

Loading diagram...
Loading chart...

「90日目は"一人でやれた"という自信がつく時期だ。同時に"自分の限界"も見えてくる。それがいい。限界が見えるということは、次に伸ばすべきポイントがわかるということだ」——カイ

この時期にありがちな壁

壁3: 「完璧主義」の罠

「PoCのコードが汚くて出せない。もう少しリファクタリングしたい」

乗り越え方: PoCは"動くこと"が正義。美しいコードは契約後に書けばいい。「Done is better than perfect」を唱える。

壁4: セールスとの温度差

「AEが技術的に不可能な機能を約束してしまった。顧客の前で否定もできない」

乗り越え方: 事前にAEとテクニカルバウンダリーを共有する。「できないこと」リストを一緒に作る。

90日目の推薦リソース

書籍なぜ今読むべきか
『Crucial Conversations』困難な顧客会話の技術
『The Challenger Sale』顧客に新しい視点を提供するセールス手法
『SRE サイトリライアビリティエンジニアリング』本番運用の原則
『Team Geek』チーム内での立ち回り方

フェーズ3: 価値創造 — Value Creation Phase(180日)

Month 4-5: 複数案件の並行管理

ソウタが3案件を同時に担当し始めた時、最初に崩壊したのは時間管理だった。

「月曜日に MedFlow のPoC、火曜日に FinBridge のデモ、水曜日に LogiTech のオンボーディング。木曜日になると、月曜日に約束したことを忘れている自分がいた」

# 複数案件の優先度マトリクス
class AccountPrioritizer
  PRIORITY_FACTORS = {
    deal_size: { weight: 0.25, desc: '契約金額' },
    close_date: { weight: 0.20, desc: 'クローズ予定日の近さ' },
    champion_strength: { weight: 0.20, desc: 'チャンピオンの影響力' },
    technical_risk: { weight: 0.15, desc: '技術リスクの高さ' },
    strategic_value: { weight: 0.20, desc: '戦略的重要性' },
  }.freeze
 
  def initialize(accounts)
    @accounts = accounts
  end
 
  def prioritized_list
    @accounts.sort_by { |account| -priority_score(account) }
  end
 
  def weekly_time_allocation
    total_hours = 40
    prioritized_list.map do |account|
      score = priority_score(account)
      total = prioritized_list.sum { |a| priority_score(a) }
      hours = (score / total * total_hours).round(1)
      { account: account.name, hours: hours, score: score.round(1) }
    end
  end
 
  private
 
  def priority_score(account)
    PRIORITY_FACTORS.sum do |factor, config|
      account.send(factor) * config[:weight]
    end
  end
end

Land & Expand の初成功

ソウタの初めてのLand & Expand は MedFlow だった。最初は研究部門の10ユーザーだったが、6ヶ月後には臨床部門50ユーザーに拡大した。

「展開のきっかけは、研究部門のチームリーダーが社内勉強会で Arclight AI の成果を発表してくれたこと。FDE が仕込んだ"成功事例"が社内で広がる——これが Land & Expand の本質だった」

INFO

Land & Expand を成功させる3つの条件: (1) 初期部門での明確な成功指標達成、(2) 社内チャンピオンの育成、(3) 他部門のペインポイントの事前調査。FDEはこの3つすべてに関与できる唯一のロール。

Month 6: スペシャリゼーション

Loading diagram...

「6ヶ月経つと、自分の得意分野が見えてくる。全部をやろうとするな。何かひとつ、"この分野ならチーム内で一番"というスペシャリティを持て」——カイ

ソウタは医療業界を選んだ。MedFlow での経験が基盤になり、HIPAA コンプライアンス、医療データの取り扱い、FDA 規制への理解が自然と深まっていた。

スペシャリゼーションの選び方

判断基準質問
市場の大きさその業界/技術の顧客は今後増えるか?
個人の興味週末でも調べたくなるか?
チーム内の空白他の FDE がカバーしていない領域か?
参入障壁深い専門知識が必要で、簡単に真似されないか?
実績の有無すでに1-2件の成功事例があるか?

社内ナレッジベースへの貢献

# ナレッジベース記事のテンプレート
class KnowledgeArticle < ApplicationRecord
  ARTICLE_TYPES = %w[
    playbook      # 特定シナリオの攻略法
    case_study    # 顧客事例
    technical_tip # 技術Tips
    battle_card   # 競合対策
    faq           # よくある質問
  ].freeze
 
  validates :article_type, inclusion: { in: ARTICLE_TYPES }
  validates :title, presence: true
  validates :body, presence: true, length: { minimum: 200 }
  validates :author, presence: true
 
  scope :by_industry, ->(industry) { where(industry: industry) }
  scope :most_referenced, -> { order(reference_count: :desc) }
  scope :recent, -> { order(created_at: :desc).limit(20) }
 
  def useful?(threshold: 5)
    upvotes >= threshold
  end
end

180日チェックポイント: ポートフォリオレビュー

Loading chart...

この時期にありがちな壁

壁5: バーンアウトの兆候

「3案件の並行で、毎週出張。金曜日には頭が回らなくなっている」

乗り越え方: 週に1日は「顧客対応なし」の日を死守する。カイは木曜日を「Deep Work Day」にしていた。

壁6: スペシャリストか、ジェネラリストか

「医療に特化すると、他の業界の案件が減る。本当にそれでいいのか」

乗り越え方: 最初のスペシャリティは「実験」。1年で変えてもいい。T字型人材の横棒を捨てるわけではない。

180日目の推薦リソース

書籍なぜ今読むべきか
『The Hard Thing About Hard Things』リーダーシップの覚悟を学ぶ
『Measure What Matters』OKR でチームと自分の目標を設定する
『影響力の武器』社内外での説得力を高める
『ドメイン駆動設計入門』業界特化の技術基盤を固める

フェーズ4: リーダーシップ — Leadership Phase(1年)

Month 7-9: メンタリング開始

ある月曜日の朝、カイがソウタに言った。

「来月、新しい FDE が入る。ソウタ、バディをやってくれないか」

ソウタの心は複雑だった。自分自身がまだ学んでいる最中なのに、人を教えられるのか。

「教えることは、最高の学びだ。自分が"なんとなくできている"ことを言語化する。それが本当の理解になる」——カイ

活動頻度内容
1on1毎週30分今週の学び、来週の目標、フィードバック
シャドウイング隔週メンティが顧客コールに同席
コードレビュー毎週メンティのPoCコードをレビュー
月次振り返り月1回成長の棚卸しと計画更新

社内勉強会の主催

ソウタが初めて主催した社内勉強会のテーマは「医療業界向けAI導入で学んだ5つの落とし穴」だった。

「自分の失敗談を共有するのは恥ずかしかったけど、終わった後に3人のAEから『次の医療案件があったらソウタに相談する』と言われた。ナレッジ共有は"信頼"の投資だと気づいた」

INFO

勉強会のフォーマット: 15分のプレゼン + 15分のQ&A。スライドは10枚以内。「こうすべき」ではなく「こう失敗して、こう学んだ」のストーリーが最も響く。

Month 10-12: 戦略的貢献

Loading diagram...

プロダクトロードマップへの直接影響

ソウタが提出した「医療業界向け監査ログ機能」の要望は、3件の顧客からの共通ニーズをまとめたものだった。

# プロダクトフィードバックの重み付け
class ProductFeedback < ApplicationRecord
  belongs_to :submitted_by, class_name: 'FdeMember'
  has_many :customer_votes
 
  def priority_score
    customer_impact = customer_votes.sum(:arr_value)
    frequency = customer_votes.count
    strategic_alignment = strategic_score # 0-10
 
    # ARR影響 × 頻度 × 戦略整合性
    (customer_impact / 1_000_000.0) * frequency * (strategic_alignment / 10.0)
  end
end

顧客アドバイザリーボードの運営

「顧客アドバイザリーボードは、FDE にとって最高の武器だ。顧客がプロダクトの方向性に直接影響を与えられる場。これを運営できる FDE は、社内での発言力が段違いに上がる」——カイ

1年チェックポイント: キャリアビジョンの再設定

Loading chart...

「1年経つと、景色が変わる。FDE を極めるのか、PMに行くのか、EMになるのか、起業するのか。どれも正解だ。大事なのは、"経験に基づいて"選ぶこと。1年前の自分には、この選択はできなかった」——カイ

キャリアパスの選択肢

パス向いている人次のステップ
Staff FDE技術と顧客の両方が好き大規模案件のテックリード
FDE マネージャー人を育てることに喜びを感じるチームビルディング、採用
プロダクトマネージャー顧客の声をプロダクトに反映したいPM として社内異動
ソリューションアーキテクト技術設計に集中したいSA チームへの異動
起業顧客の課題を自分で解きたい自分のプロダクトを作る

この時期にありがちな壁

壁7: 「次のステージ」への焦り

「1年でここまで来たのに、まだ"すごいFDE"にはなれていない気がする」

乗り越え方: 1年前の自分と比べる。他人と比べない。成長率は人それぞれ。

壁8: マネジメントへのプレッシャー

「FDE を続けたいのに、マネージャーになれと言われる」

乗り越え方: IC(Individual Contributor)トラックが明確にあるか確認する。なければ、カイのように自分でそのパスを作る。

1年目の推薦リソース

書籍なぜ今読むべきか
『Staff Engineer』IC としてのキャリアパスを設計する
『Inspired』プロダクト思考をさらに深める
『An Elegant Puzzle』エンジニアリングマネジメントの実践
『ゼロ・トゥ・ワン』起業の思考フレームワーク
『HIGH OUTPUT MANAGEMENT』マネジメントの古典

メンターとの1on1 質問テンプレート集

どのフェーズでも使える、メンターとの1on1のための質問集。

案件について

  1. 「今の案件で一番のリスクは何だと思いますか?」
  2. 「このステークホルダーへのアプローチ、他にどんな方法がありますか?」
  3. 「もし自分がこの案件を担当していたら、何を変えますか?」

スキル開発について

  1. 「自分のデモを見て、改善すべき点を率直に教えてください」
  2. 「今の自分に足りていないスキルは何ですか?」
  3. 「そのスキルを伸ばすために、何から始めるべきですか?」

キャリアについて

  1. 「この業界に特化する判断は、今のタイミングで正しいですか?」
  2. 「自分のキャリアで後悔していることはありますか?」
  3. 「FDE として5年後、どんな姿になっていたいか一緒に考えてほしい」

メンタルヘルスについて

  1. 「出張続きでペースが落ちています。どう調整すべきですか?」
  2. 「モチベーションが下がった時、どう回復していましたか?」
  3. 「"ノー"と言うべき場面で、自分はまだ言えていないと感じます」

WARNING

1on1で「特にないです」は最悪の回答。事前に3つ以上の議題を準備してから臨む。メンターの時間は有限で貴重なリソースだ。


まとめ — ロードマップは「地図」であり「答え」ではない

カイがロードマップの説明を終えた後、こう付け加えた。

「ソウタ、一つ大事なことがある。このロードマップは"地図"だ。地図は現実の地形を完璧には反映しない。予想外の嵐もあれば、地図にない近道もある」

ソウタは頷いた。

「でも、地図がなかった1年前と比べたら、次の人はずっと迷わずに済みます」

「そうだ。だからこそ、この地図を使った人が、自分の経験で地図を更新してほしい。FDE の成長ロードマップは、永遠にベータ版だ」

INFO

ロードマップの最大の価値は「完璧な計画」ではなく、「現在地の確認」にある。自分が今どのフェーズにいて、次に何をすべきか。それがわかるだけで、不安は大幅に減る。

ソウタはノートを閉じた。1年前、チャーンレートの数字に怯えていた自分がここにいる。今の自分は、数字の裏にある顧客の顔が見える。技術力だけではたどり着けなかった場所に、FDE として立っている。