Digital Heroes: Guide to IT World

ロンドンから届いた“完成品”を前に、初めて見えたプロジェクトの景色 「えっ、こんなに静かでいいの!?」 システム開発プロジェクトの真っ只中にいるはずなのに、目の前には意外なほど静かな現場が広がっていた。 これまで私は、どちらかというと「システムを作る側」のプロジェクトを数多く経験してきた。 要件を整理し、設計し、開発し、テストする。 プロジェクトのピークになれば、開発者が100人を超えることもある。問い合わせが飛び交い、課題が積み上がり、会議が増え、資料が増え、気がつけば机の上までカオスになる。 「システムを作っているのか、机を整理しているのか分からない」 そんな状態で一日が終わることも、珍しくなかった。 ところが今回、ロンドンから導入するシステムプロジェクトでは、その景色がまったく違った。 開発しないプロジェクトに入ってみる 今回のシステムは、すでにロンドン側で開発が進められ、完成したものを日本側へ導入していく。 つまり、私は開発そのものの中にはいない。 これは、私にとって意外と大きな経験だった。 プロジェクトのピークに入っても、人が爆発的に増えるわけではない。 みんな淡々と、自分の担当するテストや準備を進めている。 ロンドンから、開発を終えたシステムが少しずつ届く。 そして、日本側の周辺システムも少しずつ出来上がっていく。 単体テストは終わっている。 システムテストも終わっている。 そして今、最後の大きな山である「システム統合テスト」に、みんなで取り掛かろうとしている。 そこで、ふと思った。 「そうか。システムプロジェクトって、開発が終わってからも、こんなに長いんだ。」 完成したはずなのに、動かない 実際、開発が終わったシステムをテストしてみると、いろいろなことが起こる。 想定した通りに動かない。 データがうまく連携されない。 画面の表示がおかしい。 別のシステムとつなぐと、思わぬ問題が出てくる。 一つ直すと、別の場所で影響が出る。 だから、開発が終わったからといって、すぐに本番を迎えられるわけではない。 そこから約3カ月、しっかりとテストを行う。 そしてテストが終われば、今度は移行計画。 さらに約3カ月をかけて、何度もシミュレーションやリハーサルを行う。 関係者へのアナウンス。 システム説明。 関係会社との接続テスト。 そして、さまざまな確認を一つずつ積み重ね...

ロンドンのシステムを追いかけて、見つけた「地図」 「うわっ、システム構成図って、こんなに面白いのか！」 そう思った瞬間のことを、今でも覚えている。 当時、私はロンドンで開発されたシステムを日本へ導入していくプロジェクトに参加していた。 私のメインタスクは、先方から渡される大量のドキュメントを、英語から日本語へ翻訳すること。 もちろん、単なる翻訳作業ではない。 システムのことも理解しながら翻訳する必要がある。 だから、英語のドキュメントを読み進めるほど、「最先端のシステムの中に入り込んでいく」ような感覚があった。 翻訳しているのに、金融ビジネスまで見えてくる 面白かったのは、システムドキュメントだけではなかった。 プロジェクトでは、ビジネスに関するドキュメントも非常に多かった。 そこで私は、システムだけではなく、金融ビジネスについても勉強するようになった。 日本の金融ビジネスについても調べた。 それまでに取得していたいくつかの資格の知識も、思いがけず役に立った。 「なるほど。この業務があるから、このシステムが必要なのか」 そうやって、業務とシステムが少しずつつながっていった。 翻訳しているはずなのに、気づけば金融の仕組みを勉強している。 そして、その金融ビジネスを支えるシステムの構造まで見えてくる。 これは、とても贅沢な勉強の時間だった。 コード、サーバ、そして増えていく役割 システムドキュメントを読み込んでいくと、コードもいくつか出てくる。 サーバ構成も書かれている。 最初は、 「こんなにサーバがあるのか？」 と思った。 でも、よく見てみると、それぞれ役割が違う。 ログを扱うサーバ。 バッチ処理を行うサーバ。 それぞれの機能を担当するサーバ。 そこで、ふと気づいた。 「なるほど。ものすごく高機能な一つのアプリケーションを作っているというより、少しずつ役割を持った多くのシステムを組み合わせているんだ」 一つひとつの役割を持ったシステムが集まり、大きなサービスを作っている。 そう考えると、システム全体が少しずつ理解できるようになっていった。 そして、A3一枚の「地図」に出会った そんな中で、私が一番目を見張ったのが「システム構成図」だった。 たくさんのシステムが存在している。 サーバもたくさんある。 それぞれが複雑につながっている。 それなのに、それらが A3一枚 に収...

ロンドン生まれのシステムを、日本の現場へつなぐ仕事 「おおっ、地下に行くほど、仕事が面白くなっていく！」 そんな不思議な感覚を持ちながら、私は毎日のようにお客様のビルの地下へ向かっていた。 当時、私はロンドンで開発されたシステムを日本に導入するプロジェクトに、日本側のシステム担当として参加していた。 すでにアプリケーションそのものは完成している。 つまり、ゼロからシステムを作るプロジェクトではない。 しかし、日本で使うとなれば話は別だった。 「完成している」のに、やることは山ほどある 日本側にはインフラチームが大勢集められていた。 さらに、周辺システムとのインターフェース変更など、日本側で追加開発しなければならないものも数多くあった。 私は、その中で少し変わった役割を担っていた。 システムそのものを理解し、それを日本側の関係者に説明する。 ところが、ロンドンから来たシステムの資料は当然ながら英語。 そこで、私が一生懸命取り組んでいたのが「翻訳」だった。 ただ、日本語に訳せばいいわけではない。 「この機能は何のためにあるのか」 「この処理は業務上、何を意味しているのか」 「日本側のシステムとは、どうつながるのか」 翻訳しながら、私は少しずつシステムそのものを理解していった。 私を支えてくれた、二人のスーパー担当者 このプロジェクトには、先方側の担当者が二人いた。 一人は、日本人なのに英語がペラペラ。 しかも、システムのことだけでなく、業務のことまで深く理解している。 まさに「スーパー日本人」だった。 もう一人はイギリス人。 彼も同じようにシステムと業務を理解していて、さらに日本語を勉強していた。 この二人に支えられながら、プロジェクトは少しずつ前へ進んでいった。 二人は基本的に日本にいた。 そして、プロジェクトの開発チームがいた場所が、お客様のビルの地下だった。 地上は「業務」、地下は「作戦」 お客様の業務関係者は上の階。 そして、システムを作り上げていくプロジェクトチームは地下。 なんとも不思議な構造だった。 二人は、ほぼ地下にこもっていた。 私も、翻訳をしたり、システムの説明を聞いたりする機会が増えるにつれて、次第に地下にいる時間が長くなっていった。 地下の部屋で、英語でシステムを勉強する。 分からない言葉があれば聞く。 業務の背景を教えてもらう。 そして、それを...

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

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

うわっ！羽田空港の搭乗ゲートが、“人生の難易度変更ボタン”に見えた――。 プロジェクトが始まって、まだ1ヵ月。 突然、上司から言われた。 「ロンドン出張、2週間ね」 え？ 研修ではない。 視察でもない。 完全に“仕事”としての海外出張だった。 しかも行き先は、ロンドン。 金融街Waterloo。 当時の私は、社会人8年目。 グローバル案件への憧れはあった。 しかし、正直に言うと、金融の仕組みなんて、ほとんど分かっていなかった。 もちろん、一生懸命勉強した。 市場、決済、トレーディング、金融ネットワーク…。 でも、難しい。 本を読んでも、会議に出ても、正直「分かった気がする」レベルだった。 そんな状態で、突然決まったロンドン出張。 しかも目的は、 「ロンドンで動いている金融システムを理解しに行くこと」 いや、無理では？ “大企業案件”のリアル 今振り返ると、こういう巨大案件に入れるのは、大企業の強さだと思う。 日本の金融市場にも影響を与えるレベルのシステム。 その現場へ、実際に行ける。 これは普通では経験できない。 だからこそ、私は思った。 「ここで実力を見せないといけない」 まだ何者でもない。 でも、ここで結果を出せれば、自分は変われるかもしれない。 気合だけは、異常に入っていた。 ロンドン金融街・Waterlooへ メンバー構成は5人。 ・サーバチーム ・運用メンバー ・アプリケーション担当の私 ・そして、プロジェクト部長 営業はいなかった。 つまり、“売るための出張”ではない。 純粋に、システムを理解するための出張だった。 このメンバー構成が、逆に緊張感を生んでいた。 特に、システム部長。 寡黙。 静か。 でも圧倒的な威厳がある。 余計なことは話さない。 しかし、質問には本質だけを返す。 当時の私は、その空気だけで緊張していた。 2週間は長いのか？短いのか？ 当時は、「2週間の海外出張」と聞いて、かなり長く感じた。 初めての泊まり出張。 しかも海外。 それだけで非日常だった。 でも、今なら分かる。 巨大金融システムを理解するには、2週間なんて短すぎる。 サーバ構成。 運用設計。 監視。 DB。 ネットワーク。 市場との接続。 一つ理解すると、...

うわっ！机の上に積まれた英語ドキュメントが、まるで金融街のビル群みたいに見えた――。 社会人8年目。 私はずっと「グローバルプロジェクトに入りたい」と手を挙げ続けていた。 英語は少しだけ自信があった。 とはいえ、TOEICは750点。 今思えば、全然ペラペラではない。 でも、海外案件に関わりたい。 海外の人たちと仕事をしたい。 日本だけでは見えない世界を知りたい。 そう思いながら、少しずつ英語を勉強し、その時を待っていた。 そして、ついにそのチャンスがやってきた。 「英語プロジェクトに入ります」 当時の私は、かなり嬉しかった。 やっと来た。 待ちに待ったグローバル案件だ、と。 ただ、そのタイミングで気になっていたことがあった。 チームの中に、かなり強烈な“パワハラ気質”の営業がいたことだ。 正直、空気は重かった。 でも、仕事は仕事。 「せっかく掴んだチャンスだ。全力でやろう」 そう自分に言い聞かせていた。 ロンドンが本拠地の金融システム プロジェクトの中心はロンドン。 ロンドンの金融会社のシステム部門が持つシステムを、日本へ展開する案件だった。 日立は、日本側ベンダーとして参画。 私たちの役割は、そのシステムをプロフェッショナルの視点で確認し、日本への導入方法を探ることだった。 基本的には、ロンドンで動いているシステムをパッケージ化して持ってくる。 日本側にもサポートメンバーはいる。 しかし、本拠地は完全にロンドン。 つまり、情報も文化もルールも、全部“向こう基準”だった。 そして、アプリケーション部隊は――私一人。 最初の仕事は「読むこと」 大量のドキュメントが渡された。 運用設計書。 スケジュール定義。 バッチ処理設計。 DB設定。 サーバ構成。 ネットワーク構成。 外部システム連携。 金融システムらしく、かなり細かく書かれていた。 逆に言えば、読むことができれば、全体像は見えてくる。 だから最初の仕事は明確だった。 「まずは、このドキュメントを読み解くこと」 しかし、最大の問題が発生する 2次ベンダーから、それぞれ専門領域を持ったメンバーがアサインされてきた。 サーバ担当。 ネットワーク担当。 DB担当。 みんな、それぞれのドキュメントを読み始める。 …が。 ...

  衝撃のスタート 「えっ!? CRMをゼロから作るって本気ですか!?」──あの日、会議室でお客様の決断を聞いた瞬間、私の血が沸き立った。ヨーロッパ仕様をそのまま導入するか、日本独自に設計し直すか。お客様は迷わず「日本独自」を選んだ。つまり、一から要件定義をし、すべてを設計し直す大仕事。その瞬間から、コンサルとしての私の真価が問われるプロジェクトが始まった。 すべてをリードする日々 要件定義、アーキテクチャ設計、セキュリティ検討、アプリ選定、グローバルアプリとのアラインメント──。まるで大海原に一人で漕ぎ出すような感覚だった。Solution Architectureのリード、Data Integrationのリード、BIリード、何でもこなした。気づけば「何でも屋」のように、どの領域でも前線に立っていた。 夜明け前の会議ではアメリカのメンバーに要件を説明し、深夜にはスイスのチームと議論を交わす。昼間はインドの開発メンバーと連携し、データフローやオペレーションフローを整備。時差の壁を超え、世界中と対等に渡り合う日々。英語をフル活用しながら、まさに「日本にいながらグローバル」であることを体感した瞬間だった。 コードに向き合うコンサルタント コンサルといえば「提案」や「調整」のイメージが強い。しかし私は違った。コードを覗き込み、テストの方法を指導し、現場の課題をリアルタイムで解決していった。お客様にとっての信頼は、「口先」ではなく「実装」で勝ち取るものだと学んだ。 終わりと始まり：決断のとき プロジェクトの最後、リードを務めた海外メンバーが私に声をかけた。 「もしよかったら、うちに来ないか？」 胸が高鳴った。これまでコンサルとして走り続けてきた日々が、次の扉を開くチャンスを与えてくれるなんて。 悩んだ末、私は決断した。 「コンサルを離れる。」 そこに後悔はなかった。むしろ、新しい挑戦の始まりに心が震えていた。 アンケートでおこづかい稼ぎ     明日への一歩 これまで培った経験も、グローバルで戦った自信も、すべてが私を次のステージへ導いてくれる。そう確信している。 だからこそ、私は言いたい。 「私ならできる！明日から踏み出す。」

華々しい成功の裏で起こった「見えない失脚」 プロジェクトロスを超えて、自分の次の一歩を考える物語 🎉社内のヒーローになった、はずだった AWS移行プロジェクトを見事成功させた私は、社内でもちょっとした有名人になった。 「お疲れさま！」「すごかったね！」そんな言葉が飛び交い、グローバルのメンバーからもLinkedInで祝福メッセージが次々届いた。 でも……ふと気づいた。 昇進の話も、昇給の話も、来ない。 拍手だけが鳴り響き、報酬はどこにもなかった。 🤖プロジェクト完遂＝居場所喪失？ さらに驚いたのは、私が所属していたチームに 新しい人が入っていたこと。 プロジェクトに集中するために離れていた間、私の役割を補うために人が採用されていたのだ。 プロジェクトが終わり、「戻ってきました！」と笑顔で帰るも、そこにはもう “私の席”はなかった。 🌀自分のミッションが、他人のものに 新しく入った人がチームのミッションを担当し、私はトラブル対応係に。 名ばかりのグローバル担当、なんとなく残された「AWSの人」―― 確かにプロジェクトは成功した。だけど、そのあとがなかった。 会社内で、私の頑張りを 評価できる人がいなかった 。 📉プロジェクトロス、その正体は プロジェクトロスという言葉がある。だが、私が感じたのはそれ以上だった。 「自分の努力が報われない」という、静かにじわじわと効いてくる喪失感。 そして、「今、私は何のために働いているのか？」という問い。 🧭立ち位置を見失わないことの大切さ 今振り返って思う。 プロジェクト中に、自分の“次の立ち位置”を見つけておくべきだった、と。 華々しいプロジェクトの裏側で、自分自身の居場所を築くことを怠っていたのかもしれない。 グローバル企業においては、プロジェクトが終わったあとこそが、本当の“サバイバル”の始まりだ。 🚪最後に選んだ「次の一歩」 結局、私はその企業を離れた。 誇りと実績を胸に、次のステージへ進むために。 でも後悔はしていない。 あの経験は、今でも自分の武器になっているし、グローバルと日本をつなぐ意味も深く理解できた。     ✨明日からの一歩は、今ここから グローバルプロジェクトは面白い、難しい、でも本当に挑戦しがいがある。 ...

グローバル企業で成功したはずのプロジェクト、その裏側にある“意外な現実”とは 💥プロジェクト成功のはずが、まさかの事態！？ うそでしょ！？プロジェクト大成功したのに、私の居場所がなくなった――！ グローバル企業に勤めて数年。いくつかのプロジェクトを経験してきたが、中でも強烈に記憶に残っているのが「グローバルAWS移行プロジェクト」だ。 🌐グローバル vs 日本の構図 もともと日本発祥の企業でありながら、今ではグローバルに展開するこの会社では、よくある構図がある。 それは、 「グローバルで決まったことを、日本がどう飲み込むか」 という構図だ。 海外のリーダーたちが計画し、日本側を説得して実行に移す。だが実際のところ、グローバルの意思決定は遅く、何をしているのか分からない。連絡もなかなか来ない。 AWSへの移行案も、立ち消えたと誰もが思っていた。 🧨いきなり始まった！？秘密裏のプロジェクト ところが、ある日突然、動き出した。 実はアメリカで密かに準備が進められており、ベンダーもすでに決定済み。 日本に対しては「この流れに乗ってください」とだけ言われた。 当然、誰も賛同しない。誰も助けてくれない。 まず私が取り組んだのは、日本社内での説得。 何ヶ月もかけて、影響範囲の説明、責任分担、スケジュールの共有など、根回しと合意形成に奔走した。 🇯🇵日本だけ後発、リソース確保に苦戦 ようやく日本社内の了承を取り付け、プロジェクトが本格始動。 すでに他国では一部移行が完了していたため、日本は完全なる後発。 その結果、リソースの確保は難しく、発言権も弱い。 「最初に手を挙げた国の意見が通りやすい」――これは、グローバルあるあるだ。 ⚙技術者、調整役、通訳まで、すべて私 技術支援、トラブル対応、PM、通訳役までこなす毎日。 グローバル側が出してくる資料や仕様は、日本の現場では通用しないものばかり。 そのギャップを埋めるために、朝も夜も働きづめだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」     ⏳奇跡のオンタイム完了、でも… 遅れるのが当たり前なグローバルプロジェクトの中で、私は何とかスケジュールを調整し、日本だけは ほぼオンタイムで完了 させた。 その瞬間、自分でも「やり切った」...