iTranslated by AI
Episodes 5-6: Clearing the Bottlenecks Before Adding More People
In this article, I will explain the information engineering themes covered in the novel "The Magic World Runs on Operations" (Mahou Sekai wa Unyou de Mawaru).
Shousetsuka ni Narou
Kakuyomu
In Chapters 5 and 6, the war itself temporarily settles down.
However, the work does not end there. Instead, other problems that were hidden outside the battlefield become visible. At the Royal Grand Library, inventory remains unfinished, classification systems have collapsed, and discrepancies between catalogs and actual items have left the librarians overwhelmed with cleanup tasks.
What is interesting here is that while the problem sounds like it could be described as a "shortage of personnel," that is not actually the case.
The Chancellor in the story summarizes it as follows:
It is not a lack of manpower, but rather that the manpower is not in a shape that allows them to work effectively.
The congestion is not at the front lines, but in the procedures.
This is a phenomenon that frequently occurs in real-world business systems and software operations.
Increasing Personnel Does Not Always Increase Speed
When a task is delayed, the first solution that often comes to mind is to "add more people."
Of course, there are situations where you are truly understaffed. However, if you add people while the procedures are broken, it often leads to more confusion rather than increased processing capacity.
That is exactly what is happening in the Grand Library in Chapter 5.
Return a book.
Confirm the classification.
Fix the shelf label.
Rewrite the catalog.
Someone else reviews it.
Approve it.
Return it if it fails.
Check how far it was returned.
Because this flow is not organized, the librarians spend more time "cleaning up after failures" than "returning books."
Adding more people in this state will only drag the newcomers into the same chaos. If anything, it becomes unclear who touched what, leading to more checks and rejections.
Business bottlenecks cannot always be solved by increasing headcount.
What is necessary is to first observe the flow, and identify where it stalls, where it reverts, and where judgment wavers.
Inventory Management Is a Problem of Data Integrity
Inventory taking at a library is not simply the act of neatly arranging books. It is the task of ensuring that the data in the catalog matches the physical items on the shelves.
The catalog states, "This book belongs to this classification, has this author, this title, this volume number, and this edition." The actual book exists on a physical shelf. If both match, users can find books. Librarians can return them. Other operations can proceed based on that premise.
However, once the catalog and the physical items diverge, everything becomes unreliable.
A book listed in the catalog cannot be found.
There is a book on the shelf, but it is unclear where it should be classified.
Different editions with similar bindings get mixed up.
Volume numbers are skipped.
Shelf labels do not match the contents.
This is akin to inventory control, configuration management, and database consistency management.
A discrepancy in one place breaks the premise for the next task. If you continue working on a broken premise, incorrect corrections accumulate. As a result, the worker spends time "investigating what the correct state should have been" rather than "moving toward the correct state."
In this type of problem, increasing work speed is meaningless.
First, you must establish a standard for what is correct.
Dividing and Tidying Up in Small Steps
In Episode 6, the first thing Yu avoids is the approach of "lining everything up in one long row and putting everything in the correct order."
This seems easy to understand at first glance. Just look at the entire collection and line it up correctly from beginning to end.
However, the volume is too large. The impact of a failure mid-way is also too great. Users will arrive while you are working. You cannot close the library. You cannot touch rare books. In other words, there is no option to stop everything and rebuild at once.
So, Yu divides the area into sections.
First, target a small shelf.
Fix the classification rules only within that area.
Straighten up that section.
Verify it.
Increase the number of tidied sections.
Finally, connect the sections together.
This is the approach of breaking a large problem into small boundaries for processing.
What is important is "not aiming for global optimization from the start."
First, create a locally correct state. From there, expand the correct area.
This line of thinking is also effective in software migrations and data recovery. Rather than converting all data at once, it is often safer to narrow the scope, fix the rules, verify the results, and then proceed to the next scope.
Sorting Books is a Merge Sort
The library shelf organization in Episode 6 is, implicitly, close to a Merge Sort.
Merge Sort is an algorithm that divides the target into small parts, sorts each, and finally merges the sorted parts together.
Yu in the story does not try to line up the entire library at once. First, he divides it into sections. He fixes the classification rules within a section and organizes that range. He increases the number of organized sections and finally connects them together.
This follows a structure like this:
- Divide the entire large shelf into sections of manageable size
- Within each section, sort according to comparison rules: field, author, title, volume, and edition
- Connect the organized sections using the same comparison rules
- When an exception occurs, update the comparison rules or classification before returning to the flow
Merge Sort-like thinking is compatible with a library because it is easy to handle intermediate states.
In a method that sorts everything at once, the entire shelf being worked on becomes unstable. When you stop in the middle, it is difficult to know how much is correct. In a library where users come in, this is dangerous.
On the other hand, with a method that organizes section by section, you can maintain states such as "this shelf is verified," "this section is unprocessed," and "from here onwards is waiting for merge." Even if you stop in the middle, you can distinguish between the correct areas and the unprocessed areas.
In other words, what is important here is not just the computational complexity of the algorithm.
It is the usability in terms of operations.
You can stop in the middle.
You can increase the range that has been verified.
You can localize exceptions.
On-site personnel can understand the progress.
In this sense, the strategy in Episode 6 of "dividing into sections, increasing organized blocks, and finally connecting them" is not just a work-related trick; it is a design based on Merge Sort applied to the field.
Fixing Comparison Rules
In Episode 6, Yu confirms the classification rules before arranging the books.
Field, author, title, and volume.
Editions that are different are treated separately.
Do not touch valuable books.
The library cannot be closed.
This confirmation is crucial.
Sorting processes break if the comparison rules are ambiguous. What determines what comes "before"? What determines what is "the same"? If editions are different even if the bindings look similar, are they separate items? If classifications conflict, which one takes priority?
If you automate while leaving these points ambiguous, the processing becomes faster, but mistakes also happen faster.
The danger of automation lies in the acceleration of failure.
As long as humans are struggling one by one, it is slow, but the damage is local. If an automated system moves at once based on incorrect rules, it can break the entire shelf in an instant.
Therefore, "deciding the rules first" in Episode 6 is not just work preparation. It is a safety mechanism.
Signals are Interfaces
In Episode 6, the books do not move immediately just by chanting "Invoke."
Yu uses the head librarian's bell.
The moment the bell rings, the books float a few millimeters, slide within the shelf, and flow to the left or right according to the rules. The bell is not just a performance. It is a signal to start execution and an interface that everyone on site can recognize.
To proceed with work safely, it must be clear "when it starts."
If the start timing is ambiguous, books might move while someone is reaching into the shelf. Processing might proceed while the verification staff is not looking. Users might be in the target area.
Signals align the boundary between humans and automation.
In the battlefield's "Invoke," flags were the signal for synchronization. In the library, the bell becomes the signal. Even though the locations are different, the purpose is the same.
In processes involving multiple people, not only the execution itself but also the consensus building to start the execution becomes part of the design.
Exceptions Always Occur on Site
During the shelf organization, it becomes clear that there are mixed-in editions with similar bindings.
This is a common type of exception.
According to the rules, it is decided that "different editions are treated separately." However, it is only after moving the physical items that it is discovered, "this book looks similar but is a different edition." The verification staff spots it, Lise gives instructions for separate handling, and the head librarian specifies a red tag.
What is important here is that they do not forcibly ignore the exception.
Stop the process.
Identify the exception.
Add it to the classification rules.
Branch into a different flow.
Then, continue the work.
In real-world business, exceptions always occur.
"Only this data has a different format."
"Only this customer has different contract terms."
"Only this stock has an old label."
"Only this record is missing its history."
If you automate under the premise that no exceptions will occur, the process will stop at the first exception, or worse, proceed while being incorrect.
You need a structure where you can find exceptions on-site, return them to the rules, and reflect them in the processing.
When the Clog is Cleared, the Faces on Site Change
At the end of Episode 6, one shelf is organized, and the catalog matches the physical items.
At that point, the look in the librarians' eyes changes.
It is not just because one shelf was cleaned up.
It is because they realize, "with this method, we can make progress."
This feeling is important for business improvement.
Workplaces facing large problems are often exhausted. No matter what they do, it gets reverted. Even if they fix it, it collapses again. Chased by verification, they feel no sense of moving forward.
There, when even a small area is reliably organized, the workplace changes.
You can see the correct state.
You know what to do next.
You understand how to handle exceptions.
Their work becomes progress rather than just cleaning up the aftermath.
This is not merely a matter of mood. It is an important resource for operation.
People become exhausted by work that never ends.
People can participate in work where they can see a form that reaches completion.
Summary
Episodes 5 and 6 are stories about the "work" that begins after the war.
The problem at the Royal Grand Library looked like a labor shortage, but it was actually a problem of procedures and data integrity. Before increasing the headcount, it was necessary to fix the classification rules, divide into sections, organize in small parts, verify, return exceptions to the rules, and align the boundary between humans and automation using signals.
The way of sorting is implicitly close to a merge sort. By dividing large targets, organizing section by section, and merging sorted chunks, they are moving the whole toward the correct state while managing the intermediate state.
This is a structure often seen in business systems and software operations.
Add people because it's behind.
Automate because it's chaotic.
Rebuild all at once because it's all broken.
All of these can be necessary depending on the situation. However, if you execute them without looking at the true nature of the clog, you may end up increasing the problems.
What you should look at first is the flow on-site.
Where is it backing up?
Where is the judgment wavering?
Which data is the standard for correctness?
In what units can it be safely organized?
On the battlefield, synchronized "Invokes" supported the formation.
In the library, section organization signaled by a bell advanced the inventory.
In both cases, the essence is the same.
Before making people work harder, create a form in which people can work.
That is the design that clears the clog.
Discussion