Digital Heroes: Guide to IT World

グローバルシステムプロジェクトで知った、「システム通訳」というもう一つの専門性 「えっ、システムのことを英語で話せるのに、通訳はできないの？」 グローバルプロジェクトにシステム担当として入っていた頃、私は何度もこの壁にぶつかった。 私は、それまでシステムのことを勉強してきた。 グローバルプロジェクトにも入り、システムについて議論する。英語も、それなりにはできた。当時のTOEICは790点。 だから、当然こう思う。 「システムのことを英語で話せる。だったら、通訳もできるだろう」 ところが、実際にやってみると……。 いや、これはきつい。 「話せる」と「通訳できる」は違う 自分の考えを英語で話す。 これは、なんとかなる。 相手の話している内容も、7割、8割くらいなら追いついていける。 システムの話なら、専門用語そのものが英語になっていることも多い。 System Architecture、Application、Database、Interface、Integration、Cloud…… むしろ、システム用語が共通言語になっているので、普通にコミュニケーションできる。 システム議論も、なんとかできる。 「じゃあ、通訳をお願いします」 そう言われる。 ここからが別世界だった。 通訳は「自分が話す」のとは違う まず、日本人が話している内容を理解しなければならない。 その内容を頭の中で整理する。 そして英語にする。 次に、相手が英語で話す。 それを理解する。 そして、日本語に戻す。 つまり、自分の意見を話すときとは違って、 二人分の思考を処理しなければならない。 しかも、自分が話している時間が長くなる。 すると、すぐにプレッシャーがかかる。 「早く訳してください」 いやいやいや。 結構むずいよ、これ。 専門知識があるからといって、全部を一瞬で理解できるわけではない。 「今のところ、もう一度お願いします」 そう聞き返す。 すると、またプレッシャーがかかる。 「これを同時通訳している人がいるの？」 正直、最初はそう思った。 「いや、無理だよ。意味を理解している暇なんてないじゃないか」 それでも、何度もやる。 聞いて、理解して、整理して、訳す。 そして、また聞く。 その苦しさが、英語を鍛えていった 不思議なのは、そんな経験を繰り返しているうちに、少しずつ英語が鍛えられていったことだ。...

「えっ、この人、何者なんだ？」 今回、あるイギリスのシステムを日本に適用するプロジェクトに参加しました。 日本側の中心メンバーは2人。 一人は、英語がペラペラの日本人エンジニア。 もう一人は、日本語が少しできるイギリス人エンジニアです。 最初は「技術面でサポートしてくれる人」というくらいに思っていました。 ところが、話をしているうちに、だんだん違和感が出てきました。 日本のビジネス専門家が、その人に直接問い合わせる。 システム担当者が質問すると、「では、このスクリプトを実行しましょう」と、その場で対応する。 さらに、データベースの構造を説明し、ネットワークについても教えてくれる。 「なんなんだ、この人は？」 システムだけではありません。 ビジネスのことも分かる。 英語も分かる。 日本側の事情も分かる。 データベースもネットワークも分かる。 しかも、年収を聞けば1,000万円を超えてくる。 これは確かに、フルスタックを超えている。 でも、本人の言葉は意外だった 「すごいですね。何でもできますね」 そう話しかけると、彼は少し笑って答えました。 「いや、何でも屋なんで。結構つらいですよ」 その言葉が、妙に印象に残りました。 実際、その仕事は簡単ではありません。 突然、イギリスから指示が飛んでくる。 「日本のシステムを、この仕様に変更してください」 ところが、ビジネス側から質問を受けてイギリスに投げても、すぐには答えが返ってこない。 当然です。 日本とイギリスには時差があります。 日本の夕方になると、イギリス側との仕事が本格的に始まる。 夕方から夜まで会議。 そして、日本側では朝から別の会議。 さらに、単純な通訳だけでは終わりません。 ビジネスの意図を理解し、それをシステムの言葉に変換する。 イギリス側の技術的な説明を、日本の現場が理解できる形に戻す。 必要なら自分で検討し、スクリプトを実行し、データベースやネットワークまで確認する。 「システム、ビジネス、検討、実践、通訳。何でも屋ですよ」 そう吐露してくれました。 「何でもできる」は、実は大変だ その姿を見て、私は思いました。 できる人ほど、仕事の境界線を越えてしまう。 「私はシステム担当なので、そこは分かりません」 そう言えば、仕事は楽になるかもしれません。 でも、目の前の問題を解決しようとすると、そうはいかない。 ビ...

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