Aggregator

更新が頻繁なページの AMP 対応のベストプラクティスを解説する。2つの方法が考えられる――「何もしない」と「amp-list」を使う方法だ。

- 更新が頻繁なコンテンツのAMP対応ベストプラクティス -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、高津戸 壮さん（ピクセルグリッド）の『CSS設計方法論とその先』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「CSS設計方法論とその先」を担当した高津戸です。ありがとうござました。

私のセッションはでは、具体的なコードの書き方というよりむしろ、コードを書く上での概念的なところに終始してお話させていただきました。セッション内で取り上げたOOCSS、BEM，Enduring CSS、Atomic CSSなどのCSS設計方法論の詳細につきましては、本セッションでは詳しく取り上げませんでしたが、もしセッションを聞いて、ご興味を持たれましたら、ご参照されることをおすすめします。特にBEMにつきましては、今やデファクトスタンダードとも言える書き方となっていると言ってしまっても良いほどに広まった考え方です。

アンケートでいただいた感想として、「結局どうすればいいのか分からなかった」という意見を拝見しました。申し訳ありません、その答えを提示することはできません。私のセッションで最もお伝えしたいことは、CSS設計はどうすれば良いのか、どこかに答えが転がっているわけではないということです。そして、そのヒントとなることをパラパラと紹介させていただきました。

CSSの設計について、そこまで突き詰めて考える必要がないケースというのも多いです（まず、そこも一つ重要な認識だと思います）。ですが、規模の大きいサイトになってくると、この問題は重くのしかかってきます。UIの統一性維持、運用コスト増加の回避、スケーラビリティの確保など、多くの問題を回避するためキーになってきます。そのような問題を解決することができるスキルというのは、単にコードを書く以上の能力が必要とされます。そして、それはHTMLとCSSを書く人が次のステップとして踏み出す一つの道かと私は考えます。

最後に宣伝となりますが、弊社サービスCodeGridにおいてもCSS設計に関する記事があります。月額有料制ですがもしよろしければご参照いただければと思います。

その他ご質問いただいたこと

ECSSで書かれた具体的なサイトが知りたい

コレだというのは自分も把握していないのですが、Enduring CSS著者のBen Frain氏が、ECSSを使ったサイトを集めたいと言っているのをGitHubやTwitter上で見かけました。

• Do you public a project example that you use ecss?
• Do you know of or have built a site that uses ECSS?

まぁ、サイトを見てもそのコンパイル元のソースコードが読めるわけではないのでなんともですが、よろしければご参照下さい。

セッション中の内容に関連するサイト

• Object Oriented CSS
• BEM
• airbnb/css: Airbnbスタイルガイド
• nao215/css-style-guide: Airbnbスタイルガイド翻訳
• stylelint
• U.S. Web Design Standards
• Atomic Design
• Defining Design Systems ? EightShapes
• Enduring CSS
• Atomic CSS
• Let’s Define Exactly What Atomic CSS is | CSS-Tricks

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、大串 肇さん（mgn）の『Gitの入門とGitを利用した共同制作方法』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

補足

こんにちわ。Gitの入門とGitを利用した共同制作方法を担当した大串です。

「Gitを使ってみようと思います。」「Gitの説明で一番わかりやすかった。」「チームで導入してみます！」「Git flowとGitHub flowの違いがわかった。」「Gitのイメージができた。」といったコメントを多くいただきました。スピーカー冥利につきます。ありがとうござます。是非今後Gitを使って下さい！

また、「わかりやすかった。」「時間が短く感じた。」「こんな風に教えてもらったことなかった。」「バスガイド並みにわかりやすい。」「かわいい。」といったお褒めの言葉も沢山いただきました。とても嬉しく感じています。ありがとうございます。

冒頭に伺った、「Gitを普段から利用しているか？」という質問について8割以上の手が上がったので、全体のセッションの時間配分において、初心者向けの内容を30%ぐらいにしました。結果として「初心者向けの内容をもっと聞きたかった。」という声を頂いております。

逆に、すでにGitを使ってられる方からは、「すでにGitを使っており、学ぶところがなかった。」という声もいただきました。このあたり調整が難しかったです。初めから運用だけとか初心者向けとしておいたほうが混乱が無くてよかったかもしれません。

読み飛ばしてしまった、初心者向けのフォローアップ内容としまして、Gitの基礎講座の動画を共有します。こちらはGitの初心者向けの集中特訓講座として行っている内容をそのまま動画にしたものです。本来は集中特訓講座受講生のみへの共有なのですが特別に共有させていただきます。初心者の方は是非ご覧になって下さい。

Git基礎講座(全24チャプタ)

https://www.youtube.com/playlist?list=PLvEni36L5VuX3rrE2lG5QTB2Cgyjixppy

質問

Sass,typescriptなどのコンパイルしなければならないときは、どのタイミングでやるのですか？

一般的にコンパイル後のファイルはGit管理に含めません。srcのファイルのみGit管理するケースが多いです。

年齢のいったディレクターなどが新しいことを覚えるのが嫌らしくGitをつかってくれません。どうしたら使ってもらえると思いますか？

とてもむずかしい問題ですね。まずはご自身だけでこっそりGitを使うことをおすすめします。案件が進んでいく中で、そのうち先祖返りしたり、最新版がどれかわからなくなったり、そのディレクターさんが困るタイミングがやってきたら、そのときにドヤ顔でGitから最新版を渡してあげるというのが一番ソフトな方法でGitの有用性を感じてもらえる方法かと思います。もしくは、新しいものは使わないなんて言っている、向上心のない人との仕事はとてもストレスになるはずなので、更に上の上司に相談するか、転職を考えるか、それでも我慢するかになると思います。使ってもらえるといいですね！

以前のイベントで大串からGitの話を聞き、一人でGitを始めることができました。この場を借りてありがとうございました！

嬉しいです。コチラこそ！！！　ありがとうございます！

告知

定期的にGitの集中特訓講座を開催しております、今後の告知については以下のFacebookページを御覧ください。

• https://www.facebook.com/pg/meganedotin/

また、社内へのGitの導入支援や、Gitを利用したプロジェクトマネジメントのお手伝いなどお仕事がございましたら、どうぞお気軽にお声掛け下さい。

• https://www.m-g-n.me/

ありがとうございました！

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、阿部 正幸さん（KDDIウェブコミュニケーションズ）の『ここまでのJavaScriptスタンダードと、これからのJavaScript ES6について』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

CSS Nite LP54に参加した皆さま長丁場のイベント参加お疲れ様でした。
「ここまでのJavaScriptスタンダードと、これからのJavaScript ES6について」に
登壇いたしましたKDDIウェブコミュニケーションズの阿部です。

今回はJavaScriptに苦手意識がある方を対象にオブジェクトに重点を置いて登壇いたしました。
紹介したオブジェクトを作ったプログラミングは、DOMや現行配布されているライブラリーを理解する上でとても重要な事項です。
難しいと感じた方は是非サンプルプログラムを触ってみてください。

これからのJavaScriptはと言うと、ECMAScript6のClassを使い似たようなプログラミングをします。
ECMAScript6はIE11で動作しませんので、ES5への変換が必要です。変換はBabelなどのコンパイルツールが多く利用されています。

現行のJavaScriptと、これからのJavaScriptを両面から見ていただくと面白いかなと思います。
セミナーで使ったコードは下記よりダウンロードいただけます。よく分からなかった、JavaScritpに苦手意識のある方は、ぜひお試しください。

また多くの方からJavaScriptのハンズオンセミナーに参加したいとお声がけいただけました。
本当にありがとうございます。
次回のハンズオンセミナーはデジハリ＠大阪校で開催します。
https://www.facebook.com/events/2066803030205952/

その他にも多くのイベント登壇しております。イベント情報に関しましては、Facebookや、Line@等でつぶやておりますので、是非フォローいただけると幸いです。

長くなりましたがセミナーに参加いただきました皆様、フォローアップメッセージを最後まで読んでいただきありがとうございました。
またみなさまにお会いできることを楽しみにしております。

----------------------
サンプルプログラム
----------------------

・コンロのサンプル
http://bit.ly/lp54zipfile

・JavaScriptの基礎
http://bit.ly/js-hands-on

----------------------
ソーシャルアカウント
----------------------

下記は私のソーシャルアカウントです。
LINE@ではセミナーの無料招待チケットなどもお配りしております。
お気軽にLine@、Facebookフォローいただけると幸いです。

Facebook
https://www.facebook.com/chiyo.abe

LINE@
http://line.me/ti/p/@gkv8736o

CPIスタッフブログ
http://shared-blog.kddi-web.com/

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、鹿野 壮さん（ICS）の『Grid Layoutがやってきた！ Flexboxやfloatとの適切な使い分け方法』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「Grid Layoutがやってきた！ Flexboxやfloatとの適切な使い分け方法」を担当した鹿野です。今回はご参加ありがとうございました。

2017年、全主要ブラウザが対応したCSS Grid。その概要、コーディング方法、IE 11の対応方法、floatやFlexboxとの使い分けまでを解説しました。

• すごくわかりやすかった、実践で使えそうなことがわかった
• FlexboxやGridとの使い分けがわかりやすかった
• 基本的な使い方がイメージできて、ハードルが低くなったような気がする

など、想像よりも多くの反響があり嬉しく思います。私自身がGridについて深く学びたかったこともあり、皆さんと一緒にGridの魅力を体験できる時間だったと感じます。

アンケートやTwitterでいただいた質問と答え

フォローアップとして、アンケートやTwitterでお寄せいただいた質問をいくつかピックアップして回答します。

入れ子にできますか？

可能です。

セッション中に紹介したデモ「Rodchenko Poster Layout - CSS Grid」では、.backgroundの要素にGrid指定、その中の#cardに対して更にGrid指定となっています。

<table>のcolspan属性（セルを横に繋げる指定）は可能ですか？

spanという単位が使えます。

grid-row-start: 1;grid-row-end: span 2;

と指定すると、「行の一つ目のラインから、2つ分伸ばしください」という意味になります。

プロパティの楽な書き方はありますか？

行と列の定義についてまとめることが可能です。

行の開始と終了位置指定方法①

セッションで紹介した方法です。

.item {grid-row-start: 1;grid-row-end: 3;grid-column-start: 1;grid-column-end: 2;}

行の開始と終了位置指定方法②

行の開始・終了、列の開始・終了をまとめて指定する方法です。 / で区切ります。

.item {grid-row: 1 / 3;grid-column: 1 / 2;}

行の開始と終了位置指定方法③

行と列をまとめて指定する方法です。 /で区切り、次のように指定します。

grid-area: (行開始番号) / (列開始番号) / (行終了番号) / (列終了番号)

セッション中に紹介したメインビジュアルのアイテム位置定義は、次のように記述できます。

.main-visual {grid-area: 1 / 1 / 3 / 2;}

ポリフィルはありますか？

Grid未対応ブブラウザでもGridレイアウトが可能なポリフィルがあります。しかし、次のような課題があります（参考記事「CSS Grid Layoutをガッツリ使った所感 - Qiita」）。

• ID属性が多く付与される
• overflowの解釈・スクロールバーの発生有無が想定と異なった
• CSS Grid Layoutとはあまり関係ない部分のレイアウトが崩れる
• ライブラリの容量が大きい

ポリフィルを使う際は、これらの課題に注意してください。

複数行になる可能性があるものはGridにしておいた方がよいのでしょうか？

Gridにしておいたほうが管理しやすいケースが多いです。

例えば、今回のセッション内で紹介した「猫の3つのサムネイル画像横並び」を複数行にしたければ、display: flexの代わりにdisplay: gridを指定する方がよいでしょう。ただし、ページ全体のコンテナ .containerではなく、猫のサムネイルのコンテナ .other-photosに対してGridを指定し、 .other-photos内のみでGridレイアウトの影響が及ぶようにする方が全体のレイアウトへの影響が少なくてラクです。

frとは何の略ですか？

fractionです。（越智さん、フォローツイートありがとうございます！ https://twitter.com/o_ti/status/926724288610164736 ）

fr を使う場合、他の要素は可変にしない方がいいのでしょうか？

可変要素をいくつ並べても問題ありません。

frという単位は、「余白がある場合、その要素をどれだけ拡大するか」を指定しますが、複数の要素にfrを使うと要素の拡大率がfrの数によって変わります。いくつか例を見てみましょう。

次のCSSコードでは、2行のレイアウトになります。1行目のサイズが100px、２行目は残りの領域全てです。

.container {display: grid;grid-template-rows: 100px 1fr;}

frが一つだけの場合

次のCSSコードでは、3行のレイアウトになります。1行目のサイズが100px、2行目と3行目は、残りの領域を半分ずつに分解したサイズになります。

.container {display: grid;grid-template-rows: 100px 1fr 1fr;}

2frのように、frに2以上を指定すると余った領域をその数分だけ確保します。次のCSSコードでは、3行のレイアウトになります。

• 1行目のサイズ : 100px
• 2行目のサイズ : 残り領域を3分割したうちの1つ分
• 3行目のサイズ : 残り領域を3分割したうちの2つ分

.container {display: grid;grid-template-rows: 100px 1fr 2fr;}

FlexboxのGridを使ったことがある人であれば、 flex-grow プロパティと似たような挙動をすると覚えるとよいでしょう。記事「CSS Grid Layout を極める！（場面別編） - Qiita」にわかりやすい解説がありますので、合わせて参照ください。

レスポンシブ対応した時の状態がわかりませんでした

行列の構造を変える例

3行3列のGridを、画面サイズ500px以上のときは2行4列に変更しつつ、各セルのサイズを変更してみましょう。

.container {display: grid;grid-template-rows: 1fr 220px 30px;grid-template-columns: 50% 160px 1fr;}@media (min-width: 500px) {.container {grid-template-rows: 1fr 500px;grid-template-columns: 400px 300px 1fr 200px;}}

アイテムの配置位置を変える例

行1から3まで、列1から2まで配置したmain-visualを、画面サイズ500px以上のときは列1から4まで配置するように変更してみましょう。

.main-visual {grid-row-start: 1;grid-row-end: 3;grid-column-start: 1;grid-column-end: 2;}@media (min-width: 500px) {.main-visual {grid-column-start: 1;grid-column-end: 4;}}

いずれの場合も、HTMLコードの構造を一切変えることなくCSSのみで柔軟にレイアウトを変更できるのがポイントです。

ブラウザがGridに対応した正確なバージョン番号を知りたいです

各ブラウザは、次のバージョンにてGridに対応しました。

• Edge : 16より対応
• Safari : 10.1より対応
• Chrome : 57より対応
• Firefox : 52より対応
• iOS Safari : 10.3より対応
• Android版Chrome : 57より対応
• Android System WebView : 57より対応

いずれも2017年にリリースされたバージョンで、一番遅かったのがEdge 16（2017/10/17リリース）です。

古いiOS Safari、古いAndroidブラウザ、Grid未対応のブラウザ対応が必要な場合は？

方法1. ポリフィルを使う

「ポリフィル」を使うと、Grid未対応ブラウザでもGridのレイアウトが実現できます。副作用もあるので、詳しくは前述の「ポリフィルはありますか？」を参照ください。

方法2. デフォルトを1カラムレイアウトにする

デザイン次第ではありますが、デフォルトをGridを使わない1カラムレイアウトにするという方法もあります。

• スマートフォンまたはGrid未対応ブラウザ : 1カラム
• Grid対応ブラウザ : Gridによるレイアウト

とすることで、Grid対応、未対応ブラウザに対して情報を伝える方法です。私が個人案件で仕事をする際は、この手法を用いています。

@supports規則を使うことで「グリッドに対応しているブラウザのみ、をを付加することができます。

/* グリッド対応ブラウザで、500px以上のデバイス幅のときのみグリッドを適用する */@supports (display: grid) {@media (min-width: 500px) {.contaner {display: grid;}}}

メリットばかりではなく、Gridのデメリットとその対応策について聞きたいです

一番のデメリットは未対応ブラウザがあることです。しかし、昨今のブラウザは自動アップデートが主流になっていますし、IE 11でも対策次第でGridが使えることを考えると、今後Gridが利用できる環境は広がるでしょう。前述の「古いiOS Safari、古いAndroidブラウザ、Grid未対応のブラウザ対応が必要な場合は？」のような対応をしつつ、ブラウザのサポート拡大を待ちましょう。

また、行列の数を増やしすぎると管理が煩雑になるというデメリットもあります。Excelでも行列を多く増やしてセルの結合を多用すると見辛くなるのと同じです。Gridによるレイアウトは大枠部分に留め、細かい部分についてはFlexboxで代用できないか、Gridの入れ子ができないか、等を検討しながらレイアウトしていくのがよいでしょう。

感想

いただいた感想の中から、特に印象深かった感想をいくつかピックアップします。Gridの便利さが伝わったようで何よりです。

• レイアウトに自由度が増して面白い
• 利用できるとコードが短くなりそう
• 使えるのは少し先になりそうだけど、使えるようになったら常用しそう
• セルに名前を使えるところがデザイナーに愛され、昔のテーブルレイアウトのようなところがディレクターに愛されると思った
• Flexboxの複数行のズレが起きていたので役に立った
• JavaScriptで対応していたようなレイアウトを、CSSで実現できるのは嬉しい
• エクセルのように扱えますの言葉で一気に理解が深まりました
• 入れ子の指定がなしでGridのレイアウトができるのがすごい
• div山脈を築き上げなくてよいのが素敵
• 役所や教育機関ゆえに、日本のIE 11のシェアが16%だと思う。しかし、対応を余儀なくされるのも事実

Gridの学習に役立つサイトについて

CSS Gridの学習には、次のようなサイトが役立ちます。

• CSS Grid Layout入門。対応ブラウザが出揃った新しいレイアウト仕様 - ICS MEDIA
• これからのレイアウトはGrid Layoutで決まり？特徴で使い分けたいCSSレイアウト手法 - ICS MEDIA
• これからのグリッドレイアウト | CodeGrid
• CSS Grid Layout を極める！（基礎編） - Qiita
• CSS Grid Layout を極める！（場面別編） - Qiita
• CSS Grid Layoutをガッツリ使った所感 - Qiita
• CSS Grid Layout Module Level 1

もしGridの学習をしていて不明な点があれば、Twitter等で気軽にご相談くださいませ。

告知

次の媒体でWebデザインやフロントエンドの情報について発信しています。こちらも是非ご覧ください！

• ICS MEDIA - Webデザイナー/デベロッパーの必読メディア
• tonkotsuboy_com - Qiita
• Gulp入門 - Schoo
• Flexbox 入門 - Lynda.com
• WebデザイナーのためのiOSアプリ開発入門 - WPJ

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、久保 知己さん（まぼろし）+伊藤 由暁さん（まぼろし）の『CSSをちゃんと書くためには？』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

p>「CSSをちゃんと書くためには？」のCSSを担当した久保です。
CSSでは重要な仕様だけど、なかなか触れられない「視覚整形モデル」について、ご紹介しました。
ちゃんと理解するのは難しい内容ですが、これを理解しておくと不思議なCSSの挙動も理解しやすくなります。
視覚整形モデルには、位置決定スキームというものあり、通常の要素の流れから逸脱すると、marginの動きに違いが出ます。プロパティの働きなどを調べる際に、視覚整形モデルがわかっていると、より理解が進むでしょう。

またセッションでは、CSSの宣言を紹介した継承の特性やwidthプロパティを使った例を2つご紹介しました。
CSS設計というと、命名規則やコンポーネントの分け方などに注視されがちがですが、宣言もCSS設計の重要な要素のひとつというこをお伝えしました。宣言の行い方は、それぞれのプロパティの特性などを理解する必要があり、習得が難しいポイントです。
しかし宣言もCSS設計のひとつと意識することで、宣言の行い方も上達していくことでしょう。
再現したデザインとCSSの振る舞いがスマートに一致したCSSを目指すことが大切です。

「CSSをちゃんと書くためには？」のSassを担当した伊藤です。ご参加ありがとうございました。

CSSは命名規則や構造化だけでなく宣言そのものも重要であり、その宣言記述に注力するために効率的で意味のあるSassを構築しましょうという話でした。

セッション後の質問の補足

無駄なCSSやSassを書いていないかチェックしてくれるルールはありますか？

完全ではありませんが、Style Validatorというブラウザの拡張機能があります。

http://style-validator.io/

display: inlineが指定されたセレクタにwidth指定やheight指定があると「No effect（効果なし）」というエラーを表示してくれます。

アンケートへの回答

今回の授業だけなく何か情報を発信しているなら教えて欲しい

書籍やAdobeの公式ブログでも執筆を行なっています。また個人ブログでも、定期的に情報を発信しています。

久保

• Amazon.co.jp: 久保知己:作品一覧、著者略歴
• 久保 知己 | Adobe Creative Station
• Web Design KOJIKA17

伊藤

• いちばんよくわかるWebデザインの基本きちんと入門
• dskd

詳細度を高めている案件がある場合のリファクタリングが悩みである

詳細度が高くなっているとリファクタリングがしにくいのは私も感じます。
どの程度リファクタリングするのかわからないのですが、もし全てのCSSを書き換えていいのであれば、私はセレクタの命名規則を変えてリファクタリングすることをおすすめします。
命名規則を変えることによって、古いCSSとリファクタリングのCSSが混同していても、セレクタ名のバッティングを防ぐことができます。

ただしこの方法は、全て書き換えるのでコストがかかります。既存の状態を残してリファクタリングするのであれば、ボタンなどの小さく影響範囲の小さい箇所から、リファクタリングするしかないと思います。

メディアクエリの書き方ですが、(min-width: *) and (max-width: *) ってかくのと、1つだけ指定して上書きしていくのと、どちらがおすすめですか？

デザインによります。PCとスマートフォンで見た目が異なる箇所が多いのであれば、限定的に指定できるandを使って指定が有効です。
ただ見た目で似た部分が多く、CSSの宣言の差が少ないようであれば、1つだけ指定して上書きする方法をとっています。

CSSのプロパティでは仕様書と一般的な認識と違うようなものがあれば聞いてみたいです。

一般的な認識が難しいですが、例えばwidthとmarginプロパティとの関係性は、10の状態によって変化します。
幅とマージンの計算 | 視覚整形モデル詳細

また別の例をあげると、displayプロパティの最初値はinlineです。ではなぜ、ブラウザで見たときは、divやul要素などはdisplay: block;の挙動を行うのか。それはブラウザのスタイルシート「User Agent Stylesheet」が効いているからです。そのためブラウザが対応していなかったり、未知のHTMl要素は、すべてdisplay: inline;として表示されます。

CSSフレームワークとCSS設計の組み合わせってやりますか？

はい、弊社でCSSフレームワークを利用する場合はBootstrapを利用しています。CSSフレームワークとは別のCSSを追加するときは、命名規則が重複しないようにMindBEMなどを使う場合が多いです。

widthを9xxpxにしてmargin: autoにしちゃってるんですが、ダメでしょうか？

もちろん、ダメではありません。
レスポンシブなどで、もし段階的に幅の指定を変えなければならないのであれば、widthプロパティをメディアクエリで操作しなければなりません。
CSSで実現したい振る舞いによって、宣言の解は変わってきます。

どの段階で無駄を省いていくか？

サイトの規模にもよりますが、ある程度のコンポーネントが揃った時に、行なっています。

命名規則ではどういうルールで書いているか教えて欲しい

案件によって指定される場合もありますが、弊社では下記が多いです。

• MindBEM
• FLOCSS

&記号を使うとgrep検索しづらくなる

なりますね。目的のセレクタがあるSCSSファイルをすぐgrepするために、伊藤はセレクタの上にフルのセレクタをSCSSコメントで書いておくなどしています。

.box {// .boxheader&header {}// .boxbody&body {}// .boxfooter&footer {}}

エディタによっては追跡可能です。

WebStorm 2017.3 EAP にて。 https://t.co/1vKCCEqZhG"

あるいは&記号でセレクタを分断せずに、

.box {@at-root {& {color: navy}.boxheader {color: gold}.boxbody {color: tomato}.boxfooter {color: skyblue}}}

と書いています。@at-rootもSassの機能の一つで、中身がトップレベルのスコープで解釈されます。それでいて&記号もちゃんと親ブロックのセレクタを取得してコンパイルされます。

.box {color: navy}.boxheader {color: gold}.boxbody {color: tomato}.boxfooter {color: skyblue}

&を使う際、一つのSCSSファイルの中で違うの文脈の&が出てしまうと混乱しますので、BEMで言うところのブロック単位（SMACSSではっモジュール単位）でSCSSファイルを分けると良いです。

.header {&logo {}&lede {}}.header-nav {&list {}&item {}}

前述のような形ですと、&が.headerだったり.header-navだったりしてしまうので、header.scssとheader-nav.scssのように別ファイルに分けてください。

ネストは何段階まで許容している？

本当に必要であればいくらでもネスティングしていく、程度の気持ちです。BEMならブロックの子要素は全て&_Element {}のようにSCSS上で並列して書けますので、そもそも深くなりません。BEMエレメントから3階層程度が個人的な許容範囲です。@at-rootを使うとそのぶんインデントが増えますがそれすら気になるならネスティングは使わないとプロジェクトで決めてしまった方が気が楽かと思います。

&の問題点？

&はgrepしづらい、セレクタが分かりづらくなるという意見をいくつかいただきました。伊藤としてはブロック / モジュール単位でSCSSファイルを分割しているので、&は常にそのブロックであるという認識で書いています。よって&で分かりづらくなったことはありません。

このセクションでは、漫然としたネスティングで詳細度を高めるのはやめましょうというニュアンスをお伝えしたかったのですが、&記号の方に意識が注がれてしまう説明だったと反省しています。

改めてまとめますと「ネスティングは主従関係が可視化されるので便利だが、不必要なネスティングで詳細度が高くなると、保守・運用フェーズでメンテナンス性が下がる。必要な場合は&記号を活用して詳細度を下げましょう」ということです。

CSSの管理・設計を行うにあたり、プロダクトマネージャーやデザイナーにどうアプローチすれば良いか

HTMLとCSSもプロダクトを構成するに欠かせないものの一つであり、「誰がやっても同じもの」ではないことは啓蒙が必要です。無秩序に作ったCSSではスケジュールやクオリティーは保証できません。CSSにも相応の作業時間と専門知識が欠かせないからです。単にデザインを再現しているだけと思われないよう、プロダクトにとって保守性・可搬性の高いCSSを書き、それをアピールしていくと良いでしょう。

@functionを使ったz-indexの管理方法がためになった

ありがとうございます。z-indexの管理が必要ではないプロジェクトでは無用の長物ですので、このセクションが響かなかった方もいるかと思います。

CSSではマジックナンバーはやめようというTIPSは有名ですね。とりあえず一番上に出したいからz-index: 9999というような指定はCSSではよくないとされています。大規模なウェブサイトや施策が入り乱れるサービスですと、z-indexの値は混沌を極めます。@functionで重なり順だけ管理すれば、数字の大きさは気にしなくて済みます。

数字が大きい方が上に来るのだから管理しなくても別にいいのでは、という意見もあるかもしれません。しかし、z-indexは数字が大きい方が前面に表示されるとは限りません。スタック文脈と呼ばれる概念があり、単純な数字の大小だけでは説明できないのがz-indexなのです。

時間の関係でスライドに入れられませんでしたが、z-indexのスタック文脈問題に対応すべく、久保がカスタムした関数があります。二階層以上や逆順での管理が可能になっていますのでぜひチェックしてみてください。

Sassを使ったz-indexの管理 - Qiita

@functionの他の活用法

Sassの組み込み関数のuniqueid()と組み合わせてキャッシュバスターを付与することができます。

@function cache-buster($path) {@return #{$path + "?" + uniqueid()};}.kv {background-image: url(cache-buster("/assets/images/kv.png"));}

.kv {background-image: url(/assets/images/kv.png?u278e85ca);}

作成したcache-buster関数に画像パスを引数に入れると、コンパイル時にパスの後ろに?u278e85caというパラメータが付与されます。uniqueid関数はコンパイルの度に新しい文字列を出力するので、キャッシュバスターに利用できるというわけです。

Generated by SassMeister.com.

@importで変数を使う方法はありますか？

残念ながらないです。Sassの@importはurl()型か文字列しか受け取れず、インターポレーションやquote()を挟むことができません。

汎用性の高い変数がうまく作れない

用途が限定されすぎてる値を変数化するのはあまり意味がありません。かといって、$base: 10px;などを作りあらゆるところで演算して使えばいいというわけでもありません。

汎用性に必要な観点は「粒度」です。変数がpx系か%系といった粒度ではなく「.boxに使うサイズバリエーション」「ブレークポイントのサイズバリエーション」という具合に主に何に使われるかでカテゴリ分けしています。

まずは変数を使わずにベタ書きでコーディングを進め、変数でまとめた方がいいと感じたものを変数化すれば良いでしょう。変数を使うか使わないかでコンパイル結果が変わることはないので、定期的に変数を見直すのも良いです。

SCSS記法とSass記法の違い

SCSS記法は素のCSSと同じように {} や ;を使いますが、Sass記法はスペースとインデントと改行で書く、とセッションでは説明しました。Sass記法は

• {}を使わない
• 次のプロパティーは必ず改行して記述
• :のうしろに必ずスペースが必要
• ;が不要
• インデントが宣言ブロックを表す
• mixinはショートハンドがある

といった特徴があります。

// SCSS記法@mixin ir {display: block;overflow: hidden;text-indent: 101%;white-space: nowrap;}.nav {color: blue;font-size: 0.3em;a {width: 50px;@include ir;&:hover {background-color: #eee;}}}

// Sass記法=irdisplay: blockoverflow: hiddentext-indent: 101%white-space: nowrap.navcolor: bluefont-size: 0.3ema+irwidth: 50px&:hoverbackground-color: #eee

前述の2つのコンパイル結果は同じですが、Sass記法の方が記述が少なくて済むので好きという人は少なくありません。

社内でCSSを書くスタッフにレベル差があってSassが導入しづらいがどうしたらよいか

組織の規模に関わらず個人向けでも大勢向けでも同じで、「繰り返し啓蒙していく」のが一番です。仲のいい社員をイベントに誘って一緒に参加したり、社内勉強会を開いたり、啓蒙活動にも色々方法があります。Slackなどの分報でブログ記事などを共有するのも良いですね。まずは業務で関わった人から巻き込んでいってはどうでしょうか。

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、中村 勇希さん（トゥーアール）『テンプレートエンジンPugを使った、みんなでやるウェブ制作』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「テンプレートエンジンPugを使った、みんなでやるウェブ制作」のセッションを担当した中村です。セッションをご覧いただきましてありがとうございました。

今回のお話は「ツールの紹介」といった側面と「コーディングをデザインの一環として捉える」といった側面がありました。アンケートやTwitterをコメントをみていると、コーディングがデザインを言語化することであることについて共感・実践してみたいというコメントを頂けているようで幸いです。

一方で、運用の面で課題が多いのも事実です。特に、新規案件や、個人的には取り入れていきたいものの、実務で役立てられるかどうかという点では厳しそうというコメントも多くいただきましたので、こちらで回答いたします。

ツール

ejsはどうなの？

できることについては、Pugとそんなに変わりません。決定的にこれができないので採用できないということはなく、私もejsを使うことはあります。

• HTMLをそのまま書くことができる
  • Sassにおける「scss記法」的なもの

こちらは「Pugさすがにキモいもののコンポーネント指向で考えたい」という人はこちらの導入をおすすめします。こちらも中にJavaScriptを埋め込むことができます。Pugのように-と書くだけでJavaScriptにはならず<%%>のようにする必要があり、PHPのような見た目になります。

ejsとPugの混在はできるか

中間成果物としてのHTMLを生成し、それらをどちらかで読み込むという形になるかと思います。そうすれば、混在させることは可能です。ですが、オススメはしません。記法が混在し、コンパイルも二重に必要で、結局どちらつかずになってしまうでしょう。

現状ejsで動いているものをPugで扱いたい場合、一旦EJSをHTMLにコンパイルし、HTML2Pugなどを用いてPugに直してしまうという手もあります。

izolate/html2pug: Converts HTML to Pug

ブラウザ版もあります。

html2pug - convert your html code to jade

運用

エンジニアがいないと難しいか

環境面でいうと、何か問題があったときにメンバー全員が「黒い画面怖い」みたいな状態だと立ち往生してしまうかもしれません。最低でも一人は「少しわかる」みたいな人がいるのが理想です。

しかし、その状態ではSassも満足に導入できないという悩みもあるかと思います。少しセッション後にお話しましたが、現在その辺を含めた「デザイナー・新米コーダーでもフロントエンド怖くなくなる」ような書籍を執筆しておりますので、そちらをお待ちいただければと思います。

[宣伝]gulpに関しては、こちらの書籍をご参考いただければと思います。

ゼロからはじめるgulp入門書 - nayucolony - BOOTH（同人誌通販・ダウンロード）

コンパイル後のHTMLを触られてしまう

解決しようとする場合、社内外のコミュニケーションの部分から始まりますが、それが行き届かない範囲も関与する形になってしまうと、運用までPugでやるのは難しいです。

ツールで無理やり解決しようとするならば、HTML2Pugを使って差分をとって……という手段もなくはないのですが、あずかり知らないところで改変されているという場合は先祖返りしてしまうので有効ではないでしょう。そういう体制の場合、Pug云々のまえにまずはGitの導入からはじめることをおすすめします。Gitはセーブポイントです。

Pugを使いたい場合、初期開発だけPug、運用体制に入ったらHTML、というのが妥当なところです。初期開発だけでも、共通化などでPugは役立つ部分が多いので、ぜひ活用してみてください。

また、例えばトップページのメッセージを変えるなどで、あらかじめ他者によるHTMLの修正があることがわかっているのであれば、その部分だけをコンポーネントとして区切っておき「このファイルのテキストだけを変えてください」という取り決めをしておくと良いのではないかと思います。コンパイル作業は、コンパイル用のコマンドをバッチファイル化しておけばワンクリックでOKです（前川さんのセッションを参考にしてください）。

ファイル管理が大変そう

コンポーネントと呼べるものが増えれば増えるほどファイルが増えていきます。これらは、セッション中でもお話した通り、CSSと同じ粒度で同じように管理していくのが理想です（こうなってくると、CSS設計論的な話になっちゃうのですが）。Pug側で好き勝手にファイル管理の方法を生み出したところで、CSSとの関係性がわかりにくくなってしまっては、プロジェクト全体において「ファイル管理が大変」であることが解決できません。

一つのアプローチとして、CSSフレームワークのファイル管理方法を眺めて見ることをオススメします。案件全てに同じ考えは通用しなくても、どのくらいの粒度、どのくらいのカテゴリ感で管理しているかの参考になりますよ。

bulma/sass at master ? jgthms/bulma

bootstrap/scss at v4-dev ? twbs/bootstrap

スキルレベルによっては共有が難しそう

Pug記法がわからない、という点では、今まで見たことがない新しいものである以上仕方ない部分があります。

また、Pugで使うプログラミング的表現は「if」「else」「case/when」「include」などで、プログラムを書いているというよりは英語でコメントをしているというものに近いです。ですので、すでにJavaScriptの知識がないと使えないというものではありません。「言語化」という目的を忘れずに、なるべくシンプルを心がけましょう。

どうしてもシンプルにできない場合、そもそもデザインが複雑すぎるという可能性もあります。言語化をしているときに、もっと妥当なデザインアプローチが見つかるかもしれません。デザイナーと相談してみることも一つの解決方法です。

他人の書いたPugがわからない問題

なまじプログラミングができちゃう人ががっつりプログラミングしてしまうということはあります。それが必要なものであればいいのですが……

今回のセッションは、プログラムを書いてカッコよくやろうという話ではありません。例えば二つパターンがあったときに、ただ単に二つのファイルを渡すよりも、一つのファイル内で「こういうときはA、こういうときはB」と書いた方が、よりコードに「意味」が出てきていいよね、というお話でした。ですので、書くときは「プログラミング」というよりは「言語化」という部分を意識してほしいと思います。

PHPを中にかけるか

YesかNoかでいうと、Yesです。PHPを「プレーンテキストとして書き出させる」ことでHTML内にPHPを書き出すことができます。PHPで分割したファイルの挿入も繰り返しもできてしまうので、PHPが使える環境でPugで頑張る必要はないかと思います。

Plain Text ? Pug

pugでPHPを無理やり使うための4つの技 | q-Az

コンパイルの短縮

gulpをお使いでしたら、gulp-changedやgulp-cachedを用いることで一部改善できます。

sindresorhus/gulp-changed: Only pass through changed files

contra/gulp-cached: A simple in-memory file cache for gulp

全ページに挿入されているファイルの変更を行なった場合はやはりページの数だけコンパイルする必要があります。こればかりはコンパイラの処理速度に依存してしまうためです。しかし、素のHTMLで同じことをしようとした場合に人力でそれよりも早く処理を終えることができるのか？検索置換を行なった場合、正確に完了できるのか？ということも加味すると、割り切ってもいいのではないかというのが個人的な意見です。

jsonでデータを連携させる際のうまいやりかたが知りたい

Pug及びNode.jsはサーバサイドの技術です。テンプレートとデータに分けて考えるやり方は独自性のある考え方ではなく、サーバサイドですでに行われている手法です。ですので、データベースやAPIの設計論を参考にしてみてください。オープンソースなWordPressテーマの作りを眺めて見るのもよさそうです。いろいろなデザイン（＝設計パターン）が見えてきますよ。

また、デザインでいうと、インフォメーションアーキテクチャの考え方が流用できる部分もあります。いろいろな世界の「情報の取り扱い方」を組み合わせて、プロジェクトに適切なデータ設計を行なってみてください。

その他

div使いすぎ

ごめんなさい、アンチパターンでした。私はインブラウザデザインでのワイヤーフレーム作成を行うことが多く、その際にCSSフレームワークの「Bulma」を使っています（全ソースコードを写経した経験もあります）。プロトタイピング目的ではdivで十分なので、ついあの場で手癖が出てしまいました。もちろん、実装ではちゃんとやってますよ！

Bulma: a modern CSS framework based on Flexbox

[宣伝]古いバージョンですが、コードリーディング本もあります。

Bulma Code Reading ~ フレームワークから学ぶCSSテクニック - nayucolony - BOOTH

Butjon

Microsoftの「Fabric」の紹介で触れた「Butjon」

Home - Office UI Fabric

よくよく考えると、Microsoftのプロジェクトでそんなことあるか？と思い、あの後、GitHubで次のようなプルリクエストを投げつけてみました。

replace butjon / button by nayucolony ? Pull Request #3309 ? OfficeDev/office-ui-fabric-react

返ってきた回答は「ディセンダーを含めて見た目をチェックをするために意図的にいれています」というような内容でした。ディセンダーとは、文字のベースラインを下側にはみ出す部分です。「j」「g」なんかがそうですね。知りませんでした。

これをみて、また一つ知識が増えました。皆さんも「ディセンダー」を意識してみてください。

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、伊原 力也さん（freee）+太田 良典さん（ビジネス・アーキテクツ）の『多様なユーザーニーズに応えるフロントエンドデザインパターン：ベーシック編』セッションのスライドなどを公開します。

• Googleスライド 実際のプレゼンで使用したスライドです。プレゼンテーションモードにしていただくと、コード右下の再生ボタンからスクリーンリーダーの読み上げ音声を聞くことができます
• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

ご挨拶

ご参加ありがとうございました！マークアップが体験に大きく影響するということをお伝えできたなら嬉しく思います。少し手を掛けるだけでも対象ユーザーの範囲を飛躍的に増やせる可能性があるのが、Webフロントエンドの醍醐味です。それこそ、divをbuttonにするだけでも。ぜひ「規則を守る」という考え方から、「コードで体験をデザインする」という考え方にスイッチしてみましょう！またお会いできる日を楽しみにしております。

スライド

• Googleスライド
  • 実際のプレゼンで使用したスライドです。プレゼンテーションモードにしていただくと、コード右下の再生ボタンからスクリーンリーダーの読み上げ音声を聞くことができます。

告知

書籍　

• インクルーシブHTML+CSS & JavaScript
  • 本セッションで取り上げた本です。11月5日夜の時点では、amazonの在庫状況は特に問題なく、すぐに発送されるようです。
• コーディングWebアクセシビリティ
  • インクルーシブ本と同じ、ヘイドン・ピカリングさんの前著です。こちらはWAI-ARIAの入門書として、よりマークアップに特化した内容になっています。
• デザイニングWebアクセシビリティ
  • 戦略、要件定義、設計、デザインといった、Webデザインのワークフロー全体でアクセシビリティに取り組むための具体的なアプローチを紹介しています。

イベント登壇

• 11月9日（木）
  • Web・アプリとカラーユニバーサルデザイン
  • 配色をテーマにしたイベントです。動画配信を予定しています。
• 11月11日（土）
  • Japan Accessibility Conference
  • 国内最大級のアクセシビリティカンファレンス。初心者向けから上級者向けまで幅広いラインナップでお届けします。
• 11月22日（水）
  • GitHub＋OmegaTによる翻訳書制作ワークフローの可能性と課題
  • インクルーシブ本監訳の舞台裏を紹介する、ちょっとマニアックなセッションです。

あのTシャツ

• Use button, not div Tシャツ

質問へのご回答

アンケートやTwitterでお寄せいただいた質問や感想に回答します。

インクルーシブデザインという言葉について

質問・感想

• 「インクルーシブ」って言葉、単語に「？」と思いましたが、中身はアクセシビリティの話だったのでがっかりしてしまった…。（セミナーの内容に、ではなく、また「新しい名称」作り出したのか…という意味です）
• インクルーシブデザインっていろんな立場や（身体的）能力の人と一緒になってデザインをしていこう……という話と思っていたけど普通にアクセシビリティなのか……

回答

「インクルーシブデザイン」という言葉の一般的な意味はその通りで、極端な立場に置かれたユーザー (リードユーザー) と一緒にデザインをしていくようなことです。とはいえ本書ではもう少し広い意味で使っています。このあたりの話はAccSellポッドキャスト第122回でお話ししていますので、興味がありましたらお聞きください。

また、原著者のヘイドンさんが、なぜわざわざインクルーシブデザインという言葉を選んだのかを説明しているブログ記事もあります（英語です）。なぜアクセシビリティではなく、UXではなく、バリアフリー的な話ではなく、ユニバーサルデザインではなく、インクルーシブデザインという言葉を選んだのか。より詳しく知りたい方はこちらを読んでみると面白いかもしれません。

グラフィックデザイナーの定義

質問・感想

• グラフィックデザイナーのたとえは少し悲しいです
• グラフィックデザイナーは、実装のことはまったく考えていない人種……（と、本の中で定義されているのか）

回答

すみません。><
本書では「グラフィックデザイナー」を「コードが書けるデザイナー」の反対概念として言っていますが、もちろん、グラフィックデザイナーと呼ばれる人の全てが実装のことを全く考えていない、というわけではありません。ビジュアルデザイン専門であっても、実装のことやアクセシビリティのことを考慮したデザインができる人はいますし、そうであることが望ましいです。

マークアップ以外の職種

質問・感想

• エンジニアもさることながら、PM、ディレクター、デザイナーがちゃんと聞くべき内容だと思いました。
• コーダーだけでなくデザイナー、ディレクターも考えていくべきと思いました。
• そろそろ現場でがんばってなんとかするみたいなのは限界だと思うので組織として…みたいな話を希望します

回答

高津戸さんのCSSのセッションで、マークアップの現場に降りてきたときに手遅れになっているという例が紹介されていましたが、これはアクセシビリティにも良くあてはまる話です。上流からアクセシビリティに配慮しておくことが重要です。

Webサイト制作の全工程でアクセシビリティを考えてほしい、ということで書いたのが「デザイニングWebアクセシビリティ」という本です。これをデザイナーやディレクターの方に読んでいただけると嬉しいです。

組織にWebアクセシビリティの考え方を浸透させる取り組みについては、サイボウズの小林さんのお話（あなたの言葉で伝えるWebアクセシビリティ）が参考になります。

アクセシビリティとコスト

質問・感想

• どこまでインクルーシブを考慮するか、クライアントにどう説明するか（お金をもらうか）
• アクセシビリティのことをしっかり考えてマークアップした方がよいのは理解できるが、会社には「予算そんなにないから、そこまでやらなくていいよ」と言われるのが想像できる。案件によるのかな。
• アクセシビリティは売り上げに直結しないし、説明したり勉強会をやっても「今回はそういう人対象外だから」と言われがちです。SEOに絡めたほうが興味を持ってくれる気がしますよー（やること似てるし）
• アクセシビリティに工数が出せない場合がとても多いと思うのですが、どの程度の優先順位になるのでしょう？対象ユーザーが多い場合のみかなあ…
• アクセシビリティ対応って実際に現場ではどれくらい対応されているのでしょうか。その場合、別で金額を取っている？んですよね。

回答

今回のセッションでは、divで実装された「賛成」ボタンに対して、アクセシビリティを担保しようとしてあとからさまざまな機能を付け加えようとする例をご紹介しました。このように、望ましくない実装に対して後からアクセシビリティを担保しようとすると、大きなコストがかかることがあります。

それに対し、最初からbutton要素を使えば、それだけでもうキーボードアクセスやスクリーンリーダーへの対応ができているということになります。この場合、追加の作業は何も必要ありません。

このように、後から対応しようとすると大きなコストがかかりますので、最初から考えておくことが重要です。

ただし、動画やPDFなど、明らかにコストがかかるコンテンツも存在しますし、試験を実施すればその分はコストがかかります。このあたりの話は、書籍「デザイニングWebアクセシビリティ」の1章で触れていますので、興味ありましたら参照していただければと思います。

アクセシビリティをやらせてもらえないという悩み

質問・感想

• アクセシビリティについてはまだまだ実装されているサイトは少ないと思います。今後本当に普及するのですか？
• ワクワクするけれど、今の仕事では求められていない、やりたい

回答

アクセシビリティへの取り組みが必要な案件は近年増加している印象です。特に大規模案件や公共系の案件については、現在ではRFPにアクセシビリティ要件が含まれていないことのほうが珍しいように思います。

小規模案件では求められないことも多いと思いますが、そのような場合は要件定義でこちらから「今回はこのレベルまでの対応をします」と提案してしまうのもありです。逆に、要件定義で「アクセシビリティ対応は行わない」と明確に決めることもあります。決めておかないと後で問題が起きた際に費用内での追加対応を求められ、トラブルになることがあるからです。

このあたりの話も、書籍「デザイニングWebアクセシビリティ」の2章で触れていますので、参照していただければと思います。

おすすめのサイトは?

質問・感想

• お二人がインクルーシブデザイン的に一番いいと思うサイトを教えていただきたいです
• インクルーシブデザインが上手にできているサイトが日本のサイトにあるなら教えてほしいです

回答

サイトによっては「ウェブアクセシビリティ方針」を掲げて、自らの取り組みをアピールしていることがあります。方針を掲げているサイトはアクセシブルであることが多いので、それを見ると参考になるでしょう。(ただ、自治体系のサイトは方針を掲げていても正直それほど良くないことが多い印象です。民間企業のサイトを見たほうが良いと思います。)

また、私たちが所属しているウェブアクセシビリティ基盤委員会では、公的機関や一般企業における、ウェブアクセシビリティ方針策定と試験結果表示の実態調査を定期的に行っています。こちらも合わせてご覧ください。

その他、私の周りでアクセシビリティ文脈でよく話題に上がる企業や団体のウェブサイトをご紹介します。これらの企業や団体はアクセシビリティに取り組んでいくことを明言しており、そのサイトやプロダクトの状況にも注目していきたいと思っています。

• ChatWork
• サイボウズ
• サイバーエージェント
• アルファサード
• KDDIウェブコミュニケーションズ
• GREE
• ヤフー
• YAMAHA
• キヤノン
• NEC
• 富士ゼロックス
• 神戸市
• 東京オリンピック
• Apple
• Microsoft

現場が大変

質問・感想

• 視覚的に見えない部分までがんばるのは正直きつい…
• ここまで考慮しつつ実装のスピードを落とさない方法に苦心しそうと思いました

回答

現場の方にお勧めなのは、実際にスクリーンリーダーで一度アクセスしてみることです。そこまで時間はかかりませんし、これだけで多くの問題に気づくことができます。WindowsならNVDAが無料で利用できますし、iOSやOS XであればOS標準のVoiceOverが利用できますので、費用もかかりません。

最近はコンポーネント単位で実装することが多くなっていると思いますが、コンポーネントを実装するたびに、一度スクリーンリーダーでアクセスしてみると良いと思います。

スクリーンリーダーとその他の支援技術

質問・感想

• スクリーンリーダーの利用率はどうやって調べられるのか？
• スクリーンリーダー以外に考慮すべきツールはありますか？
• 本セッションはスクリーンリーダーに特化していましたが、それ以外はどんなものがあるか知りたかったです

回答

さまざまな状況の方がWebを利用するために使うツールを「支援技術」と呼びます。支援技術の代表格はスクリーンリーダーですが、それだけではありません。画面を拡大するツール、点字ディスプレイ、マウス操作を支援するツールなど、さまざまなものがあります（ちなみに、茗荷谷にある東京都障害者IT地域支援センターというところでは、こういったさまざまな支援技術の常設展示を行っているそうです）。

スクリーンリーダーの利用率をサイト側で調査するのは難しいです。スクリーンリーダーはブラウザの表示結果を読み上げるため、サイト側のログには通常のブラウザのUser-Agentが記録され、スクリーンリーダーを使っているかどうかはわかりません。

SVG

質問・感想

• 図版、表などもSVGで書いたほうがアクセシビリティ的にはよいのか？
• SVGスプライトの運用方法は皆さんどうしていますでしょうか？
• SVGスプライトにdisplay:noneを使うとグラデーションが反映されないので別の方法を使ったほうがよいと思いました

回答

SVGにすればアクセシブル、という単純な話でもありません。基本的には、テキストだけで必要な情報が伝わるようにする必要があります。そのテキストをSVGの中に入れるか、HTML側に入れるかという話になりますが、これは実際のブラウザやスクリーンリーダーの実装状況に照らして判断する必要があります。基本的に、img要素でSVG画像を参照しても、SVG内のテキストは読まれません。インラインのSVGであれば読まれることが多いですが、ブラウザやスクリーンリーダーによって処理が異なります。

表であれば、基本的にはHTMLのtable要素を使ったほうが良いでしょう。tableはアクセシブルでないという印象があるかもしれませんが、スクリーンリーダーは表を読むための専用のモードを実装していることが多く、行見出しや列見出しを読んでくれるなど、さまざまな支援があります。

SVGスプライトの運用は、アイコンの数が少ないときは良いのでしょうが、増えてくると管理がとても大変になります。illustratorのファイルを管理する必要もありますし、このあたりはみなさんそれぞれ工夫されているのではないかと思いますので、私も皆さんのノウハウをお聞きしたいところです。

参照される側のSVGスプライトにdisplay:noneを指定すると、Android4系の環境でグラデーションが反映されないという問題があるようです (他にも問題が起きる環境があるかもしれません)。ここで紹介したものは著者がおすすめする実装方法のひとつにすぎませんので、状況によっては別の方法を選択するほうが良いこともあります。

今回ご紹介した中には、VoiceOverでうまく読まれない事例もありましたね。さまざまな実装方法があり、どれかひとつが「正解」というわけではありませんので、状況によって適切なものを選ぶようにしていただくと良いと思います。

アイコンの実装

質問・感想

• <i>タグでアイコンを置くのはどうでしょうか？

回答

i要素が支援技術で特別扱いされることはありません。つまり、divやspanと同じ扱いだと考えてください。i要素にテキストを入れればふつうに読まれますし、中身が空でもaria-labelをつけて読ませることもできます。CSSのcontentプロパティでテキストを追加した場合も読まれます。

アイコンをどのように実装するかがポイントで、さまざまな実装方法があり、それぞれにメリットとデメリットがあるのは今回お話しした通りです。i要素を使う場合、contentプロパティを使ってアイコンフォントを入れる実装になっていることが多いように思いますが、その場合もやはり、今回ご紹介した豆腐の問題が起きることがあります。

ボタンとフォーム

質問・感想

• <button>はformタグが必要なので<a>とかそれこそ<div>でマークアップしていたのですが今後はbuttonを使うようにします
• button type の初期値 submit だったはずなので、type=“button” 指定した方が良かった気がする

回答

実は、button要素はform要素のないところでも使えます。今回ご紹介した本の前著にあたる「コーディングWebアクセシビリティ」の2章で説明されていますので、興味がありましたらご覧いただければと思います。

buttonのtypeの初期値はsubmitです。フォーム送信をしない場合は、type=buttonを明示的に指定したほうが良いですね。

buttonとinput要素

質問・感想

• <input type="button>と<button>でも使い分けたほうがいいものでしょうか？
• buttonタグを積極的に使ってると、プログラマーから、アンカーか input type=“button” に変えてってよく言われてた

回答

button要素はHTML4で登場した比較的新しい要素です (といっても、20年の歴史がありますが……)。

昔はbutton要素がなく、<input type=button>を使っていましたが、ボタンの見た目が制御しにくいという問題がありました。ボタンの見た目を変えたい場合には<input type=image>を使って画像をボタンにするということも行われていました。button要素であれば、中にさまざまな要素を入れることもでき、スタイルの制御も自由が利きますので、最近はbutton要素を使うことが多いかと思います。

ただ、バックエンド側のフレームワークを使っている場合、リンクやフォームコントロールをフレームワークの機能で動的に生成しなければならない場合があります。この際、フレームワークの機能がbutton要素に対応していないと、aかinputにせざるをえないことがあります。これはシステム側の制約ですね。

このような場合には、<input type=button>や<input type=submit>を使っても問題ありません。これらもれっきとしたボタンですので、キーボードでフォーカスが当たる、スクリーンリーダーで「ボタン」と読まれる、といったbutton要素と同じ特徴を備えています。

buttonとa

質問・感想

• ボタンはdivより<a>で組んでしまうことがよくあるのですが、<a>もあまり良くないのでしょうか？
• ボタンにbuttonではなくaタグを使うことに対してはどうですか？
• カーソルがポインターになるので<a>タグをボタンに使うことがありましたが、<button>を意識して使ってみようと思います
• 見た目buttonでもリンクの場合はa要素でお願いしますね

回答

今回はご紹介できませんでしたが、実は本書にはこの議論もあります（9章が該当します）。a要素はキーボードフォーカスが当たりますが、あくまでリンクですので、スクリーンリーダーにはリンクとして扱われます。見た目がボタンでも、機能がリンク（つまり別ページに遷移するもの）であればa要素を使ったほうが良いでしょう。なお、ボタンにマウスカーソルを載せた際にポインター（指）にすべきかどうか、という議論も同じ章で語られていますので、ご参考ください。

その他マークアップの質問

質問・感想

• 見出しの前に出てくる（日付などの）マークアップのしかたが知りたかったです

回答

今回はご紹介できませんでしたが、本書では解説されていますので、ぜひご覧ください。個人的には、可能であれば純粋に日付を見出しの後ろに置く (マークアップだけでなく、見た目上も後ろに置く) のが良いと思っています。

質問・感想

• aria-hiddenじゃなくhiddenなんですね

回答

aria-hiddenはWAI-ARIAの属性、hiddenはHTML5の属性です。似ていますが意味合いは異なり、aria-hiddenが見た目に影響しないのに対し、hiddenは見た目上も非表示になります (display:noneを指定した時と同じような挙動です)。

質問・感想

• マークアップに正解がないのか……

回答

今回はご紹介しませんでしたが、本書で著者のヘイドンさんは以下のようなことをおっしゃっています。

HTMLの構造は、自然言語の構造と同じように、ニュアンスで判断するべきです。役立つのか、じゃまなのか、少なすぎるのか、多すぎるのかといった観点です。

あることを表現する言葉が一つでないように、ある構造をマークアップする方法も一つではなく、どれが正しい、どれが間違っている、ということはないというのが著者の考えです。ただし、わかりにくい、伝わりにくいということはあります。マークアップの方法によって、伝わりやすくなったり、より多くの人に伝わるようになったりするわけです。この点も言葉と同じですね。

その他

質問・感想

• 八卦の「天」は、「乾」がベターな表現です（副業占いの観点より）

回答

ありがとうございます。勉強になります。占いには詳しくなく、八卦と言われても良くわからないというのが正直なところでした。よろしければ詳しく解説していただけると嬉しいです!

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、前川 昌幸さん（イー・ネットワークス）の『コーダーの前仕事、後仕事』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「コーダーの前仕事、後仕事」のセッションを行った前川です。ありがとうございました。

内容はTipsやツールの紹介でしたが、何かひとつでも明日から使えるものがあれば嬉しいです。
また、セッション中からTwitterで、みなさんが利用しているツールやTipsをツイートしてくれました。ありがとうございます。
全てを拾ってはいませんが、いくつか紹介します。

• MAMPの有料版、MAMP Proについて @sivacchi さん
• node.jsのバージョン管理について @turusuke さん
• ウェブベースのエミュレーター、Browserstack（ https://www.browserstack.com/ ）について @AVELWP さん
• Photoshopでの書き出し設定について @crema さん

今日の他のみなさんのセッションのように、ひとくちに「コードを書く」といってもさまざまな方法論やツールがあるように、その前後の作業でも同様にさまざまな方法論やツールがあります。

私のセッションがきっかけになって、自身の作業の棚卸しや周りの人たちとの共有などしてみてください。

【告知：書籍】

Webサイト、これからどうなるの? キーワードから探るWeb制作の未来像
こもりまさあき、栄前田 勝太郎、坂上 北斗、塚口 祐司、前川 昌幸、松田 直樹 共著
エムディエヌコーポレーション (2017/9/20 発売)
価格（本体2,000円＋税）

Amazonでの購入

告知：イベント

WCK Meeting Vol.56「キーワードから探るWeb制作の未来像」
高知で上記の書籍出版に関連したイベントを行います。
開催日時 2017年12月2日（土）13:30 開場
会場 高知市文化プラザ　かるぽーと　9F 第1学習室

「コーダーの前仕事、後仕事」のセッションを行った前川です。

アンケートでのコメント、質問

アンケートでのコメント、質問についてまとめます。

Local by Flywheel

Local by Flywheelについて、「使ってみます」というコメントが多かったです。導入の際には以下のエントリーが参考になります。

WordPressのローカル環境のためのGUIツールLocal by Flywheelが便利 - Capital P

Windowsでは、batファイルではなくcmdファイルが最近の流れ?

というコメントがありました。ざっと調べてみたところ、大きな違いは無いようですが、もしこのあたりアップデートするようであれば、どこかでアウトプットします。

Windowsのアプリも紹介してほしい

今回紹介したうちで、VirtualHostXとFluid BrowserはMacのアプリでした。すいません。
Local by FlywheelやGenymotionなど他のアプリやツールは全てWindowsでも使えるものですので、活用してください。

Photoshopの書き出し形式の「すべてのスケール」使うのキライですか？

defaultレイヤーでの作業に慣れきっているので、ほぼ使っていないです（キライではないです）。
結果同じ書き出しになるので、性に合う方を使うのが良いと思います。

乗算でパーセント指定された時に困っています。解決方法はありますか？

すいません、そのケースは遭遇した経験がなく。なにか見つかれば共有します。

会社では gyazo.com を使っています。便利です。

これでフィードバックの指示を作成されているデザイン会社さんと仕事しています。確かに便利ですね。ありがとうございます。

Gyazo

WindowsでPC、モバイル一通り利用できるエミュレーターを知りたい

クラウド型のエミュレーターのBrowserstackがカバー範囲も広いので良いかもしれません。

デフォルトで利用できるApacheで良いのでは？

私もその意見には同意する部分も多く、以前はMacに搭載されているApacheを利用していました。
ただ、並行した案件が多くなると管理が煩雑になってきたので、VirtualhostXなどを利用するようになったので、状況によってはツールに頼るのも選択肢のひとつと考えています。

XAMPPを使っていて、Browsersyncを使うことはできるのでしょうか？

できます。BrowsersyncのProxyオプションを利用すれば、Browsesync越しにXAMPPの出力を表示することができます。
（このやり方は弊社でも行っています）

Windows/Macが混在する環境の場合、違いをうまく埋める方法はありますか？

node.jsなどを利用するツールの場合は、ほぼほぼどちらでも動作するので特に気にする必要はないと考えています。
ツール類は確かにいろいろ変わってきますが、環境よりも成果物に差が出ないようにフォーカスして考えていくとよいのでは、と考えています。
なので、あくまでも弊社の場合はエディターなど利用するものは結構違っていますが、その違いを埋めることについてはあまり気を使っていません。

画像をきれいに軽量化して書き出すおすすめの方法はありますか？

私は書き出した後にImageOptimを利用して最適化しています。WindowsだとFileOptimizerなど似たようなツールがありますので、そちらを活用してみてください。

アイコンフォントやCSSスプライトの生成、更新時の管理方法が知りたい

アイコンフォントについては、生成するgulpを作成したことがあります。

https://github.com/enetworks/iconfontcreation。

このあたりが参考になれば。

CSSスプライトに関してはあまり最近使っていないので、すいません。目新しい管理方法などは持っていません。

対象ブラウザの決定はどのようにしていますか？提案していますか？言いなりですか？

提案できる案件であれば提案するのですが、そうでない状況の場合は、ほぼ抵抗せず、言いなりでやっています。

最近Sketchを使うことが多いですが、制作会社ではどうなのでしょうか？

個人的にSketchは所有していて、利用することはありますが、案件では弊社の場合は無いです。商流など環境的要因が大きいので、制作会社でも積極的に採用されているところはあると思います。

nodebrewは利用しませんか？

以前は利用していましたが、今年に入ってからnodenvに変わりました。

ルートパスってなんですか？

href="/hoge.html"という形で、「/」から書くファイルの指定です。説明不足失礼しました。

Photoshopでレイヤーマスクだとサイズの変更や確認がやりづらい、なにか良い対応方法はないか？

いまはこれと言った対応方法は持っていないので、なにかないか探してみます。

2017年9月30日（土）ベルサール神田 イベントホールで開催したCSS Nite LP53「ワイヤーフレームとビジュアルデザインの間の暗くて深い闇」のフォローアップとして、林 大輔さん（楽天）の『「闇」をなくすためのコミュニケーションとユーザーテスト』セッションのスライドなどを公開します。

• スライド（SlideShare）
• 音声
• 動画

フォローアップメッセージは、イベント開催直後（2017年10月）の時点のものです。

メッセージ

「『闇』をなくすためのコミュニケーションとユーザーテスト」を担当しました林大輔です。

今回は楽天トラベルの実例を交えながら、インハウスの制作ワークフローの一例や、コミュニケーションとユーザーテストについてお話ししました。

• ワイヤーフレームの立ち位置、PM（ディレクター）とデザイナーの役割を明確にしておく
• ディレクターはデザイナーに案件の背景や課題を伝えて欲しい
• デザイナーは案件の背景や課題し、デザイナーの視点でベストは何か？を考える
• ユーザーテストによって得られるデータから、根拠のある議論が可能になる
• プロジェクトの初期段階（ワイヤーフレーム、デザインを作っている最中）からユーザーテストを実施することで、精度を上げることができる

案件のスケジュールや予算、会社規模など、様々な要因によりすぐに取り入れることが難しいこともあるかもしれません。もし、取り入れられる案件やタイミングがあった際は、私の話を思い出していただけると幸いです。

アンケートでの質問への回答

被験者が社内の人間だとネットリテラシが高い人に偏らないか？

偏ります。ここは、被験者を正しく集めるか、スピード感を持ってテストをするかのトレードオフだと考えています。ネットリテラシが高い人にテストをしても、改善点はそれなりに発見されます。
同様にオンラインのユーザテストサービスも、被験者がテスト慣れしているなどの偏りはあります。

ワイヤーフレーム作成段階でのテストってどうやるのでしょうか？

ペーパープロトタイプでテストをするとは、具体的にどういうことをされるのでしょうか？

本編で口頭でお話しした「ペーパープロトタイプ」という手法が有効です。
ペーパープロトタイプについては下記のサイトを始め、いくつか参考になる記事があります。
http://fladdict.net/blog/2013/12/paper-prototyping-1.html

オススメのUTサービスでオススメのものはありますか？

日本では本編でも紹介した「ポップインサイト」「UIscope」が有名だと思います。

ユーザーテストを省略することはありますか？

小さな案件・改修でも100%テストしていますか？

ユーザーテストをすることを強く推奨していますが、実施するかしないかは、PMやデザイナーの判断に任せています。

仕様書はPMがひとりで作るのか？

改善系のプロダクトが多いので、1人のPMで作ることがほとんどです。もちろん規模によって2人、3人でというプロダクトもあります。

ワイヤーフレームはPMが修正するのでしょうか？

ワイヤーフレームについては、デザイナーがデザインに着手した後は、多くの場合修正されません。最終的な仕様書にはデザインが貼られるカタチになります。

仕様書の課題はどのように決まるのか？

課題があって、はじめて案件・プロダクトになります。例ですが「ここの使い勝手が悪い」「〇〇というユーザー層にリーチできていない」という課題に対して、PMがどのように解決していくかを考えていきます。

お知らせ

楽天トラベルではUIデザイナーを募集しています。
ご興味持たれた方、ご応募お待ちしてます！

• トラベル事業 UIデザイナー

また、楽天トラベルのPMシニアマネージャー・齊藤満のインタビュー記事が掲載されています。PMに興味を持たれた方は、ぜひご一読ください。

• 「理想を追え、世界を見よ」 楽天トラベル 齊藤満が語った、PMこそ理想主義者であるべき理由
• 18年間プロダクトマネジメントを生業にして来た男を支える「5％の光」とは?楽天トラベル齊藤満氏の流儀【及川卓也のプロダクトマネジャー探訪】

2017年9月30日（土）ベルサール神田 イベントホールで開催したCSS Nite LP53「ワイヤーフレームとビジュアルデザインの間の暗くて深い闇」のフォローアップとして、益子 貴寛さん（まぼろし）、松田 直樹さん （まぼろし）の『ワイヤーフレームに必要な視点とワークフローの再考』セッションのスライドなどを公開します。

• スライド（PDF）
• 音声
• 動画

フォローアップメッセージは、イベント開催直後（2017年10月）の時点のものです。

メッセージ

益子さんから

セッション4「ワイヤーフレームに必要な視点とワークフローの再考」を担当した益子貴寛です。

各登壇者からの「コミュニケーション」や「合意」という共通のメッセージがコインの表側で、クライアント（社内の担当者であれば事業責任者）の納得感を高めることがコインの裏側。両方をきちんとケアすることが「よい仕事」なんだ。そんな力強さをしっかりと感じたイベントでした。

クライアントの中でも、担当者は「完成度」を、決裁権者は「納期」を、というように、求められる満足が異なるケースもあります。こういった複数の満足を支えるひとつのカギであり、初動段階でのコミュニケーションや合意の蒸留物がワイヤーフレームだと考え、「たかがワイヤーフレーム、されどワイヤーフレーム」という気持ちで仕事をしています。そんな言外の思いが、みなさんに伝わったのなら幸いです。

以下、アンケートでいただいた質問に回答します。

Q1：写真撮影を実施するタイミングは、全体のワークフローの中でどのあたりがよいですか？

A1：私は、サイトマップをひととおり作り、主要ページ（数ページ分）のワイヤーフレームを描いたら、撮影の日程調整に入るパターンが多いです。つまり、設計作業のわりと初期の段階で動き出す感じです。撮影の実施（クライアント側の日程とカメラマンの日程が合うタイミング）まで、早くても2週間、遅ければ1か月くらいは先になるので、それまでに設計作業もだいぶ進んでいるはずで、当日までに撮影項目やそれぞれの仕上がりイメージを決めておくのはむずかしくないでしょう。

外観、社内や社外の様子、イメージカット（キービジュアルで使う雰囲気重視の写真）などであれば、それほど入念な準備はいらず、長くても2時間くらいの撮影で済むはずです。撮影費もそれほどかからないと思うので（たとえば5万円前後など）、ストックフォトなどを使うよりも、このようにオリジナルの写真を用意するとよいでしょう。けっこう、「撮影予算が取りにくい」という話を聞くのですが、そこはきちんとクライアントや社内に認めてもらう（見積り項目として堂々と立てる）ことが大切です。

もし予算が出にくければ、制作会社内や知り合いで（プロまでは当然いかなくても）撮影が上手な人に頼む方法もあります。あるいは、クライアントの社内で撮影が上手な人を探してもらい、写真を支給してもらう方法もあるでしょう。とにかく、「オリジナルに勝る素材はない」という意識が大切です。

一方、採用サイトで社員インタビューをともなう場合、プロダクトサイトでブツ撮り（製品の説明写真）の点数が多い場合などは、きっちりとスケジューリングし、数日に分けて実施することもあります。このような案件は、撮影費をきちんと予算取りできるはずで、その点は大きな問題はないと思います。

Q2：コピーライティングなどに関する作業について、見積書ではどのようにしていますか？

A2：きちんと項目を立てます。私は「コピーライティング／文章校正費」（素材準備段階の費用）や「エディトリアル費」（テストサイトを作るまでのブラッシュアップの費用）といった項目名を使っています。コピーや文章は、段階的に完成度を高めていくので、なかなかこれといった見積り項目を立てるのがむずかしい（工数が読めない）部分はありつつですが、まず企画や設計の段階（たとえばワイヤーフレーム）でその力や付加価値を認めてもらうことが、見積り項目の説得力を支えます。

Q3：ワイヤーフレームの完成度が高いと思いましたが、ディレクターにもデザインのスキルが必要ですか？

A3：ある程度はあったほうがよいと思います。というのも、デザイン的に完成度が低すぎるワイヤーフレームだと、アラにばかり目がいってしまい、肝心な「中身の検討」に意識を向けにくいからです。といっても、私も高いデザインスキルがあるわけではまったくなく、何とかここ数年、ワイヤーフレームの段階で、クライアントに「よし、行ける」と思ってもらえるクオリティにしようと心がけてきた積み重ねとして、お見せしたようなワイヤーフレームに行き着いた、という感じです。

Q4：優柔不断なクライアントのときは、どうしていますか？

A4：まず、「私たちの仕事は、提案である」という意識が大切です。クライアントが優柔不断であれば、こちらからどんどん提案し、リードして進めていきましょう。

このような前提がありつつ、テクニックとしては、担当者だけでなく決裁権者（上長など）に打ち合わせや意思決定に加わってもらう、A案とB案から選んでもらう（選択肢を狭める。ガラッと変えるのではなく、特徴的な部分を変えるだけでOK）、フィードバック期日をきちんと設定する、といったことが有効です。

そうそう、せっかくなので、とっておきの方法を教えますね。こちらが作ったワイヤーフレーム（などの中間成果物）について、「これでよいですか」「何か意見はありますか」という聞き方ではなく、「違和感がある部分はありますか」「どうしてもここは、という部分はありますか」という聞き方にすると、相手の視野を限定でき、リアクションのハードルを下げられます。公開日や納品日までタイトなスケジュールで進めなければならないときにも使える方法です。

松田さんから

以下、アンケートでいただいた質問に回答します。

Q：ワイヤーフレームはAdobe XDで作っているとのことですが、ワイヤーフレームとプロトタイピングを一緒に進めるメリットとデメリットは何ですか？

ワイヤーフレームは画面の構成要素を確定させるもの、プロトタイプは複数の画面のインタラクションを決めるためのもの、ということを前提とすれば、各画面のワイヤーフレームを作った後にプロトタイプとして画面間の関係性を検証できます。となると、複数画面の遷移において、整合性が取れているか、情報が冗長的でないか、ユースケースに適合するかなど、時系列での情報設計を行うことになります。これにより更にワイヤーフレームの精度を高めていくことが可能になります。

デメリットとしては、プロトタイピングを行うために想定されるすべての画面を用意しなければいけない点ですね。結構手間がかかります。そういう場合は手書きのプロトタイプにしてしまう方がいいかもしれませんね。

2017年9月30日（土）ベルサール神田 イベントホールで開催したCSS Nite LP53「ワイヤーフレームとビジュアルデザインの間の暗くて深い闇」のフォローアップとして、角田 綾佳さん（spicagraph）の『デザインの考え方、つくり方』セッションのスライドなどを公開します。

• スライド（PDF）
• 音声
• 動画

フォローアップメッセージは、イベント開催直後（2017年10月）の時点のものです。

メッセージ

「デザインの考え方、つくり方」を、お話しさせていただきました角田綾佳です。今回はワイヤーフレームとビジュアルデザインの間にあるすれ違いや、わたしの実例、デザインの考え方などをお話しさせていただきました。当日はみなさんあたたかく聞いていただけて、緊張しながらも思いを出し切ることができました、ありがとうございました。

アンケートでは「デザイナーがこんなに考えているなんて」というありがたいお言葉をたくさんいただきましたが、同時に「わたしも同じことを考えていました！確認できて嬉しいです！」というお言葉もたくさんいただきました。大丈夫です、みんな頑張って考えています！

アンケートでの質問への回答

デザインで使っているソフトはなんですか？

WebはPhotoshop : Illustrator : Sketchで、比率は8:1:1です（元Fireworsk100%）。印刷物はIllustrator＋Photoshopで、スライドはIllustratorで作成しています。デザインデータを納品しますので、発注元の制作会社さんからの指定が使用の理由です。

苦手なジャンルはどうしてる？

ビジュアル部分の制作の場合に限ってお答えします。例えば「装飾的なデザインが苦手」「シンプルなデザインが苦手」というようなことなら、ターゲットの好む雑誌やWebサイトを見て、「どういうところが好まれているのかな？」というポイントを探し、取り入れます（例えば写真のあしらいや、フォント、色数など）。

イラストを描くには何からすれば？

一番簡単なのは、今描いているイラストを「描けていない」と思わず、人に見せて一つでも褒められたところを伸ばすことです。「こういうイラストを描きたい」というモデルがあれば、線の太さ、色数、塗り方、デフォルメの方法など、よく観察して真似してみてください。わたしは実は手で描くのは苦手で、ベジェ曲線だといくぶんきれいに描けます、ツールの力も最大限借りましょう！

CMSのデザインの時どういう制約が出ますか？

物によりけりなので、「どういう制約が出ますか？」ということを最初に確認します。例えば、フォームのプラグインを使う、という時には「確認画面があるか」「ページ遷移するか」というようなことを確認します。なるべく労力少なくデザインを当てて欲しいので、デフォルトのデザインを活かせないか考えます（一部カラー変更のみなど）。

他のデザインメソッドを知りたい

まとめられるように、最小単位を探っているところです。わたしも知りたいので、みなさんぜひオレオレメソッドを発信してください^ ^

コンバージョンをあげられるメソッド

すみません、フリーランスということもあって、結果を事細かに知る機会が少ないのが現状です。制作会社さんから「前回はこれで下がったので、上がったので」という情報はいただきますが、案件によりけりという感じです。矢野さんのバナーくるくる会での「写真とコピー！画像内にテキストがあるのがいい」という言葉がすごく参考になりました。

どうやって見積もりを作る？

いつも難しいのですが、基本は時間工数で出しています。そのほかに* いくら欲しいか* どれくらい手戻りがありそうか* やり取りのコストこれらを加味して決めます。

ディレクターや依頼者に恵まれないのでは？

とんでもない！そんな風に聞こえていたらすみません。これまでわたしがワイヤーフレームを超えて提案できるのは、お客様とやりとりしていただくディレクターさんの苦労があってのことです。様々な案件で、区切りをつけすぎず、任せていただけるのは嬉しいことです。いつもありがとうございます！（本当ですよ）

お知らせ

2017/10/28（土） WordFes Nagoya 2017　「デザイナー＆エンジニア座談会」参加します2017/10/28（土） DevLOVE関西2017 commitment ?"何"にコミットするのか？?　「デザインを「伝える」ためにすべきこと」というテーマで登壇します

2017年9月30日（土）ベルサール神田 イベントホールで開催したCSS Nite LP53「ワイヤーフレームとビジュアルデザインの間の暗くて深い闇」のフォローアップとして、角田 綾佳さん（spicagraph）、矢野 りんさん（バイドゥ）の『コンテスト、「バナーデザインくるくる会」拡大版』セッションのスライドなどを公開します。

• 音声
• 動画

フォローアップメッセージは、イベント開催直後（2017年10月）の時点のものです。

メッセージ

矢野さんから

セッション6「バナーデザインくるくる会」拡大版 の合いの手担当、矢野です。

最後までご参加下さりありがとうございました！
メディア制作においてデザイナーは、常にユーザー視点と発注者視点の板挟み。どちらも納得、満足させなければなりませんよね。
原則的には発注側とデザイナー、ディレクター皆が｢ユーザー満足」をともに目標とすることで結果が出せるはず。
どんな時もデザイナーはユーザーを主語にしてコミュニケーションすれば良くて、ディレクターも発注側もデザイナーの力量を信じ、任せれば問題は起こりにくいはずだと各セッションを通じて思いを新たにしました。

最後に、最近めっちゃ面白かった私のデザインタスクの要件定義メモ（うちのPMが作り、ぺっ！とメール送ってきました）。
??????????????????????????????
画像A（若い人が好きそうなアーティストのライブ風景）
画像B（若い人に限らず誰でも好きそうなアーティストのライブ風景）
目標 CVR8%増
??????????????????????????????
なんだよそれwwww
ふざ（以下略）

いや、準備します。してこます。あげてやろうじゃねえか！！！そのCVRを！！！

ではまた！

アンケートでの質問への回答

コンテストの周知が足りなかったことから企画について唐突に感じたかたがいらっしゃったようです????申し訳ありませんでした。最後のセッションでしっかり時間を頂戴したのに反省です。また、リニュアル用バナーの募集という前提なら「現在」のバナーをまずちゃんと紹介すべきでは？というご意見ももっともです?????♀?

知っていたら参加したのになあ！とおっしゃってくださったかたもいらっしゃるので、運用状況をもっと改善したうえで、コンテスト形式に挑戦してみたいです（ね！角田さん！）

お知らせ

• 12月恒例のShift11今年も参加します！皆様も是非ご参加下さい
• マーケ寄りのPM職を随時募集しております...自社サービス運用に興味のあるかた是非こちらをご覧ください！！！！

角田さんから

「バナーくるくる会」出張版でお話しさせていただきました角田綾佳です。
CSS Niteの中でも珍しい取り組みの、参加型コンテストでしたが、たくさんの方に応募いただき全て紹介し切れなかったのが本当に残念です。応募作品についてはこちらにまとめました。

• CSS Nite LP53 コンテストページ

講評ではビジュアル的な話だけでなく、矢野りんさんの現場のノウハウを伺えて、大変勉強になりました。同じお題にこれだけ複数のデザイナーが取り組む、というのはなかなか機会のないことです。「なるほど、そういう解決法が」と言う発見がひとつふたつあったのではないでしょうか。ぜひこれからの制作に生かしていただきたいです。

アンケートでは、「知っていたら参加したかった」「時間があれば」と言う声もいただき、周知の甘さ・時間配分については大変反省しております。しかし、「たくさんのデザインを見られて参考になった」と言う声も多数いただきました。

今回のことを教訓に、また次回たくさんの方に参加いただけるコンテストにしたいと思います。

アンケートでの質問への回答

素材を選んでいるサイトについて

応募いただいたデザイナーさんそれぞれ、ご自身のお気に入りのストックフォトがあるかと思いますが、角田の話をさせていただきますと「Adobe Stock」を契約しています。
日々の業務だけでなく、こういったプライベートワークや、ブログのアイキャッチなど幅広く利用しています。
様々なサービスがありますが、好みの写真がありそうかけんさくしてみて、合ったものを選ばれるといいと思います。

リンク集

バナーデザインくるくる会は、どなたでも開催いただけます。会の狙いなどについてはこちらにまとめています。
もし開催いただけましたら、こちらに出題された課題などフィードバックいただけますととても嬉しいです。

• バナーデザインくるくる会GitHub

神森さんから

コンテストについて

既存のランディングページのリニューアルというお題を設け、目的と現状の課題、打ち出したい要素を提示させていただきました。また、構成に関しては、ランディングページの基本構成で構築されることを目標とし、そこで展開される項目などは既存のものを使ってかまわないという形にしました。

実際の案件においても、ランディングページのようなものであれば、この要件で制作をお願いすることが多くあります。

今回応募いただいたワイヤーフレームでは、既存のものから大幅に情報をそぎ落とし、スッキリさせていただいたり、キャッチコピーも含めてご提案いただいたりと、短い時間の中でサイトから情報を引き出し、ワイヤーフレームに落とし込んでいただきました。

またこのような機会がいただけることがありましたら、応募期間をしっかり設けた上で、開催できればと思います。

長い時間のご参加、本当におつかれさまでした。

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップを公開します。

• （1）前川 昌幸さん（イー・ネットワークス）
• （2）伊原 力也さん（freee）+太田 良典さん（ビジネス・アーキテクツ）
• （3）中村 勇希さん（トゥーアール）
• （4）久保 知己さん（まぼろし）+伊藤 由暁さん（まぼろし）
• （5）鹿野 壮さん（ICS）
• （6）阿部 正幸さん（KDDIウェブコミュニケーションズ）
• （7）大串 肇さん（mgn）
• （8）高津戸 壮さん（ピクセルグリッド）

ツイートは下記にまとめました。

• CSS Nite LP54「Coder's High 2017」 - Togetterまとめ