GoogleにおけるIDEの歴史：なぜエンジニアは独自の開発環境を追い求めるのか？

Ciderって名前にウケる。今Clojureを触ってるんだけど、CIDERっていうEmacsのプラグインが爆発的に人気なんだ。コンパイルとか補完、デバッグ、REPL統合とかをめちゃくちゃいい感じにこなしてくれるやつ。今じゃvim-ciderプラグインもあるし、他のIDEのClojureプラグインの多くもバックエンドにcider-nreplを使ってる（本家のCiderもそれを使ってる）。誰も気にしないだろうけど、毎日使ってる超ニッチなツールが、別の超ニッチなツールと同じ名前なのが面白いわ（笑）

最初はひどいダジャレで始まったんだけど、そのまま定着しちゃってさ。Geminiによると「Critique」って呼ばれてるウェブベースのコードレビューシステムが「cr/」にあるんだけど、Ciderはまさに「CRにIDEをぶち込んだ」ってこと。

彼らはdiffやPRのことを「change lists」と呼んでて、2014年以降に入社した人のほとんどはcr/の代わりにcl/というショートリンクを使ってるよ（もっとも、20年じゃなくて15年くらいしか使われてないから「比較的新しい」って意味だけどね。今ではこの2つはほぼエイリアス扱い）。まあcidelだとなんとなく響きがしっくりこないけどさ。

CLはPerforce由来だよ。

理由なんてないけど、いつか全員強制的にjtskに移行させられて、Cider Vが完全に廃止されるんじゃないかって恐怖がある😭

同じく怖い。現時点ではエディタとしてCiderを使うJtsk webが唯一の道。

マジで？俺がいた頃は、物理ワークステーション（それか、Cider-Vがまだ初期段階だったから、リモートのIntelliJにCRD接続するっていうさらに酷い環境）じゃなくて、会社がクラウドトップとかCiderを強制してくるのが本当に苦痛だったよ。当時のCiderは半分くらいの機能しか使えなかったし。退職する1年くらい前に、ようやく古いCiderからCider-Vへ正式に移行したんだ。歴史は繰り返すね。

Cider-Vは悪くないよ。標準的な選択肢って感じだから使ってるし、無難なデフォルトではあるね。でも、前の職場でIntelliJを使ってKotlinを書いてた時と比べると、退化したように感じるな。

例えば、構文ハイライトが更新されるのに何分もかかることがある。今日あったことだけど、インクルードが抜けてて修正して、ビルドしてから10分くらい席を外したんだ。戻ってきたら、Ciderはまだインポートがないと判断してた。

¯\(ツ)/¯

IntelliJでそんな経験はなかったな。まあ、Kotlinのコードベースが比較にならないくらい小さかったっていうのもあるけど。それでもイライラするよ。

IntelliJには、VSCodeやLSP界隈ではまだ再現されてない機能がいくつかある。変数の由来をトレースできる機能は、コードの仕組みを理解するのに最高だよ。

まあ、そのうちAIが足りない機能を補完してくれるようになるのかもね。

それってIntelliJ対Ciderの問題じゃなくて、小さなリポジトリとGoogleの巨大なモノリスの問題じゃないの。

確かにそれはわかるよ。ワークステーションにリポジトリ全体をインデックスさせるなんて期待できないし、毎秒何度もコミットされる環境で分散インデックスが常にうまくいくなんて思ってない。でも、自分の作業範囲は比較的狭いんだ。手を付けていないファイルには分散インデックス、編集したファイルにはローカルのインデックスを組み合わせるようなレスポンスの良いIDEがあってもいいんじゃないかな。ていうか、たぶんそうしてるんだろうけど、時々何が起きてるのか追えなくなっちゃうんだよね。要するに、普段は十分使えるレベルなんだけど、もっと良くなるはずだということ。もっと良い体験をしたことがあるから、Cider-Vならその差を埋められるんじゃないかと思ってる。

どこのリポジトリで働いてるの？g3かAndroid？俺の記憶だと、Androidのプロダクトチームは2024年時点でもJetBrains IDEのサポートがかなり充実してたはずだけど。もちろん当時はインデックスのフリーズが頻発するのが少し問題だったけど、スライスされたチェックアウトをする方法はいろいろあったし。

どのリポジトリで作業してるの？g3それともAndroid？

g3だよ。

確かAndroidのプロダクトチームはみんなJetbrainsのIDEサポートがかなり充実してたはずだけど

結局メインはAndroid Studio使ってるの？（もちろん、社外秘や内部情報は言わないでね。）

それも違うな。モノレポだからといって、全てのコードがツールの有効範囲内になければならないわけじゃない。もしそれが根本的な問題なら、そのツールは設計が悪いってことだ。

シンタックスハイライトの更新がたった数分で済むって！？Dartだとそうはいかないんだよね…😑 LSPが半分くらいの確率でずっと止まったままになるし、同じファイル内でctrl+clickして定義にジャンプすることすらできない……。普段使ってるCiderなんて、ほとんどただのメモ帳と化してるよ。

ミリ秒単位でのシンタックスハイライト、それに1〜2秒で足りないインクルードを的確に提案してくれる。C#のコードベースならそれが普通だよね。

ChatGPTが公開されたその日にシンタックスハイライトが動かなくなった。

ああ、それはこれまでIDEを使ったことがない人にとって「問題ない」レベルってだけだよ。Googleの新卒採用されたエンジニアにはそういう層が結構多いからね。

CiderVなんてただのVSCodeのフォークだし、VSCodeと大差ないよ。

昔のCiderの方がずっと安定してたよ。ロールアウトを担当したPMもかなり嫌なやつだったしな

私は（おそらく大勢いたであろう）Ciderの保守派の一人で、無理やり引きずり出されるまで古いCiderに固執してたクチだ。確かにCider Vは素晴らしいよ（コード検索やforge統合周りの特注のパワーユーザー向け機能はずっと後になるまでなかったけどね）。ただ単に新しいインターフェースを覚えるのが嫌だっただけさ。

自分でも驚いたのは、Android/Javaエンジニアとして、8年間の在籍期間中にいつの間にかAndroid StudioをCiderで置き換えられていたことだ（もちろん、画面上を歩き回るcalicosやcorgiesが目当てだったわけで、結局のところただの立派なgclレビュアーになっていたという事実とは何の関係もないけどね）。

著者が辞めたのと同じ時期（2024年中頃）に私も退職したから、状況がどう変わったかは分からない。最近はJetski/Antigravityが皆に押し付けられてるって噂をよく聞くけどどうなの？

あと、退職して2年経つのに、いまだに無意識にブラウザでcsと入力しちゃうんだよね。それが一番恋しいことかもしれない。実際、今でも狂った元恋人みたいに、as/を https://cs.android.com/ にホットワイヤリングしてるよ。

それは違うな。今でもかなり最高だよ。

彼らのビジネスモデル全体が、広告販売とプライバシーの破壊の上に成り立ってるからな。まさに悪の権化だよ。

どういう理由で？

それでも十分イケてるよ。FAANGの中で報酬が一番高いわけじゃないかもしれないけど、最も評価されてる場所の一つだ。もし報酬だけを重視するならOpenAIみたいな最先端のAIスタートアップに行けばいい。でも、福利厚生（報酬以外）、ワークライフバランス、カルチャー、開発体験、そして取り組む内容（業界を形作るような、オタクとしてワクワクできる純粋にクールなエンジニアリング）を考えると、Googleは今でもトップクラス、いやトップだよ。

もうイケてないのは確かだし、54,987番目のGoogle社員なんて誰も気にしない。中核製品はどんどん改悪されてるしね。でも、この記事は内部の様子をすごく上手く描写してるよ。よくあるIDEの導入話だと「新しい幹部Xが全員VSCodeを使えと命じた」とか「好きなものを使っていいけど、ITがサポートするのはXだけ」みたいなのばかりだけど、Googleは独自ツールに何百万ドルも投資して、そのメリットを開発者に売り込んでるわけだから。

参考までに、Laurentのブログ記事からHacker Newsにリンクが貼られてるよ： https://news.ycombinator.com/item?id=48073979 こっちの方が、実際にそこで働いていた人たちによる本質的で建設的な議論がたくさんあるね。

いや、みんな無理やり使わされてたよ。導入を主導したPMは個人的には嫌な奴だったし、CiderにできてCider Vに重要な機能がないっていう正当な苦情を言う人たちに対してもすごく嫌味な態度だった。

モノレポとかマジで勘弁してほしいわ。

入社前は疑ってたけど、実際かなりうまく機能してるよ。うまく動かすためにかなり作り込まれたツール群が用意されてるんだ。

初期に採用した悪手なやり方を後になって修正できずに、そのせいで独自の社内ツールが必要になるなんて環境、自分なら絶対楽しめないな。

[削除されました]

Googleがどこかの時点で解決しなきゃいけないのは、プロダクトをどうやって切り離すかだね。モノレポでやるにしても、今の開発手法が外部に与えている悪影響は明らかだよ。リリースノートも新機能もないまま10個のGoogleアプリがアップデートされるのを見るのはもううんざり。新しいものを作るんじゃなくて、既存のプロダクトを長期的にサポートして改善してほしい。私は今でも、Hangoutsの頃みたいにGoogle VoiceのメッセージをChatで確認できるようになるのを待ってる。YouTube MusicのTV用アプリも、Google Musicにあったようなちゃんとしたものが出るのを待ってるんだ。どれも新しいプロダクトじゃないんだから、リリースから何年も経って前任者を追いかけてるなんて言い訳は通用しないよ。Googleは巨大で鈍重な怪物になってしまった。開発手法のせいで、新機能を追加するだけで途方もない作業が必要になってるんじゃないかと思えてくる。それに、Googleの社外向け開発ツールは社内での利用による恩恵を受けていない。例えば、IntelliJのGeminiプラグインは数週間も壊れてた。ちょっとしたバグじゃなくて、かなり深刻なレベルでね。アイドル状態でもメモリとCPUを食い潰すし、入力ボックスの端っこをクリックしないと反応しないとか。マーケットプレイスで議論になって、プレースホルダーのテキストが入力フィールドを覆っちゃってることにようやく気づいてチームが修正したんだ。それまでは、何百ものレビューで指摘されてて明らかにバグってるのに「再現できない」の一点張りだった。Googleが何をしていても、それがうまくいっていないのは明らかだよ。イノベーションも更新もクオリティも全部低下してる。もっとアジャイルな体制にならなければ、Googleが優位性を保っている分野すら失うリスクがあるよ。

[削除されました]

残念なことだよ。背景を少し説明すると、大学時代に私はGoogle User Groupを運営してたんだ。Androidは1.xから使ってるし、2.xからAndroid開発者としてやってきた。Googleで働くことは長年、間違いなく夢の仕事だった。今でもサイドプロジェクトでGemini用のGodotプラグインを作ってるくらいさ。

こう言ってるのは、これらのコメントがラッダイト運動（技術否定）やGoogle嫌いから出ているわけじゃないと理解してほしいからだ。全くそんなことはない。

もしAndroid TV向けのYT Musicアプリや、Google Voice向けのRCSを作る機会があれば、喜んで飛びつくよ。ただ、Googleには迷走してほしくないんだ。最近は、もうすでに迷走してしまっているように感じることもあるけどね。

まあ、それは人それぞれだね。君が間違ってると言いたいわけじゃないよ。ただ、自分も最初は疑ってたけど、実際に使ってみたらかなりうまく機能してるなと思っただけ。ほとんどの企業はある程度の社内ツールを開発するものだし、大規模な会社ならそれなりに大規模なツールを作る余裕もあるでしょ。

問題なのは社内ツールを作ることじゃなくて、その『理由』なんだよね。

変わったのかもしれないけど、数テラバイトものデータを無理やりリポジトリに突っ込むために、ツールなしでp4を書き直したなんて正気の沙汰じゃなかったね。社内に蔓延していたGUIツールへの敵対心や、コマンドラインに比べてGUIにはメリットがあるかもなんて言う人に対する軽蔑の風潮は特にひどかったよ。

正直なところ、最近はみんなCiderか好きなIDEを通してp4/git/hgのGUIフロントエンドを使ってる気がする。昔はCLのドラフトを作ってから、CLIで長文を書くのが耐えられないからCiderに移動してサブミットしてたのを覚えてるよ。今でも頑固な人たちは一定数いるだろうけど、まあまあ妥当な選択肢もいくつかあるしね。

とはいえ、開発環境は外から見ると（あるいは数年経って振り返ってみる私のような人間から見ても）かなり奇妙だと思う。Googleに入った当初、ラップトップでのローカルリポジトリチェックアウトに対する非常に厳しいポリシーがあって、ワークステーションの前に座っていることはほとんどなかった。最初は（少なくともPlay/Androidのプロダクトチームにいた私たちの間では）、ワークステーションを常時起動しておいて、MacBookからChromeリモートデスクトップで操作するのが一般的だった。これが6〜7年くらいずっと続いてた状況だよ。

その後コロナ禍になって、最初はワークステーションを再起動するためにオフィスに行くような人が本当にいた。必須アップデートでシャットダウンされた後にYubiKeyを押すためだけにね。数ヶ月のうちに、大規模なAndroidツリーのチェックアウト用にXLストレージを備えたリモート開発サーバーへと移行した。ラップトップでのコードチェックアウト制限も緩和されたけど、ツール類が追いついてなかった。ローカル環境を構築するためのスプリントを2〜3回やったけど、パンデミックが終わるまで信頼できるレベルにはならなかったな。

開発の大部分をChromeリモートデスクトップ経由でやらなくて良くなったことが、どれほど嬉しいか伝えきれないよ。

当時はcloudtopを使わなきゃいけなかったんだけど、SSHで接続してvscodeのremote機能を使うのが解決策だったな。ローカルIDEを使ってもコード自体はローカルにはない状態。Chromiumの作業には最高だったよ！macOS用にクロスコンパイルしてバイナリをローカルに落としてテストすることさえできた。だからCRDを使う必要は一度もなかったし、そのやり方の方が快適だったよ。

CiderVは「fig」（CitC、つまりアップデートされたp4のようなレイヤー上でのMercurialクライアント）との統合がうまくいってたんだよね。全部ビジュアル化されててかなり快適だったよ。大規模なリファクタリングもよくやってたけど、変更の分割や修正で困ったことは一度もなかったな。

GUIツールは最初は優先度が高くなかったんだろうけど、長年かけてかなり改善されていった感じだね。

p4の作り直しが狂気ってわけじゃないよ。そもそもp4を使うこと自体が狂気なんだから！

外部リポジトリのパッケージじゃ絶対に味わえない、内部ライブラリのソースを簡単にクリックして追いかけられる環境は最高だった。それに、必要なら作者本人にメールやメッセージを送って直接アドバイスをもらえたしね。

その通り。モノレポってのは、gitの扱い方が分からないとか、人生にもっとドラマ（面倒事）が欲しいっていう人には便利だよ。

銀行かGoogle、あるいはその両方で働いたことがないんだろうね。俺は両方経験したし、その証拠にダサいプロペラ帽子だって持ってるよ。ここ10年くらいのGoogle（雇用主と従業員という関係性）やその方向性には思うところがあるけれど……それでも、適当なお堅いディルバート企業で働くよりはマシだと思うな。

銀行で働いたことがないか、Googleで働いたことがないか、あるいはその両方だな。

ああ、以前銀行で働いたことがあるよ。だからもううんざりなんだ。今のGoogleみたいな大企業には全く興味がないのもそのせいだよ。

忘れられないのが、ある銀行がMacを厳重にロックダウンして、ほとんど使い物にならない状態だったこと。社内ネットワーク上の短いリストにある承認済みのソフトしかインストールできなかったんだ。

Homebrewも含まれてたけど、（内部的に修正されてて承認済みのBrewしかインストールできないようになってた）。

結果、士気はボロボロだしプロダクトはクソだった。なぜ銀行アプリが80年代のデザインに見えるのか知りたいなら、それは誰もまともな開発ツールを使わせてもらえなかったからだよ。

それは単純化しすぎじゃないかな。記事によると、最初はプラグイン対応のクラウドベースのテキストエディタから始まって、何年も改善を続けた結果、岐路に立たされたんだ。そこで彼らが下した決断が、既存のCIDERプラットフォームのフロントエンドにVSCodeを採用することだったんだよ。

IDEっていうのはフロントエンドそのものだよ。フロントエンドを取り除いたら、それはもうIDEとは呼べない。Neovimを終了してVS Codeを立ち上げたら、バックエンドのツールは同じでも、その時点でNeovimを使ってるなんて主張したらかなりイカれてるだろ。

この記事で面白いのは、Googleの巨大なモノレポを複数の時点にまたがってインデックスし、1秒間に何度も再インデックスするためにバックエンドで構築しなければならなかったカスタムツール全般の話だよ。彼らはVS Codeベースのフロントエンドを追加する前に、まずそれを作ったんだ。そこ読み飛ばしてない？

それ（google3）は、現時点で10年以上前から存在しているよ。

言及されているカスタムツールっていうのはgitワークフロー関連の話で、Web UI越しにリモートで動くから共有インデックスが使えるってことだよね。つまり、クライアント側でコードベースのインデックスを再構築するのが待ちきれないほど時間がかかるからそうしてるんだろうけど、それってある意味自分たちで作り出した問題を解決してるだけのような気もする。Googleなら、検索インデックスのインクリメンタルな更新をもっと効率的にやる方法を見つけ出せるはずでしょ。

それでもまだこの記事は単純化しすぎだよ。ワークフローやコードレビューへのカスタム統合を備えたCIDERのバックエンド機能は、フロントエンドから独立したものになった。でも君が言う通り、その後VS Codeのフォークにカスタマイズを追加する必要があったから、今はもうそれほど独立してはいないね。ただ、彼らが一つのIDEを選ぶ上で抱えていた問題の多くは、実はCIDERのバックエンドが糊の役割を果たすようになるまでは、どんなIDEを使っても発生する統合の問題だったんだよ。

バックエンドはIDEそのものじゃないよ。コンパイラやLSPサーバーをIDEと呼ぶ？彼らが元のIDEとVS Codeフォークの両方で同じ機能を使えたという単純な事実が、それらの機能がIDEの一部ではなかったことを証明してる。もしIDEの一部だったら、IDEをVS Codeフォークに置き換えた時点でそれらの機能も消えてたはずでしょ。

全部を動くようにするために多少の作業は必要だったはずだ。DockerやLLMとかの既存IDEへの統合に手間がかかるのと同じで、もしCiderのバックエンドが内部ツールなら自分たちで統合するしかない。でも手元にあるのは、いくつかの追加統合が施されたVS Codeのフォークに過ぎないよ。なんでその事実を認めることにそんなに引っかかってるのかよくわからないけど、それは賢い選択だったんだ。VS Codeがこれだけ普及してるんだから、社内向けの人気IDEを作りたいならそこから始めるのは理にかなってるよ。

IDEって何の略？

もちろん、Interactive Development Environmentのことだよ。何か揚げ足取りでもするかのような聞き方だけど、何が言いたいのか詳しく教えてくれないかな？今のところ、どこが「引っ掛け」なのか全然分からないんだ。

「VS Codeにちょっと統合機能を追加しただけ」なんて言い方は、プロジェクトの実際の範囲を過小評価しすぎだよ。

俺はCiderVを使ってたし、彼らの告知メーリングリストも読んでたし、テストの様々な段階にも参加してた。彼らが抱えていた課題について説明も受けてたし、単に「VSCodeプラグインを書いて動くようにしました」っていうレベルの話じゃなかったんだ。

記事の説明を読む限り、追加されたツールっていうのはgitの統合機能と、サーバーサイドの検索インデックスを共有して個別に生成する手間を省けるっていう機能くらいに見えるんだけど。どちらもIDEとは呼べない気がする。記事に書かれていないだけで、実際にはもっと凄いものがあったの？

Ciderはフロントエンドだぞ。piperとforge/blazeがバックエンドだ。

それってantigravityのこと？Cider Vかな？

Googleは君の最初の3つのルールを破棄して、最後の2つを禁止したよ

Googleのプロダクトチームの8割にとって、選択肢は実質この2つしかないんだ：

1. クラウドベースのIDE「CIDER」
2. 冗談抜きでChromeリモートデスクトップ経由で実行するJetBrains IDE

だから、まあ大変だよ。

技術的、ポリシー的、あるいは単に馬鹿げた歴史的経緯で、大体この2択に絞り込まれてるんだ。巨大企業だから、誰もがそうしたいと思っているように勝手に独自の環境を構築してカウボーイプレイするわけにもいかないしね。

Googleにいた頃は、全員がIntelliJ Ultimateを使えたよ。申請とかも特に必要なかったしね。IntelliJの方が優れている部分（オートコンプリートとか）もあるけど、クラウドエディタの便利さには勝てなかったな。

IntelliJのリファクタリング機能は唯一無二だよ。

Androidエンジニアとして働いてるけど、Android Studio（IntelliJベース）は無料だから有料のIDEなんて必要ないし欲しくもないって言うと、経理担当はいつも驚くんだよね！