Digital Heroes: Guide to IT World

Whoa—does work have any meaning if you never see it through to completion!? That question crossed my mind at the end of my seventh year as a working professional. Seven Years on the Frontlines As I approached the end of my seventh year, I had been involved in numerous projects—some large-scale, others smaller. I belonged to an application development team, the unit brought in when large system development was required among the many deals frontline SEs brought back. Plenty of Work, but Few Lead Roles There was no shortage of work. PC replacements, network construction. But among them, system development projects had the greatest impact. The budgets were on a completely different scale. That’s why people gathered—and just as quickly, they left. I was one of them. What Does “Staying Until the End” Mean? Naturally, there were projects I stayed with until the end, and others I left midway. But what exactly does “the end” mean? Does it include operations? Or does it stop at production ...

 ・COBOLからJavaへ、その“当たり前”が崩れた日 ・テストケースは消えない資産か、それとも負債か ・量で品質を作る日本的開発のリアル えっ、まだ増えるの！？テストケースが雪崩のように積み上がる金融現場で、誰も笑えなくなった。 ■金融システムは「テストケースが多い」が前提 金融系のシステム構築では、そもそもテストケースが多い。それは常識だ。 勘定系、決済、残高、与信。どれも一つのミスが数億円の事故になる。 だからこそ「テストは多すぎるくらいでちょうどいい」という文化がある。 ■COBOL資産は“何十年分のテストの塊” 今回のプロジェクトは、COBOLで動いていた基幹システムをJavaへ全面刷新するものだった。 COBOLの世界では、何十年もかけてテストケースが積み上がっている。 それは単なるチェック項目ではない。 過去の障害、例外処理、業務のクセ、現場の“痛み”そのものだ。 そして重要なのは、 プログラム言語が変わっても、そのテストケースは消えないということだ。 業務ロジックは変わらない。だから本来はそのまま使える。 ■ただし「そのままでは使えない」 しかし現実は単純ではない。 COBOLからJavaへ移行すると、気にしなくていい領域が出てくる。 たとえばメモリ管理。 これはJavaのガベージコレクションに任せられるため、関連テストはごっそり不要になる。 またエラーハンドリングも構造が変わるため、テスト観点の再設計が必要になる。 一方で、業務ロジック自体は変わらない。 そのため多くのテストケースは“ほぼ流用可能”でもある。 ■結果：テストケースは約1万弱 こうして整理された結果、残ったテストケースは約1万弱。 多いのか少ないのか、現場では誰も断言しない。 ただ一つ言えるのは、「終わりが見えない量」であることだけだ。 ■テストは美しいほど順調に崩れる テスト開始直後は順調だった。 簡単な正常系が次々に通る。 まるで教科書に出てくる消化曲線のように、きれいに進んでいく。 しかし、その曲線は必ずどこかで止まる。 そしてその瞬間が来る。 ■どん詰まりは突然やってくる ある地点を超えた瞬間、テストは止まる。 原因は単純ではない。 ・仕様の解釈違い ・COBOL特有の癖 ・J...

The Day “Business as Usual” Broke: From COBOL to Java Are Test Cases an Asset That Never Dies—or a Growing Liability? The Reality of Japan’s “Quality Through Volume” Development Wait—are there still more!? In a financial system project where test cases pile up like an avalanche, no one is laughing anymore. ■ Financial Systems Assume “A Lot of Test Cases” In financial system development, having a large number of test cases is the norm. Accounting, payments, balances, credit—any single mistake can lead to losses worth millions. That’s why there’s a deeply rooted belief: “Too many tests is just enough.” ■ COBOL Assets = Decades of Accumulated Tests This project aimed to fully replace a core system built in COBOL with Java. In the COBOL world, test cases have been accumulated over decades. They are not just checklists. They represent past failures, exception handling, business quirks— the very “pain history” of the system. And most importantly, those test cases do not d...

うわっ、キーボードよりも先に“箸”が動く職場って、どういうことだ！？ ■ 社会人7年目、チームができた日 社会人7年目にもなると、気づけば後輩が増えていた。 そして、ある日を境に「同じチーム」として、彼らは“部下”になった。 最初は正直、どう関わればいいか分からなかった。 コードレビュー、進捗管理、障害対応——それだけでは足りない。 システム開発は個人戦ではなく、完全なチーム戦だ。 そこで自然と増えていったのが、「ランチ」と「飲み会」だった。 ■ 江東区という“選択肢の暴力” 勤務地は江東区。 ここがまた厄介で、周りに美味い店が多すぎる。 有名なラーメン店、コスパ抜群の中華、少し歩けばホテルランチ。 選択肢が多いというのは、意思決定力を試される環境でもある。 個人で行くメンバーは早々に席を立ち、迷いなく中華に走る。 一方で、チームで行くときは「どこにする？」から始まる小さな会議。 気づけば私は、その“場”をデザインする側になっていた。 ■ システム屋は、お昼にかける 普段はパソコンと会話する時間が圧倒的に長い職種。 無機質な画面と向き合い続けるからこそ、人との接点は貴重だ。 だから、システム屋は“お昼にかける”。 これは単なる食事ではない。 ・チームの空気を読む ・後輩の本音を引き出す ・他チームとの関係を作る すべてが、昼の1時間に凝縮されている。 ■ ランチは、最小単位の組織開発 私は意識的に、他チームともランチに行くようにした。 開発は横断的な連携がすべてだからだ。 節目のタイミングでは、少し背伸びしてホテルランチ。 普段はコスパ重視で中華。 天気が良い日は弁当を買って公園。 忙しいときは、おにぎりとラーメンで5分で済ませることもある。 一見バラバラだが、すべてに共通する目的がある。 それは「会話を生むこと」だ。 ■ 矛盾：ご飯にこだわらない職種の本音 システム屋はよく言う。 「別にご飯にこだわりないですよ」と。 でも、それは半分嘘だ。 本当は、味ではなく“誰と食べるか”にこだわっている。 ご飯そのものではなく、ご飯を媒介にしたコミュニケーションに価値を置いている。 つまり、我々は“食事を設計している”のだ。 ■ あの頃、一番うまかったもの 振り返ると、いろんな店に行った。 ...

Whoa—what kind of workplace is this where chopsticks move before keyboards!? ■ Year 7: The Day I Had a Team By my seventh year as a working professional, I suddenly realized that more and more juniors had joined. And one day, they became part of “my team”—my subordinates. At first, honestly, I didn’t know how to engage with them. Code reviews, progress management, incident handling—those alone weren’t enough. System development isn’t an individual sport; it’s a complete team game. That’s when something naturally started to increase: lunches and team dinners. ■ Koto City: The Overwhelming Power of Choice Our workplace was in Koto City. And this is where things got tricky—there were simply too many good places to eat. Famous ramen shops, cost-effective Chinese restaurants, and even hotel lunches within walking distance. Having too many options is, in itself, a test of decision-making ability. Some team members would leave early and rush straight to their favorite Chinese spo...

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

Whoa… was this a job where you fight the floor before the keyboard!? ■ Is System Development Just Sitting at a Desk? “System development is basically writing code in front of a computer, right?” When I hear that, I pause for a moment. Yes, that’s part of it. But the reality on-site is far too gritty to be defined that simply. I’ve led and worked on multiple system projects. If anything, I’ve been more on the management side. But I’ve also written code. Built servers. Designed databases—of course. “What about networking?” —Of course, I’ve done that too. ■ Before Wi-Fi Was Everywhere Today, Wi-Fi is taken for granted. But 10+ years ago, it wasn’t. Development environments were mostly wired. You plugged blue LAN cables into HUBs. That was the foundation of infrastructure work. But reality wasn’t that clean. If everything was neatly blue, you were lucky. Yellow, white, and random old cables from who-knows-where— The site was chaos. ■ The Reality of a 200-Person Pro...

Whoa—there’s a world where you’ve already “lost” even when everything is running. That world is system development. ■7 Years In: Inside a 200-Person Project Over seven years as a systems engineer, I’ve led and supported numerous projects. One that stands out was a massive project with over 200 people. And it wasn’t just the scale—it was physically intense. “How do we fit 200 people into this tiny room?” That’s how discussions began. But that wasn’t the real issue. As people become more concentrated, so does system complexity. ■Configuration Management: The Invisible Controller As a configuration management lead, my role wasn’t direct development, but ensuring environmental stability. Working alongside programmers, server engineers, and network specialists, I realized something critical: “Building” and “sustaining” are completely different skills. ■True Professionals Are Defined by Less Programming is deep. But true professionals aren’t measured by the amount of code they write...

うわっ、動いてるのに“負け”が確定する世界がある——それがシステム開発だ。 ■社会人7年、200人プロジェクトの現場 社会人7年、私はシステム屋として数多くのプロジェクトを回してきた。中でも忘れられないのは、200人を超える巨大プロジェクトだ。しかも、ただ人数が多いだけではない。物理的にも過酷だった。 「この狭い部屋に200人、どう座る？」 そんな議論から始まる現場。だが、本質はそこではない。人が密集するほど、システムもまた“複雑さ”を増していく。 ■構成管理という“裏側の支配者” 私は構成管理担当として、開発そのものではなく、環境の安定を支える役割を担った。プログラマー、サーバ担当、ネットワーク担当——多様な専門家と関わる中で、ある事実に気づく。 「動かすこと」と「支えること」は、まったく別の能力だ。 ■プロの条件は“少なさ”に宿る プログラムの世界は奥深い。だが、真のプロはコード量で語らない。むしろ逆だ。 行数は少ない。コメントは的確。無駄がない。 “読める・書ける”だけでは、ただの作業者に過ぎない。 本質は「設計思想」と「再現性」にある。 ■サーバも同じ、動くかではなく“耐えるか” サーバ構成も同様だ。つなげば一応、動く。日常運用では問題ないかもしれない。 しかし、負荷が急増した瞬間—— その差は一気に露呈する。 耐える構造か、崩壊する構造か。 ここに“プロとそれ以外”の境界線がある。 ■議論：なぜ日本の現場は“動けばいい”に流れるのか ここであえて問題提起したい。 なぜ多くの現場は、「とりあえず動く」ことをゴールにしてしまうのか？ 納期、コスト、評価制度——理由はいくらでもある。 だが、それを言い訳にした瞬間、技術者としての成長は止まる。 ■システム屋に必須なメンタリティ システムの各領域は、それぞれが深い。プログラム、インフラ、ネットワーク——すべてが専門職だ。 だからこそ必要なのは、 「自分の領域に閉じないこと」 そして、 「学び続けること」 変化を前提に、自らをアップデートし続ける。 それができる者だけが、“プロ”として生き残る。 ■ビジネス示唆 これはエンジニアだけの話ではない。 企業も同じだ。 「今、動いている」ことに安心した瞬間、競争力は静かに失われる。 本質は、“未来の負荷”...

The Shock of “Engineers Who Don’t Code” What!? There are people who control systems without writing code— In my 7th year as a professional, I joined a large-scale development project with over 200 members as a configuration management leader. With five companies involved, I was responsible for creating various standards and guiding the entire team through structured rules. Among all roles, the one I worked most closely with was the server administrator. Configuration management and server management were the two wheels supporting the project. Naturally, our conversations increased. One day, I casually asked: “How much Java do you usually write?” The answer I got was unexpected. “Actually, I’ve never written it.” The “Language of Scripts” That Runs the Field Surprised, I asked further: “So… you don’t program at all?” He smiled slightly and replied: “Well, I do simple stuff.” What he referred to were shell scripts like Bash and Windows VB scripts. At that moment, the hidde...

「書かないエンジニア」という衝撃 うわっ!? コードを書かないのにシステムを支配している人がいる——。 社会人7年目、私は200人を超える大規模開発プロジェクトに構成管理リーダーとして参画していた。5社が入り乱れる現場で、各種基準書を整備し、チーム全体を“ルール”で誘導する役割だった。 そんな中、最も密に連携していたのがサーバ管理担当だった。構成管理とサーバ管理は、現場を支える両輪だ。自然と会話も増えていった。 ある日、何気なく聞いた。 「Javaとか、どれくらい書くんですか？」 返ってきたのは、予想外の一言だった。 「いや、書いたことないですね」 現場を動かす“スクリプトという言語” 驚いた私は、さらに聞いた。 「じゃあ、何もプログラムしないんですか？」 彼は少し笑って答えた。 「いや、簡単なものならやってますよ」 そこで出てきたのが、Bashに代表されるシェルスクリプト、そしてWindowsのVBスクリプトだった。 ここで、システムの“裏側の構造”が一気に見えてきた。 サーバは「JOB」という単位で管理される。処理はすべてスケジュールされ、自動化されている。そして、その統制を担うのがJP1だ。 しかしJP1は、単独では動かない。OSの機能を呼び出す際には、必ずスクリプトを介する。つまり、シェルスクリプトやVBスクリプトが“翻訳者”として、JOBの指示をサーバに伝えている。 システムは「3層」で動いている ここで整理すると、構造はこうだ。 ・全体統制：JP1（JOB管理） ・実行主体：各サーバ ・接続役：スクリプト（Shell / VB） そして、その上で我々のJavaなどのアプリケーションが動く。 つまり、派手なアプリケーションの裏側には、無数のスクリプトが存在し、それらがシステム全体を支えているのだ。 “小さなコード”がシステムを支配する 週次処理、バッチ処理、ログ取得、監視連携—— これらはすべて、小さなスクリプトの積み重ねで成り立っている。 大きなプログラムではない。だが、その数は膨大で、どれ一つ欠けてもシステムは止まる。 彼らの仕事は目立たない。しかし、確実に“全体を動かしている”。 エンジニアの価値はどこにあるのか ここで一つ、議論を投げかけたい。 「高度な言語で大規模なコードを書ける人...

What!? Engineers who don’t write code are supporting the system—I encountered such a reality on the ground. ■ Behind a Massive Project The project I was involved in had over 200 members. It was led by a core company supporting one of Japan’s central financial institutions. The mission was to transform one of its core systems from COBOL to Java—a true turning point of an era. I joined as a configuration management engineer. My role was to maintain consistency across massive amounts of source code, versions, and releases. I had written some Java programs myself, but my main battlefield was “keeping things in order.”     ■ The Unsung Hero Protecting the Environment In this environment, the people I worked closely with were the server engineers. Developers can write code with confidence only when the environment is stable—and it was the server team that sustained that foundation. As we naturally started talking more and grew closer, a question came to my mind one day. “Sinc...

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

Wow—there are moments when “human relationships” break down before the code does. ■ In a Massive Project In my seventh year as a professional, I was leading the configuration management team within a development organization. The project kept growing, eventually surpassing 200 members. Programmers, testers, infrastructure, operations—amid this complex mix of roles, our configuration management team was responsible for creating an “invisible order.” 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ Documents as “Blueprints” We produced an uncountable number of documents: Programming Standards Environment Setup Procedures Package Application Guidelines Deployment Manuals At first glance, it may seem like these could be reused via templates. But reality is different. Each client environment has unique conditions, and every detail must be rebuilt. In other words, configuration management is not about “copy-paste work”—it is “environment-adaptive architecture.” ■ Hitting a Wall...

うわっ、コードより先に“人間関係”が壊れる瞬間がある——。 ■巨大プロジェクトの中で 社会人7年目、私は開発チームの構成管理チームをリードしていた。プロジェクト規模は拡大を続け、ついに200人を超える体制へ。プログラマー、テスター、インフラ、運用——あらゆる役割が入り乱れる中で、私たち構成管理は「見えない秩序」を作る役割を担っていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ドキュメントという名の“設計図” 私たちは数え切れないほどのドキュメントを作成してきた。 ・プログラム作成基準書 ・環境設定手順 ・パッケージ適用基準書 ・デプロイ手順書 一見すると、テンプレートで回せそうに見える。しかし現実は違う。顧客環境ごとに前提が変わり、細部はすべて作り直しになる。つまり、構成管理とは「コピペ職人」ではなく「環境適応型アーキテクト」なのだ。 ■しかし、1つの壁にぶつかる あるとき、私は気づいた。 「このドキュメント、自分たちだけでは完成しない」 どれだけ整理し、構造化しても、最後のピースが埋まらない。 それは——“現実の環境”だった。 ■構成管理が最も頼る相手 では、構成管理担当は誰にヘルプを求めるのか？ 答えは明確だ。サーバ担当である。 ■サーバとプログラムは分離できない サーバ担当は、サーバ構成やDB構成を設計・管理する。一方で、構成管理はプログラムの構成を握る。しかしこの2つは、決して独立しない。 ・サーバに導入されたパッケージ情報を把握しなければならない ・プログラムが必要とするパッケージはサーバに導入されなければならない どちらが欠けても、アプリケーションは動かない。 ■“交差点”に立つ役割 構成管理は、単なるドキュメント管理ではない。 それは「プログラムチーム」と「環境チーム」が交わる交差点だ。 お客様の環境を見るチームと、コードを書くチーム。その2つが接続されることで、初めて“動くシステム”が生まれる。 ■ここで1つの問い では、構成管理はどちら側の人間なのか？ 開発側か、インフラ側か。 私は断言する。 どちらでもない。だからこそ価値がある。 ■議論を呼ぶポイント 多くのプロジェクトでは、構成管理は「裏方」と見られがちだ。しかし本当にそうだろう...

Wait… I froze when I saw steaming tea placed on top of a server in a real workplace. ■ The Reality of a 6th-Year Professional In my sixth year as a working professional, I was assigned to a software development project. The development room was so cluttered that it was almost impossible to walk through. Each person had only about 80cm of workspace. The sound of a colleague’s keyboard felt like it was directly interrupting my thoughts. 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ Disappearing Meeting Rooms Meeting rooms, originally designed for discussions, had been converted into testing rooms. Only one remained. As a result, meetings were held in open spaces or as standing conversations. The quality of decision-making was inevitably declining. ■ Even Eating Becomes Difficult There was no proper place to eat. Before long, a rack-mounted server had become a “desk.” Lunch boxes were placed on top of heat-generating equipment. This is not an exaggeration—it was reality...