GitLabで働いた経験
(yorickpeterse.com)- 2015年10月にGitLabの28人目の社員として加わり、2021年12月まで働いた6年間は、完全リモート勤務、急成長スタートアップの混乱、パフォーマンス・デプロイ・組織文化の問題、バーンアウトが入り混じった経験だった
- 初期のGitLabでは、性能低下と頻繁な障害が最大のユーザー不満だったが、パフォーマンス監視インフラが不足しており、セルフホスティング顧客も使えるツールまで一緒に作る必要があった
- 2017〜2018年にはDatabaseチームでデータベース・ロードバランサーを作り、同時期に本番DB削除とバックアップ失敗が重なって、約6時間のデータ損失と約24時間の復旧が発生した
- 2019〜2021年のDeliveryチームは、Community EditionとEnterprise Editionの分離されたリポジトリ構造を統合し、コミット後にGitLab.comへデプロイされるまで最悪3週間かかっていた流れを、数時間〜1日程度まで短縮した
- GitLabで得た教訓は、スケーラビリティは文化であるべきこと、データのない「minimum viable」判断は危険であること、SaaSとセルフホスティングの並行運用は要件衝突を生むこと、そして高速なデプロイと役割ベースの報酬が重要だということだった
GitLab参加前と初期の役割
- GitLabに加わる前はアムステルダムの小さなスタートアップで働いており、会社は資金不足でオフィスの一部を賃貸に出すほど苦しい状況だった
- 個人の時間には Rubinius に取り組んでおり、これを本番環境で使えるほど安定させたいと考え、関連する仕事ができる職場を探し始めた
- Ruby meetupとRails GirlsのワークショップでSytseに会ってGitLabに興味を持ち、2015年夏にメールを送った後、2015年10月に社員 #28として入社した
- 任された仕事はGitLabのパフォーマンス改善で、勤務時間の20%をRubiniusに使うことができた
- 6年間で複数のチームを渡り歩きながら大きな裁量を持ち、10人の異なるマネージャーにレポートし、GitLabが30人台から約2000人規模へ成長していく過程を経験した
2015〜2017年: リモート勤務と性能ツールの構築
- 前職の最終勤務日の翌日にGitLabで働き始め、週5日のオフィス勤務から週5日のリモート勤務へ切り替わった
- 初期のGitLabは完全リモートの会社だったが社交的な雰囲気が強く、アムステルダムやオースティンなどで会社の集まりやイベントがよく開かれていた
- この時期のGitLabは最初の成長期を迎え、約100人ほどの新入社員が入り、会社規模は30人台から130人台まで増えた後、80人台まで減って再び成長した
- 同時に、深刻なパフォーマンス問題、ほぼ毎週起きる障害、未熟なマネジメントなど、急成長スタートアップ特有の問題も経験した
- 「GitLab is slow」がユーザー最大の不満だった
- Hacker NewsでもGitLabの遅さへの不満がたびたび出ていた
- パフォーマンス改善は、ツール不足のためさらに難しかった
- 当時の性能監視はNew Relicのtrialアカウントだけで、全15〜20台のサーバーのうち1〜2台しか監視できなかった
- 入ってくるデータは全体状況を正確に代表していなかった
- GitLabでは使うツールがセルフホスティング顧客にも提供され、可能ならオープンソースであることが求められていた
- パフォーマンスを改善するにはまずツール自体を作る必要があり、その成果が公式機能の GitLab Performance Monitoring につながった
- 開発環境向けの重いプロファイラである Sherlock もこの時期に構築した
- GitLabは、パフォーマンス問題は1人では解決できないと認識し、Performanceチームを作って専任マネージャーと小規模な採用予算を割り当てた
- RubiniusをGitLabで動かそうとしたが成功せず、保守方針やRubyコミュニティ内の論争も重なって、最終的に作業を中止した
2017〜2018年: Databaseチーム、ロードバランサー、本番DB事故
- 最初の1年半の混乱の後、パフォーマンスは大きく改善され、GitLabも性能をより真剣に扱うようになった
- Performanceチームは一般的な性能改善からデータベース性能中心へと範囲が変わり、Databaseチームになった
- 採用予算も増え、新しいデータベース設定などを支援するインフラエンジニアも割り当てられた
- この時期に構築した中核機能は GitLab database load balancer だった
- 関連発表は Scaling the GitLab database として公開された
- 開発者は普段どおりDBクエリを書き、ロードバランサーがprimaryまたはreplicaにルーティングした
- 書き込み後は、変更がすべてのreplicaに反映されるまでprimaryを使うstickingを適用した
- パフォーマンスに大きな好影響を与え、透過的に導入できたことが最も誇らしい点として残っている
- 2017年1月31日には、GitLab.comの本番データベースを誤って削除する事故が発生した
- 事故の内容は GitLab.com database incident として公開された
- バックアップシステムは長期間正常に動いておらず、バックアップエラーを通知すべきシステムも機能していなかった
- 約6時間前のproductionデータをstaging環境にコピーしていたおかげで復旧が可能だった
- 復旧には約24時間かかり、約6時間分のデータ損失が発生した
- 同じ時期、GitLabは引き続きデータベースのシャーディングを望んでいたが、当時のデータとエンジニアの判断では問題解決に適していなかった
- GitLabでは読み取りリクエストが書き込みより約10:1多かった
- 保存データの規模も、シャーディングの複雑さを正当化するほど大きくはなかった
- あるコンサルタントも、はるかに大きな負荷とストレージ規模の顧客に対してさえ、シャーディングはやりすぎだという趣旨の話をしていた
2019〜2021年: Deliveryチームとデプロイ時間の改善
- 2018〜2019年ごろ、性能と信頼性の業務に疲れ、新設されたDeliveryチームへ移った
- Deliveryチームの目標はGitLabのリリースプロセスとツールを改善することで、当時の状態は混乱していた
- コミットがmainブランチに入ってからGitLab.comにデプロイされるまで平均で数日かかり、最悪の場合は最大3週間かかっていた
- 最大のボトルネックは、GitLab Community EditionとGitLab Enterprise Editionが別々のGitリポジトリとして存在していたことだった
- 定期的に手動マージとコンフリクト解消が必要だった
- この問題を解決するため、2つのプロジェクトを1つに統合する数か月の作業が行われた
- 関連作業は Merging CE and EE codebases として公開された
- Deliveryチームはリリースプロセスを大きく改善し、変更を数時間以内にデプロイできる水準まで引き上げた
- 最悪3週間から最悪1日程度まで短縮できたのは大きな改善だった
- ただし、この速度でも理想的にはまだ十分に速いとは言えなかった
組織文化の変化と退職に至る過程
- 2018年は社員中心のGitLab summitの最後の年で、2019年以降は顧客向けの伝統的なカンファレンスに近い形式へ変わった
- 2000人以上規模の集まりは費用が非常に大きいため、財務的には理解できる変化だったが、社会的な体験としては以前ほど楽しくなくなったと感じた
- ノートPC管理の問題も繰り返し対立の要因になった
- GitLabは、会社支給Macまたは私物ハードウェアでGitLabリソースにアクセスする社員に、リモート管理ソフトウェアのインストールを要求または検討した
- 提案されたツールはユーザー活動の記録などに使える侵襲的な性質があり、乱用防止の保証が不十分だと感じた
- 社員からの多くのフィードバックは、中核社員が圧力をかけるまで無視されることがあった
- GitLabは最終的に SentinelOne ベースのノートPC管理ソリューションを選んだ
- 文化の変化と個人的な変化が重なり、動機と生産性が下がり、ストレスが増した
- 高く評価されていたマネージャーが別の役割に移り、新しいマネージャーがチームを引き継いだ後に対立が生じ、performance enablement plan が適用された
- PEPはPIP前の段階で、関係と業務を正常化するための手続きだった
- 当初は双方が改善するためのプロセスだと聞いていたが、実際には自分に求められる変化にだけ焦点が当たっていると感じた
- もともと1か月の予定だったが1か月延長され、2か月後には結果は満足できるものだと判断された
- その後、GitLabと自分が別々の方向へ進んでいると感じ、退職を考えるようになった
- GitLabの上場とストックオプション行使のタイミングのため、2021年12月に退職できるようになった
- 当時のオランダでは、stock option行使時に行使価格と評価額の差額に対して、流動化の有無に関係なく52%の所得税を支払う必要があった
- 税負担が大きく、GitLab上場前には行使しづらかった
- その後法律が変わり、行使時点または株式流動化時点のどちらで納税するかを選べるようになった
- 2021年12月にGitLabを離れ、Inko にフルタイムで集中し始めた
GitLabでの経験から得た教訓
-
スケーラビリティは企業文化であるべき
- GitLabはスケーラビリティを十分に優先しておらず、退職時点でもこの問題は続いていたと見ている
- GitLabの主な収益はGitLab.comではなく、GitLab Enterprise Editionをセルフホスティングする顧客から来ていた
- GitLab.comは稼ぐ金額よりはるかに多くのコストがかかっており、そのためセルフホスティング市場に焦点が当てられていた
- GitLab.comの多くの性能問題は、多くのセルフホスティング顧客には直接当てはまらなかった
- 多くの開発者は性能を改善したいと思っていたが、そのための時間やリソースを与えられていなかった
-
チームはデータと開発者中心で動くべき
- GitLabはプロダクトマネージャー主導の性格が強く、実装する機能は主にproduct managerとdirectorが決めていた
- 一部の決定は妥当だったが、ある決定はHacker Newsで良いアイデアだと見たものを作るべきだ、というように感じられた
- より単純な階層構造を早く導入し、team leadにより大きな権限を与え、ユーザーともっと多く対話させていれば、より良い成果が出せたかもしれないと考えている
- product managerの役割は、技術的に製品づくりへ貢献しつつ、チームとユーザーの橋渡しをするものであるべきだと考えている
-
データなしでは「minimum viable」の判断は難しい
- GitLabの中核原則の1つは、常にminimum viable changeから始めることだった
- 問題は、人によって「minimum」の定義が違っていたことだった
- あるチームは性能や優れたユーザビリティをviableの要件と見ていたが、別のチームはそれを重要視しなかった
- その結果、ユーザーにとって有用でない機能が作られたと見ている
- 要求されてもおらず、最終的に終了したserverless platform
- 3週間動いていなかったのに誰も気づかなかったKubernetes cluster管理サポート
- 既存ソリューションの代わりにCI上に作られたchatopsソリューション
- 作成と閲覧しかできず、編集も削除もできないrequirements management機能
- GitLabは四半期ごとに user survey を実施し、一部チームはユーザー参加データにアクセスしていたが、記憶と元同僚との会話によれば、このデータはチームのワークフローの中核というより断続的に使われていた
-
SaaSとセルフホスティングの両立は難しい
- GitLabはセルフホスティング導入版とSaaSの両方を提供していた
- 2つのモデルは収益構造、要件、アップデート適用方法がそれぞれ異なる
- SaaSには高速デプロイと、中央インフラで大規模なデータとワークロードを処理する能力が必要だ
- ほとんどのセルフホスティングインスタンスはSaaSよりはるかに小さいため、SaaSの問題と解決策はそのまま適用できない
- 結果として、プラットフォームのさまざまな部分でSaaS向けとセルフホスティング向けの2つのコードパスを考慮することになった
- SaaSかセルフホスティングのどちらかに集中すれば、その運用形態に合った体験へすべての注意を向けられる
-
人数が多ければ必ず良い結果になるわけではない
- GitLabは長年にわたり多くの人を採用し、現在は2000人以上を雇用している
- 開発者数は正確には分からないが、チームページをざっと見る限り少なくとも数百人はいると推定している
- プロジェクトに人を増やしても生産性や成果が必ず向上するわけではなく、これは「The Mythical Man-Month」にも通じる
- データはないが、ほとんどの会社は開発者20人以下で十分で、一部は20〜50人、ごく少数だけが50〜100人を必要とすると考えている
- 開発者が100人を超えるなら、製品の範囲が広がりすぎていないか考えるべきだと思う
- この判断はソフトウェア開発者についてのものであり、custom hardware生産、sales、supportのように同期コストが相対的に異なる領域は例外と見ている
-
Ruby on Railsの評価は両面がある
- GitLabはRubyとRuby on Railsで作られており、この組み合わせはGitLabの成功に大きく貢献した
- 同時に、プロジェクトが大きくなり経験レベルの異なるコントリビューターが増えると、Railsはパフォーマンスの悪いコードを簡単に生みやすい
- 代表的な問題は N+1 query problem だ
- RailsのActiveRecordにはこれを解決する機能があるが、opt-in方式になっている
- 開発者がそれを忘れると、行単位でクエリが発生して性能問題につながる
- GitLab初期の数年間で解決した多くのパフォーマンス問題はN+1 queryだった
- Ruby自体も優れた言語だったが、meta programmingを多用する性質は大規模プロジェクトでは難しさにつながる
- Go、Rust、Node.jsはRubyより効率的かもしれないが、Ruby on Railsほど強力なframeworkはないと考えている
- PythonとDjangoも選択肢になりうるが、RubyとRailsの問題をある程度経験する可能性があると見ている
-
デプロイ時間は組織の成功に重要
- コードはデプロイ対象ブランチやタグにpushされた後、遅くとも1時間以内にはデプロイ可能であるべきだと考えている
- GitLabがここに近づくまでには約4年かかり、それでもまだ道半ばだった
- 高速なデプロイは障害対応に役立つ
- デプロイに何時間もかかるならhot-patchが必要になるかもしれない
- 高速なデプロイはモチベーションにも影響する
- 自分が作った変更を実際に見て使えると満足感がある
- 数週間かけて作った変更がさらに2週間後にデプロイされるような状況は意欲を削ぐ
- 組織はデプロイ時間と、デプロイ過程でtest suiteにかかる時間を短縮することに非常に積極的であるべきだ
- 重要なのは、すべてのテストとデプロイが特定時間以下であることではなく、ビジネス要件が許す範囲で可能な限り速くデプロイすることを優先事項にすることだ
-
位置ベースの給与は差別的である
- GitLabの給与は複数の変数の影響を受け、その1つが居住地だった
- 物理オフィスがあり、特定地域で採用しなければならない会社なら位置ベースの補正も理解できるが、完全リモート企業なら、同じ経験と責任を持つ2人に住んでいる場所だけで異なる給与を払う正当な理由はないと考えている
- 退職時にオランダで受け取っていた給与は、税引前の年収で約€120,000、月額約€8,500だった
- Bay Areaに住んでいれば少なくとも2倍、あるいはそれ以上を受け取っていたはずだと考えている
- 解決策は応募者の居住地ではなく、職務要件を基準に報酬を決めることだ
- 0xide Computer Company は、位置ベースではなく同額を支払う会社として言及されている
- 関連内容は Compensation as a Reflection of Values で扱われている
結論
- GitLabでの時間は、非常に良い経験と悪い経験が混ざり合ったものだった
- 複数チームで成し遂げた成果と、一緒に働いた人たちに大きな誇りを感じている
- 最後の約1年が全体の経験をほろ苦いものにしてしまった点は心残りとして残っている
- GitLabで働いたことを後悔しておらず、もう一度やるなら後知恵を踏まえて少し違うやり方をするだろうと考えている
- 欠点はあっても、GitLabは多くの他社よりずっと良い会社だと思っており、今でも働く価値のある会社として勧められる
1件のコメント
Hacker News のコメント
会社が肌の色や性別を理由に賃金を下げれば大問題になるのに、居住地を理由に下げるのはなぜ許されるのか、という比較はもう少し考える必要がある
肌の色・性別と居住地は、変えられるかどうか、仕事と実際に関係があるかどうかという点で異なる
居住地については、会社が現地法人の設立、司法・税務制度の理解、タイムゾーン、出張費などを負担しなければならないため、仕事と関係がある
地域別報酬が正しいかは議論できるが、それを人種差別・性差別と比べると、GitLab を人種差別・性差別的な組織のように見せることになり、議論はすぐに終わってしまう
Bay Area に住んでいれば倍以上もらえたはずなのに、単に居住地が違うという理由で不公平だと言っているが、ここで被害者としてのポイントを得られるようには見えない
経済をよく理解していない主張に近い
今アメリカで受け取っている給与はイギリス時代のほぼ2倍だが、生活水準は似たようなもので、ある面では悪く、ある面では良い
原文の筆者も Bay Area に行っていたら、報酬は高くても生活水準はむしろ下がっていた可能性が大きい
所得だけでなく、社会保障、税金、文化まで考慮すべきで、より快適に暮らすためにヨーロッパへ戻り、大幅な年収減を受け入れることも考えている
GitLab の地域別報酬の動機は https://handbook.gitlab.com/handbook/total-rewards/compensat... に書かれており、かなり妥当に見える
フィリピンやウクライナにまで Bay Area の給与を払うと、人々は黄金の手錠に縛られ、離れるべき時にも離れられず、燃え尽きてしまう可能性がある
逆に世界の中央値給与を払えば、カリフォルニアやロンドンでは人を採れなくなる
プロダクトマネージャーは不要で、1つのプロダクトに開発者が100人以上いてはいけないという主張も議論の余地がある
原文の筆者は自律性の高い優秀なエンジニアで、比較的小さなスタートアップのほうがずっと幸せで成功できた人のように見える
税制変更を待つ必要がなかったなら、もっと早く辞めて良い体験談を書いていたかもしれない
株式に加えてアムステルダムで $300k の報酬まで受け取っていたなら、会社を辞めるのがどれほど難しかったかも考えてみる価値がある
全世界で同一報酬を強制すれば、会社はオフサイト、同じタイムゾーン、コミュニケーション上の利点から、単に現地採用だけをしようとする可能性が高い
特に生活費の高い地域にも採用希望者が多い経済状況ではなおさらだ
今後変わる可能性はあるが、現実的なインセンティブ構造を見ることが有用だ
他国で採用する会社が引き受けるリスクもあり、それは現地に知識と将来の会社の種を残す効果もある
オフィス出社は、その地域の生活費のおかげで従業員に賃金交渉力を与えるが、完全リモートの会社と文化では、会社はどこからでも採用し、最小公分母に近い給与を支払うことができる
リモート勤務は全員を世界中の人材と競争する独立契約者のようにし、オフィス勤務は主に同じ地域の人々と競争する形にする
28人目の社員としてCEOに直接レポートしていたが、上にマネージャーが次第に入り込み、そのうちの一人がPEPに載せた後、シグナルに気づいて去った、という話に見える
かなり標準的な流れで、大企業で人々が大きな仕事をうまくできない理由の一つかもしれない
社内でプロジェクトを始めて成功させても、会社は上に人を差し込み、結局は自分が始めたプロジェクトでn番目の社員になった後、成果不足だと言われることがある
面白くて興味深い仕事だけをやろうとし、結局は重要でないことに強い意見を持ち、CEOと親しい個人貢献者がマネージャーの選択を認めないと、管理上の悪夢になる
意思決定の責任は負わない一方で、あちこち動き回って問題を作り出すことがある
エンドポイントセキュリティと個人デバイスの使用が手がかりの一つだ
このような許容的な文化は、コンプライアンスと開発生産性のコストのためにスケールしない
好みのLinuxディストリビューションにこだわる古参開発者を引き離すのは難しいが、仕事には業務用コンピューターを使い、アップデートは会社に管理させるのが妥当だ
データベースバックアップの話も同じで、データベースチームならバックアップが最優先業務だ
「バックアップがなかった」を受け身で済ませることはできず、日常的にサイトを維持することよりもシャーディングアーキテクチャの議論に関心があったように見える
GitLabがホスティング製品の性能に十分投資しなかったという結論も、その製品が大きな赤字なら、より多くのリソースを投入しないのは当然かもしれない
面白いエンジニアリングではなく、実際の事業上の根拠として、なぜその仕事のほうが重要で収益を生むのかを説得しなければならない
あるマネージャーと一緒に成功したプロジェクトを始めたが、経営陣が貪欲に政治や社会的ジレンマを持ち込み、管理階層を差し込んで、私とそのマネージャーを置き換えようとしている
仕事を本気で気にかけてはいけない理由を学んだし、そのせいでプロジェクトが壊れて解体されそうな気がしている
ここでは、その社員が実際に高い成果を出しており、マネージャーは不要で、PEPを受けるに値しなかったと仮定する雰囲気があるが、安全な仮定ではない
初期スタートアップで、会社と役割が大きくなる速度に合わせて成長できない、あるいは成長しようとしない初期社員を見たことがある
過去の貢献への敬意、置き換えにくい歴史的知識、創業者やリーダーになった初期社員との関係のために、そのまま残されることはよくある
しかし、初期社員であり重要な初期プロジェクトに関わったという事実が、その仕事を引き続き任せるうえで最高または適任であることを意味するわけではない
その場しのぎやcronジョブ、手作業の介入で何かを回すのは得意でも、大企業ではそのような運用方法はまったく合わないことがある
適応できなかったり、大企業のやり方で働かなければならないことに不満を抱いたりすると、助けになるより害のほうが大きくなる
どの初期企業にも、一緒に成長できない初期社員はいるが、それが唯一の結末でも一般的な結末でもない
GitLabには長く勤めている社員も多いが、不満の混じったブログ記事では彼らの声は聞こえてこないので、選択バイアスを考慮すべきだ
GitLabを長く使ってきたし、製品は継続的に発展しているので、停滞した製品だという主張には同意しない
3年後、リリースが失敗し続けていることを見てようやく問題になったが、私の影響というより、誰かがGoogleで「リリース失敗を防ぐ方法」を検索した結果のように思えた
解決策は分からないし、今も別のテーマで同じことをまた経験している
最初はただ必要なことをやり遂げていたが、後には間違ったことをしていないか確認するという理由で、すべての段階が新しく差し込まれたマネージャーのポジションを通らなければならなくなる
会社が成長できた初期のアイデアや貢献とは無関係にそうなる
GitLab CIに関して何年も前から残っている古いIssueがある背景も、これと関係があるのか気になる
外から見ると、GitLabは優れたものを作る能力を完全に失ったように見え、何年も前からのバグが繰り返され続けても直そうとしない印象だ
従業員に個人用コンピューターの使用を認めていたというくだりは、ほとんど驚くほどです。
組織がどれほど小さくても、会社所有の機器を提供し、すべての会社業務をその機器で行わせるべきです。
会社にとっては知的財産の管理面で大きな利点があり、従業員にとっても勤務時間と私生活を分けるうえで大いに役立ち、コストもそれほど大きくありません。
どこへ行っても望むツール一式をそのまま使えますし、素早く消して作り直せる能力は「自分のコンピューターでは動く／動かない」系の問題のデバッグにも有効です。
一方の端には記憶に頼る方法があり、もう一方の端にはhttps://nixos.org/でどこでも完全に再現可能なビルドを作る方法があります。
その間にも多くの選択肢があり、
host: localhostで必要なものをインストールするAnsibleファイル群を管理している人も見たことがあります。私は最新のUbuntuバージョンを使い、新規インストールで欲しいものの80%を入れるいくつかのシェルスクリプト[1]を保守しています。
科学的に取り組みたいなら、https://atuin.sh/のようなものをインストールして、長期的なシェル履歴を基準に実際によく実行しているプログラムの統計を取ることもできます。
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
完璧な解決策ではありませんが、少なくとも会社の機器であれば、流出は悪意ある行為か、機密データを承認されていない経路へ移した無能さの結果になります。
会社が訴訟を起こされると、個人デバイスの内容まであらゆる召喚の対象になり得ます。
別のデバイスを要求することが、ユーザーにとってワークライフバランス上の利点になるわけではなく、単に不便なだけです。
仕事と私生活の時間を分ける行動は、主に自分の習慣、能力、そして最終的には決断に左右されます。
地域別給与は差別だと以前は感じていましたが、今はおおむねそうではなくなりました。
結局のところ、サンフランシスコ水準の給与を求めるということですし、インドの人たちはオランダやサンフランシスコ水準の給与を求めるようになります。
そうすると、底辺への競争が起きる可能性が高いです。
単純な事実として、各自が自分の地域で十分よい生活を送れるだけ稼いでいたということです。
もっと欲しいなら引っ越せばよく、引っ越さないならそれなりの理由があるのでしょう。
誰もがサンフランシスコ水準の給与とインディアナ州やインドの生活費を望みますが、明らかな理由から、それは成り立ちにくいです。
採用されれば、San FranciscoにいようがPolandやIndonesiaにいようが、米国水準の給与を受け取ります。
こうしたポジションは非常に競争が激しいです。
世界中に門戸を開いて「実力を見せてくれ」と言っているようなものなので、はるかに大きな応募者・人材プールを見ることができ、その中には貧しい国出身の非常に賢く、推進力の強い例外的な人材が多くいます。
需要と供給はそう機能します。
より多く支払うと言えば、通常はより高いレベルの候補者を採用することになります。
米国の複数の州でリモートで働きながら、サンフランシスコ水準の給与を受け取っている人をかなり知っています。
当然、可能です。
サンフランシスコも過信しすぎるべきではありません。
DetroitもかつてはMotor CityでありMusic Cityでもあり、世界的な文化・技術の中心地でしたが、中核的な強みは、より安く効率的な他地域の労働によって揺さぶられました。
求めているのは同一労働同一賃金です。
チームメンバーが同じ仕事をしているのに、他の人は満額を受け取り、自分だけ一部しか受け取れないなら、深刻におかしなことです。
チームへの貢献は、現在どこにいるかには左右されません。
通勤にどれだけ時間を使うかも、成果物への期待値を変えません。
オフィスの場所が過度に高額なら、会社がより安い場所を探す形で問題を解決すべきであって、従業員が会社の悪いオフィス立地を補助する理由はありません。
従業員が受け取る100kと会社のコストは別です。
国ごとに会社が追加で負担する税金、社会保障、福利厚生が異なり、多くの場合、現地法人や仮想的な形の事業体、現地法令遵守を支援するリソースが必要です。
私自身、多国籍企業でグローバルな役割を担い、現地基準の給与を受け取る従業員側にいますが、見た目より考慮すべきことは多いです。
基本的には採用コストではなく生活費を反映して調整しつつ、同等の給与を目指しています。
ひどいマネージャーは業界の厄介ごとです。
逆に、多くのスタートアップは創業者が以前の職場でひどいマネージャーを経験したために生まれます。
Traitorous EightとFairchild Semiconductorsの話を思い出します。
個人的にも、前職で非技術的で政治的、かつ報復的なマネージャーに出会っていなければ、自分のスタートアップを始める動機はなかったと思います。
振り返ると、キャリアの早い時期に、あれほど悪いマネージャーにもっと早く出会っていればよかったとさえ思います。
本当に自分の技術を必要としている会社を見つけ、人事手続きの負担なく、もっと簡単に移れるようになってもよいと思います。
Ruby のプログラミングモデル全体は、ほとんどの時間が入出力やネットワーク待ちなので言語の速度は重要ではない、という前提に基づいているという主張
しかし今では Node.js や JVM 側に、入出力・ネットワークを待つ間に別の仕事をしたり、より多くのリクエストを処理したりするモデルがある
2024年に Ruby/Rails を使うのは無駄かもしれないが、ユーザー数が限られた企業向けアプリ、開発速度が絶対的に重要な場合、市場検証用の高速なプロトタイプには良い選択になり得る
Rails は優れたフレームワークで生産性も高いが、2〜3年経った Rails プロジェクトは保守が常に難しくなる
Rails プロジェクトが Django や Express プロジェクトより厄介というわけではない
どんなコードベースでも雑草が生えないようにするには、規律と継続的な庭仕事が必要
Ruby と Rails に弱点があるとすれば、依然として 素の言語性能 と、より高いメモリ要求量・使用量であり、低レイテンシや小さなメモリフットプリントが必要な作業には魅力が薄い
経験上、主に痛みが出るのはトラフィックが突然大きく揺れたり、WebSocket を使うアクティブユーザーが非常に多い場合で、WebSocket 周りは anycable でほとんど解決できる
ただし、その限界に達するプロダクトはごく少なく、達したとしても解決可能
Stripe、GitHub、Shopify は Rails がさまざまな形で問題なくスケールした代表例
Rails を牽引した大きな原動力は、DHH の 開発者の幸福 に関する考えであり、これは開発速度と密接につながっている
Rails コミュニティで入出力の議論があるのは Web サーバー運用に重要だからであって、言語やフレームワーク選定における唯一または主な焦点ではない
Web サーバーの CPU 使用率を最大化することが目標なら、Rails でも複数プロセスを立ち上げることで可能で、これは JVM で複数スレッドを立ち上げるのと似たやり方として昔から使われてきた
多少不便かもしれないが、90年代から使われていたモデルであり、Web リクエストは通常独立して実行されるため、プロセス間通信も大きな問題にならないことが多い
「無駄」と一般化するのは乱暴
Rust でアプリを書くことも状況によっては無駄になり得るし、どこに圧力があるか次第
初期段階ではリリースできないことの方がはるかに大きな懸念であり、中盤以降でも開発者の速度は最もスケールさせにくい要素の一つ
Rails バックエンドと React フロントエンドを使う会社の CTO として、開発速度は非常に重要で、Rails の開発速度は今も大きな利点
スケーリングの問題もあるが、99% は Rails の問題ではなく データベース の問題
会社がエンジニアに勤務地基準で給与を払おうとするのは、別の差別だと思う
従業員の能力に応じて払うべきで、勤務地に応じて払うべきではない
政府のルールは性別、宗教、性的指向などで差別してはいけないと言っているが、勤務地による給与差別は公正なのか？
同じ役割で Europe から Asia に移った友人たちが、同じ人間、同じ役割なのに、勤務地が変わったというだけで少ない額を受け取るのを見た
競争の少ない市場へ引っ越して他の仕事を見つけにくくなれば、より低い給与でも出勤する可能性が高くなる
リモートなので現地市場に縛られないように見えても、政府が国際採用に大きな障壁を設けている場合が多く、国によっては競争の少ない市場になり得る
同じ会社で同じ仕事をしているのに別の国へ移って給与が下がったなら、ほぼ確実にそれが理由でその減額を受け入れたということ
会社は何らかの普遍的な価値尺度よりも、従業員が 快適で健康的 に暮らせる能力を基準に支払うべきだと思う
そのような普遍的価値は不可能だと思う
能力だけを基準にしようという主張は意図せず共同体を壊し、不平等を通じてジェントリフィケーションと社会的結束の破壊を悪化させる
場所は重要
同じ生活の質、同じタイプの住居、家族を養う機会、子どもを似たような学校に通わせる機会を与えるために支払っている
これらの費用は国ごとに異なるため、必要な所得も異なる
会社には特定の能力が必要で、市場がその能力にいくらの価値を付けようと、その分だけ、そしてそれ以上は支払わない
場所によって市場は同じ能力に異なる価格を付けるので、給与も変わる
宗教は曖昧な例外だが、公正かどうかはともかく、これは差別ではない
GitLab.com が常に稼ぐ金額より費用の方がはるかに大きく、会社が主に self-hosted GitLab Enterprise Edition の顧客から収益を得ていたのなら、スケーラビリティに十分投資しなかったことが本当に失敗なのか疑問
第一に、会社はお金を失うことより、お金を稼ぐことに投資すべき
より性能の高い gitlab.com がより多くの顧客と評判をもたらすという高次の判断はあり得るが、実際の事業が self-hosted ソフトウェア の販売なら、開発リソースをそこに集中するのは妥当
実際に GitLab ライセンスを買った後、ホスティングを GitLab に任せても自分たちでやってもシート費用が同じだと知って、ではなぜインフラ費用をこちらが負担しなければならないのかと思った
GitLab.com を中途半端にやるくらいなら、きちんとやるか、さもなければプロダクトをなくして GitLab Enterprise Edition のような self-hosting 顧客だけに集中する方が長期的には良いかもしれない
しかし経営陣の誰もそんな決定はしたくないはず
そのためプロダクトを 中途半端 に運営することになる
プロダクト自体を気にかける人たちにとっては、こうした状況はもどかしいものになり得る
新しい開発者が入るたびに「スケーラビリティをもっと気にすべきだ」と言い、シニアたちは「はいはい、分かってる…」となる
経済的に見て、アムステルダムの開発者がベイエリアの開発者と同じ価値を提供するなら、同じ給与を支払うのが妥当である可能性が高い
アムステルダムの開発者の現地市場価格は低いが、グローバル企業を作っており、他のグローバル企業と競争しているのだ
今はアムステルダムの開発者を割安に獲得できても、いずれ競合他社がその価値により近い金額を提示するか、彼らが自分の仕事をしに去っていくだろう
最も強い企業は、人材に対して場所に依存しない報酬を支払うようになると思う
結局重要なのは、提供された価値だ
GitLabのように大きなRubyコードベースを抱え、性能と安定性を重視する大企業に売り込みたいなら、こうした人には年**€120k**よりもっと支払うと思う
性能、型安全性、安定性を重視するエンジニアの大半はRubyに関心がないので、その技術の組み合わせの市場価格は確実にもっと高い
ベイエリアの年$500k水準なのかは分からないが、トップクラスの人材を求める強い企業は、報酬を場所ではなく提供価値に紐づけなければ人材を失うことになるだろう
コードのデプロイにかかる時間は、スタートアップがスケールする際に開発者の速度を維持するうえで最も重要な指標の一つ、もしかすると最重要指標だと思う
コンテキストスイッチは開発者の日常で最もコストの高い作業の一つでありながら、最も見過ごされがちでもある
マネージャーは自分の予定に合わせてチームの予定を組みたがるが、これは個々の貢献者の「メーカーズスケジュール」を頻繁に妨げる
多くの組織はこれに気づき、スケジュール面でのコンテキストスイッチのコストに注目するが、開発者にとってはビルドからデプロイまでにかかる時間も同じくらい、あるいはそれ以上に重要だ