ラック
Home > CMS > 記事 > 2016年9月 > WordCamp Tokyo 2016参加レポート

WordCamp Tokyo 2016参加レポート

カテゴリ: WordPress

目次

全体の概要

  1. WordCampとは?
  2. 全体の感想

セッション

  1. CMSとしてのWordPress - WordPressで管理するランディングページ -
  2. Google 検索モバイルトレンド: モバイルサイトを AMP でもっとサクサク高速に
  3. デザイナーが効率よくテーマ作成を進めるには? デザインから WordPress のテーマ作成のワークフローを見直す
  4. WordPressでも意識したいアクセシビリティ ~「優しいウェブサイト」作りをはじめよう~
  5. レスポンシブデザイン前提のWordPressの表示速度高速化の考え方

座談会

  1. 座談会2:案件の見積もり
  2. 座談会4:クライアントへの提案

参考

  1. セッション・LTのスライドまとめ

WordCampとは?

WordCampとは?

WordCampとは、各地のWordPressコミュニティが開催する大規模な催しです[参考1] 。「WordCamp XXXXX」の名前で、

  • アメリカ(サンフランシスコ、ロサンジェルスなど)
  • イギリス(ロンドン、バーミンガムなど)
  • 南アフリカ共和国(ケープタウンなど)

のように世界各地で開催されています。日本では「WordCamp Tokyo」と「WordCamp Kansai」が開催されています。

WordCamp Tokyo

「WordCamp Tokyo[参考2] 」は現在、秋に2日間開催されます。

  • 1日目「セッションデイ」:部屋ごとに異なるテーマのセッション(講演)を聞くことができる
  • 2日目「コントリビュータ&ハッカソンデイ」:コントリビュート(貢献)ではWordPressに貢献する活動を行う(例:テーマレビュー、プラグイン作製、コアなどの翻訳、フォーラムへの回答)。
    ハッカソン(ハッカー+マラソン=ハッカソン)では、あらかじめ決められたお題に基づいて実際の作業を行う。例えば、今年のお題は「WordPressの情報まとめサイトの作成」。

このように、WordPressに関わる様々な催しが行われるのが、WordCamp Tokyoになります。今回は、「WordCamp Tokyo 2016」の1日目「セッションデイ」に参加しました。

全体の感想

今のWebサイト作製には、多岐に渡る知識・技術が不可欠である、ということが改めて浮き彫りになったと感じました。 例:Webサイト表示速度の高速化、Webアクセシビリティ、ワークフローの見直しと効率化、など

他方で、多くの新たな知見を得られたのは非常に意義が大きかったと感じました。個人的にはWebサイトの表示速度に関する内容を多く聞いたため、その点へのウェイトが大きくなったと思います。 例:WordPressの利用法の開拓、AMPに関する知識、など

ただ、REST APIに関するセッションを両方ともスケジュールの都合から断念せざるを得なかったり、懇親会で話を聞いたりして後から「あれも聞きたかった」というものが出てきたのが残念でした(スケジュール上聞けなかったので仕方ないですが)。

今回得た知見やモチベーションを、今後に活かせれば良いと思います。


セッション

CMSとしてのWordPress - WordPressで管理するランディングページ -

登壇者
吉田 智章
所属・経歴など
Sansan株式会社所属、対企業のマーケティングを担当
twitter
@yoshida_studio
スライド
CMSとしてのWordPress - WordPressで管理するランディングページ -

概要

多数のランディングページの管理にまつわる実経験の紹介。

内容

多数のセミナーを会社で実施しており、そのランディングページやお問い合わせフォームを当初はMovable Typeで管理・更新作業を行っていた。

  • セミナーのランディングページ:70
  • お問い合わせフォーム:40

数が多く、手作業で変更・更新を行うと誤りや漏れ、期限との戦いで磨耗するため、この数を一元管理することが課題となった。

そこで、WordPressを導入。

  1. セミナー参加に対するお礼メール(自動返信)の定型句(メール末尾の文面)は「カスタム投稿」に登録、一元管理することで文面の一括変更を可能に
  2. 各ランディングページ固有の表示内容は「カスタムフィールド」を使用。
    • OGP[1] 設定
    • スマホ用コンテンツの切り替え
    • 各ランディングページごとに固有のお礼メール本文の内容
  3. 申し込みフォームへのボタンの表示/非表示を「ショートコード」で制御(ショートコード内で記述した日時を過ぎると表示/非表示)
    
     [before_expire date="yyyy-MM-dd 00:00:000"]
        内容(yyyy/MM/dd 00:00:000まで表示される内容)
      [/before_expire]
    
      [after_expire]
        内容(上記時間を過ぎるとこちらが表示)
     [/after_expire]
        

以上のように、WordPressの機能を上手く利用することで、作業効率を上昇させることに成功した。

雑感

WordPressの機能と特徴を把握し、上手に使うことで業務の効率化と質を向上させることに成功した、という具体的な事例として分かりやすいものでした。WordPressはコーポレートサイトやブログ以外でも、使い方によっては社内業務など、多方面で活躍できるツールであるという可能性を示してくれたと思います。

Google 検索モバイルトレンド: モバイルサイトを AMP でもっとサクサク高速に

登壇者
金谷 武明
所属・経歴など
グーグル株式会社、サーチクオリティチーム シニアサーチエヴァンジェリスト
twitter
@jumpingknee
スライド
(なし)
参考>Google ウェブマスター向け公式ブログ: Google Search Console をサイトの AMP 化にも活用しましょう

概要

googleはスマホからの検索に力を入れている。その中で最新の取り組みとして注目される「AMP(Accelerated Mobile Pages)」の紹介と、WordPressへの導入についての説明。

内容

  • 日本でのgoogleの検索結果の過半数がスマホからの検索であり、日本以外の国でも同じ傾向が見られる
  • Webサイトを開く際に、3秒以上かかるサイトは53%の人がコンテンツを見ることなく離脱している

以上より、インターネットに接続するツールとして、スマホはPCの代替ではなく、メイン端末である。こうしたユーザの動向から、googleはスマホからの検索に力を入れている。

(筆者補足:googleは、2015年4月に「スマホ対応しているかどうか」を検索結果のランキングの評価基準に取り入れており[2] 、「ページを開く際の表示速度」もランキングの評価基準に取り入れる方針[3] であるらしい)

スマホからより高速にコンテンツに到達するために、現在googleが取り組んでいるプロジェクトが「AMP(Accelerated Mobile Pages)」。

AMPの特徴

  • 速い
  • 実装が簡単(HTMLをベースとし、完結するため)
  • モバイルフレンドリーである(スマホで使いやすいデザイン・構造になっている)
  • 仕様・実装がオープン(門戸を広く開けている)
  • マネタイズ可能(ビジネス利用可能)

高速化の秘訣

  • AMP対応の仕様がHTTPリクエストの回数を削減する仕様になっている
  • Javascriptを非同期のもののみに制限することで、ブラウザの再描画の負荷を削減
  • 画像サイズを指定すること(imgタグのwidth, heightに相当)で、ブラウザの再描画の負荷を削減
  • AMP用のキャッシュサーバがコンテンツをキャッシュしており、ユーザはそちらにアクセスする[4] という仕組み

AMPはニュースカテゴリから始っている。実際にスマホからgoogleで時事ネタを検索すると、検索結果の上に各メディアの記事がカルーセルで表示、記事を表示した後も左右へのスワイプで即座にアクセスし、読み比べができるようになっている。このようなAMPの動作と速度を一度体験すると、いかに革新的であるかが感じられる。

今後はニュース記事に限らず、一般の検索結果の中でもAMP対応ページが存在する場合は(通常ページではなく)AMP対応ページを検索結果に表示し、「AMP」とタグを付ける方針である[5] 。そして、メディアに留まらずに広く一般にAMPを普及させる方針である。

雑感

AMPの存在や制約、用途は知っていましたので、おさらいのつもりで聞きました。それよりも「国内のgoogle検索の過半数がスマホからのアクセス」「3秒以上表示に時間のかかるサイトは過半数が見ないで帰る」といった統計の方が衝撃でした。

なお、セッション後に質疑したところ、下記のような回答を得ました。

質問(主旨要約)
今のところメディア/ニュース業界に対して特にメリットが顕著に感じられるが、他分野でもAMP対応した方が良いか?
回答(要約)
メディア・ニュースに限らず、広い分野から"いつAMP対応すれば良い?"という積極的な問い合わせが多く寄せられている。積極的に導入を検討した方が良い。

一点注意事項として、AMP対応自体は検索結果のランキングの評価基準にはなっていないとのことです。

なお、スマホへコンテンツを高速に配信する、という点では別セッション[6] も参照。

デザイナーが効率よくテーマ作成を進めるには? デザインから WordPress のテーマ作成のワークフローを見直す

登壇者
長谷川 広武
所属・経歴など
フリーランサー→法人化(株式会社 HAMWORKS)・フロントエンドエンジニア
twitter
@h2ham
スライド
デザイナーが効率よくテーマ作成を進めるには? デザインから WordPress のテーマ作成のワークフローを見直す // Speaker Deck

概要

WordPressのテーマ作製において、どのようなワークフロー(作業の項目・順番)が最適か?

  • 一度HTML+cssの静的サイトとしてコーディングし、それをテーマ化する
  • 直接テーマとしてコーディングする

よく使われるワークフローである上記2つを比較・検討し、どのような手法が良いか考察する。

内容

一度HTML+cssの静的サイトとしてコーディングし、それをテーマ化

メリット
  • 細かい要望に柔軟に対応できる
  • テーマにする前にクライアントに確認・調整してもらうことができる
  • 分業化しやすい ※手戻りを最小限に抑えるため、分業者同士の共通認識が必要
デメリット
  • 考慮漏れや手戻りの頻度が作る人のスキルに大きく左右される
  • HTML+cssで直接書くのと時間的コストがほぼ同じ
  • プラグインで出力される部分(パンくずリストやお問い合わせフォームなど)をどうコーディングするか、ルールが必要

まとめると、メリットは、静的サイトのワークフローと馴染みやすかったり、事前確認・調整が可能といった点。デメリットは、極端に言えば「2回コーディング作業を行う」ことになる時間的なコストや、

  • サイト全体で共通のパーツをきちんと共通化できるように意識してコーディングしているか? 例:ヘッダやフッタ
  • コンテンツ内部の繰り返し部分をプログラムでループさせやすい構造としてコーディングしているか? 例:見出し→本文→見出し→本文…、の繰り返し

といったコーディング上のポイントを押さえているかどうか(コーディング作業を行う人のスキルに大きく依存)、で効率にブレが生じやすい、といった点。

直接テーマとしてコーディング

メリット
  • 子テーマのようなベースとなるテーマがあって、それをカスタマイズする場合:
    • 既に存在する機能やフックを活用すれば効率が向上
    • カスタマイズで対応可能な範囲であれば、カスタマイズする箇所が少なく済み効率的
デメリット
  • 第三者が作製したテーマであるため、構造の把握にコストがかかる
  • 細かい要望が出た場合、ベースとなるテーマで対応できるか?

まとめると、メリットは、ベーステーマでどこまで対応できるかを熟知した上で上手く落とし込めば、効率は飛躍的に向上する可能性がある点。デメリットは、対応可能な範囲を見誤った場合、途端に効率が下がる危険性をはらむ点。したがって、使いどころの見極めが肝心である。

なお、登壇者の一番の疑問点は「(原稿から)コンテンツの流し込み」を行う段階。直接テーマ化する、ということはコンテンツ部分のテストコーディングを行っていない=コンテンツ部分のコーディングと確認作業はどうすのか?WordPressの管理画面で編集→保存(プレビュー)→修正→保存…、という作業を行うのか?このワークフローの明確な答えはまだ見つかっていないとのこと。

結論

どちらの手法もメリット・デメリットがある。プロジェクトの内容や開発体制によって臨機応変に使い分けることが必要ではないか。

雑感

WordPressに限らず、デザイン(テーマ)とコンテンツの内容を別個に管理するCMSにおける開発ワークフローの効率化を考える上で有用な指針が示されたと感じました。それだけでなく、コーディングにおける近年のトレンドを押さえた知見も多く含まれており、そちらも参考になりました。例として、

cssの設計1
背景
プログラム側(JSやPHP)でHTMLの構造を変化させる手法が一般的になったことで、cssセレクタの優先度が重要になってきた
結果
  • IDセレクタでcssを指定することはなるべく避ける(IDはプログラムで指定する際に用いるように)
  • クラスの濫用を避けて、最小限で済ませるように(疑似セレクタも活用する)
  • クラスセレクタも優先度を下げるため、なるべく少ない個数で指定する
といったルールが普及。
cssの設計2
上記1より、cssの設計の普遍的なルール[1] が成立
例: など。
独自ルールよりも、広く普及しているルールを適用して作業者ごとの認識のブレを解消することも1つの手。
WordPressやCMSに限らず、ワークフローをなるべく一本化することで作業を効率化

開発ツールによってワークフローは大きく変化する。 例:静的サイトとWordPressで比較
しかし、変化の振れ幅を少なくし、効率を上げる努力はできる。
例:

  • cssプリプロセッサ[5] を利用する 例:LESS、Sass(Scss)[6]
  • タスクランナー[7] を利用する 例:gulp[8]
  • 静的サイトジェネレータ[9] を利用する 例:Metalsmith[10]

「作業内容を洗い出し、どのプロジェクトでも行う共通の作業を自動化する」といったことをするだけでも、作業効率は上昇する。

以上(※内容を掘り下げて詳述しました)のように、多くの知見を得ることもできてタメになりました。それと同時に、コストを削減するために様々なツールを使うことが多くなっているということも感じました。

gulpとScssは使用しているので、静的サイトジェネレータ辺りを物は試しで試す価値はあるのかな、と思いました。

WordPressでも意識したいアクセシビリティ ~「優しいウェブサイト」作りをはじめよう~

登壇者
  • 横田 東母子
  • 森田 壮
所属・経歴など
Webエンジニア
twitter
スライド
WordCamp Tokyo 2016 WordPressでも意識したいアクセシビリティ ~「優しいウェブサイト」作りをはじめよう~ // Speaker Deck

概要

Webアクセシビリティ[1] は障がい者に限らず全ての人に関わるものであることを提起し、アクセシビリティの意識の高まりと定義を確認。その上で、Webアクセシビリティ対策の手法を具体的に紹介する。

内容

近年、Webアクセシビリティへの機運は高まっている。理由として、

障碍者権利条約
2014年1月に日本も締結。同年2月より効力発生

障がい者が新たな情報通信機器及び情報通信システム(インターネットを含む。)を利用する機会を有することを促進すること。

という条文が存在
障がい者差別解消法
日本の法律。2016年4月に施行

といった、国際条約の締結や国内の法律の施行により、意識が高まっている。

問題提起:Webアクセシビリティは誰のため?

想定される回答例
視覚、聴覚、運動、認知などに障がいのある方のため
現実
障がい者に限定されず、一般の方も含めた普遍的な問題
理由(具体例)
  • リンクが分かりづらい(急いでる・慌てている場合に不便)
  • 色が分かりづらい(外出先の直射日光の下など)
  • 重い(公共機関利用中、回線状況によって)
  • 音声入力を利用したい(怪我をした場合など)
  • 小さい文字が見づらい(お年寄りの方に優しくない)
  • 文章が難しすぎる(児童などに優しくない)

上記のように、特別な状況でなくても「利用しやすい」ことは求められる。したがって、Webアクセシビリティは普遍的な問題である。誰でも、いつでも、どこでも、どんな状況でも使えるようにすることがWebアクセシビリティの肝である。また、サイトの表示速度向上もアクセシビリティ対策の1つになる[2] ことも注目したい。

WordPressに絞ると、コアシステムはW3C[3] が規定するWebアクセシビリティの基準の高ランクを満たしている、とのこと。

Webアクセシビリティの基準

  • WCAG 2.0[4]
  • JIS X 8341-3:2016[5] (上基準と相互互換の日本の規定)

Webアクセシビリティを考慮してカスタマイズする際は、多くの事項に気を使う。

  • 見出しを正しく使う
  • imgタグにalt属性を必ず付ける
  • リンク先の内容を推測できるようにリンクを記述 反例:「詳しくはこちら」といった文章にリンクを付けない
  • リンクのフォーカスを消さない。疑似セレクタ「:focus」もcssで指定する
  • 横スクロールせずに読めるようにする
  • テキストサイズや行間に気を付ける
  • 空pタグやスペースを使わない(読み上げソフトは「改行」と読んでしまい、聞き手に文章が伝わりづらくなる)
  • HTMLをバリデートする(正しくコーディングされている=正しく文書が構造されている、ということ)
  • Webのセマンティクスに気を使う 例:section、header、footerなど、文書の役割に合ったHTMLタグを用いる
  • WAI-ARIAやrole属性[6] を使用し、HTMLタグの役割を明示・詳細情報を付与する

など、デザインからHTMLの設計まで、非常に多岐に渡る。

WordPressの場合、Webアクセシビリティに対応するためには一人だけではなく、プラグインやテーマ、カスタマイズする作製者まで、多くの人が携わることで初めて成し得る。各人が協力することで、よりWebアクセシビリティに対するクオリティを上昇させることが課題である。

雑感

サイトの表示速度向上もアクセシビリティ対策の1つたりうる、という点はなるほど、と思いました。前後のセッションの内容と関連するためです。Webアクセシビリティに限定しても、様々な面から気を配る必要があるということが分かり、新たな課題を与えられた気がします。

レスポンシブデザイン前提のWordPressの表示速度高速化の考え方

登壇者
竹洞 陽一郎
所属・経歴など
株式会社Spelldata 取締役代表
twitter
@takehora
スライド
レスポンシブデザイン前提のWordPressの表示速度高速化の考え方

概要

Webサイトにおいて、表示速度は品質の基準として重要である。しかし、Webサイト作製者・クライアントと一般ユーザの意識には大きなギャップが存在し、企業は大きく機会を損失しているのが現状である。

Webサイトの表示速度は重要な課題で、意識せずに作製している状態ではこの課題をクリアすることは困難であるという状況を啓蒙し、表示速度を向上させるための指針を示す。

内容

Webサイトの表示速度に対する意識調査

登壇者がtwitterで行ったアンケート「表示速度はWebサイトの直帰率・離脱率・コンバーション率に関係するか?」
57%の人が「表示速度?関係しないでしょ」状態
世界のユーザの意識「どのくらいの時間ならば許せるか?」
  • 表示開始(1ピクセルでも画面に表示される)まで:0.5秒以内
  • 表示完了(ユーザが操作可能になる)まで:2秒以内
  • エラー率(ダウンロード失敗など):3%以内
非常にシビア!
ユーザへの意識調査「表示が遅いサイトへは二度と行かない!」
  • 世界全体:49%
  • 日本:47%
半分近くのユーザが「表示速度が遅いサイトには行きたくない!」(Compuware、2012年調べ)
ユーザがWebサイトに望むもの
パフォーマンス:52%
コンテンツの更新頻度は39%…圧倒的に「中身よりスピード」(Limelight Network調べ)

ユーザは表示速度について非常にウルサイ!ということを重く受け止めるべき。

民法改正(請負人の担保責任の制限)

民法改正により、Web作製者はwebサイトの品質についても責任を負う。

第六百三十六条
請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき(中略)は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

クライアントが意図する「目的」に対して、目的を達成できる「品質」を満たすかを問われる。例えバグがなくても、クライアントの目的を達成できないような品質のものを納品するとアウト[1]

こうした事情からも、表示速度を向上させる、あるいはどの程度までならば妥協できるかをクライアントとWeb作製者の双方で共通認識させることが求められる。

スマートフォン対策

携帯電話が使用している電波帯域は総務省が定めているため、通信できる情報量は増加させることができない。この条件の下で計算すると、1ページあたり200KBを超過した場合、LTEで3秒以内に表示させることはできない。そのため、いかにサーバスペックを良くしても、そもそもコンテンツのボリュームを相当削ぎ落とさないといけない。

表示速度を取るか、コンテンツのボリュームを取るか、「どこまで遅延を許せるか?」という交渉も必要。 例:「この画像を入れると200KBを越えてしまい、スマホで表示すると3秒以上かかります。それでも入れますか?」

まとめ

  • Webサイトの表示速度は表示開始0.5秒、表示完了2秒が世界基準
  • 表示速度の高速化もWebサイト作製の仕事・品質の1つ。きちんと保証できますか?
  • 保証には計測と、計測したデータの分析が必要です
  • 200KBを越えると、LTE網で3秒以内に配信は不可能

雑感

Webサイト作製における「品質」の担保が、表示速度という切り口から非常に重くのしかかってくる内容でした。民法改正により品質を厳しく問われる可能性があることと、品質の保証のために多岐に渡る分野の知識・技術を結集させることが必要であることを感じました。

このセッションを聞いて、別セッションのAMPへの対応[2] も積極的に考えるべきか、と思いました。

座談会2:案件の見積もり

司会進行
後藤賢司
twitter
@428design

概要

座談会とは、市会進行役と、その場に集まった人同士で課題を出し合い、それについて相談・議論する場。セッションとは異なり、各々が抱えている課題を同業・異業種の人と共有・討論することで、何らかの解決の糸口を見出せるかもしれない。

座談会2:案件の見積もりでは、項目の洗い出しから運用・保守まで様々な場面での作業に対する金額設定について話し合った。

内容

クライアントが要件を出してくれない、項目をどう洗い出すか、マニュアルは?運用保守はどこまで?といった、あるあるな話題が出揃った。どこでも同じようなことに苦労していることが窺える。

見積もりの計算法の例として出された手法は大きく2つ。

  • 人日・人時の積み上げ
  • 作業項目の洗い出しと、項目ごとの料金の積み上げ

後者に関しては項目をなるべく小さく分散させることがコツ、とのこと。

雑感

見積もりを通す、交渉のコツは「クライアントに分かる項目で金額を出す」こと、というのは非常に納得できました。そのためには、後でブレないように最初のヒアリングをしっかり行うことが重要だと感じました。

座談会4:クライアントへの提案

司会進行
小杉 聖
twitter
@mekemoke

概要

Webサイト作製者がクライアントへの提案の際に遭遇する事象について相談・議論する。

内容

クライアントからの要望が漠然としている、担当者が上手く要望を抽出できない、クライアント側の担当者を越えても最終決定者の一声で泡に帰す、などこちらも思わず頭を抱えてしまう話題が出揃った。

最初のヒアリングが上手く行かなければ、後の行程全てが崩れかねない。土壌や基礎ができていない上に家を建てるようなものである。ヒアリングがプロジェクトを無事に遂行させるため肝である。その手法として

「最終目的」を設定

作製したWebサイトでどのような「目的」を達成したいのかを設定する。

複数人でヒアリング

複数人でヒアリングすることで、内容のすり合わせ・調整を行い、確実にフィードバックできるようにする。

ヒアリングシート・コンセプトシートを用意

口頭による打ち合わせ・ヒアリングではなく、形が残り、すり合わせや調整が行いやすいツールを使うことで、フィードバックの効率を上げる。

などが挙げられ、どうプロジェクトの進行を円滑に進めるかが焦点となった。

雑感

いくつもの知見を得られたことが大きかったです。

テーマがテーマなので、ヒアリングや交渉から始まって提案まで、コミュニケーションをどう円滑に行うか、という点で参考になると思います。

ただ、話を聞くことに集中し過ぎたのか、メモが断片的になってしまったのが個人的に残念です。

セッション・LTのスライドまとめ

懇親会

今年は懇親会まで参加しました。あまり食べることに集中するとせっかくの場がもったいないので、適当に摘みつつ会話を聞いたり話しかけたり話しかけられたりしました。名刺はなんだかんだ10枚くらいははけたようで、様々な方と交流できて良かったです。

名刺に関しては結局時間がなかったので、以前作ったHTML+css(メディアクエリで印刷用cssを作製、名刺サイズを指定して調整することでそれっぽくしたもの)でさくっと作製。ネタばらしをすると驚かれました。しかし、調整に苦労するので人にはオススメできません。


以上、WordCamp Tokyo 2016参加レポートでした。

タグ: イベント

 



関連する記事一覧