Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
NTTデータグループウェブサイトの

マルチデバイス対応
伊原 力也
はじめに
• http://www.nttdata.com/jp/ja/
• 「NTTデータ」で検索
自己紹介
• 伊原力也
– ビジネス・アーキテクツ
• シニアインフォメーションアーキテクト

– mokuva
– Twitter: magi1125
– Facebook: Rikiya Ihara
事例を通して
1. どういうときにレスポンシブ
ウェブデザイン(RWD)を
選んだらいいの?
2. RWDやるなら
デザイニングインブラウザで
作らなきゃいけないの?
本題に入る、その前に
5分でわかる!NTTデータ
グループウェブサイト戦略

http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
NTTデータとは?
• 人々の暮らしをITで支える会社
– 銀行振込の仕組み
– 飛行機の経路設計システム
– 税金の電子申告システム
– 救急車と病院の連携システム

• 続きはWebで!
世界で第6位

http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
海外グループ会社数の推移

http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
グローバル企業への道

http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
求められる一体感

http://www.nttdata.com/global/en/onecontents/future.html
プロジェクトの位置づけ
• 世界規模のリブランディング
• ウェブサイトは
新たなコミュニケーション構築の
中核的な役割を果たす
– 世界にNTTデータブランドを伝える
– 各国のビジネスを後押しする
目的を実現する手段
1. グローバル共通テンプレートを
ガイドラインで提供
2. 各国の手でサイトリニューアル
Global Site

Brazil

Japan

China

North America

Denmark

Switzer...
各国ヒアリング・調査・分析
• コンテンツ目録

• 各国の想定ユーザーとニーズ

• コンテンツ同士の関係性

• ユーザーテストやインタビュー結果

• コンテンツの役割や目的

• 問い合わせフォームの内容

• 更新頻度や季節性

• ...
プロジェクト期間:約半年
戦略
2011年 8月~10月

設計、デザイン
2011年 11月~12月

実装、ガイドライン
2012年 1月~2月
NTTデータ本社ビル

http://www.flickr.com/photos/peta_p...
本題その1
NTTデータは
なぜRWDを選んだか
それは
流行りだったから
要件に沿っていたから
プロジェクト要件:
1. マルチデバイスに対応
2. 同一性の保持
3. ワンソースで対応
4. 耐用期間を長く
5. アクセシビリティの確保
1. マルチデバイスに対応
世界主要国のスマートフォン普及率(2012年第1四半期)

http://wirelesswire.jp/Mobile_Market_Survey/201206131700.html
2. 同一性の保持
• URLに対するリソースの同一性
• デバイス横断時のブランドの同一性
参考:UA振り分けで専用サイト

http://www.aeonmall.co.jp/
モバイル特有の行動があるか?

http://www.sapporobeer.jp/
3. ワンソース(HTML)
• 各国ごとに独自のCMSで運用
• モバイル版を別HTMLで出すには
大規模な改修が必要なケースも
• 優先は「NTT DATAブランド」の統一
Japan

CMS

North
America

CMS

C...
参考:ワンソースで専用サイト

http://www.fujifilm.com/
4. 耐用期間を長く

http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/
5. アクセシビリティ
• 「社会の公器」として、
世界のシステムを作る会社
• その存在を各地域の人に受け入れてもらう
• そのためのサイトは
多様な言語・文化・状況で使用される
「多様な人・多様な環境に対応できる」

アクセシビリティ
The power of the Web is in its universality.
Access by everyone regardless of
disability is an essential aspect.
Tim Berne...
data for : the people
「NTTデータは世界中で、人を支える
ソリューションをつくっています。」

http://www.nttdata.com/jp/ja/corporate/profile/pr/ad/pdf/ad_to...
NTTデータとアクセシビリティ
• 「人を支える仕組みを作る」
という点で、ウェブの思想と重なる
• 「NTT DATAの顔」である
ウェブサイトの「根幹」は
アクセシビリティ
プロジェクト要件とRWD
1. マルチデバイスに対応
2. 同一性の保持
3. ワンソースで対応

RWDの根本
RWDの特色

4. 耐用期間を長く
5. アクセシビリティの確保

WDの基盤
RWDに一部関連
結論
• プロジェクト要件とRWDに親和性あり
• RWDを採用したうえで
「要件を満たすように」
設計・デザイン・実装する
• しかしRWDにすれば
自動的に満たせるわけではない
例えば、アクセシビリティ
アクセシビリティとRWD
• BAD!!
作りがマズイと、構造と表現が不一致に

• GOOD!!
作りが上手いと、
複数デバイスで可読性・操作性が向上
BAD!!
構造と表現の不一致
• デバイスごとにバラバラのものを
無理やり合体する考え方だと
「ほころび」が出る
– table要素を列ごとに切ってfloatで並べる
– 似た要素を複数仕込んで、幅によって表示・非表示
– box-ordin...
1.3.2 意味のある順序
RWDにする意味 = 同一性
• デバイスごとにバラバラの構成なら
無理にRWDにせず、専用サイトを
• RWDなら、画面幅に由来する部分を
ちょびっと調整するぐらいの気持ちで
GOOD!!
複数デバイスで可読性・操作性が向上
• タッチデバイスで
押しやすい

• 幅が狭くても
読みやすい
デバイス問わず向上
• マウスでも
押しやすい

• PCブラウザで
拡大しても見やすい
アクセシビリティと
ユーザビリティとの交点
• 使いにくいけど使える
→ 状況によっては使えない
• 使えなかったものが使える
→ 大勢の使いやすさもだいたい向上する

アクセシビリティ

ユーザビリティ
まとめ
• 要件に沿って実装方法を選ぶ
– ワンソース=RWDではない
– 運用性とデバイス特化のバランス
– ハイブリッドもあり得る

• 「要件を満たすように」作る
– 実装方法を決めても自動では満たされない
– 方針をきちんと立てることが...
それでは、次のお題
本題その2
デザインカンプは悪か
デザイニングインブラウザは正義か
どちらも、
悪にも正義にもなるでしょう
RWD向けワークフロー
• ウォーターフォールをやめよう
– すべて実装してから問題がわかると
アタマまで戻ることがある
設計

デザイン

!
発生
問題

実装

検証
RWD向けワークフロー
• デザインカンプをやめよう
– デザイン時点では分からない
実装上の不都合があるかも
– カンプを何枚も作っても
それは結局捨てるもの
– ピクセルパーフェクトに
こだわりがち

→ デザイニングインブラウザで
アジャ...
デザイニングインブラウザ
しかし!
• このときはデザインカン
プを作った
• 代表ページいくつか+
モジュールリスト
• 広幅と狭幅の
2パターン
なぜ?
• 多くのプロジェクトメンバーや関係者
– 国内だけでなく、海外にも多数

• 一丸となって目指す「旗」が必要
• でもタイトなスケジュール
→ デザイナーがPhotoshopで
バッとキメの絵を作るのが
合意形成への一番の近道だった
ざっくり比較
デザイニング
インブラウザ
遅い ↓

Photoshopで
デザインカンプ
早い ↑

自由度

低い ↓

高い ↑

忠実度

高い ↑

低い ↓

効率

良い ↑

悪い ↓

作業速度
カンプで作ったけど
• 以下は全て回避できた
– すべて実装してから問題がわかると、
アタマまで戻ることがある
– デザイン時点では分からない
実装上の不都合があるかも
– カンプを何枚も作っても
それは結局捨てるもの
– ピクセルパーフェクト...
対策1:ツッコミメソッド
例:カンプ作成
ッ
ツ
ミ
コ

ツッ
コ
ツッ ミ
コミ

反論

Study
&
Review

議論

修正
納得
ツッコミで叩きながら進める
ワイヤー
カンプ
HTML
Study
&
Review

Study
&
Review

Study
&
Review
対策2:後半は実装ベースに移行
• パーツの展開的なものは、アートディレクターと実装
者がペアデザイニング(?)
• 新しいパーツはPhotoshopでデザイン

Photo by Esti Alvarez
http://www.flickr....
デザイニングインブラウザの真の利点
• それは「巻き込み力」なのでは
– 画面設計後に、すぐ本物っぽく動く
– プロジェクトメンバーの視線が集中
– みんなが巻き込まれる
– スペシャリストのコメントが集まる
– 叩き上げられていく
カンプでも巻き込みは起こせる
• つまり、役割と作業物は分離できる
– 設計・デザイン・実装のメンバーが
デザインカンプに「巻き込まれ」て
ツッコミをきちんと入れればよい
– これだけで、前提の勘違いや、
実装後の手戻りは回避可能
では、本当に必要なのは?
• メンバー間の“のりしろ”
– プロジェクトの戦略
と要件の理解
– ユーザーの理解
– デバイスの理解

デザ

ナー
イ

ディ
レク
ター

– ウェブデザインの理解
– ウェブの仕様と
トレンドの理解

• ...
のりしろが無いと……
• デザイニングインブラウザも難しい
– 誤った設計やデザインの考え方を
押し付けられて実装者の負担が増える
– プロジェクト全体で見たときの
手数が減らず、効率的にはならない

実装者が頑張る
だけでOK?
のりしろがあれば……
• キャンバスは状況によって自由に選べる
– 手書きのワイヤーフレーム
– デザインカンプ
– 紙芝居プロトタイプ
– Flashで作ったプロトタイプ
– デザイニングインブラウザ
のりしろをつなげるのは?
• チームとしての雰囲気
– ツッコミを入れやすい雰囲気
– ツッコミを受けやすい雰囲気
– 他のメンバーを信頼する雰囲気
– クライアントと一緒に作っていく雰囲気
ッ
ツ
ミ
コ

ツッ
コ
ツッ ミ
コミ

修正
...
結論
• 本当の悪は
のりしろを持たない人、
ツッコまない雰囲気
• 本当の正義は
のりしろを持った人が
ツッコミあうチーム
このセッションのまとめ
これとあれのどちらが正しいのかと考えず、「正しい
のは何か」と考えるようにしましょう。

http://www.kurashi-no-techo.co.jp/hint/h_130501.html
http://www.kurashi-no-techo.co.jp/
ありがとうございました
NTTデータグループウェブサイトのマルチデバイス対応
Prochain SlideShare
Chargement dans…5
×

NTTデータグループウェブサイトのマルチデバイス対応

2 356 vues

Publié le

CSS Nite LP, Disk 27「スマートフォン対応サイト制作(3)」にて。一部増補改訂。

Publié dans : Design
  • Soyez le premier à commenter

NTTデータグループウェブサイトのマルチデバイス対応

  1. 1. NTTデータグループウェブサイトの マルチデバイス対応 伊原 力也
  2. 2. はじめに • http://www.nttdata.com/jp/ja/ • 「NTTデータ」で検索
  3. 3. 自己紹介 • 伊原力也 – ビジネス・アーキテクツ • シニアインフォメーションアーキテクト – mokuva – Twitter: magi1125 – Facebook: Rikiya Ihara
  4. 4. 事例を通して 1. どういうときにレスポンシブ ウェブデザイン(RWD)を 選んだらいいの? 2. RWDやるなら デザイニングインブラウザで 作らなきゃいけないの?
  5. 5. 本題に入る、その前に
  6. 6. 5分でわかる!NTTデータ グループウェブサイト戦略 http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
  7. 7. NTTデータとは? • 人々の暮らしをITで支える会社 – 銀行振込の仕組み – 飛行機の経路設計システム – 税金の電子申告システム – 救急車と病院の連携システム • 続きはWebで!
  8. 8. 世界で第6位 http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
  9. 9. 海外グループ会社数の推移 http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
  10. 10. グローバル企業への道 http://www.nttdata.com/jp/ja/corporate/ir/library/tool/ar/pdf/2012/ar12_J_all.pdf
  11. 11. 求められる一体感 http://www.nttdata.com/global/en/onecontents/future.html
  12. 12. プロジェクトの位置づけ • 世界規模のリブランディング • ウェブサイトは 新たなコミュニケーション構築の 中核的な役割を果たす – 世界にNTTデータブランドを伝える – 各国のビジネスを後押しする
  13. 13. 目的を実現する手段 1. グローバル共通テンプレートを ガイドラインで提供 2. 各国の手でサイトリニューアル Global Site Brazil Japan China North America Denmark Switzerland EMEA Turkey Germany United Kingdom Italy
  14. 14. 各国ヒアリング・調査・分析 • コンテンツ目録 • 各国の想定ユーザーとニーズ • コンテンツ同士の関係性 • ユーザーテストやインタビュー結果 • コンテンツの役割や目的 • 問い合わせフォームの内容 • 更新頻度や季節性 • 現状のアクセスログ • リニューアル時の追加・削除 Content • 各国の会社のビジネス要件 • ウェブサイトのKPI • 各国の競合他社のサイト • CMSの導入状況、運用フロー • 各種ウェブサイト評価ランキング • その国での利用端末の状況 User Context
  15. 15. プロジェクト期間:約半年 戦略 2011年 8月~10月 設計、デザイン 2011年 11月~12月 実装、ガイドライン 2012年 1月~2月 NTTデータ本社ビル http://www.flickr.com/photos/peta_peta/350630421/ Photo by Hiroyuki-H
  16. 16. 本題その1
  17. 17. NTTデータは なぜRWDを選んだか
  18. 18. それは
  19. 19. 流行りだったから
  20. 20. 要件に沿っていたから プロジェクト要件: 1. マルチデバイスに対応 2. 同一性の保持 3. ワンソースで対応 4. 耐用期間を長く 5. アクセシビリティの確保
  21. 21. 1. マルチデバイスに対応 世界主要国のスマートフォン普及率(2012年第1四半期) http://wirelesswire.jp/Mobile_Market_Survey/201206131700.html
  22. 22. 2. 同一性の保持 • URLに対するリソースの同一性 • デバイス横断時のブランドの同一性
  23. 23. 参考:UA振り分けで専用サイト http://www.aeonmall.co.jp/
  24. 24. モバイル特有の行動があるか? http://www.sapporobeer.jp/
  25. 25. 3. ワンソース(HTML) • 各国ごとに独自のCMSで運用 • モバイル版を別HTMLで出すには 大規模な改修が必要なケースも • 優先は「NTT DATAブランド」の統一 Japan CMS North America CMS China CMS EMEA CMS Global CMS Germany CMS
  26. 26. 参考:ワンソースで専用サイト http://www.fujifilm.com/
  27. 27. 4. 耐用期間を長く http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/
  28. 28. 5. アクセシビリティ • 「社会の公器」として、 世界のシステムを作る会社 • その存在を各地域の人に受け入れてもらう • そのためのサイトは 多様な言語・文化・状況で使用される 「多様な人・多様な環境に対応できる」 アクセシビリティ
  29. 29. The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. Tim Berners-Lee Webのもつ力とはその普遍性にあり、 障害の有無にかかわらずアクセスできることは、 Webの本質的な側面のひとつである ティム・バーナーズ=リー http://www.w3.org/WAI/ http://www.mitsue.co.jp/help/accessibility.html
  30. 30. data for : the people 「NTTデータは世界中で、人を支える ソリューションをつくっています。」 http://www.nttdata.com/jp/ja/corporate/profile/pr/ad/pdf/ad_toyosu_01.pdf
  31. 31. NTTデータとアクセシビリティ • 「人を支える仕組みを作る」 という点で、ウェブの思想と重なる • 「NTT DATAの顔」である ウェブサイトの「根幹」は アクセシビリティ
  32. 32. プロジェクト要件とRWD 1. マルチデバイスに対応 2. 同一性の保持 3. ワンソースで対応 RWDの根本 RWDの特色 4. 耐用期間を長く 5. アクセシビリティの確保 WDの基盤 RWDに一部関連
  33. 33. 結論 • プロジェクト要件とRWDに親和性あり • RWDを採用したうえで 「要件を満たすように」 設計・デザイン・実装する • しかしRWDにすれば 自動的に満たせるわけではない 例えば、アクセシビリティ
  34. 34. アクセシビリティとRWD • BAD!! 作りがマズイと、構造と表現が不一致に • GOOD!! 作りが上手いと、 複数デバイスで可読性・操作性が向上
  35. 35. BAD!! 構造と表現の不一致 • デバイスごとにバラバラのものを 無理やり合体する考え方だと 「ほころび」が出る – table要素を列ごとに切ってfloatで並べる – 似た要素を複数仕込んで、幅によって表示・非表示 – box-ordinal-groupの使いすぎ →スクリーンリーダー利用時や ブラウザとスクリーンリーダー併用時に 問題発生(見た目とHTML構造が乖離)
  36. 36. 1.3.2 意味のある順序
  37. 37. RWDにする意味 = 同一性 • デバイスごとにバラバラの構成なら 無理にRWDにせず、専用サイトを • RWDなら、画面幅に由来する部分を ちょびっと調整するぐらいの気持ちで
  38. 38. GOOD!! 複数デバイスで可読性・操作性が向上 • タッチデバイスで 押しやすい • 幅が狭くても 読みやすい
  39. 39. デバイス問わず向上 • マウスでも 押しやすい • PCブラウザで 拡大しても見やすい
  40. 40. アクセシビリティと ユーザビリティとの交点 • 使いにくいけど使える → 状況によっては使えない • 使えなかったものが使える → 大勢の使いやすさもだいたい向上する アクセシビリティ ユーザビリティ
  41. 41. まとめ • 要件に沿って実装方法を選ぶ – ワンソース=RWDではない – 運用性とデバイス特化のバランス – ハイブリッドもあり得る • 「要件を満たすように」作る – 実装方法を決めても自動では満たされない – 方針をきちんと立てることが必要
  42. 42. それでは、次のお題
  43. 43. 本題その2
  44. 44. デザインカンプは悪か デザイニングインブラウザは正義か
  45. 45. どちらも、 悪にも正義にもなるでしょう
  46. 46. RWD向けワークフロー • ウォーターフォールをやめよう – すべて実装してから問題がわかると アタマまで戻ることがある 設計 デザイン ! 発生 問題 実装 検証
  47. 47. RWD向けワークフロー • デザインカンプをやめよう – デザイン時点では分からない 実装上の不都合があるかも – カンプを何枚も作っても それは結局捨てるもの – ピクセルパーフェクトに こだわりがち → デザイニングインブラウザで アジャイルしよう
  48. 48. デザイニングインブラウザ
  49. 49. しかし! • このときはデザインカン プを作った • 代表ページいくつか+ モジュールリスト • 広幅と狭幅の 2パターン
  50. 50. なぜ? • 多くのプロジェクトメンバーや関係者 – 国内だけでなく、海外にも多数 • 一丸となって目指す「旗」が必要 • でもタイトなスケジュール → デザイナーがPhotoshopで バッとキメの絵を作るのが 合意形成への一番の近道だった
  51. 51. ざっくり比較 デザイニング インブラウザ 遅い ↓ Photoshopで デザインカンプ 早い ↑ 自由度 低い ↓ 高い ↑ 忠実度 高い ↑ 低い ↓ 効率 良い ↑ 悪い ↓ 作業速度
  52. 52. カンプで作ったけど • 以下は全て回避できた – すべて実装してから問題がわかると、 アタマまで戻ることがある – デザイン時点では分からない 実装上の不都合があるかも – カンプを何枚も作っても それは結局捨てるもの – ピクセルパーフェクトにこだわりがち
  53. 53. 対策1:ツッコミメソッド 例:カンプ作成 ッ ツ ミ コ ツッ コ ツッ ミ コミ 反論 Study & Review 議論 修正 納得
  54. 54. ツッコミで叩きながら進める ワイヤー カンプ HTML Study & Review Study & Review Study & Review
  55. 55. 対策2:後半は実装ベースに移行 • パーツの展開的なものは、アートディレクターと実装 者がペアデザイニング(?) • 新しいパーツはPhotoshopでデザイン Photo by Esti Alvarez http://www.flickr.com/photos/esti/4638056301/
  56. 56. デザイニングインブラウザの真の利点 • それは「巻き込み力」なのでは – 画面設計後に、すぐ本物っぽく動く – プロジェクトメンバーの視線が集中 – みんなが巻き込まれる – スペシャリストのコメントが集まる – 叩き上げられていく
  57. 57. カンプでも巻き込みは起こせる • つまり、役割と作業物は分離できる – 設計・デザイン・実装のメンバーが デザインカンプに「巻き込まれ」て ツッコミをきちんと入れればよい – これだけで、前提の勘違いや、 実装後の手戻りは回避可能
  58. 58. では、本当に必要なのは? • メンバー間の“のりしろ” – プロジェクトの戦略 と要件の理解 – ユーザーの理解 – デバイスの理解 デザ ナー イ ディ レク ター – ウェブデザインの理解 – ウェブの仕様と トレンドの理解 • 作っているものを 自分以外のメンバーも 説明できるレベルでの理解 エンジニア
  59. 59. のりしろが無いと…… • デザイニングインブラウザも難しい – 誤った設計やデザインの考え方を 押し付けられて実装者の負担が増える – プロジェクト全体で見たときの 手数が減らず、効率的にはならない 実装者が頑張る だけでOK?
  60. 60. のりしろがあれば…… • キャンバスは状況によって自由に選べる – 手書きのワイヤーフレーム – デザインカンプ – 紙芝居プロトタイプ – Flashで作ったプロトタイプ – デザイニングインブラウザ
  61. 61. のりしろをつなげるのは? • チームとしての雰囲気 – ツッコミを入れやすい雰囲気 – ツッコミを受けやすい雰囲気 – 他のメンバーを信頼する雰囲気 – クライアントと一緒に作っていく雰囲気 ッ ツ ミ コ ツッ コ ツッ ミ コミ 修正 納得 議論 反論
  62. 62. 結論 • 本当の悪は のりしろを持たない人、 ツッコまない雰囲気 • 本当の正義は のりしろを持った人が ツッコミあうチーム
  63. 63. このセッションのまとめ
  64. 64. これとあれのどちらが正しいのかと考えず、「正しい のは何か」と考えるようにしましょう。 http://www.kurashi-no-techo.co.jp/hint/h_130501.html
  65. 65. http://www.kurashi-no-techo.co.jp/
  66. 66. ありがとうございました

×