FDE（Forward Deployed Engineer）になるには｜必要スキルと経路別ロードマップ

FDE（Forward Deployed Engineer）になるには、資格でも特定の学位でもなく、「フルスタック実装 × 課題定義 × データ × 顧客折衝」という4辺の掛け算を揃えることが核心だ。しかも朗報がある——完全なFDE経験は採用要件になっていない。FDE自体が新しい職種で、経験者がほぼ存在しないからだ。いまエンジニア・コンサル・営業企画・データサイエンティストのいずれにいる人も、持っている辺を軸に足りない辺を後付けすれば届く。本記事は、向く人の条件、必須スキルの全体像、経路別のロードマップ、評価される実績の作り方、日本で目指す道筋までを実務目線で示す。

TL;DR: FDEになるには「掛け算の4辺」を埋める。向く人は〈動くものを作り切れる／本当の課題を掘れる／泥臭いデータ整備を厭わない〉人。採用要件の実際は「Pythonで一通り書けるフルスタック＋顧客対応経験」が目安。経路は(1)エンジニア→(2)コンサル・営業企画→(3)データ/PdMの3つ。最後に効くのは資格ではなく「顧客の課題を成果まで解いた実績1本」。日本では営業・業務プロセス理解 × 実装力を持つ人が最も希少で狙い目だ。

FDEという職種そのものの定義・年収・SESとの違いはFDE（Forward Deployed Engineer）とはで詳しく解説している。本記事は「なり方」に絞って掘り下げる。

FDEに向いているのはどんな人か

FDEは「技術 × ビジネス」の掛け算職種だ。だから、片方だけの専門家——腕は立つが顧客と話すのは苦手なエンジニア、業務は詳しいが自分では実装できないコンサル——は、そのままでは務まらない。逆に言えば、両側に足を伸ばす意志がある人に開かれた職種だ。向いている人の条件を3つに整理する。

TL;DR: FDEに向くのは (1) 動くものを一人で作り切れる／作れるようになりたい人、(2) 顧客の言葉の裏から本当の課題を掘れる人、(3) データ整備や既存システム連携という泥仕事を厭わない人。「賢いAI」と「成果」の間の泥沼を、面白がって越えられるかが分水嶺だ。

条件1: 一人で「動くもの」を作り切れる（作れるようになる意志がある）

FDEの現場では、パワポの提案書ではなく動くプロトタイプで反応を得る。数日で動くものを出すスピードが、SIerのウォーターフォールとの決定的な差になる。だから「仕様を書いて外注する」のではなく、自分の手でフロントからバックエンド、データ処理までを通しで作れることが求められる。いま作れなくても構わないが、「自分で実装する」フェーズから逃げない人でないと、FDEには届かない。

条件2: 顧客の言葉から「本当の課題」を掘れる

顧客が口にする課題と、業績を動かす本当の課題は、しばしばずれている。「レポートを自動化したい」の裏に「意思決定が遅くて商談が滞っている」という真因が隠れていることがある。現場を観察し、ヒアリングから課題を構造化し、解くべき問題を定義し直す——このコンサルタント的な力が、実装力と同じ重さで問われる。指示待ちで作業をこなすのが得意なだけの人は、この一辺で詰まる。

条件3: 泥臭いデータ整備・システム連携を厭わない

FDEの実力が最も出るのは、地味な泥仕事だ。Excelに散らばったデータの正規化、既存システムとのAPI連携、認証周りの調整、汚いデータのクレンジング——「AIの前処理の泥仕事」を引き受けられるかが分かれ目になる。華やかなモデル構築より、この泥沼を面白がって越えられる人がFDEに向く。

この3条件を全て満たしていなくても心配はいらない。次章で見るように、いま満たしている条件を軸に、足りない条件を後から埋めていくのがFDEへの現実的な道だ。

FDEになるために必要なスキルの全体像

FDEに必要なスキルは、4つの辺で構成される「掛け算」として捉えると分かりやすい。どれか1つがゼロだと、掛け算全体がゼロに近づく。逆に、全てが最高水準である必要はなく、各辺が「実務で通用する」ラインを越えていればいい。まず全体像をテーブルで示す。

各辺の中身を、これから目指す人が「何を身につければいいか」の視点で具体化する。

フルスタック実装の辺

FDE求人で共通して問われるのが、production品質のフルスタック実装力だ。実際の採用要件を見ると、PythonとTypeScript/JavaScriptのフルスタック力が「table stakes（最低条件）」とされ、production-qualityのコード——テスト・エラーハンドリング・監視・明快なインターフェースを備えたもの——が期待される。ここに2025年以降はAIネイティブな実装、すなわちRAGパイプラインの構築、評価フレームワークの設計、エージェントワークフローのproduction運用が「差別化要因」として加わった。

目指す人にとっての優先順位は明快だ。まずPythonで一通りのデータ処理・自動化・API連携を書けるようにする。次にTypeScript/Reactで簡単なフロントを作り、フルスタックで「動くもの」を出せるようにする。そのうえでLLM API・RAG・AIエージェントを実際に動かす。この順で積むのが効率的だ。必要スキルの詳細な分解はGTMエンジニアに必要なスキルセットが土台としてそのまま使える。

課題定義の辺

技術力があっても、解くべき課題を間違えれば成果は出ない。FDEには「曖昧なエンタープライズの問題を、スコープの切れた技術的なワークストリームに分解し、変化する制約の下でデリバリーする」問題分解力が求められる。これはコンサルティングの中核スキルであり、実装力とは別の訓練が要る。現場のヒアリング、業務観察、仮説の構造化——これらは本を読むだけでは身につかず、実際のプロジェクトで顧客と向き合って磨くしかない。

データエンジニアリングの辺

FDEのSQL要件は、単なるSELECT文にとどまらない。ウィンドウ関数、CTE（共通テーブル式）、クエリ最適化、そして「数十億行の巨大テーブルに対する厄介な結合」までが射程に入る。現場のデータは汚く、分断されている。それを整え、AIが扱える形にする力が、FDEの実力を静かに支える。

顧客折衝・プロダクト思考の辺

最後の辺は、現場の実務家と対等に話し、信頼を築き、巻き込む力だ。そしてFDE固有の視点として、1社の課題を解いた知見を自社プロダクトの汎用機能へ還流させる「プロダクト思考」が加わる。この還流こそがFDEを単なる受託開発と分ける本質であり、目指す人は早い段階から「この解は他の顧客にも効くか」と考える癖をつけておくといい。

各辺を何で学ぶか（学習リソースの目安）

不足する辺を埋めるための学習リソースを、辺ごとに整理する。大半は無料で始められ、FDEに求められる実務レベルへの土台になる。

※ リソースは執筆時点の一例です。最新の内容・提供状況は各提供元でご確認ください。

肝心なのは、これらを「読んで終わり」にしないことだ。FDEに必要なのは知識ではなく、動くものを作り成果を出す力だ。各リソースは、次章以降で述べる「実績を1本作る」ための手段として使う。学習時間の半分以上をハンズオンに充てる——この配分を最初から意識しておくと、インプット過多の失敗を避けられる。

未経験からFDEになる経路別ロードマップ

FDEは経験者がほぼいない職種だからこそ、いま別の職種にいる人が越境で入り込める。鍵は、前章の4辺のうち「自分が既に持っている強い辺」を軸に据え、足りない辺を後付けすることだ。全部をゼロから積むのではなく、既にある強みを土台にするから、思うより短い距離で届く。出発点別に王道ルートを示す。それぞれのルートで「越境の壁」がどこにあるかも合わせて押さえておくと、学習の重心を間違えずに済む。

TL;DR: 経路は3つ。(1)エンジニアは課題定義・顧客折衝を足す、(2)コンサル・営業企画・PdMは実装力を足す、(3)データサイエンティストは業務理解とプロダクト思考を足す。共通の最終ゴールは「顧客の課題を成果まで解いた実績1本」。腰が引けやすい辺を地道に越えた人が、希少なFDEになる。

ルート1: エンジニア → FDE

すでにPython・フルスタックの実装力がある人は、4辺のうち「フルスタック実装」と多くの場合「データ」を持っている。足りないのは「顧客が何に困っているかの解像度」と「課題を定義し巻き込む力」だ。

やるべきことは、純粋な機能開発から一歩出て、顧客折衝・要件定義・PMの経験を積むこと。社内の他部門プロジェクトに実装役として入り込み、「言われたものを作る」から「何を作るべきかを一緒に決める」へと役割を広げていく。技術力という強い武器があるぶん、この越境は比較的取り組みやすい。ソリューションアーキテクトやSEも、この延長線上にいる。

ルート2: コンサル・営業企画・PdM → FDE

課題定義力・業務理解・プロジェクトマネジメントを持つ人は、「課題定義」と「顧客折衝」の辺を既に持っている。足りないのは実装力だ。これはFDEを目指すうえで最も腰が引けやすい辺だが、逆にここを越えた人が最も希少なFDEになる。

Python・SQL・API連携・LLM活用を、教材レベルではなく「自分で動くものを作れる」実務レベルまで引き上げる。CRMのレポートをSQLで再現する、業務の手作業をスクリプトで自動化する、といった身近な題材から始めるのがいい。「自分で実装する」ラインを越えられるかが分岐点だ。プロダクトマネージャー経験者も、プロダクト思考を既に持つぶん、実装力を足せば有力な候補になる。

ルート3: データサイエンティスト → FDE

RAGやAIエージェント、データ処理の技術基盤がある人は、「データ」と「フルスタック実装」の一部を持っている。足りないのは顧客の業務ドメイン理解とプロダクト思考だ。

「モデルの精度」ではなく「顧客の業績が動いたか」で考える視点を持てるかが鍵になる。研究室的な最適化から離れ、現場に入り、汚い制約の中で成果を出す働き方に慣れる必要がある。データエンジニアも同様に、業務理解と顧客折衝を足すことでFDEに近づける。

職種別・適性と補うべき辺の早見表

※ 難易度は一般的な傾向の目安です。個人のスキルや経験により実際の到達期間は異なります。

FDE採用で実際に求められる要件はどのくらいか

「掛け算が要る」と言われると身構えるが、実際の求人票が求める技術ハードルは、思うほど高くない。主要企業の要件を整理する。

• OpenAI（FDE） — 5年以上のエンジニアリングまたは技術的な導入（デプロイ）経験を求め、顧客対応環境での経験が望ましいとされる。PythonとJavaScriptのフルスタック力が最低条件で、AIネイティブなデプロイ力が差別化要因になる
• Palantir（Forward Deployed Software Engineer） — 3年以上のPython/PySpark/Java実務と、3年以上のクラウド（AWS/Azure/GCP）経験が目安。加えて顧客と直接向き合い、Gen AI戦略と実装をエンドツーエンドで担う姿勢が問われる
• 共通して問われるもの — production品質のコード、SQL（ウィンドウ関数・CTE・巨大テーブルの結合）、RAG・評価設計・エージェント運用、そして曖昧な問題を分解しデリバリーする力

複数の解説が指摘するとおり、2026年時点の主要企業の求人票を見ると、技術的なハードルは「Pythonで一通り書けるフルスタックなソフトウェアエンジニア」であれば十分に門戸が開いている。つまり、超人的な天才だけが入れる職種ではない。実装の土台を持つ人が顧客折衝・課題定義を足す、あるいはビジネス側の人が実装を足す——この後付けで、多くの人が要件ラインに届く。

もう一つ強調したいのは、繰り返しになるが「完全なFDE経験」は要件になっていないことだ。採用側が評価するのは、戦略コンサルティング、データサイエンス、エンタープライズシステム実装、フルスタック開発、ソリューションアーキテクトといった隣接領域の実績だ。適性が高い出発点として、フルスタックエンジニア・ソリューションアーキテクト・データエンジニア・実装志向のITコンサルタント・SE・カスタマーサクセス・PdMが挙げられる。いまこのどれかにいる人にとって、FDEは越境1回で届く距離にある。

FDE転職で評価される実績の作り方

FDEの転職市場で最終的に効くのは、資格ではなく実績だ。「何ができるか」ではなく「何を成し遂げたか」で評価される。ここでいう実績とは、顧客（社内の他部門でもよい）の課題を、定義から実装・運用・数値成果まで一気通貫で解いた事例を指す。作り方を3つの方法で示す。

TL;DR: 実績は「顧客の課題を成果まで解いた事例1本」に集約する。(1)現職の業務改善、(2)副業の小規模AI導入、(3)架空企業の個人プロジェクト——どれでもいい。必須なのはBefore/Afterを数値で示すことと、課題定義から運用までの物語を語れることだ。

方法1: 現職の業務・営業プロセスを改善する

最も説得力があるのは、現職での改善成果だ。営業組織や業務部門があるなら、以下のような改善を自主的に提案・実行する。

• 手作業のレポート作成をPythonスクリプトで自動化し、作成工数を削減
• 部門間で分断されたデータをSQLで統合し、意思決定に使えるダッシュボードを構築
• 問い合わせ対応にLLMを組み込み、一次対応の下書きを自動生成して対応速度を短縮

成果は必ず数値で記録する。「月次レポート作成を15時間→30分に短縮」「一次対応の平均時間を4時間→1.5時間に短縮（62%削減）」——こうした数字が面接で最も響く。FDEらしさを出すには、単に作った話ではなく「課題をどう定義し直したか」「現場にどう定着させたか」までを語れるようにする。

方法2: 副業で小規模なAI導入を請ける

スタートアップやSMBのAI導入・業務自動化を副業で請けるルートも有効だ。実プロジェクトの経験と報酬を同時に得られるうえ、複数社の現場に触れることでスキルの幅が広がる。FDEの本質は「1社に深く入り成果を出す」ことなので、小さくても顧客現場に入って成果を出した経験は、そのままFDEの実績になる。

方法3: 個人プロジェクトでポートフォリオを作る

現職に対象業務がない、副業が禁止されている場合は、架空企業を想定したプロジェクトでも十分に評価される。課題設定→データ整備→実装→デモまでを構築し、GitHubやブログで公開する。Before/Afterを明示し、「なぜこの課題を選び、どう解いたか」の思考プロセスまで書くことで、実装力と課題解決力の両方を示せる。RAGやAIエージェントを実際に動かした成果物があると、AIネイティブな実装力の証明になる。

いずれの方法でも、FDEの実績として語るときの型は共通だ。「どんな課題を、どう定義し直し、何を作り、どんな数値成果を出し、どう定着させたか」——この5点セットで一本の物語にできれば、それがFDE転職で最も強い武器になる。

日本でFDEを目指すにはどこを狙うべきか

海外のFDEは製造・金融・情報分析など幅広いドメインで立ち上がっているが、日本で目指すなら、狙う領域の選び方が勝負を分ける。結論から言えば、営業・マーケティング領域が最も戦いやすい入口だ。

理由は2つある。第一に、多くの日本企業でAI化の効果が最初に見えるのが営業・GTM領域だからだ。製造や金融のドメインFDEも重要だが、需要が最も分かりやすく立ち上がるのが営業・マーケの現場だ。第二に、日本で「営業・業務プロセスへの深い理解 × 実装力」を併せ持つ人材が、圧倒的に希少だからだ。実装だけできる人、営業だけ分かる人はいるが、その掛け算を持つ人がほとんどいない。だから、営業企画やGTMエンジニアの知見を持つ人が実装力を足せば、国内で最も希少なタイプのFDEになれる。

日本のFDE採用は2025〜2026年に立ち上がったばかりで、Palantir、Salesforce、ソフトバンク×OpenAI、エクサウィザーズ、LayerX、ログラス、AI Shift、ANDPADなど、大手・コンサル・AIスタートアップが横並びで採り始めている。1年前のほぼゼロからの急拡大だ。米国のトレンドが数年遅れで日本に来るこれまでのパターンを踏まえると、日本のFDE求人は今後さらに増える公算が大きい。つまり、いま準備を始める人は、市場が本格拡大する前の先行者になれる。

狙う領域を決めたら、そのドメインの「業務の解像度」を上げておくことも効く。営業領域を狙うなら、営業プロセスのどこにボトルネックが生まれやすいか、どの数字が営業判断に効くかを、自分の言葉で説明できるようにする。この業務理解こそが、実装だけできる候補者との差別化になる。技術は後から6ヶ月で補えるが、業務プロセスへの深い理解は一朝一夕には得られない——だからこそ、既に業務側の経験を持つ人にとっては、それが最大の武器になる。

日本市場で意識すべき落とし穴も一つある。「客先常駐＝SES」という既存イメージが強く、FDEを「ただの常駐」と誤解される場面があることだ。FDEの価値は稼働時間ではなく事業成果にある——この違いを、目指す本人が言語化できるようにしておくと、面接でも実務でも自分のポジションを守れる。SESとの違いの詳細はFDE（Forward Deployed Engineer）とはで整理している。

FDEを目指す過程でよくある失敗パターンと回避策

FDEを目指す人が陥りやすい失敗が3つある。いずれも「掛け算の一辺に偏る」ことから生まれる。事前に知っておけば回避できる。

TL;DR: 失敗は (1) 実装スキルの独学に閉じこもり顧客現場に出ない、(2) 課題定義だけを磨いて実装から逃げ続ける、(3) ツールの資格・知識を集めるだけで実績を1本も作らない、の3つ。共通の処方箋は「早い段階で小さくても現場の課題を成果まで解く」ことだ。

失敗1: 実装の独学に閉じこもり、顧客に出ない

エンジニア出身者に多い失敗だ。RAGやAIエージェントの技術を独学で深掘りし続けるが、顧客の現場に一度も出ない。FDEの価値は「技術を現場で成果に変える」ことにあるので、技術力だけを積んでも掛け算は完成しない。回避策は、社内の他部門でも顧客でもいいので、早い段階で「誰かの実際の課題」を解く場に身を置くこと。技術は現場の制約の中で磨いたほうが、はるかにFDE的な実力になる。

失敗2: 課題定義だけを磨き、実装から逃げ続ける

コンサル・営業企画出身者に多い失敗だ。問題の構造化や提案は上手いが、「自分で動くものを作る」フェーズにいつまでも踏み込まない。外注や依頼で済ませてしまう。だがFDEの分岐点はまさにそこにある。数日で動くプロトタイプを自分の手で出せるかどうかが、FDEと「実装できないコンサル」を分ける。回避策は、小さくてもいいので自分の手で完結させたスクリプト・ツールを積み上げること。最初の一本を自分で作り切った経験が、越境の分水嶺になる。

失敗3: 資格・知識を集めるだけで、実績を1本も作らない

全出発点に共通する失敗だ。認定資格を取り、技術書を読み、インプットは充実しているのに、顧客の課題を成果まで解いた事例が1つもない。FDEの転職市場は実績で評価されるので、これでは戦えない。回避策は明快で、学習時間の半分以上を「動くものを作り、成果を数値で出す」ハンズオンに充てること。インプットとアウトプットの比率が逆転している人ほど、この失敗に陥りやすい。

FDEを目指すなら最初の30日で何をすべきか

「掛け算の4辺を揃える」と言われても、初日に何から手をつけるかが分からないと動けない。目指す人のために、最初の30日で踏むべき具体的な一歩を示す。

まず最初の1週間は、前述の4辺の自己棚卸しに使う。自分の強い辺（実装／課題定義／データ／顧客折衝）を1つ特定し、最も弱い辺を1つ決める。次の3週間は、その弱い辺を1つだけ埋めることに集中する。同時に複数の辺に手を出すと、どれも中途半端になる——これはGTMエンジニアを目指す人にも共通する鉄則で、GTMエンジニアになるにはの学習設計とも通じる考え方だ。

具体的には、実装が弱いならPythonで身近な業務の自動化スクリプトを1本完成させる。課題定義が弱いなら、社内の誰かの困りごとをヒアリングし、真因を構造化した1枚のメモを書く。データが弱いなら、実データをSQLで集計しダッシュボードを1つ作る。いずれも「読む」ではなく「作る／出す」で終わらせるのが肝だ。30日後に、小さくても自分の手で完結させた成果物が1つ手元にある——この状態を作れれば、FDEへの道は確実に前に進んでいる。

FDEとGTMエンジニア、どちらを目指すべきか

FDEを目指す過程で必ず出会うのが、GTMエンジニア（Go-To-Market Engineer）という近接職種だ。どちらも「技術 × ビジネス」の掛け算で、顧客や現場に踏み込む点が似ている。目指す人の視点で、選び方の要点を整理する。

選び方はシンプルだ。顧客の業務全般に幅広く関わりたいならFDE、営業・マーケの仕組みに軸足を置きたいならGTMエンジニア。ただし両者の重なりは大きく、営業組織を対象にしたFDEは実質的にGTMエンジニアとほぼ同義になる。逆に、GTMエンジニアが特定顧客に深く入り込んで成果まで伴走すれば、それはFDE的な働き方だ。

嬉しいことに、必要スキルの土台は共通している。だから「FDEを目指す学習」はそのままGTMエンジニアにも効くし、その逆も成り立つ。まず土台を積み、途中でどちらの領域に軸足を置くかを決める——という進め方で構わない。両者の詳しい比較はFDEとGTMエンジニアの違いで、対象範囲・スキル・年収・キャリアの各観点から解説している。キャリアの選択肢として並べて検討する価値がある。

FDE（Forward Deployed Engineer）になるには何が必要ですか？

フルスタックで動くものを作れる実装力、顧客の課題を定義するコンサル的な力、SQL・データ整備のデータエンジニアリング、顧客現場で信頼を築く折衝力——この4つの掛け算が必要です。ただし全てを最初から高水準で持つ必要はなく、いま持っているスキルを軸に、足りない辺を後付けで補うのが現実的な道筋です。完全なFDE経験は採用要件になっていません。

FDEに未経験からなれますか？

なれます。FDE自体が新しい職種で経験者がほぼ存在しないため、採用側も隣接領域（エンジニア・コンサル・データサイエンティスト・PdM）の素養を評価します。技術面のハードルは「Pythonで一通り書けるフルスタックエンジニア」が目安で、そこに顧客折衝や課題定義の経験を足せば十分に門戸は開いています。

この記事が役立つ状況

• 対象者: FDEへのキャリアチェンジを検討するエンジニア／SE／コンサル／営業企画／データサイエンティスト／PdM／カスタマーサクセス
• 直面している課題: FDEになるための必要スキル・経路・実績の作り方が断片的な情報しかなく、自分の経歴から何を足せば届くのかの基準が持てない
• 前提条件: フルスタック実装・課題定義・データ・顧客折衝のいずれか1つ以上の実務経験、または週10時間程度をスキル習得に投下できること

あなたはFDE（Forward Deployed Engineer）のキャリア設計に詳しいアドバイザーです。

私の現状は以下の通りです。
- 現職/役割: [エンジニア / SE / コンサル / 営業企画 / データサイエンティスト / PdM / CS など]
- 経験年数: [年数]
- 保有スキル: [Python / TypeScript / SQL / フルスタック実装 / 課題定義 / 業務ドメイン理解 / AI実装 / 顧客折衝 など]
- 作れる実績の題材: [現職の業務改善 / 副業 / 個人プロジェクト の可否]
- 希望: [ドメイン別FDE / 営業領域FDE / 外資AI企業 など]

FDEに必要な4辺（フルスタック実装 × 課題定義 × データエンジニアリング × 顧客折衝）を踏まえ、以下を提示してください。
1. 私が既に持っている「強い辺」と、不足している辺
2. 不足している辺を埋めるための具体的な学習・経験の順序
3. 私の経歴で作れる「顧客の課題を成果まで解いた実績1本」の題材案
4. 私が狙うべきFDEのタイプ（ドメイン別 / 営業領域 / 外資）と、その理由

まとめ——FDEになるための最初の一歩

FDE（Forward Deployed Engineer）になるには、フルスタック実装・課題定義・データ・顧客折衝の4辺の掛け算を揃えることが核心だ。完全なFDE経験は不問で、いま持っている強い辺を軸に、足りない辺を後付けするのが最短ルートになる。採用要件の実際は「Pythonで一通り書けるフルスタック＋顧客対応経験」が目安で、超人だけの職種ではない。

経路は3つ——エンジニアが顧客折衝・課題定義を足す、コンサル・営業企画・PdMが実装力を足す、データサイエンティストが業務理解とプロダクト思考を足す。そして最後に効くのは資格ではなく、顧客の課題を定義から成果まで一気通貫で解いた実績1本だ。現職改善でも副業でも個人プロジェクトでも、Before/Afterを数値で語れる事例を作れば、それが最強の武器になる。逆に、インプットだけを積んで実績を1本も持たない状態が、最も避けたい落とし穴だ。最初の30日で小さくても成果物を1つ手にする——ここから全てが始まる。

日本では「営業・業務プロセスの理解 × 実装力」を持つ人材が最も希少で、営業企画やGTMエンジニア領域からの越境が国内で最も戦いやすい入口になる。この領域はGTMエンジニアに必要なスキルセットやFDEとGTMエンジニアの違いで扱う知見と地続きだ。まずは自分の4辺を棚卸しし、足りない辺を1つ埋めるところから始めてほしい。日本でこの働き方を体現できる人材は、まだ驚くほど少ない。だからこそ、いま踏み込む価値がある。