いま Web サイトを作るときにおさえておきたい10のこと(2015年版)


Internet Explorer は、バージョン 9 から Web 標準準拠へと舵を向けました。

Internet Explorer 9、Internet Explorer 10 と、2 つのバージョンを経て、最新の Internet Explorer では、他のモダンブラウザと比較しても顕色のない Web 標準ブラウザーとなっています。

そのため、それまでの長い間 Internet Explorer で Web システムを作成してきた企業のお客様にも、これから Web システム作成される際には、 Web 標準に準拠するようにお願いするわけですが、多くのお客様から「それってどうやんの?」というご質問をいただきます。

W3C と ECMA の仕様に合致したマークアップとコードを書くだけであれば、バリデーションツールを使って検証しながらそれらを記述していけば良いのですが、ご存じのとおりそれだけでは実際の使用に耐えるものはまず出来上りません。

上記の点を鑑み、今回は、Web 標準に準拠し、かつ複数のモダンブラウザと互換が取れ、モバイルデバイスにも対応した Web ページをどのように作成していくか、最低限おさえておきたい件について 10 のポイントにまとめてみました。

「はじめて作る人にもわかるように」ということで、なかり初歩的で当たり前なものも含めているので、本職の人は おさらいと思ってご覧いただければと思います。

 

そのまえに : クロスブラウザー、スマートフォン対応の Web サイトを、低コストでもっとも簡単に実現する方法

 

Web 標準準拠はともかくとして、各 Web ブラウザーとの互換がとれ、スマートフォンにも対応した Web サイトを手っ取り早く作るには CMS (Contents Management System ) を使うのが簡単です。

ASP.NET や PHP といったサーバーサイドのロジックの開発が必要なく、静的なコンテンツのホスティングのみでよければ、多くの場合 CMS にコンテンツを流し込み、テーマを適用するだけで事足ります。Web ブラウザー同士の互換はもちろんのこと、レガシー ブラウザ、スマートフォン対応も CMS 側で自動的に行ってくれるので簡単です。

メジャーな CMS としては、WordPressMovable TypeDrupalJoomla、SNS では OpenPNE があります。

マイクロソフトの提供するクラウドサービス、マイクロソフト Azure では Web サイトを作成する際にウィザード形式でこれら CMS を含めたさまざまな OSS システムをセットアップし、すぐに使い始めることができるようになっています。

image
(Microsoft Azure Web サイト、ギャラリーの画面)

 

また、こうした OSS のシステムの Windows 環境への構築と開発用のツールとして、マイクロソフトから WebMatrix が提供されています。

そして、Google さんでは、こうした OSS の CMS をモバイルフレンドリーにするためのガイドを提供しています。

 

オープンソース (OSS) の CMS を採用する際の注意点

CMS に限らず、こうした OSS の製品を使用する場合は、製品のサポート状況や、サポート体制について充分に確認しておくことをお勧めします。

とくに、業務で使用するものであれば、製品の不具合によるトラブルや、セキュリティホールが見つかった場合の連絡やアップデートの提供などがどのような行われるかを把握しておくことはとても重要です。また、製品の開発や提供が終了してしまった場合にどうするかも考慮しておいたほうが良いでしょう。

そういった OSS の CMS の使用に不安を感じる場合は、企業向けの有償製品もサイトコア社などから販売されていますので、こうしたエンタープライズへの導入実績の高い製品を検討されるのが良いでしょう。


 

さて、ようやくここからが本題です。

 

企業の Web 担当者が これから Web サイトを作るときにおさえておきたい 10 のこと(2015年版)


はじめに

まずはじめに、Web サイトをつくるのにあたって、プランニングや方針を立てというものを行って、チームで共有しましょう。ターゲットとなるユーザーが誰であり、その誰に対してなにを行うか、ゴールを明確にしたうえで、それをどのような手法で実現するかを検討します。

Web サイトのつくるうえでの方針というものが、あまりピンとこないという人は、英国政府の Web サイト GOV.UK で「Government Digital Service Design Principles (政府デジタルサービスデザイン指針)」(※)が公開されていますので、こういうものを参考にしてみるのも良いでしょう。

(※)訳してみたのですが、著作権などが気になったので掲載はやめました。検索すると日本語訳がいくつか出てくるので、興味のある方はググっ、…bing ってみてください。ちなみにイギリス政府の英国政府の Web サイト GOV.UK は HTML5 を早い段階から採用し、政府系モダン Web サイトの先駆けと言われていました。

制作に入る前に明確な方針を立てておくと、迷ったときの判断のよりどころになるのでお勧めです。

 

1. どのデバイスをサポートするか?

サポートするデバイスを明確にしましょう。

具体的には、サービスのメインのターゲットとなるデバイスと、サポート対象とするその他のデバイスを決定します。

インターネットが普及し始めた当時、Web のクライアントは PC 上の Web ブラウザーだけでしたが、i-modeに代表される携帯電話端末の登場をへて、現在では PC 以外の Web のクライアントとして、スマートフォン、タブレットなどが使用されています。そのほか日本にはフィーチャーフォンと呼ばれるドメスティックな携帯電話端末も存在します。

image
(現在 Web のクライアントとしては PC、タブレット、スマートフォン、フューチャーフォンがある)

 

メインのターゲットデバイスは?

はじめに、サービスのメインのターゲットとなるデバイスを決めましょう。

あらかじめサービスの対象となるデバイスが決まっている場合は、当然のことながらそちらをメインのターゲットデバイスとして考えますが、もし、そのサービスを提供する既存の Web サイトがある場合は、アクセスログから各デバイスの使用状況を調べてみることをお勧めします。例えば、当初 PC を対象として作った Web サイトであってもスマートフォンの利用率が PC を上回っているのであれば、メインのターゲットデバイスが PC のままで良いのかどうかもう一度考える必要があります。

 

メインのターゲット以外のデバイスのサポートについて

前述したように、現在では Web のクライアント デバイスは複数あり、スマートフォンしか所有していない人もいれば、逆に一人で異なる複数のデバイスを使用している場合もあります。そのためメインのターゲット以外のデバイスについてもどのようにサポートするのか、あるいはしないのか考える必要があります。

たとえば、PC をメインのターゲットデバイスとした場合に、スマートフォン向けに考えられる対応のパターンは以下の 3 つです。

  1. そのまま PC 向けの Web ページを表示させる
  2. レスポンシブ Web デザインを採用し、スマートフォン向けに画面が整形される仕組みを実装する
  3. スマートフォン用の Web ページを別途用意する

余談ですが、すでにメジャーなニュースサイトなどでは、スマートフォンなどの画面の大きさに合わせてレイアウトを変えるレスポンシブ対応はあたりまえとなっています。

つまりこれは、画面を設計する際に PC 用、スマートフォン用、あるいはタブレット用と、1 つのページにつき、2 つ以上のデザインを用意する必要があることを意味しています。

 

トピック : モバイルファースト

数年前から既に、スマートフォンの年間出荷台数は既に PC の数を大きく上回っており、より多くの人にサービスを提供したいのであれば、スマートフォンの対応を考えないわけにはいかない状況になっています。さらには、現在のスマートフォンやタブレットには、一昔前の PC と同等の性能があるため、昨今ではモバイル機器の使用を前提とした「モバイルファースト」というサービスの考え方も提唱されています。こういった流れは Web ページのデザインも無関係ではなく、PC 以外のモバイル機器で接続された際に支障なく操作できるデザインが必要となります。

ただし、出荷台数ではスマートフォンのほうが PC を上回るものの、スマートフォンでは Web ブラウザーよりもアプリの使用率のほうが高いというデータもあること、画面の制約もあり、スマートフォンをはたしてサービスのメインのターゲット デバイスとするかどうかは慎重に判断したいところです。

 

2. サイトマップとページ遷移

Web サイトを構成する要素を決め、要素ごとの関係を可視化して Web サイト全体の設計図を作成します。

最初にサービス (目的) を実現するための必要な要素を列挙し、各要素をページ単位に落とし込んでから、各ページに収める機能を確定します。

各々のページに収める機能が決まったら、Web サイト内でのユーザーの導線を考え、大まかな遷移図を作りましょう。ページ遷移はもちろんですが、ページの重要度、どのページがどのページへリンクするのか、関係性を明らかにしておくと実際のページ作成が楽になります。

ページ遷移の際の情報のやり取り方法と、内容を明確にしましょう。URL だけで良いのか?、あるいはクライアント側からなんらかの情報の入力が必要になるのか?、情報が必要になるのであれば、それはどのような情報で、どのように渡すのか?、クエリーストリングで渡すのか、フォームに入力させるのか?、post か get か?、なども明確にします。

さらに、サーバーサイドに ASP.NET や PHP などのロジックがあり、API が既に出来上がっている場合は、クライアントから送られる情報が、API のどの関数の、どの引数に該当するかを明確にしておく実際の開発やメンテナンスに役立ちます。

GUI のアプリケーションを設計するのと同じく、画面と、ページ遷移から Web サイト全体の構造を設計をしていきますが、Web サイトの構造によってサービス側の仕様が過剰に影響されないようにしましょう。

画面とページ遷移は、はあくまでも対象となっているデバイス上での UI でしかありません。たとえば、PC 用とスマートフォン用では、画面のサイズが異なるのでおのずと UI は変わってきます。また、IOT の機器をターゲットと考えると、画面そのものが存在しなくなります。

 

3. ワイヤーフレームの作成

サイトマップとページ遷移が出来上がったら、ワイヤーフレームを書きましょう。ワイヤーフレームはページの設計図で、ページ内で「何を」「どこに」「どのように」表示させるかをまとめたものです。  

ワイヤーフレームがどういったものかイメージが湧かない人は、以下のサイトでさまざまなサンプルが公開されていますのでご覧ください。

ちなみにですが、画面遷移図の作成は Visual Studio 2013 Premium 以上のエディションがインストールされた環境の Powerpoint で使用できるストーリーボード機能などがお勧めです。

StoryBord
(Powerpoint のストーリーボード機能)

 

4. 基準となる Web ブラウザーの選定

Web ページの表示と動作を確認するうえで、基準となる Web ブラウザーを選定します。

Web 標準に準拠した Web ブラウザーであることが必須となるので、最低でも Acid3 テストに合格している必要があります。(とはいえ最近のモダン Web ブラウザーであればほとんどのものが合格しています。)

image
(Acid3 テストの画面)

HTML5 や CSS3 をそれほど使用しないのであれば、一番シェアの多い Web ブラウザーを基準とするのが良いでしょう。

Web ブラウザーのシェアは、StatCounter などの分析サイトで確認することができます。以下は、日本国内のブラウザのシェアを示したグラフです。

Source: StatCounter Global Stats – Browser Market Share

エンタープライズ向けの Web サイトを作る際の基準 Web ブラウザーは、過去の Internet Explorer 向けに作られた Web コンテンツへの互換機能や ActiveX のサポート、メーカーによるユーザーサポート サービスの点から Internet Explorer をお勧めします。

また、HTML5 の機能を本格的に使用する場合も、Internet Explorer を基準にすることをお勧めします。

理由としては、現在はまだ Internet Explorer が他のモダン Web ブラウザーと比較して、HTML5 関連の機能実装数が少なく(※)、シェアが大きいためです。つまり現状 Internet Explorer がサポートしている HTML5 の API であれば、他のモダンブラウザもサポートしているということです。

(※) Internet Explorer はエンタープライズ利用が多く、仕様の撤回や変更などが発生した場合の影響が大きいため、当時はまだ正式勧告に至っていなかった HTML5 の機能実装については慎重でした。今後は Spartan、新しい Edge モードの採用によりこのスタンスは変わっていくでしょう。

Internet Explorer の HTML5 機能の実装状況と、他の Web ブラウザー実装状況については status.modern.IE(https://status.modern.ie/) で、さまざまなモダン Web ブラウザーの HTML5 機能の実装比較については、Can I Use(http://caniuse.com/)HTML5test(http://html5test.com/) といったサイトで確認することができます。

image(右から status.modern.IE、Can I Use、HTML5test)

これらの Web サイトの情報を利用して、作成する Web ページで使用を予定している HTML5 の機能が、各モダンブラウザでサポートされているか確認しましょう。

#nbsp;

5. レガシー Web ブラウザーに対するデザインの方向性

HTML5 をサポートしていない Web ブラウザー= レガシーブラウザをどのようにサポートするかを考える必要があります。

メジャーな Web ブラウザーが HTML5 の機能を実装を開始してから数年経っていますが、レガシーブラウザを使用しているユーザーもわずかながら残っています。こうした古い Web ブラウザーにどのようにページを見せるか考える必要があります。

 

プログレッシブ エンハンスメントとグレイスフル デグラデーション

新旧2つの Web ブラウザーにコンテンツを提供する際の考え方として「プログレッシブ エンハンスメント(Progressive Enhancement)」と「グレイスフル デグラデーション(Graceful Degradation)」というデザインコンセプトがあります。

プログレッシブ エンハンスメントは、レガシーブラウザの仕様や機能を基準としてページの設計をおこない、モダンブラウザにはよりリッチな表現と機能を提供する方法、グレイスフル デグラデーションは、逆にモダンブラウザの仕様を基準としてページの設計をおこない、レガシーブラウザには必要最低限の機能を提供するデザインコンセプトです。

image
(レガシーブラウザを意識したHTML5のデザインコンセプト)

モダンブラウザーを基準としたグレイスフル デグラレーションのわかりやすい例としては、前出のイギリス政府の英国政府の Web サイト GOV.UK があります。

Internet Explorer のドキュメントモードを IE5 に指定して同サイトにアクセスすると、装飾のない必要最低限の情報が提供されます。

image
(レガシーブラウザでGOV.UK にアクセスすると必要最低限の装飾で表示される)

              

いっぽう、レガシーブラウザーを基準としたプログレッシブ エンハンスメントのわかりやすい例としては、日本の内閣府のホームページ (http://www.cao.go.jp/) があります。

このページは XHTML 1.0 Transitional で記述されており、レイアウトもレガシーブラウザとの互換を考慮して table タグが使用されています。その効果もあり IE5 のようなかなり古い レガシーブラウザでアクセスした場合とモダンブラウザでアクセスした場合とで、表示に大差はありません。それでいて、きちんとレスポンシブ Web デザインを採用しており、スマートフォンからアクセスした場合には、レイアウトが画面サイズに最適化されるだけでなく、コントロールの UI もモバイルデバイス用に変化します。

image
(日本内閣府のページは HTML5 を使用していないものの、きちんとモバイルデバイスにも対応している)

 

     

どちらのデザイン方針を採用すべきか

HTML5 が正式勧告となり、Web ブラウザーの自動アップデート機能によりレガシーブラウザの使用率も下がり続ける現在、レガシーブラウザーを基準としたプログレッシブ エンハンスメントを採用する理由はほぼなくなったと言って良いでしょう。

これから Web ページを作成するのであれば、グレイスフル デグラレーションを採用することをお勧めします。

<参考>

 

6. レガシーブラウザとの機能互換

レガシーブラウザとモダンブラウザで HTML5 サポートの有無を埋めるための実装技術として、ポリフィル (Polyfill) というものがあります。

ポリフィルは、レガシーブラウザのもつ独自実装や JavaScript を利用して、レガシーブラウザであっても HTML5 や CSS3 などの一部の機能が動作するようにする技術です。

ポリフィル用の JavaScript ライブラリとしては modernizrhtml5shiv.js が有名です。その他にも CSS3 用の SelectivizrIE9.js などがあります。 現在では、新旧 Web ブラウザーの HTML5 サポート有無の差を埋めるという目的だけでなく、タッチイベント(画面に指で触れたときの動作)やレスポンシブ対応(デバイスごとに異なる画面に対応すること)などを疑似的に実装するための hand.jsRespond.js といったポリフィル ライブラリも公開されています。

ただし、ポリフィルを導入する際には本当に実装すべきなのか充分に検討する必要があります。なぜならば、ポリフィルで賄えるのは HTML5 の機能の狭い一部の機能にすぎません。それは多くの場合、HTML5 から新しく導入されたタグが Web ブラウザーに認識されるようにしているだけの場合が多く、HTML5 の特徴であるリッチな機能がすべて実現できるわけではありません。また、HTML5 ポリフィルの対象となるのは主に Internet Explorer 7 や 8 ですが、このバージョンの Internet Explorer は JavaScript のパフォーマンスが高くないため、場合によってはそのバージョンの Internet Explorer を使用しているユーザーに対しページのパフォーマンスが落ちることも考えられます。

備考 : HTML5★BOILERPLATE

modernizr や html5shiv.js などをまとめた HTML5★BOILERPLATE というフロントエンド  テンプレートがあります。HTML5★BOILERPLATE は Web のフロントエンド開発に有用なライブラリや HTML、CSS、.htaccess、favicon等の各種ファイルがまとめられたテンプレートです。Web サイトから必要なものだけを選んで入手することもできます。ポリフィルに限らず、Web のフロントエンド開発に使えるさまざまなものが含まれていますので、なにが含まれているか、一度内容を確認してみることをお勧めします。

<参考>

 

旧バージョンの Internet Explorer の判断

モダンブラウザと旧バージョンの Internet Explorer とで処理を明確に別けたい場合には、Internet Explorer 9 までサポートされている「条件付きコメント」を使用することができます。たとえば、旧バージョンの Internet Explorer と現在の Internet Explorer がサポートしている JavaScript ライブラリか異なる場合、CSS の挙動が異なる場合には、これを使って src タグや link タグを振り分けることにより適切なバージョンのマッチングを行うことができます。

以下に「条件付きコメント」の記述例を示します。

<!–[if IE 7]>

    <link rel="stylesheet" type="text/css" href="ie7-style.css" />

<![endif]–>

<!–[if IE 8]>

   <link rel="stylesheet" type="text/css" href="ie8-style.css" />

<![endif]–>

<!–[if !(IE)]>

    最新のブラウザでの表示、読み込むJS/CSSファイルの指定

<!–<![endif]–>

<!–[if (IE)]>

     IE9以下のブラウザでの表示、読み込むJS/CSSファイルの指定

<!–<![endif]–>

/*@cc_on

@if(@_jscript_version == 9)

   msg.innerText = "あなたはIE9を使っています";

@elif (@_jscript_version == 5.8)

   msg.innerText = "あなたはIE8を使っています";

@end

@*/

 

なお、条件付きコメントは、Internet Explorer 10、11 でも、ドキュメントモードを旧バージョンのものにすることによって動作しますが、ドキュメントモードはあくまでも、古い Internet Explorer  の振る舞いを実行しているだけなので、@_jscript_version のような、バージョンを取得するようなものでは、実際のバージョンが返されます。

<参考>

 

禁断の技 : CSS ハック

旧バージョンの Internet Explorer を判断する方法として「CSS ハック」と呼ばれる方法があります。これは CSS の実装状況の違いや不具合を利用したものですが、その後の修正や、新しい Internet Explorer の後方互換性機能では正しく動作しない可能性がありますので、使用しないようにしてください。

 

ブラウザーの種別ではなく機能検出による判別

HTML5 の API に代表される新しい機能を使用する場合には、ユーザーが使用している Webブラウザーがその機能をサポートしているか判別する必要があります。
Web の利用がまだ PC に限られ、Web ブラウザーの種類もバージョンもそれほど多くなかった時代は User-Agent をもとに判断をすることでこの用件を満たすことができました。しかし、現在のようにスマートフォン、タブレットといったように OS やハードウェアのスペックまでまちまちなクライアントが増え、ブラウザーも多様化が進むとUser-Agent をもとにした判別は現実的ではありません。
こういった機能互換判別についての最も有効な方法は、実際にその機能の有無を検出することです。
たとえば、オブジェクトやメソッドの有無は、以下のように if 文で判別することができます。

//addEventListener メソッドの有無を判断
if (window.addEventListener) {…}

//Audio オブジェクトの有無を判断
if (window.Audio) {…}

//touchstart イベントの有無を判断
if ("ontouchstart" in window) {…}

 

JavaScript を使用した Web ブラウザーの機能検出方法については、以下のドキュメントをご参照ください。

また、Modernizr も機能検出をサポートしており、自分で記述するよりも簡易な記述で機能検出のための CSS や JavaScript コードを記述することができます。

//WebGL のサポートの有無を判断
if (Modernizr.webgl) {…}

Modernizr については以下の URL をご覧ください。

 

7. モバイル デバイス向けの画面対応

PC と、スマートフォンでは、画面のサイズや形式が異なります( PC は横長 = ランドスケープ、スマートフォンは縦長 = ポートレート) 。また、スマートフォンやタブレットはタッチ操作が前提となるため、画面内のクリッカブルな要素は、人間の指でタッチ可能な大きさにする必要があります。

こういった一連の課題を解決する方法として、画面の大きさにあわせページ内のレイアウトや要素を適切に変更することを、ひとまとめに「レスポンシブ Web デザイン」と呼んでいますが、画面の大きさに合わせてページ内のレイアウトを変更デザイン方法はいくつかあり、それらの仕組みを理解して組み合わせることで、各デバイスに最適な画面を提供することが可能になります。特徴的なものをいくつか示します。

 

■ レスポンシブ Web デザイン

CSS3 の Media Queries を利用して画面サイズに応じて適用するスタイルを変更する方法です。スタイル自体を切り替えるので、レイアウトはもちろん要素の大きさや表示/非表示なども自由に指定することができます。ただし、表示を切り替える解像度(ブレークポイント) を明示的に指定する必要があるので、複数のデバイスに対応する場合は各々のデバイスの解像度を把握し、各解像度ごとのレイアウトを厳密にしておく必要になります。

image
(レスポンシブ Web デザインでは指定した解像度でCSSを切り替える)

 

■ リキッドレイアウト

HTML では要素のサイズを “width:80%; height:25%” のように % で記述することにより相対的なサイズ指定が可能です。これを利用して、ブラウザーのサイズに合わせて要素のサイズが画面に対する割合を保ったまま自動的に変更するように記述することができます。

ただし、サイズが変更されるだけなので、レスポンシブ Web デザインのように、エレメントを非表示にしたりといったことはできません。

image
(リキッドレイアウトではサイズを % で指定することにより相対的なサイズでのデザインができる)

 

■ フレキシブル (可変) グリッドレイアウト

リキッドレイアウトでは、要素のサイズが画面のサイズに合わせて自動的に可変していきますが、その大きさが必ずしもコンテンツの量にふさわしいとは限りません。たとえば、50px × 200px のサイズのカラムの大きさが、余白も含めちょうどいい量のコンテンツがあったとして、このカラムのサイズが大きい画面での表示により 200px × 800px となった場合は、フォントの大きさはそのままなので、余白が広すぎて読みずらい印象を与えてしまいます。

フレキシブルグリッド レイアウトは、コンテンツのグリッド単位に求め、かつグリッドの大きさに上限下限を設け、画面サイズに合わせグリッド単位でのレイアウトが行うことができます。ただし、サイズに上限を設けるので、想定外の大きさの画面で表示された際には、グリッドの外側に余白が生じます

image
(フレキシブルグリッドレイアウトは、)

ここまで紹介したデザイン方法は、名前が個別についているからといって、必ずしも 1 つの手法でのみ行う必要はありません。   それぞれの得手不得手を把握し、お互いの不得意部分を補うような使い方をお勧めします。

<参考>

 

 

高い解像度での余白の埋め方

サービスのターゲットを PC として考えた場合、高解像度の大画面で表示された際に、どのような表示になるのか考えておく必要があります。

ただし、想定より大きい解像度での表示では、UI が表示されずに隠れて操作できないという状況は発生しづらいので、見た目を気にしなければそのままでも機能的には構いません。

余白を埋めるデザインの考え方としては、以下の 2 つがあります。

 

■ 固定

ディスプレイの大きさに合わせてページ全体の画面を拡大してしまうか、コンテンツを中央部分に配置するなど、画面サイズが変更されても影響のないデザインを選択するなどです。

前者は、ゲームの画面を思い浮かべてみると良いでしょう。例えば、解像度 800 x 600 のディスプレイいっぱいのゲームの画面があったとして、ディスプレイの解像度が 1600×800 に上がったからといって、ゲームの画面を横に 2 つ並べて表示してもあまりうれしくはありません。こういった場合にはディスプレイのサイズに合わせてゲーム画面のサイズを適切に拡大縮小します。

image
(固定 : 画面サイズにあわせ拡大する)

 

また、拡大縮小は行わずサイズは固定のまま、コンテンツの位置を中央に配置し、余白を均一にすることで整理された印象を与え、高解像度の大きなディスプレイで表示された際もデザインが崩れないようにするという方法もあります。こういったデザインはブログやニュース記事によく見られます。

image
(固定 : 画面サイズに影響されないデザインを採用し、サイズ変更しない)

 

■ アダプティブ(※)

ディスプレイの大きさに合わせてレイアウトを変更し空白を埋める方法です。

画面サイズの拡大によって生じた領域を有効に使用すること

image
(固定 : 画面サイズにあわせ拡大する)

(※) ここで紹介している「アダプティブ」は、大画面で表示された際に発生する余白をどのように扱うかの考え方についてであり、「アダプティブ Web デザイン」には触れていません。

<参考>

 

モバイル向け画面の検証

レスポンシブ Web デザインに代表される、解像度の変更によるスタイルシートの動作検証程度であるからば、実機やエミュレーターなどを使用しなくても、Web ブラウザーの開発者ツールで確認することができます。

たとえば、Internet Explorer 11 であれば F12 開発者ツールの [エミュレーション] タブ内にあるディスプレイ の [解像度] ドロップダウンリストボックスで Web ブラウザーの表示サイズを変更することができます。また、[向き] では表示枠の方向を変更できます。

image
(Internet Explorer F12 開発者ツール[エミュレーション]タブにある解像度の指定箇所)

 

その他、Google Developers ではモバイル フレンドリーテストというサービスを公開しており、URL を指定することで、その Web ページがモバイルに最適化されているか検査してくれますので、こういったものを試してみるのも良いでしょう。

 

     

互換性の検証に使用できるリソース

旧バージョンの Internet Explorer については、マイクロソフトが提供する Web ページの検証サイト modern.IE にて、旧バージョンの Windows と Internet Explorer のセットが仮想マシンが無償で公開されているので、それを利用することができます。

ローカルに仮想環境が用意できない場合や、その他の OS と Web ブラウザーの組み合わせについては、modern.IE からリンクされている BrowserStack が便利です。BrowserStack は、リモート デスクトップ接続を使用して、クラウド環境で動作する OS と Web ブラウザーを使用することができます。

提供される OS は、Windows や Mac というデスクトップ OS だけでなく、iOS や Android といったモバイルデバイス用の OS の環境も提供されます。

image
(BrowserStack での OS の選択画面 )

なお、BrowserStack は、マイクロソフトではなく、パートナー企業が提供する有償サービスですが、3 か月間無償で試用することができます。

BrowserStack を含めた modern.IE の使い方については、以下の記事をご参照ください。

 

モバイルデバイスの検証

スマートフォン以前の携帯電話は、OS や Web ブラウザーの仕様が端末ごとにまちまちであり、シミュレーターの精度も高いとはいえませんでした。

スマートフォンにおいては、使用される OS は限られてきており、シミュレーターだけでなく、OS そのもののエミュレーターも提供されているので、実機を使わなくてもそれなりに高い精度の検証が行えるようになっています。

以下の主だったスマートフォン用のシミュレーター/エミュレーターを紹介します。

 

■ iOS  シミュレーター

Apple の開発者ツールである Xcode には iOS アプリの開発に使用するシミュレーターが付属しています。これを使用して iPhone、iPad 用アプリの検証はもちろんのこと、Web ブラウザーを使用した Web コンテンツの検証を行えます。

iOS シミュレーターの起動は基本的には Xcode を起動し、[Xcode] メニューから [Open Developer Tool] – [iOS Simulator] で行いますが、Xcode のパッケージの内にあるエイリアスから直接起動することもできます。

手順は以下のとおりです。

  1. Finderよりアプリケーション内の Xcode を右クリックし表示されたコンテキストメニューから [パッケージの内容を表示] を選択します。 
  2. Contents/Applications の中に [iOS Simulator] があるのでクリックして起動します。

よく使うようであれば、Dock に登録しておくと良いでしょう。

 

■  Android エミュレーター

iOS シミュレーターのように OS の開発元が提供しているものは無いようですが、サードパーティーの製品や、フリーソフトなど複数提供されているようなので、それらの中から評判の高いものを使うと良いでしょう。また、次期の Visual Studio である Visual Studio 2015 には、Hyper-V 上で動作する Android のエミュレーターが付属するので、Windows ユーザーであればそちらを使用することもできます。

ただし、Android OS は、メーカーによるカスタマイズが可能であるため、ハードを含めたスペックの「断片化」が激しいので、エミュレーターの精度は、iOS ほどではないと考えたほうが良いでしょう。

 

Windows Phone エミュレーター

Visual Studio 2013 には、Hyper-V で動作する高品質な Windows Phone 8.1 のエミュレーターが付属しています。

Visual Studio 2013 のツールバーのプロジェクトの実行ボタンの横にあるドロップダウンリストボックスで、[Windows Phone] を選択することで、サブメニューから具体的な機種を選んで起動することができます。Windows Phone のエミュレーターを直接起動する方法については、同僚の高橋忍のブログの記事に書いてありますので、そちらをご覧ください。以上です。

 

■  Firefox OS シミュレーター

Firefox OS 用のシミュレーターは、OS の提供元である Mozilla で提供されており、同社の Web ブラウザー Firefox のプラグインとして動作します。

シミュレータープラグインは Web ブラウザーには同梱されていませんので、MDN(MOZILLA DEVELOPER NETWORK) のサイトより入手する必要があります。

 

■ Windows タブレット シミュレーター

Visual Studio 2013 には Windows タブレット機のシミュレーターが同梱されており、Windows ストア アプリの検証用ではありますが、単体起動して他のアプリケーションの検証も行うことができます。詳細について以下の記事をご覧ください。

 

     

シミュレーター/エミュレーターでの検証の盲点

シミュレーターやエミュレーターを使用するうえで気をつけなければならないことがあります。それは、それらのエミュレーションの精度が高くても、実際のデバイスとはハードウェアのスペックが異なるためまったく同じ動作になるとは限らないということです。

例えば、CPU やグラフィックカードのスペックは PC のほうが高いため、高い FPS のアニメーションなどは、シミュレーター上できちんと動作したとしても、実機ではコマ落ちして使用に耐えないということも考えられます。またバッテリーの持続時間や、ネットワークの状態なども同じ理由でシミュレーターなどでは正確な検証が行えません。

また、通信環境を従量課金プランで使用するユーザーをターゲットとする場合は、ネットワークに流れるデータがそのまま金銭的なコストとなるので、通常利用でどれくらいの金額がかかるのか計測する必要があります。

サービスの対象となるデバイスに関しては、リリース前に最低限 1 度以上は実機での検証を行うことをお勧めします。

 

     

7.5.互換性確保の順番

互換性の確保は、互換をとるための工数が少ないほうから行っていきます。

具体的には、基準となるブラウザーで正常動作を確認した機能を、(1)モダンブラウザ同士 –>(2) レガシーブラウザ –>(3)モバイルブデバイス という順番で互換性を確保していきます。この順番は優先度、重要度にほかなりません。もし、レガシーブラウザよりも、モバイルデバイスのほうが重要であるならば、検証の順番を入れ替えてください。

image(互換性を確保する順番)

 

     

8. 開発工数の削減方法

Web サイトの構造とページ遷移、各ページのデザインが確定したら実際の製造作業に入ります。

(※) Web ページを制作するには、コーディング以外でも、画像や、場合によってはサウンドや動画といったマルチメディア ファイルが必要になりますが、ここではそれらに関する作成や入手については触れません。

HTML5 登場からみるフロントエンド開発技術の進歩』でも触れましたが、Web のフロントエンド技術を取り巻く環境の進歩に伴い、リッチ コンテンツのへ要求は高まり、それを実現するための開発の難易度や工数は増えていきます。こうした状況を解決するために、開発にかかる工数と難易度を下げるためのライブラリや、フレームワークといったさまざまな仕組みが続々と生み出されています。そうした仕組みをうまく利用することで、開発の工数を減らしリリースまでのスピードを上げることができます。

ここでは、Web のフロントエンド開発の工数を下げるためのライブラリやフレームワークといったものを紹介します。

 

ライブラリとフレームワーク、そしてテンプレートエンジン

JavaScript には、古くからさまざまな「ライブラリ」が提供されてきましたが、現在では、よりアプリケーション全体の機能を包括する「フレームワーク」というものが登場してきました。また、構造化されたデータを動的に描画出力できるテンプレートエンジンなども使用されるようになっています。

 

■ ライブラリとフレームワークの違い

ライブラリもフレームワークも、JavaScript で書かれたコードの集合ですが、その使われ方に違いがあります。ライブラリは複数の関数が集まった、文字通りライブラリであり、ユーザーは自分のコードからライブラリ内の任意の関数を呼び出して使用します。それに対し、フレームワークはプログラム全体の動作を管理しており、ユーザーはフレームワークから呼び出されるためのコードやエレメントのプロパティを記述して使用します。

たとえば、フレームワークである Angular.js では、以下のように記述するだけで、テキストボックスに入力された文字を下の段落に書かれた「入力された内容:」の後ろに続けて出力できるようになります。

<input type="text" ng-model="inputText"/>
< p>入力された内容:{{inputText}}</p>

この機能を実装するのに JavaScript コードを記述する必要はありません。これは Angular.js を参照しているコンテキスト全体を Angular.js が管理しているためです。開発者はフレームワークである 「Angular.js に処理される」上記のようなエレメントの属性設定と、おなじく、「Angular.js に処理される」 JavaScript コードを記述することで開発を行っていきます。

つまり、ライブラリとフレームワークの違いは、ライブラリはユーザーのコードから「呼びだす」ものであり、フレームワークの場合は、ユーザーのコードは逆に「呼ばれる」ものであると言えるでしょう。

 

■ JavaScript テンプレートエンジン

「テンプレートエンジン」というと、PHP や Node.js などのサーバーサイドの仕組みのことを思い浮かべる人も多いかもしれませんが、ここでの「テンプレートエンジン」はクライアントサイドで動作するものです。

クライアントサイドにおけるテンプレートとは、HTML 内に非表示属性で記述した DOM エレメントをデータのひな形として使用し、同エレメントのインスタンスをデータの数だけ生成して値を設定し、親エレメントに追加する手法です。テンプレートエンジンとは、この処理をライブラリ化して簡単に記述できるようにしたものです。

以下は handlebars.js を使用した記述例です。実行すると変数 valus の内容が、新しくインスタンスが立った<script id=”input”> の各エレメントのプロパティに設定され、<div id=”output”> 内に挿入されます。なお、以下のコードを実際に動作させるには script タグを追加して jQuery と handlebars.js の js ファイルを参照させ、画像の URL を有効なものに差し替える必要があります。

<script>
//データの定義
var values = {
    title: ‘Hello Internet Explorer’,
    img: {
        url: ‘https://contoso.com/images/IE_logo.png’,
         alt: ‘InternetExplrer logo’
    },
    text: ‘My first Handlebars!’
};

//DOM 準備完了のイベントハンドラ
document.addEventListener("DOMContentLoaded", function () {
    var template = Handlebars.compile($(‘#input’).html());
    $(‘#output’).html(template(values));
});
< /script>

<!– テンプレート部分 (非表示)–>
< script id="input" type="text/x-handlebars-template">
    <section class="inner">
        < h1 class="header">{{title}}</h1>
        <div class="box">
             <img src="{{img.url}}" alt="{{img.alt}}" />
            < p class="flex">{{text}}</p>
        </div>
    </section>
< /script>
//実際のエレメントが挿入される場所
< div id="output"></div>

これら JavaScript のライブラリやフレームワークは、組み合わせによっては複数のものを組み合わせて使用することも可能ですので(※だめなものももちろんあります)、各々の特性を調べて適宜組み合わせることでより効率の良い開発を行うことができるようになります。

 

■ CSS フレームワーク

CSS にもフレームワークが用意されています。CSS フレームワークは Web ページに対し、デザイン性の高い一貫したテーマを提供します。統一性のある全体のカラーやコンテンツのレイアウト、よく使用されるボタンやタブなどのインターフェース部品など、それらは Web ブラウザー間の表示の違いなども考慮されているため表示くずれなども起きにくくなっており、またレスポンシブ Web デザインで作られているためスマートフォンのようなモバイルデバイスにも対応します。ただし、CSS のフレームワークのルールに合わせたマークアップをしなければならないケースも多々あるので、ドキュメント構造に書式の影響を及ぼしたくないのであれば、採用を充分に検討してください。

以下は知名度のある JavaScript のライブラリとフレームワーク、テンプレートエンジンと、同じく知名度のある CSS のリストです。各々公式 Web サイトへのリンクが設定されているので、どのようなものがあるか参照してみてください。

JavaScript
ライブラリ フレームワーク テンプレート
エンジン
jQuery,
Prototype.js,
Dojo,
KendoUI,
YUI※開発終了
Backbone.js,
Knockout.js,
Angular.js,
WinJS,
Sencha,
React.js,
Ember.js,
Polymer.js
Handlebars,
EJS,
Mustache,
Hogan,
Underscore,
jQuery.EJS,
PURE
CSS
フレームワーク

Bootstrap,
Foundation,
Pure,
Gumby,
INK,
Cardinal, 
Skeleton

 

フレームワークのオーバーヘッド

フレームワークの使用は、便利な反面、処理にオーバーヘッドが生じます。使い方によっては、非力なスマートフォンの CPU では十分なパフォーマンスが得られない場合もあるので、スマートフォンをターゲットとする際は、必ず実機による検証を実施することをお勧めします。

また、JavaScript のフレームワークやテンプレートエンジンは JavaScript が動作することが大前提となっているので、JavaScript が動作しない Web ブラウザーのサポートをどうするのか、また、サポートしている JavaScript  や Web ブラウザーのバージョンが古い場合はどうするのか、を方針だてておきましょう。

 

ライブラリ/フレームワークの選定について

JavaScript も CSS も現在、非常にたくさんのライブラリやフレームワークが公開されており、評価もさまざまで、どれを選んだら良いのか分からないといった状況もあるかと思います。

ライブラリ/フレームワークの選定について、検討すべき点を最大公約数的なものではありますが、以下参考となるものを示します。

ここでは 2 段階にわけて判断しています。

 

【第 1 段階の判断】

  1. ターゲットとなる Web ブラウザーで動作すること

    サービスがサポートしている Web ブラウザーで動作する必要があります。旧バージョンの Web ブラウザーをサポートしている場合、あまり先進的な機能を持ったライブラリは動作しない可能性があります。ライブラリのサポートしている Web ブラウザーのバージョンを確認するとともに、実際に支障なく動作するのか、使用予定の機能を前もって検証することをお勧めします。

  2. 技術サポートが受けられるか否か

    製造元、もしくはサードベンダーで技術サポートが受けられるか確認しましょう。不具合の修正はもちろん、セキュリティ問題のような重大な問題が見つかった際の対応、連絡はどのように行われるのか確認しましょう。

  3. 充分な情報があるか    
    ライブラリを使用するにあたって、使い方をはじめ充分に情報があるかを確認しましょう。インターネット上はもちろんですが、いくつか書籍が出ていたほうが安心です。

第 1 段階の判断で対象を絞ったら、第 2 段階の判断さらに絞り込んでいきます。

【第 2 段階の判断】

  1. 使用するまでの学習コスト    
    使用を開始するまでの学習コストが高すぎると、開発メンバーの追加や交代の際のスキルトランスファーや引き継ぎに時間がかかります。

  2. 開発生産性

    そのライブラリを使用して、どれくらいの範囲の作業が賄えるのか?、また、そのライブラリを使用してスムーズに開発が行える環境用意されているのか確認しましょう。メンバーに精通して人間がいる、開発ツールがそのライブラリの入力支援機能をサポートしている等です。

  3. ロックイン度合い

    広い範囲をライブラリで賄ってしまうと、ロックイン度合いも広くなります。どれくらいそのライブラリにロックインして構わないのか検討しましょう。ライブラリの開発が終了してしまった場合にロックインされた部分をどうするか、少なくとも、プログラムのどの部分を依存させるかを明確にしましょう。

  4. 運用コスト

    運用コストを測りましょう。必要なアップデートが頻繁に行われたりすると、検証の回数が増えコストがかさみます。

 

image
(ライブラリ/フレームワーク選定の際に返検討すべき点)

(※)この選定方法については、HTML5Experts.JP の酒巻瑞穂氏の記事の一部を、ご本人の了承を得て参考とさせていただきました。

 

ライブラリやフレームワークの比較については、インターネット上にさまざまな記事が出ていますので、これらを参考に、どのライブラリが合っているのか、大まかなあたりをつけるに参考にすると良いでしょう。

また、さまざまな JavaScript MVC フレームワークを用いて作られた同一の ToDo アプリが公開されており、コードを確認することで、これら JavaScript MVC フレームワークを使用するさいのコードを比較することができますので、こちらもご活用ください。

 

OSS ライブラリを使用する際の注意点

CMS のところにも書きましたが、こうした OSS の製品を使用する場合は、製品のサポート状況や、サポート体制について充分に確認しておくことをお勧めします。製品の不具合によるトラブルや、セキュリティホールが見つかった場合のアップデートの提供などがどのような行われるかを把握しておくことはとても重要です。なお、OSS のライブラリであっても  jQuery、Knockout.js、WinJS、Bootstrap については、Visual Studio 2013 に含まれているため、マイクロソフトのサポート(有償)に問い合わせることができます。

また、技術サポートのついた商用のフレームワーク販売されていますので、きちんとした品質と技術サポートが必要な場合はこういったものを使用することをお勧めします。

 

     

軽量マークアップ、altJS と CSS プリプロセッサ

HTML や JavaScript、 CSS のコーディング作業の生産性を上げるため、ライブラリやフレームとは違ったアプローチの方法として 軽量マークアップ言語 や altJS、CSS プリプロセッサといったものがあります。どちらも実際に実行される HTML や JavaScript、CSS を記述するのではなく、記述が簡単、あるいは記述量が少なくて済む他の言語で記述を行い、コンパイルによりそれらを生成します。

 

■ 軽量マークアップ言語 (lightweight markup language)

軽量マークアップは、HTML/XHTML の記述量が少なく容易になるように設計された簡潔な構造をもつマークアップ言語です。それぞれ専用のコンパイラを使用して HTML や XHTML を生成します。

軽量マークアップ言語は、おもにテキストエディタを使用したマークアップ記述作業を軽減する目的で作られました。そのため Visual Studio のように強力な入力補完機能を持ったエディタを使用する際にはあまり必要ではありません。

Visual Studio のような入力補完機能をもったエディタでは、少ない入力で意図した HTML を直接記述できますが、軽量マークアップ言語では、出力される HTML が意図したものであるかどうかは生成された HTML ファイルを見るまでは分かりません。また HTML を確認するためだけであってもコンパイルが必要になります。

 

■ altJS

altJS は JavaScript とは異なるメタ言語でソースコードを記述し、コンパイルして実行のための JavaScript を出力します。これらは「Alternative JavaScript」=「altJS」と呼ばれ、使用されるメタ言語には、LL(Lightweight Language)を意識してコードを簡易に記述できるようにした CoffeeScript や、JavaScript にはない変数の型やクラスを持ち、複雑なコードを安全かつ効率よく記述することができるようにした TypeScript や、JavaScript 以外の他の言語も出力できる Haxe といった、さまざまな特性をもった言語があります。

altJS は出力される JavaScript コードに一貫したスタイルと読みやすさもあるため、JavaScript のコーディングルールを統一させる目的として利用することもできます。

 

■ CSS プリプロセッサ

CSSにも、HTML や JavaScriptと同様に、スタイルシート設定を効率よく記述するための CSSプリプロセッサ と呼ばれるものがあります。これらも軽量マークアップ言語や  altJSと同じく、異なる記法で記述したスタイル設定をコンパイルして実際の CSSファイルを出力するものです。

CSS はとくに、プログラミング言語とは異なり、変数や関数といった概念がありません。セレクターと、それについてのプロパティと値のセットをひたすら列挙して記述していくことになるため、大規模複雑になりがちです。CSS プリプロセッサを使用することにより、ループや条件分岐を使用してプログラムチックにCSS を記述することができるため作業を効率化できます。

以下は知名度のある軽量マークアップと altJS および CSS プリプロセッサのリストです。各々公式 Web サイトへのリンクが設定されているので、どのようなものがあるか参照してみてください。

                 

HTML
軽量マークアップ
簡易的な記述から HTML
にコンパイル
JavaScript
altJS
他言語から JavaScript に
にコンパイル
CSS
プリプロセッサ
異なる記法から CSS に
にコンパイル
 

レビューと CSS ポストプロセッサ

CSS の記述を効率よく助けしてくれる CSS プリプロセッサですが、 CSS ブリプロセッサの構文を駆使して記述したコードは、一般的な CSS の知識だけでは理解することができません。よって、CSS プリプロセッサのソースをレビューで使用することはできません。

必然的に CSS プリプロセッサが生成した CSS をレビューすることになりますが、人間がレビューできる状態の CSS は余分な情報を含んでいるため、配信用に最適化されているとは言えません。

そういった際に、レビューの済んだ CSS を圧縮/最適化してくれるものを CSS ポストプロセッサと呼びます。CSS ポストプロセッサは、単一の決まった機能を提供するものではなく、書式にベンダープレフィックスを追加してくれる Autoprefixer や、重複した media-queries の設定をまとめてくれる group-css-media-queries、コメントや空白を削除してくれる clean-css といったものなど、さまざまな機能を持ったものがありますので、用途に合わせ取捨選択するか組み合わせて使うと良いでしょう。

 

ボイラープレート

HTML5 でサイトを構築するための HTML のテンプレート、さらにはフレームワークやツール、ベストプラクティスとなる設定を詰め込んだボイラープレートというものも提供されています。これらは HTML5 を使用した Web サイトを作成するさいに定型的に使用されるさまざまなものをあらかじめ含んでいるため、テンプレートやライブラリといったものを個別に集めてくる必要はなく、すぐにある程度の開発をスタートさせることができます。

人気のあるボイラープレートとしては、以下のものがあります。

 

     

Web 標準に準拠したマークアップとクロスブラウザー

モダンブラウザ間での表示の互換性を実現するうえで大前提となるのは、記述した HTML や CSS がきちんと Web 標準に準拠していることです。

W3C では、ページが Web 標準に準拠しているかどうかを確認するための以下のバリデーションツールが公開されています。

また、modern.IE でも同様のバリデーションサービスを提供してしいます。

modern.IE のバリデーションサービスは、オープンソースとして、ソースが GitHub で公開されており、これを利用してローカル環境に modern.IE のバリデーションサイトを配置することができます。これは、インターネットに公開できない、イントラネット環境や、開発中のページを調べるのに便利です。

実際に modern.IE のバリデーションサイトをローカル環境に配置する方法については、以下の記事をご覧ください。Node.js を使用してホストする方法なので、Mac OS 上にも配置することができます。

さらに modern.IE では、古いバージョンの Internet Explorer をサポートしながら、モダンなサイトを構築する 20 のヒントを以下の URL で公開していますのでぜひご覧ください。

 

クロスブラウザとエレメントの初期値

Web ブラウザー間で、表示が異なる原因の一つとしてエレメントの書式の初期値 (デフォルトスタイルシート) の違いがあります。

例えば、HTML でエレメントをマークアップする際、明示的にサイズやフォントを指定しないと、Web ブラウザー毎に初期値が異なるために表示は微妙に異なってきます。

image
(左から IE、Chrome、Firefox とならべて、書式の設定していない文字列と
テキストボックスを表示したところ。表示に微妙な違いがある)

 

この問題に対処するために「リセット CSS」というアイディアが生まれました。これは要素セレクターそれぞれに対して CSS をゼロにするという思い切った手法です。このきわめて大胆かつドラスティックな方法は、Web ブラウザーのエレメントの書式をゼロで統一するという、かつてない偉業を達した反面、サイズや枠線についてのプロパティをすべて設定しなければならないという多大な手間も生み出しました。

そういった弊害を避けるべく生み出され、現在も使用されているのが「Normalize.css」です。

Normalize.css ブラウザのスタイルを消去するよりむしろ有用なデフォルトのスタイルを保存し、不具合とブラウザーごとのスタイルの違いを修正します。

解かりやすくいうと、Normalize.css は、Web ブラウザーのデフォルト CSS の表示の違いを CSS によって補正 (ノーマライズ) してくれるものです 。

Normalize.css は、さまざまな CDN で配信されていたり、GitHub でフォークされてたりしますが、以下から正式版を入手して使用することをお勧めします。

 

     

9 . 開発ツールについて

Web 開発のためのツールとしては非常にたくさんのツールがありますが、ここでは Visual Studio を紹介します。

Visual Studio は開発製品スイートとして長い歴史とたくさん実績を持ち、ホビーユースから大規模開発までカバーできる機能と仕組みが揃っています。

Visual Studio に含まれる開発ツールの機能は、サービスパックによりアップデートされ、その分野での最新のトレンドが反映されます。

たとえば、このブログの記事「HTML5 登場からみるフロントエンド開発技術の進歩」では 、Web の進化とともに複雑化したフロントエンドの開発のニーズを満たす人気のツールとして、Yeoman を紹介しましたが、Yeoman でできることは全て、既に数世代前の Visual Studio でもできるものばかりです。

また、Visual Studio は、HTML や JavaScript だけでなく、さまざまな分野で使用される言語やマークアップについて、強力な入力補完機能を提供するエディタや、サーバーサイド、クライアントサイド問わずシームレスに調査することができるデバッガ、開発用の Web サーバー、デバイスエミュレーター等を備えた統合開発環境 (IDE) を提供します。

Visual Studio を使用すると、Web のフロントエンドで使用されている最新の技術を使用した開発を行うことができ、開発環境の準備も迅速に行えます。

Visual Studio 2013 を使用したフロントエンド Web の開発についてのチュートリアルを以下の記事にまとめましたのでご覧ください。

開発環境の準備、開発生産性をぜひ、他のフロントエンドの開発環境と比較してください。

 

10 . テストとテストの管理

コードであれページであれ、実際に機能の実装が済んだらテストを行い、テストケースあるいは、テスト用コードを作成しましょう。

テストは、プログラムが仕様どおり動作していることを証明するものであり、テストケースやテストコードは、それを判断するための装置にほかなりません。

ページやコード、あるいは ターゲットとなる Web ブラウザーがバージョンアップアップなどで変更された場合は、以前の状態での正常動作を保証していたテストを使用して、変更後の状態のものが以前とかわらず正常に動作するかを確認する必要があります。そのため、テストケースやテストコードは、検証/実行可能な状態で管理しておく必要があり、仕様そのものが変更された場合には、テストケース/テストコードにその変更を反映する必要があります。

プログラムの開発で行われる一般的なテストとしては、以下のものがあります。

 

単体 (ユニット) テスト

単体テストは、テスト対象となるクラスのメソッドや関数にテスト用の引数を渡し、実際に返された「結果」と仕様から想定される「期待値」の2つの値を比較しテストの合否を判断する方法です。このテストは、テストの対象となっているコードを実際に呼び出す必要があるため、テスト対象と同じプログラミング言語で記述する必要があります。「単体テスト ツール」と呼ばれるものは、この記述したテスト用コードを自動で呼び出すだけのもので、テスト用のコード自体はは開発者が手動で記述する必要があります。

 

コード カバレッジ

単体テストでは、どれだけのコードが調べられるかを把握することが重要です。

関数は呼び出された際、内部の全てのコードが使用されるとは限りません。内部に条件分岐がある場合などは、引数によっては、内部のコードをほとんど使用しないまま値を返す可能性もあります。そういった値を使用したテストは有効ではありません。関数の内のコードが充分に使用されるよう、きちんとシナリオを考える必要があります。

この、テストによって関数内部のコードが使用される割合をコードカバレッジといいます。コード カバレッジは必ずしも 100 % である必要はありませんが、80% 前後を目安とすることが多いようです。

 

単体テストを行うタイミング

テスト対象となるコードは開発は、すべての単体テストの成功によって完了となります。よって、開発のどのタイミングからはじめても構いませんが、なるべく早いタイミングでテストを開始することをお勧めします。早い段階から検証と修正を繰り返すことで不具合の早期発見を促し、作業の手戻りを防ぐとともに不具合の影響を小さく抑えることができます。

テスト対象となるコードよりも先に、単体テストを作成してもかまいません。単体テスト用のコードは、テスト対象となるコードの使用方法を示すサンプルであるともいえます。この単体テストを先に作成してからテスト対象となるコードを開発する方法は「テストファースト(駆動)開発」と呼ばれています。

 

Visual Studio の JavaScript 単体テスト用エクステンション

Visual Studio 2013 で JavaScript の単体テストを行う機能として Chutzpah Test Adapter for the Test Explorer (Chutzpah : 読み フツパ) というアドインが用意されています。これを使用すると JavaScript のテストフレームワークである JasmineQUnit を使用したテストを、Visual Studio の単体テスト実行環境に統合し、管理できるようになります。

Chutzpah Test Adapter for the Test Explorer が提供する Jasmin と QUnit を使用した Visual Studio における単体テストの方法については以下のページをご覧ください。

なお、単体 (ユニット) テストは開発者が行う、クラスやメソッドというプログラムの最小単位を対象としたテストであり、システム全体が仕様を満たしているかを検証するためのテストではありません。単体テストの結果が正常でも、クラスやメソッドの組み合わせによってはシステムが仕様どうりに動作しないということもあるのでより上位のテストが必要となります。

 

     

結合テスト

「結合テスト」とは、外部モジュールとインターフェース、サーバーとクライアント、など、なにを結合するか、どこに焦点を当てるかによって、内容はさまざまですが、Web のフロント エンド開発における結合テストとは、一般的に HTML や CSS も含めた一連の処理の流れを言います。

たとえば、ユーザーが Web コンテンツ上の UI でなにがしかの操作を行った際に、DOM、フロントエンドの JavaScript から Web サーバー上で動作するロジック、そこから呼び出させるバックエンドのデータベースなどの動作をふくめ、期待どおりの動作になるかどうか、です。

テストは、要件ごとに正常系、異常系もふくめ綿密なテストシナリオを作成し、決められた手順に従い、ユーザーの操作を実際に行う必要があります。

このテストのための手順とシナリオを「テストケース」といいます。テストケースを実行して発生した予期しない動作は、バグとしてテストケースに紐づけて管理します。

 

手動テストと自動テスト

UI 操作が伴うテストは、ユーザーの操作を実際に行う必要があります。

単純な手順で検証が可能な ページや、UI の変更が頻繁なもの、制作期間が短いものについては、コストや工数の面から手動でのテストが向いています。逆に、頻繁な回帰テストや、テストケースの反復、大規模システムのテストにはソフトウェアによる自動テストが向いています。また、テストケースが複雑なものも、作業者のミスを避けるという意味で、手順の記録にかかるコストの折り合いがつくのであれば自動テストを使用したいところです。

 

Visual Studio 2013 の Premium 以上のエディションであれば、「コード化された UI テスト」と呼ばれる自動 UI 機能が搭載されており、これを使用して Web ページの自動テストを行うことができます。コード化された UI テストについては以下のページをご覧ください。

 

複数の異なる環境でのテスト

Web コンテンツやアプリは異なる複数の OS と Web ブラウザーで使用されるので、環境によっては表示や挙動が異なる場合があります。

そのためリリース前には、サービスのターゲットとなっている OS と Web ブラウザーの組み合わせを使用してテストを行っておく必要があります。使用するテストケースは、PC とスマートフォンのように、UI が異ならない限りは必ず同じものを使用します。

異なるプラットフォームをテストする際に使用できるリソースについては、この記事の 互換性の検証に使用できるリソース で紹介しているので参考にしてください。ハードウェアのスペックに結果が左右されない、パフォーマンス関連のテスト以外は、多くの場合、仮想マシンでのテストで問題ありません。

Visual Studio 2013 の Premium 以上のエディション に付属する Lab Management を使用すると、複数の物理マシン、仮想マシンを含めた開発検証用のラボ環境を作成管理することができます。

Visual Studio Lab Management については以下のページをご覧ください。

 

バグの再現と管理

バグが発見された際には、バグの再現手順を明確にしておくことが重要です。開発者がバグを再現できないと原因を究明することができず、修正も行えません。

パグのレポートには、手順のほかにテストに使用した環境の情報も添付します。Web コンテンツ/ページについてのテストであれば、最低限以下の情報は添付したいところです

  • OS の種類とバージョン
  • サービスパック
  • Web ブラウザーの種類とバージョン

 

テストの管理について

この項の最初に記述したように、テストはプログラムが仕様どおり動作することを証明するものです。テストをきちんと管理運用することがプログラムの品質保持に繋がります。

そのためには、テスト自体の品質もきちんと管理されている必要があります。例えば、テスト対象や検証環境の構築手順、検証手順、バグが発生した際の再現手順など、誰でも作業ができるように明確にしてチーム内で共有したり、実施した作業については、いつ、誰が、どのような作業を行ったか、そしてそれが今どんな状態であるかを明確に、すぐに確認できるようにしておきます。

image

こうすることによって、過去に作成したテストの用リソースを効率よく再利用して、テストのかかる工数を下げつつ、プログラムの品質を保持することが可能になります。

Visual Studio 2013 Premium 以上のエディションには、こうしたテスト管理を行うための テストマネージャーが付属しています。

  テストマネージャーの詳細については以下をご覧ください。

 

まとめ

今回は、企業の Web に関わる方々むけに、Web 標準に準拠し、メジャーなモダン ブラウザとの互換もとれ、スマートフォンなどのデバイスにも対応した Web ページをイチから作成する際、初歩的な部分も含め、おさえておきたい 10 のポイントにしぼって紹介しました。

おもに Web のフロントエンド技術についての内容でしたが、Web のフロントエンドはインターネットのフロントエンドでもあり、それは変化していきます。

たとえば、Web 以外のインターネットのフロントエンドとして Flash に代表される RIA (Rich Internet Application) がありました(まだあるけど)。そして、現在は、スマートフォンなどのアプリがあります。

これから IOT が普及してくると、いままでにないほどのクライアントの多様化がおこり、インターネットのフロントエンド技術も多岐にわたっていくことでしょう。そうなったときに、インターネットのサービスはどうなっていくのか、考えなければなりません。

新しい時代のデジタルサービスは液体のように姿を変え、さまざまな機器に流れ込んでいきます。

そういった時代の要求に応えられるように、サーバーサイドの仕組みは、Web 以外のフロントエンド技術とも相互運用可能な形態にしておくことをお勧めします。

そのへんのお話についてはまだ後日。

 

おしらせ : de:code 今年もやりマス!

日本マイクロソフトが送る開発者の祭典『de:code』、今年もやります。

日 時:

5 月 26 日 (火) 10:00 – 20:30
(受付開始 9:00 予定)
5 月 27 日 (水) 10:00 – 18:30
(受付開始 9:00 予定)
* 初日は参加者パーティを開催するため、
20:30 終了予定となります。

会 場:

ザ・プリンス パークタワー東京
東京都港区芝公園 4-8-1

今なら早期割引やってますよ。

お申し込みはいますぐ以下へ。

de:code

 

Real Time Analytics

Clicky

Comments (1)

  1. この記事の内容ももうぼちぼち古いので、以下もお読みになることをおすすめします。

    de:code2016セッション「モダン Web: たった今と、ほんの少し未来の話」フォローアップ
    https://blogs.msdn.microsoft.com/osamum/2016/06/06/the-modern-web-now-and-little-future-story/

    どう作る? Microsoft Edge に対応した相互運用性の高い Web コンテンツとは
    https://blogs.msdn.microsoft.com/osamum/2015/09/08/microsoft-edge-web/

Skip to main content