| @労働

Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。

ジュニアを採用しない連中はシニアに値しない、というもの。

※なお本文中で「エンジニア」はソフトウェアエンジニアのことを指して使っています。


とても成功した企業がとてつもない愚かな決定をした話をさせてほしい。

我々はジュニアなエンジニアやインターンは雇わないことにしてるんだ…子犬を飼わなければ糞の片付けをせずに済む。

Netflix

社畜連中が子犬をよくないものと見なしていること、またみんながそれを受け入れていることに唖然とした。子犬とは地球上で最もピュアな存在だ。文字通り遊びの時間とふわふわの毛でできている。孤独なこの世界の救いだ。話が脱線してしまった。

多くの企業が "経験者のみ" という採用戦略をとっている。理由を聞かれると以下のように答える。

  • ジュニアエンジニアを雇うには時間もリソースも足りないから。我々は急いでるんだ。
  • 会社にシニアエンジニアを雇う余裕があるからジュニアな人を雇う必要がない。
  • 我々はいま間違いをおかすわけにはいかないんだ。ジュニアエンジニアを雇うのはリスクが大きすぎる。
  • 我々は従業員に自律的に働いてもらってる。ジュニアエンジニアが必要とするような手取り足取りの支援をすることはできない。
  • 未経験者を雇う前にプロダクトの基盤を固めておきたい。

ジュニアエンジニアを雇うことは企業が義務感から行うもの、あるいは会社の予算に悪影響を及ぼすものという認識で、ジュニアエンジニアは負債のようなものだと言っているに等しい。慈善活動をする余裕があって補助作業要員を置けるような大企業が雇えば良いと言ってるようにもとれるが、そんなやり方はできない。

アメリカには 10 万を超えるテック企業があるけど、どこの CEO も「ミスは大した問題にならない」とか「持ってる金はじゃぶじゃぶ使いたいね」なんて言わない。だから結局「経験者のみ」と言って近道をしたつもりになっていたとしても、それはアドバンテージにはならない。会社がきちんと運営されてないことを露呈するだけだ。

ジュニアエンジニアを雇うかどうかは組織、開発体制、企業文化の健全性の物差しになる。熟練の開発者はそのことを知っている1。もしこの主張が聞き入れられなかったとしても、ジュニアエンジニアをバランス良く採用することは会社の財務を安定させる2ことは確かだ。

Preventing messes

ジュニアエンジニアは混乱を引き起こすから雇いたくないと拒否しているのであれば、それは会社に「ミスを許さない」文化があることを意図せず表明している。我が社はサーバーがダウンするたびに原因を作ったエンジニアをクビにしています、と言っているようなものだ。どんなに給料が高くてもすぐクビになる会社で働きたくないし、ミスをしないように開発者を脅すような文化はメンタルヘルスとプロダクティビティを阻害する。

こういう脅しの文化が自動化されたテストや QA 、フェイルオーバー、アクセス制限、バージョンコントロールなどを根付かせるんだとあなた言うかもしれない。しかし逆で、会社がフェイルセーフ技術を推奨し時間やリソースを与えるのであれば、「間違いを許さない」文化は不要で無価値だ。なぜならほとんどの不具合は production にリリースされる前に見つかって修正されるからだ。ジュニアエンジニアもシニアエンジニアも堅強な開発プロセスに守られてのびのび仕事ができる。

ジュニアエンジニアを雇い入れることは、過去に講じた不具合の予防策が機能しているか確認することができるまたとない機会ともいえる。彼らはシニアエンジニアよりもそういう罠にはまりがちだ。少しでも経験のあるエンジニアならみなそう言うように、ミス予防策の動作検証をしないということはあり得ないはずで、今やるかあとでやるかくらいしか選択肢がない。不具合が起こる可能性が残されているとき、ほとんどすぐにその不具合は起こる。どんなに経験があってもヒューマンエラーを完全に予防することはできない。

つまるところ少しのシニアエンジニアがいて開発基盤を固めてもらい、エラーに強い開発サイクルを構築すればよい。誰もジュニアエンジニアだけ雇えと言っているのではない。本当にミスをケアする職場であれば、ジュニアエンジニアもちゃんとフィットするし、シニアエンジニアも含めてみんなの満足度が高くなるはずだ。障害による炎上の火消しばかりやらなくて済むし、夜や週末はゆっくり休むことができる。

Saving money

Indeed.com によると、ジュニアエンジニアの給料の平均は $55,394 でシニアエンジニアの方は $117,374 だ。シニアエンジニアの給料は未熟な人の二倍以上だ。

コストには常に理由が必要だ。シニアエンジニアはジュニアな開発者よりも生産的であることが求められる。そんなに単純な話ではないが、ビジネスにかかるコストを無視するのは怠慢だし不利益を招く。

すべてのコードを書くのに長年の経験が必要なわけではない。良いコードを書く場合にだって必要ない。すべてのプログラムには、ありふれたやり方で入力と出力を結びつける「にかわのようなコード」が存在する。こういうのは誰が書いたって大差ない。時給 $28 の人に頼んでも時給 $59 の人に頼んでも結果は同じだ。もし熟練エンジニアしか雇わないのなら、そういった軽い仕事に余分なお金を払っているということになる。

コードは作るアプリケーションごとに結構変わるもので、慣れが生産性に大きく関わることがある。大抵のケースで、 6 ヶ月チームで仕事しているジュニアエンジニアと入ったばかりのシニアエンジニアでは、アプリケーションのドメインに詳しいという理由だけで前者の方が生産性が高かったりする。

先に述べた「にかわコード」とドメイン特化のコードを書くことは少なくとも開発業務の半分くらいを占める。その残りの部分で初めて熟練したシニアエンジニアの利点を活かせる。そしてたとえジュニアエンジニアであったとしても、十分な教材やベテランのメンターが付くことで難しい分野でもとても良い働きをしてくれることがある。

従ってジュニアとシニアのエンジニアでペアを組ませると二人のシニアエンジニアと同じだけの価値を発揮すると言える。しかもコストはシニア二人の場合の 75% しかかからない。もしあなたのゴールが最小の費用で最大の生産性を発揮することだとしたら、組織の中でジュニアとシニアの組み合わせを分子レベルでの最小単位とすべきだ。

加えて、シニアエンジニアばかり集めるとアルゴリズムやマイクロ秒単位の最適化、コーディングスタイルなど些細な事柄で延々議論をしてしまう傾向があることを考慮しなければならない。もし会社がシニアエンジニアだらけで、チームに堅実な意思決定プロセスが存在しなければ、数百時間分の人件費が議論のために失われることだろう。ジュニアエンジニアであればほとんどこういう問題を起こすことはない。

Building careers

ジュニアエンジニアを採用しないことによるもう一つのメッセージは、キャリア構築に対する無理解の表明だ。

これは会社の世間体とかテックコミュニティでの役割の話をしているのではない。あなたの会社をより働きやすくし、多くのエンジニアが入社し長く働いて会社に貢献してくれるようにするためのものだ。

数人のエンジニアが「やっと職位を変えることができたよ。もう職位を変えるのは嫌だ。一生シニアエンジニアでいたいね」と話しているのを聞いたことがある。しかし「給料なんて上がんなくていいよ。新しいことを学びたくもないし金輪際達成したことを評価されたくもないね」なんて言う人はいない。それに面倒なことに、向上心旺盛な野心家を引き留めるために必要なものは、無欲だが情熱的なシニアエンジニアを引き留めるのに必要なものとほとんど同じだ。仕事の成果を図るための評価軸と十分な研修用の教材、そして様々な種類の新旧のプロジェクトが必要だ。昇進を望まない少数の人に対しても、進歩や成長の意識を植え付ける必要がある。

しかしそういう連中に手をこまねかないでほしい。彼らは少数派だ。テック業界にいるエンジニアのほとんどが 40 年間もシニアエンジニアでいたいなんて思っていない。みんなソフトウェアアーキテクトだとか、チームリーダーだとか、 CTO だとか創業者になりたいと思っている。キャリア開発に関して無関心な企業は潜在的な従業員から働き先の最終候補にしか見てもらえない。

エンジニアが面接を受けに来てもっとも感銘をうける言葉の一つはこういうものだ。「やぁ、僕はチームリーダーでこの会社に入って 8 年になる。最初はインターンだったんだ」。印象に残るがとても稀だ。こういう人は会社にとって非常に貴重だ。これまでの製品ラインの変遷を知っているし、半径 100 ヤード以内の各プロジェクトのコードを見てきている。組織の中の一人一人と一緒に仕事をした経験もある。他に誰もできないようなやり方で内側から会社を変革してくれるだろう。会社はこういう人の仕事で予測不可能なほどの利益を得るだろう。なぜなら社員を 8 年間(人生の 1/10 の時間に相当する)も同じ会社にとどまらせる方法を明らかにしたからだ。これは会社の文化醸成がうまくいっていることの証だ。職場のモラルは高く、良い仕事が評価され、社内の至る所で面白いプロジェクトが待ち受けていることを示す。

「ジュニアを雇わない」は、あなたの会社が誰かのキャリアの一部になる準備ができていないことを示している。会社が停滞していると公言しているのと同じだ。「我が社は経験豊富で能力の高いエンジニアを求めていて、金さえ払えば際限なく仕事をやってくれることを期待しています」。こういう求人に応募する人もいるだろうが、彼らは最善の仕事はしてくれないだろう。

もしあなたの会社がキャリア開発に真剣に取り組んでいるならば、ジュニアお断りポリシーは採用のパイプラインをしぼませ、従業員の在職期間を短くするだけだろう。

Making great software

ジュニアエンジニアにはシニア連中が普通失ってしまったようなユニークな特徴がある。その一つが盲目的な楽観思考だ。他に喜んで指示に従うというのもある。でも最も価値が高い特徴は、ジュニアは手ぶらであるということだ。シニアエンジニアの連中はこれまで技術の盛衰や失敗したプロジェクト、崩壊したチーム、その他の開発周りの罠を見てきている。彼らはその経験から強い意見を言い、時にそれは過度に一般化され、特定チームやプロジェクトでうまく行った(あるいは行かなかった)事柄を他のプロジェクトにも当てはまると思い込む。問題から新しい学びを得ることを避けるだろうことが明白だ。

「あれがそこで使えなかったってことは知らなかったよ。でもここではうまく行くさ」と言うことがしばしばプロジェクトマネージャーの仕事になることがある。そのときジュニアエンジニアがその主張の裏付け役としてうってつけの存在になる。シニアエンジニアが長年かけて培った偏見なしに実証のためのプロトタイプを作ることができる。僕はジュニアエンジニアだったときによくこういう仕事をした。新しいツールや技術を試し、全く違うやり方で作り直したり、他の人が手を出すには早すぎると言ったことを実証試験したりしてきた。大抵僕はよりよい方法を見つけて、結果として会社のソフトウェアはかなり良くなった。ページ読み込みが遅かったところで一桁速度を改善したこともあるし、複数ページにまたがっていたものを一つにまとめ、将来のメンテナンスにかかる数週間分の工数を節約したし、時間を浪費する可能性があった不適切な技術を除外することもできた。技術的背景がまっさらでフレッシュな視点の有効性は無視できないものであることがわかる。

多くの会社が一束のシニアエンジニアを部屋に集めて問題解決方法について合意を得るための討論をさせている。しかし人件費の安い数名のジュニアエンジニアを加えるだけで一回きりの作業や野心的な取り組みに手を出しやすくなり、プロダクトに驚くべき成果をもたらすことができる。

ソフトウェアの品質に関しても、ジュニアエンジニアが感謝こそされないが重要な影響をもたらすことがある。彼らはシニアの連中が書きたがる頭でっかちでオーバーエンジニアリングなコードを書かない。

上のツイートで "凡人" と書かれているところを "ジュニア" に置き換えてみればこれがどういうことか分かるだろう。コードベースとはコードを書いている人々が重要だと思ったことが抽象化されて記録されているものだ。ジュニアエンジニアとシニアエンジニアの割合が健全であればコードはシンプルになり将来の改修も楽になる。

まとめると、テック業界で広がりを見せる「シニアのみ」の態度はジュニアエンジニアを低く評価している。これはみんな、特に未経験者の候補者を閉め出すことで採用を楽にしようという誤った考えをしている組織にとって損失でしかない。そういう会社は財務的に余裕があったとしても、無駄にしているお金と時間はとても多い。

もしあなたの会社がこういう問題に直面していたら、そしてもしあなたがジュニアエンジニアをどう雇い、どう教育すべきか知っていたら、ここで述べているベネフィットを享受することができるだろう。あなたの会社ではどんでん返しが減り、多様性が高く、競争による副作用も少なくて済むだろう。ソフトウェアは壊れにくくなり、輝きを放つようになるはずだ。もちろん、これだけがすべてではない。しかしジュニアエンジニアに対する積極的な採用方針はあらゆるレベルのエンジニアにとって働きやすさの指針になるはずだ。(翻訳ここまで)


ジュニアがいてもぶっ壊れない開発フローで思い出すのがペパボ時代のことだ。 Jenkins のセットアップがしたくて @hsbt さんがお守りをしていたプロジェクトの Jenkins 設定を参考にさせてもらってるときに、うっかりビルドを実行してしまって production へのデプロイが始まってしまった。青ざめたけど「 master からのデプロイなら全く問題ないように作ってあるので大丈夫」と言われてめっちゃカッケーなと思った。いま CI の仕組みを整えたり誰でも Hubot から簡単にデプロイしたりできるように頑張ってるののきっかけになってると思う。


  1. 訳注) だから「経験者のみ」を掲げている会社にはよい開発者がやってこないと言いたいのだと思う 

  2. 訳注) ジュニアは給料が安いから 

| @労働

Kaizen Platform

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE (インフラチーム)のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA (総務部門のドン)やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応(スケール)できるから。詳しくは yosudo さんのスライドをご覧ください。

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし1、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー( PM )がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください!!!、!(現在 10 時)」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用!」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった2

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿(合宿だけど日帰り)でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった(教えたら自分たちが搾取していることが従業員にばれるため)。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。


厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい(参照: リモートワーク)。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質(何をやるべきかを自分で明確にできる、リーダーシップがある)は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。


  1. むしろテストコード多すぎて CI が遅くなるのが問題だったけど CircleCI に重課金してテストを並列実行して凌いでた。 

  2. ただしたまに逆のパターンが起こってた