Digital Heroes: Guide to IT World

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

見えない土台が、すべてを決めていた うわっ……鼻を突くたばこの匂いと、重たい空気！ 2010年が近づいていたある頃、私は東京の主要駅近くにある、とある開発現場へ向かっていた。交通の便は悪くない。むしろ、有名な“満員電車路線”の駅だ。ぎゅうぎゅうの電車に揺られて辿り着いた先は、日本の金融の大元を司る会社のシステム開発ルームだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ミスが許されない、極限のシステム そのシステムは、長年にわたり** 日立 **が受けてきたもの。 ミスるわけにはいかない。 もし一つでも誤れば、影響は金融業界全体に及ぶ。 下手をすれば、翌日の新聞に載る。 そんな、緊張感の塊のようなシステムだった。 舞台は“理想”から程遠い場所 だが、その重要システムが作られていた場所は、驚くほど古かった。 開発ルームの一角は薄暗く、たばこの匂いがぷーんと漂う。 絨毯は年季が入り、色もくすんでいる。 正直、モチベーションが上がる環境ではない。 それでも仕事は始まる。 絨毯をめくり、さらにその下のOAフロアを持ち上げ、ネットワーク配線に手を入れる。 机は片足が折れ、隣の机にもたれかからせて、なんとか形を保っているものもあった。 社員3人、あとはベンダーという現実 話を聞くと、常駐している社員はわずか3人ほど。 あとは複数社のベンダーさんたちだ。 社員の役割は、開発方針を語ることよりも、 「環境を整える」「サーバを配置する」「パソコンを用意する」こと。 驚いたのは、パソコンが割り当てられていない開発者がいたことだ。 光の入らない部屋に人が密集し、最低限の設備を奪い合うような状態。 それでも、日本の基盤を支えるシステムは、確かにここで作られていた。 環境整備も、立派なプロジェクト この現場で痛感した。 環境整備は“前段”ではない。 それ自体が、成功を左右する プロジェクトそのもの だということを。 どれほど優秀な設計書があっても、 どれほど優れたエンジニアがいても、 環境が整っていなければ、成果は最大化しない。 見えないところを整える人がいるからこそ、 表に出るシステムは、静かに、確実に動き続ける。 私ならできる！明日から踏み出す

恵まれた環境が“普通”だった私が、現場で学び直したこと うわっ！世界が一気に切り替わった——まるでタイムスリップだ。 これが、私が新しいシステムプロジェクトに足を踏み入れた瞬間の正直な感想だった。     ■ 本社プロジェクトという“標準” これまで私は、本社主導のプロジェクトが当たり前だった。30階を超える最新ビルの一室。フリーアドレスの机にPCを広げ、内装は洗練され、食堂もある。買い物は基本、1階のコンビニで完結する。でも、駅を越えれば活気ある商店街。 ——正直、恵まれた環境だった。そして、それが“普通”だと思っていた。 ■ 新しいプロジェクト、東京の反対側へ そんな私が、今度はお客様のプロジェクトに入っていくことになった。場所は、東京の反対側。関係会社の1フロアを借りているというオフィスだ。 入口はきれい。6階建てで新しくはないが、整然としている。私たちのフロアは5階。エレベーターを降りた瞬間、少しだけ胸がざわついた。 ■ 衝立の向こうにあった“現実” 衝立で区切られた突貫の入口。後で知ったが、会社が違うためのセキュリティ対策だった。その扉を開けると—— 古い机。ぷーんと漂うタバコの匂い。絨毯は、正直きれいとは言えない。窓は開いておらず、段ボールが積まれて光が入らない。 「なるほど、これが現場ってやつか……」 思わず身震いした。 ■ “現場”は条件じゃない、覚悟だ だが、ここにはリアルなエンジニアがいる。制約の中で手を動かし、システムを止めないために知恵を絞る人たちがいる。 私はここで、彼らをサポートしていく。環境の良し悪しではない。必要なのは、寄り添う覚悟と、現実を直視する勇気だ。 ガラス張りの世界を出て、初めて見えた景色がある。 私ならできる！明日から踏み出す

「答えを出す仕事」だと思っていた自分が、最初に突きつけられた問い うわっ……思っていた“コンサル”と、ぜんぜん違う！ そんな感嘆にも似た違和感を覚えたのは、社内コンサルとして証券系のプロジェクトにアサインされた、その初日だった。     ◆ 社内コンサルとして現場に入るということ 社会人になって二度目の「お客様プロジェクト」。 場所は、少し年季の入った古いビル。中には複数のプロジェクトが同時に走っていて、独特の緊張感が漂っていた。 そこでふと浮かんだのが、 「……で、私は何をコンサルすればいいんだ？」 という、根本的な問いだった。 ◆ 求められていたのは“答え”ではなかった 私に求められていた役割は、Justwareそのものの使い方だけではなかった。 Justwareを どう設計し、どう各プロジェクトフェーズに適用していくか 。 要件定義、設計、開発、テスト——それぞれの段階で、どんな設計思想を持つべきか。 その考え方を整理し、支えることだった。 ◆ 説明する相手は「新人」ではない 数人規模の説明会。 やっていること自体は、新人向けにこれまで何度も説明してきた内容と似ていた。 でも、目の前にいるのは各社のプロフェッショナルエンジニアたち。 顔つきが違う。 空気が違う。 「下手したら、鋭く突っ込まれるかもしれない」 そんな、恐怖に近い感覚すらあった。 ◆ 自分が作ってきた“プラットフォーム”を語る 説明したのは、これまで自分が関わり、作ってきたプラットフォームの考え方。 Justwareを“どう使うか”ではなく、 「なぜ、そう設計してきたのか」 「どんな失敗と改善を重ねてきたのか」 話しながらも、心のどこかで不安が消えなかった。 「本当に受け入れてもらえるだろうか？」 ◆ 今思えば、それは杞憂だった 振り返ってみれば、その不安の多くは杞憂だった。 ちゃんと向き合えば、プロはちゃんと聞いてくれる。 もっと自信を持っても、良かったのかもしれない。 でも当時の自分は、それだけ真剣だった。 だからこそ、その現場に真正面から入っていく覚悟ができたのだと思う。 ◆ 違和感は、成長のサイン 「コンサルとしての違和感」。 それは、役割が変わり、視座が一段上がったサインだった。 答えを出すだけ...

プロジェクトの“間”をつなぐ人、それが社内コンサルタント うわっ!? 会社の中だけで、こんなに世界が違うのか！ 入社してしばらく経った頃、私は強烈な違和感と同時に、妙なワクワクを覚えていました。舞台は、巨大企業である 日立 。想像以上に広く、想像以上に多様なプロジェクトが、同時多発的に社内で動いていたのです。     ■ 巨大企業の中は、小さな会社の集合体 日立の中では、実に多くのプロジェクトが走っていました。 サーバ構築プロジェクト、プラットフォーム構築プロジェクト、お客様のシステム構築プロジェクト、既製品の販売プロジェクト——。それぞれが独立しているようで、実は密接につながっています。 ■ “多段サポート”という見えない構造 社内では、多段でお客様をサポートする構造がありました。 お客様のシステム構築プロジェクトを、プラットフォーム構築プロジェクトが支える。 そのプラットフォーム構築プロジェクトを、さらにサーバ構築プロジェクトが支える。 私は、その中でプラットフォーム構築プロジェクトの末端を担っていました。 ■ 採用の瞬間、立場が変わる ある日、そのプラットフォームが実際にお客様のプロジェクトで採用されました。 「使うことになったから、誰かサポートに行かなければいけない」 当然の流れです。プラットフォームは、何の説明もなく簡単に使えるものではありません。使い方を教え、支え、プロジェクト間をつなぐ人が必要でした。 ■ 社内コンサルタントという役割 こうして私は、“社内コンサルタント”的な立場でプロジェクトを支援することになります。 実は、私のプラットフォームプロジェクトからも、すでに何人かがお客様プロジェクトへ出ていました。そして次は、自分の番。 お客様に近い場所で、システム開発に関わる。 「もっとお客様の気持ちを知りたい」 そう思っていた私は、少し背筋を伸ばしながら、新しい環境へ足を踏み出しました。 ■ 新しい現場、新しい緊張 環境が変われば、見える景色も変わります。 ちょっと気が引き締まる感覚。 それでも、不思議と前向きでした。 また新しい環境でのシステム開発が始まる——その期待が、私を動かしていたのです。 私ならできる！明日から踏み出す

世界標準と向き合った日本企業の挑戦と誇り うわっ、相手がデカすぎる……！ 日本の企業が、プラットフォーム開発という巨大な競争の渦中にいた時代があった。 各社が商用のサーバやDBを開発し、世界標準という“とてつもなく大きな存在”に正面から向き合っていった。 ■世界標準に追いつけ、追い越せ 正直に言えば、対応が後手に回ってしまったこともある。 すでに世界に広く普及していた巨大なプラットフォームに対し、日本の製品は「後発」だった。 それでも、日本企業の技術には確かな強みがあった。 説明書は丁寧で、使う人に優しい。 Oracleなど、世界的に使われている製品にありがちな“変な癖”が少なく、素直な設計が多かった。 ■中立性という、静かな強さ 実際、DB技術者と話すとよく聞いたのが、 「日立のHiRDBは、OracleやSQL Server、DB2と比べても、非常に中立性を保った設計だ」という声だった。 特定の思想や使い方に縛られすぎない。 だからこそ、安心して長く使える。 派手さはないが、堅実で、真面目な技術だったと思う。 ■日本の技術は“育つ”もの 日本の技術は、先行して勝つタイプではない。 最初から世界を席巻するよりも、 後から改良に改良を重ねて育っていく 。 それは、ものづくりの文化そのものだ。 では、プラットフォームはどうなったのか。 正直に言えば、世界標準の大きさには勝てなかった。 ■なぜ、色が薄くなったのか 理由は一つではない。 クラウドやオープンソースの波があまりにも大きかったこと。 価格が高すぎたこと。 マーケティングが弱かったのかもしれない。 あるいは、日本企業同士が競争しすぎたのかもしれない。 実際、IBMですらOracleに勝てていない。 「何が刺さるのか」を見極めるのは、それほど難しい。 ■それでも、私は信じている それでも、私は自信を持って言える。 日本の企業は、良いものを作ろうと本気で頑張っている。 そして、技術者はいつの時代も、常に前を向いている。 勝ち負けだけでは測れない価値が、確かにそこにあった。 その現場を知れたことは、今も私の誇りだ。 私ならできる！明日から踏み出す