飯田部長と田辺部長は、どちらも50代で独身だった。
飯田部長は53歳。システム開発部の部長で、勤続28年。田辺部長は51歳。品質管理部の部長で、勤続26年。二人とも同じフロアにデスクがあって、毎日朝8時半に出社して、夜21時か22時まで働いていた。
タバコは吸わない。トイレ休憩以外は、ずっとデスクのパソコンに向かっている。昼休みも、デスクでコンビニのおにぎりを食べながら、画面を見ている。そういう人たちだった。
二人とも、話せばにこやかに答えてくれる。でも、向こうから話しかけてくることはほとんどなかった。必要なことだけを、必要な時にだけ話す。それ以外の時間は、ずっとコードを書いているか、仕様書を確認しているか、バグの調査をしているか。そういう日々だった。
部下への声がけが、ほとんどない理由
飯田部長の部下は7人いた。そのうち中堅が4人、若手が3人。田辺部長の部下は5人で、中堅が3人、若手が2人。
中堅の社員たちは、自分たちで仕事を回せる。何をすればいいか、どこで詰まるか、誰に相談すればいいか、全部わかっている。だから部長が細かく指示を出す必要がなかった。新入社員のことは、中堅に任せていた。「わからないことがあったら、まず早坂さんに聞いて」と最初に伝えてあれば、あとは中堅がフォローしてくれる。
結果として、部長は部下に声をかける機会が減っていった。もともと静かな性格の二人だったから、それに輪をかけて、声がけが不要な状態になっていた。
でもそれは、放置しているわけではなかった。部長たちは、部下の進捗をSlackで確認していたし、週に一度の定例ミーティングでは必ず全員の状況を把握していた。ただ、日常的に声をかける、という行為が、構造的に不要になっていた。
私は入社2年目の頃、飯田部長に質問をしに行ったことがある。部長は画面から目を離さずに「うん、どうぞ」と言って、私の説明を聞きながら、手は動き続けていた。質問に答え終わると、「他にある？」と聞いて、私が「ないです」と答えると、「じゃあ頑張って」と言って、また画面に向き直った。
悪い対応ではなかった。でも、そこに温度はなかった。
ソフトウェア開発が、楽しいのだと思う
飯田部長は、Javaのコードをずっと書いていた。部長職でありながら、自分でも開発をしていた。Spring Frameworkを使った社内システムの保守と、新機能の追加。それを一人で黙々と進めていた。
田辺部長は、テストケースの設計とバグの管理をしていた。JiraとTestRailを使って、品質管理のフローを整備していた。部下が報告したバグを一つずつ確認して、優先度をつけて、開発部門にフィードバックする。その作業を、毎日何時間も続けていた。
二人とも、きっとオタク気質なんだと思った。仕事を進めなければ、という責任感ももちろんあるだろう。でも、それだけじゃない。ソフトウェア開発が、楽しいのだと思う。コードが動く瞬間、バグが特定できた瞬間、そういうところに喜びを感じているんだと思う。
だから毎日、同じ姿勢で、同じ画面を見続けていられる。
ときどき見せる、中年カップルのような微笑ましさ
ある日の昼休み、飯田部長が田辺部長のデスクに歩いていった。
「田辺さん、このバグ報告、再現手順が書いてないよ」
田辺部長は、画面を見たまま答えた。
「それ、松井くんが報告したやつでしょ。私に言わないで本人に言ってください」
「でも田辺さんが承認してるから、確認したのかと思って」
「承認はしたけど、細かいところまで全部見てるわけじゃないです。飯田さん、暇なんですか？」
「暇じゃないよ。だから早く直してほしいんだよ」
「だったら松井くんに直接言ってください。私、今忙しいんで」
飯田部長は少し笑いながら、「わかったわかった」と言って、自分のデスクに戻った。田辺部長は、ため息をついて、また画面に向き直った。
その様子を見ていた何人かが、小さく笑っていた。ときどき飯田部長が田辺部長にちょっかいを出して、田辺部長がうざがる。そういうやり取りが、たまにあった。中年カップルの微笑ましさが、少しだけあった。
でも、それ以上ではなかった。二人はあくまで同僚で、それ以上でもそれ以下でもなかった。
部長は年俸制、残業代は出ない
飯田部長の年俸は、恐らく750万円前後だったと思う。田辺部長も同じくらい。部長職で、勤続25年以上。それで750万円。手取りにすれば月50万円くらい。
部長は年俸制だから、残業代は出ない。何時間働いても、給料は変わらない。一方、部下たちには残業代が出る。だから部長たちは、部下を早く帰らせた。
「今日はもう帰っていいよ」と、19時頃に声をかける。部下たちは「ありがとうございます」と言って、退社する。残った仕事は、部長が引き取る。部長は22時まで残って、その分を片付ける。
土曜日も、日曜日も、部長たちは出社していた。特に納期前は、週末も関係なく働いていた。部下は休ませて、部長だけが出てくる。そうやって人件費を抑えて、部署の利益を確保していた。
私は、その構造を知った時、何とも言えない気持ちになった。
利益を上げる戦略が、虚しい
飯田部長の部署は、年間の売上が約5,000万円だった。そのうち人件費が3,500万円、その他の経費が500万円。利益は1,000万円。利益率は20%。会社としては、それなりに健全な数字だった。
でもその利益は、部長が土日も働くことで生まれていた。部下に残業をさせれば、残業代が発生する。月に30時間残業させれば、一人あたり月10万円くらい人件費が増える。7人いれば、月70万円。年間で840万円。それをほぼゼロにするために、部長が自分の時間を差し出していた。
部長の給料は750万円だから、時給に換算すれば約3,600円。部下の残業代の時給は約2,500円。だから、計算上は部長が働いた方が高くつく。でも、年俸制だから、何時間働いても給料は変わらない。だから部長が働く。
その仕組みを理解した時、私は思った。こんな自分ばかりが犠牲になって利益を確保するような部長には、なりたくない。
利益があっても、人生を楽しめていない
ある月曜日の朝、私は早めに出社した。8時15分頃だった。飯田部長がすでにデスクにいた。
「おはようございます。早いですね」と声をかけると、部長は「ああ、おはよう」とだけ答えて、また画面に向き直った。コーヒーも飲まず、ただ黙々とキーボードを打っていた。
その姿を見ながら、私は考えた。部長は、週末も出社していたんだろうか。それとも、今朝早く来ただけなのか。どちらにせよ、この人の生活の大半は、このデスクの前で過ぎていく。
50代で、独身で、趣味らしい趣味もなく、毎日同じ画面を見て、同じコードを書いて、同じバグを追いかけて。それが部長の日常だった。
部長の年収は750万円。同世代の平均よりは高い。でも、その対価として、部長が差し出しているものは何なのか。
休日。プライベートの時間。家族を持つ選択肢。趣味に使う時間。友人と過ごす機会。旅行に行く余裕。そういうものを、全部差し出して、750万円を得ている。
それは「豊か」なのか。利益が出ているから、成功しているのか。部長職だから、出世しているのか。
私には、そう思えなかった。
「仕事が好き」と「人生を犠牲にしている」は、同時に成立する
飯田部長と田辺部長は、恐らく仕事が好きだった。ソフトウェア開発が好きで、コードを書くのが好きで、問題を解決するのが好きだった。だから、毎日同じことを続けていられた。
でも同時に、その「好き」が、部長たちの人生の選択肢を狭めていた。
仕事が好きだから、残業も苦にならない。土日も出社できる。だから会社は、その「好き」を利用して、部長に負担を集中させる。部長も、それを受け入れる。なぜなら、仕事が好きだから。
でも、その結果として、部長は50代で独身のまま、毎日オフィスで過ごしている。家族もいない。趣味もない。旅行にも行かない。ただ、仕事がある。
それは幸せなのか。本人が納得していれば、それでいいのか。私にはわからなかった。でも、少なくとも、私はそういう生き方を選びたくないと思った。
部長になる、ということの正体
入社3年目のある日、人事部から「キャリアプラン面談」という案内が来た。将来どうなりたいか、どんなスキルを身につけたいか、そういうことを話す場だった。
面談の最後に、人事の担当者が聞いた。「将来、部長になりたいと思いますか？」
私は少し間を置いて、答えた。「わかりません」
担当者は少し驚いた顔をした。「わからない、というのは？」
「部長になることが、何を意味するのか、まだよくわからないので」
それは本心だった。飯田部長と田辺部長を見ていて、部長になることが「出世」なのか「犠牲」なのか、私にはわからなくなっていた。
給料は上がる。でも、時間は消える。責任は増える。でも、自由は減る。部下を守るために、自分が残業をする。部署の利益を守るために、自分の土日を差し出す。昇進したのに給料が増えないのはなぜか──中間管理職の幻想は、この「昇進のコスト」を数字とともに掘り下げた記事だ。
それが部長の役割なら、私は部長になりたくなかった。少なくとも、この会社の部長には。
人事の担当者は、「そういう考え方もありますね」と言って、面談を終えた。私は自席に戻って、また仕事を始めた。飯田部長は、いつも通り、黙々とコードを書いていた。
部下と部署の利益を守るために仕事を回し続ける力は、欠点ではない。仕組みを作る力だ。それが自分の時間に返ってこないのは、力が足りないからではなく、その力の置き場所が、会社の評価1つだけになっているからだ。
その力をどこで、どう活かすかは、自分で選べる。そしてその力は、会社の評価のためだけでなく、守りたい人のためにも使える。
仕組みを作る力の置き場所を、自分の経験から考えるための設計図を、こちらのページにまとめている。
