7 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • gwsはGoogle Drive、Gmail、CalendarなどあらゆるWorkspace APIを扱い、人間とエージェントの両方のために設計されたオープンソースCLI
  • 公開から数日でHacker News 1位に上がり、数千のGitHubスターと数千人の実利用ユーザーを獲得
  • Google社内の反応は二分された。複数のディレクターやリーダーがこのツールから学べる点を尋ねる一方、GoogleロゴとブランドカラーがGitHubリポジトリに入っていたことを理由に、法務チームから厳しい追及を受けた
  • 本人が推測する解雇理由は、Workspaceの一部リーダーやプロジェクトが感じた破壊的変化への恐れであり、これは特定のCLIではなく、エージェントがWorkspaceにとって何を意味するかに対するより広い恐れだと考えている
  • 解雇の2日前にGoogle Cloud Nextで公式Workspace CLIのリリースが発表されたのは皮肉だ
  • 自分の物語を自ら説明し、経験を完全に自分のものとして受け止めるために公開したものであり、これを癒やしの過程の一部だと考えている
  • 約7年間のGoogle勤務を素晴らしい機会だったと評価し、支えてくれた同僚やマネージャーに感謝を表明
  • 「20%プロジェクトだったのか」という質問には否定し、自分はWorkspace DevRel所属で、APIの上にオープンソースのレイヤーや抽象化を定期的に作っていると補足説明
    • 2026年初めにはCLIへの関心はそれほど大きくなかった

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見
  • Googleで働いていた、あるいは今も働いているらしい人たちがこの行為を批判しているが、こういう話題にコメントするときは 金銭的利害関係 を明らかにすべきだ
    Chrome配下のGoogleで働いていた頃は、個人やチームがGoogle管理のGitHub組織にオープンソースプロジェクトを載せるのはよくあることで、2015〜2021年の大半の期間はオープンソースオフィスの承認なしでもチーム単独でGitHubに公開できた
    こうしたオープンソース公開はGoogle文化の一部だったと見ていて、長期勤務社員の行動に対して 解雇 はあまりにも極端な結果に見える

    • 元Googlerで、Cloudで働きながらプロジェクトをオープンソースとして公開したことがある立場から言うと、ほかの製品領域ではまったくそんなに単純ではなく、特に Googleの名前 を使う場合はもっと厳しかった
      私の個人アカウントの小さなDiscordボットですらIARC委員会を通す必要があったのだから、Googleの名前を使うプロジェクトならIARCと法務承認、正式リリース/プライバシー審査まで必要だった可能性が高い
      OPはリリース当時、競合製品が社内で開発中だったとも言っていたので、社内の混乱も大きかったはずで、こういう点は審査プロセスで拾われただろう
      全体として、わざと真実を全部語っていないように見えるし、知名度稼ぎ のようにも見える
    • Googleで働いているなら、外部の「仕事」に関するポリシーは非常に明確だ。ボランティア、オープンソースのサイドプロジェクト、事業、役員活動など、どんな形であれ日常業務やGoogleの事業に関係していれば 申告フォーム を提出して法務承認を受けなければならない
      Google Workspace CLIは明らかにGoogleと関係しているのに、なぜ承認なしで公開したのか理解しがたい
      ユーザーに関心のある有能なエンジニアが解雇されたのは残念だが、エンジニア側の判断はよくなかったように思う
      ちなみにGoogleで働いているが、この文章は個人の見解であり雇用主とは無関係だ
    • ここでは特に、Appleの株主たちがAppleが悪意的に見えることをしたとき、たとえばユーザーのスマホを遅くしたり、Siriの録音を盗み聞きしたりした件を大したことではないと流しつつ、保有株式 を明かしているのを見た記憶がない
    • 要点は、会社の権限なしに会社へ影響を与えることをした、ということだ
      その行為によってその製品はGoogle承認製品のように見えたし、Googleは評判を守るために何十億ドルも使ってきたのに、任意の社員が会社も知らない独自製品を出した形になった
      Googleは民事上の巨額訴訟や刑事上の詐欺にまで発展する余地を抱えていたし、実際に回収できるかは別としても、当人にとっては地獄になっていただろう
      結局 解雇だけで済んだ のも運がよかった方に見える
    • 普通、Google所属ではないリポジトリを Googleブランド の下で公開することが許されるのか気になる
      違和感があるし、なぜ自分の名前で出さなかったのか理解できない
      1年前までGoogleで働いていて辞めて株も売ったが、オープンソースに関係するチームではなかったので社内手続きはよく知らない
  • 雇用主の公式リリース物と混同されうるものを個人的に公開した判断の甘さは、今後も大きな 予測不能なリスク と見なされるだろう
    手続きを踏まなかったなら相当な懲戒が予想されるし、どこかの時点で直接警告を受けていたなら解雇もあり得るように思える

    • 本当の問題は、OPが昔ながらの 破壊的イノベーター で、かつては面白く破壊的だった雇用主で働きたかったことにある
      OPはコミュニティにかなり好意的に受け入れられたまともな製品を作ったが、今のGoogleの回り方とは合わず切られたのだ
      Googleでは見返りのないリスクは取らず、面白そうに見える動きですら慎重でなければならない
      会計に執着する人たちにとって貸借対照表と損益計算書が面白いという意味を除けば、Googleはもう面白い会社ではないようだ
      残念ながらバズることが常によいとは限らず、悪いバズを経験したことがある人ならわかるはずだ
    • Googleでは、社員がオープンソースプロジェクトを公開し所有権を表示する手続きは非常に明確でよく整備されているので、この件が著者にとって混乱したものだったり突然起きたものだったりしたとは想像しにくい
      そうした手続きやポリシーの妥当性を問うのはもちろん可能だが、問題になるとは思わなかった という語りには懐疑的だ
    • 私もそういう印象を受けたし、まず上司に確認すべきだったと思う
      今のように責任転嫁するのではなく、ここから何かを学んでほしい
    • 大量の些細あるいは悪意ある訴訟やブランド攻撃に対応しなければならない会社なら、なおさら敏感にならざるを得ない
      似た状況で法務と一緒にばかげた製品関連の攻撃を防いだことがあるし、入社時にはこういうことをしないという文書にも署名した
      ただ、これを公に騒ぎ立てる目的はよくわからない
    • これは「個人的に」公開したもので、手続きが守られていなかったと仮定している
  • ここでは解雇された人に同情的な雰囲気なのが興味深い。
    雇用主の名前を冠したプロジェクトを、実際には雇用主と無関係で承認も得ていないまま公開したのなら、解雇を予想するのが自然ではないかと思う。
    Google社員だという点はむしろさらに悪く、名前を検索すれば実際にGoogle社員だと分かるので、公式のように見えやすい。
    これはかなり明白に悪い考えだったように見える。

    • 彼はデベロッパーリレーションズ(DevRel)で働いていて、この種のオープンソースツールを作るのはよくあることだったと述べている: https://x.com/JPoehnelt/status/2069535183158812698
      法的な状況は分からないが、責任を避けるためにそうした可能性もある。
      それでも、エンジニアたちに最初から作り直させたり、Google所属に見えにくい場所へ移したりするより、解雇は間違った結果のように感じられる。
      未承認のプロジェクトに雇用主のブランディングを使うべきではないのでGoogleの権利は明白だが、雇用主の使命と製品を広めようとしていた人に対しては、過度に保守的な対応に見える。
    • いや、そこまでではない。
      厳しい叱責くらいは予想するが、解雇は行き過ぎだと思う。
      Googleがまだ魅力的な職場なのかは分からないが、今回の件は確実にその方向へ天秤を傾けるものではない。
    • 彼はコーディングは得意だが判断力に欠けていたように見える。
      ただ、本人が過ちを認めるなら、解雇するよりもうまくマネジメントしたほうが賢明だった気がする。
      clueless だが優秀なコーダーには少し寛容なほうだ。
    • このプロジェクトが未承認だったという情報はどこから出てきたのか気になる。
      かなり大きな前提に見えるし、リンク先のツイートや返信、関連ページではそれを裏付ける内容を見つけられなかった。
    • Googleで7年働いた人がこの結果に驚いたというのは信じがたい。
      Googleでは社員のオープンソース貢献手続きが非常に明確で、そのくらいの期間があって go/opensource のような社内文書を一度も見ていない可能性は低いように思える。
      このポリシーや運用を擁護するつもりはないが、何ができて何ができないか、そして「正しい」手順はよく文書化されている。
      多くの人がそのルールにもどかしさを感じるのは理解できるが、単に無視して押し通したときの結果もかなり予測可能だ。
  • パーネルの官僚制の鉄則の教科書的な例に見える。
    Justin Poehnelt のように自発的に動機づけられて素晴らしいものを作り、人々が興味を持って使いたがるような人は、いまやGoogle内部の官僚制と、その中で自分の役割や重要性をより重視する人たちに左右されている。
    彼らにとって、OPのプロジェクトがGitHubですぐに人気を得たという事実は何の意味もなかったのだろう。
    ただし、Justinが承認なしにGoogleブランディングでコードを公開したのが事実なら、それは誤りであり、解雇も正当化されうる: https://news.ycombinator.com/item?id=48650310 および https://news.ycombinator.com/item?id=48650192
    参考: https://jerrypournelle.com/reports/jerryp/iron.html

    • 元Googlerたちが、以前は社員がGoogleブランディングでGitHubにコードを上げることが長い間よく許されていたと言っているのなら、そうであれば解雇は正当化しにくいと思う: https://news.ycombinator.com/item?id=48652851
      事実が変われば考えを変えることにためらいはない。
    • Googleは4兆ドル超の価値を持つ会社であり、それを守るための自然で必要な官僚制がある。
      善意ではあったかもしれないが、この種のカウボーイ的な振る舞いはGoogleが負う価値のないリスクだ。
    • むしろ0より低い、負の意味を持ちうる。
      システムの外で動いても人気を得てユーザーを奪えることを示してしまうので、組織の優位性を脅かすからだ。
    • 修正内容は筋が通らないと思う。
      Googleは商標を外すよう求めればすべて整理できたはずだが、そうしなかった。
      人々に好かれた有用なものを作った人を見せしめにし、今やGoogleの他のエンジニアたちは、事前承認されていない価値を事業に加える前によく考えるようになるだろう。
      修正前の判断が正しかった。
  • Googleで働いたことはないが、こういう状況をかなり多く見てきた立場からすると、解雇にまで至ったのならさらに多くの背景があるはずだと思う。
    通常、有能な社員がこうしたことをすると、「主体的に動いてくれたのはありがたいし今後も奨励したいが、これは取り下げる必要があり、二度と起こらないようにしてほしい」という形で終わる。
    たいていはキャリア終了級の出来事ではなく、むしろ「カウボーイ」と見なされても、そういう人を後押しする役員がいて昇進につながることさえある。
    なので、Googleがこの件を非常にまずく処理したか、組織が壊れているか、あるいはOPが会社の最善の利益に反して行動し、特定の指示に意図的に従わなかった可能性がある。

  • 「私を解雇させたツイート」の内容は次のとおり。

    Introducing the Google Workspace CLI: https://github.com/googleworkspac
    e/cli - built for humans and agents.
    Google Drive, Gmail, Calendar, and every Workspace API. 40+ agent skills included.
    これは完全にGoogleの公式製品発表のように見え、実際そう誤解されてもおかしくない。
    問題になると分かっていて当然だったはずだ。

  • Justinがこれを投稿したのを見たが、詳しくは言いにくいものの、本当に信じがたい話だ。
    Googleは20%ルールを奨励し、こうしたすばらしいプロジェクトを生み出せる場所だったのに、今ではそういうことをした人を解雇する会社になってしまった。
    Google内部で何か悪質なものが動いているように見える。
    こうした件もそうだし、オープンソースのGemini CLIが、よりひどい非公開のAntigravity CLIに置き換えられるようなことも起きている。
    いったい何が起きているのか分からない。

    • 解雇の大きな理由は、業務に関連する製品を作り、おそらく20%ルールを使って勤務中に開発し、Googleのブランディングとロゴを付けて会社の承認なしに公開したためだと聞いている。
      名前も会社と結び付いたままだったので、突然Google社員がGoogleブランドで公開したバズったGoogle Workspaceツールが現れ、皆が不意を突かれた格好だった。
      必ずしも解雇されるべきだったとは言わないが、このやり方は極めて判断が悪く、マネージャーや周囲の人たちを非常に困らせた。
    • 20%プロジェクトがいつからリリース手続きをすべて迂回して製品をそのまま公開してよいという意味になったのか分からない。
      Googleはいまや大きな官僚組織かもしれないが、リリース承認や手続きには理由がある。
    • 会社がアイデア不足に陥り、運営の大半をMBA出身者が担うようになると、こういうことが起きる。
      良いアイデアでさえ、今では誰かの縄張りを侵すことになりかねず危険だ。
    • 20%ルールのプロジェクトは、そもそもそのまま公にリリースしてはいけないという方針なのかもしれない。
  • 正当性やストライサンド効果、広報上の損害または逆に利益になるかは脇に置くとして、この件が次のGmailを作りたい若いGoogleエンジニアにどんなシグナルを送るのかを見るべきだ。
    内部ポリシーにすべて違反していたとしても、人々が実際に望むものを作った人を解雇するのは、社内にも社外にも非常に不吉なメッセージだ。
    これがAddy Osmaniの最近のGoogle退職とも関係しているのか気になる。
    連帯のための退職だったのか、それともこの件が「OPを解雇させたツイート」だったために報復だったのかも疑問だ。

  • すでに共有した以上のことは言わないが、この件は大手テック企業で働く経験と、AIが生む混乱を示していると思う。
    チーム、ロードマップ、インセンティブの面でもそうだし、ユーザー行動の変化という面でもそうだ。

    • 明確に文書化されたオープンソース公開手順のガイドラインに従っていたのかを明らかにしてくれると助かる。
      「何かを作ったから解雇」と「ルールに従わなかったから解雇」は別の話だ。
    • 気の毒だ。
      そのツールは個人的にG Workspaceをずっと便利にしてくれたし、どのカレンダープロジェクトを使うかを決める要素でもあった。
      顧客にとって製品をより有用にしたことで解雇されるのは、かなり皮肉だ。
      自分が作ったClaude skillと一緒に使うと、重要な会議向けのLogseq会議メモページを作る時間が大幅に減る。
      Gよりずっと価値を分かってくれる場所にうまく落ち着いてほしい。
    • FAANGで働いたことがないので気になるのだが、Googleには製品リリース前に厳格な手続きや承認があるのか、そしてこのプロジェクトがその手続きを通ったのか知りたい。
    • 詳しく追えていないので、すでに出た話を繰り返させる質問かもしれないが、突然解雇されたのか、それとも会社との対話があり、それがうまくいかなかったのか気になる。
  • 5年前、必要に迫られて非公開の製品APIをリバースエンジニアリングし、複雑なログインまで処理するCLIを作り、公開されていない管理機能を扱えるようにした。
    世界でおよそ100人には非常に有用だったが、それ以上ではなく、公開リリースに向けた勢いはまったく得られなかった。
    ところが自分の組織から遠く離れたDistinguished Engineerがまさにそのツールを必要とするようになると、突然会社のリーダーシップからイノベーション賞を受け、法務がオープンソース公開を迅速に通してくれた。
    こういうものを法務レビューなしで公開リポジトリに押し込むのは自殺行為だ。