スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

「システムを作ってきたのに、なぜ何も分からない？」―ロンドンで突きつけられたエンジニアの現実

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

I Built Systems for Years—So Why Did I Understand Nothing?

The Reality Check I Faced in London as an Engineer Wow! An engineer who crossed the ocean full of confidence found himself completely lost in front of a system. It was my eighth year with the company. I was traveling to London to attend training for a financial system that one of our customers had purchased. The server engineer, network engineer, and operations engineer were all there as well. And I was the only application engineer. What I was responsible for was not just a business application. It was the entire financial system. A massive platform where countless functions worked together and multiple systems were connected in complex ways. I was highly motivated. I had built many systems before. Java-based three-tier architectures. Web applications. Database design. Interface design. Customer-facing systems. I was confident in my application development skills. "My mission is to understand this entire system and eventually support its development and operations." With tha...
コメントを投稿
続きを読む

「システムは納品物じゃない」──ロンドンで見た、“育てて世界へ売る”という発想

「完成」がゴールだと思っていた うわっ！金融システムが“生き物”みたいに成長していた。 私はこれまで、約8年間システム作りに関わってきた。 設計し、開発し、テストし、納品する。 そういう世界で仕事をしてきた。 もちろん、その中で改善提案もしてきた。 しかし、どこかで「システムは作って終わり」という感覚があった。 そんな中、あるプロジェクトに参加することになった。 お客様が、ロンドンから金融系システムを日本へ持ってくるプロジェクトだった。 ロンドンで見た“異様な光景” 私はアプリケーション観点でシステムを理解する担当として、2週間ロンドン研修に参加した。 そこで見たものが衝撃だった。 そのシステムを所有していたのは、システムベンダーではない。 ロンドンの金融会社だった。 つまり、金融会社自身が金融基幹システムを作り、それを自社資産として海外へ販売していたのである。 しかも、それを買ったのは日本の金融会社。 私は驚いた。 日本では、 「金融会社が使うシステムをITベンダーが作る」 という構造が当たり前だった。 しかしロンドンでは違った。 「金融会社が、自分たちで磨き上げたシステムを商品として売る」 なのである。 しかも、国内マーケットだけではない。 海外の金融機関へ販売していた。 システムそのものが、国境を越えるビジネスになっていた。 運用担当者が9画面を操っていた さらに驚いたのは運用現場だった。 運用担当者は、9つのスクリーンを同時に使いこなしていた。 こちらが、 「こういう機能はあるんですか？」 と聞く。 すると返ってきたのは、 「それは現在開発中だ」 という言葉だった。 私はそこで初めて気づいた。 この人たちは、“完成品”を運用しているのではない。 “成長途中のシステム”を運用しているのだ。 そして、現場の知見をもとに、継続的に改善し続けていた。 最初から完璧を目指していた自分 一方、当時の私は違った。 最初の開発で、完璧なシステムを作ろうとしていた。 でも実際には、 要件は曖昧なことも多い。 お客様自身も、 「本当に欲しいもの」 を言語化できていないこともある。 そして何より、自分自身の知識もまだ中途半端だった。 しかし不思議なことに、システムを作り終える頃には、かな...
コメントを投稿
続きを読む

“A System Is Not a Deliverable” — What I Learned in London About Building Systems That Grow and Sell Globally

I Used to Think “Completion” Was the Goal Whoa! The financial system was evolving like a living organism. For nearly eight years, I had been involved in system development. Designing, developing, testing, and delivering systems. That was the world I worked in. Of course, I also proposed improvements along the way. But deep down, I still had the mindset that “a system is complete once it’s delivered.” Then one day, I joined a project that changed my perspective entirely. It was a project where a customer was bringing a financial system from London to Japan. The “Unusual Scene” I Witnessed in London I joined a two-week training program in London as the person responsible for understanding the system from the application perspective. What I saw there shocked me. The system was not owned by a software vendor. It was owned by a financial institution in London. In other words, the financial company itself had built a core banking system and was selling it overseas as its own bu...
コメントを投稿
続きを読む

“Five of Us Walked In. One Engineer Overwhelmed Us.” — The Shock of Meeting World-Class Engineers in London

Back When I Still Had Confidence Whoa! My entire “map of what an engineer should be” was completely rewritten in London. It was my eighth year as a working professional. By then, I had already gained solid experience building systems. Java 4. At the time, it was considered cutting-edge technology, and I had been involved in managing advanced enterprise systems. I had worked on multiple domestic projects in Japan, and little by little, my confidence as an engineer had grown. “Working together with overseas system engineers.” Just hearing that excited me. And the location was London — one of the world’s financial technology centers. Before the training began, I thoroughly studied massive amounts of documentation. System architecture. Operational design. Failure handling flows. But something immediately surprised me. “How can such a specialized system have documentation this detailed?” The system itself was extremely unique. It was heavily customized and built internally....
コメントを投稿
続きを読む

「5人で挑んで、1人に圧倒された」──ロンドンで見た“世界基準エンジニア”の衝撃

「自信」を持っていた、あの頃 うわっ！“エンジニア人生の地図”が、ロンドンで一気に書き換わった──。 社会人8年目。 それなりにシステム構築を経験してきた。 Java4。 当時としては最先端側のシステム管理にも関わっていた。 国内案件も複数経験し、自分なりの自信もついてきていた頃だった。 「海外のシステム担当と連携する」 それだけで胸が高鳴った。 しかも場所はロンドン。金融システムの中心地の一つだ。 研修前、私は大量の手順書を読み込んだ。 システム概要、運用設計、障害対応フロー。 だが、そこでまず驚いた。 「特別なシステムなのに、ここまで書くのか？」 そのシステムは、かなり特殊だった。 しかも自前で作り込まれている。 普通なら“属人化”していてもおかしくない。 だが実際は逆だった。 手順書が異常なほど整理されていた。 まるでソフトウェアそのもののように、構造化されている。 「誰が見ても分かるように作る」 そんな思想が、資料全体から滲み出ていた。 日本では、“詳しい人しか分からない資料”に出会うことも多かった。 だが、ロンドンでは違った。 “人に依存しない設計”を、本気でやっていた。 ここでまず、考えさせられた。 「日本は丁寧」と言われる。 だが、本当にそうなのか？ ロンドン金融システムの現場で見た“異様な景色” さらに衝撃だったのは、実際の運用現場だった。 巨大なスクリーンが9枚。 一人のオペレーターが、その全体を監視している。 しかも、その人が説明までしていた。 全体説明。 詳細説明。 運用設計。 障害時の考え方。 カバー範囲が、とにかく広い。 こちらは5人以上で話している。 だが向こうは、ほぼ一人。 「え？」 正直、最初は理解できなかった。 日本なら、 インフラ担当、DB担当、運用担当、アプリ担当…。 細かく役割分担されることが多い。 だが、ロンドンの現場では、一人が広く深く理解している。 もちろん裏にはチームがいる。 だが、“その場で説明できる範囲”が圧倒的だった。 「世界で戦う」とはこういうことなのか？ 私は、その時初めて感じた。 「日本のエンジニアは、分業に最適化されすぎているのでは？」 もちろん、日本の品質は高い。 慎重さもある。 レビュー文化も強い...
コメントを投稿
続きを読む

「“作る側”なのに、なぜ席が違う？」——ロンドン行きの飛行機で感じた、IT業界の静かな格差

“エコノミーじゃない”だけで感動していた うわっ！空の上にも“会社の階級”って存在するのか——そう思った。 入社8年目。 私はロンドンへ向かう飛行機に乗っていた。 理由は、お客様がロンドンで動いている金融システムを導入するための研修。 当時の自分にとって、“海外金融システム”という言葉だけで別世界だった。 しかもロンドン。 映画でしか見たことのない場所。 そして、さらに驚いたのは飛行機だった。 プレミアムエコノミーですら「すごい世界」 日立のメンバーはプレミアムエコノミー。 正直に言う。 その時の私は、それだけで十分感動していた。 「え？席広い！」 「足伸ばせる！」 「毛布違う！」 そもそも“エコノミー以外”なんて知らない。 飛行機にランクがあることすら、現実感がなかった。 だから、ビジネスクラスなんて、ほとんど異世界だった。 ラウンジって何？ 空港で、お客様側メンバーが別方向へ歩いていく。 「ラウンジ使うので」 ラウンジ？ 何それ？ しかも、お客様はビジネスクラス。 別ルート。 別搭乗。 別空間。 同じプロジェクト。 同じロンドン。 でも、移動の世界が違う。 その時、少しだけ頭によぎった。 「あれ？やっぱりベンダーだから？」 “技術側”なのに、なぜ立場が違う？ その出張には、40代のシステムサーバ担当も参加していた。 金融機関システムを長年支えてきたベテラン。 経験値だけなら、先方の部長クラスに近い。 障害対応。 深夜対応。 性能改善。 運用保守。 現場を知り尽くした人だった。 でも、その人も私と同じプレミアムエコノミー。 そこで、なんとも言えない感情が生まれた。 「飛行機のランクって、個人じゃなくて“企業”で決まるんだ」 モノづくりって、もっと強いと思っていた 私は昔から、システムを作れる人は格好いいと思っていた。 巨大システムを動かす。 社会インフラを支える。 金融を止めない。 そんな技術者に、強い憧れがあった。 だから、どこかで思っていた。 “作れる側”は強い、と。 でも現実は少し違った。 お客様側の方が、立場が上に見える。 待遇も違う。 移動も違う。 給料も、たぶん違う。 もちろん、それは契約構造や責任範囲の違いでもある。 発注側と受託側で...
コメントを投稿
続きを読む