マネージャーになるということの真実 — シニアエンジニアに会議が足される話ではない

はじめに — 14の「真実」に共通するもの
出力関数が変わる — グローブの等式
個人スループットという指標が機能しなくなる三つの理由
フィードバックループが遅くなり、読みにくくなる
最初の6か月に繰り返される三つの失敗
数字を探すとほとんどありません
ICに戻るべきかを判断する方法
おわりに — うまくやれているか分からない状態をデフォルトとして受け入れること
参考資料

はじめに — 14の「真実」に共通するもの

2026年7月29日、GeekNewsに「マネージャーになるということの真実」という項目が投稿され、41ポイントを集めました。原文はSofia Kodarという個人ブロガーが6月21日に書いたThe truth about being a managerで、その2日後の6月23日にはHacker Newsに投稿され、113ポイントと64件のコメントを集めました。

まず、この文章の性格をはっきりさせておく必要があります。これは研究ではなく個人の経験を書いたエッセイです。統計もなく、引用された論文もなく、標本もありません。著者が自ら明かした経歴（約11年のマネージャー経験）が唯一の根拠であり、その経歴も外部から検証する方法がありません。ですから「真実」というタイトルは、著者にとっての真実という意味で読むのが正しいでしょう。

とはいえ、こうした文章が繰り返し上位に上がるという事実そのものが情報です。14の項目を並べて眺めると、そのほとんどが一つのことを別の角度から語っています — もはやチームの一員ではない、通りすがりに言った一言が指示として解釈される、孤独である、口にできない情報を抱えて歩く、日単位で進捗が見えない。仕事量が増えたという話ではありません。仕事の種類が変わったという話です。

原文はその理由を説明しません。この記事はその構造を説明します。マネージャーになるということは、シニアエンジニアの役割に会議が乗る話ではなく、出力関数そのものが入れ替わる話です。そしてその入れ替えの副作用は、ほとんどが一つの原因から生まれます — フィードバックループが遅くなり、読みにくくなるのです。

出力関数が変わる — グローブの等式

アンディ・グローブがHigh Output Managementの管理レバレッジの章で示した定義は単純です。マネージャーの出力は、自分の組織が出した出力に、自分の影響下にある隣接組織が出した出力を足した値です。

この定義で実際に重要なのは等式の右辺ではなく、その手前にある区別です。グローブは活動（activity）と出力（output）を分離します。1日に会議を8つこなし、意思決定を12件下したのは活動です。出力は、そのチームがその四半期に出したものです。両者は相関しますが同じではなく、相関の向きすら自明ではありません。

ICのときはこの区別がほとんど必要ありません。活動と出力の距離が短いからです。コードを書くという活動は、マージされた変更という出力へ数時間から数日でつながり、その間に介在する他人の数も少なくて済みます。マネージャーになった瞬間、この間に人と時間が割り込みます。今日行った1on1の出力は、今四半期ではなく次の四半期に、しかも他人の手を経て現れます。

ここから最初の実務的な結論が出ます。マネージャー職でうまくやれているかを判断するには、IC時代に使っていた指標を捨てるのではなく、その指標がなぜ誤作動するのかを理解する必要があります。

個人スループットという指標が機能しなくなる三つの理由

IC時代の自己評価の仕方は、たいてい個人スループットです。今週何をマージしたか、インシデントをいくつ収めたか、設計文書をいくつ書いたか。この指標は、マネージャーにとって三つの理由で壊れます。

第一に、直接競合します。個人スループットを維持するには、チームの出力を作るために使う時間を削らなければなりません。1on1を後ろ倒しにし、採用面接を人に回し、隣接チームとの調整を先送りすれば、今週の個人スループットは維持されます。グローブの等式で、左辺を守るために右辺を削っているわけです。

第二に、チームの学習総量が減ります。マネージャーが直接処理する仕事は、たいてい最も難しく、最も面白く、学習価値が高い仕事です。締め切りが迫ったときにマネージャーがその仕事を引き取れば、短期的には英雄になりますが、その仕事から学ぶはずだった人は学べません。Camille Fournierが新任マネージャーのよくある失敗として、技術的な意思決定を委譲せず抱え込むパターンを指摘したのも同じ文脈です（ただし私はこの文章の本文を直接確認できておらず、タイトルと要旨だけを確認しました）。

第三に、ボトルネックになります。個人スループットが高いマネージャーは、自分の承認、自分のレビュー、自分の知識に依存する経路を作り出します。その経路は、マネージャーが休暇に入った瞬間に露呈します。

管理範囲の数字を重ねると、絵はもっと明確になります。Will LarsonはSizing engineering teams（2018年7月14日）で、マネージャーが能動的にコーチングし調整できる上限を6人から8人と見ています。その上、おおよそ8人から9人を超えると、マネージャーの役割はコーチではなく「問題が起きたときの安全網」に縮小されると書いています。逆に4人未満は、チームというより個人の集合に近いと見ます。これらの数字が語っているのは組織図の形ではなく時間予算です。6人から8人という範囲は、能動的なコーチングに必要な時間を勤務時間で割った結果に近く、個人スループットはまさにその予算から出てきます。

フィードバックループが遅くなり、読みにくくなる

副作用に共通する原因はここにあります。表に整理するとこうなります。

軸	IC	マネージャー
出力の単位	マージされた変更、復旧した障害	チームが四半期に出した成果
フィードバック遅延	分から日の単位（CI、レビュー、デプロイ）	週から四半期の単位（採用の結果は半年、組織変更の効果は1年）
判読可能性	高い。テストが赤なら間違っている	低い。チームがうまく回っているのが自分のおかげなのか、もともと良い人が集まったからなのか区別できない
失敗のシグナル	即座に、自動で届く	遅れて届き、たいていは人を介してしか届かない
修正コスト	低い。戻せばよい	高い。信頼はロールバックできない

この表で最も重要な行は判読可能性です。遅延だけが問題なら我慢すれば済みます。本当の問題は信号対雑音比です。チームの成果には、マネージャーの寄与のほかに採用市場、プロダクトの方向、隣接チームの状態、そして単なる運がすべて混ざり込みます。ですから良い四半期が自分の実力の証拠だという保証はなく、悪い四半期が自分の落ち度の証拠だという保証もありません。

学習はフィードバックループの関数です。ループが四半期単位でノイズが大きければ、事実上、教師あり学習が成立しません。ここから二つ目の実務的な結論が出ます。マネージャーの成長は自然発生しません。計測を自分で作らなければなりません。具体的には次の三つが役に立ちます。

意思決定ログ。どんな決定を、いつ、どんな根拠で、どんな結果を予想して下したのかを1行残します。四半期末に予測と結果を突き合わせれば、ノイズの中から自分の判断の偏りだけを取り出して見られます。
先行指標。四半期の結果は遅れて来ますが、1on1で悪い知らせがどれだけ早く上がってくるか、オンコールの引き継ぎがどれだけ静かか、設計レビューで反対意見が出るかといったことは週単位で観察できます。
外部の観察者。判読可能性の低いシグナルを読む最も安上がりな方法は、同じ組織を別の角度から見ている人（同僚のマネージャー、スタッフエンジニア）に定期的に尋ねることです。

最初の6か月に繰り返される三つの失敗

原文の14項目、HNのコメント、そして広く読まれている管理文献に繰り返し現れる失敗モードは、おおよそ三つに収束します。

個人スループットを手放せません。最もよくある失敗です。スプリント後半に自分でコードを書いて穴を埋め、難しいインシデントを自分で処理します。前節で見たとおり、これは短期の利得と長期の損失を交換する取引ですが、問題はこの取引の損失側が6か月後になってようやく見えることです。フィードバックループが遅いという事実こそが、この失敗を長く生き延びさせます。

言葉の重さを見誤ります。原文で最も的確な指摘だと私が思う部分です。IC時代の「これ、ちょっとおかしくないですか?」は質問でしたが、マネージャーの同じ一文は2週間のリファクタリングになって返ってきます。指示する意図がなかったということは何の防御にもなりません。これは話し手の意図ではなく、聞き手のリスク計算の問題だからです。実務的な解決策は意図にラベルを貼ることです — これは声に出して考えている最中で決定ではない、あるいはこれは決定である、と毎回明示するほうがましです。

難しい会話を先延ばしにします。成果の問題を最初の四半期に伝えなければ、次の四半期にはもっと伝えにくくなります。沈黙が長いほど相手の立場では突然の通告になり、そのときは内容の正当性と無関係に手続きの問題になります。Camille FournierがI hate manager READMEs（2018年11月23日）で述べた指摘がここにそのまま当てはまります。信頼は自己紹介文書で作られるものではなく、予測可能で倫理的な行動が繰り返されることで積み上がる、ということです。難しい会話を適時に行うことは、その繰り返しの一部です。

HNのコメントには原文への反論もいくつかあり、そのうち三つは実際に心に留める価値があります。あるコメントは、マネージャーは悪い決定を「売り込む」べきだという原文の主張に真っ向から反対し、透明なマネージャーのほうが結果的に信頼を得ること、そして偽の前向きさを向けられた側はそれを見抜くことを指摘します。別のコメントは、シニアICも会議、ステークホルダー管理、権限なきリーダーシップというほぼ同じ負担を負う点で、原文が描いたICとマネージャーの境界は実際より鮮明すぎると見ます。さらに別のコメントは、経験が積み上がれば実務とリーダーシップの両立が可能になるとして、原文が良い候補者を怖がらせて追い払う危険を指摘します。

数字を探すとほとんどありません

このテーマで最も頻繁に引用される数字は「新任マネージャーの60%が24か月以内に失敗する」です。たいていCEB（現Gartner）出典として付きます。この記事を書きながら元の報告書を探しましたが、年も標本も方法論も確認できませんでした。数十のメディアやブログが引用していますが、すべてが互いを引用しており、原典へつながるリンクがありません。ゾンビ統計として扱うのが安全です。その近くでよく一緒に引用されるLeadership IQの46%という数値は実在する調査ではありますが、新任マネージャーではなく新規入社者全般を対象にしたものなので、この文脈にそのまま使うことはできません。

逆に出典がはっきりしているものもあります。DDIのGlobal Leadership Forecast 2025は、リーダー10,796人とHR専門家2,185人を50か国以上で調査した11版目ですが、ストレスを抱えるリーダーの40%が、ウェルビーイングのためにリーダー職を離れることを検討したことがあると答えました。これは失敗率ではなく離職意向ですが、少なくとも標本と方法論が公開されています。

正直に書いておくと、エンジニアがマネージャーになってからICに戻る割合についての信頼できる統計は見つかりませんでした。広く語られる話は多いものの、引用可能な調査はありません。この事実自体が、このテーマの読み方を教えてくれます — ICからマネージャーへの移行についての助言はほぼすべてが経験談であり、経験談として読むべきです。その多くが互いに矛盾する理由もそこにあります。

ICに戻るべきかを判断する方法

このテーマの標準的な参照点はCharity MajorsのThe Engineer/Manager Pendulum（2017年5月11日）です。核心は三つです。マネジメントは昇進ではなく並行するトラックへの水平移動であること、最良の一線のエンジニアリングマネージャーは実務から2年から3年以上離れていないこと、そしてエンジニアリングとマネジメントは一度に一方しか上達しないことです。

この文章も研究ではなく視点です。引用された根拠はなく、本人が明かした出典は当時のSarah Meiとの対話です。興味深いのは、この文章への本格的な反論を見つけられなかったという点ですが、これは合意が成立したという意味というより、この領域に反証可能なデータがないという意味に近いでしょう。

その上で、私の意見を付け加えるなら、判断基準はこう分かれます。

戻る理由にならないものから見ます。今四半期がつらいということは理由になりません。前に見たとおり、最初の6か月はフィードバックループが遅く判読が難しい状態を初めて経験する時期であり、その不快感は失敗のシグナルではなく役割のデフォルトです。コーディングが恋しいということも、それ自体では理由になりません。週末プロジェクトで解消される種類なのかをまず確かめてみる価値があります。

戻る理由になるのは三つだと考えます。

12か月から18か月が過ぎたのに、チームの出力が自分が来る前と区別できないとき。ただしこれを判断するには、前節の計測をあらかじめ仕込んでおく必要があります。計測なしで下すこの判断は、たいていその日の気分です。
マネージャーの仕事の「良い日」がどんな形なのか、いまだに描けないとき。どんな1日がよく過ごした1日だったのかを自分で定義できないなら、その役割で改善の方向が定義されません。
組織がマネージャーに実際のレバーを与えないとき。採用、報酬、方向についての権限がないのに結果への責任だけがあるなら、グローブの等式は成立しません。これは個人の適性の問題ではなく席の問題であり、席を変えるほうが早いです。

戻ることを計画するなら、コストも一緒に見なければなりません。振り子モデルに従えば往復そのものは資産ですが、実際に失うものが一つあります — シニアICトラックで過ごしたはずの時間です。マネージャーとして過ごした2年は、スタッフエンジニアトラックでの2年ではありません。これは振り子モデルがうまく扱わない部分であり、決めるときに計算に入れるのが誠実です。

おわりに — うまくやれているか分からない状態をデフォルトとして受け入れること

整理するとこうなります。

マネージャーになるということは仕事量が増えることではなく、出力関数が入れ替わることです。グローブの定義どおり出力がチームの出力に変わると、活動と出力の間に人と時間が割り込みます。
その結果フィードバックループが分単位から四半期単位へ伸び、信号対雑音比が悪化します。原文が並べた14の症状のほとんどはここから派生します。
個人スループットはマネージャーの指標として三つの理由で壊れます。時間予算と直接競合し、チームの学習総量を減らし、ボトルネックを作ります。
この移行についての助言はほとんどが検証されていない経験談です。広く出回る失敗率の統計は元の出典を見つけられません。
ICに戻るかどうかは気分ではなく計測で判断するほうがよく、その計測は移行の初日から作っておいてこそ使えます。

ループが遅いシステムを運用したことがある人なら、すでに知っている感覚です。観測遅延が大きいシステムでは、即座の確信のほうが危険信号です。マネージャー職も同じです。うまくやれているという確信が毎週わく状態が正常なのではなく、うまくやれているか分からない状態がデフォルトであり、その上に計測を乗せることが仕事です。