Digital Heroes: Guide to IT World

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 Developing the System The ...

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

当時、私はある金融システムの導入プロジェクトに関わっていました。 そのシステムのメイン開発拠点は、なんとロンドン。 「ロンドンで作られているシステムを、日本に持ってきて使う」 今ならオンライン会議やチャットで、世界中のメンバーと簡単につながります。でも、当時は今ほどオンライン会議が当たり前ではありませんでした。 では、一体どうやってプロジェクトを進めたのでしょうか。 日本側の窓口は、たった2人 日本からシステムについて質問したい場合、直接ロンドンの開発者に聞くわけではありません。 まず、日本側にいる2人の担当者に問い合わせます。 「この機能はどういう仕様ですか？」 「このデータは、どういう条件で処理されますか？」 「このエラーは何が原因ですか？」 質問は一覧表に書いていきます。 すると、日本側の担当者が内容を確認し、答えられるものは、その場で回答してくれます。 しかし、当然ながら、すべてを知っているわけではありません。 そこで登場するのがロンドンです。 分からなければ、ロンドンに聞く 日本側の担当者でも分からない。 そんな質問は、ロンドンのチームへ問い合わせます。 「この仕様について確認してください」 「この動きは想定されたものですか？」 そして、しばらくするとロンドンから回答が返ってきます。 その回答を日本側の担当者が整理し、最初に質問した人へ返していく。 今振り返ると、とてもシンプルな仕組みです。 質問する人 → 日本側の担当者 → ロンドン → 日本側の担当者 → 質問した人 まさに、人を介したグローバル開発でした。 そして、時々ロンドンから人がやってくる もちろん、メールや電話だけですべてが解決するわけではありません。 重要な局面になると、ロンドンから何人かが日本へ出張してきます。 直接顔を合わせて、仕様を確認する。 画面を見ながら議論する。 日本側の業務を理解してもらう。 そして、基本的には日本のことは日本側で対応しながら、必要なところだけロンドンの力を借りていく。 なお、ロンドンのシステムが、さらにインドやポーランドなど別の拠点へ発注されていた可能性もあります。そこは当時の私には分かりません。 でも、重要なのは「どこで誰が作っているか」だけではありません。 どうやって世界中の知識をつなぎ、日本で使える形にするか。 そこだったのです。 グローバル開発は、場...

Following a London-Built System and Discovering Its “Map” “Wow! I never knew a system architecture diagram could be this fascinating!” I still remember the moment I thought that. At the time, I was involved in a project to introduce a system developed in London into Japan. My main task was translating a large volume of documentation provided by the other side from English into Japanese. Of course, it was not simply a translation task. I had to understand the system while translating the documents. As I continued reading the English documentation, I felt as though I was gradually stepping inside a cutting-edge system. Translating Documents While Discovering the World of Finance What was interesting was that there was much more than just system documentation. The project included a huge amount of business-related documentation as well. As a result, I began studying not only the system, but also the financial business behind it. I also studied the Japanese financial business s...

ロンドンのシステムを追いかけて、見つけた「地図」 「うわっ、システム構成図って、こんなに面白いのか！」 そう思った瞬間のことを、今でも覚えている。 当時、私はロンドンで開発されたシステムを日本へ導入していくプロジェクトに参加していた。 私のメインタスクは、先方から渡される大量のドキュメントを、英語から日本語へ翻訳すること。 もちろん、単なる翻訳作業ではない。 システムのことも理解しながら翻訳する必要がある。 だから、英語のドキュメントを読み進めるほど、「最先端のシステムの中に入り込んでいく」ような感覚があった。 翻訳しているのに、金融ビジネスまで見えてくる 面白かったのは、システムドキュメントだけではなかった。 プロジェクトでは、ビジネスに関するドキュメントも非常に多かった。 そこで私は、システムだけではなく、金融ビジネスについても勉強するようになった。 日本の金融ビジネスについても調べた。 それまでに取得していたいくつかの資格の知識も、思いがけず役に立った。 「なるほど。この業務があるから、このシステムが必要なのか」 そうやって、業務とシステムが少しずつつながっていった。 翻訳しているはずなのに、気づけば金融の仕組みを勉強している。 そして、その金融ビジネスを支えるシステムの構造まで見えてくる。 これは、とても贅沢な勉強の時間だった。 コード、サーバ、そして増えていく役割 システムドキュメントを読み込んでいくと、コードもいくつか出てくる。 サーバ構成も書かれている。 最初は、 「こんなにサーバがあるのか？」 と思った。 でも、よく見てみると、それぞれ役割が違う。 ログを扱うサーバ。 バッチ処理を行うサーバ。 それぞれの機能を担当するサーバ。 そこで、ふと気づいた。 「なるほど。ものすごく高機能な一つのアプリケーションを作っているというより、少しずつ役割を持った多くのシステムを組み合わせているんだ」 一つひとつの役割を持ったシステムが集まり、大きなサービスを作っている。 そう考えると、システム全体が少しずつ理解できるようになっていった。 そして、A3一枚の「地図」に出会った そんな中で、私が一番目を見張ったのが「システム構成図」だった。 たくさんのシステムが存在している。 サーバもたくさんある。 それぞれが複雑につながっている。 それなのに、それらが A3一枚 に収...

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

ロンドン生まれのシステムを、日本の現場へつなぐ仕事 「おおっ、地下に行くほど、仕事が面白くなっていく！」 そんな不思議な感覚を持ちながら、私は毎日のようにお客様のビルの地下へ向かっていた。 当時、私はロンドンで開発されたシステムを日本に導入するプロジェクトに、日本側のシステム担当として参加していた。 すでにアプリケーションそのものは完成している。 つまり、ゼロからシステムを作るプロジェクトではない。 しかし、日本で使うとなれば話は別だった。 「完成している」のに、やることは山ほどある 日本側にはインフラチームが大勢集められていた。 さらに、周辺システムとのインターフェース変更など、日本側で追加開発しなければならないものも数多くあった。 私は、その中で少し変わった役割を担っていた。 システムそのものを理解し、それを日本側の関係者に説明する。 ところが、ロンドンから来たシステムの資料は当然ながら英語。 そこで、私が一生懸命取り組んでいたのが「翻訳」だった。 ただ、日本語に訳せばいいわけではない。 「この機能は何のためにあるのか」 「この処理は業務上、何を意味しているのか」 「日本側のシステムとは、どうつながるのか」 翻訳しながら、私は少しずつシステムそのものを理解していった。 私を支えてくれた、二人のスーパー担当者 このプロジェクトには、先方側の担当者が二人いた。 一人は、日本人なのに英語がペラペラ。 しかも、システムのことだけでなく、業務のことまで深く理解している。 まさに「スーパー日本人」だった。 もう一人はイギリス人。 彼も同じようにシステムと業務を理解していて、さらに日本語を勉強していた。 この二人に支えられながら、プロジェクトは少しずつ前へ進んでいった。 二人は基本的に日本にいた。 そして、プロジェクトの開発チームがいた場所が、お客様のビルの地下だった。 地上は「業務」、地下は「作戦」 お客様の業務関係者は上の階。 そして、システムを作り上げていくプロジェクトチームは地下。 なんとも不思議な構造だった。 二人は、ほぼ地下にこもっていた。 私も、翻訳をしたり、システムの説明を聞いたりする機会が増えるにつれて、次第に地下にいる時間が長くなっていった。 地下の部屋で、英語でシステムを勉強する。 分からない言葉があれば聞く。 業務の背景を教えてもらう。 そして、それを...

システムを作る側から、システムを「つなぐ側」へ 「えっ、今回はアプリを作らないの？」 今回のシステム開発プロジェクトが始まったとき、少し意外な展開になった。 実は、今回のシステム開発では、自分の部署はそれほど出番がなかった。 というのも、今回導入するシステムは、すでに完成している。ゼロからアプリケーションを開発するのではなく、完成したシステムを日本のビジネス環境に合わせて導入していくプロジェクトだった。 もちろん、話はそんなに簡単ではない。 新しいシステムが突然やってくれば、それまで使っていた周辺システムとの間に「Interface」という問題が発生する。 当然、各周辺システムには改修が必要になる。 「システムは完成しています」 そう言われても、周りのシステムからすれば、 「いやいや、急に新しいものが来たんですけど……」 という話だ。 こうして、Interfaceに四苦八苦するプロジェクトが始まった。 「作る」より「理解する」が仕事になった その周辺システムを作っているのが、私の部署だ。 最初は、今回のシステム導入でも、当然アプリケーション構築が必要になると想定していた。 ところが、システムを理解していくと、少しずつ見え方が変わってきた。 そのシステムは、想像以上に柔軟だった。 Config、つまり設定によって、多彩な調整ができる。 つまり、プログラムそのものを書き換えなくても、多くの要求に対応できる仕様になっていた。 さらに、今回はビジネス側も新しいシステムに合わせて業務を作り込んでいく。 そのため、「日本のビジネスに合わせてシステムを大幅改修する」という場面も、当初想定していたほど多くはなかった。 では、大規模アプリケーション製造部隊にいる自分に、何ができるのか。 そこで役立ったのが、これまで身につけてきた「英語」と「システム」の両方だった。 フルスタックを超える人には、まだかなわない もちろん、世の中には、システムを深く理解し、設計し、実装し、英語でコミュニケーションまで完結できる「フルスタックを超える」ようなメンバーがいる。 正直、そこにはまだかなわない。 でも、自分にはできることがある。 システムの仕様を理解しながら、英語のドキュメントを読み込む。 技術的な意味を理解する。 そして、それを日本のメンバーが理解できる形に翻訳する。 気がつけば、今回の主な作業...

From Building Systems to Connecting Systems “Wait… I’m not building an application this time?” When this system development project began, things took a somewhat unexpected turn. In fact, my department did not have that much of a role in the initial development of this system. Why? Because the system itself was already built. This was not a project where we developed an application from scratch. Instead, we were introducing an existing, fully developed system and adapting it to the Japanese business environment. Of course, it was not that simple. When a completely new system suddenly enters an existing environment, it inevitably creates an “interface” problem with the surrounding systems that have been running until then. Naturally, those surrounding systems need to be modified as well. “The system is already complete.” That may be true. But from the perspective of the surrounding systems, the reaction is more like: “Wait a minute… this new system just showed up out of nowhere!” And so...

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

「えっ、この人、何者なんだ？」 今回、あるイギリスのシステムを日本に適用するプロジェクトに参加しました。 日本側の中心メンバーは2人。 一人は、英語がペラペラの日本人エンジニア。 もう一人は、日本語が少しできるイギリス人エンジニアです。 最初は「技術面でサポートしてくれる人」というくらいに思っていました。 ところが、話をしているうちに、だんだん違和感が出てきました。 日本のビジネス専門家が、その人に直接問い合わせる。 システム担当者が質問すると、「では、このスクリプトを実行しましょう」と、その場で対応する。 さらに、データベースの構造を説明し、ネットワークについても教えてくれる。 「なんなんだ、この人は？」 システムだけではありません。 ビジネスのことも分かる。 英語も分かる。 日本側の事情も分かる。 データベースもネットワークも分かる。 しかも、年収を聞けば1,000万円を超えてくる。 これは確かに、フルスタックを超えている。 でも、本人の言葉は意外だった 「すごいですね。何でもできますね」 そう話しかけると、彼は少し笑って答えました。 「いや、何でも屋なんで。結構つらいですよ」 その言葉が、妙に印象に残りました。 実際、その仕事は簡単ではありません。 突然、イギリスから指示が飛んでくる。 「日本のシステムを、この仕様に変更してください」 ところが、ビジネス側から質問を受けてイギリスに投げても、すぐには答えが返ってこない。 当然です。 日本とイギリスには時差があります。 日本の夕方になると、イギリス側との仕事が本格的に始まる。 夕方から夜まで会議。 そして、日本側では朝から別の会議。 さらに、単純な通訳だけでは終わりません。 ビジネスの意図を理解し、それをシステムの言葉に変換する。 イギリス側の技術的な説明を、日本の現場が理解できる形に戻す。 必要なら自分で検討し、スクリプトを実行し、データベースやネットワークまで確認する。 「システム、ビジネス、検討、実践、通訳。何でも屋ですよ」 そう吐露してくれました。 「何でもできる」は、実は大変だ その姿を見て、私は思いました。 できる人ほど、仕事の境界線を越えてしまう。 「私はシステム担当なので、そこは分かりません」 そう言えば、仕事は楽になるかもしれません。 でも、目の前の問題を解決しようとすると、そうはいかない。 ビ...

Whoa. The moment I became captivated by a salary figure, the way I saw my entire career as an engineer began to change. The “Full-Stack Engineer” I Admired In the world of engineering, there are many people who quietly and steadily build systems behind the scenes—not just those who stand out or take the spotlight. And engineers tend to be remarkably committed to learning. I was no different. Servers. Networks. Applications. A person who understands each specialized area, can see the bigger picture, and knows what needs to be done—and who needs to do it. Someone who understands the entire development project and can make the system work as a whole. People like that are often called full-stack engineers . Among engineers, they are the people others look up to. I remember going to take difficult IPA IT certification exams in Japan. The exam would take an entire day, and dozens of engineers would gather at the venue. I could almost feel the atmosphere: “Maybe these people are also working ...

うわっ、年収の数字に心を奪われた瞬間、私のエンジニア人生の見え方が変わった。 憧れだった「フルスタック」 エンジニアの世界には、前に出て目立つ人だけではなく、地道にシステムを作り続けている人がたくさんいる。 そして、エンジニアは勉強熱心な人が多い。 私もそうだった。 サーバー、ネットワーク、アプリケーション。 それぞれの専門領域を理解し、さらに全体を見渡して、必要な人に指示を出せる。 プロジェクト開発の全体像を理解し、システムを動かせる。 そんな人は「フルスタックエンジニア」と呼ばれ、エンジニアの中でも目標の的になる存在だった。 実際、IPAの難しい試験を受けに行くと、一日がかりの試験会場に、何人ものエンジニアが集まっている。 「この人たちも、いつかフルスタックを目指しているんだろうな」 そんな空気を感じていた。 私にとって、フルスタックは憧れだった。 ところが、フルスタックの「さらに先」がいた あるとき、ロンドンのシステムを日本へ導入するプロジェクトに関わった。 そこでシステムをサポートしていたのが、イギリス人と日本人のコンビだった。 イギリス人のエンジニアは、システムをよく理解していた。 技術の話をすると、構造をすぐに理解する。 「やっぱり外国人はシステムに強いんだな」 私は、自然にそう思っていた。 でも、ある時ふと気づいた。 「いや、このイギリス人と対等に話している、この日本人は何者なんだ？」 その日本人は、日本で一人だけ採用された、英語も日本語も話せるエンジニアだった。 英語でシステムを議論し、日本語でも議論する。 技術だけではない。 ビジネスの話まで理解し、調整し、そして自分で実装までこなしている。 システム、ビジネス、言語。 そのすべてをつないでいた。 私は、すぐにその人に憧れた。 「日本人でも、ここまでいけるんだ」 後になって分かった。 私が「外国人の方がシステムに強い」と感じていたのは、外国人バイアスだった。 本当にすごかったのは、そのイギリス人と対等に渡り合い、さらに日本側のビジネスまで動かしていた日本人だった。 そして、年収の話になった ある日、その人が年収の話をしていた。 私は、それなりに自分の年収に自信があった。 日本有数の大手SIerで働くエンジニア。 社内でも難しい金融システムの開発をリードしている。 年収は700万円。 年齢を考えれば、...

システム屋と業務担当、その境界はどこへ行ったのか 社会人8年目、ロンドンで感じた小さな危機感 うわっ！お客様との会話が、まるでシステム設計レビューになっていた！ 社会人8年目。 もう9年目が見え始めていた頃の話だ。 私はシステム屋として、アプリケーション構築に携わってきた。 お客様の要件を聞き、設計し、開発し、導入する。 システムのプロとしてサービスを提供する立場だった。 そんなある日、日本のお客様がロンドンの企業からパッケージシステムを購入した。 その導入プロジェクトに参加することになり、私はシステム研修のためロンドンへ向かった。 研修期間は2週間。 場所はウォータールー周辺。 ロンドンの金融機関や大手企業が集まるエリアだった。 当時の私は、新しいシステムを学ぶことばかり考えていた。 しかし、本当に学んだのはシステムそのものではなかった。 業界構造の変化だった。 ■ お客様との会話に違和感を覚えた 研修やプロジェクトの打ち合わせが始まった。 私はシステムベンダー側として説明を行う。 アーキテクチャ。 データ構造。 運用設計。 インターフェース。 するとお客様から質問が飛んでくる。 しかも、その質問が妙に鋭い。 「その設計だと将来的な拡張性はどうなりますか？」 「データ移行時の整合性はどう担保しますか？」 「パフォーマンス試験はどの条件を想定していますか？」 あれ？ なんかおかしい。 業務要件の質問ではない。 システム屋がする質問だ。 私は少し戸惑った。 ■ なぜお客様がこんなに詳しいのか しばらくして理由が分かった。 実はお客様側の担当者の多くが元システム屋だったのである。 SIer出身。 開発会社出身。 インフラ出身。 転職して事業会社へ移った人たちだった。 つまり、 業務担当者でありながら、 システムのプロでもあった。 私は衝撃を受けた。 それまで私の中には、 お客様＝業務担当 ベンダー＝システム担当 という構図があった。 しかし現実は違った。 境界線がなくなり始めていたのである。 ■ システム屋の価値はどこにあるのか そこで考え始めた。 私たちシステム屋は何を武器にすれば良いのだろうか。 アプリケーションの専門家として技術を磨くべきか。 しかしサーバ担当もいる。 ネットワーク担当もいる。 データベース担当もいる。 インフラ領域は専門ベンダーが支えている。 で...

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

システムは完成品ではない。育てるものだ。 Configurationが変えた私のシステム観 うわっ！システムがプログラムを書かずに姿を変え始めた！ ■ システム構築には自信があった システム開発に携わってきて、気が付けばプロジェクトをコントロールする立場になって8年が経っていた。 若い頃はJavaを中心としたシステム開発に関わり、設計から開発、テスト、運用まで一通り経験してきた。 正直に言えば、システム構築にはそこそこ自信がついていた。 要件を聞く。 設計する。 開発する。 テストする。 リリースする。 そんな流れが当たり前だと思っていた。 ところが、その考え方を大きく揺さぶられる経験をした。 海外製パッケージシステムの導入プロジェクトだった。 ■ ロンドンで学んだ新しいシステム思想 お客様のシステムを構築するため、私はロンドンで2週間の研修を受けることになった。 そこで学んだのは単なる製品知識ではない。 システム構造そのものの考え方だった。 当時の私は、「お客様の要件はプログラムで実現するもの」だと思っていた。 もちろん設定は使う。 OSの設定。 サーバ設定。 ログの保存期間。 メモリ割り当て。 ジョブスケジュール。 プログラムを最適に動かし、運用しやすくするためのConfigurationである。 つまり、Configurationはシステムを支える裏方だった。 ■ Configurationの役割がまったく違った しかし、そのパッケージは違った。 驚くほど多くのConfigurationが存在していたのである。 しかも目的が違う。 システムを動かすためではない。 顧客ごとにシステムを変えるために存在していた。 承認フロー。 画面項目。 入力ルール。 通知条件。 業務プロセス。 顧客ごとの個別要件をConfigurationで吸収していた。 最初は驚いた。 「こんなことまで設定でできるのか？」 「これ、本当にプログラムを書かなくていいのか？」 研修中、何度もそんな疑問を持った。 ■ システムは完成品ではなく成長するもの だが次第に理解していった。 このシステムは完成品ではない。 成長することを前提に設計されているのだ。 運用しながら改善する。 顧客から新しい要望が出る。 すぐに開発しない。 まずConfigurationで吸収する。 それでも足りなければ次のリリ...

あっ！システムがまるで家庭菜園のように扱われていた！ 私はシステム屋として約8年間、多くのシステム開発に携わってきました。 バッチシステム、Webシステム、メール連携システム。 ベンダーとして様々な案件に関わり、ある程度の規模のシステムであれば一通り経験してきたと思います。 お客様から要望を受ける。 影響調査を行う。 修正計画を立てる。 開発する。 テストする。 リリースする。 そんな流れを何度も繰り返してきました。 私が所属していたのはアプリケーション開発部隊です。 そのため、依頼される内容も比較的大きな改修が中心でした。 小さな変更はほとんど来ません。 結果として、一つひとつの案件がシステム開発プロジェクトになります。 3カ月。 半年。 場合によってはそれ以上。 システムを「作る」という感覚はあっても、「育てる」という感覚はありませんでした。 ■ロンドンで出会ったシステムのオーナーたち そんな私がロンドンであるシステムの説明を受けたときのことです。 説明してくれたのは開発ベンダーではありません。 システムのオーナーメンバー。 おそらくシステムを発注している側の人たちです。 彼らは驚くほど自然にシステムを説明していきました。 機能説明をしながらジョークを挟む。 参加者を笑わせる。 議論を楽しむ。 どこか余裕がある。 正直に言うと、私はそんな会議に少し憧れていました。 システムを熟知しながらも、肩肘張らずに語れる姿です。 ■日本との違いはどこにあったのか 説明が進む中で、日本側から質問が飛びます。 「こんな機能はないのですか？」 「あんな機能も欲しいですね。」 すると彼らは否定しません。 難しい顔もしません。 メモを取りながらこう答えます。 「それは次のリリースに入ります。」 「それはロードマップに追加していきます。」 私はこのやり取りに衝撃を受けました。 なぜなら、日本ではよくこうなるからです。 「その変更は別案件です。」 「見積もりを作ります。」 「来年度予算で検討します。」 もちろん、それも必要です。 しかし、彼らの会話にはもっと長い時間軸がありました。 今できるかどうかではない。 このシステムをどう成長させるか。 その視点で会話していたのです。 ■システムを育てるという発想 彼らはシステムを完成品として見ていませんでした。 リリースはゴールではありません。 ...

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

あっ！自信満々で海を渡ったエンジニアが、システムの前で迷子になった。 入社8年目。 私はお客様が導入した金融システムの研修のため、ロンドンへ向かっていた。 サーバ担当、ネットワーク担当、オペレーション担当も一緒だ。 そしてアプリ担当は私一人。 しかも担当するのは単なる業務アプリではない。 金融システム全体。 数多くの機能が連携し、複数のシステムが複雑に接続される巨大なシステムだ。 私はかなり意気込んでいた。 これまで数々のシステムを構築してきた。 Javaによる3層構造。 Webシステム。 データベース設計。 インターフェース設計。 お客様向けシステムの開発。 アプリケーション開発には自信があった。 「このシステム全体を理解し、将来的には開発や運用もサポートする。」 そんな使命感を持ってロンドンへ向かった。 ■ 最初の違和感 研修初日。 講師が説明を始める。 しかし、何かがおかしい。 言っていることが頭に入ってこない。 英語の問題ではなかった。 むしろシステム用語ばかりだ。 知っている単語のはずなのに意味がつながらない。 サーバ担当は理解している。 ネットワーク担当も理解している。 オペレーション担当も質問している。 なのに私だけが取り残されていた。 なぜだろう。 ■ システムを理解していたつもりだった その答えに気づくまで時間がかかった。 私はずっと「アプリケーションの中」を見ていた。 画面があり、 業務ロジックがあり、 データベースがある。 いわゆるJava中心の3層構造だ。 しかしロンドンで説明されていたのは、そのさらに外側だった。 システムとシステムはどうつながるのか。 相手システムをどう認識するのか。 通信経路はどう設計されるのか。 障害が起きたらどこで切り分けるのか。 認証はどう行うのか。 通信先の設定はどこで持つのか。 ロードバランサーはどう動くのか。 ネットワークを越えた先にあるシステムとどう連携するのか。 私はシステム間のデータ連携設計は経験していた。 CSV連携もAPI連携も設計してきた。 だが今振り返ると、それは「つながっている前提」で設計していただけだった。 そもそもどうやってつながるのか。 なぜつながるのか。 どの設定がその接続を支えているのか。 そこへの理解が圧倒的に不足していた。 ■ 焦り続けたロンドンの日々 研修は進む。 しかし理解が...