FRONTEND CONFERENCE 2018 に参加しました

---

2018年11月24日に大阪で開催された FRONTEND CONFERENCE 2018 に参加してきました。セッションは全13あり、半分はデザイナー向けで、半分はエンジニア向けの内容でした。私は6つのセッションを聞きました。本記事では、私が聞いたセッションに関する私なりのまとめと感想を書いていきます。

セッション概要と感想

WEBアプリを作らない選択肢

Wakai Shinichiro さん

セッション内容抜粋

「GAS（Google Apps Script）を使えば、WEBアプリを一から作る必要はない」といった内容でした。GASとは、Googleが提供してるJavaScriptをベースにしたプログラム言語のことです。読み方は「ガス」。GASは大きく分けると「Container Bound 」と「Standalone」の2種類あります。今回紹介していたのは、「Container Bound 」の方でした。

Standalone は Drive上で直接開発するのに対し、Container Bound はGoogleスプレッドシート内でコードを書いたり実行できるため、エディタの準備や開発環境の準備などは不要。さらに、バッチ処理を実装することも簡単にできる。GUI画面で設定できるのでプログラミングを初めたばかりの人でも気軽に設定できるような作りになっている。

GASでできることは、スプレッドシートとの連携／トリガー（バッチ処理など）／Webアプリ開発 など多彩。スプレッドシートの情報や関数をHTMLソース内に持ってくることもできる。

GASを使う上での注意点もいくつかある。GASには実行時間に制限があり、6分を越えるとタイムアウトしてしまう。その対策として、トリガーで処理を5分づつに分割して動くように調整することができる。しかし、トリガーは1日「6時間」、無料ユーザーは「90分」までという制限がある。対策としては、処理を軽くしたり複数アカウント使うくらいの方法しか無い...。
このように、GASには処理時間制限や1日のトリガー上限などの注意点がある。

『WEBアプリを作らない選択肢』Wakai Shinichiro さん
スライド：https://www.slideshare.net/ShinWakai/web-123853718

感想

ブラウザ上で直接開発から実行までできることに驚きました！開発環境がなくても手軽に始められるので簡単な実装ならこれで十分なのではないでしょうか。せっかくなのでこれから挑戦してみようと考えています。ググってみると結構な量の "作ってみた" 記事が出ているので私が思っていた以上に流行っているようです。しかし、GASを使う際には、一通り注意点となるところを把握しておいたほうが良さそうです。

デザイナ主導のプロトタイプ開発のススメ方

コンチさん

セッション内容抜粋

プロトタイプは時間とお金がない時にこそ作るもの。プロトタイプは、”100均で買えるもので試しに作ってみる” というイメージ。なので、やめる選択肢がある時に作成する。

プロトタイプの手法は大きく「ペーパープロトタイプ」、「モックアップ」、「コードプロトタイピング」の3種類（モックアップとは、XDなどのツールを使って実際にサイトのデザインを作ることで、一般的にはワイヤーフレームの次段階のことを示す）。これら3種類のプロトタイプにはそれぞれにメリット／デメリットがある。※詳細はスライドP18-20参照

デザイナ主導のでプロトタイプ開発をするメリットは、「クライアントを含めたチーム全員で価値観を共有できるようになること」。視覚的にプロダクトの共有ができるので、クライアントとのコミュニケーションがとりやすくなる。

デザイナーにとってプロトタイプを作成する上で障害となるのは「羞恥心」。この羞恥心を捨てるためには日頃からoutputをするのが大切。

『デザイナ主導のプロトタイプ開発のススメ方』コンチさん
スライド：https://docs.google.com/presentation/d/1jkWXM19KDCB-E8-urLsqi0KbNIh3IBczAN7JhM1Ja98/edit#slide=id._ss_A37382EF-FB1B-41EE-9B44-614EBAF3508F_s
コンチさんのブログ：デザイナーがプロトタイプを始めるときに知っておきたいこと | CONTLOG

感想

クライアントと打ち合わせをする際に、その場で簡単なデザインをipadや紙で作ってしまうというデザイナーは結構いるみたいです（私が今までデザイナーさんから聞いた話では... ）。確かに言葉だけでなく見える形にすることでクライアントさんもこれから作成していくものをイメージしやすくなります。クライアントさんの多くは「なんかいいものを作って欲しい」という期待だけでイメージがなかなかはっきりしない方が多いようです（私が今までデザイナ...省略...）。プロトタイプを作成することで、その “なんか” を引き出しやすくなるのだと思います。

個人的な話なのですが、Web業界に入ってから経験した、デザイン/コーディングのほぼ同時進行と、クライアントのヒアリングもコーディング途中によく入るという仕事の進め方に違和感を抱いていました。なぜかというと、Web業界に転職するまでは完全なウォーターフォール型の業務をしており、その考え方で凝り固まっていたようです。今回のコンチさんの話を聞いて、今私がやっている仕事の進め方に対しての違和感が解消され、今の仕事に対する理解が深まったように感じました。

綾なすCSSアニメーション

福壽卓哉さん

セッション内容抜粋

福壽さんは、Stylelint 推しだそうです（Stylelint とはCSSのコード品質管理ツールのこと）。

CSSアニメーションの良さは、すぐ試せる、ぬるぬる動く、プログラミング言語（JavaScript）を書かなくてもいいという所にある。

アニメーションの目的は下記のように分けることができる。印象的側面を先に考えがちだが、まずは機能的側面を満たすことが大切。

• 機能的側面：「認知容易性を高める」「注意を引く」
• 印象的側面（アート）：「サイトの特徴や性格を表現する」「面白さを加える」

機能的側面でアニメーションを実装する際は、何処に注目させたいのか？、ストーリ性はあるか？（ユーザーの予測から大きく外れるような不自然な動きになっていないか？）、アニメーションに依存したコンテンツになっていないか？に注意する。

印象的側面としてアニメーションを入れる際は、シンプルで簡潔な動きにする、要素を隠さない（→ 最近ページ読み込み時には要素を隠しておいて要素が画面に入ったら読み込めれるようなコンテンツが多い。イッキにページを流し見して後から必要な箇所だけじっくり読むようなユーザーもいるので、そのWebサイトがどんなサイトなのか、どんなユーザーが多いのかを考えてから実装すること。）、見ることを強制しない。

アニメーションに向くプロパティとして、「transform」「opacity」がある。この2つはブラウザによって自動チューニングされる。

アニメーション可能なプロパティ一覧：Animatable CSS properties
イージング早見表：https://easings.net/ja

『綾なすCSSアニメーション』福壽卓哉さん
スライド：https://speakerdeck.com/chalkygames123/ling-nasu-css-animesiyon

感想

お話の後半にはイージングのお話もありました。イージングする際はとりあえず ease-out をつけておけばいいかなと思っていましたが、ご紹介されていたイージング早見表を見るとたくさん種類があることがわかったので、ストーリ性を考えたイージングを付けれるようにしていきたいと思います。。。

理想のデザインプロセスについて

セッション内容抜粋

EC-CUBE4の管理画面のデザインをした経験から学んだデザインプロセスについてお話してくださいました。内容としてはコンチさんのお話にも通ずるものもありました。

理想のデザインプロセスを語る前提としてどの案件にも使えるデザインプロセスは存在しない。

デザインは「みんな」で作る。しかし、意見が言う人が増えるほど不確実性が増す。その不確実性と戦うためのキーとなるのか「リーン・スタートアップ」。アイディアをできるだけ早く形にし、学習→構築→測定 というサイクルを小さく回していく方法のこと（＝プロトタイプ型）。未完成であることを前提としてみんなでレビューし修正を重ねることで学びながら進めることができる。

しかし、リーンなデザインプロセスを全体で回していくのは現実的に難しい（それぞれの業務進捗、時間、タイミングで...）。なので、一定の短い開発ごとにデザインレビューをしていくのが良さそう。ただ、どのようにプロジェクトを進めていくのかをあらかじめチームで話あい決めておく必要がある。

『理想のデザインプロセスについて』深沢幸治郎さん
スライド：https://speakerdeck.com/witch_doktor/li-xiang-falsedezainpurosesunituitekao-eru-ec-cube-4falseguan-li-hua-mian-dezaindexue-ndadezainpurosesufalsemian-bai-sanan-sisa
ブログ：FRONTEND CONFERENCE 2018 でEC-CUBEのデザインについて話したことと長い補足 | note

感想

EC-CUBE という広く使われているCMSのデザイン設計の裏側を惜しげもなく紹介してくださいました。
このリーン・スタートアップな考え方は、XDをはじめとしたモダンなデザインツールも普及により、業界全体に徐々に広がりつつあるようです。これからはよりコミュニケーションとツール活用が重要になってくる時代になりそうですね。
深沢さんが補足資料としてブログを書いてくださっていますのでまだみてない方はぜひみてください！

タイポグラフィー・ベーシック

KITEさん

セッション内容＆感想

文字に関しての基礎知識から、DTPでのカーニング方法、CSSでできる自動カーニング方法など、文字を読みやすくするには何をどうすればいいのかを考えるきっかけとなるセッションでした。

CSSで自動カーニングするには font-feature-settings を使うことを知りました！カイトさんのスライドに font-feature-settings の設定値について分かりやすく例が載っています。

CSSで自動カーニングしても “「」” などの約物半角にはどうしても隙間が空いてしまいます。この隙間を埋めるのに、約物半角専用のWebフォント Yaku Han JP というものが使えます。

そして、レスポンシブなfont-sizeを算出する便利ツールを開発してくださいました！！
ViewportScaler(ブラウザ版)：https://ixkaito.github.io/viewportscaler/​
ViewportScaler(Scss版)：https://github.com/ixkaito/viewportscale

calcを使ってViewportに考慮したフォントサイズを指定することで、画面の大きさによってフォントサイズをレスポンシブに変化させることができます。セレクター名、画面の最大最小値、フォントの最大最小値を入力するだけで記載すべきソースコードを吐き出してくれます！

『タイポグラフィー・ベーシック』カイトさん
スライド：https://speakerdeck.com/ixkaito/taipogurahuibesituku-plus-dezainaidea

フロントエンドで作る理由

後藤知宏さん

セッション内容＆ほぼ感想

バックエンドばかりやっていないで、SPA制作をやってみよう！というセッション内容でした。セッション中に「SPA(Single Page Application)」という言葉がなんども出てきましたが、聞いたことがなかったので調べてみました。

新しい技術を取り入れる時、「なぜ取り入れるのか？」「取り入れてどうするのか？」を考えるべきだとお話されていました。新しい技術を業務に取り入れるとなると学習コストやミスが増えてしまう懸念があるためなかなか取り入れていくのが難しい企業は多いと思います。もし「これは業務でやりたい！」と思った時、なぜ？と、どうするのか？を考えればおのずと取り入れるべきかそうでないかが見えてくるのだと思いました。

『フロントエンドで作る理由』後藤知宏さん
スライド：https://speakerdeck.com/mikakane/hurontoendodezuo-ruli-you

最後に

アンカンファレンスの方もがっつりセッションをしていたようです。あまり聞けなかったのですが、モリサワの社員さんが、Webフォントについてお話されていたりしました。UD新ゴの多言語化 をした Clarimo UD というフォントを2018年に新しく出したお話などをされていたようです。

懇親会にも参加しました。LTを聴きながら、普段交流のない方達とお話ししました。朝から夜まで勉強になる＆楽しい時間を過ごすことができました！！ありがとうございました！

---