もちろん、Googleはネットワークを介してソフトウェアを送信できるインターネット時代に育った企業だ。Googleは自社のソフトウェアを静かに、舞台裏で、ユーザーの干渉がない形でアップデートすることを好んでいる。簡単に言うと、これはGoogleが自社の検索エンジンアルゴリズムをアップデートするのと同じ方法だ。
もちろん、ソフトウェアのリリースには、今でも多くのオーバーヘッドが存在する。オンラインアップデートでも同様だ。新バージョンはデバッグ、テスト、パッケージングの後、ネットワークを介して配布しなければならない。多くの場合、車両数が少ない2本の列車よりも、車両数が多い1本の列車の方が処理しやすい。しかしGoogleは、数カ月以内に実施予定の新しいリリースプロセスによって、プロジェクト管理も多くの点でより容易になると考えている。
ソフトウェアをテストし、リリースを管理することに慣れているIT組織にとって、Googleの哲学がどれほど受け入れやすいものになるのかは現段階では不明だ。絶えず変化し、企業のIT部門がテストできないGoogleの検索エンジンに、多くの従業員が常時依存しているのは確かだ。しかし、企業のコンピュータ上で動作するソフトウェアは、ウェブサイトを訪問する際には存在しない、セキュリティリスクや互換性の問題をもたらす。
現実問題として、リリースサイクルが3カ月から6週間に短縮されても、その何倍ものサイクルに対応している企業IT部門にとっては大した問題にならないだろう。したがって、リリースサイクルを速めるというGoogleの決定で大きな変化が起きる可能性は低い。
もっと大きな問題も関係している。ユーザーがどの程度の速さでついて来られるかという問題だ。ユーザーインターフェースが変わると、ユーザーはそれまでどこにあるか知っていたコマンドを見つけるために、メニューやダイアログボックスを何度もクリックしなければならなくなる場合がある。
Chromeがアーリーアダプター以外のユーザーまで拡大するにつれて、変化はより困難になる。しかし、そのことは意外とリリースサイクルの短縮とそれほど相反することではないのかもしれない。Chromeに追加される変更点の多くは、JavaScript処理速度の向上や、ウェブプログラマーが新しいオプションを実行できるようにするほかの多数の修正点など、ユーザーの目に見えない部分に関するものだ。
換言すると、Chromeはウェブを覗くための窓ということになる。そして多くの場合、ユーザーにフューチャーショック(急激な進化に対する不安感)を与えないように頭を悩ませるのは、ウェブサイト所有者の役目になるだろう。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
NTT Comのオープンイノベーション
「ExTorch」5年間の軌跡
日本のインターステラテクノロジズが挑む
「世界初」の衛星通信ビジネス
すべての業務を革新する
NPUを搭載したレノボAIパソコンの実力
先端分野に挑み続けるセックが語る
チャレンジする企業風土と人材のつくり方
地味ながら負荷の高い議事録作成作業に衝撃
使って納得「自動議事録作成マシン」の実力