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

投稿

ラベル(キャリア)が付いた投稿を表示しています

ブログを翻訳

「英語ができる」と「通訳できる」は、まったく別の仕事だった。

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

「なんでも屋です」が、いちばん強かった。──フルスタックを超えたエンジニアの正体

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

あれ?この人、年収1000万円超えてるの?

うわっ、年収の数字に心を奪われた瞬間、私のエンジニア人生の見え方が変わった。 憧れだった「フルスタック」 エンジニアの世界には、前に出て目立つ人だけではなく、地道にシステムを作り続けている人がたくさんいる。 そして、エンジニアは勉強熱心な人が多い。 私もそうだった。 サーバー、ネットワーク、アプリケーション。 それぞれの専門領域を理解し、さらに全体を見渡して、必要な人に指示を出せる。 プロジェクト開発の全体像を理解し、システムを動かせる。 そんな人は「フルスタックエンジニア」と呼ばれ、エンジニアの中でも目標の的になる存在だった。 実際、IPAの難しい試験を受けに行くと、一日がかりの試験会場に、何人ものエンジニアが集まっている。 「この人たちも、いつかフルスタックを目指しているんだろうな」 そんな空気を感じていた。 私にとって、フルスタックは憧れだった。 ところが、フルスタックの「さらに先」がいた あるとき、ロンドンのシステムを日本へ導入するプロジェクトに関わった。 そこでシステムをサポートしていたのが、イギリス人と日本人のコンビだった。 イギリス人のエンジニアは、システムをよく理解していた。 技術の話をすると、構造をすぐに理解する。 「やっぱり外国人はシステムに強いんだな」 私は、自然にそう思っていた。 でも、ある時ふと気づいた。 「いや、このイギリス人と対等に話している、この日本人は何者なんだ?」 その日本人は、日本で一人だけ採用された、英語も日本語も話せるエンジニアだった。 英語でシステムを議論し、日本語でも議論する。 技術だけではない。 ビジネスの話まで理解し、調整し、そして自分で実装までこなしている。 システム、ビジネス、言語。 そのすべてをつないでいた。 私は、すぐにその人に憧れた。 「日本人でも、ここまでいけるんだ」 後になって分かった。 私が「外国人の方がシステムに強い」と感じていたのは、外国人バイアスだった。 本当にすごかったのは、そのイギリス人と対等に渡り合い、さらに日本側のビジネスまで動かしていた日本人だった。 そして、年収の話になった ある日、その人が年収の話をしていた。 私は、それなりに自分の年収に自信があった。 日本有数の大手SIerで働くエンジニア。 社内でも難しい金融システムの開発をリードしている。 年収は700万円。 年齢を考えれば、...

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

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

「お客様もシステム屋だった」――ロンドンで見えたIT業界の境界線消滅

システム屋と業務担当、その境界はどこへ行ったのか 社会人8年目、ロンドンで感じた小さな危機感 うわっ!お客様との会話が、まるでシステム設計レビューになっていた! 社会人8年目。 もう9年目が見え始めていた頃の話だ。 私はシステム屋として、アプリケーション構築に携わってきた。 お客様の要件を聞き、設計し、開発し、導入する。 システムのプロとしてサービスを提供する立場だった。 そんなある日、日本のお客様がロンドンの企業からパッケージシステムを購入した。 その導入プロジェクトに参加することになり、私はシステム研修のためロンドンへ向かった。 研修期間は2週間。 場所はウォータールー周辺。 ロンドンの金融機関や大手企業が集まるエリアだった。 当時の私は、新しいシステムを学ぶことばかり考えていた。 しかし、本当に学んだのはシステムそのものではなかった。 業界構造の変化だった。 ■ お客様との会話に違和感を覚えた 研修やプロジェクトの打ち合わせが始まった。 私はシステムベンダー側として説明を行う。 アーキテクチャ。 データ構造。 運用設計。 インターフェース。 するとお客様から質問が飛んでくる。 しかも、その質問が妙に鋭い。 「その設計だと将来的な拡張性はどうなりますか?」 「データ移行時の整合性はどう担保しますか?」 「パフォーマンス試験はどの条件を想定していますか?」 あれ? なんかおかしい。 業務要件の質問ではない。 システム屋がする質問だ。 私は少し戸惑った。 ■ なぜお客様がこんなに詳しいのか しばらくして理由が分かった。 実はお客様側の担当者の多くが元システム屋だったのである。 SIer出身。 開発会社出身。 インフラ出身。 転職して事業会社へ移った人たちだった。 つまり、 業務担当者でありながら、 システムのプロでもあった。 私は衝撃を受けた。 それまで私の中には、 お客様=業務担当 ベンダー=システム担当 という構図があった。 しかし現実は違った。 境界線がなくなり始めていたのである。 ■ システム屋の価値はどこにあるのか そこで考え始めた。 私たちシステム屋は何を武器にすれば良いのだろうか。 アプリケーションの専門家として技術を磨くべきか。 しかしサーバ担当もいる。 ネットワーク担当もいる。 データベース担当もいる。 インフラ領域は専門ベンダーが支えている。 で...

「“作る側”なのに、なぜ席が違う?」——ロンドン行きの飛行機で感じた、IT業界の静かな格差

“エコノミーじゃない”だけで感動していた うわっ!空の上にも“会社の階級”って存在するのか——そう思った。 入社8年目。 私はロンドンへ向かう飛行機に乗っていた。 理由は、お客様がロンドンで動いている金融システムを導入するための研修。 当時の自分にとって、“海外金融システム”という言葉だけで別世界だった。 しかもロンドン。 映画でしか見たことのない場所。 そして、さらに驚いたのは飛行機だった。 プレミアムエコノミーですら「すごい世界」 日立のメンバーはプレミアムエコノミー。 正直に言う。 その時の私は、それだけで十分感動していた。 「え?席広い!」 「足伸ばせる!」 「毛布違う!」 そもそも“エコノミー以外”なんて知らない。 飛行機にランクがあることすら、現実感がなかった。 だから、ビジネスクラスなんて、ほとんど異世界だった。 ラウンジって何? 空港で、お客様側メンバーが別方向へ歩いていく。 「ラウンジ使うので」 ラウンジ? 何それ? しかも、お客様はビジネスクラス。 別ルート。 別搭乗。 別空間。 同じプロジェクト。 同じロンドン。 でも、移動の世界が違う。 その時、少しだけ頭によぎった。 「あれ?やっぱりベンダーだから?」 “技術側”なのに、なぜ立場が違う? その出張には、40代のシステムサーバ担当も参加していた。 金融機関システムを長年支えてきたベテラン。 経験値だけなら、先方の部長クラスに近い。 障害対応。 深夜対応。 性能改善。 運用保守。 現場を知り尽くした人だった。 でも、その人も私と同じプレミアムエコノミー。 そこで、なんとも言えない感情が生まれた。 「飛行機のランクって、個人じゃなくて“企業”で決まるんだ」 モノづくりって、もっと強いと思っていた 私は昔から、システムを作れる人は格好いいと思っていた。 巨大システムを動かす。 社会インフラを支える。 金融を止めない。 そんな技術者に、強い憧れがあった。 だから、どこかで思っていた。 “作れる側”は強い、と。 でも現実は少し違った。 お客様側の方が、立場が上に見える。 待遇も違う。 移動も違う。 給料も、たぶん違う。 もちろん、それは契約構造や責任範囲の違いでもある。 発注側と受託側で...

“英語できる奴いない?”——その一言で、地獄みたいな金融プロジェクトに放り込まれた話

うわっ…人生って、“逃げていた場所”から未来が始まることがある。 入社して8年目。 私は、ある意味で“平穏”なエンジニア人生を送っていた。 いや、正確には違う。 ずっと避け続けていたものがあった。 それが—— パワハラ営業だ。 怒鳴る。詰める。無茶を言う。 現場を振り回し、空気を凍らせる。 そんな人物だった。 だから私は、できるだけ距離を取っていた。 だが、ある日。 突然、その営業案件への参加を命じられる。 「英語できる人、他にいないから」 ……え? ■ “英語ができるシステム屋”は、実は少ない その時、私は開発部隊の中で唯一の参加者だった。 しかも、アプリチームからも一人だけ。 理由は単純。 「英語が多少読めるから」。 これ、IT業界では意外と議論になる話だ。 システムは作れる。 コードも書ける。 だが、“英語で運営される世界”に入れる人材は極端に少ない。 しかも今回の案件は、普通ではなかった。 新しい金融サービスを、日本で立ち上げる。 だが、そのサービス自体が日本に存在しない。 つまり—— 業務そのものを海外から輸入する。 システムも。 運用も。 考え方も。 全部だ。 ■ ロンドンの金融システム、日本上陸 導入されるのは、ロンドンを中心に使われる世界的金融システム。 当然、ドキュメントは全部英語。 仕様書。 設計書。 運用手順。 会議資料。 全部、英語。 しかも、金融知識まで必要になる。 私は、その頃まだ金融システムの知識は未熟だった。 だが、システムそのものは少しずつ理解できるようになっていた。 だからこそ言われた。 「アプリチーム目線で指摘してほしい」 いや、簡単に言うな。 こっちは、いきなり世界基準の金融システムに放り込まれている。 しかもプロジェクトのコントローラーは、1次受けベンダーの重鎮。 プロパー側も全体統括クラスしかいない。 そこに—— あのパワハラ営業。 そして、その取り巻き。 現場の空気は、常に張り詰めていた。 ■ “嫌いな人間”が、巨大案件を取ってくる現実 ここ、かなり議論を呼ぶと思う。 私はその営業が嫌いだった。 今でも、やり方が正しかったとは思わない。 だが。 こんな巨大プロジェクトを取ってくる。 しかも、日本に存在し...

その“ありがとう”は誰のものか?—パワハラ営業に捕まった夜に見た、大企業の静かな崩壊

うわっ…静かなオフィスに、怒号だけが響く夜がある——。 ■ 深夜の訪問者というストレス あの頃、深夜残業は当たり前だった。10時、11時。やっと自分の仕事に集中できる時間に、決まって現れる“営業”。しかも課長クラス。なぜこの時間に来るのか。なぜこのタイミングで人を捕まえるのか。現場のリズムを完全に無視したその振る舞いに、誰もが内心うんざりしていた。 ■ 上にはペコペコ、下には強圧 その営業は、たまに部長と話している姿を見かけた。驚くほど低姿勢で、まるで別人だった。だが現場では違う。お客様の前でメンバーを叱責し、会議室の椅子を蹴飛ばして壊したという話も聞いた。実際、お客様にそれとなく聞いたときも「あぁ、あの人ね」と、すぐに通じた。つまり“有名”だったのだ。悪い意味で。 ■ 捕まった、その日 ある日、ついに自分も捕まった。「これ、英語の資料。翻訳して」。別に翻訳くらいやる。ただ、時間もないし概要だけ訳して返した。すると後で呼び出され、激怒。「今すぐ全部やれ」。その場で全ドキュメントを、1時間で翻訳させられた。 ■ 屈辱の本質は“構造”にある 英語が話せない人に偉そうにされる。それ自体も不快だが、それ以上にきつかったのは、周囲の空気だった。「可哀想に…」という視線。しかし誰も何も言わない。誰も止めない。この“見て見ぬふりの構造”こそが、人を追い詰める。あぁ、こうやって人は病んでいくのか、と実感した瞬間だった。 ■ 「ありがとう」で終わる歪み 翻訳が終わると、「ありがとう」の一言。それで終わり。そこに悪意はないのかもしれない。しかし、過程を無視した感謝は、むしろ暴力に近い。評価されるのは成果だけ。プロセスで何が起きたかは、誰も問わない。 ■ 回避できる人、できない人 その後、自分はその人の仕事を徹底的に避けた。幸い違う部署だったからできた。しかし、もっと密接に関わる部署ならどうだったか。逃げ場のない人たちは、どうなっていたのか。これは個人の問題ではない。構造の問題だ。 ■ 大企業の“見えない闇” こうしたパワハラ営業が幅を利かせていた現実。それは一部の異常者の話ではなく、大企業の中で許容されていた“文化”だった。巨大組織の中では、数字を作る人間が正義になる。そしてその裏で、静かに削られていく人がいる。 ■ ビジネスとしての示唆 ここで問うべき...

優しさは武器になるのか?——200人プロジェクトで出会った“静かなリーダー”

うわっ…こんなにも“戦い方”が違うのか!? ■システム担当者という幻想 「システム担当者」と一言で言っても、その中身は驚くほど多様だ。 プログラマーと呼ばれる人たちも同じ。 パソコン一つで作業をする職種だからといって、全員が強く押し切るタイプとは限らない。 むしろ現場に入ると、その多様性に戸惑う。 前のプロジェクトでも、リードするイメージのなかった同期が、いつの間にか全体を引っ張っていた。 役割は肩書きでは決まらない。 現場での振る舞いが、その人のポジションを作る。     ■200人プロジェクトという“圧力” 社会人6年目。 私はMAX200人を超えるプロジェクトに入った。 規模が大きくなるにつれ、プロパーのメンバーも後から増えてくる。 組織は流動的で、常に変化し続けていた。 そんな中、隣のプロジェクトで中堅として活躍していた同期が、こちらに移ってきた。 彼は構成管理担当として加わることになった。 ■怒らない男の戦い方 彼を一言で表すなら——とにかく穏やか。 もしかしたら「怒る」という感情を知らないのではないかと思うほどだ。 人の話を真摯に聞く。 そして、ゆっくりと話す。 構成管理という役割は、各チームからの要望が集中する。 時には無理難題も飛んでくる。 それでも彼は、一つ一つ丁寧に耳を傾け、ゆっくりと回答を作っていく。 当然、時間はかかる。 彼はいつも終電だった。 一度、体調を崩して来られなくなったこともあったらしい。 「リハビリ期間なんだよ」と笑いながら話していた。 それでも彼は変わらなかった。 どんな時も、人に向き合う姿勢を崩さなかった。 ■理想と現実の狭間で 正直に言えば、私は迷っていた。 彼の姿勢は、間違いなく見習うべきものだ。 だが、仕事が山積みのプロジェクトで、そのやり方は成立するのか。 スピードが求められる現場で、丁寧さは時にリスクにもなる。 私たちは、終電まで並んでパソコンを叩く日々を過ごした。 彼がいてくれて良かった。 話を聞いてくれる存在がいるだけで、抱え込まずに済んだ。 だが同時に思う。 一度来られなくなった後、リハビリと言いながら終電まで働くこの状態は、本当に正しいのか。 ■正解のない世界で この世界に、明確な正解はない。 速さで押し切る...

3か月で去ったプロジェクトが、なぜか一番忘れられない理由

うわっ、終わったはずのプロジェクトが、いまだに頭の中で続いている――。 ■プロジェクトは「長さ」で記憶に残るのか 社会人になってから、いくつものプロジェクトを回してきた。 短いものから長いものまで。 短くて2、3か月、長くて2年以上。 やはり記憶に残りやすいのは長いプロジェクトだ。 そりゃそうですよね。 時間をかけ、苦労し、乗り越えた分だけ、思い出は濃くなる。 しかし、例外もある。 短いのに、妙に強烈に残るプロジェクトがあるのだ。 ■3か月で終わった、終われなかったプロジェクト 今回のプロジェクトもそうだった。 わずか3か月で離れることになった案件。 正直、悔しかった。 「役に立ちませんでしたよ」と言われているような気がしたからだ。 もちろん、そんなことはない。 理由はシンプルで、部署間の取り決め。 最初から「いついつまで」という約束が決まっていた。 直前に一つのプロジェクトをやり遂げていた私は、 次も活躍できる自信があった。 だが現実は違った。 ■“関われるのに、踏み込めない”という制約 契約上、メインタスクには関われない。 意思決定にも深く入れない。 できることは、情報を伝えること。 補足説明をすること。 私は、できる範囲で動いた。 説明会の資料作成を手伝い、 何かあればアドバイスをする。 しかし、それ以上は踏み込めない。 目の前では、同期がメインでプロジェクトを回している。 明らかに忙しい。 助けたい。 でも、リードが取れない以上、 そのタスクをカバーすることはできなかった。 ■やり切れなかったという違和感 そして、3か月。 私はプロジェクトを離れた。 形式的には「完了」。 しかし、感覚としては「未完了」だった。 何か引っかかる終わり方。 やり切った感覚が、まったくない。 ■その後に知った“もしも”の連続 そのプロジェクトは、その後も何年か続いた。 そして、かなりドタバタしていたらしい。 作り直し。 方向転換。 混乱。 話を聞くたびに、こう思ってしまう。 あの時、もう少し踏み込んでいれば。 あの時、自分の手を動かしていれば。 何か変えられたのではないか。 もちろん、後からなら何とでも言える。 契約や役割の制約は現実だ。 それでも、この「心残り」は消えない。...

同期が100人プロジェクトを率いていた日 ――「支援」という立場の難しさを初めて知った瞬間

う わっ、 あいつ が こんな 大きな プロジェクト を 率 い て いる の か! プロジェクト を いくつか 経験 した 頃、 私 は 別 の プロジェクト へ「 支援」 として 入る ことに な っ た。 自分 の 担当 プロジェクト が 落ち 着い た タイミング で、 他の プロジェクト を サポート する。 IT 業界 では よく ある 話 だ。 ただ、 今回 の 支援 先に は 少し 驚 い た。 その プロジェクト を リード し てい た の が、 私 の 同期 だ っ た からだ。 同期 が 率いる 100 人 プロジェクト プロジェクト に 入 って み て、 まず 規模 に 驚 い た。 メンバー は 100 人 を 超える。 Web 機能 の チーム、 バッチ 機能 の チーム。 さらに 複数 の ベンダー が 参加 し て いる。 チーム の 数 も 多く、 調整 も 複雑 だ。 それ まで 私 が 経験 し てい た プロジェクト は、 最大 でも 70 人 ほど だ っ た。 その 倍 近い 規模 だ。 そして、 その 中心 で プロジェクト を まとめ て いる の が 同期 だ っ た。 正直、 誇らしい 気持ち に な っ た。 同じ 時期 に 入社 した 仲間 が、 ここ まで 大きな プロジェクト を 任 さ れ て いる。 「 すごい な」 そう 思 っ た。 昔 の 彼 は リーダー タイプ では なか っ た ただ、 少し 不思議 な 気持ち も あっ た。 彼 は 昔 から、 いわゆる リーダー タイプ では なか っ た からだ。 どこか 独特 で、 あまり みんな と 群れる タイプ では ない。 スポーツ を や って い た わけ でも なく、 体育 会 系 の 雰囲気 も ない。 どちら か という と、 静か で まじめ な タイプ。 そんな 彼 が、 100 人 規模 の プロジェクト を リード し て いる。 「 人 って 変わる ん だ な」 そんな こと を 思い ながら、 私 は 支援 メンバー として プロジェクト に 入 っ た。 夜 遅 く まで 残る 同期 プロジェクト に 入 って から 気 づ いたこ と が ある。 ...

今さら!?――「女性の社会進出」に感じた小さな違和感

性別よりも、向き合うべき“本当の問い”とは ずっと前から当たり前だと思ってた! 新人のころから、ずっと不思議だったことがある。それが、「女性の社会進出が!」という言葉だ。ニュースや会議、研修の場で何度も聞くたびに、なぜか胸の奥に小さな引っかかりが残っていた。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       ■ 幸か不幸か、身近にいた“働く女性たち” 幸か不幸か、私の周りには働く女性が本当にたくさんいた。 祖母は、ケーキ屋さんを営んだ後、60歳からの手習いで始めた大正琴で、ついには教室を開いた。母は学校の先生をしながら、家では個人塾を切り盛りしていた。学校の先生も女性が多く、特に英語の先生は女性が多かった印象が強い。 正直に言えば、「女性の先生に叩きまくられた」という経験談を持つ人も少なくないだろう。それくらい、女性が前線で働く姿は日常だった。 ■ 理系に進んで見えた、別の“少なさ” 高校は男子校だったから、女性が少ないのは当たり前だった。だが、大学で理系に進み、違和感ははっきりした。クラス29人中、女性はたった2人。 だから私は、「女性の社会進出」よりも、「そもそも理系に女性が少ないことの方が不思議だ」と感じていた。 実際、女性でも私より工学知識が高い人は山ほどいる。数学だって、何度もいろんな人に負けてきた。能力の問題ではないことは、現場にいればすぐ分かる。 ■ 社会に出て、また感じた違和感 社会人になっても、相対的に女性の数は少なかった。だが、大学時代よりは確実に多い。「あ、意外と多いな」と素直に思った。管理職にも部長職にも女性はいた。 だから、「女性の社会進出が課題で…」という話が、どうにもピンとこなかったのだ。 ■ システム業界は、性別を超えられる場所 システム開発は、女性も存分に活躍できる業種だ。重いものを持つ必要はない。必要なのは、知識と論理と粘り強さ。つまり、頭一本で挑戦できる世界だ。 しかも、コミュニケーションが極めて重要。もしかしたら、この点では女性の方が得意かもしれない。 もちろん、楽な仕事ではない。夜は遅くなるし、バグが見つからなければ徹夜もある。だが、それは男性でも嫌だ。お風呂に入りたいし、帰って寝たい。それは皆同じだ。 ■ 性別を意識しない社会へ だからこそ、「...

大企業の安心を手放す勇気!私が選んだ個人事業という道

  安定と自由、どちらも諦めない――次の一歩を踏み出すための選択 1. 安定の中の葛藤 「えっ!? 安定した大企業を捨てるなんて、正気の沙汰!?」――そう思ったあなたにこそ読んでほしい、私の挑戦の物語。 次の転職を考えるとき、私にはマスト条件があった。副業を許可してもらうこと。そして自分のアイデアを形にする自由を持つこと。住宅ローンもあり、大企業のネームバリューもある。保険も通りやすく、給料も安定している。家族を守るには、大企業で働き続けることが最適だった。特に住む場所や子どもの教育への影響は無視できない。だからこそ、私は大企業を辞めず、さらに上のポジションを目指す道を選んだ。 2. 自由を求める心 しかし、心の中では常に葛藤があった。大企業の枠の中では、自分が本当にやりたいことをすべて実現できない。毎年100以上のベンチャーやベンダーと接し、新規サービスやプログラム、商品の話を聞く中で、課題解決のアイデアは止まらなかった。「このアイデアを実現する方法は?」と、自問自答が続いた。 3. 企業の枠のリスク 同時に、企業で働くことのデメリットも見えてきた。会社の状況に自分の人生が左右され、もしクビになれば路頭に迷う可能性もある。MBA取得は高額でリスクが大きく、投資も思った成果は出ず借金だけが増えた。 4. 個人事業という決断 そこで私が出した次の決断は、「個人事業」という選択だった。コンサルティングか、商品販売か、まずはできることを少しずつ考えて形にしていく。企業という枠から離れることで、自由にアイデアを試せる環境を作ることができる。リスクはあるが、自分の手で人生を動かせる喜びがそこにはあった。     5. 明日からの一歩 個人事業はまだ始まったばかりだが、計画を立て、行動に移すことで、私のアイデアは現実のものとなる。家族の安心を守りつつ、自分の挑戦も諦めない。 「明日からの一歩、私ならできる!」――そう信じて、私は今日も最初のステップを踏み出す。

上司の転職が教えてくれた、私の次の一歩

衝撃の知らせが胸を打つ 「えっ、あの人が転職!?😲」――オフィスでそのニュースを聞いた瞬間、胸が高鳴った。 直属ではないけれど、人生を変えるキーパーソン 私にとってその人は、ただの上司ではなかった。直属ではないものの、私の思いを理解し、かつ会社の重要な意思決定にも影響力を持つ“キーパーソン”。スペイン人の彼は、常に私の考えをサポートしてくれた。その人が転職するという事実は、私にとって大きな衝撃であり、同時に学びの瞬間でもあった。 新たな挑戦が示す選択の自由 彼は能力のある人で、新たな挑戦を求めていた。Bostonに集中する企業環境の中で、どのように自分のキャリアを活かすか悩んでいたが、結局、新たな道を選んだのだ。「なるほど」と思った。自分の思いや方針が企業の方針とずれるなら、別の場所を探せばいいのだ――そのシンプルながらも強い選択は、私に大きな刺激を与えた。 自分の一歩を踏み出す決意 その出来事をきっかけに、私は再び転職活動を意識し始めた。実は、以前から常に転職エージェントとは接点を持ち、自分の市場価値を確認していた。しかし、このときは本格化させる決意をした。社内で改善活動を行っても、組織の壁に阻まれることが多く、思うように変化を起こせなかったからだ。 空いた時間でお小遣いを貯めよう!「アイリサーチ」     未来を切り拓くために 「ならば、自分の成長と挑戦のために、新しい環境を探すべきだ」――そう考え、私は3回目の転職活動に踏み出した。彼の選択は、私に勇気を与え、そして自分自身の未来を自分で切り拓く決意を後押ししてくれたのだ。 転職は単なるキャリアチェンジではなく、人生を前に進めるための一歩。自分の価値観と向き合い、成長を望む場所を選ぶことができる力を教えてくれた。だから私は、今日も明日も、一歩を踏み出す。

「登壇したのに、窓際族!?」──AWS登壇の栄光と、その後に待っていた現実

成功の影と居場所喪失、そこから見えた大企業の真実 「えっ!? 登壇できたのに、仕事がなくなった!?」──この一文に、私のここ数年の経験は凝縮されている。 栄光の瞬間 私は事業会社のシステム担当として、グローバル規模の難易度の高いプロジェクトを成功させた。システム的にも、他社が実現できていなかったことを形にし、AWSにまで認められ、ついには AWSの公式イベントで登壇 する機会を得たのだ。 会場からの拍手、グローバルのメンバーからの「Great Job!」という声。自分のキャリアの中でも、まさに最大級の成果だった。 予期せぬ落とし穴 しかし、その裏で私は重大な「落とし穴」に落ちていた。 プロジェクトに集中しすぎるあまり、組織改正や新規採用の流れにまったく神経を使っていなかったのだ。気づけば、日本で私一人だったグローバルチームに、インドから新しいメンバーが入っていた。さらに、日本のシステム担当の上に新しく入ったマネージャーが外国人の採用を進めており、私のポジションは組織間のはざまに吸い込まれていった。 結果、私は半年間、ほとんど仕事がない「窓際族」を味わうことになった。驚くべきは、その状況に陥ると、なぜか周りの人も少しずつ距離を置いていく感覚を持ったことだ。 窓際族の真実 世間では「窓際族=やる気のない人」と思われがちだ。しかし、私はそこで気づいた。 窓際族とは、やる気がなかった人ではなく、むしろやる気をもって大きな成果を出したがゆえに、組織の調整のはざまに落ちた人たちなのだ。 ある先輩にこう言われたことがある。 「事業部をまたぐような大きなプロジェクトをやり切ると、その後会社での居場所がなくなる」 まさに、その通りだった。 大企業のリアル 大企業で大切なのは、プロジェクトをやり遂げることではない。 周りを見ながら調整を重ね、組織の動きに合わせて生き抜くこと。グローバル化が進む中では、ポジションを奪うのは日本人ではなく、むしろ外国人だ。 考えてみれば自然なことだ。グローバル企業とは、常に最適なリソースを世界から引き入れる存在だからだ。 そして、次の一歩へ 半年後、ようやく次のポジションが見つかり、再び折り合いがついた。だが、この経験から学んだことは大きい。 「成果を出すこと」と「会社で生き抜くこと」は、似て非なるものだ。どちらも意...

システム屋よ、誇りを取り戻せ!

事業会社で気づいた“低い地位”の真実と、これからの可能性 「えっ!? システム屋って、こんなに肩身が狭いの!?」──事業会社に転職したばかりの私は、思わず心の中で叫んだ。 コンサル時代には、要件定義から検討、開発、ローンチまで一気通貫でプロジェクトを回し、堂々と成果を語れた。ところが、事業会社に入ってみると、システム屋は驚くほど低い位置づけに置かれていたのだ。 ■ 歴史を振り返るとわかること なぜシステム屋の地位は低いのか?それは歴史を見ればよくわかる。 製薬会社では薬を作ること、説明することが企業の中心。エアコン製造会社ならエアコンを作り、販売し、説明することが中心だ。こうした「事業の核」としての業務は、長い時間をかけて社会に認識されてきた。 一方で、システム屋の役割が形を持ったのは、PCが普及し始めたここ数十年のこと。システムは主業務を支えるものであり、各事業部のサポート役として位置づけられてきた。 2000年前後には大規模なシステム部署が立ち上がった時代もあったが、その後ノーコードの発展などで再び「業務支援」の位置に押し戻され、システム屋の立場はバラバラで総じて低めになっていった。 ■ でもちょっと待って! ここで立ち止まって考えてみたい。 今やシステムが関係しない業務なんて、ほとんどないのだ。 ・足で稼ぐ営業も、システムで報告し、AIにサポートされている。 ・製造現場では、システムからの生産指示なくして機械は動かない。 ・顧客対応も、バックヤードも、システムを通してつながっている。 もはやシステム抜きにして業務は語れない。ならばシステム屋はもっと胸を張るべきではないか。 ■ 両方を知る唯一の存在 システム屋は、業務を理解し、同時にシステムも理解している。両方を知る存在は他にいない。つまり「自分がいなければ、この会社の、この業務は回らない」のだ。 考え方次第では、システムはコスト削減にとどまらず、利益を生む仕組みにもなりうる。金融業を見ればわかるように、今やシステムの良しあしが業績そのものを左右する時代になった。各業界も同じ道を進みつつある。 システム屋が会社の“メイン”となる日も、そう遠くはない。 ■ 明日への一歩 システム屋はもっと自信を持っていい。 もっと誇りを持っていい。 私たちは支援役ではなく、未来...

コンサルじゃ世界は変えられない!? 経験から見えた“限界”と、次に踏み出す勇気

「えっ、ここまで提案しても誰も動かないの!?」 コンサルとして様々な会社を回り、プロジェクトを次々に進める中で、何度もそんな歯がゆい瞬間に遭遇した。たった2年ほどの経験だったが、振り返れば濃密で、学びの多い時間だった。朝早くから夜遅くまでプロジェクトの課題を洗い出し、提案書を作り、関係者に説明する——その日々の中で、自分の知識や視点が評価される喜びもあれば、決定権がないもどかしさも同時に味わった。 横断的な視点と提案力の面白さ 多方面から声がかかるため、会社を横断的に見て、多くの改善策や解決策を提案できる。それは確かに面白く、視野を広げる絶好の機会だった。あるプロジェクトでは、複数部門の業務フローを整理し、効率化の提案を行った。その時、各部署から「こんな発想はなかった」と驚かれた瞬間の達成感は、コンサルならではのものだった。 しかし、どれだけ優れた提案でも、コンサルはあくまで“提案者”にすぎない。最終決定には関与できない。声を張り上げ、「ここが絶対に良い!」と叫んでも、決断は闇の中に隠れ、結果として自分の提案が適用されないことも多々あった。 立場の限界と歯がゆさ ベンダーからも“コンサル”として見られるため、重要なポイントは必ず社員を巻き込む必要がある。正直なところ、社員よりも理解している自信はあった。それでも、社員か社員でないかという立場の違いが、決定において決定的な壁になる。さらに、予算も扱えない。自分が熱を込めても、社員が自分のプロジェクトに予算を回さなければ、提案は机上の空論に終わってしまう。 この立場の制約に、何度ももどかしい思いをした。提案が通らず、プロジェクトが停滞する中で、「もっと自分が決められれば…」という思いが何度も頭をよぎった。自分のアイデアが世に出ない悔しさや、現場の実情を知りながらも手を出せないもどかしさ——その感情が積み重なっていった。 次のステップへの気づき それでも、この経験を通して一つの事実に気づいた。立場を変え、社員として、あるいは全体をコントロールできるポジションに立てば、より良いシステムの在り方を本当に実現できるということだ。コンサルとしての限界を知ったからこそ、全体像を見渡し、意思決定に関わる力の重要性が身に染みて理解できた。 また、提案だけでなく、実行まで関わる経験が必要だということも痛感した。提...

英語なんて要らない?──そう思っていた私が、コンサルで武器に変えた瞬間

英語は本当に必要なのか? 「えっ!? Deloitteに入っても、英語なんて使わないの?」──これは私が最初に抱いた違和感です。 大手コンサルといえば、グローバル案件を華やかに飛び回るイメージを持ちますよね。ところが実際は、日本のお客様を支える案件がほとんど。毎日英語を使うシーンなんて、思った以上に少ないのです。 プロジェクト探しの日々 コンサルティングの現場では、案件ごとにプロジェクトメンバーを集めます。適材適所で人を探すというよりは、まず優秀な人を確保して、プロジェクトごとに調整しながらアサインするスタイル。 人材の情報は一箇所にまとまっていないので、「この人、システム強い?」「誰か英語できる人いない?」といった声が、日々ネットワークを通じて飛び交います。そんな中で私も、いくつかの国内プロジェクトを回して経験を積んでいました。 英語×システム、突然のチャンス 入社して1年少したった頃、ある日声がかかりました。 「英語ができて、しかもシステムに強い人を探しているんだけど」 そう、まさに私へのオファーだったのです。聞けば、そのプロジェクトは外国人リードが仕切っていて、厳しくも優秀な方。システム構成を理解し、英語でしっかり説明できる人材が求められていました。 面接での勝負 プロジェクトに入る前、私はそのリードとの面接に臨みました。Architectureの全体像を整理し、どう説明すれば伝わるかを必死に考え抜きました。 結果は──合格。 英語はコンサルの中でも希少な武器。そして「システムがわかる」×「英語で話せる」という掛け算は、想像以上に強力なカードだったのです。 英語は武器になる そのプロジェクトをきっかけに、私のキャリアは加速していきました。Deloitteのような大手コンサルでも、実際には英語を使える人は限られています。だからこそ、ほんの少しのスキルが差別化につながる。 英語は、コンサルタントとしての自分を際立たせる武器でした。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       そして、これから 英語は万能ではないかもしれません。でも「ここぞ」という場面で使えることが、プロジェクトの流れを変え、キャリアを大きく前に進めるきっかけになります。 あの日の挑戦があったから、私はグローバルなシ...