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

ロンドンから届いた“完成品”を前に、初めて見えたプロジェクトの景色 「えっ、こんなに静かでいいの!?」 システム開発プロジェクトの真っ只中にいるはずなのに、目の前には意外なほど静かな現場が広がっていた。 これまで私は、どちらかというと「システムを作る側」のプロジェクトを数多く経験してきた。 要件を整理し、設計し、開発し、テストする。 プロジェクトのピークになれば、開発者が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一枚 に収...