第9回 ASP.NETなWeb開発者のためのHTML5活用ポイント：連載：.NET中心会議議事録

会場の様子

　今回のテーマは、これから本格化するマルチデバイス時代に向けての「HTML5の活用」について。

　スマートフォンやタブレットが一般ユーザーに急速に普及し、ユーザーが利用するデバイスの種類が多様化してきている。その多様性に対する1つの対処方法として、HTML5やレスポンシブWebデザインなどの、1ソースでマルチデバイスに対応できるWebアプリ開発技術に注目と期待が寄せられている。HTML5に詳しい／経験のある開発者は、HTML5の活用について、どう考え、どう実践しているのか。基調講演やセッションで基本知識を説明し、パネル・ディスカッションと交流会でその内容を深く掘り下げた。

　セミナーの構成は、下記のとおり。

1. 基調講演『HTML5、どう使う？』
2. IEセッション1『IE10正式リリース版のHTML5／CSS3新機能』
3. パネル・ディスカッション『マルチデバイス時代のWebアプリ開発』
4. 交流会

　本稿ではこのうち、パネル・ディスカッションで交わされた主要な発言をまとめたものである。

パネル・ディスカッション『マルチデバイス時代のWebアプリ開発』

　パネル・ディスカッションにご登壇いただいたのは、下記の方々である。

　以下は、パネル・ディスカッションで筆者が重要だと思った主要なポイントである（以下、敬称略）。

●業務アプリ開発における「HTML5」と「レスポンシブWebデザイン」

―― HTML5と言えば、マルチデバイス、特にスマートフォン向けに活用するという話が多いですね。逆に言えば、PC向けではHTML5が役立つ場面は少ないのでしょうか？

ひらい　もちろんPC向けのサイトで業務アプリを新規に提供する場面でも、ブラウザ環境がIE9以上に統一されるなどの条件が整っているのであれば、HTML5は役立ちます。特に、HTML5のセマンティックな要素（＝ページ構成上の意味を持たせた要素）やCSS3のレイアウト機能などは有用だと思います。HTML4→5で使ってはいけなくなったタグ（例えば<font>タグなど）がありますので、まずはそこから注意してHTML5のWebサイトを構築してみてはどうでしょうか？ これなら、少しの労力でHTML5対応を始められます。

井上　HTML5／CSS3のデモではインタラクティブなデザイン部分が注目されがちです。しかし、業務アプリとしてはデザイン性よりも、機能性やマルチデバイス対応、セマンティックな部分が重視される場合が多いのではないでしょうか。業務アプリを作るための要求仕様の中でHTML5のどの部分が一番大切なのか、実装にどれぐらい工数や期間をかけられるのかを、まずは考える必要があります。それぞれのバランスを取って、その業務アプリにやはりHTML5が必要であると判断できたならば、できる部分から少しずつHTML5を取り込んでいくのがベストだと思います。

―― 確かにHTML5を使う目的を明確にする必要がありますね。それではマルチデバイス対応に絞って話を聞いてみたいと思います。1つのHTMLコードで画面サイズに応じてレイアウトを調整する「レスポンシブWebデザイン」が最近話題になっています。これは、デバイスごとにHTMLコードを切り替える場合と、どういう違いがありますか？ 両者の使い分けの指針を教えてください。

ひらい　レスポンシブWebデザインで作れば、マルチデバイス対応が完ぺきになるわけではありません。例えばフィーチャーフォン（＝従来の携帯電話）向けとPC向けのマルチデバイス対応をする場合、この両者でHTMLコードの文字コード（例えばShift-JISとUTF-8など）を切り替える必要なケースが多いです。このような場合、1つのHTMLソースだけでは対応できません。

　ほかにも、Webアプリでは、レスポンシブWebデザインの採用が難しい場合があります。例えば、PCとスマートフォンでユーザーが使いたい機能自体が大きく変わる場合です。このような場合、PC向けとスマートフォン向けで、「画面のレイアウトやコンテンツ」という見た目の部分だけではなく、「PCとスマートフォンで提供すべき機能」という根本的な部分から異なることになるからです。

　逆に、レスポンシブWebデザインが向いているサイトというのは、PC向けとスマートフォン向けで同じような情報を表示したいケースです。例えば米国の新聞サイト「The Boston Globe」は、画面の横幅に応じて、レイアウトやフォントを変更するレスポンシブWebデザインを採用しています。このように、「表示される情報や使える機能はほぼ同じにしたいが、レイアウト・デザインやUIなどの外観をデバイスごとに最適化したい」という場合は、レスポンシブWebデザインは最適です。

井上　業務アプリの場合は、レスポンシブWebデザインはやはり難しいと思います。例えばPC向けの画面サイズでは3カラムのレイアウトにしておき、スマートフォン向けでは1カラムのレイアウトで表示するように実装した場合、「画面幅によってボタンの位置が変わってしまい、マニュアルの表現やスクリーン・ショットが正しくなくなる」などの問題が想像されます。

ひらい　そういう場合は、カラムの数を変更するのではなく、カラムの幅を「％指定」にすることで、画面幅に応じて横幅が調整されるようにする方が取り組みやすいかもしれません。

―― ところで、実際の顧客から「業務アプリをマルチデバイス対応させたい」という要望が挙がることはあるのでしょうか？

尾崎　最近はよくありますね。その対応デバイスは、AndroidからiPad／iPhoneまでと多種多様です。確かにマルチデバイス対応のためにHTML5で作っている場合は、いずれのデバイスでも「表示」はできます。しかし業務アプリの場合、「これこれの環境では正常に動くことを検証済みです」という形で、対応済みのマルチデバイス環境を明確にして動作保証を行う必要があると思います。

―― その場合もレスポンシブWebデザインは有用でしょうか？

ひらい　既存の業務アプリをマルチデバイス対応する場合で、レスポンシブWebデザインを採用するのは（全面作り直しになってしまうので）難しいと思います。そうではなく、新規開発でマルチデバイス対応を目指すのであれば、スマートフォンなどのモバイル端末向けから作り込んでレスポンシブWebデザインを徐々に実現していく「モバイル・ファースト」という手法がお勧めです。小さい画面幅から徐々に大きいものへと、対応デバイスを増やしていけば、効率的にレスポンシブWebデザインを実装できます。大きいものを小さくするよりも、小さいものを大きくする方がはるかに楽です。

　デバイスは次々と増えています。将来的に、現在は想定していないサイズのデバイスが登場することはよくあります。例えばアップルは中身は2倍だけど見た目のサイズは従来と変わらない「Retinaディスプレイ」を出しましたが、これと同じように、想定外のデバイスが将来、登場することはあり得るでしょう。「そうなった場合にも対応したい」ということであれば、最初からレスポンシブWebデザインを採用し、CSSなども標準に従ったマークアップをしておくのがお勧めです。

　あと、マルチデバイス対応でよくある失敗パターンがあるので、それに対する注意点を1点だけ挙げておきます。PC向けの常時接続のインターネットと異なり、スマートフォン向けの3G回線では、回線が不安定だったり、速度が遅かったり、圏外になったりすることが多々あります。そういった場合に備えて、「地下鉄などで接続が切れても表示だけは行う」などの「回線を意識したオフライン対応」が必要になります。最悪なのは、そういう状況で「つながりません」というダイアログがたくさん出てきてしまうようなケースです。そうならないよう、「1回失敗したら、以後の失敗は当分告知しない」などの工夫が必要です。

●ASP.NETでのマルチデバイス対応

―― まずは最新のVisual Studio 2012でのマルチデバイス対応について教えてください。

井上　ASP.NET開発に取り込まれる皆さんに最初にお伝えしたいのが、「例えばVB6（Visual Basic 6）の開発に慣れているのならば、VB.NETに移行するのがチーム・メンバーの開発スキルを生かせるベストの選択になる」ということです。そして、Windowsフォームのようなコントロールをドラッグ＆ドロップして、そのコントロールをダブルクリックすると自動作成されるイベント・ハンドラに実装を書いていく「イベント駆動開発」の手法に慣れているのであれば、やはりASP.NET Webフォームがお勧めです。これらはマルチデバイス対応を進める場合においても同じことが言えます。

　Visual Studio 2012では、ASP.NET MVCだけでなくASP.NET Webフォームも、HTML5関連も含めてさまざまな機能強化がなされています。具体的には例えば、HTML5のドキュメント・タイプがHTMLコードとして出力されたり、セマンティックなタグを用いてHTML文書を作成したりできます。このように従来のWebフォームでもHTML5対応が進んでいますので安心して今後もお使いください。

　またVisual Studio 2012＆.NET Framework 4.5では、ASP.NET WebフォームとASP MVCで使える機能はあまり変わらなくなっています。例えばWebフォームは、ルーティングやモデル・バインディング、jQueryにも対応しています。

―― ASP.NET WebフォームとASP.NET MVCの使い分け指針を教えてください。

竹原　Webフォームを使ったときのメリットは開発生産性です。サーバ・コントロール・ベースでコードをあまり書かずに開発できることに特化してきた技術なので、ほかの技術に比べて圧倒的に速く目的どおりのWebアプリを開発できます。わたしの自己紹介でも述べたことですが、わたしの所属する会社がECサイトのバックエンドをASP.NET Webフォームで作っているのは、その開発生産性を生かすためです。特にGridViewコントロールでデータから表を手軽に作成できるのは本当に便利です。

　一方、ECサイトのフロントエンドは、お店が見た目を主体的にデザインできるようにする必要があります。ASP.NET MVCはそういった柔軟なデザインや機能を実装したい場合に向いています。

井上　最近はjQueryを使うことが増えてきています。WebフォームでもjQueryを組み合わせて使えますが、「サーバ・コントロール・ベースなのでHTMLコードは基本的に記述しない」という仕組みの中で、「クライアント側のJavaScriptフレームワークであるjQueryを使ってJavaScriptコードを書いていく」ということになります。この両者の組み合わせは、設計仕様のハイブリッドのような形になってしまうので、あまりシンプルではなくなります。jQueryやjQuery Mobileを多用するのであれば、ASP.NET MVCの方が、開発生産性がより高まる可能性があります。

―― ASP.NETでは、マルチデバイス対応するための機能も提供されているのでしょうか？

竹原　以前から、デバイスごとにHTMLコードのレンダリングを切り替えられる「ブラウザ定義ファイル」によるデバイス・アダプタ機能がありました。しかしブラウザ定義ファイルをメンテナンスし続ける必要があり、日本向けのデバイス情報は更新されていない状況が続いていました。

　最新のASP.NET MVC 4（クラス自体はASP.NET Webページに含まれる）では、「ディスプレイ・モード」という機能が追加され、ユーザー・エージェント文字列からモバイル端末を判定する短い処理を自分で記述して、簡単にビューを切り替えられるようになっています。例えば「iPhone」用のディスプレイ・モードを追加するには、Global.asax.cs／Global.asax.vbファイルに以下のようなコードを記述します。

　そして、iPhone用ビュー・ファイルを作成して、以下のように「.iPhone」というディスプレイ・モード名をサフィックスとしてファイル名に付加するだけです（以下の例はC#の場合です。VBでは拡張子が「.vbhtml」になります。また、この例ではRazorエンジンを想定していますが、拡張子が「.aspx」のASPXエンジンでも同じようにモード名を付加するだけです）。

• 通常のビュー： Index.cshtml
• iPhone用のビュー： Index.iPhone.cshtml

　この状態で、iPhoneのブラウザでサイトにアクセスするとiPhone用ビューが自動的に表示されます。それ以外のブラウザでは通常のビューが表示されます。

井上　付け加えて、標準で「Mobile」というディスプレイ・モードが用意されており、モバイル・デバイスかどうかで簡単にビューを切り替えられるようになっています（モバイル用のビューは「Index.Mobile.cshtml」のようなファイル名を付けます）。現状、「Mobile」ディスプレイ・モードでは、iPhone／Windows Phoneは「モバイル・デバイス」として判定されますが、それ以外は「通常のデスクトップだ」と判定されます。従って、フィーチャーフォン向けのビューを用意したい場合などで各種デバイスを正確に細かく判定するためには、竹原さんが説明されたような独自のディスプレイ・モードを追加する必要性が出てきます。

　ディスプレイ・モードの利点は、内部でビューを切り替えてくれるので、URLをスマートフォン向けとPC向けで切り分ける必要がなく、全てのデバイス向けに単一のURLを提供できることです。

　次回の.NET中心会議（今後は「業開中心会議」（業務アプリ開発者中心会議）という名称に変わる予定）のテーマとしては、「.NET技術の“断捨離”」を検討中である。.NETが登場してから早くも10年がたち、その間、休むことなく進化を続けたので、ある対象を実装する技術や記述方法が多種多様になってきている（例えばデータベース・アクセスであれば、ADO.NETデータセット／LINQ to SQL／Entity Frameworkなど、さまざまな技術がある）。そこで今、次の10年、さらに快適で効率的な.NET開発を進めるために、あらゆる技術や記述方法を整理整頓し、「今後はどういう技術を使うべきなのか」や「どうやって使うべき技術に移行していくのか」を講演および議論したいと考えている。12月ごろの参加申し込みのご案内になると思うので、興味のある方はぜひご応募いただき、ご来場いただけると幸いだ。

「連載：.NET中心会議議事録」