FDE in Japan: How Forward Deployed Engineers Are Reshaping AI Development

FDE in Japan: How Forward Deployed Engineers Are Reshaping AI Development

FDE (Forward Deployed Engineer) refers to an engineer who works closely with customers to identify real business problems, implement software or AI solutions, and continuously improve them using feedback from actual users. Unlike development models that primarily focus on implementing predefined specifications, FDE emphasizes understanding business operations, validating solutions with real data, and adapting technology to measurable operational needs.

Key takeaways

• FDE is a delivery approach, not a contract type: Forward Deployed Engineers work with real users from problem definition through implementation and measurable improvement.
• Japan’s major IT firms are investing: NTT DATA Group (Fortience Consulting), Hitachi, and Fujitsu each expanded FDE-related services in 2026, with different focuses.
• Man-month contracts are not disappearing automatically: FDE can operate under time-based, fixed-price, usage-based, or outcome-based models.
• Evaluate partners on six criteria: problem definition, working validation, system integration, security, outcome measurement, and post-launch accountability.
• Start small: validate a limited implementation with real users, real problems, and real data before scaling.

Why FDE Matters for Japanese Businesses in 2026

On November 10, 2026, Nikkei XTECH published an article titled NTT DATA and Hitachi Move Beyond Man-Month Contracts Through FDE.

The development reflects a broader question facing Japan’s technology industry.

As generative AI and AI agents accelerate certain software development activities, should companies continue evaluating engineering services primarily through the number of developers assigned and the months they work?

Or should they place greater emphasis on identifying business problems, validating solutions quickly, and measuring the value delivered?

However, an important distinction is necessary.

The adoption of FDE does not automatically eliminate traditional man-month contracts. FDE primarily describes an engineering and delivery approach, while man-month, fixed-price, subscription, and outcome-based arrangements describe different commercial models.

For Japanese businesses, the most important question is not whether a technology vendor uses the term FDE.

It is whether that vendor can understand business operations, develop practical solutions, and demonstrate measurable improvements after deployment.

What Is FDE, and How Is It Different from Traditional Systems Engineering?

A Forward Deployed Engineer works closely with a customer’s operational teams to identify problems, define requirements, develop solutions, and continuously improve them. The distinction is not necessarily whether an engineer works onsite, but whether their responsibilities extend from understanding the business problem through implementation and measurable improvement.

Japanese companies have long relied on systems engineers who work alongside customers.

Therefore, companies should not treat FDE as an entirely new concept that replaces traditional onsite systems engineering.

There is considerable overlap between the two approaches.

The distinction becomes clearer when examining how projects are initiated, evaluated, and improved.

Traditional Software Development

In a conventional outsourced development project, the customer typically defines business requirements before commissioning the development team.

The vendor then designs and implements software according to the agreed specifications.

This approach can work well when requirements are stable, expected outputs are clearly defined, and the organization’s processes are already understood.

However, problems arise when the initial requirements do not accurately reflect how employees perform their work.

Changing the system may then require additional approvals, revisions to specifications, or further development.

In complex AI projects, this challenge can become particularly significant because the best technical solution may not be apparent before real data and workflows are examined.

The FDE Approach to AI Development

An FDE-style engagement begins by examining the actual business problem.

Engineers work with users to understand how tasks are performed, what information is required, and where existing processes create unnecessary friction.

Consider a sales department that requests an AI system to generate weekly reports automatically.

At first, the solution might appear straightforward: connect an LLM to a reporting interface.

However, after examining the workflow, the engineer discovers that the main problem is not report writing.

Instead, sales information sits in fragments across CRM records, email correspondence, and internal documentation.

Employees spend most of their time gathering information before they can prepare the report.

In this situation, an effective solution may require connecting existing applications, organizing business information, and developing a controlled reporting workflow.

The AI model is only one component.

The value of FDE lies in identifying what should actually be built, rather than simply implementing the functionality initially requested.

Nevertheless, the FDE title does not guarantee superior engineering quality.

Experienced agile development teams and traditional systems integrators can also work closely with users and deliver iterative improvements.

Businesses should evaluate the actual delivery process rather than relying on job titles.

Why Are NTT DATA, Hitachi, and Fujitsu Investing in FDE in 2026?

Major Japanese technology companies are expanding FDE-related capabilities because enterprise AI projects increasingly require close coordination between engineering teams and business operations. The challenge is not simply deploying AI, but converting technical capabilities into systems that employees can use effectively.

NTT DATA Group: FDE-Style Consulting

On June 16, 2026, Fortience Consulting, part of the NTT DATA Group, announced the launch of its FDE-style consulting services.

The approach combines industry knowledge with engineering capabilities to support business transformation through short implementation and improvement cycles.

Rather than separating strategic consulting from technical execution, the company aims to connect problem identification, implementation, and operational improvement.

Source: Fortience Consulting, June 16, 2026 announcement

On September 17, 2026, Fortience also announced an AI-driven demand forecasting FDE service for the consumer goods sector.

The service starts by examining customer demand characteristics and the condition of available data.

It then validates forecasting models using a limited group of products before expanding the implementation.

According to the company, initial validation can begin with approximately 10 stock-keeping units (SKUs).

This is a characteristic of that particular service, not a standard scope applicable to every FDE project.

The important point is the development process.

Business users contribute their knowledge while engineers improve the forecasting system based on actual operating conditions.

Source: Fortience Consulting, September 17, 2026 announcement

The underlying shift is from treating AI model development as the final deliverable to treating its successful integration into daily operations as an essential part of the engagement.

Hitachi: Connecting IT and Operational Technology

Hitachi has been strengthening FDE capabilities through initiatives involving Physical AI, Google Cloud, and NVIDIA.

Its approach is particularly relevant to manufacturing, infrastructure, and other industries where digital systems interact with physical assets.

In these environments, software knowledge alone is insufficient.

Engineers must also understand equipment limitations, operational procedures, safety requirements, data availability, and the constraints of existing infrastructure.

On November 2, 2026, Hitachi published a case study describing an initiative to connect data across four businesses associated with industrial equipment and utilities.

Forward Deployed Engineers worked with the operating teams to identify IT and operational technology (OT) challenges.

The case study reports that the team developed a functioning prototype within three months.

Source: Hitachi, November 2, 2026 case study

The significance is not simply the development timeline.

It is the integration of operational knowledge, engineering, and real-world validation across several businesses.

However, the three-month duration applies to the specific project described by Hitachi. Readers should not interpret it as a general implementation timeline for enterprise AI systems.

Fujitsu: Rethinking Engineering and Revenue Models

On September 16, 2026, Fujitsu announced plans to evolve the business model of its Uvance portfolio.

Its proposed delivery structure includes three areas:

• Consulting and Forward Deployed Engineering.
• Applications and AI agents.
• AI platforms.

The company aims to incorporate customer-specific operational knowledge and decision-making processes into AI-powered business transformation.

Fujitsu also described a strategic transition toward outcome-linked and usage-based revenue models.

Source: Fujitsu, September 16, 2026 announcement

This is particularly interesting because it connects two developments.

The first concerns how AI solutions are engineered and implemented.

The second concerns how technology providers may eventually charge for the value their solutions deliver.

However, these are not identical changes.

Fujitsu’s announcement describes a strategic direction. It does not mean that every Fujitsu contract has already moved away from traditional time-based or project-based billing.

Taken together, the NTT DATA, Hitachi, and Fujitsu initiatives illustrate different approaches to a common challenge:

How can engineering providers move beyond delivering software functionality and become more closely involved in solving operational business problems?

Does FDE Replace Man-Month Contracts, and How Will AI Development Costs Change?

FDE does not automatically replace man-month billing. It is an approach to engineering and customer engagement that can operate under time-based, fixed-price, subscription, usage-based, or outcome-linked contracts. Businesses should evaluate how the contract aligns cost, risk, deliverables, and measurable business results.

Traditional man-month billing calculates project costs primarily through engineering resources and the duration of their involvement.

This structure has advantages.

It can provide flexibility when requirements are evolving, and it allows companies to purchase engineering capacity without fully specifying every deliverable in advance.

However, difficulties arise when the project is managed primarily around the quantity of development work rather than its operational value.

For AI projects, the optimal technical approach may change after engineers begin examining the company’s data.

A project initially described as AI agent development may turn out to require extensive data integration or modernization of an existing application.

Consequently, companies may benefit from contracts that allow hypotheses to be tested and priorities adjusted during implementation.

Four Common Commercial Models

1. Time-Based or Man-Month Contracts

The customer pays according to the engineering effort or resources provided.

This approach can support flexible development but requires clear priorities and performance monitoring.

Without appropriate governance, project effort may become the main measure of progress rather than business improvement.

2. Fixed-Price or Deliverable-Based Contracts

The customer and vendor agree on a defined scope and price.

This can simplify budgeting when requirements are sufficiently stable.

However, changes to requirements may require contract adjustments.

3. Usage-Based or Subscription Models

Customers pay according to service usage, capacity, or recurring access.

This can reduce certain upfront expenditures.

Nevertheless, companies must evaluate long-term costs, usage growth, and dependency on the service provider.

4. Outcome-Based Contracts

Compensation depends on agreed results, such as improvements in a business metric.

This can encourage both parties to focus on measurable value.

However, defining outcomes and attributing improvements to a particular technology implementation can be difficult.

Consider a company that wants to reduce customer support handling time.

An AI system may shorten the time employees spend preparing responses.

But changes in ticket volume, customer behavior, issue complexity, and staffing levels also influence support performance.

A simple before-and-after comparison may therefore be insufficient to determine the value created by AI.

What Buyers Should Ask Before Signing

Regardless of the commercial model, businesses should clarify:

• What business outcome will you measure?
• Who owns and provides the data needed to measure performance?
• How will you handle changes to requirements?
• Are cloud infrastructure, AI model usage, monitoring, and maintenance included?
• What happens if the solution does not achieve the expected results?
• Who is responsible for improving the system after initial deployment?

Moving away from man-month billing is not inherently an improvement. The real objective is to create a transparent relationship between engineering investment and business value.

What Does It Take to Develop FDE Capabilities Internally?

Developing internal FDE capabilities requires more than programming knowledge or familiarity with AI tools. Employees need experience identifying operational problems, interviewing real users, testing solutions with actual data, and explaining whether implementation has improved the business process.

On November 10, 2026, Nikkei XTECH reported that SOMPO Holdings and MISUMI Group are developing internal FDE capabilities.

The publication emphasized three practical conditions for successful FDE initiatives:

Real users, real problems, and real data.

Source: Nikkei XTECH, Developing FDE Talent Internally

These conditions should be understood as useful practical principles, not as a statistically validated formula guaranteeing successful implementation.

Real Users

A system may function correctly during development but fail to address employees’ actual needs.

For that reason, people who perform the work should participate in validation.

Their involvement helps engineers understand exceptions, informal procedures, and requirements that may not appear in formal documentation.

Real Problems

A project beginning with the instruction “we want to use AI” lacks a clear operational objective.

A more effective starting point is a specific issue.

For example:

• Employees spend excessive time verifying customer orders.
• Maintenance teams struggle to reconcile equipment inspection records.
• Information sits scattered across several departments.
• Employees repeatedly search multiple systems for the same information.

Teams can investigate these problems before selecting the technology.

Real Data

Demonstrations often use well-organized sample datasets.

Actual enterprise information is rarely that consistent.

Records may be incomplete, differently formatted, duplicated, or subject to access restrictions.

Teams should therefore validate an implementation against representative business data, with appropriate privacy and security controls.

For Japanese companies developing internal FDE teams, the objective should not necessarily be to replace every external engineering provider.

Instead, it is to strengthen the organization’s ability to understand its own processes, manage its data, evaluate technical proposals, and measure implementation outcomes.

These capabilities remain valuable even when software engineering is outsourced.

How Should Businesses Choose an FDE-Style AI Development Partner?

Businesses should evaluate an FDE-style AI development partner based on business understanding, real-world implementation capabilities, system integration, security controls, measurable outcomes, and post-launch accountability. The FDE designation alone does not establish whether a vendor can deliver successful enterprise projects.

For Japanese IT departments, DX leaders, and procurement teams, the following six criteria provide a practical evaluation framework.

1. Ability to Define the Business Problem

Can the vendor investigate the problem behind the initial feature request?

A capable partner should be able to discuss business workflows, interview users, identify constraints, and establish relevant operational metrics.

For example, before proposing an AI reporting agent, the vendor should determine whether the main bottleneck involves generating reports or collecting the information required to create them.

This distinction may significantly change the project scope.

2. Ability to Validate Working Solutions

Presentations and interface prototypes are insufficient to demonstrate operational value.

The engineering team should be able to build a limited working implementation, test it with actual users, and improve it based on feedback.

However, rapid prototyping and production readiness are different capabilities.

A vendor must also explain how a successful prototype will be tested, secured, and prepared for real-world operation.

3. Integration with Existing Business Systems

Japanese companies frequently rely on ERP systems, CRM applications, inventory platforms, sales management tools, and custom legacy software.

AI solutions become more useful when they can access appropriate information from these environments.

The vendor should understand:

• Available APIs and integration mechanisms.
• Authentication and authorization requirements.
• Data quality and formatting constraints.
• Restrictions on updating existing records.
• Long-term integration maintenance.

An AI model alone cannot resolve these challenges.

4. Security and Permission Management

When AI agents access enterprise data or perform business operations, organizations need clear controls.

These may include:

• Role-based access permissions.
• Human approval for sensitive operations.
• Execution logs and audit trails.
• Separation of testing and production environments.
• Emergency stopping procedures.
• Procedures for investigating unexpected behavior.

The vendor should demonstrate how these controls will be incorporated into the implementation. For a deeper look, see our guide to AI agent governance in Japan.

5. Ability to Measure Outcomes

Businesses should distinguish between technical completion and operational success.

For example, an AI system that processes documents automatically may reduce the time required for initial review.

However, if employees spend additional time correcting errors, the overall benefit may be limited.

Therefore, success metrics should account for relevant factors such as:

• Processing time.
• Error rates.
• Manual corrections.
• Employee review effort.
• Operational reliability.
• Actual usage after deployment.

Both parties should agree on these measures before implementation whenever possible.

6. Transparency Around Responsibilities and Costs

Enterprise AI systems require continued attention after launch.

Business processes change, source data evolves, model capabilities are updated, and existing applications may be modified.

Before signing a contract, customers should understand:

• Who monitors the system.
• Who investigates operational incidents.
• Who performs updates and improvements.
• Which services are included in ongoing support.
• Which costs recur after deployment.
• What happens when the original engineering team is no longer assigned.

A reliable AI development partner should be able to explain not only what it will build, but also how the solution will be validated, operated, improved, and supported.

What Should Companies Do Before Outsourcing AI Development?

Before commissioning an AI development project, organizations should define the business workflow, intended users, available data, expected outcomes, and operational constraints. Starting with a limited implementation allows the business to validate assumptions before committing to a larger rollout.

Consider a manufacturing company seeking to improve internal employee support.

The IT department might initially request an AI chatbot.

However, the first step should be understanding why employees currently struggle to find information.

Useful questions include:

• Which departments generate the most support requests?
• Where are the answers currently stored?
• Do employees struggle to find information, or do they need help interpreting it?
• Are different employees permitted to access different documents?
• Which questions can the system answer automatically?
• Which situations require human judgment?

Answering these questions helps determine whether the organization needs a knowledge-search application, workflow automation, system integration, or modernization of existing software.

For example, a retrieval-augmented generation (RAG) system may be appropriate when employees need to search authorized internal documents.

However, if the main problem is inconsistent information across applications, an integration project may deliver greater value.

The company can then test a limited solution with a defined group of users.

Evaluate performance against operational outcomes, not simply whether the AI produces plausible responses.

If the implementation demonstrates sufficient value and reliability, the company can expand its scope.

How Renesis Tech Japan Can Support AI Engineering

Renesis Tech Japan provides AI engineering and software development capabilities covering business requirements, data integration, AI applications, existing system connectivity, validation, and operational improvements.

Its AI Agent Development Services include the development of business-oriented AI systems using technologies such as LangGraph, CrewAI, and AutoGen.

The company also supports application modernization and custom software integration for organizations working with existing enterprise systems.

These capabilities are relevant to many FDE-style engagements.

However, this does not mean every Renesis Tech Japan engagement is formally offered as an onsite FDE service or under an outcome-based commercial agreement.

Each project must determine its own delivery arrangements, responsibilities, and contractual conditions.

The priority should remain the business problem and the most appropriate engineering approach.

Frequently Asked Questions

1. What Is the Main Difference Between an FDE and a Traditional Onsite Systems Engineer?

An onsite systems engineer generally describes an engineer’s working arrangement or assignment to a customer environment.

FDE describes an engineering role focused on identifying customer problems, implementing solutions, and improving them through direct engagement with users.

The roles are not mutually exclusive. An onsite engineer may also perform FDE-style responsibilities.

2. Does Hiring an FDE Reduce AI Development Costs?

Not necessarily.

Shorter validation cycles may reduce unnecessary development in some projects, but costs depend on the business requirements, implementation scope, integration complexity, operational controls, and contractual arrangements.

The right comparison is total project and operating cost relative to measurable business value.

3. Is FDE Necessary for AI Agent Development?

No.

Traditional engineering teams can successfully develop AI agents when the requirements, interfaces, and operating constraints are well defined.

An FDE-style approach can be particularly useful when the business problem requires investigation and repeated validation with real users and operational data.

4. What Is the Most Important Factor When Choosing an FDE-Style Development Company?

The vendor should be able to understand the operational problem and work with users to validate a solution.

Technical expertise is essential, but organizations should also assess system integration, security, production readiness, maintenance, and accountability for outcomes.

5. Can a Company Adopt FDE-Style Development Without Having Internal AI Engineers?

Yes. Companies can work with external engineering partners.

However, internal business representatives, data owners, and decision-makers must still participate in defining requirements and evaluating results.

Outsourcing engineering does not eliminate the customer’s responsibility for business decisions and governance.

Conclusion

The growing attention toward FDE in Japan during 2026 reflects a broader reassessment of how enterprise AI solutions should be developed and delivered.

NTT DATA Group is expanding consulting services that connect industry expertise with practical implementation.

Hitachi is demonstrating how engineering teams can connect IT and operational technology in complex industrial environments.

Fujitsu is exploring delivery structures that combine FDE, AI applications, and platforms, alongside a strategic shift toward outcome-linked and usage-based revenue models.

These initiatives differ in important ways.

Readers should not interpret them as evidence that every major technology provider has adopted the same delivery structure or pricing model.

For businesses purchasing AI development services, the more important shift concerns how engineering outcomes are defined.

Instead of asking only, “How many engineers will work on this project, and for how many months?” companies should also ask, “What business problem will we solve, and how will we verify that the solution works?”

A Pre-Commissioning Checklist for Decision-Makers

Before commissioning an AI development project, decision-makers should confirm the following:

• Business problem: Have we clearly defined the operational issue and identified the people affected?
• Data and systems: Do we understand which information and existing applications the solution must use?
• Validation approach: Can we begin with a limited implementation and improve it based on evidence?
• Success criteria: Can we distinguish technical performance from meaningful business outcomes?
• Responsibilities: Are development costs, maintenance, security, and post-launch obligations clearly defined?

The objective is not to adopt the FDE model simply because major technology companies are discussing it.

It is to select an engineering approach that connects real business problems with practical implementation and continuous improvement.

For organizations exploring where AI might provide value, or how existing systems could support new applications, Renesis Tech Japan offers an AI Business Diagnosis to help identify potential opportunities and implementation considerations.

Editorial note: This article reflects publicly available information as of November 10, 2026. Company initiatives, figures, and timelines are attributed to the cited announcements and Nikkei XTECH reporting, and should not be read as general benchmarks for every FDE project.