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

投稿

ブログを翻訳

怒鳴り声が正義だった時代——平成のパワハラ営業が残した“歪んだ成功体験”

うわっ…成功って、こんなに“うるさい”ものだったのか!? ■ 社会人7年目、現場の違和感 社会人7年目の中盤、私はある開発ベンダーの現場にいた。 それなりに経験も積み、プロジェクトの中核を担い始めた頃だ。だが、そこで目の当たりにしたのは、スキルでも戦略でもない、「声の大きさ」が支配する世界だった。 ■ パワハラ営業という“文化” その現場には、ある有名な営業部長がいた。 社内外で結果を出していることで知られていたが、その裏側は強烈だった。 夜、お客さんと飲んで帰ってきたその足で、突然「11時から会議だ」と号令がかかる。 開発チームの部長陣が呼び出され、席に着いた瞬間——怒鳴り声が飛ぶ。 机を蹴る。 資料を投げる。 言葉ではなく“圧力”で支配する空気。 それが、その場では「当たり前」だった。 ■ 見ているだけで削られる現場 私は直接怒鳴られることは少なかった。 だが、自分の上司が目の前で責められる姿を見るのは、想像以上に消耗する。 ある日、上司がモノを投げられた。 その後、頭を押さえながら静かに戻ってきた。 何も言わず、ただ席に座る。 その背中が、すべてを物語っていた。 ■ なぜ“続いていた”のか 不思議なことに、その営業部長は長くその地位に居続けていた。 理由はシンプルだ。 「結果を出していたから」だ。 売上という絶対指標が、すべてを正当化する。 組織は、その“成功体験”を否定できない。 つまり、あの振る舞いは個人の問題ではなく、構造の問題だった。 ■ 自分も巻き込まれた瞬間 ある時、私はメインプロジェクトの合間に、その営業部長の案件支援に入ることになった。 土日に呼び出され、提案書作成。 本来は上司が受けた案件のヘルプだ。 幸い、上司の配慮で私は会議に出なくてよくなった。 だが、その代わりに上司が前面に立つ。 そして——また怒鳴られていた。 「守られている」という事実と、 「誰かが代わりに傷ついている」という現実。 そのギャップが、強烈に心に残った。 ■ 平成でも、パワハラは“現役”だった 平成という時代は、すでにコンプライアンスや働き方改革が語られ始めていた。 それでも、特定の現場では、こうしたパワハラが“普通に機能”していた。 むしろ、「あれくらいやらないと勝てない」という空気すら...
最近の投稿

When Shouting Was Justice — The “Distorted Success Formula” Left by Heisei-Era Power Harassment Sales

Whoa… was success really supposed to be this loud !? ■ Year 7 in My Career — A Growing Sense of Discomfort In the middle of my seventh year as a professional, I was working at a development vendor. I had gained solid experience and was beginning to take on core roles in projects. But what I witnessed there was not a world ruled by skill or strategy—it was a world ruled by the volume of one’s voice . ■ Power Harassment as a “Culture” At that workplace, there was a well-known head of sales. He was famous for delivering results both internally and externally—but what lay beneath was intense. After drinking with clients late at night, he would suddenly call out, “Meeting at 11 PM.” Department heads from the development team would be summoned, and the moment they sat down—shouting would erupt. Kicking desks. Throwing documents. An atmosphere dominated not by words, but by sheer pressure. And in that place, it was considered “normal.” ■ A Workplace That Drains You Just by Watchin...

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

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