タイトルを見て，奇妙に感じた方が多数いたことだろう。標準仕様の遵守と互換性の確保は，ほとんど同義とも言えるからだ。
ISO（国際標準化機構）/IEC（国際電気標準会議）を含め，各種の標準化団体がさまざまな標準仕様を策定する主目的は，互換性を高めるためである。当然，そうした仕様を守った方が互換性が高まるわけで，標準仕様の遵守と互換性の確保は両立するもの---である。だが，中には標準仕様の遵守によって，“過去の資産に対する”互換性が犠牲になることもある。
例を挙げよう。ISO/IECのC++言語仕様では，for文の中で宣言した変数の有効範囲（スコープ）はfor文の終わりまでである。ところが，米MicrosoftのVisual C++ 6.0（1998年に登場）以前のC++コンパイラでは，for文を含むブロックの終わりまで有効だった（Visual C++ .NETについては後述）。このため，以下のようなコードはISO/IECの言語仕様では全く正しいにもかかわらず，Visual C++ 6.0では「変数iが2度定義されている」と認識され，コンパイル・エラーが生じてしまう。
for(int i=0; i<10; i++) sum += i; for(int i=0; i<10; i++) sum2 += i;
ここで，「だからMicrosoftは…」と思うのは早計である。MicrosoftがC++コンパイラをこのように実装したのは，もとはと言えば，C++の初期のドラフトではそうなっていたためである。Visual C++に限らず，かつてC++コンパイラは，for文の中で宣言した変数の有効範囲をfor文を含むブロックの終わりまでとして扱っていた。
その後，有効範囲をfor文の中だけに限定した方が好ましいことが分かったため，C++の言語仕様のドラフトはそのように改訂された。Borland C++をはじめとするVisual C++以外の各種C++コンパイラは，次のバージョンアップでその仕様変更に従った。これに対してVisual C++は，過去のコードに対する互換性維持を優先し，以前の仕様のまま据え置いたのである。
Visual C++ 5.0/6.0は，テンプレート周りの不具合などもっと深刻な問題を抱えていたので，それに比べればfor文中で宣言した変数の振る舞いなどはささいな問題であったとも言える。あるいは，いつまた変わるとも知れないドラフトの仕様変更に合わせて変更するのは意味がないと考えたのかもしれない。だが，ISO/IEC C++の言語仕様が正式に策定された後も，何年も放っておかれたことを見ると，互換性維持の優先というのは言い訳に過ぎなかったのではないかと疑いたくなる。
IE6向けWebページがIE7だと異常表示？
最近の話題では，2006年にリリース予定のInternet Explorer（IE） 7のCSS（カスケーディング・スタイル・シート）対応が気になる。
現バージョンのIE6は，リリース時期が古いこともあってFirefoxやOperaなどの最近のWebブラウザに比べて，CSSのサポート状況などが見劣りする。このため，最新のブラウウザのみならずIE6でも期待通りにページが表示されるようにするには，ブラウザを判別して，FirefoxやOpera向けにCSS標準に従ったWebページを記述する一方で，IE固有の振る舞いやバグを逆手にとってIEでも閲覧できるようにするなどの，面倒な作業が必要になる。IE7では，この点を改良し，CSSのサポートを大幅に強化する予定だという。
問題は，CSSとの互換性を高めることによって，これまでIE6で正常に表示されていたWebページのうち，期待通りに表示されなくなるものが出てくる可能性があることだ。
調査によって細かい差異はあるものの，IEのシェアは約9割を占めている。世の中のサイトの大部分はIEで正常に表示できることを前提にデザインされているし，個人サイトや社内だけで閲覧するイントラネットには，対応ブラウザがIEだけというWebページも少なくない。Microsoftはこの点を考慮して，IE7では標準に準拠するモードと以前のIEとの互換性を重視したモードの2つを用意する予定だが，十分な互換性が保たれる保証はない。
IE7の公式ブログでは，Microsoftは互換性と標準サポートが両立しない場合には互換性を捨ててでも標準サポートを優先すると述べている。記者はこのこと自体は英断と評価したい。いつまでも過去との互換性を気にしていては，進歩は望めないからだ。特に，過去との互換性が不具合すらも再現することを意味するならなおさらである。
「こちらを優先」は，最大限の努力をした上で言うべき
記者が不安なのは，標準サポートの声の基に，過去の資産に対する互換性が不当にないがしろにされることである。電子商取引サイトや大手ポータル・サイトなどがIE7に対応するのは，顧客を増やす，もしくは減らさないという理由あってのことだろう。しかし，イントラネットの業務用Webアプリケーションでは，IE7に対応しても業務の生産性が上がることは期待しにくい。できるなら手を入れたくない，というのが本音だろう。いくつかの企業のシステム部に取材した際も「バージョンアップで一番重要なのは互換性」という声が多かった。
結局，標準の遵守と互換性の確保は両方とも大切なのである。どちらか一方を優先するというのは，十分な努力をした上で言うべきことだ。どうあがいても両立しないケースがあるのも事実だが，現実的な解決策を見出せることも少なくない。
先のC++コンパイラの場合には，標準準拠モードと互換モードの2つのコンパイラ・オプションを用意すればよいだろう。そうすれば，プロジェクト・ファイルやmakeファイルを多少変更するだけで両方のコードをコンパイルできるようになる。
実際，Visual C++ .NETはfor文の中で宣言した変数の扱いを変更するオプションを用意している。実はVisual C++ 6.0も（for文に限らず）言語仕様全体を標準に準拠させるオプション（/Zaオプション）を備えていたが，有効にすると付属するヘッダー・ファイルがコンパイルできないなどの理由で事実上使いものにならなかった。
ブラウザの場合はどうだろうか。ページをデザインする側と，閲覧する側が異なるために，単にブラウザにモードを2つ設けるだけでは問題は解決しない。閲覧者に対して「このページをご覧になる際にはブラウザの○○オプションを設定してください」などと言うわけにはいかないからだ。Webページによっては，ページの中にDOCTYPEによる指定を埋め込むなど，ブラウザに対してモードを自動的に切り替えるよう指示する必要が生じる。互換モードの互換性が不十分なら，さらに多くの修正が必要になるかもしれない。
だが，その手間を軽減する工夫はできるだろう。ページを自動的に修正する移行支援ツールや，Internet Information Services用の拡張モジュールを配布する，というのがその例だ。限りある開発リソースをそうした後ろ向きの機能に振り分けることはできないというのなら，正式版リリース後でもよい。何らかの救済策を提供してほしいものである。
新製品投入時に，過去の資産との互換性を重視しなかったためにシェアを落とした例は，枚挙にいとまがない。15年以上のパソコン歴がある方なら，IBMがPC/ATとの互換性を捨て去ってPS/2を投入したときのことを覚えていらっしゃるだろう。PS/2は互換機メーカー製のPC/AT互換機にシェアを奪われ，結局IBMも元のPC/AT互換路線に戻らざるを得なくなった。Visual Basic 6.0ユーザーの取り込みに失敗したVisual Basic .NETも，こうした例の一つと言えるかもしれない。
2006年には，MicrosoftはIE7以外にもWindows VistaやOffice 12（開発コード名）などの主力製品をバージョンアップする予定である。Office 12では標準の文書ファイル形式をこれまでのOffice 97形式からXMLベースのものに変更するという。記者自身は，過去の成功にあぐらをかかないこうした挑戦をうれしく感じる一方で，ユーザーがバージョンアップしようとする気をそがれてしまわぬよう，互換性確保にも力を注いでほしいと思っている。それがユーザーにとっても，Microsoft自身にとっても，ためになることなのだから。
