本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。
また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。
ここから本文です。
GitLab 社で働くのはどのようなものだったか
私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。
前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。
- 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6年間を見直す気力がありませんでした
- 私は24ヶ月間の NDA 下にあり、おそらく何の問題も起こさないだろうとはいえ、NDA に違反することなくどこまで議論できるか確信をもてませんでした
その NDA は昨年12月に失効し、私はまだ燃え尽き症候群の影響があると思われますが、GitLab 社での時間をふりかえるエネルギーは少しあります。
この記事は大きく2つの節で構成することにします。1つはまだ覚えていることに基づく GitLab 社での私が働いた概要と、もう1つは私の仕事と経験から学んだことです。
GitLab 社の入社前
GitLab 社に入社する前、私はアムステルダムを拠点とする小さなスタートアップで働いていました。ほとんどのスタートアップがそうであるように、私が退職するまでの数ヶ月間、会社は資金不足に陥り始め、費用を賄うためにオフィススペースの一部を貸し出すなど、絶望的な解決策に頼らざるを得ませんでした。同時に、技術的なレベルではやりたいこと、できることはやり尽くしたという思いもありました。
これと並行して、余暇には Rubinius の開発にも取り組んでいて、様々な場面で Rubinius の利用を検討し、すべてのコードが問題なく動くことを確認するまでに至りました。これは、Nokogiri に代わる XML/HTML 解析ライブラリ Oga の作成にもつながりました。
残念ながら、資金不足とさまざまな技術的問題が重なり、Rubinius の利用をそれ以上追求することはありませんでした。このようなことから、私は Rubinius を本番環境で使用できるほど安定させたいと思い、少なくとももう少し Rubinius の開発に時間を費やせる仕事を探し始めました。
その間、アムステルダムで開催されるさまざまな Ruby ミートアップに参加したり、Rails Girls のワークショップを手伝ったりしました。これらのワークショップのひとつで Sytse と彼の妻に出会い、後のワークショップかミートアップでまた出会いました (もうずいぶん前のことなのでよく覚えていません) 。その中で GitLab 社のことを知り、そこで働くことに興味を持ちました。
2015年の夏のある時、私は Sytse にメールを送り、GitLab 社で働きたい旨を伝え、週に1日 Rubinius で働くスポンサーになってもらえないかと頼みました。その後の会話と面接の結果、私は2015年10月に社員番号28番として GitLab 社に入社しました。私の仕事は GitLab のパフォーマンスを向上させることで、20%の時間を Rubinius に費やすことができました。
その間、私は様々なチームの一員となり、多くの自主性を持ち、数年間で10人の異なるマネージャーに報告し、会社をほぼ消滅させ、GitLab が今日まで使用している様々な重要なコンポーネントを構築し、会社が30人ほどの従業員から2000人ほどの従業員に成長するのを見届け、そして燃え尽き症候群で終わりました。オランダのことわざでは "Lekker gewerkt, pik!" です (がんばって翻訳して) 。
2015-2017
GitLab 社に入る前の会社での最終日は9月30日の水曜日で、その翌日から GitLab 社で働き始めました。つまり、私は週5日オフィスで働くことから、週5日リモートで働くことになったのです。それまでも自宅で仕事をしたことはありましたが、主に線路に積もったわずかな雪や落ち葉のために電車が動いていないときに仕事をしていました。
特に印象に残っているのは、日中に食料品の袋を家まで持ち帰ったことで、仕事から帰ってきて夕方ではなく、日中にそれをすることがいかに素晴らしいかをを実感しました。
もうひとつの思い出は、愛猫とソファで昼寝をしたことです。
そう、それはホーマー・シンプソンのスリッパです。
当時私が借りていたアパートは広くなく、小さなキッチンスペースと小さなリビングルーム、そして同様に小さな屋根裏部屋しかありませんでした。そのため、私のリビングルームは、寝室、リビングルーム、オフィスとして機能していました。あまりいい環境とは言えなかったですが、当時の私にはそれしかありませんでした。おそらく高価なアーロンチェアが関係していたのでしょう。
フルリモートの会社であるにもかかわらず、GitLab 社は社交的な会社で、何年もの間、頻繁にミートアップやイベントが開催されていました。例えば、私が入社して数週間後にアムステルダムで会社の集まりがあり、日中は様々なアクティビティ、夜には夕食会がありました。
当時はまだ、レストランの一角に会社全体をおさめることができました。
それから間もなく、GitLab 社は最初の成長期を迎え、100人ほどの従業員が新たに加わりました (と思うけれど、現時点では少し記憶があいまいです) 。2016年にオースティンで開催された次の会社の集まりでは、レストランの一角ではもはや十分ではありませんでした。
この間、ネガティブな経験もたくさんありました。GitLab はひどいパフォーマンス、頻繁な機能停止 (ほぼ毎週どこか)、不十分な管理、その他スタートアップが直面する多くの問題に苦しんでいました。その結果、"GitLabは遅い" というのがユーザーからの不満の声の第一位となりました。特に Hacker News では、元のトピック (例えば新機能の発表) が何であろうと、人々は文句を言うのが大好きでした。もちろん GitLab 社はこのことに気づいていましたし、実際 GitLab 社が私を雇った理由の一つはこの問題を解決するためでした。
特に、GitLab 社には適切なパフォーマンス・モニタリングのインフラがなかったからです。当時稼働していた唯一のサービスは New Relic のトライアルアカウントで、当時あった (と思う) 合計15～20台のサーバーのうち1台か2台しか監視できませんでした。このため、どのようなデータであっても正確な表現ではなく、パフォーマンスの測定と解決が困難でした。
これらの問題を解決するのをさらに難しくしたのは、GitLab の要件で、私たちが使うどんなツールであれ、セルフホスティングの顧客が利用できるものでなければならず、できればオープンソースでなければならなかったことです (あるいは、これは難しい要件だったのかもしれませんが、覚えていません) 。つまり、パフォーマンスを向上させるだけでなく、そもそもパフォーマンスを向上させるためのツールを構築しなければならなかったのでした。同時に、パフォーマントなコード (あるいは少なくとも恐ろしく遅くないコード) を書くことは、会社の他のメンバーにとって優先事項とはまったく考えられていませんでした。GitLab 社はまた、社内の苦情よりも Hacker News 上の苦情に耳を傾ける傾向がありました。そのため、社内では「何かを変えて欲しければ、然るべきルートで文句を言うよりも、匿名で Hacker News に文句を言った方がうまくいく」というジョークが飛び交っていました。
その後、数ヶ月間、私はパフォーマンスを改善し、そのために必要なツールを構築し、パフォーマンスに対する会社の文化や態度を変え、時間が経てば実際に改善されるように努め、GitLab がその改善に満足しないことに対処しました。少なくとも何度か、Sytse を怒鳴りつけそうになったビデオ通話があったことをはっきりと覚えています。
このような困難にもかかわらず、私は必要なツールを構築し、様々な部分でパフォーマンスを向上させることができました (重要なものもあれば、そうでないものもあった) 。このツールは "GitLab Performance Monitoring" として知られる GitLab の公式機能になりました。私が作ったもう一つのツールは "Sherlock" で、開発環境で使うためのヘビー級のプロファイラでした。
この間、GitLab は、特にパフォーマンスが会社の他の部分にとって優先事項でない場合、一人の人間を雇うだけではこの種の問題を解決できないことに気づき始めました。その結果、Sytse に直接報告する代わりに、新しい "Performance" チームの一員として専任のマネージャーに報告することになり、そのチームにはさらに人を雇うための予算がつくことになりました。その予算は正確には覚えていませんが、2人か3人だったと思います。会社の規模や、できるだけ多くの機能を生み出すことに主眼を置いていたことを考えると、これでは到底足りなかったが、スタートにはなりました。
2年目の大半は、このチームの一員として過ごしました。より多くのリソースを求めるキャンペーンを続け、新しいコードには優れたパフォーマンスを要件としましたが、結果はまちまちで、もちろん私やチーム全体としてパフォーマンスを改善し続けました。
この間、GitLab 社は最初のレイオフの波を経験し、主に GitLab 社が最初に間違った人を雇った結果、自分の意志で人が去っていきました。その結果、GitLab 社は30数人から130数人 (だったと思う) まで成長し、80数人まで縮小し、また数ヶ月後に成長し始めました。
Rubinius について。私たちは Rubinius で GitLab を動かそうとしましたが、成功しませんでした。Rubinius のメンテナがプロジェクトを別の方向に進めようとしたことと、このことが Ruby コミュニティ内で論争を引き起こしたことも相まって、私たちは最終的に Rubinius に見切りをつけることにし、私は Rubinius での作業を完全にやめました。Rubinius は長年にわたって多くのことを実現してきたのですが、最終的には、プロジェクトを成功させるために必要なこととは異なる方法で運営するメンテナーによって抑制されてしまったのです。
2017-2018
最初の不安定な1年半の後、事態は好転し始めた。パフォーマンスは大幅に改善され、GitLab 社はより真剣に取り組み始めた。採用プロセスは大幅に改善され、チェスのゲームのように GitLab 社は適切な人材を適切な場所に配置し始めた。パフォーマンス・チームの範囲も変わりました。パフォーマンス全般に焦点を当てるのではなく、データベースのパフォーマンスに焦点を当てることになり、その一環として "データベース・チーム" というクリエイティブな名称に変更されました。この変更に伴い、人を雇うための予算も増え、新しいデータベースのセットアップなどを手伝ってくれるインフラ・エンジニアも配属されました。
この時期に私が作った決定的に重要な機能は、GitLab のデータベースロードバランサー です (ここで発表しました) 。この機能により、開発者は通常通りデータベースクエリを書き続けることができ、ロードバランサはこれらのクエリをレプリカやプライマリのどちらにも向けないようにします。書き込みを行った後、ロードバランサーは、書き込んだ変更がすべてのレプリカで利用可能になるまで、プライマリデータベースが使用されるようにする。ロードバランサーの導入はパフォーマンスに大きく良い影響を与えました。もしこのロードバランサーがなかったら、GitLab は大変なことになっていたと思います。私が最も誇りに思っているのは、このシステムを透過的に導入できたことです。これまでのところ、(Ruby on Rails はともかく) プロジェクトに追加するだけで使えるデータベースロードバランサーは見たことがありません。その代わり、既存のソリューションは、パズルのほんの一部分だけを提供するフレームワークのようなもので、自分ですべてをつなぎ合わせる必要があり、多くの場合、何のサポートもありません。スタンドアローン・ライブラリーにまで発展させることができなかったのは残念でした。
1月31日、夜遅くまで続く多くの問題に対処する長くストレスフルな一日の後、私は GitLab のパフォーマンス問題を解決しました 誤って GitLab の本番データベースを削除してしまいました 。その結果、システムが長い間機能していなかったため、バックアップがないことが判明しました。また、バックアップのエラーを通知するシステムも機能していませんでした。結局、その日に行っていた作業の一環として、6時間ほど前に本番データをステージング環境にコピーしていたため、復旧はできましたが、復旧には24時間ほどかかりました。約6時間のデータ損失はどう考えてもひどいものでしたが、もしバックアップを取っていなかったらどうなっていたかはわかりません。その日、私の心臓は数拍飛び、白髪が数本増えたことは間違いない。
この間、何度も苛立ちの種になったのは、データベースのロードバランサーを導入した後も、GitLab がデータベースをシャード化したがることでした。私や他のエンジニアや上司は、これが問題に対する間違った解決策だと考えていただけでなく、それを裏付けるデータも持っていました。例えば、シャーディングは書き込みが読み込みを大きく上回る場合に有効ですが、GitLab の場合は読み込みが書き込みを 10:1 の割合で上回っていました。さらに、私たちが保存していたデータ量は、シャーディングを導入する複雑さを正当化できるほどではありませんでした。私たちが雇ったコンサルタントが、"悪気はないのですが、私たちには数桁多い負荷とストレージを持つ顧客がおり、彼らにとってもシャーディングはやり過ぎです" というようなことを言っていたのをはっきりと覚えています。にもかかわらず、GitLab は何年もシャーディングを推し進め続け、経営陣がシャーディングを放置する決断をするまでになりました。
2019-2021
2018年から2019年にかけてのある時期、私はこの4年間、パフォーマンスと信頼性に取り組むことに疲れてしまったため、データベースチームから新しく設立された「デリバリー」チームに移動しました。さらに、複数の人間がパフォーマンスと信頼性に取り組むようになったので、私にとっては新しいことに移る適切な時期だと感じました。この新しいチームの目標は、GitLab のリリースプロセスとツールの改善でした。
例えば、私たちはメインブランチにコミットしてから GitLab.com にデプロイするまでの時間を調べました。その結果、平均して数日かかるが、ひどい場合は3週間かかるというデータが出ました。ここでの主なボトルネックは、GitLab Community Edition と GitLab Enterprise Edition が別々の Git リポジトリとして存在し、定期的に手作業によるマージと競合解決が必要だったことです。そのため、 2つのプロジェクトを1つにマージする のに数ヶ月を要しました。私たちは作業をフロントエンドとバックエンドに分け、様々なチームがそれぞれの分担を分担して貢献するようにしましたが、結局私はバックエンド関連の変更のほとんどを実装し、別の同僚がフロントエンド作業のほとんどを担当しました。
チームの他のメンバーとともに、この期間にリリースプロセスを大幅に改善し、数時間で変更をデプロイできるまでになりました。これは本来あるべきスピードにはほど遠いものの、最悪の場合3週間かかっていたものが、最悪の場合1日程度で済むようになったのは大きな進歩でした。
これまでの期間と同様、この期間も混乱や変化がなかったわけではありません。
2018年は従業員に焦点を当てた GitLab サミットを開催した最後の年であり、2019年以降はより伝統的なカンファレンスのような形式で、より顧客向け、より従業員向けではないものになりました。2000人以上の集まりを開催するのはとてつもなくお金がかかるので、財政的な観点からすればこれは理解できることでした。社交的な観点からは、サミットがより企業的な設定になったことで、以前の形式ほど楽しくなくなったことは損失でした。コンテストで優勝したチームに対して Sytse がステージでダンスを披露したり 、Sytse がキリンの着ぐるみを着て Sytse 夫妻がフィットネス教室を開いたりしたのはいい思い出です。このようなおふざけイベントは、その後の数年間は起こらなくなりました。
ラップトップの管理の問題もありました。会社の Mac ラップトップを要求され、それをどう使うかは多かれ少なかれ自由でした。何年もかけて、GitLab 社の経営陣はラップトップをリモートで管理できるソフトウェアを使おうという議論を始めました。これらの議論で繰り返し問題になったのは、提案されたツールが侵略的で (例えば、ユーザーの行動を記録するために使われる可能性がある) 、悪用に対する保証がなく、主要な社員が経営陣に圧力をかけ始めるまで、社員からのフィードバック (たくさんあった) が無視されるということでした。そして計画は棚上げされ、数カ月後にまた議論がやり直されました。
最も際立っていたのは、提案された変更点ではなく、むしろ経営陣のフィードバックの扱い方であり、変更点全般が、その存在を正当化するために問題を解決しようとしているような雰囲気を醸し出していたことだった。この議論に参加したほとんどの人たち (私も含めて) は、(盗難対策など) 何らかの形でラップトップを管理する必要性を理解していましたが、提案された侵略的な解決策は行き過ぎだと感じていました。
GitLab 社は SentinelOne を使ったラップトップ管理ソリューションに落ち着きました。GitLab 社は、個人のハードウェアを含め、GitLab 社のリソースにアクセスするために使用するハードウェアにこのソフトウェアをインストールすることを従業員に義務付けていました (あるいは、少なくとも義務付けることを検討していました) が、私 (自分のデスクトップ・コンピューターを使っていました) はどういうわけかレーダーを潜り抜け、問題のソフトウェアのインストールを求められることはありませんでした。おそらく、会社支給のノートパソコンを使っていなかったために GitLab 社が私をチェックするのを忘れてしまったのでしょう。
このような文化的な変化と私生活の様々な変化が重なり、モチベーションや生産性が低下し、ストレスが増大し、労働時間が安定しなくなりました。チームのマネージャー (今までで最高のマネージャーだと思う) も別の役割に移り、今は新しく雇われたマネージャーがチームを率いています。私はこのマネージャーと折り合いが悪く、その結果、「業績改善計画」(PIP) が必要になる前に、物事を軌道に乗せるための手順である「業績向上計画」を立てることになりました。PIP は、従業員と仕事、そして雇用主との関係を改善するための最後の試みとして使われるものだ。
私は改善すべき点があることを認めましたが、問題の一端は新しいマネージャーの働き方にあると感じました。経営陣は、PEP は両者の状態を改善することを意味している、つまり私だけに焦点を当てるのではなく、マネージャーにも焦点を当てるのだと保証してくれました。それは実現せず、PEP は私が違うことをする必要があることだけに焦点を当てました。PEP はまた、どのような要件を満たさなければならないかについても少し曖昧でした。当初の計画では PEP は1カ月でしたが、最初の1カ月が終わるころ、上司は PEP をもう1カ月延長することを決めました。そして2ヵ月後、私は PEP を完了し、経営陣はその結果を満足のいくものだと判断した。
私の中の楽観主義者は、私が PEP を実施した最初の従業員であったため、経営陣が状況を把握しながら進めていったのだと信じたいです。私の中の悲観主義者は、この一連の出来事に対してはるかに否定的な意見を持っていますが、それは自分の胸にしまっておきます。
この経験の後、GitLab 社も私も違う方向に向かっていて、当時の状況に満足していなかったので、もしかしたら辞める時が来たのかもしれないと思いました。
そのチャンスは2021年の終わりに訪れました。GitLab 社が上場することになり、ストックオプションを行使できるようになるまでの期間を考慮すると、2021年12月に退職できることになりました。ストックオプションを行使すると、行使手数料と評価額との差額に対して、たとえ株式が流動的でなくても、所得税 (52％) を全額支払わなければならないからです。私の場合、税金が高すぎて払えなかったので、GitLab 社が上場するまで待つことを余儀なくされました。数ヶ月後、法律が変わり、税金を行使時に支払うか、株式が流動化した時に支払うかを選択できるようになりました。注意点は、株式が流動化するまで税金を先延ばしにした場合、ストック・オプションを行使した時点の価値ではなく、その時点の価値に基づいて税金を支払うということです。これは確かに理想的ではなく、財務上のリスクも大きいが、少なくとも選択肢はありました。
こうして株式を取得した私は、2021年12月に退職し、貯蓄を切り崩しながら Inko でフルタイムで働くことになりました。
学んだこと
歴史はさておき、私が GitLab 社で学んだことをいくつか見てみましょう。一つ心に留めておいてほしいのは、これらの知見は私の個人的な経験に基づくものであり、そのため、私が間違っている部分がある可能性は低くないということです。
スケーラビリティは企業文化とする必要がある
GitLab 社が犯した過ち、そして私が退職した後も犯し続けた過ちは、スケーラビリティを十分に気にしなかったことです。確かに、役員たちはスケーラビリティは重要だと言うでしょうし、改善もされてはきたけれど、他の目標ほど優先されることはありませんでした。この問題の核心は、GitLab 社のお金を稼ぐ方法にあります。GitLab 社は主に、GitLab.com ではなく、GitLab Enterprise Edition をセルフホストしている顧客からお金を得ています。 このため、当然ながらセルフホスティングの市場に焦点を当てることになり、GitLab.com で遭遇したパフォーマンスの問題の多くは、多くのセルフホスティングの顧客には当てはまりませんでした。
さらにイライラさせられたのは、多くの開発者が実際にはパフォーマンス向上を望んでいたにもかかわらず、そのための時間とリソースを与えられていなかったことです。
チームをよりデータ主導且つ、開発者主導にする
もう一つの要因は、GitLab のプロダクトマネージャー主導の性質です。主要な開発者の中には、プロダクトの決定に影響を与える能力を持っていた人もいたかもしれませんが (十分に叫んだり蹴ったりすれば)、何を実装すべきかを決めるのは主にプロダクトマネージャーやディレクターでした。これらの決定がとても理にかなったものであることもあれば、「Hacker News で読んだこれは良いアイデアだから作らなければならない」というだけのものであることもありました。
GitLab 社は、今日のような伝統的な多層階層ではなく、もっとシンプルな階層を早い段階から採用していれば、会社としてもっと良いパフォーマンスを発揮できたと思います。特に、プロダクトマネージャーという考え方はやめて、チームリーダーにもっと権限を与えて、ユーザーともっと交流させるべきだと思います。技術的なレベルで製品作りを支援するだけでなく、チームとユーザーとの連絡役としても機能します。
データがなければ、何が「最小限の実行可能」なのか判断できない
GitLab 社の基本原則の一つは、常に「実行可能な最小限の変更」から始めることです。これは、ユーザーに価値をもたらす可能な限り小さな作業単位を提供するという考え方です。机上では素晴らしいことに聞こえますが、実際には「最小」の定義は人によって一貫していません。その結果、あるチームではパフォーマンスや使い勝手の良さを実行可能な要件と考えるかもしれませんし、別のチームではそんなことはどうでもいいということになります。
誰も求めなかったサーバーレスプラットフォームは最終的に廃止され、Kubernetes クラスターを管理するためのサポートは誰にも気づかれることなく3週間も機能しなかったり、既存のソリューションを使う代わりに CI サービスの上に chatops ソリューションを構築しなければならなかったり (その結果、大幅なレイテンシが発生した)、データの作成と閲覧しかサポートしない要件管理機能 (更新や削除さえもサポートしなかった)、これらはここ数年のほんの一例です。
何が実現可能なのかを判断するには、ターゲットとするユーザーの要望を深く理解する必要があります。GitLab 社では四半期ごとにユーザー調査 を行っており、ユーザー・エンゲージメントに関するデータにアクセスできるチームもありますが、私が覚えている限り、また他の元同僚と話して学んだ限りでは、このデータは各チームのワークフローの中核部分ではなく、付随的に使われているようでした。
SaaS とセルフホスティングは相性が悪い
GitLab 社は、セルフホストインストールと SaaS (Software as a Service) の2種類の製品を提供しています。GitLab 社を含め、ほとんどの企業はこのようなセットアップを効果的に提供することはできないと思います。何が一番儲かるかという利害の対立が生じるだけでなく (前述の通り)、2種類のセットアップには異なる要件やアップデートの適用方法があります。
例えば、SaaS の場合、迅速にデプロイでき、一元化されたインフラ上で大量のデータとワークロードを処理する必要があります。ほとんどのセルフホストインスタンスは、SaaS の提供するものに比べて小さい傾向があるため、SaaS として遭遇する問題やそれに対応するソリューションの多くは、セルフホストインストレーションには適用されません。このため、プラットフォームの多くの部分で、SaaS 版とセルフホスト版の2つのコードパスが存在することになります。コードが物理的に同じであったとしても (つまり、セルフホスト型インストレーション用に使いやすいラッパーを提供する場合)、その違いについて考える必要があります。
対照的に、SaaS またはセルフホスティングのセットアップのどちらかに集中する場合、そのセットアップにとって最高のエクスペリエンスを提供することに全神経を集中させることができます。もちろん例外はありますが、それはまさに例外であり、例外はまれです。
人数が多ければ成果が上がるわけではない
GitLab 社は、それ以前の多くの企業と同様、何年にもわたって多くの人を雇用し、現在では2000人以上の従業員を抱えています。そのうちの何人が現在の開発者なのかは知りませんが、チーム・ページをざっと見た感じでは少なくとも数百人でしょう。
プロジェクトに人を増やしても、必ずしも生産性や成果が向上するわけではないことはよく知られています (「人月の神話」も参照) 。しかし、ベンチャーキャピタルを持つ欧米のスタートアップはほとんどすべてこのことを無視しているようで、製品にそれほど多くの開発者が必要でなくても、何百人もの開発者を雇っています。
これを裏付けるデータはありませんが、ほとんどの企業は20人以上の開発者を必要とせず、20人から50人、50人から100人の開発者を必要とする企業はほんの一握りではないでしょうか。開発者が100人を超えたら、さらに人を雇う前に、製品の範囲が手に負えなくなっていないかどうか考え始める必要があると思います。
なお、ここでは特にソフトウェア開発者について話しています。例えば、カスタムメイドのハードウェアを製造しているのであれば、製造工程を拡大するためにもっと多くの人が必要になるでしょう。営業とサポートは、一般的に人数が多い方が有利な2つの分野です。
Ruby on Rails の使用について葛藤している
GitLab は Ruby と Ruby on Rails を使って構築されており、これが今日の成功をもたらした大きな要因です。同時に、この組み合わせは、プロジェクトが大規模になり、経験レベルの異なる多くの貢献者が参加するようになると課題をもたらします。特に Rails では、うまく動作しないコードを導入するのが簡単過ぎます。
たとえば、プロジェクトメンバーの数を示すカウンタとともにプロジェクトのリストを表示したい場合、N+1 クエリの問題 を誤って導入するのはあまりにも簡単です。Rails (より具体的にはActiveRecord) はこの問題を解決する機能を提供していますが、これはオプトインの仕組みであるため、開発者がこの問題を忘れてしまうことは避けられません。私が GitLab 社にいた最初の数年間に解決したパフォーマンス問題の多くは、N+1 クエリの問題でした。
他のフレームワークは何年もかけてこの問題から学び、よりよい代替案を提供してきました。通常のアプローチは、関連するデータを任意にクエリできる代わりに、前もってデータを渡しておくというものです。この利点は、もしデータの受け渡しを忘れても、コードが行ごとにデータを照会してパフォーマンスの問題を引き起こすのではなく、何らかのエラーに遭遇することです。
また、Ruby 自体にも賛否両論があります。一方では、10年弱の間楽しく使ってきた素晴らしい言語です。一方では、メタプログラミングを多用するため、オプショナル型付けが導入されたとはいえ、大規模なプロジェクトで使うのは難しいです。私は数年前に Ruby の静的解析ツール を書いたときに、それを身をもって体験しました。
にもかかわらず、Ruby と Ruby on Rails の組み合わせの代わりに、どのような選択肢を勧められるかわかりません。Go、Rust、Node.js といった言語は Ruby よりも効率的かもしれませんが、Ruby on Rails ほど有能なフレームワークはない。Python や Django も選択肢に入るかもしれませんが、少なくともある程度は Ruby や Ruby on Rails と同じような問題にぶつかるのではないでしょうか。新しいウェブフレームワークが、ルーティングツリーをどう定義するかにこだわるのをやめて、代わりに全体としての生産性をもっと重視するようになれば、おそらく役に立つでしょう。
Inko でこの問題にどうアプローチするか、漠然としたアイデアはあるのですが、Inko でウェブ・フレームワークを書き始める前にやらなければならないことが他にもたくさんあります。
コードのデプロイにかかる時間は、組織の成功に欠かせない
これは GitLab 社に入社する前からわかっていたことで、前職では優れたデプロイとテストのパイプラインの構築にかなりの時間を費やしてきました。GitLab 社では、それに近づくまでに4年ほどかかりました。
(デプロイに何時間もかかることを考慮してコードをホットパッチする必要がない) より効率的にインシデントに対応できるといった明らかな利点のほかに、モチベーションを上げる利点もあります。変更に何週間も費やし、それがデプロイされるまでにさらに2週間かかることほど、やる気を失わせることはありません。
これがうまくいくためには、デプロイにかかる時間や、デプロイの一部としてテストスイートを実行する時間を、驚くほど積極的に削減する必要がある。アプリケーションの種類やテストするサービスの種類によっては、テストの実行にある程度の時間が必要な場合もあります。ここで重要なのは、「テストとデプロイにX分以上かかってはならない」ということではなく、(組織として) ビジネス要件が許す限り、デプロイを高速に行えるようにすることを優先することです。当たり前のことのように思えるかもしれないが、多くの組織はこの分野で、できる限り良い仕事をしていないのではないでしょうか。
場所ベースの給与は差別的だ
GitLab 社であなたが得る給料は様々な変数に影響されますが、その一つが勤務地です。勤務地の影響も取るに足らないものではありません。物理的なオフィスがある会社で、特定の地域で人を雇う必要がある場合、そうでなければ必要な地域で必要な人を雇うことができないかもしれないので、場所によって給与を調整することは理にかなっているかもしれません。しかし、物理的なオフィスを持たず、全世界に法人を持つフルリモートの会社にとって、同じ経験と責任を持つ2人の異なる人材に、純粋に住んでいる場所によって異なる給与を支払う正当な理由はありません。
例えるなら、私が GitLab 社を辞めた時の給料は税引き前で年間約12万ユーロ、月に約8500ユーロでした。オランダではこの給料は良い方で、これより良い給料でフルタイム在宅勤務ができる会社を見つけるのは難しいでしょう。しかし、もし私がベイエリアに住んでいたら、少なくともその2倍、場合によってはそれ以上の収入を得ていたでしょう。ベイエリアの方が仕事ができるからとか、そういう正当な理由ではなく、オランダではなくベイエリアに住んでいたからです。
どう言い繕ったところで、住んでいる場所によって賃金を決めるのは、どう考えても差別行為である。考えてみてください。肌の色や性別を理由に給与を低くしたら、会社は大問題になるでしょう。しかし、住んでいる場所によって賃金が低くなるのは問題ないのでしょうか？
これを解決する方法としては、企業にとっては簡単です。応募者の所在地ではなく、ポジションの要件に基づいて給与を支払えばいいのです。ベイエリアにいる人に年間10万ドル払おうが、フィリピンにいる人に払おうが、企業としてのコストは同じだからです。従業員に対する私の唯一のアドバイスは、より良い給与を交渉してみることですが、場所によって給与を支払う企業も頑固な傾向があるので、これは難しいかもしれません。いつか法律がこの慣習に追いつくことを願っています。
このやり方がうまくいっていると思われる会社に、0xide Computer Company があります。0xide は従業員に勤務地に応じて給与を支払う代わりに、同額を支払っています(詳しくは こちらの記事 を参照) 。
結論
振り返ってみると、GitLab 社で過ごした時間は信じられないほどポジティブな経験とネガティブな経験の両方が混在しています。私が所属していた様々なチームが成し遂げてきた成果や、一緒に働くことができた人たちを信じられないほど誇りに思っていますが、素晴らしい経験を台無しにしてしまったここ1年ほどのことを悲しくも思っています。GitLab 社で働いたことに後悔はありませんし、できることならもう一度やり直したいと思っています。欠点はあるにせよ、他の多くの会社よりもずっと良い会社だと思うからです。
