Googleのサービスを長く使っていると、「昨日まであったボタンがなくなった」「メニューの場所が変わった」「以前できた操作ができなくなった」といった細かな変化に気づくことがあります。Google検索、Gmail、Googleマップ、YouTube、Chromeなどでは、サービスを終了するほどではない小さな仕様変更も継続的に行われています。
そこで気になるのが、「こうした変更をGoogleの誰が決めているのか」という点です。基本的にはGoogle全体の細かな変更を一人の経営者が一件ずつ決めているのではなく、それぞれの製品を担当するプロダクトチームが、プロダクトマネージャー、エンジニア、デザイナー、リサーチャーなどと連携しながら判断する、と考えるのが適切です。
ただし、Googleは社内のすべての承認フローを一般公開しているわけではありません。「このボタンを消す決定は誰が最終承認したのか」といった個別案件について、外部から担当者を特定できるとは限りません。この記事ではGoogle自身が公開している開発・実験の情報をもとに、仕様変更がどのように決まるのかを整理します。
Googleの仕様変更を「Googleの誰か一人」が全部決めているわけではない
Googleは非常に多くの製品を提供しているため、検索画面の小変更からGmailの新機能まで、すべてをCEOなど一人の人物が判断する仕組みだと考えるのは現実的ではありません。
製品開発では一般に、プロダクトマネージャーが「どんな問題を解決するか」「どの機能を優先するか」といった製品面の判断に深く関わり、エンジニアが技術面、UXデザイナーやリサーチャーが使いやすさや利用者の行動などを検討します。変更内容によってはセキュリティ、プライバシー、法務など別分野の確認が必要になることもあります。
したがって「Googleの誰が決めた？」という問いは、実際には「そのGoogle製品を担当するチームの中で、誰が提案し、検証し、承認したのか」という問題になります。その具体的な担当者や承認経路は変更ごとに異なり、外部へ公表されないことも珍しくありません。
プロダクトマネージャーだけで勝手に変更しているとも限らない
「製品の仕様ならプロダクトマネージャーが全部決めているのでは？」と思うかもしれません。しかし実際の大規模サービス開発は、単独の職種だけで完結するものではありません。
例えば「検索結果のボタンを一つ減らす」という一見小さな変更でも、利用率のデータ、ユーザー調査、デザイン、アクセシビリティ、技術的な実装コスト、モバイルでの表示、広告や他機能との関係など、多数の要素が関係する可能性があります。
Googleの採用情報でも、プロダクトマネージャーについてエンジニア、デザイナー、マーケターなどの部門横断チームと協力し、製品を構想からローンチまで導く役割として説明されています。[参照] Google Careers
つまり、プロダクトマネージャーは仕様決定の中心的な役割を担うことがありますが、「PMが思いつきで決め、エンジニアがそのまま実装する」と単純化するのは適切ではありません。
Googleは実験を行ってから仕様を変えることがある
Googleのサービスでは、すべての利用者へ同時に新しい画面を公開するのではなく、一部の利用者を対象に実験・テストを行うことがあります。そのため、同じGoogleサービスを使っていても「自分には新しいボタンがあるのに家族の端末にはない」という現象が起こり得ます。
Google検索ではSearch Labsのように、開発中の機能を利用者が試せる仕組みも公開されています。GoogleはSearch Labsを、Google検索の初期段階の実験を試してフィードバックできるプログラムとして案内しています。[参照] Google検索ヘルプ「Search Labs」
公開型の実験だけでなく、サービス改善のために異なるUIや機能を比較するテストが行われることもあります。結果が良ければ対象を拡大し、期待した効果がなければ元に戻したり別案へ変更したりする、といった開発方法が可能です。
「前までできたことが突然できない」が起こる理由
利用者から見ると便利だった機能でも、Google側が永続的に維持するとは限りません。利用者が少ない、別機能へ統合できる、操作を簡素化したい、保守コストが高い、セキュリティやプライバシー上の見直しが必要、といった理由で変更・廃止される可能性があります。
例えば100万人のうち一部の人には非常に便利な機能でも、大多数が利用しておらず、その機能の存在によって画面が複雑になっているなら、製品チームが削除を検討することはあり得ます。逆に一部利用者から不評でも、全体として目的の操作が完了しやすくなっているなら、新仕様が維持される可能性があります。
また、外からは「ボタンが移動しただけ」という軽微な変更に見えても、内部では新しいシステムへの移行や将来の機能追加に必要な変更であることもあります。利用者から見た変更の大きさと、開発側にとっての変更の重要性は必ずしも一致しません。
Google検索の場合は変更・実験が特に多く見えやすい
Google検索は、継続的に多数の変更が行われる代表的なサービスです。Google Search Centralでは検索ランキングシステムの更新情報などが公開され、大規模なコアアップデートについても公式情報が提供されています。[参照] Google Search Central「Google検索ランキングの更新」
ただし、すべての小さなUI変更や内部調整について個別の告知記事が公開されるわけではありません。そのため利用者側では、「ある日突然変わった」という印象を持ちやすくなります。
検索ではランキングだけでなく、検索結果の表示方法、検索フィルター、AI機能、画像・動画・ショッピングなど多くの要素が同時に開発されています。小規模な変更が頻繁に見えるのは、こうした継続的な改善と実験が背景にあります。
なぜGoogleは全員に同じ仕様を同時配信しないのか
大規模なオンラインサービスでは、新機能を一度に全利用者へ公開するより、段階的に展開する方法にメリットがあります。問題が見つかった場合の影響範囲を抑えたり、実際の利用環境でデータを確認したりできるためです。
その結果、「昨日は旧画面だったのに今日は新画面」「別のGoogleアカウントでは旧仕様」「スマホでは変わったがPCでは変わっていない」といった状況が発生することがあります。
これは必ずしも端末の故障や設定ミスではありません。アカウント単位、地域、端末、アプリのバージョン、テスト対象などの違いが関係している可能性があります。ただし、Googleが個々の実験について対象者の選定条件をすべて公開しているわけではないため、外部から原因を断定できない場合もあります。
ユーザーから不評でも変更されるのはなぜ？
サービス変更でよく起こるのが、「前のほうが使いやすかったのに、なぜ変更したのか」という疑問です。これは個々の利用者が感じる使いやすさと、製品チームが見ている評価指標が異なることが一因になり得ます。
製品チームは特定のユーザーの感想だけでなく、多数の利用者の行動、操作完了率、利用頻度、エラー、ユーザー調査、フィードバックなど複数の材料をもとに判断できます。その結果、長年その機能を使っていた人にとっては改悪でも、新規利用者を含む全体では改善と判断されることがあります。
もちろん企業側の判断が常に利用者にとって正しいとは限りません。実際に変更後のフィードバックを受けて仕様が再変更されることもあります。そのため、使いにくくなった機能について公式のフィードバック機能が用意されているなら、具体的な問題点を送ることには意味があります。
Googleの変更が「実験」「正式仕様」「不具合」なのか見分けるには
突然挙動が変わった場合、必ずしも意図的な仕様変更とは限りません。実験中のUI、不具合、アプリ更新、アカウント設定、ブラウザー拡張機能などが原因の場合もあります。
まずGoogle公式ヘルプや公式ブログに変更の案内がないか確認します。次に別のGoogleアカウント、シークレットモード、別ブラウザー、別端末などで同じ挙動になるか確認すると、アカウント限定の変更なのか広範囲の変更なのかを切り分けやすくなります。
例えば「AのアカウントではボタンがないがBのアカウントでは残っている」なら、単純なブラウザー故障ではなく、段階的展開やテストなどの可能性も考えられます。一方、すべてのアカウントで特定端末だけおかしいなら、端末・アプリ側を確認する価値があります。
まとめ：Googleの軽微な仕様変更は製品チーム単位で判断されると考えるのが適切
Googleの細かな仕様変更について、「Googleの特定の一人がすべて決めている」と考えるのは適切ではありません。Google検索、Gmail、Chromeなど、それぞれの製品を担当する組織があり、プロダクトマネージャー、エンジニア、デザイナー、リサーチャーなどが協力して開発しています。
個々の変更では担当チームがデータ、ユーザー調査、技術的事情、事業上の優先順位などを検討し、必要な承認を経て実験・段階展開・正式提供へ進む、と捉えるのが現実に近いでしょう。ただし、Googleは個々の小変更について「誰が最終決定したか」まで公開しているわけではないため、外部から特定の社員名を断定することはできません。
また、「昨日までできたことができなくなった」場合も、正式な仕様変更とは限りません。段階的なロールアウト、アカウントごとの実験、不具合、アプリ更新など複数の可能性があります。
頻繁な変更は利用者にとって不便になることもありますが、大規模なWebサービスでは、小さく試し、結果を確認し、改善を繰り返す開発方法が使われています。Googleの画面が人によって違う、数日後に元へ戻る、といった現象も、このような継続的な実験・開発という視点から見ると理解しやすくなります。
コメント