Digital Heroes: Guide to IT World

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...