Digital Heroes: Guide to IT World

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

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

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

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

「ユーザーの、その先」を考える仕事に出会った2年目後半〜3年目 うわっ、こんな“底”まで考えるのか!? 社会人として、日立人として2年目の後半から3年目にかけて、私はプラットフォーム構築という仕事に携わった。 当時の私は、「システムはユーザーが使うもの」という考えを当然の前提として持っていた。     ■「お客様」だけでは終わらない視点 しかし、プラットフォームの世界は違った。 そこでは、システムを“要求するお客様”だけでなく、 その上でシステムを作る人 のことまで考えなければならない。 ユーザーのさらに奥、もっと奥底を考える——それは、私にとって初めての、そして特殊な経験だった。 ■見えないところで起きていた競争 当時、サーバ構築競争があり、DB構築競争があった。 日立には、Cosminexusというサーバ製品、HiRDBというDB製品、JP1という運用管理製品がある。 そこに、JustwareがJavaのプラットフォームとして入り込んでいく。 Globalで勝てている日本発のソフトウェア製品は多くない。 日本では、大企業がそれぞれ競争している。 そんな厳しい世界の中に、少しでも関われたこと自体が、今振り返ると本当に貴重だった。 ■JavaとO’Reillyと、終わらない理解 プラットフォーム構築には、Javaの深い理解が不可欠だった。 机の横には、分厚いO’Reillyの本。 何度読んでも意味不明。 「これを理解して実装している人がいるのか…」 レベルの差を、嫌というほど感じた。 一時期、O’Reilly本が並ぶコーナーに何時間も立ち読みしていた。 一冊何千円。簡単に買えない。 でも、ネットより情報が正確だと信じられた。 コードを頭に叩き込み、本屋を出たらすぐメモ。 家に帰って実装。そんな日々だった。 ■天才と限界と、不安 プロジェクトでは、数人の天才がプラットフォームをリードしていた。 会話はマニアを超え、もはや異次元。 「ここでやっていけるのか？」 不安と、「でも、やらないと！」という気持ちに押される毎日。 この仕事は、間違いなくプロフェッショナルで、そして難しい。 だが同時に、 ものづくりの最深部を覗いた経験 でもあった。 ■今だから言えること プラットフォー...

設計書の先にあった“リアルな価値”を見た日 うわっ、これ……本当に自分が作ったやつだ！ 画面の向こうで、エンジニアの方々が当たり前のように操作しているその仕組みを見た瞬間、胸の奥がじんわりと熱くなりました。 ■ 初めて「使われる現場」を見に行った日 それは、私が関わって作ったプラットフォームが、初めて実プロジェクトで使われた証券会社様の案件でした。 プロジェクトリーダーは、人を引っ張る力が本当に強い先輩。迷いなく前に進み、周囲を自然と巻き込んでいく姿が印象的な方です。その先輩から「一度、現場を見に来たらいいよ」と声をかけてもらい、私はプロジェクトの現場を訪れました。 ■ 設計書が“動く瞬間” そこでは、私が作ったプラットフォームを使い、エンジニアの方々が実際に設計書を書き、そこからプログラムを自動生成し、システムを構築していました。 扱っているのは、システム間連携に関わるプログラム。頻繁に作られるものではありませんが、重要なシステム同士をつなぐ、いわば要の部分です。 ■ 今とは違う、当時のシステム連携 今でこそAPI連携は当たり前で、システム同士は軽やかにつながります。しかし当時は違いました。 まずはサーバ間でシェイクハンズ。 その後、データをメッセージに乗せて送信する。 ヘッダーとフッターを持ち、ペイロードに重要なデータが詰め込まれる——そんなデータ構造が“普通”の時代です。 私は、その「基本のキ」をしっかりと実現できるプラットフォームを目指し、必要な考え方や仕組みを詰め込みました。 ■ 「よく分かってるね」の一言 現場で使っていたプログラマーの方々は、さすがでした。 自由度を高めた私の設計意図をすぐに理解し、柔軟に使いこなしてくれていたのです。 そして、ふとした会話の中で言われました。 「これ、すごく使いやすいですね」 その言葉は、先日、例の先輩が私に伝えてくれた言葉とまったく同じでした。 胸の奥で、何かがストンと落ちた気がしました。 ■ お客様に認められるということ ああ、これが“お客様に認められる”ということなのか。 自分の作ったものが、誰かの仕事を支え、自然に使われ、価値として受け取られる。その瞬間に立ち会えたことが、何よりの報酬でした。 ものづくりって、やっぱり面白い。 システムづくりも、間違いなくも...