グーグルにおける IDE の歴史

以前、Google の主要なコードベースが、拡張性とスケーラビリティを確保するために厳格なツールチェーンや規約を採用してきたことについて触れました。しかし長らく、一つの顕著な例外がありました—that は「開発者環境」つまり「エディタ／IDE」の選択です。

背景： 筆者は Google で 2011 年から 2024 年まで勤務しました。一部の内容は概算であり、後に報告があれば更新します。本記事は Google の主要モノリポである google3 に焦点を当てています。

分断されたエコシステム

多くの企業と同様に、Google のエンジニアも自分好みの IDE を自由に選択することができました。その結果、環境の分断が進行しました。2011 年、最 senior なエンジニアの一部に「すべての Google エンジニア向けに優れた統一された IDE は可能だろうか？」という問いかけがありました。答えは基本的に「不可能」というものでした。その中で Jeff Dean は次のように述べています。

「一団の開発者に共通のエディタへの合意を取り付けることは、不幸を招く道です。何事が重要で、どのシステムがどのような長所・短所を持ちうるかについては、人によって意見や価値判断が異なります。結果的に、それほど大きな違いにはなりません。」

この考え方は長らく支配的な見解でした。「同僚が使っている IDE はどうでもいい。重要なのはコードの質さえ保証されればよい」という発想です。しかし私は開発ツール領域で 12 年間を過ごしており、時にこの問題について疑問を抱きました。

企業生産性の観点から見ると、各エンジニアがエディタの設定に時間を使いすぎるのは望ましくありません。実際に使われている IDE は異なりましたが、有用な統合機能は結局どこでも再実装する必要がありました：Bazel サポート、Starlark ツール、コードフォーマッタ、コード検索の統合など。Google の社内文化はこれを管理可能な水準に保っていました。エンジニアらは自発的にツールプロジェクトを立ち上げることが多く、他の人が共有コードベースを通じてそれを見つけ、貢献することも一般的でした（20% タイムやピアボーナスを通じて）。こうした貢献が重要なプロジェクトに至っては、正式なスタッフ配置へと発展しました。例えば、IntelliJ インテグレーションを専門とするチームが 2015 年左右に設立されました。

なぜこのように大規模な専用チームが必要なのかと疑問を持つ人もいるかもしれません。当初から IDE が十分でなかったのでしょうか？理由の一つは、Google が独自ツールを多数用意しており、それらをすっきりとした IDE インテグレーションで使える場合、エンジニアの生産性が向上することにあります。また、もう一つの要因はモノリポの巨大さによるものです。伝統的な IDE は、ソースコード、ビルドメタデータ、インデックス化、解析などすべてをローカルで行うことを前提として設計されていますが、Google 規模ではこの前提が成立しなくなってきました。

クラウド IDE

2013 年頃（正確な時期は不明ですが）、予想外の展開がありました。一部の人が Web ベースのエディタ「Cider」を開発をはじめました。「Cloud IDE」というコンセプトに由来する名称ですが、末尾の「r」を加えることで記憶に残りやすい名前にしたといいます。

ほぼすべてのツールが Web ベースであり、コードレビューや Code Search によるコードベースナビゲーションもブラウザで行われる組織であり、Chromebook を採用している環境では、ファイルをブラウザから素早く編集できる手段があるのは理にかなっています。

しかし驚いたのは、Cider が次第に多くのエンジニアの間で普及し始めたという点です。最初はテクニカルライターを中心に使われており、バージョン管理を気にせず Markdown ファイルを編集したいというニーズを満たすものでした。ミス入力への修正も非常に効率よく、「プルリクエストを送信」のボタン一つで済み、承認後自動マージするオプションもありました。当時は GitHub でも同様の機能がなかったため、新鮮な印象でした。

時間の経過とともに、開発者向け機能も順次追加されていきました。転換点となったのは、言語サーバープロトコル（LSP）を介したコード補完機能を導入してからでした。

Cider は軽量クライアントとして、従来の IDE よりもはるかに速く起動します。「魔法」の部分はバックエンドで行われ、全体コードベースをインデックス化した上で、ユーザーがページを開いた時点で必要なデータが準備されます。

コードインテリジェンスを実現するには、各識別子をその型や参照関係に結びつける必要があります。これにより巨大な言語グラフが形成され、コミットごとに更新する必要があります。実際には毎秒多数のコミットが来るためです。また、IDE には履歴データへのアクセスも必要です。例えば私がプロジェクトを作業中、同僚がコードをマージしても、すぐにその変更を取り入れたいわけではありません。そのためエディタは、自分の最後の同期日に対応するグラフを使う必要があります（もちろんローカルの変更を上書きする仕組みが必要です）。

このような機能を含んだ Cider の採用は、特定のユーザー層でさらに高まりました。例えば、Cider を Java 開発者よりも Go 開発者に切り替えるほうが圧倒的に容易でした（Java 開発者はより高度なエディタを期待するため）。「十億行のファイル間でも検索や参照が即座にできる」という喜びは本物です。

Cider V のスクリーンショット（2022 年）

Cider V：VSCode をフロントエンドとして採用

バックエンドへの投資はその価値を十分に証明しました。Google 固有の課題を解決しており、代替案がなかったからです。しかしフロントエンド自体は比較的に制限されていた：速い修正には良かったものの、真の IDE と競合できませんでした。

方針転換が起こしたのは 2020 年、私が技術リーダーとしてチームに加入した時です。その時点で Cider は社内での主要エディタでしたので、その将来性に関する議論が起き、最終的に VSCode のフロントエンドを Cider に採用することが決定しました。これは自然な選択でした。VSCode はすでに IDE 市場で優勢であり、言語非依存、拡張可能、かつ Web 向けに設計されていました。

VSCode フロントエンドへの移行により、成熟したエディタ、豊富な拡張機能エコシステム、そして長年の累積機能を継承できました。Cider の多くが要望されていた機能も、すでに VSCode で解決されていました。より重要なのは、拡張機能システムによって全社のチームが参入可能になり、Cider チーム自体をクリティカルパスから外せた点です。

フロントエンドチームに十数名のエンジニアが関わっても、Cider を完全に代替する製品をつくるのに数年かかりました。2021 年にオープンベータ版では 5,000 人のエンジニアが使いましたが、まだ多数の統合作業や体験の微調整が残されていました。バージョン管理サポート、コードレビューツールの統合、Cider バックエンドを活用したコード補完・リファクタリング機能の実装、拡張機能のパッケージングと更新方法の再設計など、多くの課題がありました。

Cider エディタに愛着を持ち、細かい挙動まで変更を望むユーザーも多くいました。わずかなワークフローの変更やボタンクリック数の増加などが、あるユーザーにとっては採用の障壁になる可能性があります。そのため、 polishing 段階では数ヶ月にわたる反復が必要でした。例えば配色scheme の一つが話題になったりもして、論争を巻き起こすほどでした。Joshua Bloch は 2011 年の時点でこう語っています。

「プログラミング言語よりテキストエディタや IDE が宗教的熱狂を生み出すものがあるとしたら、それは何か？」

コードレビュー統合のためのデザイン探索（2022 年）

VSCode エンジニアとの相互作用や、私たちが VS コードへの変更を還元した話なども書ける内容ですが、本稿は既に長くなっています。いずれまた詳しく書きたいと思います。ここでは「ローカルフォークを維持し、月に一度更新し、可能な限りローカルハックを減らして上流コードと揃えるよう努めた」とおきましょう。

統一された IDE

記事冒頭で「Googlers 全員向けの統一 IDE」について問いましたが、完全には実現はしませんでした。しかし 2023 年までに、主要 Google コードベースの開発の 80% は Cider V で行われており（その比率はさらに上昇しています）。

各 IDE に優劣がありますが、Cider は社内ツールとの統合が極めて優れていたため多くのユーザーに選ばれました。優れたバージョン管理サポートや、レビューコメントがインラインで表示されるコードレビュー統合などが特筆されます。

私が最も刺激的だったのは、大部分のユーザーが同じツールを使うという副作用です。これにより、ツールへのリソース投資の効果が相乗的に高まり（各変更の影響範囲が広がるため）できました。私は IDE 拡張可能性を担う技術リーダーでしたところ、やがて全社のチームから連絡が来るようになり、各自がワークフローを改善する独自の拡張機能を開発し始めました。2 年後には約 100 の社内拡張機能が開発されていました。これにより以前は不可能だった多数のシナリオを実現することができました。

2023 年、経営側がすべてのチームに AI 機能をさらに深く統合するように促しました。これにより「機械学習を使ったコードレビューコメントの解決」や「コンテキストに合わせた貼り付け内容の調整（Smart Paste）」といった画期的な機能が実現されました。もちろん、AI によるコード補完も含まれます。

IDE にますます多くの AI 機能が集積してくると、単一で拡張可能なプラットフォームを持つことの優位性がより明白になっていきます。もちろん、これは非常にコストが高く、少数の企業しかこれを実現できるとは言えません。しかし、「標準（強制ではない）的な IDE への移行」が大きな影響を与えたことは間違いありません。

結局のところ、標準化したツールチェーンこそがレバレッジを生みます。

コメント欄は閉鎖していますが、フィードバックを歓迎します。Hacker News や Mastodon で議論することもできます。この種のコンテンツがお好きであれば、RSS を通じて購読いただけます。メール通知を受けたい場合は、Feedrabbit などのサードパーティツールをご利用ください。