グーグル、過去1年間で小規模チーム管理職の35%を削減

 (cnbc.com)
3 ポイント 投稿者 GN⁺ 2025-08-28 | 1件のコメント | WhatsAppで共有
  • グーグルは組織効率を高めるため、小規模チームを管理する管理職の35%を削減。主に3人未満の従業員を監督する管理職が対象
  • 削減された管理職の多くは、**個人貢献者（IC）**の役割に移って社内に残り、業務を継続
  • **希望退職プログラム（VEP）**は、検索、マーケティング、ハードウェア、人事運用チームなど10の製品領域で実施され、従業員の3〜5%がこれを受け入れた
  • こうした変化は、非効率な官僚主義を減らし、人員を増やさずに拡張可能な運営体制を構築するための取り組みの一環
  • グーグルの組織再編は、財務実績の改善と株価上昇にもかかわらず、従業員の士気に悪影響を及ぼしており、テック業界全体の効率化トレンドを反映

グーグルの管理職削減と効率化戦略

  • グーグルは、過去1年間で小規模チーム（従業員3人未満）を管理する管理職の35%を削減
    • 人事分析・業績担当バイスプレジデントのBrian Welle氏は全社会議で、「現在の管理職数は昨年より35%少なく、直属の部下の数も減った」と説明
    • これは官僚主義の削減と効率的な運営を目指した措置
  • 削減された管理職の多くは、個人貢献者（IC）へ転換して社内に残留
  • CEOのSundar Pichai氏は、「人員増ですべての問題を解決するのではなく、拡大時の効率性を高める必要がある」と強調
  • 目標は、管理職・取締役会・VPの比率を全従業員に占める割合として下げ、リーダーシップ構造を簡素化すること

希望退職プログラム（VEP）と組織再編

  • グーグルは2023年に全従業員の約**6%**を削減して以降、複数部門で追加の人員削減を進めている
    • AlphabetのCFOであるAnat Ashkenazi氏は、2024年10月にコスト削減を「さらに強化する」と発表
  • **希望退職プログラム（VEP）**は、検索、マーケティング、ハードウェア、人事運用など10の製品領域で、米国拠点の従業員向けに提供
    • 最高人事責任者のFiona Cicconi氏は、対象チームの3〜5%がVEPを受け入れたと明らかにした
    • VEPは、キャリアの休止や家族の介護などを理由に従業員が選択しており、「かなり成功した」と評価されている
  • Pichai氏は、従業員の一律解雇への反対意見を受けてVEPを導入し、「従業員に選択肢を与え、うまく機能した」と評価

従業員の士気と企業文化への懸念

  • 従業員は会議で、雇用の安定性、社内の障壁、グーグルの文化について質問
    • 最近の解雇、買収、組織再編によって士気の低下が報告されている
  • グーグルは2023年に58%、2024年に36%、2025年に10%の株価上昇を記録し、強い財務実績を維持

競合他社の制度比較と社内の反応

  • 従業員は、Metaが勤続5年後に提供する1か月の有給サバティカル休暇（recharge）制度に似た福利厚生を求めた
    • 福利厚生担当シニアディレクターのAlexandra Maddison氏は、既存の休暇制度で競争力があると回答し、サバティカル休暇の導入を拒否
  • Cicconi氏は、「MetaにはVEPのようなプログラムはない」と言及
    • Pichai氏は冗談交じりに「Metaのすべての制度を導入すべきなのか、それとも一部だけ選ぶべきなのか？」と述べ、否定的な立場を示した

テック業界のトレンドと比較

示唆と見通し

関連記事

1件のコメント

 
GN⁺ 2025-08-28
Hacker Newsの意見
  • この役割はGoogleではTLM（Technical Lead/Manager）と呼ばれていた。TLMは実際にコードを書きながら数人のジュニアエンジニアを管理する役割で、最近はこのようなハイブリッド職を減らし、マネージャーとエンジニアをそれぞれ専任にする方向を目指している。表向きは効率性向上という名目だが、実際にはTLMを純粋にプログラミングへ集中させる配置にしただけだ
    • 約3年前からGoogleはTLMという役割を体系的になくす方向に動き始めていた。当時の自分のマネージャーはスタッフレベルで、4人からレポートを受けるIC TLMだったが、強制的にEM（Engineering Manager）へ転換させられた。ここ3年ほどTLMは、過負荷状態のEMを補助する役割としてしか使われていなかった。実際に見たパターンでは、EM-IC-ジュニアという構造の中で、あるプロジェクトにマネージャーが適さないとき、シニアICが一時的にTLM役を担い、最終的には正式にEMへ移るか、再びICへ戻る形だった。身近で2回見た例はいずれも1〜2年後に再びICへ戻っており、TLMをやると70%はIC、70%はEMのような複合的な負担を感じることになった。今は公式にはTLMがなくなり、Principal EMが技術的な役割の大半を委任しつつ、正式な肩書きは与えない形になっている。自分もシニアICとしてプロジェクトCを任されたときに同じ経験をした
    • TLMという役割は常に罠のように感じていた。自分に提案されても絶対にやらない。表向きは50%コーディング、50%マネジメントとして売られるが、実際に期待されるのは80%コーディング、80%マネジメントだった
    • Googleは徐々に典型的な「テクニカルリード」モデルへ移行しているように感じる。リードは主にメンタリング役と権限を持つが、実際の管理は指揮系統上の別のマネージャーが担う構造だ。非公式にはテックリードがジュニアを指導できても、直接的な懲戒が必要なら別途マネージャーが介入しなければならない。TLM自体がビッグテック特有の文化なのかもしれないが、効率性は別として良いマネジメント構造ではないと思う
    • うちの会社にもTLMがいて、うまくいった例も失敗した例もあった。たいていはその役割を長く担っていた人で、1〜2人のジュニアがその人から知識を吸収する構図だった。ドメインが成長中でTLMがコードに継続的に関与していればうまく回ったが、失敗すると会社にとってROIが低く、誰にとっても良い経験ではなかった。ジュニアが成長してもドメインが小さいと昇進機会はほとんどなかった。TLMは自分の王国を守るだけで、年5〜10%の昇給を受けていることが多かった。資金が潤沢で採用が活発な時期には、こうしたポジションもキャリア成長の機会になり得るが、ヘッドカウントが固定されると結局は銀行のように毎年リストラするか、昇進不能の状態が起きる。だから2022年以降この役割がほとんど消えたのは偶然ではないと思う
    • この変化は良いことだと思う。技術とマネジメントの二重役割にいる人たちを見ると、いつもストレスが多く、やることが多すぎた。また、技術的に判断できるマネージャーがチームメンバーの技術的判断を承認または却下できると、パワーバランスの問題が生じる。TLMが変な技術的方向を押し進めても、その人が自分の評価や報酬まで握っているので、気軽に反論しづらい
  • <i>35%減少とは、3人未満を管理するマネージャーの数を指す</i> 管理人数が0〜2人なら、たいてい非効率な構造だと思う。Googleにどうしてこんなに多くのマネージャーが生まれたのか不思議だ。残りの65%は何をしているのか気になる
    • こうした小規模チームでは、マネージャーが時間の半分だけマネジメントし、残り半分はチーム業務に直接参加する構造が有効かもしれない。ただ、余裕がなければどちらもきちんとできない。パートタイムのマネージャーは組織内での影響力が低く、チームを十分に支えにくい。実際にこの構造を試したが、全員がエンジニアとして働く小さなポッド構成で、専任マネージャーにレポートする方式の方がよかった
    • 自分の経験では、組織再編や退職者の補充を制限すると、こういう構造が生まれる。最初は普通に何人も管理していたマネージャーが、時間の経過とともに人数が減ってこの形になる
    • 個人的には0人を管理するのがいい。誰かを管理しなければならない仕事なら、あまりやりたいとは思わない。本当に自立した1人くらいまでなら可能だ
    • 自分が入社した当時、L5への昇進を最も簡単にする方法の一つはマネージャーになることだと聞いた。それが当時本当に現実だったのかは分からないが、局所最適の結果としてこういうマネージャーが増えたのかもしれない。今ではL5で新たにマネージャーを置くことはないようだ
    • Google社員ではないが、自分の経験ではこういうケースはたいてい、将来ヘッドカウントが増えることを見込んで昇進が行われたものの、実際には転職や退職が繰り返されて管理人数が増えず、こじれていくことが多かった
  • 最初は非技術職の社員を解雇する。Googleのようなビッグテックは、コーディングが重要だからとそう言う。次に、コーダーを管理する中間管理職を解雇する。それでもまだコーディングが重要だと言う。その次には、各製品のドメイン専門家だった下位レベルのマネージャーも整理する。今回もコーディングに集中すべきだと言う。それでも足りず、次はシニアエンジニアも解雇するだろう。シニアはアーキテクチャ設計に時間を使いすぎる、とでも理由をつけるはずだ。それでもまだ足りないと言って、ついには一般のエンジニアまで解雇する。そうして最終的には、製品理解もない「純粋なコーダー」だけが残ることになる。最後にはジュニアも全員追い出して、Gregという1人だけが残り、webmaster of google dot comという肩書きでPHPを使ってGoogle全体を作り直すことになる、という冗談だ
    • もうすでに今そうやって繁栄しているのでは、という問いかけ
  • 開発チームのマネジメントは本当に難しい。良いマネージャーは周囲の状況にかかわらず、自分で価値を生み出している。それ以外の大半は環境に適応しつつ上ばかり見ており、結果として実質的な価値は乏しく、TPSレポートだけを出し続ける状態になっている
  • 最近、役員が社員に話す口ぶりを見ると本当に憂鬱になる。以前いた頃と比べて企業文化があまりにも変わったように思う
    • 2013年から2017年の間だけでも、企業文化が大きく変わったのを経験した
    • 上から腐り始める、という言葉がぴったりだ
  • 技術チームの一次マネージャーとしては5人が適正人数だと思う。10人まで行くと管理は不可能になる。マネジメントは時間のかかる仕事だ。もし10人を超えるチームなら、各自が独立的で主体的に動ける人員であるか、信頼できるラインマネージャーを追加で置く必要がある構造だ
    • 自分の経験では、人数対マネージャー比率は高いほどよかった。マネージャーがすべてに関与できないと、かえって委任が進み、不要なマネジメントも減らせた。最悪だったのは2〜3人ごとにマネージャーが1人付き、その上にもさらにマネージャーがいる構造だった。終わりのない会議、毎週の1:1、目標設定、各種の育成トレーニングなど、役に立たない仕事が増え続けた。マネージャーが自分の役割を誇示しようとして、不要に忙しいふりをし、チームの時間を浪費する
    • 5人程度のチームには、毎日30分のスタンドアップ、金曜のサマリーミーティング、週次1:1など、仕事そのものではない活動が追加で生まれる。5人チームに専任マネージャーが必要なら、そのグループには「大人」がいないということだ
    • 5人チームだと、たいていマネージャーは自分の存在意義を示すために不要な仕事を作り出す
    • 10人以上の大きなチームでは、各自が自立していなければならず、信頼できるラインマネージャーが必ず必要になる。自分がいたAppleのハードウェアチームがまさにそういう構造で、中間管理職の王国化を防ぐため、できる限りフラットな組織を目指していた
    • 直接5人だけを担当するマネージャーの下で働いたことはない。チームメンバーとしては5人くらいがちょうどよいが、マネージャーが複数チームを同時に持っていても大きな問題はなかった。マネージャーが全員の日常業務に細かく関与する必要はない
  • もうすぐ元GoogleのPMたちが「Googleではそうしていなかった」と言いながら、新しい職場で不満をまき散らす姿が見られそうだ
    • そういう現象はもう10年以上続いている
  • 35%が3人未満を管理しているという事実からして、なぜそういう人たちがマネージャーになったのか本当に気になる。思った以上にその肩書きが多いことが明らかになった点を見ると、統計自体が間違っているか、さもなければGoogleが本当に非効率なのだと思う
  • ビッグテック企業が不必要に肥大化するのは、リーダーシップが不足していて明確なビジョンを伝えられないからだと思う。もちろん簡単な問題ではないが、Appleは今もSteve Jobsのような人物のビジョンで持ちこたえている
    • 2018年のGoogleにはそういう印象を持っていた。最近は少し改善して組織が効率的になった面もあるが、CEOはいまだにオートパイロットのように感じる
  • 記事を3分の2ほど読んだところで、突然ページが消えてフッターに飛ばされた。戻ってみるとタイトルと要点だけが残り、ものすごいTaboola広告が表示されていた。記事提供元には、こういうUXは良くないと言いたい