WP Fastest CacheによるMW WP Formが送信できない不具合




 

先日、WordPressで制作したサイトで突如メールフォームが送信できない以下の事象が起こりました。

 

  1. 入力後、確認画面で別のユーザーの入力情報が表示されてしまう。
  2. 再度入力しても確認画面に遷移せず入力画面に戻されてしまう。

 

公開後、半年経ったあとの出来事で今までは正常に受信していました。

上記の1の事象に関しては最初ゾッとしましたが、早期的に原因を突き止める手がかりとなりました。

 

原因はキャッシュ系プラグイン

メールフォームのプラグインはMW WP Formを使用しており、設定画面やソースに異常は見られず、狐に包まれた気持ちになっていた頃、WordPressでなにか起きた時はだいたいキャッシュ系のプラグインの仕業だろうと思い、試しにWP Fastest Cacheを停止。

 

その後、再度送信テストを実施したところ不具合が解消されました。

 

しかし、WP Fastest Cacheを停止してしまうと、PageSpeed Insightsでスマートフォン表示のスコアが30も下がってしまい一気に真っ赤っかに。




WP Fastest Cacheをページ毎に設定除外

去年2018年、SEO業界を賑わしたメディックアップデートとともに重要事項である、MFI(モバイルファーストインデックス)評価を下げるわけにはいかず、WP Fastest Cacheの設定を再度見直したところ、個別のページ、つまりURL別に設定を除外できることが分かりました。

 

手順1

WordPress管理画面のメニューから「WP Fastest Cache」>「除外する」タブを選択。

 

手順2

上段に「除外するページ」という項目があるので、右側の「Add New Rule」ボタンを押します。

 

WP Fastest Cacheのページ除外

 

手順3

「Exclude Page Wizard」というウィンドウが開くので、「If REQUEST_URI」のプルダウンから「Is Equal To」を選択。

 

WP Fastest Cacheのページ除外

 

手順4

入力項目に、メールフォームを要するページのURLを入力し除外させます。最後に「Save」ボタンを押して完了。

 

WP Fastest Cacheのページ除外

 

以上で、メールフォームを要するページのみWP Fastest Cacheが適用されなくなり、ページスピードのスコアも落とさずに済みました。

 

確認画面なども除外しておく

フォームが表示されているページのみを除外してもまだ安心してはいけません。

 

以前、ユーザーから「フォームの確認画面へ進まない」という電話がきたことがあります。

 

コンバージョン計測やユーザビリティのために確認画面や送信完了画面が必要でMW WP Formをメールフォームとして使用している人が多いかと思いますが、確認画面と送完了画面も除外設定しなければならないことを忘れずに。

 

そうしないと、確認画面ページには遷移せず、真っ白な画面になってしまいますので。

 

さいごに。

キャッシュ系プラグインは便利な反面、むかしからヒヤヒヤさせられていて、設定には気をつけているつもりでしたが久しぶりに肝を冷やす思いをしました。




「WordPressを守ろう!セキュリティの最新トレンドと対応事例」で得た対策と知見




 

Tokyo WordPress Meetup主催の「WordPress を守ろう!セキュリティの最新トレンドと対応事例」にWebデザイナーと一緒に参加してきました。

 

Tokyo WordPress Meetupのイベントへの参加は、去年の旧WordBench 東京「Webサイト制作プロジェクトマネジメント入門」以来久しぶり。

 

厄年のせいか、去年から今年にかけてリダイレクトスパムDoS攻撃の対応に追われたこともあり、今回のテーマは非常に楽しみにしていました。

 

WordPress 管理者がおさえておきたい Web アプリケーションセキュリティ

最初のセッションは表題の通り、WordPress ユーザー・管理者・開発者がおさえておきたいWebアプリケーションセキュリティのトレンドの解説を、OWASP Japan(オワスプ ジャパン)の松本悦宜氏がスピーカーをされていました。

 

僕はまず、OWASP(オワスプ)の存在を知りませんでした。

OWASPは、Open Web Spplication Security Projectの略で、Webセキュリティを取り巻く問題を解決するために各国の専門家が集結した国際的なコミュニティで、日本にも10の拠点があります。WordPressを愛するWordPress Meetupのようですね。

 

のちに、そのOWASPが発表している脆弱性と対処法に関するドキュメントなどを含め、WordPressにおけるリスクの確認と対策方法が紹介されました。

 

サイト改ざんなど、セキュリティリスクが多く報道されていますが、中でもWeb制作やWeb運用に携わっている人たちの間では、WordPressはセキュリティが弱いと思われがちですが、これは単にWordPressがCMSの中で圧倒的にシェア率が高いだけの話で、当然なにか脆弱性が発見されればそれに比例してしまい、他のCMSに比べれて名前が上がりやすいということで、決してWordPressが突出してセキュリティが弱いということではない冒頭のお話に納得しました。

 

リスクを確認するための3つのドキュメント

WordPressを安全に使うためにはどうすればいいのか。なにごとにもリスクヘッジができて越したことがないように、Webアプリケーションのセキュリティにおける最新の情報やトレンドを確認できる信頼性あるドキュメントが3つ紹介されました。

【1】OWASP TOP 10

前述のOWASPが発表している、最も注意すべき脆弱性と対処法が10件まとめられており、内容は3年おきに見直され更新。日本語版もあります。

OWASP TOP 10 – 1017(PDFドキュメント)

 

【2】WordPressセキュリティ白書

WordPress.orgで公開されている、まさにWordPressに特化したセキュリティ対策がまとめられています。日本語版もあります。

WordPressセキュリティ白書

 

【3】OWASP WordPress Security Implementation Guideline

OWASPのサイト内で提供されているWordOressに関連した情報のドキュメント。WordPressの様々な設定がまとめられているけど、現状は英語版のみです。

OWASP WordPress Security Implementation Guideline

 

3つのWordPressセキュリティ対策

【1】WordPressのログインを守る

ログイン画面のセキュリティ設計として、

  1. wp-login.phpのアクセス制限
  2. 2要素認証、アカウントロック
  3. パスワードポリシーの確認

 

上記3つが考えられますが、運営者への負担の許容など、ユーザーがどう使うかも考慮もしながら設定しなければならないとのこと。

 

しかしながら、3番目のパスワードポリシーは重要とのことです。映画(スターウォーズやスタートレック)のキャラクターやポケモンなどの名称を使用したパスワードは特にあぶないそうです。

 

僕の場合、クライアントの案件でもwp-login.phpのアクセス制限とパスワードポリシーだけは実施しております。

 

【2】脆弱性情報を確認する

WordPressの管理画面の更新情報に注目し、下記3つは最新のヴァージョンに保つ。

  • 本体
  • テーマ
  • プラグイン

 

注意すべきは、使用してないプラグインは削除する。停止では不十分だそうです。また、今回お話には出てきませんでしたが、使用していないテーマのバージョンアップや削除もしておいた方がいいという話を聞いたことがあり、例えば、WordPressをインストールするとデフォルトでバンドルされているテーマなどは不要の場合は僕は削除しています。

 

【3】WordPressの関数を使う

正しくWordPressの関数をしようしないと、SQLインジェクションやXSS(クロスサイトスクリプティング)といったデータベースへの漏洩や書き換えなどの攻撃にさらされる危険があるとのこと。

 

以前、固定ページでPHPをかけるようにするためのプラグインExec-PHPにてeval関数が使用されていて非推奨になった記憶がありますが、そういったことでしょうか。

 

とにかく、攻撃者が裏口を作り、PHPをアップし遠隔操作などを行うバックドアの話は恐ろしかったです。

 

 

セキュリティ診断ツール2点

最後に、推奨のセキュリティツールを紹介しておりました。

OWAAP ZAP

OWAAPが提供している診断ツールで、動的スキャンで擬似攻撃による検証ができるそうです。OWAAP ZAPの記事などのキータに一番まとまってるそうです。

検証といっても、結局は自分でサイトを攻撃していることになるので、自社で計画的に使用するなら問題ないですが、第三者のサイトに無断で使用するのは許可や計画が必要。

OWASP ZAP Hands-on In Osaka (2015-02-10)

 

WPScan

WordPressのセキュリティマニアの方々が集まる会社が提供している脆弱性スキャンツール。任意のパスワードリストからの総当たり攻撃もできるそうです。

WordPressの本体、プラグイン、テーマのバージョンが影響を受ける脆弱性を検証、また、不要なファイルが公開されてないか(readme.htmlなど)も確認できるそうです。

しかし、コマンドラインが必要なので、完全にエンジニアさん向けと思いました。

WPSCanによるWordPressの脆弱性スキャン

 

 

セッション1のまとめ

wp-login.phpのアクセス制限、パスワードの強化、本体・テーマ・プラグインの更新情報の注意と対処。これらは普段から行っていたことなので安心しました。

特に松本悦宜氏のお話の中では、OWASPの存在をはじめ、信頼性あるドキュメントや診断ツールを紹介していただいて、とてもためになりました。

また、今後「WordPressって大丈夫なの?」とクライアントに聞かれても、自信を持って説明できるようになれてよかったと思います。

 

今回の登壇で使用された松本悦宜氏のスライド

 

 

「WordPress セキュリティインシデントの対応事例」

セッション2は、主にサーバーサイドのプログラマーである神垣聡氏の豊富な経験の中から、実際に起きたインシデントとその対応事例について。

 

リダイレクトスパム編

あるURLを踏んだら、勝手にスパムサイトへ強制リダイレクトされるリダイレクトスパム。

 

リダイレクトスパムに関しては僕もやられた経験があり、その時のことを記事にしたことがあります。

 

WordPress マルウェアの確認と駆除作業(リダイレクトスパム)

 

リダイレクトスパムはリダイレクト用のプログラムがHTMLやPHPに埋め込まれてしまい、それが作用して強制的にリダイレクトされてしまう仕組みです。

 

WordPressの場合、主にplugin/index.phpが書き換わっている場合が多いらしいのですが、上記で紹介した以前の記事の時は、header.phpと、footer.phpが改ざんされていました。

 

しかも、コアファイル群の中にwp-login.phpに模した、w-login.phpというPHPファイルも仕込まれていたり。。

 

plugin/index.phpが書き換わっている場合、plugin/index.phpにファイルのアップロードを行うスクリプトが書かれ、他のファイルを呼び込むバックドアとなっているとにこと。

 

WorsFenceとSucuriScannerというプラグインで確認したそうです。

 

根本的な原因として、推測らしいのですが、メッセンジャーツールにてアカウント乗っ取りが多発時期だったらしく、フィッシングスパムメッセージを踏んで被害が拡大した可能性があるそうです。

 

 

スパム投稿記事編

この事例は知らなかったのですが、投稿一覧画面を確認してみると、記憶にない記事が大量に投稿されており、その記事にはスパム広告が貼られているそうです。

 

原因の推測として、パスワードが脆弱だったほかに驚いたことが、初期アカウントを調べるのは容易だということです。

 

「user id 1 wordpress」というキーワードでググってヒットした下記の記事でも詳しく書いてありますが、最初作ったアカウント「author=1」のログインユーザー名はダダ漏れということになります。

 

WordPressのログインユーザー名は丸見え!?

 

対処として、該当記事の削除、パスワードの一新、ロギングを行ったそうです。

 




 

サーバ屋さんから怒られた編

レンタルサーバー側がハッキングされているのを検知し、「ファイルが改ざんされてるので、おたくのサイトを停止します」という通達がきたお話です。

 

被害

  • サーチコンソールも検知しているので被害サイトとして認定されSEOランクダウン
  • 事例はECサイトであったため、即座に売上に直結し売上がダウン

 

「サーバ屋さんから怒られた編」というタイトルから、若干ほのぼのした話かと想定していましたが、このような被害状況に陥ったら生きた心地がしないかも知れません。

 

対処として、WordPressを移設しプラグインを入れ直したそうですが、この対処もなかなかの作業です。被害の進行と対処に掛かる機会費用は計り知れないので、松本悦宜氏が紹介されていたドキュメントなどを日頃からチェックするべきかなと思いました。

 

セッション2のまとめ

そのほかにも、古い事例の改ざん系として、header.phpに読み難いコードが埋め込まれていた「メール踏み台編」、サイトやサーバーにつながらない「DDoS攻撃 DNS攻撃編」といったインシデントと対応策も紹介されていて本当に豊富な事例はためになりました。

 

最後に、ディレクターにとって興味深い話として、思わぬ事態が起きてしまったときに当然Web制作事業者はクライアントに説明責任があり、ダウンタイムや復旧費用、また、毎月/年の保守やバックアップの金銭的根拠を明確に示さなければならないなど、今後心がける部分も勉強になりました。

 

今回の登壇で使用された神垣聡氏のスライド

 

 

セッション3「まとめ」

最後のセッションは、今回のTokyo WordPress Meetup 10月のモデレーター、ちくちゅう氏。

 

ちくちゅう氏は冒頭で、クライアントから「セキュリティ 対策はどうなっていますか?」と聞かれたときにどう答えるべきか?といったノウハウを紹介。

 

今後は、「暗号化はHTTPSのみ、SFTPのみ」「WAF」「インシデント発生時のルール化」「外部メモリ禁止」といったセキュリティ 項目リストを明文化して作っておくべきと思いました。

 

また、ちくちゅう氏、セッション1の松本悦宜氏、セッション2の神垣聡氏を交えて質疑応答となりました。
以下、メモれた限りです。

 

セキュリティ維持向上に普段利用しているおすすめのプラグインは?

「WP SiteGuard」と「Crazy Bone」。

監査ログをメールで通知してくれるプラグインもある。

との答え。

また、2年以上メンテ、アップグレードされていないプラグインは危ないとのこと。

 

user_id(初期アカウント)からアカウント名が簡単に取れるということでしたが防ぐ方法はあるか?

初期アカウント防げない。

とにかくパスワードを強化とのこと。

 

脆弱診断を実行できるツールはありますか?

Walti.ioがめっちゃ便利です。定期実行でログもずっと保管

JVNというサイトでWordPressの情報が出ると注意!

あと、JSACの注意喚起も注意!

 

本体をアップグレードしたら、プラグインの動作チェックはしてますか?

正直あまりしていないが、コピーサイトを作って調べるときはあります。

 

ほか、全てをメモれませんでしたが、とても有意義な質疑応答でした。

 

今回の登壇で使用されたちくちゅう氏のスライド

 

 

「WordPressを守ろう!セキュリティの最新トレンドと対応事例」まとめ

今回のイベントに参加して下記の認識と知見を得ました。

  • OWASP(オワスプ)の存在
  • WordPressが突出してセキュリティが弱いということではないこと
  • バックドアの恐ろしさと仕組み
  • 初期アカウントを調べるのは容易だということ
  • クライアントへの説明責任
  • ダウンタイムの復旧費用
  • 毎月/年の保守やバックアップの金銭的根拠の明示
  • セキュリティ項目リストを明文化
  • 様々な脆弱診断を実行できるツール

 

久しぶりのWordBench!じゃなかった、WordPress Meetupの参加でしたが今回も楽しませていただきました。

 

キャンセル待ちも出ていたみたいで人気のテーマだったのも納得するくらい、とても身になる良いイベントでした。

 

スライドの公開が早かった(その日のうち)のも嬉しかったです。

 

また、面白そうなテーマがあったら行きたい。

 

この記事も読まれています。

WordPress マルウェアの確認と駆除作業(リダイレクトスパム)

さくらレンタルサーバーで特定のIPアドレスからのアクセスをブロックする方法

 




究極やさしい入門本『スラスラ読める JavaScript ふりがなプログラミング』




 

ディレクターがJavaScriptを基礎から学びなおす

組織の都合もあるけど、Web制作を俯瞰的に見れるよう自分のキャリアアップのためにもディレクターへシフトしたものの、Webデザイナー時代にもっと経験を積んでおけばよかったと今でも思うプログラミングスキル「JavaScript」。

 

考え方は人それぞれ違うかもしれませんが、僕の場合Web制作の仕事をしていくうえでディレクターになった今でも時折JavaScriptをマスターしたいという衝動にかられます。

 

以前、オライリージャパンから出版された『デザインの伝え方』の著者が、プライベートの時間に本業のデザインから離れクラシックカーのリペアをしているのを読んで、僕もこの夏、なにかを本業とは別の分野の研究や学習をし直そうと思っていました。

 

『デザインの伝え方』の著者Tom Greeverは、クラシックカーを弄り通して、当時のエンジニアから多くのことを楽しみながら学び、本業へフィードバックしており、クリエイティブな仕事をしている身としてこのライフスタイルに共感しました。

 

本業のWeb制作に活かせるかはわかりませんが、普段にらめっこしているパソコンやスマホから離れ、別の分野に没頭するために、はんだごてとニッパーでも買って鉱石ラジオをスクラッチ開発してみようかと思った矢先、ふらり立ち寄った本屋で面だしされていた、ある一冊の本のタイトルが目に止まりました。

 

スラスラ読める JavaScript ふりがなプログラミング

というわけで、ディレクター職がメインの僕はJavaScript(以下、JS)初心者レベルなのですが、本屋さんで『スラスラ読める JavaScript ふりがなプログラミング』という本を見かけて立ち読みしたとき、「この本なら今度は挫折しなそう」という気がして久しぶりに衝動買い。


スラスラ読める JavaScript ふりがなプログラミング (ふりがなプログラミングシリーズ)

 

別に他分野にこだわらなくても同じWeb制作の分野で身近に関わっているコーダーやフロントエンジニアのスキルの一環を学ぶのも必ず本業に役に立つ。

 

さらに、2020年度から小学校でプログラミング教育が必修化されることが明示されたことにより、自分の子どもの勉強を見てあげられるのでは?

 

と、自分に言い聞かせ、鉱石ラジオのスクラッチ開発は来年の夏休みに先送りにし、再びパソコンの画面に戻ってきました。

 

著者はリブロワークスさんで、監修は、ネット上でもフォローさせていただいているGoogleやMicrosoftを渡り歩いた日本を代表するエンジニアの及川卓也さん。

 

終始ふりがながふってあることでソースの意味を理解。

過去にもこのような教材があったのか知りませんが、この本はタイトルの通り、本書内にある全てのサンプルプログラミングのソースコードに、もれなく「ふりがな(ルビ)」がふってあるのが最大の特徴。

 

最終章まで繰り返し付きまとう「ふりがな(ルビ)」のおかげで、覚えが悪い初心者の僕でも本書をもとに学習し終わった頃には演算子、関数、変数、式の書き方や基本的なルールなどを頭に叩き込むことができました。

 

読み下し文によってさらに理解への補完に。

変数、演算子などの単語ひとつひとつに細かくふりがながふってありますが、英単語の様に、ふりがな部分だけを繋げて読んでも日本語の文法としてはおかしい状態です。

 

よって、ふりがながふってあるサンプルのプログラムの下には、「読み下し文」も記載されていて、プログラミングコードの式の理解をさらに深めることができます。

 

今思えば、もしこの読み下し文が無くふりがなだけだったら理解し難かったと思います。

 

ソースコードのサンプルをダウンロード。

1章〜5章までに本書内で出てくるサンプルのプログラムコードがダウンロードできます。

 

最初にダウンロードしたものの、僕は2ヶ月間ゆっくり時間をかけてこの本で実習したので、結局最後まで使うことはありませんでした。

 

ですが、時間が無い中どうしても記載通りに書いてるのにプログラムが動かない/エラーになる、または、4章(Chapter4)までは、テキストエディタに書いたプログラムをGoogle Chromeのコンソールを利用して動作確認をするのですが、最終章の5章(Chapter5)では、実際にHTMLファイルを作成して動かすので、うまくいかない時に差分用としてあると便利です。

 

JavaScript ふりがなプログラミングを読んで

実際のプログラムの書き方の前に、1章ではJavaScriptとはどんなものかの話から始まります。

 

JSのバージョンであるES5とES6の説明もあり、基本的に今後移行しつつあるES6に基づいて章が続きますが、ES6では対応できない書き方についても別の章で解説されています。

 

また、本書の読み進め方とJSを書くとための準備として、Web屋にお馴染みにChromeデベロッパーツールのコンソールと、テキストエディタ(Atom)を推奨していますが、僕の場合、動作を確認するためのコンソールはChromeを使いましたが、エディタは日頃から慣れ親しんでいるAdobeのBraketsを使用しました。ここら辺は使い慣れたツールでいいと思います。

 

どの章にも後半にエラーメッセージの読み解き方が紹介されており、制作実務でバグっているときに、社内の新米Webデザイナーとデベロッパーツールをにらめっこしてても理解できないことがあり、いちいちベテランに来てもらってたこともあったので、これは僕にとって良い勉強材料になりました。

 

1章の中盤、実践学習からは、いよいよ文字列の表示の書き方から始まり、その後、演算子を使って簡単な計算(四測計算)の書き方に進みます。

 

「またか」と思いました。

 

JSの個人的なイメージとして、ひと昔前は入力フォームの様にユーザーに何かを入力してもらった結果を素っ気なく表示したりといった印象でしたが、最近だとスライドショー、モーダルウィンドウ、その他スクロールエフェクトなどの華やかな動きの役割を担うプログラムの印象が強いので、以前学んだときも足し算掛け算などのこういった地味な計算から学ぶのが非常に退屈だった記憶があります。

 

しかし、「+」「-」「×」「÷」といっ演算子の使いこなしが今後重要になることを理解してきて考え方が変わりました。以前購入した技術書やネットスクールで学習をしていた頃は、この地味な計算式から覚えなければならない退屈感から挫折した記憶があるのですが、本書は2名のキャラクターイラストがストーリーを展開しており、図版や優しい色使いのせいか、緊張感なく基礎の大切さが伝わりました。

 

ちなみに、最初はエディタの入力保管機能は使わず、慣れるまで直打ちの繰り返しを徹しました。そのおかげで各章の最後のドリル問題にて、自然にコードが打てるようになりました。

 

やっぱり、何かを覚える時には書く(打つ)って大事だと思います。

 

初心者とはいえ、for文の条件分岐、while文などのループ、配列のarrayなどは、WordPressのPHPをいじっていた経験もあり比較的に理解しやすかったけど、やっぱりエッセンスというか、基本を理解していなかったので、この本でJSやプログラムの原理が学べて充実した夏の自由研究を終えました。

 

当然この本は、僕の様なディレクターではなく、これからJavaScriptを学ぶWebデザイナー、フロントエンドエンジニアの初学者におすすめです。

 

誤植について

JS初心者の僕が読み進めていると、どうしても理解できない部分があり、調べて見たら数ページに誤植があることに気づきました。

版元のインプレスブックスのサイトから確認できるので、つまずく前に確認することをおすすめします。

インプレスブックス紹介ページ
https://book.impress.co.jp/books/1117101139

 

今回紹介したJavaScriptの姉妹本で、Python版も出ていました。


スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

 

番外編:ディレクターにJavaScriptの知識は必要か?

「ディレクターはコーティングしてはいけない」という言葉を耳にすることがあるけど、その通りだと思います。

 

ディレクターの仕事は、あくまで「なるべくプロジェクトを円滑に完遂することが基本」なので役割として不当に思うし、そもそも複数のプロジェクトの舵取りの片手間にコーディングをやる暇がない。

 

一人でWeb制作の1から10を担った経験がある人なら尚更わかると思うけど、それはかなり荷が勝つことです。

 

しかし、JSに限らずPHP、HTML、CSSの知識はディレクターといえども持っていて不都合は当然ないどころか役に立ちます。理由は以下の2つ。




 

クライアントの前ではっきり可否

上流工程のクライアントとの会議において、目前のクライアントは遠慮なく技術的な質問をしてきます。

 

ディレクターだろうが、デザイナーだろうが、コーダーだろうが、なんだか知らないけどクライアントにとっては目の前にいる人間はWeb制作者に見えています。

 

PHPなどのバックエンドプログラムにもいえることですが、オリエンの時点でアサインするメンバーはほぼ決めているので、費用感や技術レベルを会議の場である程度は把握していますが、あまりに複雑で多くのパターンを要する条件分岐の要望があった際に、「この予算でこの仕様は可能か?」との質問にその場で答えられないことが多々ありました。

 

「多分大丈夫です」「宿題にします」「勉強します」とその場を切り抜けたり、その場で直接エンジニアに電話や、こっそりSlackなどで聞いたりすることもありますが、やはり即答できてミーティングを円滑に進められることが望ましいと思います。

 

プログラム上のトラブルの早期対応

納品後にプログラム上のなにかしらのトラブルが発見された時に、協力会社のコーダーにいちいち時間を作ってもらうより、その場で自分で解決策をみつけたほうがよほど早い場面もあります。

 

ただ気をつけなければならないのは、自分で直せるからといって毎回自分で作業しないこと。

 

矛盾しているかに思えますが、ディレクターには他にやらなければならない優先事項が多々あるのでタスク優先度としては低い。あくまで緊急時。エラーの原因の究明まで終えルことができたら、あとは極力エンジニアに任せた方が良い。

 

そういった意味では、前述の通り本書に書いてあるエラーの読み解き方はとても参考になります。

 

なにはともあれ、この本は社内のデザイナー達に共有しようと決めるくらいJavaScriptの入門書として良書です。




さくらレンタルサーバーで特定のIPアドレスからのアクセスをブロックする方法




 

先日、さくらインターネットのサーバーで特定のIPアドレスからのアクセスを制限した時の事例を備忘録。

 

この記事を読んでいる人は早期的に解決を望んでいると思いますので、特定IPアドレスをブロックすることになった経緯は後述するとして、とりあえず最低限の状況と条件、さくらのレンタルサーバーでのブロックの簡単な方法を足早に書いていきます。

 

条件

  • 制限対象のグローバルIPアドレスのナンバーがわかっている。
  • さくらインターネットのレンタルサーバーを利用(ちなみにビジネスプラン)。

 

事象

  • 全ての環境からWebサイトが閲覧できない。
  • もしくは、一部の環境のみWebサイトが閲覧できない。

 

さくらのファイルマネージャーから制御する

さくらインターネットのカスタマーサポートの対応はメールでも電話でもとても親切ですが、さすがにすぐには対応してくれるのは難しい。なぜなら、このようなトラブルみ見舞われている人の対応が多すぎるから。電話はすぐつながればラッキーだし、メールも問い合わせた直後に返信がくるわけではありません。

 

なので、手っ取り早くさくらインターネットのファイルマネージャーを利用して自分でアクセス制限をします。

 

※注意:ファイルマネージャー作業とはいえ.htaccessに記述されたりするので、復元できるようデータのバックアップを取っておくことを推奨します。




 

さくらのコントロールパネルにアクセス

まず、さくらインターネットサーバコントロールパネルにアクセスします。
https://secure.sakura.ad.jp/rscontrol/

 

ドメイン名とパスワードを入力し「送信する」をクリックしてログイン。

 

さくらコントロールパネルにログイン

 

左側のメニューの上から5番目「サイトに関する設定」の中の「ファイルマネージャー」をクリック。

 

ファイルマネージャー」をクリック。

 

別ウィンドウが開き、ファイルマネージャが開きます。

 

ファイルマネージャの画面

 

home/初期ドメイン/wwwのディレクトリのまま、画面上部のメニューバーの左から3番目「表示アドレスへの操作」をクリックするとプルダウンメニューが開き、「アクセス設定」をクリック。

 

「アクセス設定」をクリック。

 

ポップアップウィンドウが開くので、タブ中央の「接続元アクセス制限」を選択し、下部の「拒否するアクセスのリスト」内の「+追加」をクリック。

 

ポップアップウィンドウ

 

左側のプルダウンメニューがデフォルトの「IPアドレス」になっているのを確認し、右側の入力欄にアクセスブロックしたいIPアドレスを入力。さらにブロックしたいIPアドレスを追加したい場合は続けて「+追加」をクリック。

 

ポップアップウィンドウのIP入力

 

「OK」をクリックして完了です。

 

アクセスブロックを解除したい時

事がおさまりアクセスブロックを解除したい時は、単純に上記の逆の手順になります。

ポップアップウィンドウで追加したIPアドレスの右にある赤い「×」を押して消します。

最後に「OKをクリック。

 

.htaccessでの制御は可能か?

FTP経由で.htaccessをダウンロードして直接制御しても大丈夫か?と、一応さくらのサポートの方にと問い合わせてみたら、

 

「大丈夫です、しかし.htaccessのファイル上での操作および操作方法はサポート外です。」

との返答をいただいた。

 

特定IPアドレスをブロックすることになった経緯

余談ですが、今回かなり稀なケースであったため、同業者の人たちに向けてIPアドレスをブロックすることになった経緯を共有します。

 

とあるクライアントの全面改修案件で起きたこと。

 

SSL化してフルリニューアルしたWebサイトを公開した翌日、クライアントから

「社内でホームページが見れない」

という連絡が入り、額に汗をかく。

 

自分の会社のWi-Fi環境の内外で確認すると、なにごともなく閲覧できる。

 

先方に画面のスクショを送ってもらったところ503エラーの表示でした。

 

なぜコンテンツもほぼ一新し、リニューアルした直後に大量のアクセスがされたのか?

 

さくらインターネットのコントロールパネル内の「サーバーエラーログ」を確認すると、たしかにクライアントのグローバルIPからのアクセスが尋常ではなかった。

 

リニューアルして公開したばかりのタイミングだったので、クライアントも僕らも原因はこちらにあるのだとばかり思っていました。

 

意を決してクライアント側のシス管に調査を求めたところ、リニューアルとほぼ同時期に導入したサブスクリプション型業務系ソフトが立ち上がるたびにドメインを踏んでから起動する設定になっていたらしく、結果的に数千人の社員が同時に業務系ソフトを立ち上げるたびに自社のWebサイトへアクセスが集中してしまう事象だったらしいです。

 

原因が判明するまでは何も手をつけられない状態が続き、混乱してかなり憔悴しました。

かなり稀なケースですが、ひとつの要因としてこの件でいい経験になりました。

 

この記事も読まれています。

WordPress マルウェアの確認と駆除作業(リダイレクトスパム)

「WordPressを守ろう!セキュリティの最新トレンドと対応事例」で得た対策と知見




フルスタックWebディレクターへの指標『Webディレクションの新・標準ルール』




 

特定分野の研究は深く掘り下げるクセがあるにも関わらず、Webディレクターを始めるにあたりこの手の標準ルール本からWebディレクションを学ぶという選択肢はなぜか今までなかった。

 

ここまでなんとなく歩いてはきたけど、口コミの評判が良かったこともあり、去年(2017年)『Webディレクションの新・標準ルール 現場の効率をアップする最新ワークフローとマネジメント』を購入して、やっと最近一通り読み終える。

 

うんざりするWebディレクターのスキルの広さ

目次を読むと、あらためてWebディレクターという仕事も”身につけるべき”と思われるスキルがたくさんあるんだなーと思いつつ後ずさりしたくなる。

 

当然わくわくしながら読み進める人もいるでしょうが、たぶん、この本を手に取る人はこれからWebディレクターを始めようという人が多いと思うので、この目次の項目数の多さにおののいてしまう人もいるのではないか・・・。

 

今思えば、自分が今まで標準ルール本からWebディレクションを学ぶという選択肢がなかったのは、こういった理由だったのかもしれない。

 

しかし、そういった人もちょっと考え方を変えれば、この本は普段持ち歩くに等しい良書となる。

 

この本に書いてあるスキルを全て体得してフルスタックなWebディレクターになるのだという考え方を一時的に捨てれば。

 

「ディレクションの目的と役割」「企画」「設計」「制作・進行管理」「運用・改善」と全5章にわたり、一人前のWebディレクターになるための必要不可欠な知識が完全といっていいほどコンパクトにまとまって網羅されている。

 

最初から読み進めれば読み進めるほど、たしかにどのスキルの習得もはっきり言って捨てがたい。

 

が、エッセンシャル思考の本を読んだときにも書いたけど、ここはあえてどんどん切り捨てる。




 

Webディレクターの守備範囲は人それぞれ

どんどん切り捨てると言っても、好きなところだけを読んであとは無駄という意味ではない。

 

Webディレクターも組織の環境によって役割の守備範囲がだいぶ変わる。

 

  • ほとんどの工程を内製できるWeb制作会社
  • 企画立案がメインの上流工程を主体としたマーケティング会社
  • メーカーのマーケティング部門、並びにインハウスWeb制作部隊
  • 印刷・製版会社の中のWeb制作事業部隊

 

自分のバックグラウンドも大きく影響するが、周囲の環境によって守備範囲が変わるのは物理的にも避けられない。

 

特に、比較的にWeb制作のリテラシーが高くないと思われる印刷・製版会社では、組織と自分(たち)との狭間で根本的な考え方の違いで苦悩と奮闘の日々を送ることになることが想定される。

 

ポジティブな行動として組織改革が考えられるが、そこに労力を費やす余裕はこの本を読んでいる時点ではきっとない。

 

人それぞれに合った効率的な読み方

したがって、その環境・案件に適用するスタイルを確立するためには、今の自分に絶対的に必要な知識からチョイスして読み進めることをおすすめする。

 

チョイスをしたら、その分野を別の本なり、勉強会なり、ネットなりでもっと深く掘り下げていけばいい。

 

当然、最初から最後まで一読しても面白くて有用な内容だけど、もはやWeb制作会社だけにWebディレクターがいるわけではない現在において、こういったチョイス方法は相応かと思う。

 

本書CHAPTER 1でも、事業会社の社内ディレクターの役割と必要なスキルセットも紹介されているほどだし、しつこいようだが、Webディレクターは受託会社だけに存在するわけではない。さらにUXなどの人間中心設計についても科目として取り上げられているあたりが、今回の標準ルールに「新」をつけた理由のひとつなのだろう。

 

繰り返しになるけど、この本は立派なWebディレクターになるために必要な知識が完全といっていいほどコンパクトにまとまって網羅されているので、現在のWebディレクションに関するスキルセット内容を俯瞰的に把握できるという点もこの本の特徴のひとつ。

 

そういった意味では、一人前のWebディレクターへの道を計画的にロードマップを立てるのにも使えると思った。

 

好きなところから読み進め、何かの壁にぶつかった時に開けば助け舟にもなるかもしれない。


Webディレクションの新・標準ルール 現場の効率をアップする最新ワークフローとマネジメント

 

この記事で紹介しているのは『現場の効率をアップする最新ワークフローとマネジメント編』です。

 

『システム開発編 ノンエンジニアでも失敗しないワークフローと開発プロセス』というのもあるので、気をつけてください。


Webディレクションの新・標準ルール システム開発編 ノンエンジニアでも失敗しないワークフローと開発プロセス

 

とはいえ、この開発編も非常に気になりますが。

 

本質を押さえてから

と、ここまで偉そうに書いてきたけど、本書の冒頭に以下の文章がしっかりと書いてある。

 

(省略…)では、上記(様々な技術や知識を要すること)を満たすため技術に長けたフルスタックなWebディレクターでなければならないのか?もちろんできればそれに越したことはないが、それがWebディレクターの本質ではない。……

 

前述のようにどこから読み進めるべきかは人それぞれだが、サブタイトルに「現場の効率をアップする最新のワークフローとマネジメント」とあるように、物事(プロジェクト)を円滑に進行することに重点を置く思考こそが、やはりWebディレクターが最初に身につけるべき最優先事項なのではと思う。

 

必要なテクニックが多く網羅されているともいえるのだが、「ディレクターはこうあるべき」という思考はとても大事で、本質を捉えてから多くのことを学んでいってっも遅くはない。

 

むしろ、このエッセンスを理解していないと、のちに多くのスキルを身につけていく過程で自分が何者だかわからなくなるという、急に自分探しの旅に出なくてはならなくなるという恐れがある(自分がその傾向にあった)。

 

ちなみにまったく別の本のだけど『ディレクション思考』という本はWebディレクターのエッセンスを刷り込むのに大変おすすめ。

 

初歩的な問題から効率化を図るテクニックまで

最後になって気になる内容についてだが、各科目についてははっきり言ってAmazonのなか見!検索を見ていただいた方が手っ取り早い。そこで目次も見ることができる。

 

本質を理解したうえでも、いざWebディレクターとして実際に走り始めてるとミクロな部分ですぐに壁にぶち当たる現実。

 

  • キックオフミーティングの開催はいつ?
  • どのサーバーを選べばいいのか?
  • 工数計算の算出法は?
  • MacだからExceでドキュメントを作ったことがない・・・
  • DNSって?公開のタイミングがわからない・・・

 

上記のような初歩的な問題から、「見込み案件の見極め」「運用後の課題管理」「商流のパターン」「Webサイトの検収の見極め」といった、さらに効率化を図るテクニックやリスクマネジメントまで。

 

そういったリアルな現場で直面した時に役にたつ対処、習得しておくとディレクションがさらに効率よくなる知識が、見開き2ページ単位で具体的に紹介されている。

 

僕は最初この本を知り合いから借覧していたが、現在はKindleで購入しMacBookでいつでもどこでも引けるようにしている。




オライリーの『デザインの伝えかた』はディレクターも読むべき




 

プログラミング系の技術書でエンジニアにおなじみのオライリー出版のUXデザイン本シリーズ。

 

ステークホルダーにデザインの意図を正しく伝え、承認や合意を得ることは最適なUXを実現する

 

序盤はUXがもたらした近年のデザインの役割変化についてを振り返り、そして有効なコミュニケーションがデザインの決定過程においてどれほど必要不可欠なのか理解を深めてから、内容の濃い本題へと突き進んでいく。

 

Webサイトやアプリの制作を依頼をしてくるのはクライアントだったり自社の役員だったり。

 

他にも、一緒にプロジェクトのゴールへと向かうエンジニアやプロジェクトマネージャーなど、避けようのないステークホルダー(非デザイナー)たち相手に、デザインの専門家であるデザイナーが事業課題解決のためのデザインの意図をどう伝えることができるのか?

 

多くの修羅場をくぐってきたデザイナーである著者のTom Greever(トム・グリーバー)は、緊迫したステークホルダーとの戦略会議をS会議(ステークホルダー会議)と称し、非デザイナーとの接し方、考え方、会議に向けての準備や予防策、その場での対処法やステークホルダーの分析などを自身の豊富な経験の中から実例を交えてS会議の成功法を解説していきます。

 

1章にて、若き日のTom Greeverが、ある企業への就職活動で、マーケティング担当副社長との最終面接のやりとりの場面が印象的でした。

 

副社長は、

 

私が新しいプロジェクトを始めて、あなたに発注しようか検討しているとします。あなたなら最初に何を訪ねますか?

 

という質問に対し、Tom Greeverは、

 

印刷物ですか?ウェブサイトですか?カラーですか?白黒ですか?〜省略、そのウェブサイトあるいは印刷物は、何ページになりますか?納期は?

 

に対し、副社長は、

 

それでは困りますね。一番最初に尋ねるべきは『何を伝えたいか』でしょう

 

この『何を伝えたいか』という核心的な一言こそが、デザイナーのエッセンスなのかなと思いました。

 


デザインの伝え方

 

1章の実例と一言を念頭に置いて読み進めると、後に続く本題であるステークホルダーとの有効なコミュニケーションの具体的な実例や解説が全て紐付けられながら理解できると思います。

 

この本は、対ステークホルダー対策というだけではなく、デザイナー自身が自分の役割の一つとしてコミュニケーションの大切さを認識でき、「基本的にクライアントやステークホルダーはわがままで面倒臭い」という印象を持っている人は、読み終えるとだいぶ考え方が変わってくると思います。

 

自分が中心となって先導していくプロジェクトであっても、それは単に立場上の役割なだけで、ステークホルダーからしてみればデザイナーもステークホルダーなわけで、自分だけが正しいという考えではいけない。という忘れがちだったスタンスにも気づく。

 

一歩会社を出れば、ステークホルダーもデザイナーと同じ人間。

 

非デザイナーがデザインに触れる機会といえば、インターネットやスマートフォンが登場する以前は、駅や電車内の広告、好きな美術展やライブのポスターやチラシ、書籍の体裁などでしたが、今やWebサイトにアプリといった日頃の生活や人生に欠かせないUIツールを操作しながら毎日デザインに触れているといえます。

 

なので、いまの時代は非デザイナーでも自分が触れてきたUIデザインの経験がそのまま意見となりやすいのだが(それは悪いことではない)、やはりコンバージョンへの導線や、プロジェクトの目的を見失いがちになってしまうのもクライアントであり、ステークホルダーであり、非デザイナーであり、さらに言えば同じ人間。

 

戦略的で意図的なデザインに対してのステークホルダーのブレを軌道修正し、合意や承認を得るのに必要なのがデザインを伝え方である。

 

ここまで読んでいただければ、Webディレクターの方が読んでも面白い本だと思ってもらえると思います。

 

Webディレクターにとって女房役とも言えるデザイナーとの接し方、そのデザイナーのデザインに合意し、クライアントへの説明やその場での軌道修正に挑むことを考えると、Webディレクターにもおすすめです。

 

ちなみに、別の方の書評でも書いてありましたが、この本は翻訳がとても丁寧で分かりやすく、ステークホルダーへの具体的な発言例などの語彙は、そのまま実戦でも使えるようになっています。

 

数あるUX/デザイン系のオライリー本の中でもかなりの良書。




UXデザインセミナー『UX Bridge vol.5』に行ってきました。

UXデザインセミナー『UX Bridge vol.5』



 

BtoB/BtoBtoCサービスにおけるUXをテーマにした勉強会『UX Bridge vol.5』に行ってきました。

 

去年の『UX Bridge vol.2』では、新人のデザイナーを連れて行くことが一番の目的でしたが、本人は補欠から繰り上がらず落選。叶わず。

 

しかし、今回は、去年連れて行けなかったデザイナーと、今年入社したばかりの新人デザイナーの2名を連れて参加することができました。

 

参加した動機

  • 前回同様、前線で活躍しているデザイナー、フロントエンジニア、プロダクトマネージャーといった様々な役割の方々の視点で、UXデザインの取り組みや考え方、ビジネス上でどのような価値をもたらしているか?といったお話が聞けること。
  • 自分が所属する組織・チームの各役割のメンバー達に、自分の立ち位置からUXデザインの価値を、僕の言葉ではなく、外部の方々からの言葉で知ってもらいたかった。

 

良いUXデザインをする為に必ず必要とされる事

良いUXデザインをする為に必ず必要とされる事

 

業務では主に自社サービスのUXとUIの改善業務を担当しているUI/UXデザイナーの大村真琴氏。

 

良いUXデザインをする為に必要とされる事とは、スタッフエクスペリエンスとのこと。

 

要は、ユーザーに対するUXを向上させるためには、まず自チームや組織に対してエクスペリエンスデザインを施してから、ユーザーに良いUXを提供する。

 

大村氏は、テモナ株式会社に参画した際に初めてそれに向き合ったそうで、組織、人、文化、業務フロー、思考というキーワードをあげ、スタッフエクスペリエンスを実施した例を紹介していました。

 

ディレクターとはUXにおける問題点・課題点をすり合わせ、双方に学びや意思疎通、共通認識を増やす話のほかに、エンジニアとのコミュニケーションをピックアップしていました。

 

以前のエンジニアさんは、改善指示に対し黙って従う傾向にあり、ここにUX/UIのことを知れる絶好の機会をエンジニアが逃していると危惧していたとのこと。

 

実案件の中で改善指示を出す際は(おそらく)プロジェクトの背景やゴール、UIを改善することの意図を説明し、勉強会などを行わなくとも意思疎通や共通認識を高めることができたそうです。

 

とても良いアイデアだと思ったのは、セルフユーザビリティテストの実施方法。

 

プロジェクトチーム以外の社内の人たちにセルフユーザビリティテストを実施する際、「バグコンテスト」という告知ポスターを作成。セルフユーザビリティテストを社内イベント化し、他部門の人たちには業務以外のタスクが増えるといった印象を払拭したアイデアはいつか真似したいと思いました。




エンジニアがUXをロジックで考えてみる

エンジニアがUXをロジックで考えてみる

 

株式会社サイバーエージェント AdTech Studioの折原レオナルド賢氏は、エンジニアらしいロジカルな視点で管理画面の改善にあたった話などをされていました。

 

A〜Eまでページを遷移するタスクがあった場合のタスク完了までのユーザーの迷い度を、

 

  • N:ユーザーがタスク実行中に閲覧した異なるページ数(ユニークビュー)
  • S:ユーザーがタスク実行中に閲覧したページ数(ページビュー)
  • R:ユーザーがタスクを完了するための最短ページ数
  • L:迷い度

 

として数式に表し、複数あるタスク完了までの各ルートの迷い度を導きだす話が印象的でした。

 

その他にも、カードソートの集計にクラスター・デンドログラム(たぶんクラスター分析)の説明など、個人的には折原氏の登壇が一番興味深く、もっと詳しく話を聞きたいと思いました。

 

UI/UX カイゼンチーム始めました

UI/UX カイゼンチーム始めました

 

株式会社SmartHRから、デザイナーの渡邉氏、フロントエンドエンジニアの渡邉氏の同じ苗字の2名が登壇。

 

UX/UIに強いメンバーでカイゼンチームを立ち上げた経緯に、

 

  • プロダクト専任のデザイナーがいない。
  • エンジニアがBootstrapでUIを決定していた。
  • 当時のリソース・フェーズだとそれが正解。

 

といったことをあげてて、同行したWebデザイナーと自チームでのあるある話すぎておもわず笑みがこぼれた。

 

様々な改善例を紹介していた中で、会員登録へのタスクが斜格的すぎて、会員登録までの道筋案内の問い合わせがユーザーから殺到した時の改善例がグッときました。

 

ドロップダウンメニューに隠れていた会員登録へのリンクをグロナビに置いただけでは問い合わせは減らなかったが、最終的に罫線で区切り、並列から分類したことにより問い合わせが激減した成功例。

 

マイクロコピーじゃないけど、こういった細部のちょっとした修正で改善される成功例はつくづく素晴らしいと思う。

 

もちろん両名とも試行錯誤の努力と情熱が前提にあるのですが、僕は色んな知識を蓄えすぎて難しく考えすぎるクセがあるのだと今回の話で認識できてよかった。

 

感想

今回もデザイナーとエンジニアの視点から色んな考え方や取り組みを聞けて面白かったのですが、UXというよりも比較的UIやユーザビリティの話が多いという印象を受けました。

 

しかし、ワークフローやチームビルディングにおいて、やはり自分たちの環境だけが恵まれていないというわけではなく、どの組織も様々な課題を抱えており、その問題解決への素晴らしい工夫を聞けて収穫になりました。

 

同行した新人デザイナー達にも、自チームの問題や、Webサイトの改善に対して意欲が湧いているのが帰り道に感じられた。

 

UX Bridge vol.5




 

ユーザーに行動を促す『ザ・マイクロコピー Webコピーライティングの新常識』




 

昨年、SNS上でお世話になっているWebディレクターの方が紹介していたザ・マイクロコピーという本を読んでみて、サイト制作の参考になった。

 

文字伝達情報である「コピー」は、様々な広告やWebサイト上に見られるけど、「マイクロコピー」とはどの部分にあたるのか。

 

マイクロコピーは、主にアプリやWebサイト内のボタン上やボタン付近といったCTAまわり、入力フォーム内などにあるユーザーに重要な行動を促すための少ない文字。

 

この本は、サイトのコンバージョンに左右するそういった細部のコピーライティングのノウハウを、数々のマイクロコピーの実践・ABテストをおこなって結果を出してきた著者の株式会社オレコンの山本琢磨氏が、豊富な事例と多くの図版を使用し、やさしく専門的に紹介している。


Webコピーライティングの新常識 ザ・マイクロコピー

 

たった数文字にユーザーのコンテキストを考える。

一時期、ランディングページ制作においてコンバージョンポイント、コンバージョンエリアなどと呼ばれているエリアのデザインを研究していた時は、ボタンの大きさ、色や形、ボタンまわりの装飾や出現のタイミングといったことばかりに気をとられていました。

 

ユーザーの不安、懸念、疑問、迷いを払ってあげる、ちょっとした文章をCTAに添える、もしくはリライトすることでユーザーの行動は劇的に変わる。

 

コストがかかるデザイン変更や、HTML再構築といった改善実装の前に、ユーザーの前後関係、状況を見直した、たった数文字のリライトや文言追加で結果が変わるのがマイクロコピーの特徴だと思った。

 

マイクロコピーの力が発揮できるのはCTAまわりだけではない。

商品注文、問い合わせ、会員獲得といったところだけではなく、メニューやナビゲーション、ローディング画面、メール内などにも、その状況において適切な”思いやりの語りかけ”が有効。

 

わかりやすかったのが404ページのカスタム。404ページは、ユーザーが目的のページにたどり着けなかった際に「お探しのページは見つかりませんでした」と表示される、あの残念なイメージのページ。

 

ページが見つからないことを伝えるという常識的なことだけではなく、コンテンツにたどり着けなかったユーザーに対し、そこで行き止まりにさせないようにトップページリンク、サイト内検索、商品一覧といった道を作り、そしてモチベーションダウンさせない協力的な姿勢を示したコピーでインタラクションにつなげる。

 

上記のように、直帰率を下げるために404ページに工夫をこらすSEOテクニックが存在しますが、ここでの手法がマイクロコピーとの結びつきが強いことが証明されていた。

 

細部までこだわってナンボ。
何かしらの結果を出すUIとして機能しなければならないWebサイトの制作者に大変おすすめ。