Googleからの撤退〜シン・すべてがNになる〜

Published on 2021-10-22
Tagged: bazel career go

　先週の金曜日は、私にとってGoogleでの最後の日でした。もちろん、Googleを辞めるときには、何かしらの手紙や暴言を書かなければなりません。真面目な話、これはルールで、出版するまで神経インプラントは外されません。

　冗談はさておき、これは極論というよりも回顧録のようなものです。もちろん、私は意見を持っていますが、今はその時ではありません。これは、私の人生の最後の7年間を振り返って、何が重要だったのか、そして将来何を違った方法で行うのかを考えるためのものです。

Googleでの仕事内容

　

　私はニューヨークに移り、2015年の初めにGoogleに入社しました。私はずっとそこで働きたいと思っていました。最も賢い人々が最も興味深い問題を解決するために働いている場所のように思えたからです。実験が奨励され、ビジネスの重要性が低い、エンジニアリング主導の文化という考え方が気に入りました。GMailのように、20％のプロジェクトで大成功を収める可能性にも魅力を感じました。

　しかし、私が入社した頃のグーグルは、すでに堅苦しい巨大企業に変貌していました。自動運転車や新しいプログラミング言語のような "ムーンショット "プロジェクトを2015年に始めるのは難しかったと思います。現在では、その可能性は限りなく低いでしょう。

Docs, Sheets, and Slides

　

　私はまず、Docs、Sheets、SlidesのAndroidアプリを担当しました。期待していたような仕事ではありませんでしたが、私が入社した当時、Docsは成長していましたし、人々も素晴らしかったです。2年ほどモバイルアプリの仕事をしたのは面白かったのですが、この組織には深刻な問題がありました。

　まず、私のチームにはメンターやサポートが不足していました。私たちは、シドニーのDriveチームからAndroidアプリを継承しました（もともとDocs、Sheets、SlidesはDriveアプリにバンドルされていました）。私たちのチームは全員が新入社員（ほとんどが新卒）と他の部署からの異動者だったので、誰も技術的なインフラをよく理解しておらず、質問があっても誰に聞けばいいのかわかりませんでした。

　第二に、管理職の人数が多すぎること。私の前任のマネージャーは、約25人の部下を持っていました。3週間に1度、30分程度のミーティングを行いましたが、数ヶ月間、彼女は私のプロジェクトの名前を覚えていませんでした。私はこの会社で昇進することを諦めました。

　3つ目は、組織が極めて製品主導型であったことです。PMがすべての決定を下します。エンジニア（少なくとも私のレベルでは）はほとんど影響力を持ちませんでした。複数の四半期にわたるプロジェクトでは、正確な期限（2週間以内）を守ることが求められ、それがどうしても実現できない場合は、30分単位ですべての作業時間を記録しなければなりませんでした。まさに機械の歯車のようでした。

　挫折して2年で転校しました。今にして思えば、もっと早く辞めるべきでした。(面白いことに、私のチームには同じ日に別の新入社員が入ってきました。彼は1週間で辞めてしまいました。彼を見つけられなかったので、私たちは彼をワルドと呼んでいました。結局、彼は他のマネージャーと話をしていたことが判明しました)

　今回の主な教訓は

１.特に初期の段階では、メンターシップがとても重要です。プロジェクトのアーキテクチャーだけでなく、歴史や組織的なポリティクスについても教えてくれる人が早い段階でいることは絶対に重要です。コンウェイの法則により、これらの要素は互いに深く結びついています。新しいグループに参加する場合は、歴史を教えてくれる人を探しましょう。

２.昇進したいなら、サポートしてくれるマネージメントが不可欠です。私がグーグルに入社したのはL4で、前職（クアルコムのスタッフエンジニア）よりも少なくとも1つ下のレベルでした。すぐに昇格できると思っていましたが、3年以上かかりました。Docsを使っていたことは、そのためには全く役に立ちませんでした。

3.組織が大切にしているものと同じものをあなたも大切にしてください。Docsのリーダーシップは、有料顧客に新機能を提供することに集中していました。一方、私はミニマムで高速かつ信頼性の高いソフトウェアを重視しています。どちらの視点も間違ってはいませんが、両者は緊張関係にあり、私はそこで必要とされる種類の仕事をすることに満足できませんでした。

 ベイゼルへの応援

  私は2017年の初めにGoチームに参加し、最初はBazelのGoサポートを構築していました。当時のGoogleは、クラウドのお客様や新しいAlphabetの会社のために、社内のインフラの多くをオープンソース化したり、書き換えたりしようとしていました（Alphabetの結成はまだ最近でした）。Bazelは、Googleの内部ビルドツールであるBlazeのオープンソース版です。Blaze Goのルールには、外部のやり方とは一致しない特質がたくさんあったので、rules_goはほとんどがグリーンフィールドプロジェクトでした。 

 Goチームに参加する前は、その1年前に発売されたAlan DonovanとBrian Kernighanの『The Go Programming Language』を読んだ以外、実はGoもBazelも知りませんでした。実はチームの中には、入社して初めてGoを知ったという人が結構います。それはそれで貴重な教訓です。「N年の経験」という条件は、不要な門番です。賢い人はどんなことでもすぐに覚えてしまうし、多様な視点は貴重です。

 

 アランは非常に優れた指導者でした。初期の頃は、彼の新しいインタプリタ「Starlark」のコードをレビューしました。これは、慣用的で性能の高いGoを学ぶための素晴らしい方法でした。コードレビューで多くのバグを発見したとは思いませんが、多くの質問をする機会を得て、多くのことを学びました。また、Blazeの開発者の一人である彼のおかげで、Blazeのスピードアップにもつながりました。

 また、私は幸運にも協力的な上司に恵まれ、私の仕事は当時の組織の目標と密接に関連していました。多くの企業やKubernetesのような大規模なオープンソースプロジェクトがBazelに移行していたので、しっかりとしたGoのサポートが不可欠でした。私は1年余りでL5に昇進しました。

 そういった追い風は、得られるときはいいのですが、いつも続くわけではありません。その直後、GoチームはGoogle Cloudに再編成され、KubernetesはBazelの使用をやめることを決めたため、優先順位が変わりました。Go 1.11はモジュールを実験的にサポートして出荷されましたが、依存関係の管理が今後本当に重要になることは明らかでした。ニューヨークチームのほとんどは、モジュールを製品化できるようにすることにシフトしました。

 私は2018年末にgoコマンド（go build、go getなど）に取り組み始めました。初期の段階では、パフォーマンスを改善し、より良い診断メッセージを追加し、go getを書き換えました（それ以降、少なくとも2回は書き換えられています）。その後、retractディレクティブを追加したり、go installやgo runのcmd@version形式を追加したり、その他多くの細かい機能や改善を行いました。

 私が書いたものの中で最もインパクトがあったのは、モジュール・リファレンス・ドキュメントでしょう。約80ページのテキストで、すべての構文やプロトコルの仕様を含め、モジュール・システムが実際にどのように機能するかを説明しています。依存関係の管理は複雑で（数え切れないほどのエッジケースがあるため）、マニュアルがないと開発者がモジュールに移行するのは難しいのです。ドキュメンテーションプロジェクトの成功を測るのは難しいですが、メーリングリストやStack Overflow、公開Slackなどを見ていると、行き詰まる人が減り、より高度な質問がされるようになり、お互いに助け合えるようになったという逸話があります。

 最も興奮したプロジェクトは、Katie Hockmanと取り組んだネイティブ・ファジングでした。ファジング・エンジンを一から作るのはとても楽しかったです（もちろん、途中でたくさんのことを学んだり、アイデアを借りたりしました）。残念なことに、出荷されるまでいられませんでした。Go 1.18は、ネイティブ・ファジングを搭載した最初のリリースになることを期待しています。go-fuzzや他のシステムに合わせて効果を向上させるためにはさらなる作業が必要ですが、初期の状態でも多くのバグを捕まえることができると思います。

 Goチームで働く最大の欠点は、全員が過負荷になっていることでした。チームには非常に優秀で生産性の高い人々が集まっていましたが、全員が重い荷物を抱えていました。すべてのプロジェクトには継続的なメンテナンスが必要なので、実際にプロジェクトを完成させて排出することは困難でした。結局、私は6つのプロジェクトを少なくとも部分的に担当することになりました。いろいろな方法で注意を払っても、何も進まないのがもどかしい。問題の整理やコードレビューに追われるだけで、丸一日を費やしてしまいました。

 今回の私の重要な教訓。

 1.一度に集中する長期プロジェクトの数を制限します。6つの悪いことをするよりも、1つか2つの良いことをする方が良いのです。素晴らしい新しいチャンスがあれば、それを手に入れますが、何か他のものを捨ててください。落としたものが重要であれば、人員を確保することができます。そうでなければ...なぜそれに取り組むのか？

2.製品に責任を持つのは、個人ではなくチームです。Goでは、一人の人間が所有するプロジェクトが多すぎました。それが燃え尽き症候群や孤児となったパッケージの原因となっています。

3.スケール感を持って仕事をすることは重要ですが、時にそれが「怠慢」に感じられることもあります。Bazelの開発では、個人が直接問題を解決するのを手助けすることに多くの時間を費やしました。それは生産的で喜ばしいことでしたが、ルールが文書化されておらず、正しく使用するのが難しすぎたため、問題は尽きませんでした。対照的に、モジュールのリファレンス・ドキュメントを書くことは、より効率的な時間の使い方であり、スケールアップにもつながりました。人々はシステムを精神的にモデル化し、助けを必要とせずに問題を回避することができました。

グーグルで働き続けた理由

 グーグルで一緒に働いた人たちは素晴らしかったです。他の会社では考えられないほど、多くの人と親しくなることができました。

Docsでは、夜遅くまでCoupやPandemic Legacy（素晴らしいゲームですが、最近ではあまり良い選択ではありません）で遊んでいました。時にはチェルシーマーケットの下にあるバーで愚痴ったりもしました。

 Goでは一緒に料理をしたり、ディナーパーティーをしたりしました。カンファレンスでも楽しい時間を過ごしました。Gophercon 2019で講演が終わった後、プールの周りでフローズンマルガリータを飲んだことは、私の記憶の中でハイライトでした。

 そこにいた人たちをどれだけポジティブに感じているか、そして彼らをどれだけ恋しく思っているかを、うまく表現するのは難しいです。みんなと友達でいたいと思っていますが、同じようにはいかないと思っています。個人的なつながりを超えたグループ精神があります。

 完全にリモートになることで私が最も恐れているのは、新しいチームでこのようなつながりを再現するのが難しいということです。このような絆は直接会って形成されるものです。私たちがパンデミックをうまく切り抜けられたのは、そうした絆が早くからできていたからです。

私が辞めた理由

 このような手紙を書く人がいるのは（そして他の人がそれを嘲笑するのは）、Googleでの仕事が雇用の頂点であると少なからず洗脳されているからです。仕事を辞めることは、通常はあまり説明を必要とする行動ではありません。

しかし、ここではそれを説明します。

 燃え尽きた

 私はとても疲れています。私の知っている人は皆、燃え尽きているか、そのギリギリのところにいる。このツイートがこれほど注目されるとは思っていませんでした。その数日後、Maya Kaczorowskiの「Burning out and quitting」に自分の言葉が引用されているのを見て驚きました。その記事は私の心にとても響きました。私は夏の初めに、パンデミックによる燃え尽き症候群の経験について書きましたが、長くてつまらない個人的な話だったので、どこにも投稿しませんでした（この記事のようなものです）。マヤの記事の方がずっと良かった。

 要約すると、パンデミックが起こる前、私はかなりのストレスと負荷を感じていました。2020年に起きたすべての出来事が、私を限界まで追い詰めました。睡眠不足が続き、頭痛や腰痛もひどくなりました。また、集中力や判断力を欠く「ブレイン・フォグ」が頻発しました。言葉や名前を忘れたり、会話の流れを途中で見失ったりするようになりました。仕事をする以外のエネルギーが残っていないような気がして、それをこなすのがやっとでした。ミスも多くなり、後で修正するのに時間がかかるようになりました。

 思いつく限りのことを試してみました。いくつかのことは解決しましたが、十分ではありませんでした。もう仕事ができないので、長期休暇を取ることにしました。このような経験をした他の人々と話していると、本当に助けになるのはそれだけのようです。

 キャリアと報酬

　Googleでは3ヶ月間の無給期間が認められているので、長期休暇を取ってから新たに復帰することもできました。しかし、私は自分が再び燃え尽きることのないようにしたかったのです。しかし、2つの大きな問題が私を引き止めました。

　まず、Googleは私がリモートになったことで報酬を10％カットしようとしていました。私がサンディエゴに戻ってきたのは6月で、まだリモートワークの規定がなかったのです。私は、Googleがいずれリモートワークに関する方針を打ち出さなければならないと考えていたし、それがあまりにも不利なものであれば辞めてもいいと思っていました。同じチームで同じ仕事をしていたことを考えると、10％の削減はかなり不利です。会社にも余裕がなかったわけではありません。2021Q1の決算から、Google Cloudの収益は前年比53％増、全体の収益は61％増となっています。

　2つ目は、Goの仕事でL6に昇格するチャンスがあるとは思えなかったことです。Googleはgoコマンドやモジュールを使用していませんし、Googleに直接測定可能な利益がないので、ケースを作るのは非常に難しいです。ビジネスに直接結びついていないオープンソースの仕事では、L5以上の昇進は難しいので、結果的にGoチームのほとんどの人はL5に甘んじていることになります。成長を望むなら、グーグル社内で新しい仕事を見つけるか、外に出るかのどちらかしかないと感じていました。

　その他の考え方
　

Googleで起こったことには、不満なことがたくさんありました。MavenやDragonflyは今となっては遠い記憶のようです。Googleにもう少し倫理的になってくれと頼んだために、かなりの数の活動家や研究者が解雇されました。また、友人が低賃金、低レベルで、相応の敬意を払わずに扱われているのを目の当たりにしました。

 嘆願書に署名したり、デモに参加したりするだけでなく、こうしたことに立ち向かうためにもっと何かできたらよかったと思います。でも、私はあまり活動家ではありません、特に燃え尽き症候群では。私が言えるのは、あの人たちのことが頭から離れないということです。このような出来事があったからこそ、退職の決断が容易になったのだと思います。今後、どのような会社に入社するにしても、倫理についてもっと真剣に考えることになるでしょう。

 

 

 

 人生で初めて、次に何をするかという計画がありません。最低でも半年、いや1年は休むつもりです。サバティカルとでも言うのでしょうか。あるいは、ラムズプリンガ。

 その間にやりたいことはいくつかあります。マラソンの練習をする、料理がうまくなる、家庭菜園を始める、絵画教室に通う、空手道場に通う、地元の友達を作る...。しかし、ほとんどの場合、私はしばらくの間、仕事をしない人間になりたいと思っています。

 このようなことができるのは、非常に恵まれていると思います。妻も技術系の仕事をしていて、2人を楽に養うことができます。1年後には休息を取り、目的意識と方向性を持って技術者に戻る準備ができていることを願っています。

 

All Posts | About Me
Copyright © Jay Conrod, 2009-2021　

jayconrod.com

 

www.DeepL.com/Translator（無料版）で翻訳しました。

完