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

WordCamp Tokyo 2017 参加レポート

カテゴリ: WordPress

WordCamp Tokyo 2017に一般参加してきたので、参加レポを書き留めておきます。

セッション内容メモ

各敬称略

※セッションの内容を聞き取ってまとめたりしましたが、抜け・漏れや解釈違いなどがあるかもしれません。

WPサイト構築プロジェクトマネジメント

  • 大串 肇
  • 聞いてる人へのアンケート
    • Webに携わる仕事をしている人: ほぼほぼ
    • 困ったことがない人: 0
      • 上手く行かないことが多い
  • 困ること
    1. 仕事量(多くても少なくても)
    2. 終わらない
      • できない
      • 仕様変更
      • お客様の返答がない
      • etc.
    3. 成果が出ない
      • 目標に到達しない
      • そもそも目標がない
      • etc.
  • 今回は2.終わらない について話す
    • テスト直前の修正、ついでに仕様変更……とするとついでにがさらに増える。あれこれドバっと出てくる。
      • マージン
      • 1行追加・修正
      • 画像変更
      • 管理画面で編集できないの?という問い合わせ
      • 印刷すると崩れる
      • etcetc.
        • 言われてみれば対応した方が良いことばかり
        • でもスケジュール……予算……orz
    • 一つの発見: 10年くらいWebディレクションの仕事をして気付いた
    • コミットログ(Git)の中にヒントが
      • 修正・調整が5~6割(スムーズに終わったという体感でも)
        • 開発準備: 0.5
        • デザイン: 1.5
        • 開発: 3
        • 修正/調整: 5
    • 見積もりでテストについて明記なし: 修正/調整に対して工数の見積もりがない
      • すごくよくありそう
      • ここでは「レビュー」とする
        • 「動作検証のテスト」ではない
        • お客さんとの調整という意図での「レビュー」
      • テストとレビューを見積もりを組み入れる
      • が、見積もりは最初に出す。どうやって工数を出す?
        • 一通り見た目や動作に工数掛かるから
        • レビューで意図が伝わりづらいのであれば、開発の中にレビューも含ませる、ということを開発者・お客さん双方に伝えるのも方法
        • 解決策
          1. 一度出す
            • 一度出すことで、例えいったん削ったとしても後で工数かかったときの説得材料になる
          2. プロトタイプを作ってそこから再見積もり
          3. 最低限だけ作ってリリース、そこから運用保守で作り込みをしていく
            • 終わらず続けるスタイル
              • 実際のユーザの動きを見ながらサイト構成を最適化できる
              • 新しいもの・解析を見ながらフィードバックを基にお客さんとサイトの価値を共創する
              • WPならアクセス解析・お客さん自身が更新しながら、というフローがやりやすい
        • レビューの工数・スケジュールを決め打ちすると「最初は一切見ないよ」という逆手に取られる可能性も……
          • それはこちらのことを考えてないことでもある。もっと開発者側が制作フローや経験則をアピールすることも必要
        • アジャイル的に段階を切る
        • etc.
    • まとめ
      • レビューとテストを入れよう
  • One more thing.
    • プロジェクトで使うプラグインの紹介
      • Show Current Page→どのテンプレート階層で表示されてるか表示するプラグイン。製作者必須!
      • WP SiteManager: パンくずやナビを一括で作れる
    • 作者の人たちがたくさん会場にいる
      • どうやったら正しくプラグイン作成者に感謝を伝えられるか
        • エアリプとか口頭とか…
          • Rating。WordPress.orgのアカウントでスターを付けられる
          • Githubでスターとか
          • ブログでマニュアルを書く、友達に教えるとかもあり

まとめ

レビュー・テストの工数は読みづらいこともあって見積もり段階では見落としがち。これを考慮することで、予算もスケジュールも余裕を見ることができるのではないか。ただし、銀の弾丸ではないことに留意。

Gutenbergが切り開くWPの新UX

  • 西川 伸一
  • 5.0から採用される"Gutenberg(エディタの名前、プロジェクトの名前)"
    • Gutenbergとは?
    • 1440年に開発された活版印刷の技術。技術者のヨハネス・グーテンベルク氏より
      • 活版印刷の文字→活字。英語にするとMovable types。別のCMSの名前でもある。
  • よりWYSIWYGに。ブロックの概念が導入され、concrete5っぽい編集が可能に
  • WPの使命: Democralization of Publishing
    • Gutenberg: 活版印刷により他人にメッセージを伝えることを容易化した。それと同じように、メッセージを誰でも伝えることができるように
    • +自分でそのデータを持つことができる
      • 移行しやすい
      • デジタルサイネージやWatch端末に出す場合: データで出力(REST APIなど)
  • 使命を受け継ぐ名前としてGutenbergという名前
  • WP: 上位1000万PVのサイトのうち26%がWP。CMSだと6割。日本のCMSでは8割。
  • WPが今取り組んでいるプロジェクト(去年12月に発表)
    1. エディター: Gutenberg: 記事一つ一つに対して
    2. カスタマイザー: カスタマイズcssなどのカスタマイズ: ウィジェットなど共通部分を追加・削除・修正できる
      • 1.2.はWebサイトビルダー(Wix, Jimdooなど)でできる「簡単さ」をWPに導入する
    3. REST API
  • 技術的な問題
    • Reactを使っていた
    • 昨日、Mattから重大発表
    • Reactの開発元、facebookのライセンスがWPの意義に抵触する可能性がある
    • そのため、別のJSフレームワークに移行する方向性
  • 制作者、クワイアントワーク
    • 3年後にはデザインはあまり必要なくなる
    • どういう付加価値を提案していくか
    • 今まで使えていたテーマが使えなくなるかも?(Gutenbergの中で足されたブロックに対してcssなどをどう対応させるか

まとめ

Gutenbergのエディタに対して、制作者は慣れておく必要がある。また、より「見たまま編集」できるようになることで、単なるビジュアルのデザインのみで対価はもらいづらくなると考えられる。付加価値を付けることが必要。技術的には、多少JSフレームワーク周りも知っておくと良いかもしれない。

Hub・プラットフォームとしてのWP

  • 岡本 秀高
  • 今日の話
    • WPで「やれること」「やるべきこと」は違う
    • 得意なことは得意なところに任せよう
    • 適材適所で素早く行動・判断することが必要
    • コミュニティに参加して「自分のモノサシ」を見付けよう
  • WPの強み
    • テーマによるデザイン変更
    • プラグインで機能を簡単に拡張
    • アクションフックでカスタマイズが自由
    • ノウハウが多い
  • 巨大なモノリス化
    • カスタムフィールドによる複雑な検索クエリ
    • アップデートで見られなくなるフロントエンド
      • 「触るのが怖い」となる
    • (WPに限らず)データ増加でパフォーマンス増加
    • (WPに限らず)アプリ化するWebの流れ
      • その流れで良いの?
  • 肥大化に対して一つの対策
    • すべてをWPに任せない
  • WPをHub・プラットフォームにして外部サービスと連携
  • WPの便利
    • 洗練された管理画面
    • ブログ・メディア向けの構造
      • 日付アーカイブ
      • カテゴリ
      • URL自動出力
    • フックやAPIで連携が可能
  • このセッションでは
    • Hub: WP→ほかのサービスを利用
      • 事例
        • 検索の外部化
          • Algolia/Elasticsearch
            • 両方全文検索エンジン
            • transition_post_statusなどで更新をフック
            • 検索をWP_Queryでやらない。こっちに任せる
            • Elasticsearch: WP Simple Elasticsearch(検索クエリの書き換え)
            • ElasticPress(関連記事表示などに対応)
        • 問い合わせの外部連携
          • Mautic/kintone
            • お問い合わせフォームのデータを外部サービスへ
            • WPはView(フォームの見た目)のみに専念
            • WP to kintone(kintoneのフォームをWPに挿入)
            • WP mautic(トラッキング・フォーム挿入)
        • 画像のタグ付け
          • アップロード画像をタグ付けを外部化
          • 画像認識サービスを利用して解析
          • googleなど
          • 解析結果をタグとして利用
          • 360images.io
            • 360度画像販売
            • タグ付けの自動化
            • 連携プラグインをOSSに
        • 決済処理の外部化(WPにログすら残さない、とか)
        • kintoneのデータインポート
        • etc.
      • 「欲しい機能のAPIを探す」という開発方法
        • wp_remote_post, wp_remote_getでAPIをリモートコールしやすい
        • WPはコンテンツ管理に特化
        • 得意分野に特化した開発
        • コードを減らす
    • プラットフォーム: 他のサービス→WPを利用
      • フロントエンドとアプリの分離
        • フロントはReactやAngular
        • SPA
        • スケーラビリティ、耐障害性を高める
      • データとコンテンツを分けて使う
        • モバイルアプリにデータを使う
      • SaaSの取り組み: Nomadbase/HappyTables
      • 音声デバイス Amazon Alexa
        • Amazonの音声認識サービス&デバイス
        • バックエンドにWep APIが利用可能
      • ニュースやプロダクト紹介のデータソースにWP
        • フィード(ニュース記事)を読み上げる(WPのFeedをAlexaは認識する)
        • 既存コンテンツを音声デバイスへ
        • 近い将来「ブラウザで見る」ことすら必要ないかもしれない
      • WPのコンテンツを有効活用する
  • 「WPだけ」でやらない
  • 制作時間3時間のサイトが一週間で100万PV達成、NHKにも作者出演、ということがWPでは可能
    • 素早く始めて素早く改善する
    • 巨大化して動きが遅くならないように
  • 大切なのは: 考えは大きく、でも始めるのは小さく、そして素早く改善

まとめ

画像タグ付けに関しては、Microsoftのcognitive Serviceもこれに該当すると思われる。APIにより、各種サービスを連携させてWebサイト(Webアプリ)を作ることも今後需要が高まると考えられる。WPの得意・不得意を迅速に見極めて、Webシステムの設計できるようになることが求められていると感じました。

大規模案件の苦悩から生まれたCF設計

  • 安藤 大海, 関井 遼平, 丹羽 孝彰
  • 実装サンプル
    • 縦に長いサイト
  • どう設計する?
    1. ビジュアルエディタ
    2. ビジュアルエディタ拡張
    3. ウィジェットプラグイン
    4. 上記以外
  • カスタムフィールドで実装
  • デフォルトのエディタない
    • 全てカスタムフィールド
      1. 使い回せるパーツを洗い出す
      2. 構造を分解
      3. 複数の要素を機能別にセット化
      4. カラムなどを入れ替えられるように
    • 「記事セット」として使う
    • 作成・運用のコストを下げるメリット
    • 予想外の使い方をされることが減り、デザインが保持できる
  • でも最初は……
  • WebLerease2というエンタープライズCMSを使用
    • 管理画面も編集用エディタを作る必要があるCMS
    • この使い方をWPに取り入れる動きに
    • →大変だった
  • TypeRocket
    • エンジニア向けWPフレームワーク
    • 21種類のフィールドタイプ
  • コアでもカスタムフィールド周りが徐々に充実してきた
  • が、プロジェクトごとに0からワイヤーを作るのは……など苦悩が
  • じゃあ、自前で記事のセットを作ろう
    • 「IZANAKI」プロジェクトとして制作
  • まとめ
    • 一つのソリューションとしてどうか

まとめ

お客様用のテーブルの編集をの考え方を取り入れられないか?と考えました。実装は難しそうですが、必要になるときが来るかもしれない、と感じました。 ただし、なんでもかんでもカスタムフィールドに任せると後が悲惨なことになりそうなので、最初の要件定義と設計が必須だと思いました。

常時SSL化の事前確認・注意点・手順 ~WordPressとその周辺で必要なこと~

  • 古里 武士, 前川 昌幸
  • SSL化について
    • google
      • Symantecを無効化
      • 検索ランキングでもSSLはポイントが高くなる
    • Apple, MicrosoftのサービスはSSL前提
    • HTTP2はhttpsが前提
    • メールフォームだけSSLは終焉
    • 常時SSL化が進む
  • 事前確認で必要なこと
    • サーバ
      • 証明書を誰がとる
      • 利用する証明書の種類
      • SSL使えるサーバか?
    • 他サイト・サービスとの連携
      • 連携先がSSL対応しているか?
    • その他
      • SNSボタン
      • Analytics/Search Consoleなど
  • サーバで必要なこと
    • 証明書の反映
    • httpsの有効化
    • リダイレクト
  • WPで必要なこと
    • WPの設定
      • WordPress設定
      • サイトURL
    • テーマのURLの修正
    • 記事内のURLの修正
      • WP-CLI利用。これが一番早い。
      • Search Regex
      • DBのダンプを一括変換するとカスタムフィールドプラグインなどでデータが壊れることが稀にあるので非推奨
    • なぜか「!」が付くことが(Chrome) or Safariで鍵マークが付かない(警告が出ていないので以外とスルーされる)
      • ページ内でhttpsではないソースがある
      • テーマや記事のhttpをhttpsに修正する必要がある
      • JSの多段バナーなどは注意
      • src="//"は?→httpならhttp、httpsならhttpsになる、が最近は推奨していない(httpsのみのサービスはhttpsで良いので)
  • 無停止でSSL化する手順
    1. バックアップを取る
    2. httpsと平行稼働
    3. テーマ修正
    4. 記事内の修正
    5. WP設定を変更
    6. https動作確認
    7. httpからhttpsへリダイレクト

まとめ

WP-CLIが使えれば常時SSL化も簡単そうなので、Let's Encryptと合わせて試験を行ってみたいです。

WPの制作案件相談会(AMA)

  • 大串 肇, 長谷川 広武, 小杉 聖
  1. ローカル開発、テスト、本番の3つのサーバ…というように、サーバの準備やテスト→本番への移行はどうするか?
      1. ローカル、テスト、本番の3つのサーバを立てる
        • ローカルはLocal by Flywheel, VCCWなど。開発環境構築がハードルになってその日の作業が進みが悪いことも…となるとMAMPに
      2. WPコアすべてgit管理しておく。wp-configだけignore
      3. デプロイは手動or自動。DBはdumpしたものをWP-CLIでURL書き換えして引っ越し
      • ほとんど本番しかない
      • functions.phpなどはローカルでテストするがお客さんに見せながらテスト
      • ローカルはMAMP
      • ローカルは最低限。テストと本番は1つだったり分かれていたり
        • お客さんによってレンタルだったりクラウドだったりするため
      • ローカルはMAMP
  2. Vagrant使うメリット
      • すぐ壊せる。すぐ立てられる。さっと作ってさっと壊す。サーバを手軽に弄れる。
      • PHPやMySQLのバージョンを本番に合わせられる
  3. WPのアップデートをお客さんに任せるか?自分で保守するか?
    • 3名:
      • 契約によりけり。
      • ただし保守・バックアップはなるべくするように勧めるようにしている
  4. 自動アップデートした後、プラグインが動かなくなった場合。かつ保守の数が多くなった場合の対応
    • 3名:
      • まずそういった例がない
      • プラグインを選ぶ。作者を知っているものか、数十万~数百万ダウンロードしたものしか使わない
      • 選定段階で危なさそうなものを断ることが大事
  5. どうやっているのか?月に何件?何人体制?
      • 勝手に入ってくる(インバウンド)ばかり
      • 講演会などで発表してアピールする
      • 「どんなに優れたエンジニアでも、見付からなければいないのも一緒」
      • 1.に同じ
      • WiFiのSSIDで遊ぶ
      • 月2~3本
      • 最大4人なので
      • 大体スケジュールが重なる
      • mgnと同じ
      • 2~3月に1本、1つ50万円など
      • 大体スケジュールが重なる

まとめ

開発環境や保守運用について実地体験に基づく貴重な意見を聞くことができました。
これを参考にして、より自分の場合に当てはめて洗練させていきたいです。

みんなどうやってるの?(アンカンファレンス)

  • サーバ環境や開発環境はケースバイケースだが悩みどころ
  • お客さん用のテーブル、他の方々も苦労されているようだった

メモ

  • アドオンプラグイン
  • Coldbox

雑記

文章ばかりだとアレなので、写真をいくつか掲載しておきます。

ランチセッションのチケット

ランチセッションのチケット。今回初めて「ランチセッション」なるものが追加され、お昼を食べながら他の参加者とお話しする機会を作りやすくなりました。

ランチセッションのランチ

ランチ。いくつか種類があったのですが、カレーを選びました。

顔出し写真用のパネル

写真撮影用のパネル

懇親会の料理

懇親会の料理。ピラフとサンドイッチが美味しかったです。

チケットやストラップ、懇親会のリストバンドなど

チケットやストラップ、懇親会のリストバンドなど

全体のまとめ

今回も様々な概念や知見を得ることができた。同時に今まで接点がネットのみの方にも直接お会いして挨拶することができ、交流を深めることができ、充実した一日になりました。
懇親会のLT大会の熱量はカオスというか色々な意味で「すごい」としか形容しがたい空気でした。あの空気はあの場所にいないとなかなか味わえないのではないかと思います。

この記事が参加の様子や知見など、少しでも誰かの参考になれば幸いです。

最後に、参加されたすべての方とスポンサーの皆様に感謝を。お疲れさまでした&ありがとうございました!

タグ: イベント

 



関連する記事一覧