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

投稿

ブログを翻訳

“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 system was introduced, the sys...
最近の投稿

「システムは、つながって初めてビジネスになる」 ――ロンドンから届いた金融システムが教えてくれたこと

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

「もう、誰でもいいから動いてくれ!」――外注開発で本当に追い込まれたDX担当者の話

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

The Longest Part of a System Project Comes After It’s Finished!

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カ月をかけて、何度もシミュレーションやリハーサルを行う。 関係者へのアナウンス。 システム説明。 関係会社との接続テスト。 そして、さまざまな確認を一つずつ積み重ね...

Wait, are we really going to run a system in Japan that was developed by a team that isn’t even in Japan?

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人の担当者に問い合わせます。 「この機能はどういう仕様ですか?」 「このデータは、どういう条件で処理されますか?」 「このエラーは何が原因ですか?」 質問は一覧表に書いていきます。 すると、日本側の担当者が内容を確認し、答えられるものは、その場で回答してくれます。 しかし、当然ながら、すべてを知っているわけではありません。 そこで登場するのがロンドンです。 分からなければ、ロンドンに聞く 日本側の担当者でも分からない。 そんな質問は、ロンドンのチームへ問い合わせます。 「この仕様について確認してください」 「この動きは想定されたものですか?」 そして、しばらくするとロンドンから回答が返ってきます。 その回答を日本側の担当者が整理し、最初に質問した人へ返していく。 今振り返ると、とてもシンプルな仕組みです。 質問する人 → 日本側の担当者 → ロンドン → 日本側の担当者 → 質問した人 まさに、人を介したグローバル開発でした。 そして、時々ロンドンから人がやってくる もちろん、メールや電話だけですべてが解決するわけではありません。 重要な局面になると、ロンドンから何人かが日本へ出張してきます。 直接顔を合わせて、仕様を確認する。 画面を見ながら議論する。 日本側の業務を理解してもらう。 そして、基本的には日本のことは日本側で対応しながら、必要なところだけロンドンの力を借りていく。 なお、ロンドンのシステムが、さらにインドやポーランドなど別の拠点へ発注されていた可能性もあります。そこは当時の私には分かりません。 でも、重要なのは「どこで誰が作っているか」だけではありません。 どうやって世界中の知識をつなぎ、日本で使える形にするか。 そこだったのです。 グローバル開発は、場...