ROI Case File No.500 'The Design Document Only One Person Can Read'
The Design Document Only One Person Can Read
Chapter One: Guarding 30-Year-Old Code Alone
"Only one person in the company can maintain the CAD/CAM system that's been running for 30 years."
Seiya Ashizawa, CTO of TechFusion, opened the internal system configuration diagram. Drawn large at the center was an in-house developed CAD/CAM system. With proprietary specifications specialized for press processing, about 100 people use it across all domestic and international locations. "Design data automatically connects to processing steps—the operational efficiency is excellent. However, only one person understands that mechanism."
"Are there design documents?" I confirmed.
"None," Ashizawa answered. "30 years ago when development happened, there was no convention to create design documents. Only operation manuals remain. Code comments are limited. The person in charge holds the entire structure in their head."
"How old is that person?" Claude asked.
"Late 50s," Ashizawa answered. "There are health concerns too. If they fall ill, the system becomes a black box. Last year, they were actually hospitalized for two weeks. During that time, no one could respond even to minor incidents."
"Is full-scratch rebuilding an option?" Gemini asked.
"The cost is enormous," Ashizawa answered. "Rebuilding from zero a system used by 100 people for business takes years. The business impact during that time is also large. Not a realistic option."
"Direction of creating design documents while keeping the current system," I responded. "PDCA suits this."
Chapter Two: PDCA Asks About Building Assets in Four Rotations
"This case requires PDCA."
Claude wrote four letters on the whiteboard: P, D, C, A.
"PDCA is a framework that cycles through four stages: Plan, Do, Check, Act," I explained. "Often said to be too standard to be fresh, but it's appropriate for work like reverse engineering 'where the correct answer can't be known in advance.' Perfect design documents can't be made with one round of work. Generate with AI, verify with humans, modify, and generate again—repeating these four rotations raises precision."
"Let's first measure current costs," Gemini said, opening ROI Polygraph. She entered the data from Ashizawa.
"Monthly personal dependency costs are out," Gemini read. "The maintenance person's monthly work hours: about 180 hours, salary equivalent of 1.02 million yen monthly. Backup personnel absence risk expected value at 1.5 million yen monthly—the expected value of business stoppage loss when the person leaves. Stalled improvement requests due to the person's busyness average 20 per month, opportunity loss of 400,000 yen. Investment not made due to inability to train younger talent: 200,000 yen monthly. Total: 3.12 million yen monthly. Annualized: approximately 37.4 million yen."
Ashizawa studied the figures. "There's reality in the risk expectation number."
"Now let's design with PDCA," I continued.
[P—Plan: Decide What, How Far, and How to Make]
"First, we decide the scope of design documents," Claude said. "Trying to make complete design documents for all code at once takes years. Set priorities. First, the system's overall structure diagram. Second, detailed design documents for the 10 main modules. Third, data flow diagrams. Fourth, external integration specifications. Start with this order, expand staged."
"How do you decide which modules are priority?" Ashizawa asked.
"Judge by improvement frequency over the past three years," I answered. "The more frequently improved a section, the higher the personal dependency risk. Reference improvement logs and start with the top 10 modules. Design documents for unused parts can be later."
[D—Do: Execute Reverse Engineering with AI]
"In the execution stage, we use AI tools to auto-generate design documents from code," Gemini continued. "Generative AI can read code and document function roles, data flow, and dependencies. The structure that one person was reading alone, AI drafts."
"What's the accuracy?" Ashizawa confirmed.
"About 80 percent," Claude responded. "Not fully automatic. The remaining 20 percent are parts due to proprietary specifications and historical context that AI can't judge. The current person supplements here. However, since it's not from-scratch writing but 'addition to AI's draft,' the person's burden drops significantly."
[C—Check: Person and Younger Staff Verify in Cooperation]
"The verification stage is most important," I continued. "AI-generated design documents are verified together by the current person and two younger candidate staff. Where the person says 'this description is wrong,' the younger staff interview why. The verification process itself becomes formalization of tacit knowledge."
"Not just documentation," Ashizawa confirmed.
"Documentation is the means," I responded. "The purpose is sharing the judgment criteria in the person's head with the organization. Design verification sessions as places of knowledge succession. Skip this, and documents are made but the next generation isn't trained."
[A—Act: Build in Continuous Update Cycle]
"In the improvement stage, we build a continuous update mechanism," Claude continued. "Not making design documents and finishing—update design documents whenever the system changes. Build 'design document updates' into the improvement checklist, maintaining a state where code and design documents are always synchronized. The current system is a living asset."
[Calculating Investment Recovery]
"Let's run the numbers with ROI Proposal Generator," Gemini suggested.
- Initial cost: AI reverse engineering tool contract, design document writing project, younger staff training program, continuous update infrastructure construction. Total: 6.2 million yen
- Monthly cost: AI tool continuous use, design document management infrastructure combined: 140,000 yen
- Monthly reduction: Risk expected value reduction = 1.05 million yen (70% reduction through backup personnel securing), resolution of stalled improvement requests = 280,000 yen, advancement of younger staff training = 150,000 yen, distribution of current person's load = 220,000 yen. Total: 1.7 million yen monthly
- Net monthly reduction: 1,700,000 − 140,000 = 1,560,000 yen
- Payback period: 6,200,000 ÷ 1,560,000 = approximately 4 months
"Four months payback," Gemini summarized. "However, the essential value is risk reduction. The effect of reducing the expected value of business stoppage loss when the person leaves is greater than the numbers suggest. The system that has run for 30 years is preparing to run for the next 30."
Ashizawa confirmed the figures. "I was viewing creating design documents only as cost. As risk reduction investment, the priority changes."
"Investment to make assets the organization's," I responded.
Chapter Three: Converting Tacit Knowledge to Formal Knowledge
"Let me organize the approach," I said, standing at the whiteboard.
"Month 1—Confirm scope, select 10 priority modules, select AI tools. Months 2–3—Initial AI design document generation, creation of overall structure diagrams and data flow diagrams. Months 4–5—Verification sessions with the person and two younger staff, detailing of priority modules. Months 6–7—External integration specifications, expansion to remaining modules. Month 8—Internal rule formalization for continuous updates, integration into improvement processes."
"Who do you select for the two younger staff?" Ashizawa confirmed.
"Two with motivation to read code," Claude answered. "Rather than teaching everyone, train two first. If two grow, they then convey to other employees afterward. Pyramid-style knowledge succession is realistic."
Ashizawa took notes and said, "Rather than rolling out to everyone at once, gradually expanding seems more likely to take root."
Chapter Four: The Day a Design Document Anyone Can Read Was Born
Ten months later, a report arrived from Ashizawa.
Design documents for the 10 priority modules completed in month 7. After cycling AI initial generation and person-younger-staff verification four rotations, accuracy ultimately reached 95 percent. "Not perfect design documents, but it reached a level where the system can be understood and improved," Ashizawa wrote.
The biggest change appeared in the growth of the two younger staff. Through verification sessions, opportunities to directly learn the current person's judgment criteria continuously occurred. After 10 months, one of the two could independently handle minor improvements. "Judgment criteria that don't take root just from reading textbooks were transmitted through the documentation process," the report noted.
Structural reduction of risk expected value was also realized. When the current person took vacation, the two-week absence was covered by the two younger staff. Of four troubles that occurred, three were handled by younger staff, only one escalated to the person. "Previously, we'd stop without the person," Ashizawa wrote.
Continuous update of design documents was also integrated. "Design document update" was integrated into the improvement process checklist as a mandatory item, creating a mechanism where misalignment between code and design documents doesn't structurally occur. "The problem of design documents growing old disappeared," the report noted.
As a secondary effect, the veteran person's working style itself changed. With personal dependency resolved, taking vacation became realistic, and night and weekend inquiries decreased. "I'm released from the anxiety of what happens if I fall," the person commented.
Industry evaluation also rose. Inquiries about TechFusion's reverse engineering project came from competitors, and an industry magazine introduced it as a case. "The case of reviving a 30-year-old system with AI" became a reference case for legacy system maintenance in manufacturing.
The end of Ashizawa's report read: "30 years of proprietary specifications transformed into organizational assets. The day the design document only one person could read became a design document anyone can read—that was the day this system was truly turned into an asset."
It was the day knowledge that had been personally dependent transformed into organizational knowledge.
"PDCA isn't a framework only for new development. It's also effective for the work of transforming a system that's run for 30 years into organizational knowledge. AI drafts, humans verify, generate again—repeating four rotations transforms tacit knowledge into formal knowledge. When a design document only one person could read transforms into a state anyone can read, the system shifts from being personal property to organizational property. Code that has run for 30 years was an accumulation of 30 years of judgment. The work of documenting it is both respect for the past and preparation for the future."
Related Files
Tools Used
- ROI Polygraph — Visualizing personal dependency risk, stalled improvements, and stalled training cost
- ROI Proposal Generator — Investment recovery simulation for reverse engineering project
