Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。
"If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J
— DHH (@dhh) September 21, 2018
ジュニアを採用しない連中はシニアに値しない、というもの。
※なお本文中で「エンジニア」はソフトウェアエンジニアのことを指して使っています。「お前ハードのことなんも分からないくせにエンジニア名乗るなよ」という正義感に満ちたかっこいいツッコミはご遠慮下さい。どうせ僕は文系のアホです。
とても成功した企業がとてつもない愚かな決定をした話をさせてほしい。
我々はジュニアなエンジニアやインターンは雇わないことにしてるんだ…子犬を飼わなければ糞の片付けをせずに済む。
— Netflix
社畜連中が子犬をよくないものと見なしていること、またみんながそれを受け入れていることに唖然とした。子犬とは地球上で最もピュアな存在だ。文字通り遊びの時間とふわふわの毛でできている。孤独なこの世界の救いだ。話が脱線してしまった。
多くの企業が "経験者のみ" という採用戦略をとっている。理由を聞かれると以下のように答える。
- ジュニアエンジニアを雇うには時間もリソースも足りないから。我々は急いでるんだ。
- 会社にシニアエンジニアを雇う余裕があるからジュニアな人を雇う必要がない。
- 我々はいま間違いをおかすわけにはいかないんだ。ジュニアエンジニアを雇うのはリスクが大きすぎる。
- 我々は従業員に自律的に働いてもらってる。ジュニアエンジニアが必要とするような手取り足取りの支援をすることはできない。
- 未経験者を雇う前にプロダクトの基盤を固めておきたい。
ジュニアエンジニアを雇うことは企業が義務感から行うもの、あるいは会社の予算に悪影響を及ぼすものという認識で、ジュニアエンジニアは負債のようなものだと言っているに等しい。慈善活動をする余裕があって補助作業要員を置けるような大企業が雇えば良いと言ってるようにもとれるが、そんなやり方はできない。
アメリカには 10 万を超えるテック企業があるけど、どこの CEO も「ミスは大した問題にならない」とか「持ってる金はじゃぶじゃぶ使いたいね」なんて言わない。だから結局「経験者のみ」と言って近道をしたつもりになっていたとしても、それはアドバンテージにはならない。会社がきちんと運営されてないことを露呈するだけだ。
Hostility to junior developers is an easy way to spot a toxic company culture.
— April Wensel (@aprilwensel) August 1, 2017
ジュニアエンジニアを雇うかどうかは組織、開発体制、企業文化の健全性の物差しになる。熟練の開発者はそのことを知っている1。もしこの主張が聞き入れられなかったとしても、ジュニアエンジニアをバランス良く採用することは会社の財務を安定させる2ことは確かだ。
Preventing messes
ジュニアエンジニアは混乱を引き起こすから雇いたくないと拒否しているのであれば、それは会社に「ミスを許さない」文化があることを意図せず表明している。我が社はサーバーがダウンするたびに原因を作ったエンジニアをクビにしています、と言っているようなものだ。どんなに給料が高くてもすぐクビになる会社で働きたくないし、ミスをしないように開発者を脅すような文化はメンタルヘルスとプロダクティビティを阻害する。
こういう脅しの文化が自動化されたテストや QA 、フェイルオーバー、アクセス制限、バージョンコントロールなどを根付かせるんだとあなた言うかもしれない。しかし逆で、会社がフェイルセーフ技術を推奨し時間やリソースを与えるのであれば、「間違いを許さない」文化は不要で無価値だ。なぜならほとんどの不具合は production にリリースされる前に見つかって修正されるからだ。ジュニアエンジニアもシニアエンジニアも堅強な開発プロセスに守られてのびのび仕事ができる。
ジュニアエンジニアを雇い入れることは、過去に講じた不具合の予防策が機能しているか確認することができるまたとない機会ともいえる。彼らはシニアエンジニアよりもそういう罠にはまりがちだ。少しでも経験のあるエンジニアならみなそう言うように、ミス予防策の動作検証をしないということはあり得ないはずで、今やるかあとでやるかくらいしか選択肢がない。不具合が起こる可能性が残されているとき、ほとんどすぐにその不具合は起こる。どんなに経験があってもヒューマンエラーを完全に予防することはできない。
つまるところ少しのシニアエンジニアがいて開発基盤を固めてもらい、エラーに強い開発サイクルを構築すればよい。誰もジュニアエンジニアだけ雇えと言っているのではない。本当にミスをケアする職場であれば、ジュニアエンジニアもちゃんとフィットするし、シニアエンジニアも含めてみんなの満足度が高くなるはずだ。障害による炎上の火消しばかりやらなくて済むし、夜や週末はゆっくり休むことができる。
Saving money
Indeed.com によると、ジュニアエンジニアの給料の平均は $55,394 でシニアエンジニアの方は $117,374 だ。シニアエンジニアの給料は未熟な人の二倍以上だ。
コストには常に理由が必要だ。シニアエンジニアはジュニアな開発者よりも生産的であることが求められる。そんなに単純な話ではないが、ビジネスにかかるコストを無視するのは怠慢だし不利益を招く。
すべてのコードを書くのに長年の経験が必要なわけではない。良いコードを書く場合にだって必要ない。すべてのプログラムには、ありふれたやり方で入力と出力を結びつける「にかわのようなコード」が存在する。こういうのは誰が書いたって大差ない。時給 $28 の人に頼んでも時給 $59 の人に頼んでも結果は同じだ。もし熟練エンジニアしか雇わないのなら、そういった軽い仕事に余分なお金を払っているということになる。
コードは作るアプリケーションごとに結構変わるもので、慣れが生産性に大きく関わることがある。大抵のケースで、 6 ヶ月チームで仕事しているジュニアエンジニアと入ったばかりのシニアエンジニアでは、アプリケーションのドメインに詳しいという理由だけで前者の方が生産性が高かったりする。
先に述べた「にかわコード」とドメイン特化のコードを書くことは少なくとも開発業務の半分くらいを占める。その残りの部分で初めて熟練したシニアエンジニアの利点を活かせる。そしてたとえジュニアエンジニアであったとしても、十分な教材やベテランのメンターが付くことで難しい分野でもとても良い働きをしてくれることがある。
従ってジュニアとシニアのエンジニアでペアを組ませると二人のシニアエンジニアと同じだけの価値を発揮すると言える。しかもコストはシニア二人の場合の 75% しかかからない。もしあなたのゴールが最小の費用で最大の生産性を発揮することだとしたら、組織の中でジュニアとシニアの組み合わせを分子レベルでの最小単位とすべきだ。
加えて、シニアエンジニアばかり集めるとアルゴリズムやマイクロ秒単位の最適化、コーディングスタイルなど些細な事柄で延々議論をしてしまう傾向があることを考慮しなければならない。もし会社がシニアエンジニアだらけで、チームに堅実な意思決定プロセスが存在しなければ、数百時間分の人件費が議論のために失われることだろう。ジュニアエンジニアであればほとんどこういう問題を起こすことはない。
Building careers
ジュニアエンジニアを採用しないことによるもう一つのメッセージは、キャリア構築に対する無理解の表明だ。
Sometimes when companies say they're not hiring junior developers I want to shake them by their hoodies and yell, where do you think senior developers come from?!
— Kate Heddleston (@heddle317) September 13, 2018
これは会社の世間体とかテックコミュニティでの役割の話をしているのではない。あなたの会社をより働きやすくし、多くのエンジニアが入社し長く働いて会社に貢献してくれるようにするためのものだ。
数人のエンジニアが「やっと職位を変えることができたよ。もう職位を変えるのは嫌だ。一生シニアエンジニアでいたいね」と話しているのを聞いたことがある。しかし「給料なんて上がんなくていいよ。新しいことを学びたくもないし金輪際達成したことを評価されたくもないね」なんて言う人はいない。それに面倒なことに、向上心旺盛な野心家を引き留めるために必要なものは、無欲だが情熱的なシニアエンジニアを引き留めるのに必要なものとほとんど同じだ。仕事の成果を図るための評価軸と十分な研修用の教材、そして様々な種類の新旧のプロジェクトが必要だ。昇進を望まない少数の人に対しても、進歩や成長の意識を植え付ける必要がある。
しかしそういう連中に手をこまねかないでほしい。彼らは少数派だ。テック業界にいるエンジニアのほとんどが 40 年間もシニアエンジニアでいたいなんて思っていない。みんなソフトウェアアーキテクトだとか、チームリーダーだとか、 CTO だとか創業者になりたいと思っている。キャリア開発に関して無関心な企業は潜在的な従業員から働き先の最終候補にしか見てもらえない。
I only recruit senior devs.
— Reginald Braithwaite (@raganwald) September 17, 2018
The trick is, I recruit some of them earlier in their career.
エンジニアが面接を受けに来てもっとも感銘をうける言葉の一つはこういうものだ。「やぁ、僕はチームリーダーでこの会社に入って 8 年になる。最初はインターンだったんだ」。印象に残るがとても稀だ。こういう人は会社にとって非常に貴重だ。これまでの製品ラインの変遷を知っているし、半径 100 ヤード以内の各プロジェクトのコードを見てきている。組織の中の一人一人と一緒に仕事をした経験もある。他に誰もできないようなやり方で内側から会社を変革してくれるだろう。会社はこういう人の仕事で予測不可能なほどの利益を得るだろう。なぜなら社員を 8 年間（人生の 1/10 の時間に相当する）も同じ会社にとどまらせる方法を明らかにしたからだ。これは会社の文化醸成がうまくいっていることの証だ。職場のモラルは高く、良い仕事が評価され、社内の至る所で面白いプロジェクトが待ち受けていることを示す。
「ジュニアを雇わない」は、あなたの会社が誰かのキャリアの一部になる準備ができていないことを示している。会社が停滞していると公言しているのと同じだ。「我が社は経験豊富で能力の高いエンジニアを求めていて、金さえ払えば際限なく仕事をやってくれることを期待しています」。こういう求人に応募する人もいるだろうが、彼らは最善の仕事はしてくれないだろう。
もしあなたの会社がキャリア開発に真剣に取り組んでいるならば、ジュニアお断りポリシーは採用のパイプラインをしぼませ、従業員の在職期間を短くするだけだろう。
Making great software
ジュニアエンジニアにはシニア連中が普通失ってしまったようなユニークな特徴がある。その一つが盲目的な楽観思考だ。他に喜んで指示に従うというのもある。でも最も価値が高い特徴は、ジュニアは手ぶらであるということだ。シニアエンジニアの連中はこれまで技術の盛衰や失敗したプロジェクト、崩壊したチーム、その他の開発周りの罠を見てきている。彼らはその経験から強い意見を言い、時にそれは過度に一般化され、特定チームやプロジェクトでうまく行った（あるいは行かなかった）事柄を他のプロジェクトにも当てはまると思い込む。問題から新しい学びを得ることを避けるだろうことが明白だ。
Companies so eager to only hire senior people often forget that unlearning what doesn't apply can take longer than learning what does.
— DHH (@dhh) July 31, 2017
「あれがそこで使えなかったってことは知らなかったよ。でもここではうまく行くさ」と言うことがしばしばプロジェクトマネージャーの仕事になることがある。そのときジュニアエンジニアがその主張の裏付け役としてうってつけの存在になる。シニアエンジニアが長年かけて培った偏見なしに実証のためのプロトタイプを作ることができる。僕はジュニアエンジニアだったときによくこういう仕事をした。新しいツールや技術を試し、全く違うやり方で作り直したり、他の人が手を出すには早すぎると言ったことを実証試験したりしてきた。大抵僕はよりよい方法を見つけて、結果として会社のソフトウェアはかなり良くなった。ページ読み込みが遅かったところで一桁速度を改善したこともあるし、複数ページにまたがっていたものを一つにまとめ、将来のメンテナンスにかかる数週間分の工数を節約したし、時間を浪費する可能性があった不適切な技術を除外することもできた。技術的背景がまっさらでフレッシュな視点の有効性は無視できないものであることがわかる。
多くの会社が一束のシニアエンジニアを部屋に集めて問題解決方法について合意を得るための討論をさせている。しかし人件費の安い数名のジュニアエンジニアを加えるだけで一回きりの作業や野心的な取り組みに手を出しやすくなり、プロダクトに驚くべき成果をもたらすことができる。
ソフトウェアの品質に関しても、ジュニアエンジニアが感謝こそされないが重要な影響をもたらすことがある。彼らはシニアの連中が書きたがる頭でっかちでオーバーエンジニアリングなコードを書かない。
One underrated programmer attribute is the ability to write code that average or mediocre engineers can easily read, modify, and extend.
— Jamon Holmgren (@jamonholmgren) September 17, 2018
上のツイートで "凡人" と書かれているところを "ジュニア" に置き換えてみればこれがどういうことか分かるだろう。コードベースとはコードを書いている人々が重要だと思ったことが抽象化されて記録されているものだ。ジュニアエンジニアとシニアエンジニアの割合が健全であればコードはシンプルになり将来の改修も楽になる。
まとめると、テック業界で広がりを見せる「シニアのみ」の態度はジュニアエンジニアを低く評価している。これはみんな、特に未経験者の候補者を閉め出すことで採用を楽にしようという誤った考えをしている組織にとって損失でしかない。そういう会社は財務的に余裕があったとしても、無駄にしているお金と時間はとても多い。
もしあなたの会社がこういう問題に直面していたら、そしてもしあなたがジュニアエンジニアをどう雇い、どう教育すべきか知っていたら、ここで述べているベネフィットを享受することができるだろう。あなたの会社ではどんでん返しが減り、多様性が高く、競争による副作用も少なくて済むだろう。ソフトウェアは壊れにくくなり、輝きを放つようになるはずだ。もちろん、これだけがすべてではない。しかしジュニアエンジニアに対する積極的な採用方針はあらゆるレベルのエンジニアにとって働きやすさの指針になるはずだ。（翻訳ここまで）
ジュニアがいてもぶっ壊れない開発フローで思い出すのがペパボ時代のことだ。 Jenkins のセットアップがしたくて @hsbt さんがお守りをしていたプロジェクトの Jenkins 設定を参考にさせてもらってるときに、うっかりビルドを実行してしまって production へのデプロイが始まってしまった。青ざめたけど「 master からのデプロイなら全く問題ないように作ってあるので大丈夫」と言われてめっちゃカッケーなと思った。いま CI の仕組みを整えたり誰でも Hubot から簡単にデプロイしたりできるように頑張ってるののきっかけになってると思う。
