“フルスタック”は死語？AI時代に「100倍の成果」を。顧客現場で汗を流すエンジニア像「FDE」の生々しすぎる実践事例【InsightX岸本・中塚・和田】

中塚Kaggleのようなコンペティションとビジネス現場では、そもそも解くべき問題の質が異なります。

コンペでは「決められた評価指標をいかに0.01%高めるか」という技術を極限まで競いますが、ビジネスの現場で最も重要かつ難しいのは「そもそもどの指標を追うべきか」という設計そのものです。

加えて、レコメンド領域特有の難しさとして、過去データでのシミュレーション（オフライン評価）と、現実のA/Bテスト（オンライン評価）の結果には明確な乖離があるものです。

私たちがこれまでのPoC等で蓄積してきた「勝ちパターン」も、あくまで過去の検証実績からの理論値に過ぎません。現実には、天気やトレンドの変化といった「ドメインシフト」が激しく起きますし、バイアスも複雑です。だからこそ、固定された正解を適用するのではなく、変化し続ける現場で指標を再定義し、チューニングし続ける必要があるのです。

岸本例えば「ランキング上位の商品を見せる」というECでは鉄板の施策でも、ブランドA社では全体の売上が伸びる一方で、ブランドB社では逆に全体の売上が下がってしまうようなことがあり得ます。最新の論文で書かれたレコメンド手法を用いても、目の前のサービスにおいてA/Bテストを実施したら芳しくない結果となることだってあります。

アパレルという領域は、特にこうした難しさが顕著だと感じます。クライアントのブランドイメージやユーザー層、あるいは季節などによって、正解が真逆になったりもするんです。ドメイン知識を科学し尽くすようなモデリングの腕が試される難しい領域なんです。

中塚だからこそ、汎用的な「正解」をそのまま押し付けるのではなく、「個社ごと」でデータを細かく捉え、チューニングしていかなければ、成果が出続けることにはなり得ません。そのために、エンジニアがクライアント企業のデータの中に深く潜り込むことが不可欠です。

和田そもそも、新しい施策を試したくても、そのための「土台」が整っていないことがほとんどです。

レガシーなシステム設計、部署やプロジェクトごとに分散してしまい連携されていないデータ、そして「ツール一つ入れるのに数カ月はかかる」という複雑な確認・承認フロー。

岸本私も大手テック企業にいたからこそわかるのですが、社内エンジニアであっても「他部署のデータを使う」だけで数週間の調整が必要だったりします。バックエンド開発のチームを尋ねて、データ基盤の管理主体を教えてもらい、その主体であるチームにお伺いを立てて、同時にセキュリティ審査を通して……とやっているうちに、あっという間に時間が経つ。

和田そんな現場に対して、外部のベンダーが打ち合わせのたびに「持ち帰って検討します」というペースでやっていたら、いつまで経っても実装は進まず、売上・利益面のインパクト創出がどんどん遅れてしまいます。

だから、FDEとして、時には打ち合わせの場でコードを書いたり、APIがないなら別の道を相談するなど技術的に安全な裏道を常に探ったり……と、実装に向けてスピーディーに進行できる体制を構築しようとしているんです。

エンジニアが、このように「突破力」を発揮することで、これまで難しかったことも実現できるようになっていくんです。ただし、このように動ける現場自体がそもそも多くないのが実態ですね。

岸本そして何より、SaaSプロダクト上で誰でもすぐに使える機能として固定化してしまうと、時代・クライアントに合わせた進化が止まってしまう恐れもあると思っています。

FDEが現場でコードを書いて実装するからこそ、一社でうまくいった「特注の解決策」を、即座にプラットフォームの共通機能として抽象化し、他社にも展開できる。

中塚A社で解いた難問が、翌日にはB社の課題解決の鍵になったり、C社の新規商談で活用できたりする。このスピード感は、受託開発型ビジネスではもちろんのこと、パッケージ製品を売る従来のソフトウェアビジネスでも、非常に難しいのではないかと思います。

和田現場を知るエンジニアが常にいて、市場全体の実態や状況を見極めたうえで実装するからこそ、そのコードは「使い捨て」にならず、全クライアントに高品質なかたちで提供できる資産となるんです。

和田多くのSaaSは、より多くの人がスムーズに操作できるよう、管理画面（GUI）をつくり込みます。しかし、機能を追加するたびにUI改修が必要になり、入力規則やレイアウトの検討まで細かく必要になることから、どうしても「例外的な要望」に対応しにくい。その取捨選択の検討に多くの工数がかけられていますよね。

岸本「このボタンの色を変えたい」とか「この条件の時だけ表示を変えたい」という要望一つ叶えるのに、管理画面の改修とデプロイで数日は待つことになる。そういうものだという前提で多くのプロダクト開発が進んでいるわけですが……本当にどうしようもないのでしょうか？そんなことはなく、GUIへのこだわりも疑ってみていいんじゃないかと思ったんです。

和田だから僕らは今、設定をすべて「コード」で管理することを選びました。

和田GUIがない分、常にFDEとして現場を確認し、手を動かして実装を進める必要があります。その一方で、どんな複雑なロジックも、例外的な処理も、コードを数行書くだけで実装でき、売上・利益向上への仮説検証を進められる。

別の表現をするなら、「必要なものは、必要な時に、最小の工数でつくる」ということでもあります。たとえば「可視化ダッシュボード」があれば次の施策が一気に前進するという場面がありました。この時、バイブコーディングなどの手段も臨機応変に取り入れ、その時の意思決定に特化した使い捨ての可視化ダッシュボードの画面をすぐにつくりました。

このようにして、SaaSの特徴でもある「進化と汎用性」を最大限に高めることができている、ということだと考えています。

岸本僕たち開発チームの合意事項はシンプルです。「人間は意思決定や設計、複雑な機能の実装のみを行い、単純なコーディングはAIに任せる」ということ。これを当たり前に目指すという共通意識で、InsightX全員、中でも特にFDEの3人は日々、取り組んでいます。

とはいえ、変化が特に激しい領域なので、何か特定の対応で十分というわけにはいきません。将来を見据え、LLMのプロバイダーが変わっても使い回せるような汎用的なタスク定義やワークフロー定義で自動化を進めています。

和田私たちがエンジニアとして蓄積してきた実装ノウハウを、AIへのプロンプトとして「形式知化」しようとしているわけです。

例えば「新しいクライアント用の環境構築」や「標準的なレコメンドロジックの実装」といったタスクは、コマンドを一つ実行するだけで、AIが指示書に従い、熟練者とほぼ同じ品質のコードやテストを瞬時に生成できます。

岸本退屈なボイラープレート（定型的なコード）を書く時間は、限りなくゼロにする。人間のエンジニアはやはり、「本当に問題なく動き続けるコードになっているのか」「本当にこれでエンドユーザーとクライアントが喜ぶのか」といった本質的な思考だけに集中できるようにしたい。

中塚現実の人間の購買行動を、過去のデータから画一的に予想し切ることは、やはり困難です。どのようなAIモデルを実装すべきか、常にアップデートしながら開発していく必要があります。

というのも、AIは、基本的に過去データを前提に確からしい答えを導くものだからです。一方で、天気、あるいはSNSでのインフルエンサーの動きなど、細かな予測が難しい変数による影響がアパレル業界では大きくなりやすい。このような前提の変化を、「ドメインシフト」と呼びます。そんなことが日常茶飯事な現場で、エンジニア一人ひとりが変化を緻密に捉えながら開発を進めることは何よりも重要なことです。

岸本もう一つ、厄介なのが「バイアス」です。

ユーザーがその商品をクリックしたのは、本当に欲しかったからなのか？それとも単に「ランキング1位の場所に表示されていたから」なのか？

こうしたUIによる誘導（ポジションバイアス）を十分に考慮できていないと、新しいAI機能を導入したところで「売れているものをさらに売る」だけの退屈な装置になってしまう。ですが、アパレル事業者は「新商品の露出最大化」というわかりやすい施策だけを打てばいいのではありません。発売から時間が経っていてもじわじわと売れ続けている「ロングテール商品」が適切にパーソナライズされることも、エンドユーザーの一人ひとりの体験価値最大化には不可欠です。そうした組み合わせによって、中長期的な売上の最大化にもつながるものなんです

和田たとえば、「去年の売れ筋」をおすすめする施策が、有効かもしれないし、有効じゃないかもしれない。実装内容を変更すべきか否か、そして変更する場合はどのような仮説検証を進めるべきか、こうした検討をFDEが積み重ね、また新たな仕組み・勝ち筋をつくっていくんです。

岸本通常、大企業のシステムで実験を行うには、数週間の承認プロセスが必要です。もしシステムが止まったりしてしまえば、その期間に得られるはずだった売上・利益が完全に失われてしまい、大きな責任問題になりますから。

だから基本的に、開発というのは検証環境（ステージング）でテストを繰り返すものです。ところが、当たり前の話ですがそこには「生きたユーザー」がいません。

和田生きたデータがない場所でいくら実験しても、本当のことは分からない。BtoCの購買データを扱う上で、致命的なことだと考えています。そのため、私たちは常に本番環境で安全に検証を進めるという道を実現しようとしてきたんです。

そのための武器が、「Feature Flag*」です。

和田クライアント企業に迷惑をかけないよう、少しでも悪化の兆しが見えればすぐにその検証を取りやめられる設計にできているんです。万が一のエラーも起きないような構造を徹底的に考えています。

これにより、どれだけ大きな規模でユーザーを管理しているECサービスに対しても、悪影響を与えるリスクを最小化しながら、本番環境のリアルなデータを使って安全かつ瞬時にテストを行うことができています。

岸本多くの人が「難しい」「不可能だ」と思うようなことでも、考え続ければ、突破口が見えてくる。そんな価値観で取り組んでいるのが、InsightXのFDEチームです。その一つの事例として、この「本番環境で高速検証を続ける」というのは象徴的なものだと思います。

岸本この「スクロールの度にパーソナライズされたシェルフが続けて表示される」という機能が、PALさんで好評だった直後、別のクライアントからも「うちもやりたい」と相談を受けました。通常の受託開発であれば、一から要件定義と実装を行うため数カ月はかかります。

しかし僕らは、わずか2日でデモ環境をつくり、数日後にはお見せして、クロスセルの提案フェーズを一気に前に進めることができました。

和田最近では多くのSaaSが「カスタマイズ性」も取り込むようになっていますが、それでも「新しい機能のスピーディーな横展開」はなかなか難しい。

なぜなら、A社のために新しいロジック（例：無限スクロール）を開発しても、それをB社も使えるようにするには、そもそもどのように汎用化すべきかという整理を改めて進めた上で、横展開のための「管理画面」まで開発・実装していく計画から考える必要性が出てくるためです。これらを既存フローで進める中で、大きなタイムロスが生まれます。

しかし僕らは、GUIをそもそも持たず、かつ領域を絞ることで汎用性も兼ね備えやすい構造を確立していることから、こうした工程をほとんどスキップできます。

たとえば、A社でつくった複雑なロジックを即座に「共通部品（module）」化し、B社では設定ファイル（config）でその部品を呼び出せる一行を書く──というだけで進むこともあります。

「画面（≒GUI）をつくる」という本質ではない時間を削ぎ落とし、機能という「価値」だけを最速でデリバリーできる構造になっているんです。

中塚さらに、その裏側にはもう一つ、地味ですが決定的な技術的貢献があります。「データの標準化」です。

岸本そのままでは、ある会社でつくったモデルは他社では動きません。だからこそ僕らは、行動ログ取得用SDK（Software Development Kit）とETLパイプライン（*1）を駆使し、あらゆるクライアントの行動ログや商品データを、共通の定義（スキーマ *2）に変換して自社環境に取り込んでいます。

和田この「泥臭いデータの正規化」があるからこそ、アプリケーション層は抽象化されたロジックに集中できるんですよね。

中塚そうです。データが整っているからこそ、A社で開発した分析クエリやレコメンドモデルが、B社のデータに対しても、容易に転用できるんです。

個別のカスタマイズに見えて、実は裏側では高度に抽象化されたデータ基盤とプラットフォームが動いている。この「データエンジニアリングの極致」こそが、一人の発明が瞬時に全クライアントの資産になる「複利」の源泉なんです。

和田これまでの「フルスタック」は、フロントエンドからバックエンドまで、技術レイヤーの広さを指していました。ですが、これからのフルスタックは定義が変わります。

技術だけでなく、ビジネス課題の発見、クライアントとの対話、実装、そして効果計測から次のアクションまで。プロダクト開発における「上流から下流まで」を一人で回し切る能力が求められます。

岸本AIという最強の武器を手に入れた今、一人のエンジニアが生み出せるインパクトの上限は、かつての10倍、100倍に跳ね上がっています。

だからこそ、分業して小さくまとまるのではなく、一人ひとりが「事業家」のように振る舞える環境をつくり、まず私たちがそこで実践を重ねています。

中塚綺麗なデータセットの中でスコアを競うのも、もちろん非常にエキサイティングな体験でした。

そして今は、違ったエキサイティングな体験の毎日に、大きなやりがいを感じています。自分の書いたコードが本番環境で動き、数百万人のユーザーの行動を変え、クライアントの売上を劇的に向上させる。その瞬間の「手触り感」は、やみつきになりますね。