物流の現場には、AIだけでは解けない課題がある。Hacobuのフルサイクルエンジニアの挑戦

「SaaS is Dead」という言葉が飛び交い、AIがコードを書く時代に、エンジニアのキャリアはどこへ向かうのか。そんな問いと向き合う中で注目を集めているのが、FDE（Forward Deployed Engineer）と呼ばれる職種です。顧客の課題に直接触れ、自ら設計・実装まで担う——「コードを書くだけ」から一歩踏み出したいエンジニアにとって魅力的に映る一方で、「具体的に何をする仕事なのか」「自分のキャリアとどうつながるのか」が見えにくいのが現状です。

この問いに対して、物流DXを推進する株式会社Hacobuは独自の答えを持っています。同社が展開するクラウド物流管理ソリューション「MOVO（ムーボ）」は、バース管理システム市場で6年連続シェアNo.1^（※1）を獲得。ドライバー累計ID発行数^（※2）は80万を突破し、利用事業所は4万4,000カ所^（※3）を超えます。2030年にはトラックドライバーが約24.8万人不足し、荷物の約35%が運べなくなるとされる「物流危機」。その最前線で、同社は「フルサイクルエンジニア」という働き方を打ち出しました。

CTOの戸井田 裕貴さんは、自らこの働き方を実践するなかで「エンジニアの仕事の本質は変わらない」と語ります。物流のリアルの中で見えてきた、フルサイクルエンジニアの実像に迫りました。

CTOが現場に出て見えた、“コードの先”にある仕事

―― Hacobuでは「フルサイクルエンジニア」の採用を開始しました。これはどういう働き方を想定した職種なのでしょうか

戸井田：ひとことで言うと、開発・実装だけでなく企画もやるエンジニアです。お客様のところへ行って、課題を聞いて、自分で設計して実装してリリースする。課題発見からデリバリーまでを一貫して担います。

たとえば「トラックの配車計画をまだ紙で管理していて困っている」「それを基幹システムに手入力し直す手間をどうにかしたい」といった声を現場で直接聞いて、すぐにソリューションを形にする仕事です。

―― CTOである戸井田さんご自身が、フルサイクルエンジニアを実践されていると伺いました。なぜ自ら現場に出ようと思ったのですか

戸井田：2025年12月に新たにVPoEとして奥野さんが就任し、開発組織のマネジメントを権限委譲できたことがきっかけでした。それまでは組織運営の基盤づくりに注力していたため、お客様先への訪問機会は限定的でした。

CTOとして何をやるべきかを改めて考えた結果、「お客様の課題をソフトウェアで解決する」を真正面から取り組もうと思ったんです。まずはお客様の課題の解像度を高めないと何も見えてこないと思い、現場訪問・商談同席を始めました。

最初から「フルサイクルエンジニアをやろう」と考えていたわけではなく、現場に解像度を上げにいったら、その場で課題が見えてきたので、解決するために設計と実装を何度も繰り返し、気づいたらフルサイクルエンジニアのような動きになっていたというのが正直なところです。2026年2月にリリースした「MOVO Adapter」も、この活動から生まれたプロダクトです。

―― お客様を訪問してからプロトタイプが形になるまで、具体的にはどう進むのですか

戸井田：営業とプロジェクトマネジメントの両方を担当する、ソリューションアーキテクト（以下、SA）やPdMと一緒にお客様の現場に訪問します。業務の流れと困りごとを聞いて、「こういうものがあれば解決できそうですか」と投げかけるんですが、お客様もまだ具体的なイメージが湧かないので、大体「あったらいいかもしれません」ぐらいの反応です。

ただ商談の場ではピンとこなくても、実際の業務現場を見せていただくと情報の質が一気に変わります。作業の流れ、使っている帳票、人の動き。そういった一次情報を持ち帰って、帰りの電車で訪問メンバーと振り返るんです。「あの場面の本質的な課題はこれだよね」「こういう構造なら解けるんじゃないか」「こういうプロダクト作ってみようか」と。会話しながら頭のなかで設計が進んでいくので、家に着く頃にはだいたい作るものが固まっています。

その後は、AIの出番です。ハーネスエンジニアリングと言ったりしますが、いきなりコードを書かせるのではなく、AIが自走しやすいように要件も含めガードレールを構築してから実装に入らせる。私が使っているのはCodexとClaude Codeで、自分ではコードを書きません。

この前は数日でプロトタイプができました。AIの進化によってプロトタイプの質が格段に上がったことで、現在は課題発見からお客様へのソリューション提供まで、フルサイクルエンジニアが一貫して担うことができるようになっています。

―― お話を伺っていると、いま注目を浴びているFDE（Forward Deployed Engineer）に近い仕事のように感じました。あえて「フルサイクルエンジニア」と呼んでいるのはなぜですか

戸井田：FDEという言葉がまだ新しいぶん、企業ごとに定義や業務内容にかなり幅があると感じています。客先常駐型に近いものもあれば、私たちのように非常駐で自社プラットフォーム上の開発を主体とするものもある。言葉だけでは伝わりにくいので、Hacobuとしての期待値を正確に示すために「フルサイクルエンジニア」と呼んでいます。

―― これまでのキャリアのなかでもお客様を訪問して直接課題を伺うご経験は多かったんですか

戸井田：Hacobuに入社する前はBtoCのサービス開発経験しかなく、お客様の現場に出向いた経験はありませんでした。

ただ実際にやってみて気づいたのは、どちらも本質は変わらないということです。BtoCの時代も、PdMから「この機能が全然使われない」と相談されて、データを元に課題を分析し、設計・実装を繰り返すということをずっとやってきました。結局エンジニアの仕事って、困っている人の課題を解きほぐして、解決策を形にすることなんですよね。企業の担当者とのコミュニケーションはBtoCとは作法が違うので、そこは慣れが要りましたけど（笑）、やっていることの本質は同じなんだと思います。

物流のリアルに触れたとき、エンジニアは何に熱くなるのか

―― 実際に現場を訪問されて、物流業務にはどんな課題があると感じましたか

戸井田：まだまだ属人的で、紙ベースの業務が多く残っています。

たとえば検品作業。トラックに段ボールを50個載せると決まっていて、出荷前のステージに積まれた荷物を一つずつ目視で数える現場もあります。パレットの上に段ボールが外周だけ並んでいれば数えやすいんですが、たまに真ん中の空洞の下のほうに荷物が残っていることがある。高さがあるので見えないんですよ。それを一個ずつ開けて確認している。

こういう作業を見ていると、どうにかしてあげたいと思いますよね。しかもお客様自身はそれを「課題」だと認識していないケースもあり、当たり前の業務として日々こなしている。エンジニアが現場に行って初めて見える課題が、物流領域にはたくさんあるんです。

―― 業務が属人化しているケースも多そうですね

戸井田：それはもう、山のようにあります。

ある卸売会社の配車業務を見学させていただいたときのことでした。「商品を◯◯に運んでほしい」という依頼が入った途端、担当者の方が何も参照せずにルートやドライバーの名前を言い始めたんです。

「あそこに工場があって、水曜日だから○○さんがこのエリアを回っていて、このルートならこれも一緒に運んでもらえる。後で定期便の案件が来るはずだから、2tトラックで足りるけど4tを手配して半分だけ先に積んでおこう」と。

いやいや、ちょっと待ってくれ、と（笑）。その方の頭の中にしかないルールと判断基準で、配車が回っているわけです。ただ、ご本人も「属人化していて困っている」という自覚はあって、聞けばちゃんと教えてくれます。あとはそれをシステムに落とし込むだけなので、解決への道筋は見えやすいんです。

―― 現場の方々は、エンジニアが業務を観察したり詳しく聞いたりすることに対して、どんな反応をされるのですか

戸井田：最初は「ご迷惑ではないか」「お忙しいのに邪魔にならないか」と心配していたんですが、実際に声をかけてみるとそんなことはなく、堰を切ったように業務のコツや苦労話をしていただけます。「これはこのExcelでしか管理できないんだよ～」とか「基幹システムが微妙でさ〜」とか（笑）。

お客様自身も業務を改善したいけれど、やり方がわからない。だからこそエンジニアが踏み込んで聞くことを歓迎してくれる。これはやってみて初めて気づいたことですね。

―― 複数の顧客を訪問するなかで、エンジニアとして特に面白いと感じる瞬間はありますか

戸井田：物流業務は各社バラバラで属人的で業務標準化が難しいと一般的には言われますが、私はそうは思っていません。複数の現場を回るうちに、一見バラバラに見える物流業務のなかに、共通のモデルとして抽象化できる構造が見えてくるんです。

A社、B社、C社とお伺いするなかで、「こういう構造にすれば全部解決するのでは」というひらめきが訪れる瞬間がある。大抵シャワーを浴びているときですが（笑）。それが最高に楽しいです。

個社ごとの受託開発であれば、納品した時点でその知見はリセットされるケースが多いと思います。でも私たちがやりたいのは、業界全体を最適化することです。お客様の要望をそのまま受け入れるのではなく、「ここは個社の事情だから切り離す、ここは共通化できる」と構造を整理して、設計に落とし込む。お客様が言うものをただ納品するのではないというのが、この仕事の面白さだと思います。

―― その「共通化」の先に、Hacobuとして目指しているものはあるのでしょうか

戸井田：いま、MOVOの上に新しいプラットフォーム基盤を構築しています。物流業務を共通のモデルとして体系化し、個社固有の要件も吸収できる設計を目指したものです。

現在のMOVOはSaaS型ですが、そこに顧客ごとのカスタマイズにも対応できるソリューション型を載せていくビジョンを持っています。フルサイクルエンジニアは、このプラットフォームの上で活動します。

2015年の創業からピボットせずに物流一筋で11年。その間に蓄積されたドメイン知識と顧客基盤があるからこそ、この構想が成り立つと考えています。

エンジニアの「越境」を支える、顧客との信頼関係

―― お客様の前に出ることに、不安を感じるエンジニアも少なくありません。Hacobuの場合、お客様との関係はどのような状態から始まるのでしょうか

戸井田：すでにMOVOを使ってくださっているお客様は、「物流をどうにかしたい」と本気で思っている方々です。Hacobuが物流DXを推進する会社であるという認知も100%取れていますし、お互いの信頼関係がすでにある状態で訪問します。

実際、最初に伺うと「ああ、MOVOさんね、いつも使ってるよ、ありがとう」と温かく迎えてくれます。ゼロから関係を築くための「営業」ではなく、信頼がある上での「協業」が前提。飛び込み営業のようなことは基本的にありません。

訪問先もたくさんあって、お客様のほうから「来てよ、困ってるんだよ」と声をかけてもらえます。そういう顧客ネットワークを、11年かけて築き上げてきました。

―― お客様とのコミュニケーションにおいて、エンジニアはどこまでの役割を担うのですか

戸井田：顧客折衝や期待値の調整などの顧客コミュニケーション、プロジェクトマネジメントはSAやPdMが担うので、エンジニアの仕事の本質は変わりません。従来の開発業務に、課題の発見と本質の見極めという上流工程が加わる。違いはそれだけです。

他社のFDEの求人をみると、顧客折衝力を必須スキルとしているケースもありますが、Hacobuでは求めていません。バックエンドとフロントエンドの開発経験があり、お客様とコミュニケーションが取れれば、十分に活躍できると考えています。

―― お客様先への常駐はあるのでしょうか

戸井田：いいえ、常駐はありません。訪問が必要なときに出向いたり、商談に同席し、課題を発見し、社内で開発します。Hacobuのフルサイクルエンジニアは、社内のチームに所属しながら顧客課題に向き合う働き方を想定しています。

信頼関係のある顧客基盤がある。コミュニケーションの窓口を担うSAやPdMがいる。常駐もしない。この3つが揃っているので、エンジニアが今いる領域から越境しようとしたとき、顧客との接点をもっとも持ちやすい環境がHacobuだと思っています。エンジニアが得意とする課題発見と設計・実装に集中できる環境が、すでに整っているんです。

今のキャリアの延長線上にある、フルサイクルエンジニアという働き方

―― フルサイクルエンジニアに必要なスキルを、具体的に教えてください

戸井田：必須なのは、バックエンド・フロントエンド双方の設計と実装力です。といってもAIが実装してくれるので、イメージができ、指示ができるかですかね。お客様の課題を聞いたときに、「こういうシステムを作ればいい」と頭の中にパッと浮かぶ。画面のイメージもざっくり描ける。この2つは欠かせません。

一方で、顧客の期待値調整や工数の見積もり、社内メンバーの巻き込みといったスキルは、組織としてフォローできます。一般的な開発をやってきた方であれば、必須の2つはある程度身についているはずです。加えて、人とコミュニケーションを取ることが好きなエンジニアであれば、この仕事はきっと楽しめると思います。

―― いきなり一人でこなせる人は限られると思いますが、どのように育成していく想定ですか

戸井田：最初から一人で完結できる必要はありません。すでに実践している先輩と一緒にお客様のところへ行って、課題の拾い方や設計の考え方を間近で見ながら身につけていく。そういう育て方を想定しています。

最初からフルサイクルエンジニアとして入社するルートもあれば、まずはフルスタックとして、MOVOの開発を通じてドメイン知識を身につけてから、段階的にステップアップするルートもあります。

実際、現在フルサイクルエンジニアとして動いている3名の出自はバラバラです。私自身はBtoCのソーシャルゲームがメインキャリアですし、顧客訪問の経験はゼロでした。もう一人は受託開発のスタートアップ出身で、Hacobuで初めてSaaSを学んだエンジニア。4月に入社したメンバーは大手Web企業でBtoCサービスを手がけていた方で、BtoBは初めてというキャリアです。全員、物流は未経験からのスタートです。

―― 物流の知識がなくても大丈夫なのでしょうか

戸井田：大丈夫です。弊社は物流ドメイン知識の宝庫ですし、社内には物流のスペシャリストが多く在籍しています。わからないことがあればすぐ聞ける環境です。オンボーディングのなかでも物流業務の背景を学ぶ機会がありますし、勉強会も開催されています。

カルチャーとしても聞きやすい雰囲気があって、経営会議の議事録まで社内に公開されるぐらいオープンな文化なので、情報へのアクセスで困ることはほとんどないと思います。課題解決に興味があれば、知識は自然とついてきます。

―― 最後に、フルサイクルエンジニアというキャリアに興味を持っている読者に向けて、メッセージをお願いします

戸井田：いま、多くのエンジニアが実装だけでなく、上流工程に関わりたいと思っています。AIがコードを書く時代に、エンジニアとしてどんな価値を発揮すべきかと考えているからです。フルサイクルエンジニアは、従来の開発業務に「課題発見」という工程が加わった、上流に踏み込んだ働き方が可能な職種です。

課題の本質を見つけたとき、それを解決するソリューションを作ったとき、お客様にアウトプットを提供して「これが欲しかったんだよ」と喜んでもらえたとき。そのすべてのやりがいが手に入るのが、この仕事です。

お客様の前に出ること、開発以外の領域に踏み込むこと、なんとなく怖いと感じている方も多いと思いますが、やってみると、思っていたほどのハードルはなかったと気づくはずです。ぜひ、最初の一歩をHacobuで踏み出してほしいと思います。

^（※1）出典：デロイト トーマツ ミック経済研究所『スマートロジスティクス・ソリューション市場の実態と展望【2025年度版】』バース管理システム市場のベンダー別拠点数。本調査に参加した国内主要システム6社の拠点数合計をシェア100%とした場合のシェア

^（※2）累計登録ドライバー数。利用者が「MOVO Berth」を利用する際に登録するドライバー電話番号の累計ID数

^（※3）MOVO導入拠点に加えて、MOVOを利用する事業所数のアカウントを合計した数字 。なお、記載の数値は2026年4月末時点