スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

完成を見ないプロジェクトに価値はあるのか？——「途中で去る者」が背負う現場のリアル

うわっ、完成を見届けない仕事に意味なんてあるのか！？——そんな疑問が、社会人7年目の終わりに頭をよぎった。 走り続けた7年間の現場 社会人7年目も終わりを迎えようとしていた私は、これまでいくつものプロジェクトに関わってきた。大規模案件もあれば、小規模なものもある。所属しているのはアプリケーション開発部隊。各前線のSEが持ち帰ってくる案件のうち、大規模なシステム開発が必要な場合に投入される舞台だ。 仕事は山ほどあるが、主役は限られる SEが持ってくる仕事は多い。パソコンの置き換え、ネットワーク工事。しかし、その中でも最もインパクトが大きいのはシステム開発プロジェクトだ。かかる金額は桁違い。だからこそ人も集まり、そして去っていく。私もそのうちの1人だった。 「最後まで関わる」とは何か？ 当然、最後まで関われたプロジェクトもあれば、途中で離れたものもある。ではここでいう「最後」とは何か？運用まで含めて見届けることなのか。それとも本番ローンチまでか。アプリケーション開発部隊の役割は明確だ。基本は本番ローンチまで。ハイパーケアまでは関わるが、その先の運用には踏み込まない。 200人プロジェクトでも同じ現実 ある200人規模のプロジェクトで、私は構成管理担当として多くの仕組みを整備した。システムテストからテスト環境への移行はやりきった。そして、その仕組みを本番にも適用する段階まで持っていった。 しかし——そのタイミングで次のプロジェクトの話が来た。 選択の分岐点 このプロジェクトの最後まで見届けるか。それとも新しい挑戦に踏み出すか。断ることもできた。しかし、新しい環境で自分の力を試す機会でもある。 ここで一つの問いが浮かぶ。 「完成を見ない仕事に価値はあるのか？」 私は思う。価値はある。ただし、それは“成果物”ではなく“仕組み”に宿る。誰かが作った仕組みの上に、次の誰かが乗り、本番を迎える。プロジェクトはリレーだ。全員がゴールテープを切る必要はない。 ビジネスとしてのリアル むしろ、すべてを見届けることに固執する方が非効率な場合もある。人材は有限であり、機会は連続する。重要なのは「どこで価値を最大化するか」という視点だ。 選択できる立場にいること自体が、すでに価値だ。ならば、止まる理由はない。 私は次のプロジェクトへ進むことを選んだ。 この...
コメントを投稿
続きを読む
最近の投稿

Is There Value in a Project You Never See Go Live? — The Reality Carried by Those Who Leave Midway

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 ...
コメントを投稿
続きを読む

テストケース1万件の山で、誰も息ができなくなった——金融システム移行の現場で起きた“静かな崩壊”

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

Buried Under 10,000 Test Cases—A Silent Collapse Inside a Financial System Migration

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分で済ませることもある。 一見バラバラだが、すべてに共通する目的がある。 それは「会話を生むこと」だ。 ■ 矛盾：ご飯にこだわらない職種の本音 システム屋はよく言う。 「別にご飯にこだわりないですよ」と。 でも、それは半分嘘だ。 本当は、味ではなく“誰と食べるか”にこだわっている。 ご飯そのものではなく、ご飯を媒介にしたコミュニケーションに価値を置いている。 つまり、我々は“食事を設計している”のだ。 ■ あの頃、一番うまかったもの 振り返ると、いろんな店に行った。 ...
コメントを投稿
続きを読む

Hotter Than Code Was Lunch — A System Engineer’s ‘Strategic Lunch Theory’ in Koto City

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フロアを開け、 その下に配線していく。 絨毯を剥がし、床を持ち上げ、 ケーブルを通す。 人がいない時間しかできない。 だから、夜か朝。 急いで配線し、 床を閉じ、絨毯を戻す。 ——あ、ネジ締め忘れた。 次の日、床が“ボコッ”と沈む。 そんなことも日常だった。 ■スーツは泥まみれになる ...
コメントを投稿
続きを読む