seminar_direction.pdf

WEBディレクション  マスター講座  現場もクライアントも気持ちよく進行する秘訣 

目次  • WEBディレクターとは  • WEB制作プロジェクトの全体像  • WEBサイトの企画と設計  • WEBサイトのデザインと開発 

自己紹介  • 松山佳代子  • フリーランスのWEBディレクター  • クーポンサイト、求人サイト、クックパッドのディレクターをしていました  •
老舗の制作会社でセールスもやってました  • ディレクターの仕事は独学と現場で覚えたタイプです（だいたいみんなそう）  • デザインは「良し悪しの言語化ができる」、コーディングは「書いてあることの修正ができる」くらいのレベルです 

皆さんの今の役割と、  これからやっていきたいことがあれば教えて下さい  Q. 

WEBディレクターとは 

ディレクターにもいろいろいる 

業種によってディレクターの役割が変わる  • 自社サービスを作っている会社のディレクター  • 制作受託会社でクライアントのサイトを作っているディレクター  • 広告代理店でプロモーションサイトを作っているディレクター  • メディアの記事を編集・執筆しているディレクター  今回 

基本のスキルを３つだけ 

① リリースから逆算して  スケジュールを組む 

①リリースから逆算してスケジュールを組む  • 案件の打診がきたらいちばんに確認するのがリリース日  • 作りたいものの規模感を把握して、リリース日までの営業日数×工数で制作できるかを確認する  • ペライチのLPで２・３週間〜、コーポレートサイトのような静的サイトで３ヶ月〜、大規模サイトなら６ヶ月〜は欲しいところ  •
無茶なスケジュールはミスや遅延を生むので、制作メンバーを守るためにもきちんと交渉しておく  • 営業がいれば営業に交渉してもらうこともある 

②優先順位をつけて、  「やりたいこと」と「できること」を調整する 

②優先順位をつけて、「やりたいこと」と「できること」を調整する  • WEBに詳しくないクライアントの場合、工数がどれくらいかかるのか想像できないことがほとんど   • そして「やりたいこと」はどんどん出てくるのが普通   • 「やりたいこと」が「できること」＝「工数」を上回ってしまったら、「やりたいこと」に優先順位をつ
ける  ◦ 「やりたいこと」によって得られる効果は？  ◦ 「やりたいこと」にかかる工数はどれくらい？  ◦ 「やりたいこと」は別の手段で代替できないか？  ◦ クライアントにとって「やりたいこと」の重要度はどれくらい？  • 要望をのむ場合は、「ここまではできますが、ここからはできません」、「これを優先する場合、こういったリスクがあります」と事前に握っておくのがとても大事 

③ 学び続ける 

③学び続ける  • WEBの技術は日進月歩、トレンドも移り変わる  • ディレクターは技術者ではないのでデザイナー・コーダー・エンジニアに技術的な知識では勝てない。それでも彼らに仕事を振らねばならないのがディレクター  • だから、学び続ける姿勢が大事  • もはや「調べる」→「判断する」がディレクターの仕事かもしれない… 
• わからないことはとりあえずググってみる  • 新しい技術は皆も初めて触るから、やったもん勝ち 

ディレクターの基本スキル３つ  1. リリースから逆算してスケジュールを組む  2. 優先順位をつけて、「やりたいこと」と「できること」を調整する  3. 学び続ける  まとめ

WEB制作プロジェクトの全体像 

WEB制作の流れ  提案と受注  企画・設計  デザイン  コーディング  運用  受注提案
提案アップテスト今日お話する範囲 

WEB制作のステークホルダー  クライアント  （現場担当）  クライアント  （意思決定者）  ライター  デザイナー  コーダー  プログラマー  クライアント 
制作チーム  営業  （プロデューサー）  ディレクター 

クライアントコントロールのコツ  • 最終意思決定者を見極める  • 現場担当者が社内で顔が立つようにする  • WEBに詳しくないクライアントの場合は、専門用語を使わずわかりやすく説明する  • 説得したいときは、メリット・デメリット、代替案を用意しておく  •
クライアントの要望に譲歩する場合、できることとできないことの線引き・リスクの明示をして握っておく  • できるだけ文書で記録を残す 

制作チームに気持ちよく動いてもらうコツ  • 制作チームがディレクターに求めていることは「決めてくれる」こと  • クライアントの要望と、技術や工数の都合が食い違うことはよくある  • クライアントの要望や制作チームからのフィードバックを相手方にそのまま伝えるのではなく、自分の中で天秤にかけて結論を出してから、調整を行う  • 度重なる修正はメンバーの心理的な負担になるので、ときにはストッパーとなって
チームを守る  • クライアントが修正依頼をしてくる理由を見極めると吉 

ディレクターは常に板挟み  調整がうまくいったときの達成感  でメンタルを保つ 

WEBサイトの企画と設計 

WEBサイトの企画とは？ 

作る成果物から考えると  やることがイメージできる 

①ヒアリングシート 

ヒアリングシートとは  • クライアントの初期要望を聞き出してまとめたもの  • サイトを作る目的、方向性を決める第一ステップとなる  • 「WEB制作ヒアリングシート」とかで検索するとフォーマットが落ちてたりする  • 受注の段階ですでにヒアリング済のこともあるが、キックオフMTGの際に顔合わせの意味も含めてディレクターから不明
点のヒアリングを行うことが多い 

クライアントのビジネス構造を理解する  • 上場会社であれば、IR情報のページから決算説明資料（パワポ形式のもの）を読むのがいちばん  • 「どんな顧客」に「何を」売っているのかを把握するだけでも、どんなサイトを作るべきか見えてくる  • わからないことはクライアントに聞く 
• 現状のサイトも一通り見ておき、サイトの課題の仮説を立てておくと質の良いヒアリングになる    ヒアリングの前に…  https://www.amazon.co.jp/dp/B073PSGWDK/ref=dp-kindle-redirect?_e ncoding=UTF8&btkr=1

サイトの目的・KPI・ターゲットを定める  • サイトの目的とKPIを決めていないと、リリースした後に「なんのためにやったんだっけ？」となり、効果測定ができない  • 効果測定ができないと、サイト制作のROI（投資対効果）が出せない、運用が続かない…となりがち  • ターゲットを明確に定めることで、そのユーザーの行動やニーズを解像度高く想像できるようになり、「刺さる」サイトになる 

KGIとKPIとは  • KGI（Key Goal Indicator）が最終目標で、KPI（Key Performance Indicator）はKGIを達成するための中間指標  •
例えば、ECサイトにおけるKGIが売上だとしたら、KPIは顧客数や顧客あたりの売上金額になる  • 要はそのサイトが追っている数字が何なのかを把握できればOK  画像出典何が違う？KPI、KGI、そしてOKR　目標達成のための設定のコツとは？ https://data.wingarc.com/what-is-kpi-kgi-3956

ペルソナと  カスタマージャーニーマップ  • ユーザーの特徴を超具体的に書き出してみるとそのユーザーの思考や行動を追体験できるので、コンテンツの精度を高めることができる  • 年齢・性別・職業・年収・家族構成・趣味をはじめ、インターネットの使用状況といった細かな行動も書き出してみる  •
対象となりそうなユーザーにインタビューを行ってみるのも効果的  • ユーザーがその商材と出会い、行動を起こすまでの一連の過程を表にしたものがカスタマージャーニーマップ  • 昔よりもユーザーとの接点が複雑化してきているので、ユーザーの行動を点でなく線で捉えるようになった  画像出典『はじめてのカスタマージャーニーマップワークショップ』著者が語るマップ作成のポイントは https://markezine.jp/article/detail/29298

②要件定義書 

要件定義書とは  • 制作するWEBサイトの仕様を詳細にまとめたもの  • おおまかに、サイト要件・機能要件・システム要件などがある  • この定義書から漏れているものは原則として実装されないものとして、文書の変更履歴まで管
理される（こともある）  • こちらも「要件定義書テンプレート」とかで検索すると落ちてたりする 

要件定義書の項目（抜粋）  • サイト要件  ◦ Webサイト制作の背景   ◦ Webサイト制作の目的   ◦
ターゲットユーザ  ◦ ターゲットブラウザ・OS   • 機能要件  ◦ ユーザー向け機能  ◦ 管理者向け機能  • システム要件  ◦ インフラ要件  ▪ 本番環境・開発環境について   ▪ サーバ構成やドメインについて   ▪ データベースについて   ◦ セキュリティ要件  ▪ SSL  ▪ パスワード管理  ▪ 脆弱性対策  ◦ 非機能要件  ▪ ユーザビリティ・アクセシビリティについて   ▪ 品質・性能要求について   • 開発手法  ◦ 開発言語について  ◦ ソフトウェアについて   ◦ バージョン管理について   • プロジェクト管理  ◦ スケジュール  ◦ 会議体  ◦ 納品物・納品場所・受け渡しについて   ◦ プロジェクトメンバー   • 画面遷移図（サイトマップ）   • 保守・運用  ◦ システムダウン  ◦ 更新頻度 

全部は大変なので… 

これだけやります  • サーバーとドメインとは  ◦ WEBサイトが表示される仕組み   ◦ ドメインとは  ◦ HTML・CSSとプログラミング言語の違い
  ◦ ではWordPressは？   • 画面遷移図を作る  ◦ サイトマップとの違い   ◦ ツールを活用して時短する    

サーバーとドメインとは 

WEBサイトが表示される仕組み  1. ユーザーが、ブラウザから閲覧したいサイトをリクエストする  2. 閲覧したいサイトが格納されているWEBサーバーが、HTMLファイルやCSSファイルをユーザーのブラウザに返す  3.
ブラウザが受け取ったファイルを処理し、ページを表示する  出典　国民のための情報セキュリティサイト「ホームページの仕組み」 http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/service/03.html

ドメインとは  • HTMLファイルをもらうためには、サーバーの住所が必要  • サーバーの住所は「IPアドレス」と呼ばれ、もともとは「124.124.124.124」のような数字の羅列  • 数字の羅列だと人間が覚えにくいので、文字
列にしたのがドメイン  • ドメインと本来の住所（数字の羅列）をつなげているのがDNS（ドメインネームシステム）  blog . example . co . jp / diary  サブドメイン  サードレベルドメイン  セカンドレベル  ドメイン  トップ  レベル  ドメイン  ディレクトリ 

HTML・CSSと  プログラミング言語の違い  • HTMLとCSSは、正確には「プログラミング言語」ではない  • プログラミング言語は何かしらのデータを制御することができるが、HTMLやCSSは「文書構造」を示したり「装飾」するだけ  • プログラミング言語は、JavaScript・PHP・Ruby・javaなど 
• 様々なWEBサイトは、プログラミング言語とHTML・CSSの組み合わせで作られている  SNSの投稿はわかりやすい「データ」の例 

ではWordPressは？  • WordPressはサイト作りが簡単にできるパッケージの名称  • PHPというプログラミング言語がデータベースとのやり取りを担当する   • 「投稿」データや「ユーザー」データを格納しているのがデータベース 
• PHPによってやり取りされたデータを、HTMLとCSSで見た目を整えて表示している    記事のデータください  記事読みたい  記事ページのファイル送ります  はい、  これ本文とタイトル  はい、HTML とCSSファイル  投稿ページ表示します 

画面遷移図を作る 

サイトマップとの違い  • 画面遷移図はサイトを作っている人が見るもの、サイトマップはユーザーが見るもの  • 画面遷移図はページとページのつながりを見える化し、作るべきページ・機能を把握するのが目的  • サイトマップはユーザーが見るので、目的とするページがどこにあるのかをガイドするのが目的 
• なお、SEO目的で設置するsitemap.xmlというファイルはまた別にあります  画像出典　「Sketchで簡単に画面遷移図が作れるプラグイン、 UserFlows」 https://bagelee.com/design/sketch/create_userflows_with_sketch_plugin/

ツールを活用して時短する  • パワーポイントでも書けるが、AdobeXDや Sketchといったツールを使うとテンプレートが充実していてかなり時短できるので積極的にマスターしたい  • 画面遷移図に必要な情報は、ページの名称・ページ遷移を表す矢印・アクションとトリガー
（例：メール送信と送信ボタン）  • 主要なページ（例：記事カテゴリトップと記事詳細）を優先する  • 同時にナビゲーションも考えておくとワイヤーフレームの段階で手戻りがない 

③ワイヤーフレーム 

ワイヤーフレームを描いたことがある✋ 

ワイヤーフレームとは  • そのページに載せる情報を実際のページの大きさに合わせてレイアウトしたもの  • ワイヤーの段階でクライアントの確認をとることで、いきなりデザインに入るよりも手戻りを少なくできる  • デザイナーの手腕によっては、載せたい情報とエリアだけ指定すればよしなにレイアウト＆デザインしてくれることも… 
• ディレクターは、そのページに載せるべき情報が何かを気にしておく  • できるだけ実際に近いダミー文言を入れると、情報の過不足や最適な文字数に気づける   

ワイヤーフレームを描く3つのコツ 

①ナビゲーションパーツを先に置く  1. PCの場合はページレイアウトを決める（シングルページ／カラム／タイル）  2. ヘッダー・フッター・グローバルナビゲーションなど、ほぼすべてのページで共通して使われるエリアを配置する  3. 画面遷移図を見て、ページ間の遷移が成立するように
リンクを配置する  4. メインエリアに載せる情報を洗い出し、整理して配置する  画像出典「はじめてのUIデザイン」P.29　吉竹遼・坪田明・池田拓司・上ノ郷谷太一・元山和之・宇野雄著    

②情報アーキテクチャの概念を知る  • ユーザーに的確に情報を伝えるために、情報を整理し、導線を設計する技術  • 情報を整理する軸として有名なのがLATCH法  出典「IAシンキング WEB制作者・担当者のためのIA思考術」P.32　坂本貴史著  
 

料理レシピを分類する切り口を考えてみる  Q. 

材料は？  誰が作る？  栄養は？ 

ユーザーがクリックしたくなるラベル名をつけてみる  Q. 

情報の切り口がラベルになり、  ナビゲーションになる！ 

③他社サイトを見る  • デザインをまとめたサイトを眺めてみる  • 作ろうとしているサイトと似ているビジネスをしている会社のサイトは特に参考になる  • 他社サイトのページを見たままトレースしてみると、なぜその情報がそこに配置されているのか考えるきっかけになる 
• 他社サイトのサイトストラクチャを書き起こしてみると、カテゴリや導線がつかめる      出典「IAシンキング WEB制作者・担当者のためのIA思考術」P.65 坂本貴史著    

デザインは  「センス」ではなく「ロジック」 

「なぜこうした方が良いのか」を  言語化できれば、  クライアントも納得する 

WEBサイトのデザインと開発 

デザインカンプを起こす 

デザインの修正をなるべく少なくしたい 

イメージに合う他社サイトを列挙する  • カンプ制作後に「イメージと違う」となった場合、デザイン工数にもデザイナーのメンタルにもダメージを与える  • クライアントの頭の中にあるサイトのイメージを引き出すため、参考にしたい他社サイトを教えてもらう  • 参考にしたいサイトと、「これは避けたい」というサイトを
両方挙げてもらうと良い  • 参考にしたい点を言語化し、「こういう点を取り入れたいのですか？」と確認しておくと更に良い  • ギャラリーサイトは検索するとたくさん出てくる  出典  I/O3000 https://io3000.com/  

デザインの方向性を言葉で表してみる  • ロゴを制作するときにも使える手法  • そのサイトのイメージを言葉で表してみます  • 形容詞でも名詞でもOK  • 例　「かっこいい」⇔「かわいい」 
• 例　「洗練された」⇔「素朴な」  • 例　「格調高い」⇔「ポップな」  • 言葉から連想される画像をPinterest等で探してムードボードを作成してみるのも良い  画像出典「なるほどデザイン」P.86 筒井美希著  

❏ レイアウト  ❏ ファーストビューに重要な情報が含まれているか、もしくはページを読み進めたくなるか  ❏ 視線がFの字を描くように動くことを意識しているか  ❏ レスポンシブサイトの場合、スマホ（とタブレット）表示を考慮にした構造になっているか 
❏ （コンバージョンがある場合）コンバージョン導線がわかりやすいか  ❏ ユーザビリティ  ❏ クリック（タップ）できる箇所はクリッカブルに見えるか、ホバー時のデザインがあるか  ❏ 「詳しくはこちら」のような抽象的なラベルではなく、「商品詳細」のような具体的なナビゲーションになっているか  ❏ 文字  ❏ フォントサイズは適切か  ❏ デザインに合ったフォントを選択しているか、そのフォントが実装可能か、可読性がたかいか  ❏ タイトル・見出し・本文で文字ジャンプ率が適切に設定されていて、サイト全体で統一されているか  ❏ 文字量が適切か、改行が行われていて読みやすいか  ❏ 文字数が標準範囲内の時だけでなく、短い場合・長い場合も考慮されているか  ❏ データがない（記事が0件など）場合のデザインが用意されているか  ❏ 色  ❏ 色数が多すぎないか  ❏ 注目したい箇所が目立つ配色になっているか  デザインをチェックするポイント 

コーディングする 

コーディング指示  • デザインカンプは静的ファイルなので、動的な動きを実現したい場合は追加で指示をしておく  • 原則として、デザインカンプを見ただけでは想像できないような挙動に対して指示をしていく  • コピーしたデザインファイルに直接指示を書いてOK（指示したい場所が伝わりやすい） 
• JavaScript等で動きをつけたいときは、参考にしてほしい動きを含む他サイトのURLや、実装方法を解説したサンプルのページを共有しておくと伝わり易い  • それでも指示漏れやすり合わせることが後から出てくることはよくある。コーダーさんに「実装にあたって疑問がでてきたら遠慮なく質問してください」と伝えておく  出典  コーディング指示書の書き方！Web制作の入稿前にディレクター・デザイナーが確認したい5つのこと   https://fastcoding.jp/blog/all/direction/codingspec/  

テストする 

テストでチェックするポイント  • ここでいうテストとは、サイト上の挙動が想定通りかどうかを確かめること   • 正常系・異常系という概念を知っておく   • どんなテストをしたのか、そのテストの結果
がどうだったかをまとめてクライアントに納品する  • テストでバグが発覚したらバグ管理表に記載し、影響度が大きい順に直していく   • コーダーやエンジニアがテストをしているものの、最終納品前にはディレクターもなるべくテストに参加したい   ❏ テスト環境  ❏ デバイス  ❏ ブラウザ  ❏ テスト環境か、本番環境か  ❏ ディレクターがよくやるテスト内容   ❏ リンクの遷移先は正しいか  ❏ JavaScriptが意図通り動いているか  ❏ 投稿や問い合わせフォーム  ❏ 最小/最大文字入力数の前後で正しい挙動をするか  ❏ エラー判定が機能しているか（半角/全角、記号、機種依存文字）  ❏ エスケープ処理が行われているか  ❏ URL  ❏ パラメータを削除したり、存在しないパラメータを入力したときに意図した挙動になるか 

本番環境にアップする 

最後にもう一度テスト  • 開発環境・ステージング環境では問題なかった挙動が、本番環境にリリースしてみると思わぬバグが発生した、ということはよくある  • クライアントに報告して「ここ動いてないよ」と言われるのはつらいので、リリース連絡をする前にもう一度全体の動きを確
認する  クライアントにバグを指摘されると息が止まりそうになる  

おすすめの参考図書1  • 『WEBディレクション標準スキル』　https://amzn.to/2Hc1ofX   2012年出版なので情報がちょっと古いのですが、ディレクターに必要な知識が網羅されています。今回のセミナーにあたって最も参考にしました。   • 『IAシンキング
Web制作者・担当者のためのIA思考術』　https://amzn.to/2HdNV7r   情報アーキテクチャについての解説本です。これ一冊読めば情報設計できるようになります。実践で役に立ちそうなところだけ拾って読んでも大丈夫です。   • 『ユーザ中心ウェブビジネス戦略顧客心理をとらえ成果を上げるプロセスと理念』　 https://amzn.to/2LwT0vq   こちらも古いのですが、「ユーザーありきでサイトを作る」という、忘れがちだけれど一番大事なことを教えてくれる本です。ユーザーインタビューやユーザーテストのやり方が詳細に載っているのも良いです。  

おすすめの参考図書2    • 『なるほどデザイン』　https://amzn.to/2VlYdL8   タイポグラフィや色など、デザインの要素の基礎が学べます。「そこが知りたかった！」というポイントを実践的に解説してくれているので、仕事ですぐに応用できます。   •
『伝わる、WEBテキストのつくりかた -知っておきたい文字情報デザインテクニック』　 https://amzn.to/2LyqeLb   こちらも古くて恐縮ですが、よくある分かりづらい文章のどこがまずいのかを具体的に指摘してくれます。実践ですぐに役立ちます。   • 『入門ウェブ分析論――アクセス解析を成果につなげるための新・基礎知識増補改訂版』 https://amzn.to/2vN3DzD   今回の範囲からは外れますが、サイトを運用するフェーズで必ず必要になるアナリティクスの使い方を丁寧に解説している本です。  

seminar_direction.pdf

seminar_direction.pdf

Other Decks in Business

Featured

Transcript