Digital Heroes: Guide to IT World

えっ、私が「発注する側」に行くの？ 入社8年目。 それまでの私は、ひたすらシステム構築をやってきた。 要件を聞き、設計して、開発して、テストして、リリースする。 一つのプロジェクトが終われば、また次のプロジェクトへ。 そんな仕事を繰り返していた。 ▼開発会社選びに悩んでいる方はこちら   ある日、突然「お客様側」へ 当時、私はある会社から発注を受ける立場で仕事をしていた。 周囲を見ていると、発注しているベンダー側に出向している人が何人かいる。 「へえ、そういう働き方もあるんだな」 そんな程度に思っていた。 ところが、ある日。 「山口さんにも、出向の話があります」 ドキッとした。 ついに自分にも来たか。 でも、話を聞いてみると、これまで見ていた出向とは少し違う。 私は、 お客様側に出向する というのだ。 「お客様側？」 「発注する側？」 「システムを企画する側？」 頭の中に「？」がいくつも浮かんだ。 今までとは、明らかに立ち位置が違う。 「作る」から「会社全体を見る」へ 幸い、そのポジションには前任者がいた。 だから私は、まず前任者の話を聞くことにした。 そこで分かってきたのが、IT企画部の仕事だった。 システムを作ることだけが仕事ではない。 会社全体のITが今どうなっているのか。 どんなシステムが存在しているのか。 どんなリスクを抱えているのか。 これから何を変えていく必要があるのか。 つまり、個別のシステムを見るのではなく、 会社全体のITを俯瞰して考える仕事 だった。 既に大きなプロジェクトは終わっていた。 だから、これからは管理が中心。 そして、次のプロジェクトの計画も始めなければならない。 「なるほど……。これまでとは全然違うな」 少しずつ、仕事の輪郭が見えてきた。 「2年間」という長さに驚いた そして、この出向には一つのルールがあった。 前任者も2年間。 そして、私も2年間。 泣いても笑っても、2年間で終わり。 「2年間か……」 正直、ちょっと長い気がした。 それまで私が関わってきたプロジェクトは、3カ月から1年程度。 短いプロジェクトをいくつも動かしてきた私にとって、同じ場所で2年間というのは、なんだか奇妙だった。 でも、よく考えてみると、やることはいっぱいありそうだった。 会社全体のITを理解する。 リスクを把握する。 ベンダーと調整する。 経...

システムを作る側から、システムを「つなぐ側」へ 「えっ、今回はアプリを作らないの？」 今回のシステム開発プロジェクトが始まったとき、少し意外な展開になった。 実は、今回のシステム開発では、自分の部署はそれほど出番がなかった。 というのも、今回導入するシステムは、すでに完成している。ゼロからアプリケーションを開発するのではなく、完成したシステムを日本のビジネス環境に合わせて導入していくプロジェクトだった。 もちろん、話はそんなに簡単ではない。 新しいシステムが突然やってくれば、それまで使っていた周辺システムとの間に「Interface」という問題が発生する。 当然、各周辺システムには改修が必要になる。 「システムは完成しています」 そう言われても、周りのシステムからすれば、 「いやいや、急に新しいものが来たんですけど……」 という話だ。 こうして、Interfaceに四苦八苦するプロジェクトが始まった。 「作る」より「理解する」が仕事になった その周辺システムを作っているのが、私の部署だ。 最初は、今回のシステム導入でも、当然アプリケーション構築が必要になると想定していた。 ところが、システムを理解していくと、少しずつ見え方が変わってきた。 そのシステムは、想像以上に柔軟だった。 Config、つまり設定によって、多彩な調整ができる。 つまり、プログラムそのものを書き換えなくても、多くの要求に対応できる仕様になっていた。 さらに、今回はビジネス側も新しいシステムに合わせて業務を作り込んでいく。 そのため、「日本のビジネスに合わせてシステムを大幅改修する」という場面も、当初想定していたほど多くはなかった。 では、大規模アプリケーション製造部隊にいる自分に、何ができるのか。 そこで役立ったのが、これまで身につけてきた「英語」と「システム」の両方だった。 フルスタックを超える人には、まだかなわない もちろん、世の中には、システムを深く理解し、設計し、実装し、英語でコミュニケーションまで完結できる「フルスタックを超える」ようなメンバーがいる。 正直、そこにはまだかなわない。 でも、自分にはできることがある。 システムの仕様を理解しながら、英語のドキュメントを読み込む。 技術的な意味を理解する。 そして、それを日本のメンバーが理解できる形に翻訳する。 気がつけば、今回の主な作業...

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

新人研修プロジェクトが教えてくれた「逃げられない現場」 うわっ、まさかこのタイミングで!?――社会人2年目に入ったばかりのある日、私は思わず声にならない声を漏らしました。 任されたのは、新人向けの研修プロジェクト。しかも「ほぼ担当すべて」を任される形です。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       社会人2年目、役割が一気に変わった日 昨年までは、先輩の背中を追いながら必死に食らいつく立場でした。 でも2年目になった瞬間、状況は一変します。 「今回は君がメインで進めてほしい」 その一言で、プロジェクトの重みが肩にのしかかりました。 準備期間は1か月、条件はなかなか厳しい 準備期間は約1か月。 担当は、経験豊富な女性の先輩と私の2人。 サポートとして何人か頼れる先輩はいるものの、同じチームの先輩は技術屋ではなく、さらにお子さんが小さく、勤務時間は10時から16時の短時間勤務。 つまり、実質的に「自分がやらないと、後がない」状況でした。 CosminexusとHiRDB――情報が少ない現実 課長から示された方針は明確でした。 「去年の研修資料を使いつつ、サーバ構成は大幅に変える。基盤は日立のCosminexus、DBはHiRDBでいこう」 Cosminexusは昨年少しだけ勉強したことがある。 HiRDBもDBだから、Oracleと似ているはず。 そう自分に言い聞かせましたが、ネット上の情報は驚くほど少ない。 救いだったのは、社内システムなのでマニュアルだけは手に入ることでした。 やることは多い、でも立ち止まれない 環境構築、設定確認、動作検証。 ドキュメントも一部は作り直し。 タスクは山積みで、毎日が判断の連続です。 「これで本当に大丈夫か？」 冷や汗をかきながらも、不思議と逃げたい気持ちはありませんでした。 冷や汗の先に芽生えたもの 気づけば、責任感がはっきりと芽生えていました。 与えられた条件は確かに厳しい。 でも、やらないと前に進まない。 誰かがやるのを待つより、自分がやる。 社会人2年目で初めて、「任される側」の覚悟を持てた気がします。 この経験は、きっとこれから先の自分を支える土台になる。 そう信じて、今日も一歩ずつ積み上げていく。 ...

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

イメージできないから難しい、でも知ればグッと近づける“構築の世界” 「えっ、ATMって、あんなに気軽に使えるのに、作るのってそんなに大変なの!?」 ある会議で、非エンジニアの同僚が放った一言に、私たちは笑いながらも大きくうなずきました。 システム構築。 それは、言葉にすると簡単ですが、実はとても奥が深くて、そしてとても“見えにくい”仕事です。 ATMはどう作るのか？ Yahoo!のWebページはどう設計されているのか？ そもそも、システムってどうやって生まれるのか？ 多くの人にとって、それは「黒い画面で何か入力してる世界」でしかありません。 「家はどうやって作るか、想像できますか？」 突然ですが、住宅建築を思い浮かべてみてください。 ・土地を整える ・基礎を打つ ・柱や梁を組み立てる ・電気や水道を引き込む ・内装を整える 建てるのに1年、場合によっては2年かかることもあるでしょう。 工程が分かれていて、担当も別々、進捗管理もとても大変。 実は、システム構築もそれと同じなのです。 「システム構築」＝「建築プロジェクト」説 企業の業務システムや銀行のATMネットワークは、まさに“オフィスビル”や“商業施設”を建てるようなものです。 地盤固め（ネットワーク設計） 基礎工事（サーバーのセットアップ） 躯体工事（プラットフォーム、ミドルウェアの導入） 電気工事（各システムの連携設定） 仕上げ工事（業務アプリケーション開発） このように、工程は順を追って積み重なり、どこかが崩れれば全体が崩れます。 もしも連携部分がうまくいっていなければ、画面は表示されても取引は失敗するでしょう。 これが、“欠陥住宅”ならぬ“欠陥システム”です。 「保証期間」と「引渡し前検査」もある世界 さらに、完成後には「検収（引渡し前チェック）」という儀式が待っています。 ここで漏れがあると、正式運用後に問題が起きても「それ、対応外です」と言われてしまうことも…。 だからこそ、細かな仕様の確認、調整、テストがとても重要になります。 「イメージできる」だけで、世界が変わる 「システムって難しい」 確かにそうかもしれません。 でも、「建物を建てるようなもの」とイメージできるだけで、ぐっと理解が深まるはずで...

やばい…また不採用だ… 面接のたびに撃沈し、自信を失いかけているあなた。もしかして「自分の強み」を伝えられていないのでは？ 実は、中途採用のIT市場では 「どんなプロジェクトをやったか？」 ではなく、 「自分が何をしたか？」 が超重要なんです！今回は、転職市場で本当に求められるスキルと、内定を勝ち取るための話し方を伝授します！ 📌 求められるのは"チームの成果"じゃない！"個人の成果"だ！ 転職活動で面接官が知りたいのは、「この人がうちの会社に来たら、どんな貢献をしてくれるのか？」ということ。そのために必要なのは、 「自分がどんな立場で、何をして、どう成果を出したのか」 を明確に伝えることです。 例えば、こんな話し方をしていませんか？ ❌ 「5人のチームでシステム開発をしました。結果、無事に納期通りリリースしました！」 この話し方では、「で、あなたは何をしたの？」と突っ込まれるのがオチ。大事なのは、 チームの成果ではなく、自分がどう関わったのかを話すこと！ ✅ 「私はバックエンドのAPI設計を担当し、データベースとの連携を最適化しました。特に、クエリのレスポンスを平均40%短縮し、パフォーマンス向上に貢献しました。」 こう話せば、一気に「できる人」感が増します！ 📌 具体的に語れる人が勝つ！STARフレームワークを活用せよ！ プロジェクトの話をする際に役立つのが、「STARフレームワーク」です。 STARとは？ S（Situation：状況） → どんなプロジェクトだったのか？ T（Task：課題） → 自分に与えられた課題は？ A（Action：行動） → 具体的に何をしたのか？ R（Result：結果） → どんな成果が出たのか？ 例えば、こんな風に話せます👇 🔥 「レガシーシステムのクラウド移行プロジェクト（S）で、オンプレ環境からAWSへ移行する際のパフォーマンス最適化（T）を担当しました。具体的には、LambdaとDynamoDBを活用し、クエリレスポンスを平均40%改善（A）。結果、システムの応答速度が大幅に向上し、ユーザー満足度も上昇しました（R）。」 面接官はこのような具体的なエピソードを求めています！ 📌 転職は"相性"！落ち込む必要なし！ 何社受けても、不採用が続...

やばい…システム乱立でカオス！ これは、多くの企業が直面しているリアルな問題です。営業部門が選んだCRM、経理部門が導入した会計システム、現場が使いやすいと判断した管理ツール…。気がつけば、各部署がバラバラにITを導入し、つながらないデータ、増え続けるコスト、複雑化する運用が企業全体の足かせになっている。 その結果？ ベンダーの言いなり！ 「このツールが便利ですよ」「最新のクラウドサービスを入れましょう！」と次々に提案されるままに導入。結局、システムが増えるばかりで、最適化されるどころか、逆に業務が複雑になってしまう…。 この状況を打破するために必要なのが、**Enterprise Architecture（EA：エンタープライズアーキテクチャ）**の考え方です。 EAとは？企業ITの"設計図" EAとは、簡単に言うと 「企業全体のITの設計図」 です。 例えば、家を建てるとき、 どこに何の部屋を作るのか？テレビは何台必要か？古い冷蔵庫はそのまま使うか？新しいものに買い替えるか？ といった全体の計画を立てますよね。 企業も同じ。 どのシステムを使い、どのデータを統合するか？ 古いシステムは廃止するのか？ 最新のテクノロジーは本当に必要なのか？ こうした戦略をしっかりと設計するのが、 EAの役割 なのです。 EAの目的は「DX」ではない！ 最近のトレンドとして「DX（デジタルトランスフォーメーション）」が叫ばれていますが、EAの目的はDXそのものではありません。企業の最終的なゴールは、 「利益を上げ、コストを下げること」 。 DXはあくまで手段であり、「最新技術を使うこと」自体が目的ではないのです。 むしろ、無駄なシステム投資を削減し、統合や最適化を進めることで 「最小のコストで最大のパフォーマンスを発揮できる企業IT」 を実現することが、EAの本質です。 EAの視点を持つエンジニアは少ない！ 残念ながら、日本企業で EAの観点を持っているエンジニアは本当に少ない のが現実です。 多くのエンジニアが、 システム単位での最適化 には目を向けるものの、 経営全体の視点でITを考える ビジネス戦略とITをつなぐ こうした視点を持っている人はほとんどいません。 だからこそ、EAを理解し、企業のために 本当に必要なITを考えられるエンジニア の価...