FDE（Forward Deployed Engineer）とは、顧客の業務現場に入り、AIエージェントや業務アプリを設計・実装し、PoCから本番運用・改善までを担うエンジニアリング手法／役割です。ViVOでは、AI時代の業務アプリでは「新しい画面を作ること」以上に、「人が操作しなくても済む業務を増やすこと」が重要になると考えています。
この記事で書く「要望をその日のうちに本番へ反映する」とは、動くものを先に見せ、現場の要望をその場で聞き、その日のうちに直して、翌朝には現場がそのまま使える状態に戻しておく進め方です。ViVOは、完成品を何週間もかけて作ってから見せるのではなく、動くものを数日で出し、見せて直す往復を短くすることを優先しています。
仕立て屋にたとえると、採寸して1ヶ月後に完成品を渡す店と、仮縫いの状態で一度着てもらい、その場で袖丈を直す店の違いです。体に合った服が早く手に入るのは、後者です。業務アプリも同じで、使う人が触ってはじめて、本当に直すべき場所が分かります。
この記事で使う言葉
- FDE（Forward Deployed Engineer）：お客様の業務の現場に入り、AIや業務アプリを設計・実装し、試作から本番の運用・改善までを担うエンジニア（またはその進め方）
- プロトタイプ（試作品）：動くことだけを優先して短時間で作った、機能の少ない最初の版。見せて、直すために作る
- デモ：動くものを、使う人の目の前で見せること
- 本番環境／本番反映：お客様が実際の仕事で毎日使っている状態と、そこへ直した結果を届けること。試作を見せるだけとは違い、翌日の業務にそのまま効く
- フィードバック（FB）：使った人からの「ここが使いにくい」「こうしてほしい」という返事
- MVP（最小限の製品）：必要最小限の機能だけを持つ最初の版。まず使ってもらい、要望で育てていく
- スコープ：プロジェクトで「やること」と「やらないこと」の範囲
- 受入テスト（UAT）：お客様自身が実際に使ってみて、求めたとおりに動くかを確かめる工程
- 本番障害：本番で動いているものが止まる、または誤って動くこと
2026年9月17日。建設会社様で、現場のご担当の方と、水道メーターの現場作業に使うアプリの改善の打ち合わせをしました。出た修正要望は6点。担当エンジニアは、スマートフォン対応とアカウントの分離を除く4点を、その日のうちに直して本番に反映しました。
同じ日に、担当エンジニアへこんなメッセージが届きました。
「本当にいつも迅速に対応してくださりありがとうございます。感謝しかないですし、これをもっと活用したいと思います。夢のようなことが実現化してることが本当に嬉しいです」
建設会社様 現場のご担当の方から、ViVOの担当エンジニアへ
担当エンジニアは、こう返しています。
「質の高いFB→修正のサイクルスピード感がここまで実用的なアプリ作成につながっていると思います」
ViVO 担当エンジニアから、建設会社様のご担当の方へ
この日の午後には、同じ会社の幹部会（経営層10名）でこのアプリの実績を報告し、原価管理の仕組みを全現場に広げる方向が固まりました（記事#1）。現場の「嬉しい」と経営の判断が、同じ日に動いています。
この記事では、なぜ要望をその日のうちに本番へ反映できるのかを、建設会社様の7月から10月までの記録と、メーカー様での逆の経験から書いていきます。
要望をその日に反映できる理由（要約）
- 速さは、作る側の腕だけで決まらない：デモを見せる→その場で要望が出る→即日直す、の往復が短いから速い。現場のフィードバックが速いほど、直すのも速くなる
- 荒削りでも、先に動くものを見せる：検討開始の翌日に動くものを共有し、ヒアリングの最中に40〜50分でプロトタイプを作って渡した。想定要件を全部入れた設計で始めたテーマは、見せるのが遅れた
- 直すのは機能だけではない：本番障害は当日に復旧する。要望にそのまま従うのではなく、リスクを示して代替案で合意する
- その日に直せるものと、そうでないものを分ける：6点のうち4点は即日、残り2点は設計が要るので後続に。線引きを隠さない
- 小さな「その日」の積み重ねが、経営の判断を動かす：7月の試作が、9月の幹部会の評価になり、10月には他社へ販売する合意になった
速さは才能ではなく、往復の設計。私たちは「見せて直す」の往復を、その日のうちに回る形で作っている。
建設会社様：7月の試作から10月の販売合意まで、ずっと「その日のうち」で回してきた
経営の課題：水道メーターの現場作業では、毎日、どの家をどの順で回るかのリストと地図を人が作っていました。経営としては、工事ごとの原価と粗利をつかめる仕組みを進めたい。一方で現場は、この段取りの手作業に毎日追われていました。
ViVOが入った範囲：担当エンジニアが現場と経営企画室に通い、ヒアリングと実装を繰り返しています。現場のアプリは、次のような順で育ってきました。
- 7月23日：ViVOのメンバーが、訪問先の回り順を自動で決める試作品を表計算の仕組みで作り、現場のご担当の方に共有しました。返ってきたのは「すごいですね!!」の一言です。
- 7月29日：地図出しの業務を本格的にアプリにする検討を始めました。翌30日には、動くアプリをURLで共有しています。31日には、現場で使うナビ、担当の方がリストを作って進捗を見る画面、月初にリストを班ごとに分ける画面の3つに整えました。
- 8月28日：現場からの新しい要望と不具合の報告6件に対応しました。
- 9月2日：現場のご担当の方の体感で、完成度は8割。リストの分割、地図出し、班分けの負担が大きく減り、作業の終了時刻が早まったと報告をいただきました。
- 9月17日：冒頭の打ち合わせ。要望6点のうち4点をその日に本番へ反映しました。
- 9月28日：前週に本番へ入れたセキュリティ対応が本番で効いていない、という報告が現場から届きました。原因は設定の不足で、その日のうちに復旧しています。同じ日に、班分けの月ずれと登録状況のリセットという2つの不具合も直し、リストの並び順も改善して本番に反映しました。
- 9月30日：完成度は体感で9割。次に手を付ける手書き伝票の電子化は、月40時間×3班分の削減になると試算しました。
- 10月6日：現場から「1番の端末だけで並び替えができればよい」という案をいただきました。担当エンジニアは、その端末の電池が切れたときや担当者が不在のときのリスクを説明し、「誰でも並び替えられる。最後に並び替えた順で班全体を揃える。ほかの端末に変更を知らせる」という代替案を提案して、了承をいただきました。仕様の提案から実装、リリースまで、この日のうちです。リリース直後に本番障害が起き、これも同じ日に復旧しています。
変わったこと：リスト作りは月20時間・6人から、月4時間・2人になりました。現場から会社に戻る時刻は、以前の16時〜16時15分ごろから15時4分になりました（3班・5日間の実測平均）。
「地図出しをするのが本当に嫌でした。もうリストを作ってくれるって最高だね、それがあるだけで全然違う」
建設会社様 現場のご担当の方
経営の判断・次に広がったこと：10月6日、社長と、このアプリを同社の外部へ販売していく方向で合意しました。営業は社長が担い、システムの実装はViVOが担います。社長からは「営業は任してください」という言葉をいただいています。現場のための小さなアプリが、3ヶ月で、会社の新しい商材になりました。
ヒアリングの最中に、40〜50分で作ってその場で渡した
9月17日は、もう一つの出来事がありました。担当エンジニアは、建設会社様の経営企画室で業務のヒアリングをしていました。会計ソフトへの入力、グループ会社の書類管理、グループ会社の集金業務の集計。その中で、集金業務の集計はアプリにすれば解消できそうだと判断し、その場で40〜50分かけてプロトタイプを作り、経営企画室のご担当の方にお渡ししました。
「早速のご対応ありがとうございます。今、確認した限りでとても良くできています。（中略）大変、助かります。」
建設会社様 経営企画室のご担当の方
気になる点として挙がったタイ語の表示と、現金以外の支払い方法が反映されない不具合は、その日のうちに直しています。必須項目や選択の方式、最低保証額の基準といった業務のルールは、現場のスタッフとグループ会社の社長の意見を踏まえて、改めて回答をいただくことになりました。ここは、エンジニアが決めることではないからです。
担当エンジニアは、この日のことをこう振り返っています。ヒアリング中の業務を40〜50分でアプリにして即日提供できたのは、現場のアプリと原価管理の仕組みを日々自分で触ってきたことで、作る時間と、どう作ればよいかの見通しが立つようになったから。見積もりの精度が上がった感覚に近い、と。そして次の行動を決めています。
「ヒアリングした業務の中で「アプリ化すれば解消できそうなもの」を見つけた時点で、その場でプロトタイプを作って渡す。」
ViVO 担当エンジニア（その日の振り返り）
なぜその日のうちに直せるのか：速さは、往復の設計で決まる
担当エンジニアは、速さの理由を自分の腕には置いていません。
「デモを見せる→その場で要望が出る→即日直す、というループが回っているからスピードが出ており、その実績が幹部会での評価につながった。」
ViVO 担当エンジニア（その日の振り返り）
現場のご担当の方がフィードバックを出すのが速いから、直すのも速くなる。このことを、担当エンジニアはこう書いています。
「お客様側のFB速度がこちらの改善速度を規定しているという構造は、今後の業務改善やアプリ化を進める上での理想形だと思う。ただ、全現場展開ではこのループがそのまま再現できるとは限らない。」
ViVO 担当エンジニア（その日の振り返り）
この往復を、私たちは偶然に任せていません。進め方として決めていることがあります。
- スライドは出さない。動くものを見せる。 ViVOの社内の方法論には、「Slidewareは出さない。動くものを見せてフィードバックをもらう。」と書いてあります。従来の提案書の代わりに動くプロトタイプを持っていき、お客様のデータは現場に入った初日から使います。
- 60〜70点で出す。 私たちは社内で、最初から完璧を求めず、60点から70点の出来で早く出し、コメントをもらって直すサイクルをたくさん回すほうがよい、と繰り返し話しています。
- 初回を待たせない。 依頼の翌営業日までに、目的と優先順位と小さな初回成果物と、それを見せる日をお客様と合意する。原則3営業日以内に叩き台や部分的な成果を見せる。これを社内のルールとして示しています。
- 直す順番を、現場と決める。 建設会社様の原価管理の仕組みでは、受入テストの運用を3段階にしています。毎日の運用中に不備があればその場でSlackへ連絡をもらい、早く直す。毎週の定例で1週間分を振り返り、直す順番を決める。
- その日に直せないものを隠さない。 9月17日の6点のうち、スマートフォン対応とアカウントの分離は、設計が要るので後続に回しました。10月6日の並び替え機能は、要望のままではなく、リスクを示して代替案で合意しました。
AIでコードを書く道具（ViVOではClaude Codeを使っています）で、作る時間そのものが短くなったことは前提です。ただ、速さの本体は道具ではありません。見せて、聞いて、直して、翌朝には使える状態に戻しておく。この往復をその日のうちに回る形で設計していることが、本体です。
メーカー様：見せるのが遅れたテーマと、翌日に「素晴らしい」が返ってきたテーマ
逆の経験も書いておきます。私たちがうまくいかなかった側です。メーカー様の社内マニュアルのAI検索（記事#1）では、最初のヒアリングで想定されたすべての要件を入れた複雑な構成で作り始めました。見せるのが遅れ、要件を見直して（対象を絞る、回答は簡潔にする）、設計を引き算してからやり直しています。担当エンジニアは、8月の振り返りにこう書きました。
「初期ヒアリングの段階で想定されるすべての要件を網羅した複雑なアーキテクチャを組むのではなく、まずは最小限の機能（MVP）を最速で構築し、実運用に近い環境で検証してもらうプロセスを挟むことが手戻りを防ぐ立ち回りが必要だなと思った。」
ViVO 担当エンジニア（振り返り）
その後、同じテーマで進め方を変えています。8月5日の夜に精度8割程度の簡易版を作り、翌6日にはお客様にデモの動画を共有しました。お客様のご担当の方からは、曖昧な質問のときは「どんなことを聞きたいか」を提案してあげると精度が上がりそうだ、という具体的な反応がその日のうちに返ってきています。9月の振り返りで、担当エンジニアはこう書いています。
「荒削り（プロトタイプ）であっても最速で顧客の手に触れさせ、実地でのフィードバックをベースに修正していくMVP型の開発サイクルを回す方が、結果的に顧客要件とのズレを防ぎ、提供価値を最大化できる」
ViVO 担当エンジニア（振り返り）
営業のダッシュボードでは、最初から翌日で回しました。8月19日の打ち合わせで出た内容を、翌20日にダッシュボードへ反映して共有すると、役員の方からその日のうちに返事が届きました。
「追加タブの中身が素晴らしいです。大変参考になる内容になっています。」
メーカー様 役員の方
8月26日には、午後1時55分に出た「年度の進捗を昨年と比べて見たい」という依頼を、午後3時32分には反映して共有しています。
10月のメーカー様との振り返りでは、スコープ（やることの範囲）を決めるヒアリングが遅れると、後からテーマの変更やずれが出る、という課題が議論になりました。私たちが出した答えは、最初に出すものを最小限にし、運用と保守を前提にフェーズを分けて、まず本番に出すこと。この振り返りをもとに、FDEプロジェクトの進め方を型にする作業を始めています。
自分の会社で、明日から始めるなら
私たちが建設会社様とメーカー様で2026年7月から10月にかけて実際にやってきたことから、経営者が明日から動けることを3つにまとめます。
- 現場が一番嫌がっている作業を、1つ選ぶ。 建設会社様は「地図出しが本当に嫌でした」から始まりました。社内で「一番嫌な作業を1つ出してほしい」と言うだけで、最初の一歩になります。
- 完成品を求めず、数日で動くものを見る。 60〜70点でよい。検討開始の翌日に動くものが出てくるか、ヒアリングの場で試作が出てくるか。ここで、相手の作り方が分かります。
- 直す相手を、現場の担当者に直接つなぐ。 要望がその日に返り、その日に直る往復は、経営者が間に入ると回りません。現場の担当者が直接フィードバックを出せる場を作り、経営者は結果を幹部会で受け取る側に回ります。
本番は止まることがあります。建設会社様でも、9月28日と10月6日に本番障害が起きました。どちらも当日に復旧しています。「止まらない」ではなく「止まったらその日に直す」まで含めて頼むのが、現実的です。
速さは才能ではなく、往復の設計
冒頭で挙げた5つを、事実とともに振り返ります。
1. 速さは、作る側の腕だけで決まらない。 担当エンジニア自身が、速さの理由を「デモを見せる→その場で要望が出る→即日直す」の往復に置いています。現場のご担当の方のフィードバックが速いから、直すのも速い。
2. 荒削りでも、先に動くものを見せる。 7月の試作に「すごいですね!!」、検討開始の翌日に動くアプリ、ヒアリング中の40〜50分のプロトタイプに「とても良くできています」。逆に、想定要件を全部入れた設計で始めたテーマは、見せるのが遅れました。
3. 直すのは機能だけではない。 本番障害は当日に復旧する。要望にそのまま従わず、リスクを示して代替案で合意する。
4. その日に直せるものと、そうでないものを分ける。 6点のうち4点は即日、2点は後続。線引きを隠さないから、次の要望が出てきます。
5. 小さな「その日」の積み重ねが、経営の判断を動かす。 7月23日の試作が、9月17日の幹部会の評価になり、10月6日には他社へ販売する合意になりました。
見せて、聞いて、直して、翌朝には使える状態に戻しておく。この往復をその日のうちに回る形で作っているから、現場から「夢のような」という言葉が出て、経営が次の判断に進む。それがViVOのFDEです。
速く作ることについて、よく聞かれること
- Q. その日のうちに直して、品質は大丈夫ですか？
- 本番障害は起きます。建設会社様でも9月28日と10月6日に起き、どちらも当日に復旧しています。私たちは「障害が起きない」とは言いません。毎日の運用中に不備があればその場で連絡をもらい早く直す、毎週の定例で1週間分を振り返って直す順番を決める、という受入テストの運用を先に決めています。
- Q. 全部の要望をその日に直せますか？
- 直せません。9月17日の6点のうち、即日に反映したのは4点です。スマートフォン対応とアカウントの分離は、設計が要るので後続に回しました。その日に直せるものと、そうでないものを分けて伝えることが、往復を続ける条件です。
- Q. どんな業務から始めるのがよいですか？
- ヒアリングの中で「アプリにすれば解消できそう」と分かる業務からです。建設会社様では、訪問先のリストと地図作り、集金業務の集計がそうでした。どちらも、人が毎日・毎月、手で集計や段取りをしている業務です。
- Q. その日のうちに直す進め方で、注意点はありますか？
- 3つあります。1つ目は、本番は止まることがあると最初に共有しておくことです。建設会社様でも9月28日と10月6日に本番障害が起き、どちらも当日に復旧していますが、「止まらない」ではなく「止まったらその日に直す」まで含めて合意しておきます。2つ目は、要望にそのまま従わないことです。10月6日の並び替えの要望は、電池切れや担当者不在のリスクを説明して、代替案で合意しました。3つ目は、この往復が現場のご担当の方のフィードバックの速さに支えられていることです。担当エンジニアも、全現場に広げたときに同じ往復がそのまま再現できるとは限らない、と書いています。広げるときは、フィードバックを出す人が現場ごとにいるかを、先に確かめる必要があります。
- Q. 速さは、何を指標にして見ればよいですか？
- 要望が出てから本番に反映されるまでの時間と、現場が実際に使った結果の2つです。前者は、Googleの研究チームDORAがソフトウェア提供の性能を測る指標の1つに置いている「変更のリードタイム」（変更がコードに取り込まれてから本番で動くまでの時間）と同じ考え方です[1]。私たちは、依頼の翌営業日までに初回の合意、原則3営業日以内に叩き台を目安にし、運用に入ってからは、要望がその日に本番へ反映されたかを見ています。後者は、建設会社様のリスト作りが月20時間・6人から月4時間・2人になり、現場から会社に戻る時刻が15時4分になった、という実測です。作った機能の数ではなく、現場の時間が減ったかで見ます。