「お客様と未来を描く戦略＆技術伴走 — CM エンタープライズサービス TAM 支援 2つのユースケース」

https://events.classmethod.jp/study-club/connpass-402011/

The "private" way to record things is the way to go to the altar.

Accompaniment Is Not About Headcount: How Small Teams Support Large Customers

Few People, Large Scope

For one major game launch, the core support team was just two people. Another customer was a large retailer with a complex organization and many product lines, and we had to work on cost, operations, and governance at the same time. Seen through the lens of traditional staff augmentation, both projects look understaffed. But in practice, the small headcount was not the biggest problem. What decided the outcome was whether the team put its effort in the right places.

I work in Enterprise Service at Classmethod. Before joining, I did customer support at an SIer and at AWS, and I saw plenty of "assign one person who knows the system really well" arrangements. They are responsive, but they easily turn into "the customer gained an extra pair of hands" rather than "the customer gained a new capability." So the kind of accompaniment I want to talk about is not about adding people. It is about getting on the same boat as the customer, helping them see the direction and keep momentum, and eventually letting them steer the boat to the destination themselves.

Let me start with the three roles as I understand them. I will save AI for the end, because it touches all three.

Three Faces of Accompaniment: Compass, Flow, Catalyst

When people hear "accompaniment," many picture someone who deeply understands the customer's system, spots problems ahead of time, and supports them proactively. That definition is not wrong, but it is still abstract. I prefer three metaphors.

The first is a compass. The destination of the customer's ship is already set, and the crew is excellent, but the ship needs someone who can look at the direction together with them. Accompaniment is not deciding where to go on the customer's behalf. It is making the direction clear when the customer has to make a trade-off.

The second is flow. A ship needs more than a direction to move forward; it needs power to reach the right place without getting stuck. Inside an organization, that means keeping the flow between information, decisions, and execution from clogging up. This is a lot like the oil and engine maintenance on a car or a ship: usually invisible, but it determines whether you can keep running.

The third is a catalyst. The customer already has its own strength. Accompaniment does not pour something in from outside; it draws out that existing strength and helps it react more fully.

These three correspond to three roles, but in real projects the same small team often switches between them as the situation changes.

Building the Team: Get on the Boat, Don't Just Send People

The basic setup is an account lead plus an operations engineer, with a solutions engineer added when needed. Depending on the contract, this can be a dedicated small team, a few people sitting alongside the customer on their boat, or even people boarding the boat together with them.

What matters here is not "how many people we sent" but "whether the customer's boat ran more steadily as a result." A dedicated team that only waits for tickets is just outsourcing, no matter how many people it has. Conversely, a team of two or three that can judge, act, and take responsibility at key moments can support a scope far larger than its headcount.

The next two customers happened to represent two different shapes.

Case One: A Game Company's "Time Axis" — Shifting the Center of Gravity

The first customer was a game company. A major version was about to launch, the timing was fixed, and the security requirements were high. After launch, there would also be optimization work. The customer's own standards were high, and they wanted to be able to maintain the system themselves eventually, but they were uneasy about what the launch would bring and whether their team could handle it.

We set up a dedicated two-person team: one account lead and one engineer. Before the launch, we broke the customer's anxiety down into concrete technical issues and resolved them one by one. On launch day, the team was on site. Before and after launch, monitoring was not "look only after something happens"; we checked key metrics once every two hours, and if anything looked wrong, we immediately opened a ticket and routed it to the back-end support team. This sounds plain, but it turned the launch from a moment that depended on luck into a process with observation, rollback, and an escalation path.

Once things were stable, the team's center of gravity began to move: first keep the launch stable, then optimize, then harden security, and finally bring in cost optimization. One important detail here is that the goal was not fixed at the start and then executed mechanically. The customer initially wanted to do a lot, and their standards were high. Once we were actually moving, we kept adjusting the "waypoints" along the way — secure this first, then talk about the next thing. The original destination remained, but the route was redrawn.

Today, when the customer has a problem, they come to us first to bounce ideas around rather than waiting for the ticket process in the contract. That kind of relationship cannot be built by stacking up headcount.

Case Two: A Retailer's "Space Axis" — Reconnecting Broken Flows

The second customer was a large retailer. It had many product lines, a different owner for each product, and a complex organization. The tools were also complex and fragmented. A common pattern was that someone would notice a problem, but no one would turn it into an issue that could actually be pushed forward, so it just sat there.

One of the customer's senior leaders knew AWS well, and his goal was for the team to become self-sufficient rather than depend on outside help indefinitely. The support we designed had three axes: cost, operations, and governance.

Why three? Because cost reduction alone, however impressive, is a one-time result. To keep reducing costs, you have to work on operations support and governance strengthening at the same time, so that the process keeps turning on its own. Cost is the entry point, but the entry point is not the destination.

The three pillars are not arranged side by side. Strategy sits at the top, and front-line operations engineers sit below, but their standpoints differ: the strategy side has to be able to go down to the floor, and the operations side has to be able to look up at the whole picture. On cost, the concrete work included designing commitment discounts such as Compute Savings Plans, and sorting out data-transfer discounts. We also built visibility: using data collected daily, we analyzed whether a given volume carried a risk of over-provisioning and whether a more favorable commitment could be purchased, turning data into evidence for procurement. The operations engineers ran things day to day and fed deviations back to the strategy side; the strategy side provided plans and expected effects, then came back to the floor to verify them. The two sides passed the ball back and forth rather than working in separate lanes.

Two concrete results came out of this: in about one month, the backlog of tasks was cleared; and the cost reduction exceeded the original target. The cost visibility work later grew into a daily cost-reduction list, and the hard parts of governance were organized into the service process.

Two Shapes, Three Constants

The team shapes were different. The game company was support along a time axis: a minimal dedicated team that kept shifting its center of gravity through launch, stabilization, optimization, security, and cost. The retailer was support along a space axis: a multi-layered organization and multiple product lines required broader coverage and connecting problems across levels.

But underneath, three things were common.

First, proposals have to be expressed in the customer's own words. Instead of pushing a menu we prepared, we translate the anxiety the customer has already voiced into an option they can judge. Only when the customer hears "this is exactly what I was worried about" will they move forward.

Second, take a neutral position and provide the materials for judgment. What the customer needs is not "we think this is good," but "this is the data, this is the trade-off, this is the risk." Much of the value of accompaniment lies in putting the basis for a decision on the table for the customer.

Third, strategy and plans have to reach the hands. Support that exists only in slides cannot move anything deep inside an organization; support that is only hands-on turns into doing the customer's work for them. Both have to sit in the same team, and each side has to be able to see the other.

The Real Difficulty of Accompaniment

This model is not without its difficulties.

One recurring problem is that the customer team closest to us understands the fastest, while the deeper layer of the organization cannot keep up. The further down you go, the more often you hit "you're right, but we can't move here." At that point, reasoning alone does not help. You have to pick one concrete use case, produce a result first, and let the result persuade people. That is why I prefer to start from a small opening where results are visible, rather than talking about company-wide reform from the outset.

Another question is: when the customer really has learned, where is the value of the accompaniment team? My view is that the value is not in "only we can do it," but in observation, experience, procurement leverage, and the responsibility to deliver to the end. Customers can learn tools and processes, but organizations always have new changes and new trade-offs, and they need someone to make those judgments with. The end point of accompaniment is not a customer that cannot function without us, but a customer that can walk on its own and still chooses to consult us at important crossroads.

Where Generative AI Fits: Faster Weapons, Human Delivery

Finally, AI. The real focus of this session was AI tools and people. AI is not about "using a few more tools"; it is about embedding AI in the accompaniment framework to amplify the effects of the compass, the flow, and the catalyst.

Our approach can be broken into a loop. First, people gather the freshest information — changes on the customer's front line, movements in the organization, updates in technology. Then AI accelerates turning that information into "weapons": analyses, proposals, and deliverables. Output has to be fast, but the last step must be done by people: turning the output into something the customer can understand, accept, and carry forward themselves. When the customer accepts it, trust increases, new opportunities appear, and the next cycle begins.

Put more plainly: AI can help you build weapons faster, but how those weapons reach the customer's hands, and how the customer comes to feel that this is their own work, is still up to people. AI provides the speed; people decide the timing and the touch.

The End Point: The Customer Runs on Its Own

Back to the original question: why can a small team support a large project?

Not because every individual is stronger, but because the team puts its effort in the right places — direction, flow, catalysis — and does not separate strategy from execution, while moving its center of gravity as the customer's phase changes. The final product of accompaniment is not a report or a set of tools, but an organization that can run on its own.

Having few people forces us to think this through properly.