「100日後に退職する47歳」は、どうすればボーナス0円を回避できたのか? ― 感情論を「数字」と「リスク」に置き換える技術
漫画「100日後に退職する47歳」を覚えておいででしょうか。
デスマーチ、度重なる仕様変更、無能な増員、そしてエースの退職……。あらゆる苦難を乗り越え、ボロボロになりながらシステムをリリースした47歳の主人公に突きつけられたのは、「ボーナス0円」という非情な通告でした。
多くの読者が「ひどすぎる」「これが日本のITの現実か」と涙し、彼に同情しました。しかし、経営やマネジメントの視座でこの物語を読み解くと、残酷ながらも別の側面が見えてきます。
「彼は、ボーナスをもらえるだけの『価値』を、経営陣に伝わる言葉で提示できていなかった」
今回は、彼が陥った「頑張り損」の構造を解き明かし、どう振る舞えば「会社に利益をもたらす人材」として評価され、ボーナスを勝ち取れたのか。その具体的な「IF(もしも)」の戦略をシミュレーションします。
前提:ボーナスの原資は「汗の量」ではなく「増えた利益・減った損失」で決まる
まず大前提として、会社は「苦労したから」お金を払うわけではありません。
ボーナスを勝ち取るとは、自分の行動によって会社の利益を増やすか、将来発生しうる損失を明確に回避することです。
例えば、作中で何度も起きていた本番障害。これにかかった社員の残業代、売上機会の喪失、顧客からの信頼低下……これらを合計すれば、障害1件あたり数百万円〜数千万円の損失になっていてもおかしくありません。
もし彼が、そのうちのたった1件でも「事前の検証や設計変更で未然に防いだ」と証明できていれば、それだけで自分のボーナス分など余裕で賄える金額を会社に残したことになっていたはず。
そういう交渉をするために、具体的にどうすればよかったのでしょうか?場面ごとに見ていきましょう。
1. リリース前後:「環境がない」という言い訳を「リスクの数値化」に変える
漫画の展開
負荷テスト環境がないままリリースを強行し、本番でサーバーダウン。「(原因が)うちじゃなくてよかった・・・」とほっとする。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) September 6, 2021
54日目#100日後に退職する47歳 pic.twitter.com/hNb0UDqbM1
どうすればよかったのか?
リリースの担当者がなすべき仕事は、テストができない理由を並べることではなく、そのまま進めた時に生じうる損失を数字で示して、経営に判断を仰ぐ(リスクを移譲する)ことです。
47歳氏は、環境がない時点で以下のメモを作るべきでした。
【負荷試験未実施によるリスク試算】
ダウン確率: 高(現状の想定アクセス数に対し、検証なし)
ダウン時の損失: 復旧に約10人日(◯万円)、および顧客対応コスト。
提案: 簡易負荷試験用にクラウド環境を3日間レンタルする(費用◯万円)。または、ピークタイムを避けて段階的にリリースする。
これを出していれば、「数万円のコストを惜しんで数百万円の損害を出した」のは経営判断のミスになります。彼は責任回避を確実にできるだけでなく、このメモ自体が「会社のお金を守ろうとした」という価値ある成果物として評価されたはずです。
2. 増員投入:「とりあえず手伝って」を「コスト回収プランの立案」に変える
漫画の展開
3名の増員(スキル不足のベテラン、日本語勉強中の外国人、完全未経験者)に対し、「とりあえずタスクを振る」ものの、「期限は特にない」と指示。結果、Gitブランチは崩壊し、手直しで逆に工数が圧迫される。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) July 31, 2021
18日目#100日後に退職する47歳 pic.twitter.com/73B6Ss4KHr
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) August 20, 2021
37日目#100日後に退職する47歳 pic.twitter.com/Viweh8ms0J
どうすればよかったのか?
人を増やしてもらった瞬間から、その人件費を上回る成果を設計するのがマネージャーの仕事です。スキルが低いなら低いなりの「回収プラン」を立てる必要があります。
例えば、こう宣言します。「この1ヶ月で、本番障害の主因である『入力エラー』をゼロにします」
そのために、増員メンバーには「入力チェックとエラー処理の共通モジュール化」や「異常系テストケースの作成」だけを徹底させます。たとえコードが汚くても、これによって本番障害が減れば、その「障害削減効果」だけで追加3名分の人件費を回収できたと説明できます。
「使えない部下」を嘆くのではなく、「彼らをどう使って赤字を減らすか」を考えるべきでしたし、よしんば、宣言したメトリクスを満たせなかったときも、それはそれで無能のクビを切り自分を守る根拠とすべきでした。
3. チーム構成:「最後の砦」から「若手の力を最大化する土台」へ
漫画の展開
優秀な若手I君が、C++17の新機能を使ってバグを特定・修正。47歳氏はそれに感心するだけで、結局I君は「割に合わない」と退職してしまう。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) August 31, 2021
48日目#100日後に退職する47歳 pic.twitter.com/l1yM8HKrB6
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) September 16, 2021
64日目#100日後に退職する47歳 pic.twitter.com/dwthLgPPa3
どうすればよかったのか?
自分より技術力のある若手が現れた時、プレイヤーとして張り合ったり、単に感心している場合ではありません。ベテランの価値は、その若手のパフォーマンスを最大化し、組織に定着させることにあります。
I君が成果を出した時点で、47歳氏はこう動くべきでした。
権限委譲: 素直に彼を技術リーダー(テックリード)に据える。
環境整備: 彼が嫌がる雑務や深夜対応を自分が引き取り、「コーディングに集中できる環境」を作る。
知見の展開: I君の書いたコードをチームの勉強会で解説させ、ドキュメント化する。
こうすれば、成果は「I君一人の力」ではなく、「I君プラス数人分の技術レベル向上を実現したチーム全体の力」になります。さらに、I君の離職を防げれば、採用コストや教育コストの削減という大きな「利益」を生んだことになります。
4. 技術的負債:「デグレが怖い」を「一点突破での解消」に変える
漫画の展開
四捨五入の計算バグに対し、根本ロジックを直すと他が壊れる(デグレ)のが怖くて、表示部分(printf)だけを修正して誤魔化す。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) October 21, 2021
98日目#100日後に退職する47歳 pic.twitter.com/XeNY881vqK
どうすればよかったのか?
技術的負債は、全部を返す必要はありません。しかし、「最もコストを浪費している原因」を一点だけ潰すだけでも、ベテランの価値は証明できます。
47歳氏は、「ここだけは根本修正する」と決め、影響範囲を洗い出して小さな自動テストを書くべきでした。
そのテストを通しながら安全にロジックを組み替えることで、「料金計算の誤りによる毎月の信用毀損リスク」を完全に消し去ることができます。
「なんとなく動いている」状態を維持するのではなく、「この爆弾だけは私が処理しました」と言える実績で、ボーナス査定のテーブルに乗る成果をねん出すべきでした。
5. 勉強時間の投資対効果:「ただの勉強」を「数百万円の利益」に変える
漫画の展開
彼は計算量(オーダー記法)の概念も理解していませんでした。プログラムが遅い原因を特定できません。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) October 13, 2021
90日目#100日後に退職する47歳 pic.twitter.com/QqVgmonX7q
どうすればよかったのか?
「技術力不足」は単なる知識の問題ではありません。「コスト削減の選択肢を持っていない」という経営上の損失です。
彼は「自分の勉強時間をどう投資すれば、一番効率よくボーナス原資(会社の利益)を稼げるか」という視点を持つべきでした。
例えば、「毎日1時間」だけ、基礎アルゴリズムと最新言語仕様の学習に投資したとします。
投資コスト:
月30時間(残業時間を減らして充てる)改善アクション:
学んだ知識で、システム内で最も重いループ処理(計算量 $${O(N^2)}$$)を特定し、効率的なアルゴリズム($${O(N \log N)}$$)に書き換える。リターン(利益化):
バッチ処理時間が短縮され、クラウドサーバーのランクを1つ下げることができた。もし月額5万円の削減なら、年間60万円の利益確定。もしピーク時のサーバー増設を回避できたなら、数百万円規模のコスト回避。
「サーバースペックを上げればいい」はお金で解決する発想ですが、「コードで解決する」ことは、会社のお金を使わずに同等の効果を出す=利益を生む行為です。彼が勉強しなかったことは、この「数百万円の利益」をみすみす捨てているのと同じなのです。
この成果をプレゼンすれば「どちらに転んでも」勝ち確定になる
さらに重要なのは、この改善提案を会社にプレゼンすることで、「負けない状況」を作り出せるという点です。
【パターンA:会社が提案を受け入れた場合】
彼は「毎日1時間の勉強時間」を業務時間内に行う正当性を勝ち取れますし、ボーナスの原資も得ることができるかもしれません。なぜなら、それは自分の趣味ではなく「年間60万円以上の利益を生むための業務」だからです。
【パターンB:会社が提案を却下した場合】
ここからが本番です。もし「そんなことより目の前の作業をしろ」と言われたら、その事実を持って転職活動に向かえばいいのです。面接で「弊社を志望する理由は?」と聞かれた際、こう答えられます。
「私は現職で、アルゴリズム改善による月額◯万円のコスト削減を提案し、技術的な裏付けも用意しましたが、経営方針により評価されませんでした。私は、技術をコスト削減や利益貢献に直結させる提案ができ、それを評価してくれる環境で働きたいと考えています」
ただの「愚痴」だった退職理由が、一瞬で「経営視点を持ったエンジニアの正当なキャリアアップ」に変わります。技術への投資は、社内で評価されればボーナスに、されなければ最強の転職カードになる。どちらに転んでも「お得」な生存戦略なのです。
6. 最後の期間:「情」ではなく「成果」で惜しまれる去り方
漫画の展開
退職が決まった後、後任(出戻りのKさん)に引き継ぎを行うが、口頭や断片的な情報のみ。
100日後に退職する47歳
— 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) October 15, 2021
92日目#100日後に退職する47歳 pic.twitter.com/abTK8SrXM4
どうすればよかったのか?
ここまでやる人は少数とはいえ、退職が決まってからの数十日は、金を引っ張る最後のチャンスです。「後任が劇的に楽になる仕組み」を売ることで、会社からの評価は感情論ではなく「損失回避」の観点で逆転します。
具体的には、「システムハザードマップ」を作ることです。
ここは根本修正済み(安全地帯)
ここは暫定対処で危険(地雷原)
この監視アラートはオオカミ少年(無視してOK)
これらを一覧にして渡していれば、Kさんは着任初日からリスクの高い箇所に集中して着手できます。会社としては、「47歳氏が残した情報のおかげで、後任が半年早く戦力化した」と判断し、それを退職金に色をつける理由にできたかもしれません。
47歳でも「ボーナス」は自分で勝ち取れたのではないか?
この47歳さんの物語の悲劇は、彼の能力の不足もさることながら、
「自分がやっているしんどい仕事を、経営から見える『お金』と『リスク』の言葉に置き換えなかったこと」
そして、
「成果として示しやすいポイント(=急所)に手を出さず、ひたすら耐えることを選んでしまったこと」
が非常に大きい。
彼が一貫して続けていた長時間労働やトラブル対応を、そのまま「美談(かわいそうな話)」で終わらせてはいけません。
「どの障害を、どの再発防止策で潰して、年間で何時間の深夜対応と何件の顧客トラブルを減らしたか」。
その形に一つでも変換できていれば、彼は「残業しているから偉い人」ではなく、「会社に利益と時間をもたらすプロフェッショナル」として、当然のようにボーナスを手にしていたはずなのです。
