年収に見合うエンジニアの秘密: 「わからないこと（Ambiguity）」を「できること」に変える技術

要点:

• シニアとミドルレベルのエンジニアを分ける決定的な違いは、不確実で曖昧な問題を具体化する能力にある。
• シニアの価値はコーディング技術そのものではなく、プロジェクトのリスクを取り除き、実行可能な計画へと変換する点にある。
• 現在の採用慣行（アルゴリズムテストなど）は、こうした能力を評価できていない。
• 本当の成長は、コーディング前の段階で問題を明確に定義する練習から始まる。

---

序論: シニアエンジニアの定義を考え直す

• 一般にシニアエンジニアは、アーキテクチャ設計、コミュニケーション、リーダーシップなど、さまざまなスキルの一覧で定義される。
• しかし、肩書き、年収、経験年数を除いて考えると、シニア以上のエンジニアを分ける唯一の中核スキルは 「曖昧さを減らす能力」 である。
• 他のあらゆる能力（技術的な実行など）は、この中核スキルを土台として派生する結果にすぎない。

本文

1. 問題解決の進め方の違い: 明確さ vs 曖昧さ

• ミドルレベル（Mid-level）エンジニア: 明確な仕様（Spec）と制約条件が与えられたときに優れた成果を出す。よく定義された問題を解くのが得意である。
• シニアエンジニア: 「パフォーマンス改善が必要」「ユーザーの不満が増えている」「スケーラビリティを考慮」といった、不明瞭で抽象的な要求を受けたときに違いが現れる。
• シニアは曖昧な問題を単にこなすのではなく、それを分析し、分解し、具体的なタスクへと変換する。

2. シニアの中核的な役割は、プロジェクトのリスクを取り除くこと

• シニアエンジニアは、大きく抽象的な問題を前にして、次のようなアプローチで不確実性を解消する:

• 他の人がしない本質的な問いを立てる。

• 重要なシグナルとノイズ（Noise）を切り分ける。

• 今すぐ実行することと後回しにすることの優先順位を決める。

• この過程はプロジェクトのリスクを下げ（De-risking）、「何なのかまだわからない状態」を「実行可能な小さなプロジェクトと取り除くべき要素」へと整理する。

• シニアがこれをうまく行うと、プロジェクトは滑らかに進み、見た目には簡単そうに見える。しかし実際には、その前段で膨大な「見えない仕事」が行われている結果である。

3. 曖昧さを解消するための具体的なアプローチ

• シニアエンジニアは、コーディングに先立って問題を明確にするために、次のような問いを投げかける:
• 問題の本質: 私たちが望んでいる解決策ではなく、実際に解決しようとしている根本問題は何か。
• ユーザーの定義: 具体的に誰のどんな痛みを解決しようとしているのか。 （「ユーザー」という包括的な言葉は避ける）
• 仮説の検証: 現在の計画に潜んでいる誤った前提は何か。
• リスク評価: 私たちの判断が間違っていた場合に起こりうる最悪の事態は何か。

4. 採用システムの限界と、誤ったシニア選抜

• ほとんどの企業は、技術スタックの一覧やアルゴリズム問題の解答力（LeetCode）に集中して採用を進めている。
• こうした方式では、曖昧なプロダクト要件を実行可能な計画へ変換する能力を検証できない。
• その結果、コーディング力は高いのに、不完全な仕様を前にすると何もできない「見かけだけのシニア」エンジニアが量産される。

結論: 成長のための提言

• アーキテクチャやコミュニケーション能力も重要だが、それらが価値を発揮するのは 「何を作るか」 が明確になってからである。
• 曖昧さを減らせないままの技術的優秀さは、「間違った問題を優雅に解いている」にすぎない。
• 自分がシニアレベルかどうかを判断する基準は、抽象的な課題を受け取ったとき、他人が明確化してくれるのを待つのか、それとも自分でチームが実行できる形に具体化するのかにかかっている。
• これは生まれつきの才能ではなく練習の領域なので、曖昧なチケット（業務）を受け取ったときは、すぐにコーディングするのではなく、問題を具体化する訓練を始めるべきである。

[mhj5730]

シニア開発者を「アルゴリズムのコーディングテスト」で見極めようとするプロセスは、私も……採用システムの限界だと思います。何か問題の本質に近づいた人、近づける人こそが、年俸に見合うシニア開発者なのだと思います。

[elbanic]

視点によって解釈がさまざまだということをこの記事で学びました。私の基準では、シニアと中堅エンジニアを分ける基準は単にスコープだと思います。
Ambiguityを具体化するのはエンジニアの基本的な素養であり、中堅エンジニアからはこれができてこそエンジニアというタイトルがふさわしいように思います。ですから私にとっては、この記事は中堅エンジニアと初級（associate）エンジニアを分ける基準になり得ます。

[mbh023]

問題を明確に定義できていない状態での
技術的な卓越性は、「間違った問題を優雅に解決すること」にすぎない。

本当にゾッとする一文

[bichi]

シニア開発者のテストで、プログラミングテストまではまだあり得るとしても、
アルゴリズム問題を出されたらあまりにも呆れてしまいます（動揺しすぎて記憶にも残っていません）

[baeba]

1. 質問の技術と社会関係資本（Social Capital）

• 戦略的無知: シニアの質問は無知から生まれるのではなく、不確実性を取り除くための意図的な行為である。初歩的な質問（「この略語は何か？」）を恥ずかしがらずに投げかけることが重要な能力だ。
• 社会関係資本の活用: ジュニアと違ってシニアは「社会関係資本（信頼）」が築かれているため、「ばかな質問」をしても無能だと評価されない。これを活用して会議の曖昧さを取り除くのがシニアの役割だ。
• 政治的文脈への配慮: 明確さを嫌うマネージャーに対しては、率直な質問が脅威になり得る。したがって、政治的に安全でありながらプロジェクトを前進させる質問を選び取る高度な立ち回りが求められる。

2. 自律性とリスク管理（Autonomy & Risk）

• 安全網のない問題解決: 外部の助けや明確な指針がなくても、自力で問題を突破（Plough through）してやり遂げる能力がシニアの基準となる。
• カオス（Chaos）の制御: 無条件に明確さを求めるのではなく、状況に応じて「停止」と「前進」を判断する。完璧な仕様を待つより、適切な仮定を置いて実行（Ship）することで混乱を減らす。
• 計算されたリスクの引き受け: コンパイルできないコードをランタイムで修正したり、大規模なリファクタリングを断行したりするなど、ジュニアにはできない大胆な技術的判断を下し、その結果に責任を負う。

3. 肩書きのインフレと採用の構造的矛盾

• 肩書きのインフレ（Title Inflation）: 成果指標を達成するため、準備のできていないジュニアをシニアに昇進させる慣行が蔓延している。その結果、タイトルと実際の能力の間に乖離が生じる。
• 採用手法の限界: 企業は曖昧な要件を具体化する能力ではなく、アルゴリズム（LeetCode）の問題を解く能力ばかりに注目して採用している。その結果、「仕様がなければ何もできないシニア」が量産される。
• PM役割の代行: シニアエンジニアが、怠惰なPMの投げた不完全な企画（Half-baked spec）を具体化することに時間を費やす現象が起きている。これはエンジニアの能力の表れでもあるが、組織的非効率の証拠でもある。

4. 単純な勤続年数（Tenure）と意図的鍛錬

• 経歴の質的差: 「10年の成長」と「1年の経験を10回繰り返しただけ」は明確に区別されるべきだ。真のシニアは、慣れた領域を離れた意図的な練習と挑戦を通じて形成される。
• If vs What-if: ジュニアは与えられた条件（If）を処理することに集中するが、シニアは条件が変わった場合（What-if）を想定して備える。
• 成長段階の定義: 業界で一般的な基準は、「指導を受ける段階（Junior）」→「独立して遂行する段階（Regular）」→「他者を指導する段階（Senior）」に分けられる。

5. シニアという肩書きへの懐疑的な見方

• 単なる給与等級（Pay Grade）: シニアという呼称は能力の指標というより、HRが給与を決めるために作った行政的な分類にすぎない、という冷笑的な見方がある。
• 企業間の格差: ビッグテック企業のシニア（高い曖昧性と広い範囲の課題を解決する）と、一般企業のシニア（単なる長期勤続者）との間には、能力面でも待遇面でも非常に大きな差がある。