🏢 運命のプロジェクト開始
「君に会計システムのリーダーをお願いしたい」
部長の高橋さんからその話を聞いた時、正直に言うと逃げ出したくなった。
前任者の先輩が、同じような大規模会計システムで心を病んで休職してしまったのを見ていたからだ。
でも、断れる雰囲気ではなかった。
クライアントは従業員数8,000名の大手製造業。
関連会社30社を抱える企業グループの基幹会計システムを、15年前の古いシステムから最新のERPパッケージに刷新する。
期間は1年の予定。でも、心の中では「絶対に1年では終わらない」と確信していた😅
プロジェクトの主要メンバー:
- プロジェクトマネージャー: 中村さん（42歳、ベテラン、でも...）
- 会計システムリーダー: 私（当時32歳、不安でいっぱい）
- 技術リーダー: 佐々木さん（38歳、技術は凄いが気難しい）
- 業務コンサルタント: 伊藤さん（45歳、知識豊富だが完璧主義）
お客様側も本気度が違う。
経理部から専任者3名、IT部門から2名、各事業部から業務担当者...総勢20名の大所帯。
「今度こそ、完璧なシステムを作りたい」
お客様の経理部長、鈴木さんの言葉に、プレッシャーを感じずにはいられなかった。
📋 要件定義：底なし沼の始まり
2005年5月から要件定義が始まった。
最初の会議で、鈴木部長が分厚いファイルを持参してきた。
「現在使っている帳票の一覧です」
開いてみて愕然。100種類以上の帳票がびっしりと並んでいる😱
- 貸借対照表、損益計算書（各事業部版、連結版、単体版...）
- 売上分析表（製品別、顧客別、地域別、営業担当別...）
- 予算実績対比表（月次、四半期、年次、累計...）
- 各種管理資料（部門別、プロジェクト別、コスト要素別...）
「ERPの標準帳票でどれくらいカバーできるんですか？」私が佐々木さんに小声で聞く。
「ゼロだよ。ERPの標準帳票なんて、そのまま使える会社なんて存在しない」
冷静に答える佐々木さん。でも、その表情は既に疲れていた。
「100種類以上を全部アドオン開発ですか...？」
「まあ、実際には統廃合して20種類くらいに絞り込むのが現実的だけどね」
20種類でも相当な開発量。帳票開発だけで半年はかかりそうだった。
組織マスタの悪夢
次に待っていたのが、組織構造の複雑さ。
「部門は100部門以上あります」
鈴木部長が説明を始めると、私の頭の中でアラームが鳴り響いた。
- 本社、工場、営業所、海外支社
- 事業部制と機能部門の混在
- 在籍部門と費用計上部門の使い分け
- プロジェクト組織と恒常組織の並存
「例えば、営業の田中さんは東京支社に在籍してるけど、九州担当だから売上は福岡営業所計上。でも交通費は東京支社で処理して...」
話を聞いているうちに、頭がこんがらがってくる😵
伊藤さんが完璧主義の性格を発揮して、「全ての組み合わせを網羅した設計にしましょう」と言い出した時、私は密かにため息をついた。
これは長期戦になる。
🔍 設計フェーズ：チームの亀裂
2005年8月から設計フェーズが始まった頃、チーム内の空気が少しずつおかしくなってきた。
中村PMの微妙な変化
中村PMは経験豊富で人当たりも良い。でも、お客様からの要求が想定以上に複雑になってくると、だんだんピリピリしてきた。
「スケジュールが遅れてる。もっと効率的にできないのか？」
定例会議での彼の口調が、だんだんきつくなってくる。
でも、問題はスケジュールだけじゃなかった。お客様の要求が、打ち合わせのたびに微妙に変わるのだ。
「前回は『部門別集計』と言ってましたが、やっぱり『プロジェクト別集計』も必要です」
「『月次レポート』だけでなく、『週次レポート』も欲しいです」
仕様がコロコロ変わるたびに、設計のやり直し。
佐々木さんの表情がどんどん険しくなっていく。
佐々木さんのストレス爆発
ある日の深夜、オフィスに残って設計書を書いていた佐々木さんが、突然机を叩いた。
「いい加減にしろよ！また仕様変更かよ！」
彼の怒りは理解できた。
技術者として完璧な設計を目指しているのに、土台がコロコロ変わるのは本当にストレスだと思う。
でも、その矛先が新人のプログラマーに向けられた時は、さすがに止めに入った。
「お前のせいで工数が増えた」 「もっと考えてからコーディングしろ」
新人の山田くんが萎縮しているのを見ていて、胸が痛かった😢
伊藤さんの完璧主義の弊害
伊藤さんは会計業務に精通していて、本当に頼りになる存在。でも、完璧主義すぎるのが問題だった。
「この処理パターンも考慮しておくべきですね」 「例外処理も全て洗い出しましょう」 「マニュアルも詳細に作成しましょう」
品質への こだわりは素晴らしいけれど、工数がどんどん膨らんでいく。
「伊藤さん、さすがにそこまでやると予算オーバーです...」私が言うと、彼は不機嫌な顔をした。
「品質を犠牲にするんですか？お客様に迷惑をかけることになりますよ」
正論だけに、反論しづらい。でも、現実問題として予算とスケジュールの制約はある。
板挟みになった私のストレスも、日に日に増していった💦
💻 開発・テストフェーズ：地獄の始まり
2005年12月から開発とテストが本格化。
ここからが本当の地獄の始まりだった。
帳票開発の悪夢
20種類に絞り込んだ帳票の開発が始まると、想像を絶する複雑さが明らかになった。
例えば、「部門別損益計算書」一つ取っても：
- 直接費と間接費の振り分けロジック
- 本社費の配賦計算
- 前月比、前年同月比の算出
- 累計値の計算
- 予算との差異分析
単純な集計じゃない。
複雑なビジネスロジックの塊だった。
プログラマーの山田くんが、夜中の2時に泣きそうな顔で私のところに来た。
「先輩、この配賦計算、どうやってもうまくいきません...」
見てみると、確かに複雑すぎる。基準となる数値が別の帳票の計算結果だったり、条件分岐が10個以上あったり...
「明日、お客様に確認してみよう」
そう言いながらも、心の中では「これ、設計が甘かったな」と反省していた😅
テストで次々発覚する問題
2006年2月からテストが始まると、バグが雨のように出てきた。
- 計算結果が合わない
- 画面が固まる
- データが消える
- 印刷がずれる
佐々木さんは連日深夜までデバッグ作業。
彼の机の周りには空のコーヒー缶が山積みになっていた。
「あと何個バグが出るんだ...」
呟く彼の声には、明らかに疲労が滲んでいた。
中村PMのプレッシャー
状況が悪化するにつれて、中村PMのプレッシャーも強くなってきた。
「会社の上層部から、スケジュール遅延について説明を求められてる」 「お客様からも、品質について厳しい指摘が...」 「なんとか4月稼働に間に合わせないと、みんなの評価に響く」
気持ちは分かる。
でも、品質に問題があるまま稼働するわけにはいかない。
「もう少し時間をください」私が頭を下げると、彼は深いため息をついた。
「分かった。でも、これが最後だ」
🚀 2006年4月：地獄のリリース
結局、予定通り2006年4月1日にリリースすることになった。
正直に言うと、まだテストが完了していない機能があった。
でも、「とりあえず基本的な仕訳入力はできるから」という判断だった。
リリース前夜、私たちは徹夜でデータ移行作業を行った。
「データ移行開始」中村PMの号令で作業開始。
15年分の膨大なデータを新システムに移行する作業。
午前2時：移行作業でエラー発生 「文字化けしてます！」 「データ件数が合いません！」
午前4時：何とか移行完了 「動作確認を急いで！」
午前6時：基本機能の確認完了 「仕訳入力は問題なし」 「でも帳票は...まだ確認できてません」
「とりあえず稼働させよう」
中村PMの判断で、不完全な状態でのリリースとなった。
誰も「やった！成功だ！」なんて言わなかった。むしろ、全員の表情に不安が浮かんでいた😰
🔥 リリース後の地獄：日次処理の悪夢
リリース初日、午前中は比較的平穏だった。仕訳入力はERPの標準機能だから、大きなトラブルは起きない。
「意外と大丈夫かも...」
そんな淡い期待を抱いていた私たちに、現実は厳しい仕打ちを与えた。
深夜バッチ処理の地獄
翌朝、お客様から緊急電話。
「昨夜のバッチ処理がエラーで止まってます！」
急いで確認すると、日次処理のバッチが夜中の3時でエラー停止していた😱
- 売掛金の残高更新でエラー
- 部門別集計でメモリ不足
- 為替換算処理でタイムアウト
朝8時から緊急対応。でも、原因特定に時間がかかる。
「これ、今日の業務はどうするんですか？」お客様の経理担当者が不安そうに聞く。
「前日のデータで暫定対応してください...」
そう答えながらも、心の中では冷や汗をかいていた💦
毎朝の憂鬱な電話
リリース後2週間、毎朝6時に携帯が鳴る。
「また夜間処理でエラーです...」
お客様の声に申し訳なさと焦りが混じっている。こちらも、毎朝胃が痛い思いで対応にあたった。
佐々木さんは毎日深夜までデバッグ作業。目が血走って、明らかに限界に近づいていた。
「もう無理だ...」
ある朝、彼がポツリと呟いた時、私は本当に心配になった😢
💥 月末締め処理：最大の試練
リリースから3週間後、4月の月末締め処理。これが最大の試練だった。
月末締め処理は、その月の全取引を確定させ、翌月に繰り越すための重要な処理。
これができないと、翌月の業務が始められない。
4月30日深夜、締め処理開始
「今度こそ、うまくいってくれ...」
全員が祈るような気持ちで処理開始ボタンを押した。
午前1時：エラー発生 「部門別集計でエラーです」
午前3時：修正後、再実行 「今度は連結処理でエラー」
午前5時：また修正、再実行 「データの整合性チェックでエラー」
朝になっても終わらない😰
お客様の経理部の方々も、オフィスで待機していた。
みんなの疲れ切った顔を見ていて、本当に申し訳ない気持ちでいっぱいだった。
結局、締め処理完了まで1週間
毎日修正とテストの繰り返し。ようやく締め処理が完了したのは、5月7日だった。
「これじゃあ、月次決算が遅れて仕方ありません」
お客様の経理部長の疲れ切った声が、胸に刺さった💔
チームの限界
この頃になると、チームメンバーの疲労は極限に達していた。
佐々木さんは連日の徹夜で体調を崩し、2日間休養を取った。
山田くんは、お客様から厳しい指摘を受けるたびに、明らかに萎縮していく。
伊藤さんは、自分の設計の甘さを責めて、一人で抱え込むようになった。
中村PMは、会社からの圧力とお客様からのクレーム対応で、常にイライラしていた。
私？私は板挟みになって、毎晩眠れない日が続いた😞
🌧️ IT業界のブラック、その正体
この地獄のような期間を通して、「IT業界がブラック」と言われる理由が、身に沁みて分かった。
リリース前のブラック要素
何としても期限に間に合わせなければいけないプレッシャー。
「4月1日稼働は絶対」という制約の中で、品質に問題があると分かっていても見切り発車。
連日深夜まで作業しても追いつかない工数。でも、「みんな頑張ってる」という雰囲気で、弱音を吐けない空気。
リリース後のブラック要素
品質に問題があると、対応に追われる日々。
毎朝6時の緊急電話。夜中の3時までのトラブル対応。休日も関係なく呼び出される。
お客様からの厳しい指摘。「こんな品質で納品するなんて」という言葉に、心が折れそうになる。
人間関係のブラック要素
プレッシャーがかかると、人間関係がギスギスしてくる。
佐々木さんが新人に当たり散らすのを見ていて、「この人も追い詰められてるんだな」と感じた。
中村PMの口調がだんだんきつくなって、以前の人当たりの良さが失われていく。
チーム内で責任の押し付け合いが始まる。「あの設計が甘かった」「あの実装にバグがあった」...
根本的な問題
でも、一番のブラック要素は、これらすべてが「個人の能力不足」として処理されがちなこと。
「スキルが足りない」 「経験不足だった」 「もっと頑張れば良かった」
システムの複雑さや、無理なスケジュール、品質とコストのトレードオフ...構造的な問題があるのに、個人の責任にされてしまう😢
そして、成功した時は会社の手柄、失敗した時は個人の責任。この非対称性が、多くのエンジニアを苦しめている。
🌅 転機：8月の奇跡
地獄のような4ヶ月を過ごした後、8月に転機が訪れた。
お客様の経理部で新しい課長が着任した。前職でシステム導入の経験がある方だった。
新課長との面談
「正直に状況を教えてください」
新課長の第一声に、私は思い切って本音を話した。
「申し訳ありません。品質に問題があるまま稼働させてしまいました」 「毎月の締め処理に時間がかかりすぎて、業務に支障をきたしています」 「チームのメンバーも疲弊していて、このままでは...」
新課長はしばらく考えた後、こう言ってくれた。
「分かりました。一旦、リスケしましょう」
現実的なアプローチ
新課長の提案は、現実的だった。
「完璧を求めすぎないで、段階的に改善していきましょう」 「まず、月末締めを確実にできるようにする」 「帳票は、本当に必要なものから順番に対応する」 「品質が安定してから、機能拡張を考える」
この方針転換で、チームの雰囲気が劇的に変わった✨
チームの立て直し
8月から、チーム運営も見直した。
佐々木さんには、新人指導を外してもらい、技術的な問題解決に専念してもらった。
山田くんには、プレッシャーをかけずに、一つずつ確実に作業を進めてもらった。
伊藤さんには、完璧主義を少し抑えて、優先度を付けて取り組んでもらった。
中村PMは、お客様との調整に専念し、チーム内のプレッシャーを減らすことに努めてくれた。
私は、メンバーの体調やメンタルケアにも気を配るようになった。
📈 2007年春：ようやく見えた光
2007年3月、リリースから丸1年。ようやく安定稼働にこぎつけた。
月末締め処理：3日で完了
最初は2週間かかっていた月末締め処理が、3日営業日で完了するようになった。
まだ理想的ではないけれど、業務に支障をきたすレベルではない。
帳票の品質向上
20種類の帳票も、計算ロジックの修正を重ねて、ようやく実用レベルに。
「やっと使える数字が出るようになりました」
お客様からそう言ってもらえた時は、本当に嬉しかった😊
チームの成長
何より、チームメンバーの成長が素晴らしかった。
山田くんは、複雑なロジックも一人で実装できるようになっていた。
佐々木さんは、技術的な問題を冷静に分析し、効率的に解決する能力を身につけていた。
伊藤さんは、完璧主義を保ちながらも、現実的な判断ができるようになっていた。
中村PMは、チームマネジメントのスキルを大幅に向上させていた。
私自身も、技術だけでなく、人間関係や調整能力の重要性を学んだ。
🎓 1年半の格闘から学んだこと
IT業界のブラック要素の正体
1. 構造的な問題を個人の責任にする風潮
- システムの複雑さ vs 限られた期間・予算
- 品質・コスト・スケジュールのトリレンマ
- でも失敗すると「スキル不足」で片付けられる
2. 無理なスケジュール設定
- 営業段階での甘い見積もり
- お客様の期待値と現実のギャップ
- 「何とかなる」という根拠のない楽観主義
3. 品質の定義の曖昧さ
- 「動けばOK」vs「完璧に動く」
- どこまでテストすれば十分なのか？
- リリース後のトラブルは誰の責任？
4. チーム内の人間関係
- プレッシャー下での人格の変化
- パワハラ的な指導の横行
- 責任の押し付け合い
でも、ホワイト要素もある
1. 成長実感
- 困難を乗り越えた時の達成感
- 技術的な能力の向上
- 人間としての成長
2. チームワーク
- 苦労を共にした仲間との絆
- お互いを支え合う関係性
- 一緒に問題を解決する喜び
3. お客様からの感謝
- 業務改善に貢献できた実感
- 「助かりました」という言葉の重み
- 社会に役立っている実感
4. 高い専門性
- 企業の基幹システムに携われる責任
- 幅広い業務知識の習得
- 技術的な深い知識の獲得
💭 今、同じような状況で苦しんでいる方へ
もしあなたが今、似たような地獄を経験しているなら：
逃げることも勇気
無理をしすぎて体を壊したり、心を病んだりする前に、逃げることも必要。
私たちも、佐々木さんが体調を崩した時、「無理をしすぎていた」と反省した。
一人で抱え込まない
問題を一人で抱え込まず、チームで共有する。恥ずかしいことじゃない。
山田くんが素直に「分からない」と言ってくれた時、みんなでフォローできた。
お客様との正直なコミュニケーション
品質に問題があることを隠さず、正直に伝える勇気も必要。
新課長のような理解のある方なら、一緒に解決策を考えてくれる。
長期的な視点を持つ
短期的には辛くても、その経験が将来の成長につながる。
1年半後の自分たちを見て、「あの苦労があったから今がある」と実感した。
🌟 最後に：IT業界の現実
IT業界がブラックかどうかは、本当にケースバイケース。
ブラックになる要因:
- プロジェクトマネージャーのスキル不足
- チームメンバーの相性・性格
- システムの複雑さ・技術的難易度
- お客様の業務の複雑さ・理解度
- 会社の体制・サポート体制
これらの要因が重なると、地獄のような状況になる。
でも、逆に言えば、これらの要因を改善できれば、やりがいのある素晴らしい仕事になる。
私たちの経験から言えること:
確かに大変な仕事。でも、意味のある仕事。
お客様の業務改善に貢献できる喜び、チームで困難を乗り越える達成感、自分自身の成長実感...これらを得られるのは、やはりIT業界の魅力だと思う。
「地獄も経験すれば、天国がより輝いて見える」
あの1年半の格闘があったからこそ、今の充実した仕事があるのかもしれない。
同じような戦いを続けている皆さん、一緒に頑張りましょう💻✨
体だけは壊さないように、お互い気をつけて...