Digital Heroes: Guide to IT World

Wait… a system isn’t finished just because you’ve completed the system itself? Some time ago, I was involved in a project to implement a financial system from London. At the time, my first question was, “How can we make this core financial system work in Japan?” Since it was a system being introduced from overseas, naturally, some adjustments were necessary to accommodate Japanese business processes. But the basic approach was simple. Configure the core system as much as possible. Only develop the parts that could not be handled through configuration. And rather than developing everything in Japan, we would basically ask the London team to handle the required development. From there, the development would be carried out at the appropriate location. “I think we can make this work.” I remember thinking that. But then came the next challenge: the surrounding systems. ▼開発会社選びに悩んでいる方はこちら   When the Core System Changes, Everything Around It Changes Once the new financial syste...

えっ、システムって一つ完成させれば終わりじゃないの？ 以前、私はロンドンから金融システムを導入するプロジェクトに関わっていました。 当時の私は、まず「メインとなる金融システムを日本でどう動かすか」を考えていました。 海外から導入するシステムですから、当然、日本の業務に合わせた調整が必要です。 ただ、基本的な考え方はシンプルでした。 メインシステムは、できるだけ設定で変更する。 どうしても設定では対応できない部分だけ開発する。 そして、その開発については日本で全部作るのではなく、基本的にはロンドン側へ依頼する。そこから必要な開発が、しかるべき場所で行われていく。 「これなら、なんとか進められそうだ」 そう思ったのを覚えています。 ところが、次に待っていたのが「周辺システム」でした。 ▼開発会社選びに悩んでいる方はこちら   メインシステムが来ると、周りも変わる 新しい金融システムが入る。 すると、当然ながら、そのシステムとつながっている周辺システムも変えなければなりません。 データ項目が変わる。 インターフェースが変わる。 送信する形式が変わる。 受け取る側も、それに合わせて改修する。 一つずつ確認し、一つずつ接続していく。 すると、少しずつ社内システム全体の姿が見えてきました。 「よし。社内はなんとか目途が立ってきた」 そう思った瞬間、次の課題が出てきました。 今度は、 別の会社のシステムです。 金融システムは「会社の中」だけでは完成しない 金融の世界では、一つの会社のシステムだけですべての業務を完結できません。 注文が入る。 確認する。 承認する。 支払う。 記帳する。 そして、その情報を別のシステムや企業へ連携する。 つまり、一つの取引を成立させるために、多くの企業、多くのシステムがつながっています。 ここで重要になるのが、「どうつなぐか」です。 どのプロキシーを使うのか。 どのデータフォーマットで送るのか。 どのくらいの頻度で送信するのか。 システムはこちらから接続しに行くのか。 それとも相手に接続してもらうのか。 さらに、接続に料金は発生するのか。 こうしたことを一つずつ決め、相手企業に通知しなければなりません。 そして、通知して終わりではありません。 「この項目は何ですか？」 「この形式には対応できますか？」 「テスト環境はどうしますか？」 次々と...

「すみません。これ、いつ直りますか？」 その質問を受けるたびに、私は答えに困っていました。 なぜなら、私自身も分からなかったからです。 開発会社に聞いても、 「確認します」 「担当に確認中です」 「もう少しお時間ください」 そんな回答ばかり。 でも、社内からは毎日のように聞かれます。 「進んでますか？」 「いつリリースできますか？」 「この問題、まだ直らないんですか？」 私はDX担当者。 プロジェクトの責任者です。 でも、自分でプログラムを書いて直すことはできない。 だから、開発会社に頼るしかありません。 そして、その開発会社が動いてくれない。 これが、私が外注開発で経験した、かなり苦しい時期でした。 ▼開発会社選びに悩んでいる方はこちら   最初は、こんなことになるとは思っていなかった もちろん、最初から怪しい会社を選んだつもりはありません。 提案書はきれいでした。 営業担当者も優秀でした。 「この領域は経験があります」 「お客様の要望に柔軟に対応できます」 「経験豊富なエンジニアをアサインします」 こちらも安心します。 「これなら大丈夫だろう」 そう思って契約する。 ところが、プロジェクトが始まってみると、少しずつ違和感が出てきました。 「それ、営業から聞いてません」 最初に出てきたのが、これでした。 こちらが契約前の打ち合わせで話した内容について確認すると、 「その件は聞いていません」 と言われる。 「いや、営業の方と話しているんですが……」 「営業と現場で認識が違うかもしれません」 ……。 この瞬間、本当に嫌な予感がします。 その後、 「それは追加開発です」 「そこまでの対応は含まれていません」 「仕様変更になります」 という話が増えていきました。 契約前には、 「できます」 と言っていたことが、 契約後には、 「条件によります」 に変わっていく。 そして最終的には、 「それは難しいです」 になる。 この変化を何度経験したか分かりません。 そして、問題が起きる システム開発で一番怖いのは、問題が起きることではありません。 問題が起きたときに、 誰も責任を持って前に進めてくれないこと です。 ある時、システムで問題が発生しました。 当然、私は開発会社に連絡します。 「原因を調べてください」 「いつまでに対応できますか？」 すると、 「まず調査します」 ...

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

ロンドンから届いた“完成品”を前に、初めて見えたプロジェクトの景色 「えっ、こんなに静かでいいの!?」 システム開発プロジェクトの真っ只中にいるはずなのに、目の前には意外なほど静かな現場が広がっていた。 これまで私は、どちらかというと「システムを作る側」のプロジェクトを数多く経験してきた。 要件を整理し、設計し、開発し、テストする。 プロジェクトのピークになれば、開発者が100人を超えることもある。問い合わせが飛び交い、課題が積み上がり、会議が増え、資料が増え、気がつけば机の上までカオスになる。 「システムを作っているのか、机を整理しているのか分からない」 そんな状態で一日が終わることも、珍しくなかった。 ところが今回、ロンドンから導入するシステムプロジェクトでは、その景色がまったく違った。 ▼開発会社選びに悩んでいる方はこちら   開発しないプロジェクトに入ってみる 今回のシステムは、すでにロンドン側で開発が進められ、完成したものを日本側へ導入していく。 つまり、私は開発そのものの中にはいない。 これは、私にとって意外と大きな経験だった。 プロジェクトのピークに入っても、人が爆発的に増えるわけではない。 みんな淡々と、自分の担当するテストや準備を進めている。 ロンドンから、開発を終えたシステムが少しずつ届く。 そして、日本側の周辺システムも少しずつ出来上がっていく。 単体テストは終わっている。 システムテストも終わっている。 そして今、最後の大きな山である「システム統合テスト」に、みんなで取り掛かろうとしている。 そこで、ふと思った。 「そうか。システムプロジェクトって、開発が終わってからも、こんなに長いんだ。」 完成したはずなのに、動かない 実際、開発が終わったシステムをテストしてみると、いろいろなことが起こる。 想定した通りに動かない。 データがうまく連携されない。 画面の表示がおかしい。 別のシステムとつなぐと、思わぬ問題が出てくる。 一つ直すと、別の場所で影響が出る。 だから、開発が終わったからといって、すぐに本番を迎えられるわけではない。 そこから約3カ月、しっかりとテストを行う。 そしてテストが終われば、今度は移行計画。 さらに約3カ月をかけて、何度もシミュレーションやリハーサルを行う。 関係者へのアナウンス。 システム説明。 関係会社との接続...

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

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

What I Learned from a Global Systems Project About Another Kind of Expertise: “Systems Interpretation” “Wait, if you can talk about systems in English, why can’t you interpret?” When I was working as a systems specialist on a global project, I ran into this wall many times. I had spent years studying systems. I joined global projects and discussed systems with people from around the world. My English was decent, too. At the time, my TOEIC score was 790. So naturally, I thought: “I can talk about systems in English. Then I should be able to interpret, too.” But when I actually tried it… No. This is tough. “Speaking” and “Interpreting” Are Different Speaking about my own ideas in English? I could manage that. I could also follow about 70 or 80 percent of what the other person was saying. When it comes to systems, many technical terms are already in English. System Architecture, Application, Database, Interface, Integration, Cloud… In fact, because system terminology itself becomes a comm...

グローバルシステムプロジェクトで知った、「システム通訳」というもう一つの専門性 「えっ、システムのことを英語で話せるのに、通訳はできないの？」 グローバルプロジェクトにシステム担当として入っていた頃、私は何度もこの壁にぶつかった。 私は、それまでシステムのことを勉強してきた。 グローバルプロジェクトにも入り、システムについて議論する。英語も、それなりにはできた。当時のTOEICは790点。 だから、当然こう思う。 「システムのことを英語で話せる。だったら、通訳もできるだろう」 ところが、実際にやってみると……。 いや、これはきつい。 「話せる」と「通訳できる」は違う 自分の考えを英語で話す。 これは、なんとかなる。 相手の話している内容も、7割、8割くらいなら追いついていける。 システムの話なら、専門用語そのものが英語になっていることも多い。 System Architecture、Application、Database、Interface、Integration、Cloud…… むしろ、システム用語が共通言語になっているので、普通にコミュニケーションできる。 システム議論も、なんとかできる。 「じゃあ、通訳をお願いします」 そう言われる。 ここからが別世界だった。 通訳は「自分が話す」のとは違う まず、日本人が話している内容を理解しなければならない。 その内容を頭の中で整理する。 そして英語にする。 次に、相手が英語で話す。 それを理解する。 そして、日本語に戻す。 つまり、自分の意見を話すときとは違って、 二人分の思考を処理しなければならない。 しかも、自分が話している時間が長くなる。 すると、すぐにプレッシャーがかかる。 「早く訳してください」 いやいやいや。 結構むずいよ、これ。 専門知識があるからといって、全部を一瞬で理解できるわけではない。 「今のところ、もう一度お願いします」 そう聞き返す。 すると、またプレッシャーがかかる。 「これを同時通訳している人がいるの？」 正直、最初はそう思った。 「いや、無理だよ。意味を理解している暇なんてないじゃないか」 それでも、何度もやる。 聞いて、理解して、整理して、訳す。 そして、また聞く。 その苦しさが、英語を鍛えていった 不思議なのは、そんな経験を繰り返しているうちに、少しずつ英語が鍛えられていったことだ。...

システムを作る側から、システムを「つなぐ側」へ 「えっ、今回はアプリを作らないの？」 今回のシステム開発プロジェクトが始まったとき、少し意外な展開になった。 実は、今回のシステム開発では、自分の部署はそれほど出番がなかった。 というのも、今回導入するシステムは、すでに完成している。ゼロからアプリケーションを開発するのではなく、完成したシステムを日本のビジネス環境に合わせて導入していくプロジェクトだった。 もちろん、話はそんなに簡単ではない。 新しいシステムが突然やってくれば、それまで使っていた周辺システムとの間に「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万円。 年齢を考えれば、...

システムを入れるだけなら、仕様書なんて読めば終わり！……本当にそうでしょうか？      ロンドン出張から帰ってきた。 目的は、イギリスで使われているシステムを日本に導入することだった。 「イギリスのシステムなら、まず仕様書を読めばいい」 最初は、そんなふうに考えていた。 システム要件を理解して、機能を確認して、日本に実装する。 ところが、実際に要件を読み始めると、すぐに壁にぶつかった。 「これ、日本ではそのまま使えない……」 システムは、その国のビジネスを映している 理由はシンプルだった。 システムの前提になっているビジネスルールそのものが、日本とイギリスでは違う。 特に証券業界は、さまざまなルールが多段構造になっている。 まず金融庁や取引所がルールを決める。 そのルールを、大手の銀行や証券会社が自社の業務に落とし込む。 さらに中小の証券会社が、そのルールに対応する。 そして最終的には、顧客にまでルールが配分されていく。 つまり、システムだけを見ても全体像は分からない。 その背景にある「ビジネスの仕組み」を理解しなければ、システムを日本に持ってくることはできないのだ。 イギリスのルールを、日本のルールに翻訳する そこで重要になったのが、単純なシステム導入ではなかった。 イギリスから入ってきたビジネスルール。 それを日本の業務ルールに合わせていく。 そして、その日本の業務を支える形にシステムを実装していく。 つまり、 イギリスのBusiness → 日本のBusiness → 日本のSystem という変換が必要だった。 ロンドンに行ったからといって、システムの導入方法が分かるわけではない。 仕様書を読んだからといって、日本でどう使うかが分かるわけでもない。 そこで、ロンドンのシステムを日本に導入するための「橋渡し役」が必要になる。 そこで出会った、すごい人たち プロジェクト期間中、ロンドンから日本に滞在して支援する人がいた。 一方、日本側にも、英語ができて、システムも分かる人が雇われていた。 彼らの仕事は、単なるシステム担当ではない。 イギリス側の業務内容を理解する。 システムの構造を理解する。 日本側の業務を理解する。 そして、それぞれの違いを言語化して、両者をつなぐ。 英語も、日本語も、業務も、システムも分かる。 私は、その姿を見て...

If all you have to do is implement a system, then just read the specifications and you're done! …Really? I had just returned from a business trip to London. The purpose of the trip was to introduce a system used in the UK into Japan. At first, I thought: “If it’s a UK system, all we need to do is read the specifications.” Understand the system requirements. Check the functions. Then implement them in Japan. Simple enough. But as soon as I actually started reading the requirements, I ran into a wall. “This simply won’t work as it is in Japan…” A System Reflects the Business of Its Country The reason was simple. The business rules underlying the system itself were different between Japan and the UK. The securities industry, in particular, has a complex, multi-layered structure of rules. First, regulatory authorities and exchanges establish the rules. Large banks and securities firms then translate those rules into their own business processes. Smaller securities firms follow and supp...