世界を動かす技術を、日本語で。

ねえ、初心者さん、私たちはあなたをタスクを完了させるために雇ったわけじゃないよ

概要

  • 新人エンジニアは「完了タスク数」よりも「成長と貢献度」が重視される
  • シニアエンジニアは新人をA・B・Cの3タイプに分類
  • Aになるには単なる作業量ではなく学びや周囲への影響が重要
  • Cシグナルの繰り返しは即NG、B以上を目指す姿勢が必須
  • タスク管理や自己成長への投資がキャリア成功の鍵

新人エンジニアが知るべき「成果」の本質

  • 新人が何タスクこなしたか は重視されない現実
  • シニアエンジニアは A(変革者)・B(安定)・C(戦力外) の3分類で新人を評価
  • シニアの本音は Aを全力支援・Bを適度支援・Cには最小限の労力 で済ませたいという方針
  • 自分がどのカテゴリに入りたいかを示すこと が新人の最優先課題
  • タスク自体は マネージャーやTech Leadなら短時間で終わる レベルであることが多い
  • 新人採用は「未来のエース育成」への投資という視点
  • 今日の生産性ではなく、将来の成長力 が本当の評価基準

タスク完了数は評価基準にならない理由

  • タスク40件完了のNoob Aと20件のNoob B、どちらが優秀かは不明
  • タスクの難易度や内容が分からなければ 数だけでは評価不能
  • 本当に求められるのは A・B・Cのどこに入るかを判断するための情報

BとCの分かれ目となる重要ポイント

  • コードが正しく動作すること
  • 自分の進捗や作業内容を周囲に共有できること
  • 見積もりの3倍以内で完了すること
  • 他人に不必要な負担をかけないこと
    • ヘルプを頼むのはOK
    • レビューで負担増→NG
    • オンコールやDevOpsに迷惑→大NG
  • 作業したふりや成果の偽装は即C認定
  • Cシグナルは誰でも出すが、同じ失敗を繰り返さないことが重要
  • 全体としてBシグナルが多い状態を目指す

A判定を得るためのシグナル

  • 不要なタスクであることを論理的に説明できる
  • 全体最適を考え、効果の大きい部分を発見できる
  • 複数のアプローチで実装できる柔軟性
  • タスクの実装だけでなく、設計改善や他部分の簡素化も提案
    • 先に難しい変更を簡単にする工夫も評価
  • 大きな差分よりも小さな差分をこまめに提出(理想は日次)
  • 内製ツールを作り、他タスクの効率化に貢献(類似タスクがある場合のみ)
  • 自チーム外にも有用な差分を提出(ただし本業優先)
  • 学びを社内で共有し、他者の役に立つアウトプット
  • 建設的かつ迅速なレビュー対応
  • 堅実なユニットテストの実装(理想はBシグナルだが現状はA扱い)

Aシグナルの特徴と時間管理

  • Aシグナルは単なるタスク完了よりも時間がかかる
  • ただし「終わらせること」が前提、無限に時間をかけて良いわけではない
  • 時間捻出のためのタスク・差分管理、自己成長のための投資が重要
  • 自己成長が他者の利益にもつながる行動が評価対象

まとめ

  • 新人の本当の価値は「将来への伸びしろ」と「周囲への貢献」
  • タスク数やスピードよりも、学び・改善・共有の姿勢を示すことがキャリア成功の鍵
  • 同じ失敗を繰り返さず、常にB以上を目指す意識が求められる

Hackerたちの意見

これに共感できたらいいんだけど、15年前に自分がジュニアだった時以来、ジュニアを雇う会社にはいなかったんだよね。

同じく。これは、初期段階のスタートアップでの経験とは全く合わない。

これは面白い視点だね(ジュニアが成長するための素晴らしいロードマップでもある)。でも、私の経験からすると、ほとんどの場合この主張は間違ってると思う。会社はジュニアを雇うのは、彼らを良いエンジニアに育てるための長期的な戦略じゃなくて、ジュニアレベルのタスクをこなす必要があるから雇うんだよ。

会社はジュニアを良いエンジニアに育てるための長期的な戦略で雇うわけじゃない。マネージャーとして会社で働いてきたけど、私はそういう意図で雇ったことがあるよ。管理職にそう言ったし、実際にそのために人を雇った。

もうそうじゃないね。そういうタスクはジーニーに任せて、ジュニアは見習いとして雇ってる。

確かにそういうことはあるし、ジュニアレベルの仕事は建設的だけど、私が経験して気づいたのは、会社が非常に優秀なジュニアを見つけて雇うために多くの努力をしていることだよ(インダストリアルプレースメント制度や卒業生の早期採用など)。そういう人たちが会社やプロジェクトに大きな価値をもたらすことに安全をかけられるからね。大きな会社の中には、明確な5年のキャリアロードマップを持って、相互に利益のある関係を築こうとするところもある(特定の業界では、優秀な候補者がフィンテックを選ぶのに苦労しているけど)。私は、定量的にも定性的にも経験豊富な中堅プログラマーを大きく上回る高パフォーマンスのジュニアプログラマーと働いたことがあるから、彼らに投資することを常に支持しているよ。

ドットコムバブルの前は、明確にジュニアエンジニアを育てるために採用してた。5年で権利が発生するストックオプションは、みんなの時間を価値あるものにするためのものだった。

彼らは、完了する必要のあるジュニアレベルのタスクがあるからジュニアを雇う。 そんな会社には一度も働いたことがない。シニア開発者がタスクをこなすか、重要でないからカットするかのどちらかだった。ジュニアを雇った理由は、潜在能力を見込んで、しっかりした同僚に成長できると思ったからだ。

Bレベルについて: > * 他の人に不合理な量の仕事を押し付けてはいけない。* これは注意が必要だね。後に挙げられている例、例えばオンコールのインシデントやコードの追加レビューは、必ずしも新人のせいじゃないから。私のキャリアはまだ4年だけど、間違ったことをしたり、もっと良くするためのポイントについて関わることはすごく価値があると思う。私の立場からすると、失敗すること自体は問題じゃない。チームと協力して回復し、学ぶことができるならね。

私もそう思う。レビュー段階で止めなかったなら、それはチームの問題だよ。「Xのコードが本番を壊した」ってわけじゃないからね。アットウィルの環境では、Xは文句を言う暇もなく去ってしまう可能性がある。その場合も結局はチームの問題になる。マージするものはみんなで責任を持つようにしよう。

この記事、自己中心的で毒のあるシニア開発者の視点が強い気がする。あなたの意見には賛成だな。「不合理な仕事を生み出さない」ってのは、あんまり良いサインじゃないと思う。全く仕事をしなければ「不合理な仕事を生み出さない」カテゴリーに入っちゃうし、それは良いサインじゃないよね。それに「あなたのマネージャーやテックリードは、あなたを手助けするよりもずっと短時間で、手間も少なくそれを終わらせられる」ってのは、彼が優秀なジュニアを雇ってないってことを示唆してる。優秀なシニア開発者の仕事は、ジュニアがシステム全体を崩壊させないようにタスクを設計して範囲を決めることだと思う。

この記事は、毒のある責任転嫁文化のある会社のように感じる。重要な航空宇宙分野がノーブレームでやってるなら、ソフトウェアもそうできるはず。もちろん、無駄にならないように努力は必要だけど、会社にガードレールがないのは彼らの責任じゃないよね。インターンが何かを削除した場合、そもそもなんでアクセス権があったの?バックアップはなかったの?

Hacker Newsで議論の続きを見る