Digital Heroes: Guide to IT World

What Comes After Building a Financial System? Bringing a London-Based System to Japan At the time, I was part of a project to introduce a financial system developed by a company in London into Japan. My role was application management. I was responsible for supporting the implementation in Japan while working closely with the system team in London and coordinating the applications across the overall system. The London-based system team took the lead in developing and managing the applications themselves. My role was to handle the coordination and confirmation needed on the Japanese side, and I stayed with the project all the way through the final stages of testing. Finally, we could see the launch approaching. I supported the operations team by reviewing their business processes and making sure they would be able to use the system effectively once it went live. I remember thinking, “This project will be finished soon.” It was March. I was starting to think about what would come next. ▼...

A System Cannot Run Alone. Every Server Has a Role Some time ago, I was involved in supporting the development of a financial system and helped introduce a system used in London into Japan. One thing left a strong impression on me. I realized that connecting systems and getting people to work together are, fundamentally, very similar. ▼開発会社選びに悩んでいる方はこちら   The London system was not simply one huge program. It was built by combining many servers, each with its own specific role. One server received data. Another processed that data. Then another server passed the processed results to the next system. Each server was simply performing its own role. But that alone does not create a system. Only when each component follows the defined rules and connects properly can the entire system begin to operate as one financial system. Being Connected Is Not Enough This is where system integration becomes difficult. It is not enough to simply connect two systems. What data should be transferred? W...

Seeing the project from a completely different perspective after receiving the “finished product” from London “Wait… is it really okay for things to be this quiet!?” Even though I was right in the middle of a system development project, the scene in front of me was surprisingly calm. Until now, I had experienced many projects where I was on the “system-building” side. We gathered requirements, designed the system, developed it, and tested it. When a project reached its peak, there could be more than 100 developers involved. Questions came from everywhere, issues piled up, meetings increased, documents multiplied, and before I knew it, even my desk had become chaos. “There were days when I couldn’t tell whether I was building a system or just organizing my desk.” That kind of day was not unusual. But this time, the landscape was completely different in a system implementation project bringing a system from London to Japan. ▼開発会社選びに悩んでいる方はこちら   Stepping Into a Project Where I’m Not D...

At the time, I was involved in a project to introduce a financial system. The main development center for that system was, surprisingly, London. “We’re going to bring a system developed in London to Japan and use it here.” Today, we can easily connect with members around the world through online meetings and chat. But back then, online meetings were not nearly as commonplace as they are today. So how did we actually move the project forward? There Were Only Two Points of Contact in Japan When someone in Japan had a question about the system, they did not contact the developers in London directly. First, they contacted the two people responsible for the system in Japan. “What are the specifications for this function?” “Under what conditions is this data processed?” “What is causing this error?” The questions were entered into a list. The Japanese representatives reviewed the questions and answered anything they could handle themselves. Of course, they did not know everything. That was w...

Connecting a London-Built System to the Reality of Japan “Wow! The deeper I went underground, the more interesting the work became!” With that strange but exciting feeling, I found myself heading down to the basement of the client’s building almost every day. At the time, I was working on a project to introduce a system developed in London into Japan, serving as the system lead on the Japanese side. The application itself had already been completed. In other words, this was not a project where we were building a system from scratch. But bringing an existing system into Japan was a completely different story. There Was Still So Much to Do, Even Though the System Was “Finished” On the Japanese side, a large infrastructure team had been assembled. In addition, there was a lot of development work required in Japan, including changes to interfaces with surrounding systems. My role in the project was somewhat different. I needed to understand the system itself and then explain it t...

  “Wait… Who is this guy?” This time, I joined a project to adapt a system from the UK for use in Japan. There were two key members on the Japanese side. One was a Japanese engineer who was completely fluent in English. The other was a British engineer who could speak a little Japanese. At first, I thought of him simply as someone who provided technical support. But as I talked with him, I began to notice something unusual. Japanese business experts would go directly to him with questions. When a system engineer asked a question, he would say, “Okay, let’s run this script,” and handle it right there. He could also explain the database structure and teach us about the network. “Who is this guy?” And it wasn’t just systems. He understood the business. He understood English. He understood the situation in Japan. He understood databases and networks. And when I heard that his annual income was over ¥10 million, I thought: Yes, this really is beyond full-stack. But His Own Words Were Un...

Where Did the Line Between IT Professionals and Business Users Go? A Small Sense of Crisis I Felt in My Eighth Year as a Professional Wow! My conversation with the customer felt more like a system design review than a business meeting! It was my eighth year as a working professional. I could already see my ninth year approaching. By then, I had spent years building business applications as a systems engineer. I listened to customer requirements, designed solutions, developed systems, and delivered implementations. My role was to provide professional IT services to customers. Then one day, a Japanese customer purchased an enterprise software package from a company in London. I joined the implementation project and traveled to London for system training. The training lasted two weeks. It took place around Waterloo, an area known for its concentration of financial institutions and large corporations. At the time, I thought I was there simply to learn a new system. What I actually learned,...

A System Is Not a Finished Product. It Is Something You Grow. How Configuration Changed My View of System Design Wow! The system started transforming itself without writing a single line of code! From Confidence in Development to a New Discovery I have been involved in system development for many years, and before I knew it, I had spent eight years leading and controlling large-scale projects. In my early career, I worked mainly with Java-based systems and gained experience across the entire lifecycle—from design and development to testing and operations. To be honest, I had become fairly confident in my ability to build systems. Gather requirements. Design. Develop. Test. Release. I believed that was simply how systems were built. Then I had an experience that completely challenged that mindset. It was a project to implement an overseas enterprise software package. The Lesson I Learned in London As part of the project, I attended a two-week training program in London to learn the prod...

The Different Mindset About Systems I Discovered in London Wow! They were treating a system as if it were a home garden! For about eight years, I worked as a systems engineer and participated in many system development projects. Batch systems. Web applications. Email integration platforms. As a vendor, I was involved in a wide range of projects and gained experience developing systems of various sizes. The process was always familiar. Receive a request from the customer. Analyze the impact. Create a modification plan. Develop. Test. Release. I repeated this cycle over and over again. I belonged to an application development team, so most of the requests we received were relatively large-scale enhancements. Small changes rarely came our way. As a result, every request became a project of its own. Three months. Six months. Sometimes even longer. I always felt that I was "building" systems. But I never felt that I was "growing" them. The System Owners I Met in London O...

Whoa… sometimes, your future begins in the very place you were trying to avoid. By my eighth year at the company, I had been living what looked like a relatively peaceful engineer life. Well… not exactly. There was one thing I had been avoiding for years. That was — a power-harassment sales manager. He yelled. He cornered people. He made unreasonable demands. He controlled the workplace with pressure and fear. So I kept my distance from him whenever possible. But one day, everything changed. Suddenly, I was ordered to join one of his projects. “Because nobody else can handle English.” …What? ■ Engineers Who Can Actually Work in English Are Rare At that moment, I was the only participant from the development team. Even from the application team, I was alone. The reason was simple. “Because you can at least read English.” This is actually a surprisingly controversial issue in the IT industry. Many engineers can build systems. Many can write code. But very few can su...

Whoa… the moment I realized I was eating lunch on top of a server, reality itself felt like it had glitched. ■The Dev Floor Was a Battlefield This was a 200-person development project. But the workspace? Nowhere near enough. Every seat was packed. Trying to eat lunch at your desk meant balancing your bento next to your keyboard—if you could even find space. “Let’s eat together?” That option was already gone. ■The Disappearance of Meeting Rooms Meeting rooms—normally the safe haven for lunch— were almost entirely converted into testing environments. Only one room remained. And it was always occupied. “Maybe the test rooms?” No chance. Testing never stopped. Even during lunch, engineers rotated in and out. Noise. Movement. Pressure. “So… where do we eat?” No one had an answer. ■The Forbidden Idea: Server = Table Then someone noticed it. Rack-mounted servers. Randomly placed. Sitting on desks. “No space… maybe we can use this?” It started small. Someone plac...