Digital Heroes: Guide to IT World

えっ、私が「発注する側」に行くの？ 入社8年目。 それまでの私は、ひたすらシステム構築をやってきた。 要件を聞き、設計して、開発して、テストして、リリースする。 一つのプロジェクトが終われば、また次のプロジェクトへ。 そんな仕事を繰り返していた。 ▼開発会社選びに悩んでいる方はこちら   ある日、突然「お客様側」へ 当時、私はある会社から発注を受ける立場で仕事をしていた。 周囲を見ていると、発注しているベンダー側に出向している人が何人かいる。 「へえ、そういう働き方もあるんだな」 そんな程度に思っていた。 ところが、ある日。 「山口さんにも、出向の話があります」 ドキッとした。 ついに自分にも来たか。 でも、話を聞いてみると、これまで見ていた出向とは少し違う。 私は、 お客様側に出向する というのだ。 「お客様側？」 「発注する側？」 「システムを企画する側？」 頭の中に「？」がいくつも浮かんだ。 今までとは、明らかに立ち位置が違う。 「作る」から「会社全体を見る」へ 幸い、そのポジションには前任者がいた。 だから私は、まず前任者の話を聞くことにした。 そこで分かってきたのが、IT企画部の仕事だった。 システムを作ることだけが仕事ではない。 会社全体のITが今どうなっているのか。 どんなシステムが存在しているのか。 どんなリスクを抱えているのか。 これから何を変えていく必要があるのか。 つまり、個別のシステムを見るのではなく、 会社全体のITを俯瞰して考える仕事 だった。 既に大きなプロジェクトは終わっていた。 だから、これからは管理が中心。 そして、次のプロジェクトの計画も始めなければならない。 「なるほど……。これまでとは全然違うな」 少しずつ、仕事の輪郭が見えてきた。 「2年間」という長さに驚いた そして、この出向には一つのルールがあった。 前任者も2年間。 そして、私も2年間。 泣いても笑っても、2年間で終わり。 「2年間か……」 正直、ちょっと長い気がした。 それまで私が関わってきたプロジェクトは、3カ月から1年程度。 短いプロジェクトをいくつも動かしてきた私にとって、同じ場所で2年間というのは、なんだか奇妙だった。 でも、よく考えてみると、やることはいっぱいありそうだった。 会社全体のITを理解する。 リスクを把握する。 ベンダーと調整する。 経...

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

金融システムを構築した、その次は ロンドンのシステムを日本へ 当時、私はロンドンの会社が開発した金融システムを、日本に導入するプロジェクトに入っていた。 私の立場は、アプリケーション管理。 システム全体のアプリケーションについて、ロンドン側の担当者と連携しながら、日本での導入を支えていく仕事だった。 アプリケーションそのものは、ロンドンの会社のシステム担当者が中心となって進めていく。 私は、日本側で必要となる調整や確認を行い、テストの最終段階までプロジェクトに付き合った。 そして、いよいよ本番運用が見えてきた。 オペレーションの担当者が実際に使えるように、業務の流れを確認し、運用面もサポートする。 「もうすぐ、このプロジェクトも終わるな」 3月。 そんなことを考え始めていた。 ▼開発会社選びに悩んでいる方はこちら   「次のプロジェクトだ」 そんなタイミングで、声がかかった。 「次のプロジェクトだよ」 私は、当然こう思った。 「次もシステム開発プロジェクトかな？」 ところが、話を聞いてみると違った。 「次は、顧客先への出向」 ……うん？ 出向って、何だ？ システム開発プロジェクトではないのか？ さらに聞いてみる。 「IT企画部門に行ってもらう」 そこで、少し驚いた。 私は、それまでアプリケーションの設計やシステム導入には関わってきた。 プロジェクトの計画を作った経験もある。 しかし、「会社全体のITをどうしていくのか」という企画は初めてだった。 これは、面白い！ でも、考えてみると、とても面白い仕事だった。 これまでは、一つのシステムをどう作るかを考えていた。 今度は違う。 会社全体のシステムを、どうしていくのか。 どんなシステムが必要なのか。 何を残して、何を変えるのか。 どのタイミングで投資するのか。 それを企業レベルでプランニングする。 「プロジェクトのプランニングなら、ある程度やってきた」 正直、基盤側については、まだまだ自信がなかった。 それでも、プロジェクト全体の計画を書き、関係者を整理し、システム導入を前に進めてきた経験はある。 それが、企業全体のIT計画になる。 「かなり面白いじゃないか」 そんな仕事があること自体、当時の私には新鮮だった。 しかも、選ばれたのは一人 さらに驚いた。 会社から選ばれるのは、一人。 その一人として、自分が行くこと...

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

システムは、一人では動かない。 一つひとつのサーバには「役割」がある 以前、私は金融システムの開発サポートに携わり、ロンドンで使われていたシステムを日本へ導入するプロジェクトをサポートしていました。 そこで強く感じたことがあります。 それは、 「システムを連携すること」と「みんなで協力すること」は、本質的には同じなのではないか ということです。 ▼開発会社選びに悩んでいる方はこちら   ロンドンのシステムは、一つの巨大なプログラムだけでできているわけではありませんでした。 多くのサーバを組み合わせ、それぞれが異なる役割を持っています。 あるサーバはデータを受け取り、別のサーバはそのデータを処理する。そして、処理された結果をさらに別のサーバへ渡していく。 一つひとつのサーバは、自分の役割を果たしているだけです。 しかし、それだけでは一つのシステムにはなりません。 それぞれが決められたルールに従い、正しくつながることで、初めて全体が一つの金融システムとして動き始めます。 「つながっている」だけでは、動かない ここで難しいのが、単純にシステム同士をつなげればいいわけではないことです。 どのデータを渡すのか。 いつ渡すのか。 どのような形式で渡すのか。 エラーが発生した場合はどうするのか。 どちらのシステムが正しいデータを持つのか。 それぞれにルールがあります。 そのルールが一つでも合わなければ、データは正しく連携できません。 そして、データがうまく連携できなければ、個々のシステムが正常に動いていても、全体としては一つのシステムとして機能しない。 ここが、システム連携の難しいところです。 金融システムだけを見ても、多くのサーバが連携しています。 そして、本当の難しさは、その外側にあります。 社内だけでは、金融システムは完成しない 金融システムは、そのシステムだけで完結するものではありません。 社内のWebシステム、通知システム、決済システムなど、周囲にあるさまざまなシステムとも連携しなければなりません。 さらに、その先には社外のシステムがあります。 ここが、さらに難しい。 社外のシステムは、自分たちが管理しているわけではありません。 それぞれ別の会社が管理し、それぞれの事情やルールがあります。 そのため、自分たちのシステムを変更するだけでは解決できないこともありま...

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