事業開発に進みたいエンジニアへコードが安くなった後に効く力と、転職せずに練習する場所

AIにコードを書かせる時間が増えて、自分の手で書く量が目に見えて減った。そう感じているエンジニアは多いと思います。書く速さで差がつきにくくなると、次に差がつくのは「何を作るかを決める」側です。誰の、どの困りごとを、どこまで解けば合格なのか。ここを決められる人は、まだ少ないままです。この記事では、事業開発に寄っていきたいエンジニアに向けて、コードが安くなったあとに価値が移る場所、FDE（Forward Deployed Engineer）という働き方、技術に足す4つの力、転職せずに練習できる場所の順に整理します。技術はそのまま持って、「決める仕事」の近くへ移っていく話です。 ハコブネを運営する株式会社Walkers（累計開発実績300件）の現場で起きたことを交えて書きました。

コードが安くなると、値段が上がるのは「決める仕事」

作る作業が速くなっても、作るものを決める作業は同じ速さでは縮みません。Walkersの要件定義の解説記事は、要件定義を「何を作るのか」「どんな機能が必要か」を作る前に決める作業と説明し、ここを上流でしっかり行うことでやり直しが減り、予算と期間を管理しやすくなるとしています。実装が数時間で終わるようになると、要件の取り違えで失うのは実装の時間よりも、その間に試せたはずの別の案のほうになります。

もうひとつ値段が上がるのは、顧客の近くにいる時間です。現場で何が起きているかを自分の目で見ている人は、要件の行間を埋められます。仕様書に書かれなかった例外、担当者が当たり前すぎて口にしない手順、導入したあとに誰がそれを毎日使うのか。こうした情報は、聞きに行かないと手に入りません。

エンジニアがここに強いのは、聞いた話をその場で「作れる形」に直せるからです。営業や企画の人が持ち帰って仕様に起こし、それを開発が読んで質問を返す、という往復が一人の中で済みます。要件を決める人と作る人が同じだと、往復の回数そのものが減ります。 事業開発に寄るというのは、この往復を自分の仕事として引き受けることです。

事業開発という仕事の範囲そのものを先に確かめたい方は、事業開発とは。何をする仕事かで営業・企画との境目を整理しています。

FDEという働き方。顧客の近くで、分解から定着まで

「決める仕事」と「作る仕事」を一人で持つ形として、いま名前がついているのがFDE（Forward Deployed Engineer）です。WalkersのFDE解説記事は、FDEを顧客の近くに入り込み、課題の特定から実装・導入までを一気通貫で進めるエンジニアと説明しています。「近く」は常駐に限らず、週次の打ち合わせやチャットで密に連携する形も含みます。

職種の原型は、Palantir Technologiesが2019年4月のブログ「Dev versus Delta」で紹介した社内のエンジニア職だとされています。製品を作るDevの焦点は「one capability, many customers（一つの機能を多くの顧客に）」、顧客先に入るDeltaは「one customer, many capabilities（一人の顧客に多くの機能を）」です。日本ではまだ定義が揺れていて、住友商事グループのInsight Edgeが2026年5月にFDEの職を新設するなど、各社が自社の役割の定義を載せて使っています。Walkersの記事は、国内のFDEをプラットフォーム型・プリセールス型・カスタマーサクセス型・SIer型・価値創出型の5つに分けて整理しています。

従来の支援形態と比べると違いがはっきりします。コンサル型は分解する人と作る人が別、受託開発型は顧客が仕様書で渡したものを作る、ツール導入型は製品に業務を合わせる。FDE型だけが、業務の分解・実装・定着の3工程を同じ担い手で持ちます。

肩書きとしてFDEを名乗る必要はありません。Walkers自身も「FDE-NOAH」というサービスを、先に自社で運用してから外に提供する順番で作りました。大事なのは、分解した人がそのまま作り、使われるところまで見届けるという動き方のほうです。 この動き方は、社内の小さな仕事からでも始められます。

エンジニアが足す4つの力

技術はすでに持っています。事業開発に寄るために足すのは、主に次の4つです。どれも、エンジニアが普段やっている「仕様を確かめる」「テストを書く」「ログを読む」「レビューを通す」の延長にあります。

1. 顧客インタビュー。意見より、過去の行動を聞く

「こんな機能があったら使いますか」と聞くと、相手はたいてい「使うと思います」と答えます。聞くべきは、その困りごとに対して最近実際に何をしたか、いくら・何時間使ったかです。エンジニアはバグ報告の再現手順を聞き出すのに慣れているので、同じ要領で「最後にそれが起きたのはいつで、そのとき何をしましたか」と聞けば足ります。質問の作り方は顧客インタビューのやり方にまとめています。

2. 仮説と合格ラインを、作る前に置く

テストを書く前に期待値を決めるのと同じで、事業でも作る前に「何がどうなれば合格か」を数字で置きます。ハコブネのハッカソンで運営が作った記録アプリ「BENLOG」は、確かめる仮説を「うんちを育てるためなら、人は毎日トイレを記録するのか」の一点に絞り、7日後の継続率40%・30日後20%・1日平均3.5件という合格ラインを先に置いていました（いずれも検証前に置いた目標値で、実測ではありません）。数字の正しさより、判断の基準が作る前に決まっていることに意味があります。

3. 数字の読み方。率より先に母数を見る

ログを読める人は、事業の数字も読めます。気をつけるのは、立ち上げ初期は母数が小さいことです。10人中3人の30%と、1,000人中300人の30%は同じ意味を持ちません。初期は率を追うより、誰が使い続けていて、なぜ戻ってきたのかを一人ずつ確かめるほうが判断材料になります。

4. 社内で通す。技術の正しさを、相手の言葉に訳す

Walkersの要件定義の記事は、専門用語が多いと関係者の理解がずれ、のちのトラブルの原因になりやすいと書いています。決裁する人が知りたいのは、技術の選び方よりも「いくらかかって、いつ何が分かり、駄目ならどこでやめるか」です。設計レビューで使う説明を、この3点に組み替えるだけで通り方が変わります。

要件が固まっていない案件で、実際に起きていること

この記事を監修している池田龍一（株式会社Walkers取締役）は、100件以上のシステム開発に携わり、要件が固まっていない案件や、他社から引き継いだ開発の立て直しを担当してきました。要件が固まっていない案件では、最初に渡された仕様のとおりに作ることよりも、途中で分かったことに合わせて作る順番を変えられるかどうかが結果を分けます。

UPSTA Japanのビジネスマッチングサービス「ApoLink」では、開発の途中でテストマーケティングを行ったところ、マッチング機能への反応が圧倒的に良かったため、その機能を前倒しで入れる形に方針を変えました。それでも当初の予定どおりに完成し、リリースから1ヶ月半ほどで会員は200人弱に達しています。作る順番を変える判断は、仕様書の中からは出てきません。反応という事実を見て、作る順番を変えられる位置にエンジニアがいたことが効いています。

一番飯店では、紙の伝票とトランシーバーで回していたオーダーを、タブレットのシステムに置き換えました。開発側がいちばん重視したのは簡単に操作できることで、写真を多く使い、文字を大きくして、日本語の伝票を書くのに苦労していた外国籍のスタッフでも直感的に注文を入れられるようにしています。副店長はオーダーの労力が体感で50%ほど減ったと話していて、導入から約2年たった今も使われています。「写真を多く、文字を大きく」は機能の一覧には出てこない要件で、誰が毎日使うのかを知っている人にしか書けません。

どちらの例も、技術の難しさより「何を先に作るか」「誰が使うか」を決めたところで結果が変わっています。事業開発に寄るエンジニアの仕事は、この判断を作る側の中で持つことです。

転職せずに練習できる4つの場所

事業開発の経験は、職種を変えなくても積めます。むしろ、小さく試して手応えをつかんでから移るほうが、自分に向いているかどうかも確かめられます。

1. 社内の小さな課題を、頼まれる前に拾う。 隣のチームが手作業で回している集計や転記は、立派な練習台です。担当者に30分だけ時間をもらい、困りごとを聞き、合格ライン（たとえば「月に何時間減れば使い続けるか」）を一緒に決めてから作ります。使われなかったら理由を聞きに行く。ここまでやると、一周分の事業開発になります。

2. 副業で、要件が決まっていない仕事を受ける。 仕様が固まった実装案件ではなく、「こういうことをしたいが、何を作ればいいか分からない」という相談を受けると、要件を決める側の経験が積めます。本業の就業規則で副業の扱いを確かめてから始めてください。進め方は事業開発の副業で整理しています。

3. ハッカソンで、決めるところから作るところまでを1日で回す。 2026年8月にハコブネが東京・目白台とオンラインで開いたAI新規事業立ち上げハッカソンでは、開発が初めての人や事業を持っていない人を含む参加者全員が、4時間弱でプロダクトを完成させて発表しました。開発がまったく初めての参加者が約4時間で作った、類似のPoCを横断比較する企業向けのPoC設計ツールが受賞しています。作る時間が短いと、残りの時間を「誰のための何か」を詰めることに使えます。アンケートに答えた3名は満足度が全員10点満点でした（回答3名の少人数の回です）。

4. 1DAYイベントで、一人では決めきれない部分を人に聞く。 ハコブネの1DAY新規事業立ち上げイベントは、アイデアがなくても、開発が初めてでも参加できる回です。エンジニアにとっては、技術以外の視点を持つ参加者と組んで、決める側の判断を練習する場になります。日程は1DAYイベントのページで案内しています。

職種として移るときの見取り図

練習を重ねて「決める仕事」が面白いと分かったら、次は職種としての動き方です。進み先は大きく三つに分かれます。社内で新規事業や企画のチームに移る道、FDEや顧客の現場に近い技術職に就く道、自分で小さな事業を立ち上げる道です。それぞれの経験の積み方は事業開発のキャリアパスで詳しく整理しています。

どの道を選んでも、技術を捨てる必要はありません。むしろ、聞いた話をその場で動く形にできることは、事業開発の現場では強い武器になります。職種名より先に、「分解した人がそのまま作り、使われるところまで見る」経験が一つあるかどうかが問われます。 面接や社内異動の相談でも、社内の小さな課題で合格ラインを置き、作り、結果を見た一周分の話ができれば、肩書きがなくても伝わります。

逆に、向かない人もいます。仕様が決まった状態で深く作り込むことに一番の面白さを感じる人は、無理に寄せなくて構いません。FDE型が向かない会社の条件として、Walkersの記事は「仕様が確定している」「現場の観察ができない」などを挙げていますが、人にも同じことが言えます。決まっていないものを決める作業が苦にならないかどうかを、練習の段階で確かめてください。

ハコブネでは、1DAY新規事業立ち上げイベント（会員は参加費無料、一般3,000円）で1日の中で決めるところから作るところまでを回せるほか、月1〜2回のランチ会で事業を作っている人と話せます。いま考えていることを話しながら入るかどうかを決めたい方は、オンラインの無料相談会も使えます。

よくある質問5選

質問1エンジニアが事業開発に移ると、技術力は落ちませんか？

書くコードの量は減ることが多いです。ただ、AIに実装を任せる場面が増えたいま、設計を判断し、出てきたコードを読んで正しさを確かめる力は引き続き必要です。顧客の近くで使う技術は幅が広がるので、落ちるというより使い方が変わると考えてください。

質問2FDEとPM（プロダクトマネージャー）は何が違いますか？

FDEは自分で実装まで持つのが前提です。WalkersのFDE解説では、業務の分解・実装・定着の3工程を同じ担い手が持つことをFDE型の特徴としています。PMは作る人と決める人をつなぐ役割を持つことが多く、実装を担うかどうかは会社によって違います。

質問3ビジネスの経験がまったくなくても事業開発に寄れますか？

寄れます。最初の一歩は、社内の誰かの困りごとを聞いて、合格ラインを置いてから小さく作ることです。売上を作った経験がなくても、「誰の何を、どこまで解けば合格か」を決めて結果を見た経験があれば、事業開発の話ができます。

質問4事業開発に向いているエンジニアの特徴はありますか？

仕様の曖昧さを嫌がらず、聞きに行くことが苦にならない人は向いています。バグの再現手順を利用者から聞き出すのが得意な人は、顧客インタビューも得意なことが多いです。反対に、決まった仕様を深く作り込むことが一番好きな人は、無理に移らなくても構いません。

質問5転職と社内での挑戦、どちらから始めるべきですか？

まずは社内か副業で一周回してみることをおすすめします。転職は、決める仕事が自分に合うと分かってからでも遅くありません。一周分の経験があると、転職先を選ぶときにも「どこまで任されるか」を具体的に確かめられます。

この記事について

執筆：ハコブネ編集部　／　監修：池田 龍一

株式会社Walkers 取締役

池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。

株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。

最終更新：2026年10月15日