Digital Heroes: Guide to IT World

あっ！自信満々で海を渡ったエンジニアが、システムの前で迷子になった。 入社8年目。 私はお客様が導入した金融システムの研修のため、ロンドンへ向かっていた。 サーバ担当、ネットワーク担当、オペレーション担当も一緒だ。 そしてアプリ担当は私一人。 しかも担当するのは単なる業務アプリではない。 金融システム全体。 数多くの機能が連携し、複数のシステムが複雑に接続される巨大なシステムだ。 私はかなり意気込んでいた。 これまで数々のシステムを構築してきた。 Javaによる3層構造。 Webシステム。 データベース設計。 インターフェース設計。 お客様向けシステムの開発。 アプリケーション開発には自信があった。 「このシステム全体を理解し、将来的には開発や運用もサポートする。」 そんな使命感を持ってロンドンへ向かった。 ■ 最初の違和感 研修初日。 講師が説明を始める。 しかし、何かがおかしい。 言っていることが頭に入ってこない。 英語の問題ではなかった。 むしろシステム用語ばかりだ。 知っている単語のはずなのに意味がつながらない。 サーバ担当は理解している。 ネットワーク担当も理解している。 オペレーション担当も質問している。 なのに私だけが取り残されていた。 なぜだろう。 ■ システムを理解していたつもりだった その答えに気づくまで時間がかかった。 私はずっと「アプリケーションの中」を見ていた。 画面があり、 業務ロジックがあり、 データベースがある。 いわゆるJava中心の3層構造だ。 しかしロンドンで説明されていたのは、そのさらに外側だった。 システムとシステムはどうつながるのか。 相手システムをどう認識するのか。 通信経路はどう設計されるのか。 障害が起きたらどこで切り分けるのか。 認証はどう行うのか。 通信先の設定はどこで持つのか。 ロードバランサーはどう動くのか。 ネットワークを越えた先にあるシステムとどう連携するのか。 私はシステム間のデータ連携設計は経験していた。 CSV連携もAPI連携も設計してきた。 だが今振り返ると、それは「つながっている前提」で設計していただけだった。 そもそもどうやってつながるのか。 なぜつながるのか。 どの設定がその接続を支えているのか。 そこへの理解が圧倒的に不足していた。 ■ 焦り続けたロンドンの日々 研修は進む。 しかし理解が...

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

「自信」を持っていた、あの頃 うわっ！“エンジニア人生の地図”が、ロンドンで一気に書き換わった──。 社会人8年目。 それなりにシステム構築を経験してきた。 Java4。 当時としては最先端側のシステム管理にも関わっていた。 国内案件も複数経験し、自分なりの自信もついてきていた頃だった。 「海外のシステム担当と連携する」 それだけで胸が高鳴った。 しかも場所はロンドン。金融システムの中心地の一つだ。 研修前、私は大量の手順書を読み込んだ。 システム概要、運用設計、障害対応フロー。 だが、そこでまず驚いた。 「特別なシステムなのに、ここまで書くのか？」 そのシステムは、かなり特殊だった。 しかも自前で作り込まれている。 普通なら“属人化”していてもおかしくない。 だが実際は逆だった。 手順書が異常なほど整理されていた。 まるでソフトウェアそのもののように、構造化されている。 「誰が見ても分かるように作る」 そんな思想が、資料全体から滲み出ていた。 日本では、“詳しい人しか分からない資料”に出会うことも多かった。 だが、ロンドンでは違った。 “人に依存しない設計”を、本気でやっていた。 ここでまず、考えさせられた。 「日本は丁寧」と言われる。 だが、本当にそうなのか？ ロンドン金融システムの現場で見た“異様な景色” さらに衝撃だったのは、実際の運用現場だった。 巨大なスクリーンが9枚。 一人のオペレーターが、その全体を監視している。 しかも、その人が説明までしていた。 全体説明。 詳細説明。 運用設計。 障害時の考え方。 カバー範囲が、とにかく広い。 こちらは5人以上で話している。 だが向こうは、ほぼ一人。 「え？」 正直、最初は理解できなかった。 日本なら、 インフラ担当、DB担当、運用担当、アプリ担当…。 細かく役割分担されることが多い。 だが、ロンドンの現場では、一人が広く深く理解している。 もちろん裏にはチームがいる。 だが、“その場で説明できる範囲”が圧倒的だった。 「世界で戦う」とはこういうことなのか？ 私は、その時初めて感じた。 「日本のエンジニアは、分業に最適化されすぎているのでは？」 もちろん、日本の品質は高い。 慎重さもある。 レビュー文化も強い...

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

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

うわっ、キーボードよりも先に“床”と戦う仕事だったのか!? ■システム構築＝机に座る仕事？ 「システム構築って、パソコンに向かってコードを書く仕事ですよね？」 そんな問いに、私は一瞬、言葉を失う。 確かに、そういう側面もある。 だが、それだけで語るにはあまりにも現場は“泥臭い”。 私はこれまで、いくつものシステムプロジェクトを回してきた。 立場としてはどちらかと言えばマネジメント側。 しかし、プログラムも書いてきた。 サーバも構築した。DBも当然やってきた。 「ネットワークは？」 ——もちろんやっている。 ■まだWi-Fiがなかった時代 今でこそWi-Fiは当たり前だが、10何年前は違った。 開発環境は基本、有線。 青いLANケーブルをHUBに差し込む。 それが“インフラ構築”の基本動作だった。 だが現実は、そんなに綺麗ではない。 青で統一されていればまだ良い方。 黄色、白、どこから来たかわからない古いケーブル。 現場はカオスだった。 ■200人プロジェクトの“現実” 200人規模のプロジェクトになると、話はさらに変わる。 急ごしらえのテーブルを並べる。 当然、ネットワークが追いつかない。 ルーターからHUBをいくつもつなぎ、 そこからさらにLANケーブルを伸ばす。 だが、当然足りなくなる。 ではどうするか？ LANケーブルのソケットを買ってきて、 長いケーブルを切断し、つなぎ直す。 “増やす”のではなく、“作る”。 それが現場だった。 ■昼は会議、夜は職人 昼は会議。 進捗、課題、顧客説明。 完全にマネジメントの顔だ。 だが夜になると違う。 誰もいないオフィスで、 LANケーブルを作り続ける。 ペンチを握り、端子をかしめる。 気づけば、エンジニアというより職人だ。 ■床の下にある“本当のシステム” さらに作業は続く。 LANケーブルは床の上には置かない。 OAフロアを開け、 その下に配線していく。 絨毯を剥がし、床を持ち上げ、 ケーブルを通す。 人がいない時間しかできない。 だから、夜か朝。 急いで配線し、 床を閉じ、絨毯を戻す。 ——あ、ネジ締め忘れた。 次の日、床が“ボコッ”と沈む。 そんなことも日常だった。 ■スーツは泥まみれになる ...

えっ!? プログラムを書かないエンジニアが、システムを支えている——そんな現場に出会った。 ■巨大プロジェクトの裏側 私が関わっていたのは、200人を超える大規模プロジェクトだった。日本の中枢を支える金融機関の中核企業。その基幹システムの一つを、COBOLからJavaへと変換するという、まさに時代の転換点とも言える取り組みだ。 私は構成管理担当として参画していた。日々、膨大なソースコードやバージョン、リリースの整合性を保つ役割だ。Javaのプログラムもいくつか書いていたが、主戦場はあくまで“整えること”。     ■環境を守る、もう一つの主役 そんな中で、常に一緒に戦っていたのがサーバ担当だった。開発者が安心してコードを書けるのは、安定した環境があってこそ。その基盤を支えていたのが彼らだ。 自然と会話も増え、距離も近くなったある日、ふと疑問が浮かんだ。 「サーバ担当って、Javaの構成も詳しいし、やっぱりプログラムも上手いんですよね？」 ■予想外の答え 返ってきた答えは、想像とまったく違っていた。 「いや、私、プログラムできないんですよ」 一瞬、思考が止まった。自分はプログラムから入った人間だ。コードを書き、動かし、その中でシステムを理解してきた。だからこそ、プログラムができないという言葉が、どうしても結びつかなかった。 ■異なる入口、同じゴール 話を聞いていくうちに、その違いが少しずつ見えてきた。 自分は“動くもの”から入っている。だから、処理の流れやロジックはイメージしやすい。一方で彼は、サーバ構成という“土台”から入っていた。 「少しずつ組み立てていくんですよ。ブロックみたいに」 その言葉が妙に印象に残った。 ■デジタルのレゴ 確かに彼は、分厚い技術書を片手に、一つひとつパーツを組み合わせるように環境を構築していた。サーバ、ミドルウェア、ネットワーク、設定ファイル——それぞれを積み上げて、ひとつの“動く世界”を作り上げる。 それはまるで、デジタルのレゴのようだった。 プログラムを書くことだけが“ものづくり”ではない。環境を組み上げることもまた、創造なのだと気づかされた瞬間だった。 ■キャリアは一つじゃない この経験から強く感じたのは、エンジニアのキャリアに正解はないということだ。 コードから入る人...

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

年齢の先にあったのは、圧倒的な「経験知」だった うわっ……その人が、全部決めていたの!? プログラミングやシステム開発と聞くと、どんな人を思い浮かべるだろうか。多くの人が「若い」「30代くらい」「最新技術に強い人」と答えるのではないだろうか。私自身も、ずっとそう思っていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       若手が前に立つプロジェクトの記憶 これまで関わってきたプロジェクトでは、実際に30代のエンジニアが前面に立ち、プロジェクトをリードしていた。 プラットフォーム開発でも、40代の課長が大きな方針を決め、30代のメンバーが各エリアの開発を引っ張る。そんな構図が当たり前だった。 Javaも、当時はまだ「新しい」プログラミング言語だった。 だからプラットフォーム開発は、40代から20代までの比較的若いメンバーで作られている。私は、ずっとそういう世界を想像していた。 現場で目にした、想定外の光景 ところが、実際の現場に足を運んだとき、私は本当に驚いた。 プロジェクト全体をリードしていたのは、50代のエンジニアだったのだ。 特に業務中心の領域では、60歳に近い人が意思決定をしている。 「あの人が、すべての仕様を決めている」 誰もがそう口を揃える存在が、確かにそこにいた。 “あの人”の正体 その人は、超が付くほど経験豊富なエンジニアだった。 Windowsが世に出る前から、システムを支え続けてきた人。 技術だけでなく、金融という業界そのものを知り尽くしている。 30代のエンジニアでさえ、まだまだペーペーと言われる世界。 「システムのこと」と「金融のこと」、その両方を本当に理解している人は誰か。 答えは、迷いなく“あの人”だった。 重鎮がつくる、揺るがないシステム その人は、お客様からも絶大な信頼を得ていた。 派手さはない。最新技術を声高に語ることもない。 しかし、その人が形作るシステムは、金融業界の根幹を静かに支えている。 エンジニアの中心は、若者だけではない。 現場を見て、私はその事実をはっきりと理解した。 年齢ではなく、積み重ね 年齢は関係ない。 問われるのは、どれだけの修羅場をくぐり、どれだけの責任を背負ってきたか。 その積み重ねこそが、最後にシステムを...

「あの人、多分そうだった…」でも、それが何か？ 「あっ！」と思い出す瞬間がありました。 これまでのキャリアで、明らかにLGBTQだと公言していたわけではないけれど、「あの人、多分そうだったな」という同僚が何人かいます。 でも、不思議なことに――一度も気にしたことがないんです。 性別の話題なんて、出たことない 僕らのチームでは、性別や恋愛対象について語り合う時間なんてありません。 マニキュアをしていようが、髪が腰まであろうが、金髪だろうが赤髪だろうが、どうでもいい。 話題に出るのはいつも、 システムのこと、そしてプロジェクトを成功させるための方法 だけです。 「誰が何をして、どうやって完成まで持っていくか」 ――それだけが焦点で、性別は関係ない。 正直、気にするのは年齢と“この2つ”だけ じゃあ何を気にするのかと聞かれれば… 正直、年齢は少しだけ気にします。 プログラムの世界は5年違えば、最初に触った言語も、プロジェクト管理の方法も違う。 その時代に流行っていたシステムや、IDE（開発環境）も変わります。 基本の考え方は変わらなくても、やはりちょっとした差はあるんです。 もう1つは、 使う言語 。 国籍自体は気にしませんが、英語か日本語か、そこは仕事の進め方に直結します。 LGBTQ？全く問題なし LGBTQかどうかなんて、本人がうまく隠していれば分からないことも多いでしょう。 仮に知っていても、それが仕事の成果に影響するわけじゃない。 むしろ多様な価値観はチームにとってプラスになることもあります。 働きやすい環境は整っている 僕が見てきた限り、システム開発の現場はLGBTQの方にも働きやすい環境だと思います。 条件はただ1つ―― システムを理解し、プロジェクト成功のために協力できること 。 それさえできれば、あなたはこの世界で輝けます。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       明日からの一歩 だから僕はこう言います。 「私ならできる！」 そう信じて、明日からまた一歩踏み出そう。

  僕の答えは…NO！ 「えっ、そのシステム、日本製じゃなきゃダメなの？」 そんな問いを何度も聞かれましたが、僕の答えははっきりしています。 NO です。 昔は「日本のエンジニア」「インドのエンジニア」「ベトナムのエンジニア」…なんて国ごとに色を付けて考えていました。 大企業で働いていると、ベンダーの社長や営業の方からこんな提案が飛び交います。 「日本に依頼してください」 「ベトナムが安くて優秀ですよ」 「いやいや、インドが最高です！」 正直、その頃は「国ごとの特性」を意識していました。 本当の差は「国」じゃない 結局わかったのは、成果は チームリーダーの技術力とビジョン に依存するということ。 リーダーが技術を理解し、アイデアが豊富なら、日本でもインドでもベトナムでも同じように成功します。 逆に… 「スタートアップだから技術強いんでしょ？」→いやいや、根性論だけじゃ困ります。 「ベトナム系だから優秀でしょ？」→いやいや、採用してから言ってください。 「大手だから安心でしょ？」→いやいや、エクセルばかり作っていた人もいます。 日本×インドの協業プロジェクト 先日、日本のIoTチームとインドのクラウドチームで協業しました。 開発中、インド側のIssueが止まらず、日本からエスカレーション。会議が何度も行われました。 ところが――本番後に顧客影響のあるバグを複数出したのは 日本側 。 しかもそれが上層部に報告されず…。正直、がっかりしました。 足りなかったもの このプロジェクトは、「同じワンチーム」という意識が育たなかった。 お互いのミスを指摘するだけで、相手を信じて支える姿勢がなかった。 それは僕のチーム作りのミスでもあります。 でも、同じ開発者として、国や立場を超えて「信じて応援する」気持ちを持ってほしかった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       明日からの一歩 システム屋の世界に国境は要りません。 必要なのは、国籍やラベルではなく、 技術を理解し、ビジョンを描けるリーダー と、それを信じる仲間です。 「私ならできる！」――そう信じて、明日からまた一歩踏み出します。

やばい…これは終わったかもしれない… ある大規模ITプロジェクトの現場で、誰かがつぶやいた。スケジュールは崩壊、タスクは未整理、関係者はカオス状態。こうなったらもう、炎上一直線…と思いきや、ある3つのポイントを徹底することで、見事にプロジェクトは軌道修正された。 大規模ITプロジェクトは、一歩間違えば 数億円の損失 、クライアントの信頼喪失、そして チームの崩壊 に直結する。では、成功するためには何をすればいいのか？今回は、絶対に押さえるべき3つの鉄則を紹介しよう。 ① まずは話せ！「会話なくしてプロジェクトなし」 「ITプロジェクトはドキュメントが命！」なんて言う人もいるが、それよりも大事なのが 会話 だ。 会話がなければ、どんなに優れた計画もただの紙切れ 。 最初にやるべきことは、 キックオフミーティング で関係者全員としっかり話すこと。何を作るのか？誰が何をやるのか？この認識を一致させないと、後で必ずトラブルが起きる。 あるプロジェクトでは、開発チームが「A機能」を作るつもりで動いていたのに、顧客は「B機能」を求めていた。数ヶ月後、出来上がったシステムを見て「こんなの頼んでない！」と大騒ぎに。最初にもっと話し合っていれば、こんな悲劇は起こらなかったのに…。 ② EXCELで整理せよ！「プロジェクトは構造化が命」 大規模プロジェクトでは、関係者が多くなり、やるべきタスクがどんどん増える。「これ、誰の仕事？」「どこまで進んでる？」が分からなくなったら、もうアウトだ。 そんなときこそ EXCEL の出番！ 体制図 を作って、誰がどの役割なのかを明確にする **WBS（Work Breakdown Structure）**で、タスクを細分化し、進捗を可視化する リスク管理表 を作成し、問題が起きる前に対策を考えておく 「そんなのExcelじゃなくて専用ツールでやるべきでは？」と思うかもしれないが、シンプルなExcelのほうがチーム全員が簡単に把握できる。実際、成功しているプロジェクトの多くは、Excelを活用しているのだ。 ③ Project Charterを作成せよ！「迷ったら原点に戻れ」 プロジェクトが進むにつれて、「これは本当に必要なのか？」と迷うことが増える。そんな時の拠り所になるのが Project Charter （プロジェクト憲章）だ。 Project ...

  え、日本ってこんなにすごかったの！？ 世界中の企業が日本の技術力を学びたがっている。その理由を知ったとき、僕のキャリア選択は決まった。 日本の企業は世界のトップブランド トヨタ、ソニー、パナソニック、日立…。日本の企業は、世界中で名を知られている。実際、海外のコンサル会社が「TOYOTA WAY」や「KAIZEN（改善）」を掲げ、日本流のマネジメントや技術を高額で売っている。日本企業の名前が「信頼の証」になっているなんて、すごくないか？ 日本の技術は世界の憧れ 海外のビジネスリーダーと話すと、必ず「日本の技術力を学びたい」という声を聞く。特に製造業、精密機械、インフラの分野では、日本が圧倒的に強い。日本の企業で働くことは、その最先端技術を「第一言語」で学べるチャンスなのだ。 時間通りに動く新幹線、止まらない銀行システム 新幹線が1分の遅れもなく運行する国、ATMが止まらず稼働し続ける銀行システム。これって当たり前じゃないんだよ。海外では電車の遅延やシステムダウンは日常茶飯事。そんな中、日本は異次元のレベルで安定したシステムを実現している。 日本のモノづくり＝世界で通用する技術 日本で学ぶ技術は、どこに行っても通用する。実際に日本で鍛えられたエンジニアやビジネスパーソンが、海外で引く手あまたなのは有名な話。だからこそ、僕は日本でキャリアを築くことを選んだ。 まとめ：この国でしか学べない価値がある 「日本で働く」ことは、単なる就職ではない。世界でも通用する技術と仕事のスタイルを学べる、最高の環境なんだ。 🔥 あなたのキャリアを次のレベルへ！日本での可能性、見逃すな！