元記事が言っていること
Cloudflare の Sunil Pai 氏が 2026年9月19日に公開した the senior engineer death spiral は、転職したばかりの友人に話した内容をそのまま文章にしたものだ。日本語では iwashi 氏の紹介ポスト で広まった。
筆者が挙げている失敗の流れはこうだ。転職・昇進・大きな案件を機に、自分を証明しようとして実力以上のエンジニアを演じる。過度に野心的な設計に挑み、数週間ほど音信不通になる。朝会では「順調です、そのうちお見せします」と言うが、見せられるものはない。焦って睡眠を削り、関係が壊れ、最悪の場合はバーンアウト・解雇・突然の退職に至る。
原因として、リモートワークとコーディングエージェントの普及で、以前のように隣の席で働く構造が失われ、個人の裁量が増えた代わりに孤立しやすくなったことを挙げている。処方箋は逆説的で、上のレベルを演じるのではなく、あえて一段下げてしばらく「最高のチームメイト」になるというものだ。放置されたバグ、誰も手をつけない雑務、ドキュメント。成果ベースではなく習慣ベースに切り替えて、日々の積み重ねを取り戻す。
以下は、この記事に対する私の見解である。
「何をしているか分からない人」が、いちばん危ない
私はシンシアの代表だが、いまも毎日コードを書いている。採用する側と発注する側の両方に立ちながら、書く側でもいる。その立場から見て、元記事の指摘で最も実務的だと思うのは、周囲から「あの人が何をやっているか分からない」と思われる状態が最大のリスクだという部分だ。
ここで起きているのは、能力の評価ではない。読めなさの評価である。進捗が見えない期間が続くと、周囲は「この人は難しいことに挑んでいるのだろう」とは考えない。「何が起きているか分からないので、当てにしていいか判断できない」と考える。そして、判断できないものは計画から外される。本人が気づくのは、外された後だ。
元記事はこれを、自分の仕事について話しすぎるくらいがちょうどいい、と表現している。品のいい言い方ではないが、実感としては正しい。共有はアピールではなく、相手の意思決定コストを下げる行為だからだ。
リモートとコーディングエージェントが、この失敗モードを増やした
元記事が原因として挙げているコーディングエージェントの影響について、私は少し違う角度から見ている。
以前は、詰まったら誰かに聞かないと前に進めなかった。その「聞く」という行為が、結果的に進捗の可視化を兼ねていた。いまはエージェントに聞けば、とりあえず前に進む。一人で抱えられる範囲が広がった分、詰まっていることが外から見えなくなった。 手が止まっていないので、本人も問題だと認識しにくい。
もう一つある。エージェントを使うと動くものが早く出る。ところが、動くことと業務に乗ることの距離は縮んでいない。運用コスト、監視、既存システムとの接続、データの整合。この部分の検証は相変わらず時間がかかる。早く出た手応えと、実際に完成に近づいた度合いのあいだに、以前より大きなずれが生まれている。 「あと少しで見せられます」が何週間も続く背景には、この錯覚があると考えている。
採用の現場でも同じ変化が起きている。AI を使えること自体は差にならなくなり、本番運用まで持っていけるかが見られるようになった。この評価軸の移り方は生成AIでエンジニアの仕事はなくなるのか｜採用する側が見ている評価軸の変化で詳しく書いている。
ITコンサルに移った人には、もっと強く出る
ここからは、このメディアの読者に引き寄せて書く。
この失敗モードは、エンジニアだけの話ではない。むしろ、SIer や事業会社の IT 部門からコンサルに移った人、あるいはファーム内で職位が上がった直後の人に、より強く出ると考えている。理由は三つある。
一つ目は、成果物が出るまでの期間が長い職種があることだ。実装であれば動くものが残るが、上流の検討は、出るまで何も見えない期間が構造的に長い。二つ目は、転職直後は「早く元が取れる人だと示さなければ」という圧力が最も強い時期だということ。三つ目は、コンサルでは成果を見せること自体が仕事の一部であり、隠れて挽回するという選択肢が、そもそも職務の定義と矛盾していることだ。
入社直後にやるべき最大の仕事は、難しい案件を取りに行くことではなく、期待値を擦り合わせることだと私は考えている。何を、いつまでに、どの水準で出せば「想定どおり」なのか。ここを握らないまま走ると、本人の努力量とは無関係に評価がずれる。入社後の立ち上がりについてはコンサル未経験でも成長できる？入社後のオンボーディングと育成の実態で整理している。
なお、追い込まれてからの個人の耐性の問題として処理しないほうがいい。コンサルでメンタルが保てない原因｜弱い・病むと感じる構造的要因と7つの習慣で扱っているように、多くは構造の側に原因がある。
「一段下げる」は、評価を下げるのか
元記事の処方箋のうち、日本の読者が最も抵抗を感じるのはここだろう。高い報酬で入ったのに雑務をやるのか、と。
採用する側の実感を書く。私が人を任せるかどうかを決めるときに見ているのは、難しいことができるかどうかよりも、任せたときに読めるかどうかだ。締切が守られる。守れないときは早めに言ってくる。抱えている問題が共有される。この三つが揃っている人には、次はもう少し大きいものを渡す。順序は逆にならない。
元記事はこれを、自分は評判を作る仕事をしているのであってソフトウェアはその下流にある、と表現している。言い方は強いが、採用や発注の実務と整合している。信頼の総量が先に増えないと、任される仕事の大きさは増えない。
だから「一段下げる」は、能力の申告を下げることではない。評価の軸を、一発の成果から、継続的な読めなさの解消に切り替えるという話だと理解している。
ただし、この処方箋が効かない場合がある
ここは元記事があまり踏み込んでいない部分なので、補っておきたい。
前提として、元記事は「周囲は善意で動いている」「いまのあなたを評価して採用した」という立場から書かれている。その前提が成り立っているなら、処方箋は有効だと思う。
しかし、そうでない場合がある。聞いていた職務範囲と実際が違う。欠員補充なのに新規立ち上げだと説明されていた。任される責任が増えないまま、評価上の責任だけが増えている。こうした期待値のミスマッチが構造的に存在する場合、「もっと貢献する」では解けない。 貢献の量を増やしても、評価される軸がずれたままだからだ。
この場合にやるべきなのは、頑張り方を変えることではなく、上長と職務範囲を定義し直すことである。それが動かないなら、残るか動くかの判断に進む。転職が正解だと言いたいのではない。現職で役割を再設計できる余地があるなら、そちらのほうが早いことも多い。 見極めの観点はコンサルタントに向いている人・向いていない人の特徴にまとめている。
区別の目安として、私は「共有を増やしたときに、周囲の反応が変わるかどうか」を見ている。変わるなら、問題は可視化の不足だった。変わらないなら、そもそも期待の中身が食い違っている。
私の結論
元記事の核心は、大きな仕事は大きな努力ではなく、毎日の地道な積み重ねで達成される、という一点だと読んだ。これは私自身、経営とコードを両方やってきて、何度も確かめさせられたことだ。
転職や昇進の直後は、最も証明したくなる時期であり、最も証明しなくていい時期でもある。採用した側は、いまのあなたを見て採用している。半年後の理想像を約束させたいわけではない。
技術者が次にどの方向へ広げるかという、もう少し長い時間軸の話はAI時代のエンジニアキャリア戦略｜今すぐ実践できる5つの方向性に整理してある。
まず、何をやっているかを読める状態にする。話はそこからで十分に間に合う。
次のキャリアの判断を整理したい方へ
転職や昇進の直後にどう立ち上がるか、いまの役割を再設計できるかどうかは、個別の状況によって答えが変わります。現職に残る選択も含めて整理したい場合は、無料のキャリア相談をご利用ください。
出典
- Sunil Pai「the senior engineer death spiral」2026年9月19日（2026年9月22日閲覧）
- iwashi / Yoshimasa Iwase 氏による紹介ポスト（X、2026年9月22日）
本稿の見解部分は筆者個人のものであり、元記事の著者の主張ではありません。
