Who Is Configuration Management’s ‘Best Friend’? — The Truth Revealed in a 200-Person Project

Wow—there are moments when “human relationships” break down before the code does.

■ In a Massive Project

In my seventh year as a professional, I was leading the configuration management team within a development organization. The project kept growing, eventually surpassing 200 members. Programmers, testers, infrastructure, operations—amid this complex mix of roles, our configuration management team was responsible for creating an “invisible order.”

空いた時間でお小遣いを貯めよう！「アイリサーチ」   

■ Documents as “Blueprints”

We produced an uncountable number of documents:

• Programming Standards
• Environment Setup Procedures
• Package Application Guidelines
• Deployment Manuals

At first glance, it may seem like these could be reused via templates. But reality is different. Each client environment has unique conditions, and every detail must be rebuilt. In other words, configuration management is not about “copy-paste work”—it is “environment-adaptive architecture.”

■ Hitting a Wall

At one point, I realized something critical:
“We cannot complete these documents by ourselves.”

No matter how well we structured and organized them, a final piece was always missing.
That missing piece was the “real environment.”

■ The Most Important Partner

So, who does configuration management rely on the most?
The answer is clear: the server team.

■ Servers and Programs Cannot Be Separated

The server team designs and manages server and database configurations. Meanwhile, configuration management handles program structure. But these two are never independent.

• We must understand what packages are installed on the server
• Required program packages must be installed on the server

If either side is missing, the application will not run.

■ Standing at the “Intersection”

Configuration management is not just document control.
It is the intersection where the “programming team” and the “environment team” meet.

The team that understands the client’s environment and the team that writes code—only when these two connect does a “working system” emerge.

■ A Critical Question

So, which side does configuration management belong to?
Development? Or infrastructure?

I can say this with certainty:
Neither. And that is precisely where its value lies.

■ A Point for Debate

In many projects, configuration management is seen as a “support role.” But is that really true?

If configuration management fails:

• Bugs cannot be reproduced due to environment differences
• Deployment accidents occur
• Production and test environments diverge

In other words, the entire project’s quality collapses.

Can we still call configuration management a “supporting role”?

■ Business Insight

In the DX era, the key capability is “the power to connect.”
The value of a system is determined not by individual functions, but by “integrated operation.”

Only when configuration management and server management work closely together does the foundation become complete.
And that foundation is what ultimately supports business trust.

■ Final Thoughts

Back then, the person I spoke with the most was undoubtedly the server engineer.
Configuration management’s “best friend” is not the person writing code—it’s the one building the environment.

The moment you realize this, your perspective on projects changes completely.

I can do it! I’ll take the first step starting tomorrow.

Content Notes

• Practical insight: Configuration management cannot function alone in large-scale development; close collaboration with server teams is essential
• DX perspective: Value is defined by system-wide integration, not individual components
• Message to readers: “Who you connect with defines your value”
• Next action: Redefine which team your role should be most strongly connected to