ROI Case File No.545: The More Expertise Grew, the More It Vanished Inside Someone's Head
The More Expertise Grew, the More It Vanished Inside Someone's Head
Chapter 1: The Knowledge Exists, but It Can't Be Found
"We want to centrally manage product information for used motorcycles. Our staff spend too much time finding information."
Hayato Komai, CEO of MotoQuest, said this as he described the situation. A fast-growing company handling used-motorcycle sales. "Model-by-model characteristics, maintenance history, fault diagnosis, genuine-parts information—the expertise is vast. But it's scattered across our own system, maintenance records, and manufacturer sites, and finding it takes effort."
"What's happening in the course of growth?" Claude asked.
"The more staff we add, the more personnel dependency advances," Komai answered. "The knowledge inside the veterans' heads isn't being accumulated systematically. Even as newcomers grow, the knowledge isn't shared. Even when a specialized question comes from a customer, we have no structure to answer immediately."
"Have you ever tried to build a mechanism to accumulate knowledge?" I confirmed.
"We have," Komai answered. "But we tried to build a perfect system at the start, the requirements ballooned, and it collapsed. Aim for all-in-one and it never gets finished. The knowledge keeps growing, but the mechanism can't keep up."
"If the knowledge is scattered and personnel-dependent, then rather than aiming for perfect, we need to build small and grow it," I responded. "Let's break this down with agile development."
Chapter 2: What AGILE_DEVELOPMENT Asks—Development That Builds Small and Grows It
"This case needs AGILE_DEVELOPMENT."
Claude drew arrows repeating short intervals on the whiteboard.
"AGILE_DEVELOPMENT is a framework that builds small in short periods (sprints), has people use it, and repeats improvement," I explained. "Rather than fixing a perfect specification at the start, you begin from the bare minimum and grow it. Knowledge management never gets finished because knowledge keeps growing. It's a tool that doesn't wait for completion but keeps building small and cycling."
"First, let's measure the current cost," Gemini said, opening the ROI Polygraph. He entered the data Komai had provided.
"The monthly cost is in," Gemini read out. "Labor required to search scattered information: 200 hours per month on average, at ¥3,600 per hour, ¥720,000 per month. Deal-opportunity loss from being unable to immediately answer customers' specialized questions: ¥480,000 per month on average. Expected value of handover risk from non-accumulated, personnel-dependent knowledge: ¥450,000 per month on average. Duplicate-investigation labor for maintenance history and fault diagnosis: ¥330,000 per month on average. Opportunity loss from the collapse risk of large-scale all-at-once development: ¥300,000 per month on average. A total of ¥2,280,000 per month. Annualized, about ¥27,360,000."
Komai stared at the figures. "I thought it was just the time to find information. Add the opportunity loss of not answering immediately, and the risk of personnel dependency, and it's this much?"
"Now, let's design with AGILE_DEVELOPMENT," I continued.
[Forming the Scrum Team—Gather the People Who Hold the Knowledge]
"First, we form a team with members who hold the expertise," Claude said. "We put veterans and developers on the same team and build while drawing out the knowledge in their heads. When the knowledge holder and the builder are apart, personnel dependency doesn't dissolve."
[Sprint Planning—Decide the Scope to Build in Two Weeks]
"Next, we decide the scope to build in two-week units," Gemini continued. "Rather than aiming for all-in-one, we start with the most-searched model information. Because we carve into short intervals, effects begin to appear without waiting for completion."
[Incremental Development—Grow From the Minimum]
"We build the carved scope with minimal functions and have people use it," I continued. "We reflect the requests that emerge from use into the next sprint. Not a perfect specification, but a used specification, built up."
[Review and Retrospective—Cycle and Improve]
"Finally, at the end of each sprint, we look back," Claude continued. "We confirm what worked and what was missed, and apply it to the next. Even as knowledge keeps growing, keep cycling and the mechanism is a structure that catches up."
[Calculating the Investment Recovery]
"Let's run the estimate with the ROI Proposal Generator," Gemini proposed.
- Initial cost: Scrum-team formation, knowledge-base build, initial sprint development, maintenance-history/fault-diagnosis data organization, and training—¥5,100,000 total
- Monthly cost: Infrastructure operation and ongoing improvement fees combined, ¥250,000 per month
- Monthly reduction effect: Information-search labor reduction = ¥570,000 per month (assuming 80% reduction), opportunity-loss recovery from an immediate-answer structure = ¥380,000 per month, personnel-dependency resolution through knowledge accumulation = ¥350,000 per month, duplicate-investigation reduction = ¥220,000 per month, totaling ¥1,520,000 per month
- Net monthly reduction: ¥1,520,000 − ¥250,000 = ¥1,270,000 per month
- Payback period: ¥5,100,000 ÷ ¥1,270,000 = approximately 4.0 months
"Recovery in four months," Gemini summarized. "What works is building from the most-searched information rather than aiming for perfect. We don't wait for all-in-one—we release small from the high-effect scope. Because we grow it while cycling sprints, we avoid the failure of ballooning requirements collapsing."
Komai confirmed the figures. "We collapsed thinking 'a perfect system all at once.' Build small and grow it, and even as knowledge grows, it catches up."
"AGILE_DEVELOPMENT is a tool that builds and grows never-finished knowledge in small pieces," I responded.
Chapter 3: A Deployment Plan That Builds Small and Grows It
"Let me organize the approach," I said, standing at the whiteboard.
"Month one—forming the scrum team, seating veterans and developers together. Month two—sprint planning, selecting the most-searched model information. Months three and four—developing minimal functions in the initial sprint and starting use. Month five—review and retrospective, reflecting requests. Month six—expanding the scope to maintenance history and fault diagnosis. Month seven onward—adding a customer-facing immediate-answer function, cultivating knowledge by continuing sprints."
"When will it be finished?" Komai confirmed.
"We don't aim for completion," Claude responded. "Because knowledge keeps growing, wait for completion and it's forever unusable. Begin from the minimum and grow it while using. Because the usable scope widens with each sprint, effects appear without waiting for completion. Premising that it won't be finished is agile's strength."
Komai said, taking notes, "Don't wait for perfect, build small and cycle. I can see the sequence that doesn't collapse now."
Chapter 4: The Day the Knowledge Came Out of People's Heads
Nine months later, a report arrived from Komai.
The scattered product information saw search time greatly shortened through consolidation into the knowledge base. "Model-by-model characteristics and maintenance history can be found in one place. The time spent going back and forth across sites vanished," Komai wrote.
Personnel dependency also headed toward resolution. The knowledge inside the veterans' heads was accumulated into the mechanism. "'Have to ask that person or you won't know' decreased. Even newcomers can access the same knowledge," the report read.
The biggest change appeared in how development progressed. The system that had collapsed moved forward by cycling small. "What had stalled aiming for all-in-one—the usable scope grew every two weeks. Effects appeared without waiting for completion," Komai wrote.
Customer response also grew faster. They could answer specialized questions immediately. "We can answer a customer's question on the spot, with grounds. Deals stopped stalling," the report read.
As a secondary effect, a culture of putting out knowledge was born. Each time knowledge took shape through a sprint, sharing advanced. "Veterans stopped hoarding knowledge and began putting it out. Because they understood that putting it out leaves it in the mechanism," Komai wrote.
At the end of Komai's report it said: "Knowledge management had collapsed aiming for perfect. The moment we built small and cycled with agile, the knowledge came out of people's heads. Never-finished knowledge can only be grown."
The day a company where expertise vanished inside people's heads the more it grew became a company that could grow and retain knowledge, knowledge management had changed from a great construction waiting for completion into development that builds small and grows it, the report noted.
"Knowledge-management consultations usually collapse trying to build a perfect system all at once. But because knowledge keeps growing, wait for completion and it's forever unusable. What AGILE_DEVELOPMENT asks is development that builds small and grows it. Build minimally from the most-used scope, and cycle improvement while using. The day a company where expertise vanished inside people's heads the more it grew could grow and retain knowledge, what changed was not the scale of the system but the very perspective that doesn't wait for completion and grows by cycling small."
Related Files
Tools Used
- ROI Polygraph — Visualizing information-search labor, immediate-answer opportunity loss, and personnel-dependency risk
- ROI Proposal Generator — Investment-recovery simulation for sprint-rooted knowledge management
