Digital Heroes: Guide to IT World

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

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

新人の頃、まぶしすぎた先輩の背中 うわっ、プロジェクトってこんなにも人の人生を映すのか!? 新人だった頃、私はプロジェクトルームの端で、いつも同じ先輩の背中を目で追っていた。     ■ まぶしかった「お客様へ報告に行く姿」 その先輩は、週に二回以上、お客様のところへ報告に行っていた。 「問題ありません」 30人規模のプロジェクトを前に、そう言い切る姿が、とにかくかっこよかった。 正直に言えば、当時の私は思っていた。 「ベンダーの花形って、こういう人なんだろうな」と。 ■ 実際に動いているのは、誰か 一方で、現場ではプログラマーの皆さんが必死にコードを書いていた。 Javaの実装、サーバ設定、パラメータ調整、構成管理。 泥臭い仕事の積み重ねで、システムはようやく形になる。 それでも、その全体を把握し、整理し、言葉にしてお客様へ届ける。 その役割を担っていたのが、あの先輩だった。 ■ 報告書、会議、メール…見えない努力 報告書を作る姿は、正直「大変そう」だった。 会議の取りまとめ、メール、文書作成。 夜遅くまで、何度も推敲していたのを覚えている。 しかも後で知った。 その先輩、Javaは「あまり詳しくなかった」らしい。 それでもプロジェクトは、確かにコントロールされていた。 ■ 詰まった瞬間の“判断力” スケジュールが遅延しかけた時。 技術的に詰まった時。 先輩はすぐ別の人を呼び、ヘルプを入れていた。 抱え込まない。 決断が早い。 だからプロジェクトは前に進んでいた。 ■ ムードメーカーという、もう一つの役割 遅くまで作業が続いても、先輩はどちらかというと笑っていた。 場の空気を和らげる、ムードメーカーのような存在。 後になって、ようやく分かった。 プロジェクトの雰囲気づくりは、成果に直結する ということを。 ■ 少し先の未来を見ていた 「自分も、こういう役目になっていくのかな」 「こんなに忙しくなるのかな」 不安と期待が入り混じりながら、あの背中を眺めていた。 それは、自分のエンジニア人生の、少し先の未来を見ている感覚だった。 プロジェクトコントロールは、決して楽ではない。 でも、人と技術と時間を束ね、前に進める仕事だ。 今なら分かる。 あの先輩が、なぜあんなにも...

言語でも理論でもない。最後に立ちはだかったのは、意外すぎる“敵”だった うわっ、まさかそこ!?——今振り返っても、プログラミングで一番苦労したポイントは、当時の自分の想像を完全に裏切っていました。     ■ プログラムで一番難しかったのは何だろう？ 今では自動でできるようになったことも、昔は一つひとつが壁でした。大学時代、C/C++の分厚い本を常にカバンに入れ、電車の中でも、空き時間でも眺めていました。理解できない。読んでも腑に落ちない。それでも何とか分かろうとして、サンプルコードを何度も作り直す。コンパイルエラーと格闘しながら、頭を抱える日々でした。 ■ 社会人になって、Javaで「ジャバジャバ」 社会人になると、言語はJavaへ。ここで立ちはだかったのがオブジェクト指向です。「オブジェクト指向とは」という本が、完全にバイブルになりました。クラス、継承、インターフェース。理屈は分かるけど、なぜそう設計するのかが分からない。何度も読み返し、コードを書いては壊し、少しずつ感覚をつかんでいきました。 ■ DBは意外とシンプルだった 一方で、DBは思ったよりも分かりやすかった。スキーマの考え方さえ理解できれば、要は整理しているだけ。データをどう分類し、どう関連づけるか。ロジックというより、頭の中をきれいに整頓する感覚でした。 ■ オブジェクト・パターンとの格闘 デザインパターンは正直、苦戦しました。理解できないパターン、結局使えなかったパターンも山ほどあります。それでも「知っている」ことが後で効く場面は確実にあった。全部を使いこなせなくても、引き出しに入っていること自体が価値だったのだと思います。 ■ 本当に一番苦労したのは「空白」 そして、最終的に一番苦労したのは、まさかの「空白」でした。インデント、スペース、タブ。どのテキストツールを使うのが一番良いのか、という悩みも重要でした。IDE（統合開発ツール）の機能がどんどん拡張されていったのもこの頃。でも結局、シンプルで軽快なSakuraエディタが一番しっくりきた。気づけば20年以上使い続けているのは、ExcelとSakuraくらいです。 ■ いつの間にか、言語は増えていた 使えるようになった言語は、C/C++、Java、Cobol、JavaScript、Python、VB、...

デジタルの声が聞こえた日、世界の広さを知った うわっ、これは才能の差だ……!? 社会人になり、最初に味わった“圧倒的な敗北感”を、私は今でもはっきり覚えている。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ システム屋になると決めた日立でのスタート 私は「システム屋」として働くことを決め、日立に入社した。 当時は今ほど職種のカテゴリ分離が明確ではなく、システムエンジニアがインフラも担当し、プログラムやアプリケーションはプログラマーが担う、そんな時代だった。 そして私は、プログラマーを取りまとめる部署に配属された。 もちろん、フルスタックのプログラマーへの憧れも強かった。 ■ オブジェクト指向の熱狂と、Javaの時代 時代はオブジェクト指向真っ只中。 世界ではJavaが大規模アップデートを重ね、日本では「Cobolは終わる」と叫ばれていた。 「Javaを極めれば、プログラマーのトップを目指せる」 そう信じ、私は日々、徹夜でコードを眺め続けていた。 ■ 見つからない“何か” ある日、別のプログラマーからヘルプが入った。 「うまく動かない。でも、どこにバグがあるかわからない」 私も他のメンバーも加わり、必死にコードを追った。 確かにおかしい。でも、原因が見えない。 スペースが潜んでいる？ 半角・全角の問題？ 目を皿のようにして、ひたすら確認を続けた。 「いや、これ…ムズイ……」 そんな言葉が、心の中に浮かびかけた瞬間だった。 ■ 「見つけた」の一言 静まり返った中で、一人の同期がつぶやいた。 「見つけた」 大学卒の、まだ若い女の子だった。 毛布をかぶってパソコンを眺めている姿が印象的な彼女が、その難解なバグをあっさり見つけたのだ。 「え？なんで？どうやって？」 誰もが不思議がった。 彼女は少し照れたように、こう言った。 「声が聞こえた」 「……？？？」 ■ 才能という現実 衝撃だった。 これがデジタルネイティブ。 これが才能。 私には、どうしても“デジタルの声”は聞こえなかった。 入社1年目にして、プログラマーとしての限界を知った瞬間だった。 でも同時に、世界の広さを知った日でもあった。 ■ だから、次の道を選んだ 向いていないと知...

動かない…… あの日の感覚は、今でも指先が覚えています。 システム屋人生の中で、最も強く残っているのは、やっぱり“最初に世の中に出したシステム”。 銀行の裏側で、今もあのコードが生きてるかは分からないけれど、街中でそのサービスの画面を見ると、つい立ち止まってしまう自分がいます。 構想より、完了を見届けたほうが記憶に残る これまで大小さまざまなプロジェクトに関わってきました。 3年越しのものもあれば、半年で終わった案件もあります。 でもやっぱり、 「最後までいたプロジェクト」 ほど記憶に強く残ります。 そういう意味では、開発側にいたときの経験は大きかった。 Deloitteでは構想フェーズ中心で、作り上げる楽しみや思い入れはやや薄かった気がします。 日立時代、みんなで夜通し働いてローンチにこぎつけた案件――あれは特別でした。 でも、もっとも鮮明に思い出されるのは、 最初のリリース当日のこと 。 お客様先で、夜通し“立ちっぱなし”だった日 銀行向けの新システム、ローンチ当日。 私は現地に出向き、稼働状況の確認を任されていました。 でも、予定の時刻を過ぎても、動かない。 実際の障害箇所は自分の担当範囲じゃなかったんですが、立ち会っていた手前、「自分が責任を取らねば」と思い込んで、報告もできず、席にも座れず。 「座ってくださいよ」 と何度か言われたけれど、なんだか申し訳なくて、立ち続けてしまいました。 時間は刻一刻と過ぎ、深夜から明け方へ。 そして、 午前6時、「動きました！」の一言 。 思わず肩の力が抜けて、そこからやっと社内に報告を入れに戻ることができました。 緊張と不安と、でもそれ以上の達成感。 あの体験が、僕のシステム屋としての“原点”かもしれません。 今は画面が変わっていても、記憶は生き続ける その銀行の画面も今ではすっかり刷新され、あの時のUIは残っていません。 でも、 裏側の処理やロジックのどこかに、当時のコードがまだ動いているのかもしれない と思うと、なんだか誇らしい気持ちになります。 街で見かけるたびに、「あの日、立ってたな……」とちょっとだけ胸を張って振り返っています。 アンケートでおこづかい稼ぎ   自宅でできるフィットネスサービス SOELU(ソエル)   私ならできる...