Googleスプレッドシート開発秘話：リアルタイム共同編集への挑戦

まえがき

Googleスプレッドシートは、いまや多くの人々や企業で利用されるクラウドベースの表計算ソフトです。しかし、その誕生の裏にはどんな物語があったのでしょうか？本記事では、Googleスプレッドシートの開発秘話に焦点を当て、初期の背景からリアルタイム共同編集の技術まで、開発者たちの挑戦と工夫の歴史を追ってみます。

初期開発の背景ときっかけ：スタートアップからGoogleへ

Googleスプレッドシートの原点は2Web Technologies社という小さなスタートアップに遡ります。同社はJonathan Rochelle（ジョナサン・ロシェル）氏とFarzad “Fuzzy” Khosrowshahi（ファルザド・「ファジー」・コスロシャヒ）氏によって創業され、「XL2Web」と呼ばれるウェブベースの表計算アプリケーションを開発していました。ロシェル氏は金融業界のIT分野で働いた経験を持ち、従来の表計算ソフト（Excelなど）が「デスクトップに閉じ込められている」ことに課題を感じていました。共同創業者のファジー氏は「複雑な財務モデルのスプレッドシートを即座にウェブアプリに変換する」アイデアを思いつき、そのプロトタイプを作り上げます。本来であれば半年はかかるような機能を短時間でウェブ上に再現できたことで、二人はこの技術にビジネスチャンスを見出しました。

こうした背景から2005年6月、2Web TechnologiesはGoogleに買収され、ロシェル氏ら創業メンバー4人はニューヨークのGoogleオフィスに合流します。当時Googleはオンライン版ワープロのWritely（Upstartle社）も買収した直後で、オンラインアプリケーションによるオフィスソフトの構築を模索していました。この流れの中で、2Web Technologiesの技術は「Google Spreadsheets」へと姿を変えることになります。ロシェル氏自身も「私たちは昨年GoogleのNYオフィスに加わり、リアルタイムで情報を共有する問題の解決策を模索しました。表計算こそ明確なターゲットでした」と述べており、メール添付によるバージョン不整合など従来の表計算の欠点をウェブ技術で克服しようとしたのです。

そして翌2006年6月6日、GoogleはGoogle Labs上で「Google Spreadsheets」を限定テストとして初公開しました。このリリースは先着順の招待制で行われ、ロシェル氏が公式ブログで「情報をすぐ共有できるスプレッドシート」を強調した投稿を行っています。当初からこのサービスの狙いは単なるExcelクローンではなく、「素早く簡単に同じスプレッドシートを共有しながら使えるようにする」ことにありました。実際、ロシェル氏は当時のインタビューで「このプロジェクトはExcelと競合することよりも、ユーザーがスプレッドシートを公開・共有できるようにすることに焦点を当てている」と述べています。これはGoogle自身もExcelの全機能をすぐに置き換えるつもりはなく、まずコラボレーション（共同編集）という新たな価値に注力していたことを示しています。

なお、Google Spreadsheetsは限定テストから数ヶ月後に全ユーザー向けのベータ版へ拡大され、同年10月には前述のWritelyと統合する形で「Google Docs & Spreadsheets」として正式公開されました。この統合によって、文書と表計算をウェブ上で扱うGoogleのオフィススイートが本格始動したのです。

開発チームの構成と中心人物

Googleスプレッドシート立ち上げ時のチームはわずか4名という極めて小さいものでした。中心人物であるJonathan Rochelle氏はプロダクトマネージャー（後にGoogle Docs全般のPMリーダー）としてプロジェクトを牽引し、共同創業者のFarzad “Fuzzy” Khosrowshahi氏はフロントエンドのエンジニアとしてユーザーが触れる表計算アプリのUI部分（ブラウザ上で動作するJavaScript）を構築しました。もう一人のキーパーソンがMicah Lemonik（マイカ・レモニック）氏で、彼は当時若きバックエンドエンジニアとしてリアルタイム同期のエンジンを開発しました。レモニック氏が生み出したこの共同編集エンジンは、のちにGoogleドキュメント（Docs）の新バージョンやスライド（Slides）、図形描画（Drawings）、デジタルホワイトボード（Jamboard）など他のコラボ製品の基盤ともなっていきます。

創業メンバーの4人目はEvelyn Kao氏で、彼女は買収後しばらくしてGoogleのファイナンス部門に異動しました（後に検索チームのPMとなる）。そのため、実質的に開発の中心はロシェル氏（PM）、ファジー氏（フロントエンド開発）、レモニック氏（バックエンド開発）の3名でスタートしたことになります。Google参加後、最初の一年で新たに加わったエンジニアはたった一人だけでした。新人のJohn Danaher（ジョン・ダナハー）氏が新卒でチームに入り、ファジー氏＆レモニック氏と共にスプレッドシートのコードを書き上げていきました。デザイン面ではBraden Kowitz氏が必要最低限の支援を行いましたが、当時Google内部ではこのプロジェクトは正式な重点事業というより実験扱いで、潤沢な人員も予算も与えられていなかったのです。

それでもこの小さなチームを支えたのが、Google社内の有志の支援者たちでした。著名なエンジニアリーダーであるAdam Bosworth氏は2Web買収を推進し、プロジェクトの将来性を信じて後押ししました。また、エンジニアリングマネージャーだったAlan Warren（アラン・ウォーレン）氏は、チームに裁量と必要最低限のリソースを与えつつ、Googleの巨大インフラにこのサービスを乗せるための社内調整役となりました。ロシェル氏はウォーレン氏について「彼は我々に必要な縄（猶予）と空中支援、そしてエンジニアリングの規律を与えてくれた。本番用マシンを用意し、この実験を続行する勇気をくれた」と感謝を述べています。まさに大企業の一角でひっそり進むスタートアップ的プロジェクトを、信念あるマネージャー達が陰で支えた形です。

技術的アーキテクチャと進化（JavaScriptからWebAssemblyへ）

初期のGoogleスプレッドシートは、当時のWeb技術の限界に挑むものでした。アーキテクチャ設計としては大きく分けて、「サーバー側の計算エンジン」「Ajaxを活用したブラウザ上のクライアント」「リアルタイムのコラボレーション層」「データ保存層」という構成をとっていました。具体的には、計算処理（数式の計算など）はサーバー側で実行し、ブラウザ側はJavaScriptでユーザーインターフェースと基本操作を担います。そして複数ユーザーの同時編集を調停するコラボレーション用のロジックが加わり、最終的なデータはGoogleのインフラ上のストレージに保存される、という形です。Googleの大規模インフラストラクチャのおかげで、理論上はマシンを追加するだけで負荷に耐えられるスケーラビリティが得られましたが、その反面「まずGoogle規模でスケールできるようにしてからでないとローンチできない」という制約もありました。小さなチームにとって、この巨大インフラへの適合作業は決して容易ではなく、ローンチ前の大きなハードルだったといいます。

幸い、2006年の限定公開時点ではこのアーキテクチャで社内外のテストに耐えることができました。当時の内部コードネームは「Trix（トリックス）」と呼ばれており、ロシェル氏が頭をひねって命名したものです。社内では「Trixを使った？」という会話が交わされるようになり、ローンチ日にはカフェテリアのシェフがTrixシリアル（シリアル食品）でライスクリスピートリートを作ってお祝いしてくれたというエピソードもあるほどです（Trixという名前はMatrixから取ったもので、長らく社内で親しまれたコードネームでした）。

その後の技術的進化も目を見張るものがあります。計算エンジンに関して言えば、最初期はJavaで書かれたサーバーサイドのコードが中心でしたが、2013年頃から大きな転換が行われました。よりインタラクティブな操作性とサーバー負荷軽減のため、計算処理をブラウザ（クライアント）側でJavaScript実行する方式に切り替えたのです。Google Web Toolkit（JavaコードをJavaScriptに変換するツール）や後継のJ2CL（Java to Closure Compiler）を使って既存のJava計算エンジンをJavaScript化し、Web Worker上で動かすという大胆なアプローチでした。この移行の際には、Java版とJavaScript版の計算結果が厳密に一致するよう大規模な検証も行われました。JavaScript版への移行当初、計算速度はサーバー版（Java）よりも3倍以上遅かったものの、Googleはこの後もブラウザ上での高速化に投資を続けます。

そして近年、さらに画期的な技術としてWebAssembly（Wasm）が導入されました。特にWasmGC（Garbage Collection対応のWebAssembly拡張）を活用することで、Googleスプレッドシートの計算処理がChromeやEdgeブラウザ上で従来の2倍の速度で実行できるようになったのです。WebAssemblyはブラウザ上でネイティブに近い高速実行を可能にする技術ですが、従来JavaScriptで動いていたコードを直接置き換えるには課題も多く、特にJavaのようなガベージコレクション言語をそのまま移植するのは困難でした。そこでChromeブラウザのV8チームとGoogle Workspace（Google Docs/Sheetsの開発チーム）が協力し、JavaのコードをWasmGCにコンパイルする実験が行われました。2021年には試作版が動き始め、2022年にかけて最適化を重ねた結果、最終的にJavaScript版の約2倍の性能を達成するWasm版エンジンが完成しました。これは初期のWasm版（最適化前）の4倍にも及ぶ改善であり、長年チューニングを重ねてきたJavaScript実装をさらに凌駕する成果となりました。2024年6月にはGoogle公式ブログでも「ChromeとEdge上でSheetsの計算速度が2倍になった」ことが発表され、裏側で活躍するWasmGC技術についても触れられています。

このように、Googleスプレッドシートの技術アーキテクチャはサーバー中心からクライアント中心へ、さらにブラウザ性能の限界に挑むべくWebAssembly活用へと進化してきました。現在も初期ロード時間の短縮やコピー&ペースト性能の向上など継続的な改善が図られており、15年以上経った今も「より快適なスプレッドシート体験」への挑戦が続いています。

リアルタイムコラボレーションの実現方法（OTとCRDT）

Googleスプレッドシート最大の特徴は、複数ユーザーによるリアルタイム共同編集でしょう。同じシートを同時に編集しても各ユーザーの画面が即座に同期し合い、まるで一つのパズルをみんなで組み立てているかのように作業できます。この魔法のような機能を支えるのが、Operational Transformation（OT）と呼ばれるアルゴリズムです。Googleはドキュメントやスプレッドシートのリアルタイム協調編集に早くからOT技術を採用しており、「Google Docsでは、複数人が同じ箇所を編集する際の衝突を避ける方法としてOTを使い、数多くの変更が同時に起きたときも全員の編集内容が正しくマージされるようにしています」。OTは一種の差分合成アルゴリズムで、各ユーザーの編集操作（挿入、削除、変更といった操作）を操作履歴（トランスフォーム）として記録・変換することで、順序の異なる変更同士も矛盾なく適用できるようにします。

具体的には、各クライアント（ブラウザ）は自分の編集操作を即座にローカルに反映しつつサーバーに送信し、サーバーは受け取った操作を他のクライアントへブロードキャストします。もし同じ箇所にほぼ同時に変更が加わった場合でも、サーバーおよび各クライアントが保持する操作履歴をもとに整合性の取れた位置への調整（トランスフォーム）を行います。例えば、あるユーザーがセルA1に入力を始めた直後に別のユーザーが同じセルに入力した場合、一方のクライアントは自分の変更をまだサーバーから承認されていない「未確定変更」として保持しながら、届いた他人の変更を適切に位置ずらしして適用します。このようなプロトコル設計により、Googleスプレッドシートではネットワーク遅延に左右されず手元で操作ができ、かつ最終的には全員の編集内容が統一されるというリアルタイム性と正確性を両立しています。

OTはGoogle WaveやGoogle Docsによって広く知られるようになった手法で、Googleスプレッドシートも基本的に同じ原理で動いています。もっとも、近年リアルタイム共同編集の分野ではCRDT（Conflict-Free Replicated Data Type）という別手法も注目されています。CRDTは各クライアントがデータの複製を持ち、最終的に全員が同じデータセットに収束するよう数学的性質を持たせたアルゴリズムです。OTとCRDTはいずれも同時編集の矛盾解決を目的としていますが、そのアプローチには違いがあります。Googleのプロダクトは歴史的に集中管理型のOTを採用してきましたが、CRDTは分散システムやオフライン編集の分野で強みを持ち、競合他社のコラボレーションアプリ（例：Figmaなど）が採用するケースも出てきています。

Googleスプレッドシート開発当初、OTはまだ新しい技術でしたが、先述のMicah Lemonik氏が構築した独自エンジンによって、このリアルタイムコラボレーションが実現しました。ロシェル氏は「ファジーの強引なまでのフロントエンドJavaScriptと、マイカの画期的なリアルタイム共同編集バックエンドエンジンをつないだ瞬間、これはGoogleブランドに値する何かになると確信した」と述懐しています。実際、社内テスト（ドッグフーディング）でも最初は100～200人程度だったアクティブユーザーが、UI改善後にはほぼ全社員（約5,000人）に広がるほど高い支持を得ました。「共同編集が即座に体験できる」というインパクトが利用者を惹きつけ、この技術こそがGoogleスプレッドシートの価値の核になったのです。

他のスプレッドシートソフトとの違い・競合戦略

Googleスプレッドシートの登場は、従来のデスクトップ型表計算ソフト、とりわけMicrosoft Excelに対する新たな挑戦でした。しかし興味深いことに、当初GoogleはExcelと真正面から競合するつもりはなかったといいます。ロシェル氏は「Excelのことは熟知しているが、当時のGoogleスプレッドシートは到底Excelそのものではなかった」と語っています。事実、2006年の公開時点でGoogle Spreadsheetsがサポートしていた関数はExcelのごく一部（約210種類程度）に過ぎず、ピボットテーブルやマクロ、複雑なグラフ機能など高度な機能は軒並み未対応でした。Googleはむしろ「スプレッドシートというキャンバスを使って、情報共有とコラボレーションを改善すること」に使命を置いており、プロジェクトをLabs（実験作）扱いにしてベータ版として提供することでユーザーの期待値をコントロールしたのです。

当時のExcelは機能豊富な業界標準ソフトでしたが、リアルタイム共同編集やクラウド上でのどこからでもアクセスといった点は持ち合わせていませんでした。Googleスプレッドシートはその弱点を突く形で、「インストール不要・無料で使える共同編集表計算」という新市場を開拓したのです。この戦略は一定の成功を収め、特に小規模チームや教育分野で爆発的に普及しました。後にMicrosoftもOffice Web Apps（現：Web版Office）やOffice 365の共同編集機能で対抗しますが、Googleが先行者利益を得た領域でもあります。実際、Googleスプレッドシート公開当初から「GoogleはオンラインアプリでMicrosoft Officeに対抗するスイートを用意しつつある」という見方がされており、Microsoftの当時のCEOであるSteve Ballmer氏も「Googleに代表されるソフトウェア・サービスモデルは我々にとって最大の挑戦だ」と述べるなど、相手社内に危機感を抱かせました。

機能面で見ると、Googleスプレッドシートは年月とともにExcelに追いつくべく進化を続けています。例えばグラフ作成やピボットテーブル機能の追加、関数の大幅拡充、さらにはマクロ機能（Apps Scriptを利用）の提供など、かなり高度な分析・開発まで可能になりました。また機械学習を活用した「探索（Explore）」機能では、自然言語で質問するだけでデータの集計やグラフ提案を行うなど、Excelにはない独自色も打ち出しています。

一方でExcelにも依然として優位な点があります。特に超大規模データの処理や高度にカスタマイズされたマクロ（VBA）の世界では、デスクトップアプリであるExcelのパワーは依然強力です。Googleスプレッドシートも拡張により1000万セルまで扱えるようになりましたが、Excelの理論上の行数（約100万行）などと比べると、絶対的なデータ容量ではExcelに軍配が上がります。またオフライン環境での利用や、レガシーな業務システムとの連携など、企業ユースでの歴史的資産の部分ではExcel＋Officeスイートのエコシステムが依然根強いものがあります。

Googleはこうした差を埋めるため、Excel互換性の強化にも取り組んできました。2010年にはExcelファイルをそのまま複数人で編集できる技術を持っていたDocVerse社を買収し、その成果を取り入れてOffice文書とのリアルタイム互換編集を改善しています。また2012年にはモバイル向けOfficeスイートを手掛けていたQuickoffice社を買収し、スマートフォンやタブレットでの表計算編集能力を高めました。これらはExcelユーザーや企業ユーザーを取り込む戦略的布石と言えるでしょう。

総じて、Googleスプレッドシートは「競合に追いつく」のではなく「違う土俵で競う」ことで発展してきたと言えます。リアルタイム共同編集やクラウド連携といった新機軸でユーザー体験を革新しつつ、必要に応じて既存ソフトの強みも取り込んでいく――その柔軟な戦略が今日の普及につながったのです。

社内外の苦労話や開発エピソード

小さなチームから始まったGoogleスプレッドシート開発には、多くの苦労話やエピソードが伝えられています。当時を振り返ってロシェル氏が語るのは、「2005年当時、Webアプリを作るのは今よりずっと大変だった」という点です。ブラウザは未成熟で、通信のリアルタイム化も始まったばかり。開発者たちはロード時間短縮のためにコードを極限まで削ったり、まだ標準化されていないCSSの代わりに「ハック的なHTMLと初期のJavaScript」でUIを作り込んだりと、試行錯誤の連続だったといいます。「ブラウザを言うことを聞かせるためにだまくらかすようなコーディング」と表現されるこれらの工夫は、快適とは程遠いユーザー体験を少しでもマシにするための涙ぐましい努力でした。さらに、このプロジェクトがGoogle規模のトラフィックに耐えることも求められていたため、4人のチームには「Google級にスケールするものを作る」というプレッシャーも重くのしかかりました。

また、ユーザーインターフェース（UI）の難しさも語られています。社内テスト中、最初期のGoogleスプレッドシートは機能自体は画期的だったものの、アイコンのデザインや操作感には改善の余地がありました。ユーザーからは「列を固定したい」「ドラッグ＆ドロップで操作したい」「コピー&ペーストが直感的でない」等、多くのフィードバックが寄せられ、開発チームはそれに応える形で2006年夏から秋にかけてUIをブラッシュアップしていきます。ロシェル氏は「UI専門家の助けをもっと早く得るべきだった」と振り返っており、特に「プロダクトマネージャーは良いアイコンを作れない」という教訓を得たと冗談交じりに述べています。実際、UI改善後に社内利用が急増したことからも、使いやすさの重要性を痛感させられたようです。

社外に目を向けると、ユーザーデータの信頼性という課題もありました。クラウド上の表計算というコンセプトが新しかった当時、多くの人は「自分の大事なデータをオンライン上に置いて大丈夫だろうか？」という不安を持っていました。開発チームもそれを認識しており、「ユーザーのデータは神聖なものだ。絶対に信用を損なってはいけない」という信条でサービスを運営していたといいます。ベータ版の段階からユーザーの要望や不安の声に耳を傾け、「データは常に安全に保存され、権限を持たない他人から見られることはない」という点を強調することで徐々に信頼を勝ち取っていきました。また、サービス安定性にも細心の注意が払われ、万が一サーバーが落ちてもデータが失われない設計や、編集履歴からいつでも復元できる仕組み（リビジョン管理）などが早い段階から導入されました。

買収交渉時のエピソードも興味深いものがあります。ロシェル氏は、最初Google側と会った際には「Googleはこの種の製品に興味は無い」と一度は断られかけたそうです。しかし、その場でファジー氏が作ったWebスプレッドシートのプロトタイプを実演してみせると、Googleの担当者は思わず「Wow、これは動くじゃないか」と驚き、態度を一変させました。その瞬間から話はとんとん拍子に進み、Google側も買収に乗り気になったといいます。「動くプロダクト」を目の当たりにしたインパクトが、机上の議論を覆したエピソードと言えるでしょう。

最後に、Googleスプレッドシート開発の歩みを振り返るタイムラインをまとめます。

2005年6月：Google、2Web Technologies社を買収。NYの小さなスタートアップチーム（ロシェル氏ら4名）がGoogleに参加。
2006年6月6日：Google Labs Spreadsheetsとして限定公開スタート（ロシェル氏が公式ブログで発表）。
2006年10月：オンラインワープロのWritelyと統合し、正式版「Google Docs & Spreadsheets」を提供開始。
2007年2月：Google Docs & Spreadsheets、14言語対応でグローバル展開。
2010年3月：Microsoft OfficeプラグインのDocVerse社を買収。ExcelやWordのファイルを複数人で共同編集する技術を取得。翌月、その技術を活かしたリアルタイム編集の改良をGoogle Docs/Sheetsに展開。
2012年6月：モバイル向けオフィススイートのQuickoffice社を買収。
2012年10月：サービス名を「Google Sheets（スプレッドシート）」に正式変更。Chromeウェブストアでショートカットアプリ提供開始。
2013年頃：計算エンジンをサーバー(Java)からクライアント(JavaScript)へ移行完了。以降、リアルタイム性能と操作性が向上。
2014年：Google Sheets単体のモバイルアプリ（Android/iOS版）リリース。オフライン編集モードのサポート開始。
2016年：Microsoft Office（Excel）との双方向同期を可能にするアドオンなど互換性強化策を導入。
2018年：機械学習機能「Explore（探索）」を追加し、自然言語での質問応答や自動グラフ生成に対応。
2020年：オフラインモード強化・共有ドライブ対応など、企業利用を意識したアップデート。
2023年：計算エンジンをWebAssembly(Wasm)対応版に刷新開始（Chrome開発チームと協働）。順次一部ユーザーから高速化をテスト。
2024年6月：計算速度2倍化（WasmGCの活用）を正式発表。AIアシスタント「Duet AI（旧称: Gemini）」によるシート自動生成機能のプレビュー提供開始。

あとがき

こうした歴史を経て、Googleスプレッドシートは単なる実験プロジェクトからGoogle Workspaceの中核サービスへと成長しました。ロシェル氏はローンチから17年を振り返り、「これは小さな試みから始まったが、私たちチームにとっては全てだった」と述べています。リアルタイム共同編集という当時は「ささやかな技術の点」に過ぎなかったものが、現代のコラボレーションツールの常識を作り、ひいては人々の働き方を変えました。開発に携わった彼らの情熱と工夫があったからこそ、今日私たちはオンラインでシームレスにスプレッドシートを共有できているのです。