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

投稿

ブログを翻訳

Wait—my next job wasn’t about “building systems.” It was about “designing the company itself”!

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計画になる。 「かなり面白いじゃないか」 そんな仕事があること自体、当時の私には新鮮だった。 しかも、選ばれたのは一人 さらに驚いた。 会社から選ばれるのは、一人。 その一人として、自分が行くこと...

“Wait, it’s connected that far?” — Behind a financial system was a massive team effort.

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システム、通知システム、決済システムなど、周囲にあるさまざまなシステムとも連携しなければなりません。 さらに、その先には社外のシステムがあります。 ここが、さらに難しい。 社外のシステムは、自分たちが管理しているわけではありません。 それぞれ別の会社が管理し、それぞれの事情やルールがあります。 そのため、自分たちのシステムを変更するだけでは解決できないこともありま...

“A Business Only Comes to Life When Systems Connect” —What a Financial System from London Taught Me

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担当者の話

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