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

投稿

ラベル(グローバルIT)が付いた投稿を表示しています

ブログを翻訳

ロンドン帰りの私が見た、「フルスタックを超える人」

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

「システムは納品物じゃない」──ロンドンで見た、“育てて世界へ売る”という発想

「完成」がゴールだと思っていた うわっ!金融システムが“生き物”みたいに成長していた。 私はこれまで、約8年間システム作りに関わってきた。 設計し、開発し、テストし、納品する。 そういう世界で仕事をしてきた。 もちろん、その中で改善提案もしてきた。 しかし、どこかで「システムは作って終わり」という感覚があった。 そんな中、あるプロジェクトに参加することになった。 お客様が、ロンドンから金融系システムを日本へ持ってくるプロジェクトだった。 ロンドンで見た“異様な光景” 私はアプリケーション観点でシステムを理解する担当として、2週間ロンドン研修に参加した。 そこで見たものが衝撃だった。 そのシステムを所有していたのは、システムベンダーではない。 ロンドンの金融会社だった。 つまり、金融会社自身が金融基幹システムを作り、それを自社資産として海外へ販売していたのである。 しかも、それを買ったのは日本の金融会社。 私は驚いた。 日本では、 「金融会社が使うシステムをITベンダーが作る」 という構造が当たり前だった。 しかしロンドンでは違った。 「金融会社が、自分たちで磨き上げたシステムを商品として売る」 なのである。 しかも、国内マーケットだけではない。 海外の金融機関へ販売していた。 システムそのものが、国境を越えるビジネスになっていた。 運用担当者が9画面を操っていた さらに驚いたのは運用現場だった。 運用担当者は、9つのスクリーンを同時に使いこなしていた。 こちらが、 「こういう機能はあるんですか?」 と聞く。 すると返ってきたのは、 「それは現在開発中だ」 という言葉だった。 私はそこで初めて気づいた。 この人たちは、“完成品”を運用しているのではない。 “成長途中のシステム”を運用しているのだ。 そして、現場の知見をもとに、継続的に改善し続けていた。 最初から完璧を目指していた自分 一方、当時の私は違った。 最初の開発で、完璧なシステムを作ろうとしていた。 でも実際には、 要件は曖昧なことも多い。 お客様自身も、 「本当に欲しいもの」 を言語化できていないこともある。 そして何より、自分自身の知識もまだ中途半端だった。 しかし不思議なことに、システムを作り終える頃には、かな...

“英語”より怖かったのは、“世界標準の設計思想”だった——入社8年目、ロンドン研修で崩れた自信

“システムを作れる”と思っていた うわっ!飛行機の羽が、やけに軽く見えた。 羽田空港からロンドンへ向かうANA便。 人生初の「海外システム研修」が始まろうとしていた。 入社8年目。 それなりにシステム開発の経験も積み、既に社会で動いているシステムにも関わってきた。 しかも、ただの開発担当ではない。 マネジメント側として、プロジェクト全体を見ながら進める立場にもなっていた。 「システムはこう作るものだ」 そんな感覚も、少しずつ持ち始めていた時期だった。 もちろん、私はJavaのプロフェッショナルではない。 コードを極めるタイプではなく、どちらかと言えば“全体構造”や“業務とITの接続”で戦うタイプ。 自分の戦う領域も、少しずつ理解し始めていた。 だから今回のロンドン出張も、ある意味では「確認作業」だと思っていた。 アプリケーション観点でシステムを評価し、理解し、日本側に持ち帰る。 やるべきことは分かっている。 ……そう思っていた。 “海外システム”は、空気そのものが違った 事前に送られてきたドキュメントも読んでいた。 英語自体は、なんとか理解できる。 技術用語も、そこまで問題ではない。 でも、違和感があった。 自分たちが日本で作ってきたシステムマニュアルと、雰囲気が違う。 日本の資料は、「開発した人」が説明している感じが強い。 一方で、ロンドン側の資料は、“製品”として整理されていた。 どちらかと言えば、パッケージソフトの説明書に近い。 「誰が作ったか」ではなく、 「どう使うか」が中心。 この時点で、私はまだ本当の意味を理解していなかった。 プレミアムエコノミーで感じた“境界線” お客様は別便だった。 私たちはANAのプレミアムエコノミー。 私はその時まで、「エコノミーにプレミアムなんてあるのか」と本気で思っていた。 少し広い座席。 少し前方の席。 それだけなのに、不思議と気持ちが高揚する。 「ああ、自分は今、国際案件に向かっているんだ」 そんな感覚があった。 海外旅行自体は慣れていた。 でも、観光ではない。 “ビジネストリップ”には独特の緊張感がある。 空港ラウンジ。 英語のアナウンス。 ノートPCを開く周囲のビジネスマン。 その空気の中で、自分も“グローバルIT”の入口に立って...

「あれ?システム担当、全員カタコト!?」──外国人だらけの窓口から見えた新時代

ServiceNowが変えた問合せの現場。世界をまたぐチケット管理と、そこに立つ人たちの物語。 うわっ、全員カタコト!? 先日、社内のシステム窓口に問い合わせたら、返ってきた第一声が流暢な英語。 「あれ?ここ日本だよね…?」 気がつくと、窓口のスタッフはほぼ外国人。インド、中国、フィリピン…世界中のアクセントが飛び交う、まるで国際空港のような雰囲気になっていました。 システム屋に合う人って? システム屋として働く中で、相性がいいのは 論理的で粘り強い人 。 「なぜ?」を3回は聞くし、ちょっとやそっとのトラブルじゃ動じません。 そんな人たちが今、 窓口担当 として活躍しています。 ServiceNowがやってきた 最近、多くの会社で導入されているのが「ServiceNow」というシステム。 もともとは環境や構成管理のためのプラットフォームでしたが、今では 問合せをチケットとして管理する機能 が大きく広がっています。 これにより、ただの「ちょっと質問なんですけど…」が、正式なチケットとして記録され、分析まで可能になりました。 チケット管理の威力 以前は「システム担当に直接聞く」が当たり前。 でも、急に話しかけられると、自分の担当じゃないことも多いし、担当だったとしても「いつ答えたか」なんて覚えていられません。 ServiceNowのチケット管理なら、 担当振り分け、進捗把握、履歴の検索 まで一元化。 時間を奪われる雑談的な質問から、エンジニアを解放してくれる救世主です。 なぜ外国人が多いのか? このチケット管理は グローバル対応 が前提。 インドや中国にあるシステムチームに依頼を投げるのもワンクリック。 そのため、窓口担当は日本語と英語の両方を使いこなせなければなりません。 実際、英語中心で業務が回るため、「日本語が少し不自由でも問題なし」というケースが多く、結果として外国人比率がぐんと上がっています。 でも、日本人もできる! 正直、日本人でも十分できる仕事です。 必要なのは、 英語の読み書きと最低限の会話力 。 それさえあれば、時差も文化も超えて仕事ができる。 「私には無理」と思う人が多いけれど、そんなことはありません。     明日から踏み出す ITの現場は、ますます国際色豊か...