1) 安中 浩、 2) atokam、3) 松澤 太郎、 4) 江後田 基弘、 5) 引地 重幸、 6) 伊藤 正、 7) 桃井 勝彦、 8) kattin、 9) 河合 亮彦、 10) 小池 和彦、 11)片貝 正紀、 12) 中島 紀之、 13)神部 竜二、 14) 信沢 たかし、 15) 加賀屋 拓臣、16) 外山なお、 17) 伊藤 正、 18) 齋藤 雅昭、 19) 中野 雅之（本城涼）、 20) 春永 浩敏
2001年8月の中旬に始まったもじら組日本トップ・ウェブサイト テスト・プロジェクトは2001年12月9日頃テストの部を無事終了した。テスト・プロジェクトで発見されたバグに関しての処理はまだ残っているものがあるが、プロジェクトの総括的な報告書をここで公にすることによって、日本もじら組有志の活動記録として、日本のみならず世界のMozillaボランティアのお役に立ちたいと思う。更にもう一つの目標としてウェブサイト開発に関わっている人たち、ウェブサイト開発に関心のある報道関係者の方のお役に立てれば、プロジェクト参加者一同、とても喜ばしいと思う。（この文書は近々英訳されます。）
2001年7月23-27日に米国サンディエゴ市で O'Reilly Open Source Convention (以下 OOSC） 年次大会が開かれ、その最後の日に催された「Mozilla Developer Day」（Mozilla開発者 Day）でMozilla 1.0について議論された。日本の「もじら組」からは小池和彦が参加した。その席上で桃井（米国ネットスケープ社ウェブ標準担当）は、Mozilla 1.0までに多くのウェブ・サイトでMozillaではそのページがきれいに表示されないとか、機能がうまく作動しないとかの問題をなるべく最小限に止めることが必要だと発言した。これはMozilla開発が一般に使用されるブラウザ・テクノロジーを提供する立場である限りは、避けて通ることのできない問題だと認識されたからである。その為にはいわゆる「エバンジェリズム」（宣教）活動を通して、ウェブ標準に則ったウェブページ作成を推奨することが重要ではないかと発言した。
OOSCの後、小池は Mozilla.orgの客員としてカリフォルニア州、マウンテン・ビュー市にあるMozilla.orgの本部で数日を過ごした。Mozilla.orgと席を隣にする桃井と小池は更に日本におけるエバンジェリズム活動について話し合った。もじら組の運営するmoz-usersメーリングリストの購読者の中からボランティアを募り、日本のトップ・ウェブサイトをMozillaブラウザやMozillaの使用するGeckoレイアウト・エンジンを搭載したNetscape 6.xのようなブラウザで現在どれだけ問題なくブラウズ出来るのかを検証することは意義のあるプロジェクトではないかということで意見の一致を見た。
小池は更に、日本のトップサイトを公開されているデータから決定すべきだと提案した。商用に会社向けに出版されているデータはあるのだが、それだとウェブサイトのランクは公開できないからである。Netscape内部にはMediaMetrix社などの調査による統計データはあるが、原則として公開できないデータは使用しないことに決定した。
ここで小池が目に付けたのは、エキサイトのサーチ・エンジンで使用されているカテゴリー別の人気サイトランキングである。16あるカテゴリーの中では、ユーザが訪れる回数を基に★の数を五つまで示すことによって、人気上位のサイトを分別している。これは、ウェブ・リサーチ会社の提供するような正確なランキング・データではないかも知れないが、ユーザが選んだサイトの統計ということで、それなりの信憑性はあるし、何よりも公開されているデータである。Mozilla活動はオープン・ソースであり、「公開の原理」はこのようなプロジェクトでも大事である。
上記のような合意のもとに、小池の日本帰国後に桃井はMozilla日本トップサイト テスト・プロジェクトの発表とボランティア募集のメールを出してプロジェクトの意義を説明した。[注。記事 moz-users: 03658.] その趣旨は次のようなものだった：
Mozillaに搭載される Geckoエンジンはウェブ標準の正しいサポートを目標としている。そのGeckoエンジンをを使ったブラウザで日本のトップサイトを閲覧した時に、どれだけの成功率があるのか。それをなるべく組織的な方法で、なるべく正確に知ることによって、MozillaやGeckoベースの他のブラウザ(例えば Netscape 6.x)が対応しなければいけないことが明確化される。更に、ウェブサイト側でのよく起こる問題が浮き彫りにされると思う。
この呼びかけに対して最終的には18人もの参加申し出があった。当初は数人も参加者があればと考えていたオーガナイザーもこの反響には驚いた。しかしプロジェクトの広範な意義と実際にこのように日本のトップサイトを或るブラウザを使って具体的に調査するという企画は他にも今までなかったことを考えるとこの結果も頷けるものがある。
この18人に加えて、プロジェクトが始まってから中野雅之と春永浩敏がバグ分析担当で参加した。
更に、テストを終了後に感じられることはこのボランティア・グループは非常にレベルの高い人たちが集まったということである。プログラマーの観点からウェブサイトのデバッグやコード修正案を提供してくれたボランティア、HTMLやCSSの部門での知識を生かしてサイトの問題を見つけたり、分析をしてくれた人たち。更に自分のサイトを運営してきた知識を生かしてレイアウトの問題を見つけてくれた人たち。Bugzillaの使用法を高度に理解した何人かがこのプロジェクトから生まれたバグを管理、進行、結論へと導いてくれた。
一つ一つのウェブ・サイトをトップレベルのリンクや機能も含めてテストするということ結構時間のかかるものであり、上記のテスタはこれを辛抱強くこなしていった。日本の「もじら組」活動は主に大学生以上の人の参加が多いのだが、このプロジェクトで特筆すべきは、信沢、外山, 加賀屋という現役高校生が加わってくれて、活躍したことだ。
日本版 Bugzillaでのバグ管理は担当・分析に中野雅之と小池和彦がメインで、春永浩敏、中島紀之、神部竜二が援助した。更にQAコンタクトとして桃井勝彦がサポートに回った。小池はこの他にも総合役を務め、プロセスの進行を滑らかにする役割を担った。
このように、顔を合わせずにメールだけでプロジェクトを進めるという方法だったが、時間が当初の予定よりかかったことを除けば、成功と言える成果を生み出した。
Mozilla 日本トップ･サイトテストプロジェクトは2001年8月13日ころ開始された。具体的な手段は次のようなものだった：
テストの方法は最終的にはテスター個人の判断に任せることにして、一応輪郭的な事項は桃井の書いた二つの文書にある要領ですることになった。詳しいことは「テストの注意点」と「ウェブ・サイトをテストする時のチェック・ポイント」で参照できるが、前者はテストを進める上での全体的な流れを説明したものであり、後者はウェブ・サイトでよくある問題についてそのタイプや見極め方を説明している。尚、各テスターはウェブ標準については知識の深い人たちが殆どで、その経験から蓄えたツールや参考文献を使用したことは言うまでもない。
ここでテストを進める上での中心的な役割を果たしたのが小池の作ったテスト・プロジェクト・トラッキングツール（テスト報告ツール）である。このツールは：
このツールは公開されているので下記のURLからダウンロードして参照することができる。
http://www.mozilla.gr.jp/webtest/webtest.tgz
今までに既に二つの違ったレポートがこのテスト・プロジェクトに関して書かれている。小池は [moz-users:0417]の記事でテスト結果のサマリーを書いているので、この報告書でもその結果を取り入れた。中野雅之はプロジェクトに途中から分析担当でリクルートされたが、その重要な活動を通してプログラマーの観点から感じたことを下記のURLで公開している。
http://www.toybox.jpn.org/mozilla/webtest/report.html
この感想は現プロジェクトの大事な問題の一つ、ウェブ開発者側の現状について率直な分析と意見を述べている。その内容はウェブ開発に関わっている人たちに是非読んでいただきたいと思う。
この他にも、テストボランティアの松澤太郎が感想を出している。テストする過程でウェブ開発・テストに関する意識が変化して行ったこと等について書いている。
http://homepage2.nifty.com/btm/mozilla/taro_matsuzawa_report.html
その他にもプロジェクト用の MLを通して、幾人かのメンバーが意見を寄せている。上記以外のメンバーも感想を書く予定であり、それらについては本文書の最後のセクションを参照。
ボランティアの数とテスト期限を照らし合わせて、実行可能な数にURL を絞ることにした。テストの対象となるURLを決定するのには次の手順で行った。
Excite.co.jpの分類の仕方で特徴のあるのは、単なるアクセス頻度数によるランキングではなくて、ある程度細分化されたカテゴリー内でのトップサイトを五★で選んであることだ。このような分類により、普通のランキングとは一味の違うシステムになっている。ある意味では広範なカテゴリーのトップサイトを代表するサイトのリストになっており、広範にわたるユーザのブラウジング嗜好をより反映した分類である。
このセクションでは、テストの結果を日本版Bugzillaから採取して、色々な角度からテーブル形式でまとめる。
| 重複するバグとして解決されたもの | 13 |
| 再テストした結果問題が認められなかったもの | 12 |
| 重要な問題ではないので修正しないと決定したもの | 2 |
| 無効なバグとして解決されたもの | 3 |
| 解決されたバグの総数 | 21 |
| 現在最終解決のないバグの総数 | 49 |
| 現在最終解決のない標準化コンポーネントのバグ | 42 |
| 重複するバグとして解決されたもの | 7 |
| 再テストした結果問題が認められなかったもの | 10 |
| 重要な問題ではないので修正しないと決定したもの | 2 |
| 無効なバグとして解決されたもの | 2 |
| ウェブ・サイト側やMozilla側で修正して現在問題のないもの | 18 |
| 現在最終解決のないバグ | 42 |
| 重複するバグとして解決されたもの | 6 |
| 再テストした結果問題が認められなかったもの | 2 |
| 重要な問題ではないので修正しないと決定したもの | 0 |
| 無効なバグとして解決されたもの | 1 |
| Mozillaで修正されたもの | 3 |
| 現在最終解決のないバグ | 7 |
| ブロッカー （サイトが全然使えない、見れない） | 0 |
| 重症のバグ（サイトのメジャーな部分や、機能がうまく使えない） | 0 |
| メジャーなバグ（重症ではないが、サイト使用上で少し問題になる） | 2 |
| マイナーなバグ（他のブラウザとの違いはあるが、気にならない） | 5 |
| ブロッカー （サイトが全然使えない、見れない） | 0 (0%) |
| 重症のバグ（サイトのメジャーな部分や、機能がうまく使えない） | 2 (4.7%) |
| メジャーなバグ（重症ではないが、サイト使用上で少し問題になる） | 1 (2.3%) |
| 普通のバグ（問題はあるが、サイトは使える） | 25 (59%) |
| マイナーなバグ（他のブラウザとの違いはあるが、気にならない） | 8 (19%) |
| 些細なバグ（バグとしては上げてあるが、修正しなくても問題がない） | 5 (11.9%) |
| サイト側での問題としてではなく、仕様の向上が望ましい点のあるサイト | 1 (2.3%) |
| 問題を分析して、解決法が分かり、サイト側に通知して結果を待っている | 34 (81%) |
| 一度は解決したが又問題が起きているサイト | 2 (4.7%) |
| まだ解決法に一致を見ていないサイト | 6 (14.2%) |
CSS/HTML/JavaScript等の記述が正しくないサイト |
35 (44%) |
| JavaScriptでIEやNN4に対応しているが、Mozilla/NS6には対応していないサイト | 10 (12.5%) |
| IEにしかない非標準の独自機能拡張を使用しているサイト | 10 (12.5%) |
| 無効なバグ・修正する必要のない問題・調査の結果、問題ではなく仕様と分かったサイト | 9 (11.2%) |
| Mozilla側のバグか、Mozilla側で対応した問題のあるサイト | 8 (10%) |
HTTPサーバーの動作が標準に従っていない |
3 (3.7%) |
| Mozilla側の問題か、サイト側の問題か決定できない問題（実装上の違い？） | 2 (2.5%) |
| Javaのバグ | 2 (2.5%) |
| 問題というより新仕様のリクエスト | 1 (1.2%) |
(*) 3つまったく同じバグが登録されいているので、それらを1と計算すると、80が総数となる。
| CSS/HTML/JavaScript等の記述が正しくないサイト | 17 (40.4%) |
| JavaScriptでIE4以上やNN4に対応しているが、Mozilla/NS6には対応していないサイト | 9 (21.4%) |
| IEにしかない非標準の独自機能拡張を使用しているサイト | 6 (14.2%) |
| Mozilla側のバグか、Mozilla側で対応すべき問題のあるサイト | 4 (9.52%) |
| HTTPサーバーの動作が標準に従っていない | 3 (7.14%) |
| Javaのバグ | 2 (4.8%) |
| Mozilla側の問題か、サイト側の問題か決定できない問題（実装上の違い？） | 1 (2.38%) |
まず最初に特筆すべきは、現在ウェブ標準化の問題が残っているサイト42のうち、本当に大きな問題があって Mozillaでは使えないというサイトは非常に少ない(7%)ということが分かる。Table 4 で分かるように、未解決の総数のうち3つのサイトがこの分類にあてはまる。
同Table で、未解決の問題が残っているサイト42のうちで、問題があるが何とか使えるサイトが約59%。そして、約 33%はサイトを使うのに全然と言ってよいほど支障がない。これはテストする側が一般のユーザでは気がつかないような詳細にいたるまでウェブ・サイトを検証したからである。
上記の結果をテスト対象となった487の全サイトに当てはめてみると、
ということになって、使用に支障が少し以上あるサイトは487サイト中 5.7% である。一般に500近くのウェブサイトを取り上げれば、問題が全然ないブラウザは存在しないし、3-5%位のサイトで多少の問題があってもおかしくはないと思われる。
前にも述べたように、Mozillaには 「Geckoエンジン」と呼ばれるレイアウトの中枢モジュールが組み込まれている。GeckoエンジンはMozillaのみならず、Netscape 6.x やその他のデバイスなどでも使用されている埋め込み可能な、次世代レイアウト・エンジンである。Netscape社のNetscape Navigator 4.xとはまったく違ったコードで書かれているし、最近ブラウザの世界にオープン・ソースの形で登場したものである。その様な事情を考慮に入れると、5.7%の問題率は、特にサイト使用不可能な問題が0.6%というのは、高い数字ではないと思われる。
更に Table 5で分かるように、標準化コンポーネントで未解決のバグのうち 81％ (34)は既にウェブ標準に準拠した範囲での修正案が分かっており、サイトの方にも連絡を行っている。後は結果待ちである。
Table 3aはこのテスト・プロジェクトで見つかってブラウザのバグとして登録されたものの内訳である。最初19あったバグは現在は6となっている。更にTable 3bによって、サイトを利用する上で大きな支障となるバグはないことが分かる。一つだけ残っているメジャーなバグはサイトで JavaScriptで生成されたページに後のページから戻れないというものである。JavaScriptで生成したページは「履歴」に登録されないというものである。それ以外は全てマイナーな問題でサイト使用と言う観点からは支障にはならない。
Table 6 で分かるように、ウェブ標準関係で登録されたバグ80の内55（69％）は3つのタイプに分類できる。上記の3つのカテゴリーは最近のウェブ標準のテストには必ず出てくるタイプだ。もう一つのカテゴリー（10％）はMozilla側のバグだ。更に Table 7 で現在未解決の42のバグの内、76％に当たる32のバグが同じ3つのカテゴリに分類できることが分かる。小池の報告書 も参照にしながら、これらの3つのカテゴリーについて更に説明を付け加えると以下のようになる。
これが一番多い問題だった。問題は色々とあるが、タグの閉じ忘れ、タグの順序の間違い、間違った文字コードの指定、等初歩的なものから、テーブルを含んだ複雑なものまであった。この他のカテゴリーで特筆すべきはサーバから送られて来る、MIMEタイプや文字コードのHTTPヘッダー指定にも間違いがあった。
これらの問題がこのテストの対象となったようなメジャーなサイトにあるということは残念なことだ。何故こういう問題がサイト側で事前に解決できないのかという疑問が残る。これに関しては中野雅之の感想報告書で指摘している通りである。ここで引用させてもらうと、
このような問題の解決の大きな壁となっているのが、Netscape Navigator 4.xや Internet Explorer 5/6の「親切な間違い処理」にある。幸いにして Mozilla内蔵の Geckoエンジンはこういった「親切」解釈は極度に少なくしている。僅かにある「親切処理」も標準モードでは全然していない。Quirksモードと呼ばれる前ブラウザ互換モードでは厳選したものに限って「親切」処理をすることがある。しかしIEやNetscapeの独自拡張機能はQuirksモードでも殆どサポートしていないし、標準モードでは当然サポートしていない。
更にもう一つの原因は多くのサイトでページ作成・維持にかけることの出来る人員が限られていることだ。その為に、主要なブラウザだけでテストしてそれでよしとする慣習があることは否定できない。
これらの問題に関して、テスト・プロジェクトの担当者は W3C標準に準拠した解決法を提示して修正をお願いした。
IEとNetscapeのブラウザを分別する処理は多くのサイトで行われているが、その主な理由はダイナミックHTMLと呼ばれる動的なサイト開発でのブラウザ間の違いやCSS対応におけるブラウザ間の違いに対応するために、IE4/IE5とNN4を区別しないといけなかったからである。これはダイナミックHTMLを可能にするウェブ上のオブジェクトを参照するのに、document.all (IE)と document.layers(Netscape 4)という互換性のない方法を両社が推奨したことによる。こういう分別方法はIE 4とNetscape Navigator 4だけの世界では有用だったのかも知れないが、IE5/6やMozilla/Netscape6の世代にこれを持ち込むことは無意味なことだ。
プロジェクトの調査の結果、結構多くのサイトで、
という分岐を採択していることが分かった。MozillaやそのGeckoエンジンをベースにしているNetscape 6.xのブラウザはどちらかとIE 5.5以上のバージョンに機能の観点から近いものだ。しかし、上記のような分別法だと、Mozillaを分別しないという問題と更にNetscape6.xをNetscape 4.xと同じに扱うことになってしまうという問題が起こる。そして、レイヤーなどのNetscapeの独自拡張機能を使用するので、JavaScriptの機能が応用されなかったり、CSSの設定が応用されないという不具合が起こるということになる。
この問題に対して、このテスト・プロジェクトの分析担当者が推薦したのは、
という選択肢だ。これを使用すれば、Mozillaだけでなく、Netscape 6.xやその他の Geckoエンジン・ベースのブラウザ、更にIE 5/6もその対象に入る。W3Cの標準準拠ブラウザというのは例えば、W3C DOM APIの属性があるかないかで分別が出来る。つまりダイナミックHTMLを作るのに必要な特定な属性があるのかどうかを判別のツールとして利用するという一石二鳥の方法だ。もしそのブラウザに必要な属性があるなら、IE/Mozilla/Netscape/Operaに関わらず使えることになる。同じように、CSSのサポートに関してもIE5/6とMozilla/Netscape 6は同じカテゴリに分類したほうが都合がよいので、この方法を効果的に使うことができる。小池の報告書で参照している下記のバグなどが参考になる。
2の分別法として使われている document.all などもこれに入るのだが、主に <MARQUEE>,<BGSOUND>等のHTMLタグ、HTML属性としてTOP/BOTTOM/LEFT/RIGHT MARGIN, bgproperties、CSS 属性としてdropshadow, bordercolorlight, bordercolordark, 等々。
この中でウェブサイト側で意図的に使用していると思われるものは <MARQUEE> タグだけではないかと思われる。他は深く意識しないで、これらを使えば主にテストしているブラウザでうまく行くからというだけの理由から使用されている可能性もある。いずれの場合でも、テスト分析担当者は代替案としてW3C標準の範囲内で出来るものを提示することで一致している。
例えば Marqueeタグではhttp://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1237のバグがあるが、これに対してはJavaScriptを使用した代替案が提案されている。このように、少数の例外を除いては、独自拡張機能を使わなくても同じ効果が得られる。
尚、Netscapeの独自拡張機能を使用しているサイトの問題は上記の 2で扱った。何故かと言うと、IEの独自拡張機能だけを使用しているサイトはあるが、Netscapeの独自拡拡張機能だけを使用しているサイトは殆どないからである。また、この例の殆どが document.layersを使用した分別用の選択肢であり、更にその Layerを利用して IEとの違いに対処にしているので、2のカテゴリーで扱うのが妥当だと思われるからである。
ここでは、プロジェクトの現状をまとめ、更にこのプロジェクトの結果から考えられる将来への展望について述べてみる。
今回のテストの結果により、標準準拠をモットーにしたMozilla (Geckoエンジン内蔵）次世代のブラウザでも少数のサイトを除いては十分に使えるものであることが分かった。少なくとも今回のターゲットとなった日本のメジャーなサイトに関しては将来の展望が明るいと思われることは大きな収穫だった。今回は対象がwww.excite.co.jp の五つ星の人気サイトから選ばれたが、勿論違ったランキングの仕方もあるわけだし、そこでも同じような結果が出るとは断言できない。そういった限定はあるものの、excite.co.jpの人気サイトは日本のインターネットサイトの一つのバロメータとして素直に受け取っていいのではないかと思う。
テストの観点からはこのプロジェクトは終了した。現在未解決のバグについては、分析担当の何人かがフォローアップを行っている。主にメールを出して修正を頼んだサイトへの再連絡、そして少数の修正提案の出ていないバグでは、その解決法を打ち出せるように努力することだ。後者の中には、Mozillaコードに新しい要素、属性、仕様などが入るの待たなければいけないケースもある。
このプロジェクトへの参加についてボランティアの方の中には最初はそれ程乗り気ではなかった人もいる。だが、実際にサイトのテストや分析に関わることによって、このプロジェクトの意義を再評価した人が幾人かいた。「ウェブ標準を語る」ということと「実際にテストをして日本での標準に関する状況を把握する」とは違うことだと思う。このプロジェクトは議論の領域から飛び出して、まず現実を見てみようという一つの目的があった。その目的は成功したと言っていいと思う。このようにボランティアもプロジェクトを通して貴重な経験したと言えよう。日本のMozillaコミュニティーから20人近い人たちが参加を表明してくれたということはありがたかった。
更に、ボランティアのタレントはウェブ・サイトの開発に関わっている人たちがウェブ標準の知識を深め、応用し、将来の問題を軽減することを援助するという面で大いに発揮された。ボランティアの幾人かは現状に問題があるにもかかわらず、プロジェクトの経験を通してウェブ開発者達に広く話し掛ければ何とかなるのではないかという楽観的な気持ちを表明している。
創立されてすでに何十年も経っている業界とは異なって、インターネットは精々この十年間である。既に規準を異にする種々の規格がはびこっている業界とは違って、インターネット業界はまだ標準準拠の夢が果たせる段階にある。ブラウザのベンダーに対しての標準遵守の声は国際会議や国際組織の討論などでますます強まっている。ブラウザ・ベンダーが独自の拡張機能を推奨できる時代はもう本当に終わりに来ているといってもいいだろう。
まだ不完全ではあるが、Mozillaはその標準準拠を旗に掲げているブラウザ開発プロジェクトである。標準に関しての問題があるなら、Bugzillaで訴えれば、修正してもらえる。また、出来る人は自分で修正コードを書いて提出してもいい。この開発形態の特徴を生かして、これからもウェブ標準の広い採択を目指して活動して行くことが期待される。
これらの結果を踏まえて、将来の課題としてはどんなものがあるのか箇条書きにしてみる：
このように将来の課題は幾つもあるので、適切なボランティア活動を続けることが望ましい。
この報告書では殆ど触れていない問題として、ウェブサイト構築をする上でどのような全体的を計画を立てるべきかということである。これについてプロジェクト・ボランティアの中から感想、意見の形での貢献を期待したい。（下記セクション 6 のリンクを参照のこと。）
最後に、このプロジェクトの成果としてボランティア諸氏が出版などの形での啓蒙活動を続けることを期待する。「Web Site Design」第三号にこのプロジェクトの成果に基づいて中島紀之が執筆した記事が掲載されたので、参照頂ければ幸いである。
注: この報告書は必要に応じて将来アップデートされます。