Digital Heroes: Guide to IT World

Wait… I’m the one moving to the “client side”? It was my eighth year with the company. Until then, I had spent most of my career building systems. I gathered requirements, designed systems, developed them, tested them, and released them. When one project ended, I simply moved on to the next. That was the work I had been doing over and over again. ▼開発会社選びに悩んでいる方はこちら   Suddenly, I Was Moving to the “Client Side” At the time, I was working on the vendor side, receiving orders from another company. I had seen several people around me being assigned to the companies that were actually placing the orders. “Huh. So that’s another way of working.” That was about as far as I had thought about it. Then, one day: “Yamaguchi-san, we have an opportunity for you to be assigned to another company.” My heart skipped a beat. So, it was finally my turn. But when I heard the details, it was different from the assignments I had seen before. I was going to be assigned to the client side . “The client s...

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...

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...

Whoa! The boarding gate at Haneda Airport looked like a “difficulty level switch” for my life. The project had only started one month earlier. Then suddenly, my manager said: “You’re going to London for two weeks.” What? It wasn’t training. It wasn’t an inspection visit. It was a real overseas business trip. And the destination was London. The financial district of Waterloo. At the time, I was in my eighth year as a working professional. I had always admired global projects. But honestly speaking, I barely understood how financial systems actually worked. Of course, I studied hard. Markets, settlements, trading systems, financial networks… But it was difficult. Even after reading books and attending meetings, I still felt like I only “kind of understood” things. And in the middle of that uncertainty, the London trip was suddenly decided. The purpose was simple: “To understand the financial system running in London.” Honestly… wasn’t that impossible? The Reality of ...

Whoa! The pile of English documents on my desk looked like skyscrapers in a financial district. It was my eighth year as a working professional. I had been raising my hand for years, saying, “I want to join a global project.” I had a little confidence in my English. Still, my TOEIC score was only around 750. Looking back, I was far from fluent. But I wanted to work on international projects. I wanted to collaborate with people overseas. I wanted to see a world beyond what could only be seen in Japan. So I kept studying English little by little, waiting for my chance. And finally, that opportunity arrived. “You’ll be joining the English project.” At that time, I was genuinely excited. Finally, it had come. The global project I had been waiting for. But there was one thing bothering me. There was a sales manager on the team with an intense power-harassment style. Honestly, the atmosphere felt heavy. Still, work is work. “This is the chance I finally earned. I’m going t...

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—does work have any meaning if you never see it through to completion!? That question crossed my mind at the end of my seventh year as a working professional. Seven Years on the Frontlines As I approached the end of my seventh year, I had been involved in numerous projects—some large-scale, others smaller. I belonged to an application development team, the unit brought in when large system development was required among the many deals frontline SEs brought back. Plenty of Work, but Few Lead Roles There was no shortage of work. PC replacements, network construction. But among them, system development projects had the greatest impact. The budgets were on a completely different scale. That’s why people gathered—and just as quickly, they left. I was one of them. What Does “Staying Until the End” Mean? Naturally, there were projects I stayed with until the end, and others I left midway. But what exactly does “the end” mean? Does it include operations? Or does it stop at production ...

Whoa… was this a job where you fight the floor before the keyboard!? ■ Is System Development Just Sitting at a Desk? “System development is basically writing code in front of a computer, right?” When I hear that, I pause for a moment. Yes, that’s part of it. But the reality on-site is far too gritty to be defined that simply. I’ve led and worked on multiple system projects. If anything, I’ve been more on the management side. But I’ve also written code. Built servers. Designed databases—of course. “What about networking?” —Of course, I’ve done that too. ■ Before Wi-Fi Was Everywhere Today, Wi-Fi is taken for granted. But 10+ years ago, it wasn’t. Development environments were mostly wired. You plugged blue LAN cables into HUBs. That was the foundation of infrastructure work. But reality wasn’t that clean. If everything was neatly blue, you were lucky. Yellow, white, and random old cables from who-knows-where— The site was chaos. ■ The Reality of a 200-Person Pro...

Wow—there are moments when “human relationships” break down before the code does. ■ In a Massive Project In my seventh year as a professional, I was leading the configuration management team within a development organization. The project kept growing, eventually surpassing 200 members. Programmers, testers, infrastructure, operations—amid this complex mix of roles, our configuration management team was responsible for creating an “invisible order.” 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ Documents as “Blueprints” We produced an uncountable number of documents: Programming Standards Environment Setup Procedures Package Application Guidelines Deployment Manuals At first glance, it may seem like these could be reused via templates. But reality is different. Each client environment has unique conditions, and every detail must be rebuilt. In other words, configuration management is not about “copy-paste work”—it is “environment-adaptive architecture.” ■ Hitting a Wall...

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...