公開前の確認が、スクショになる理由

社外の人に公開前のページを見てもらう場面は、思いのほか多くあります。

  • 専門的な内容を、社外の監修者に確かめてもらう
  • 取引先の製品情報や社名表記を、先方に確認してもらう
  • 代理店や販売店向けの案内を、公開前に共有する
  • 発注側と制作会社のあいだで、仕上がりを確かめ合う

ところが、公開前のページは作った側の環境の中にしかありません。管理画面やテスト環境は、社内の人が使う前提で作られています。社外の人にアカウントを発行するには手続きが要り、使い方の説明が要り、確認が終わったらアカウントを消す手間も残ります。一度の確認のためには重すぎます。

見てもらう側にも事情があります。知らないシステムにログインしたくない。社内の規程で、社外のURLを開きにくい。紙やPDFに赤を入れて返すほうが慣れている。

こうして、いちばん確実に届く方法として「画面を撮って、資料にして、メールで送る」が選ばれます。誰でも開ける、手元に残る、赤を入れやすい。スクショやPDFには、選ばれるだけの理由があります。

困るのは、それが実物の代わりでしかないことです。

スクショ・PDFでの確認で起きること

修正のたびに、資料を作り直す

長いページは、何枚かに分けて撮り、つなぎ、どこに何があるかの注記を付けます。1か所直すと、その部分を撮り直して差し替えます。確認が2往復、3往復と続くと、作業時間の多くが、ページを直すことではなく資料を作り直すことに使われます。

新旧のファイルが混ざる

「確認用_v2」「確認用_v2_修正」「確認用_最終」。やり取りが続くほど、どれが最新なのか、戻ってきた赤がどの版に対するものなのかが分かりにくくなります。

確認者が複数いると、さらに混ざります。一人は第2版に、もう一人は第3版に赤を入れて返してくる。すでに直した箇所への指摘が届くこともあります。指摘を一つずつ、どの版の話かと照らし合わせる作業が増えます。

実物でなければ確かめられないことが残る

画像やPDFでは、確かめられないことがあります。

  • リンク:画像の中のリンクは押せません。リンク先が正しいかは分かりません。
  • 画面の幅:スマートフォンでの見え方、文章の折り返し、表のはみ出しは、撮った幅の分しか分かりません。
  • 動き:開閉する項目、タブの切り替え、動画などは、画像では伝わりません。
  • 撮っていない部分:ページの下のほう、マウスを乗せたときの表示などは、撮らなければ確認の外に落ちます。
  • 文字:画像の文字はコピーも検索もできないので、用語や数値を照らし合わせにくくなります。

確認者がOKを出したのは、その画像に対してです。公開されるページそのものに対してではありません。このずれは、監修や法務の確認のように「何を確認したか」が問われる場面ほど重くなります。

誰がいつOKを出したかが、メールに散る

どの版に、誰が、いつOKを出したのか。その記録は、添付ファイルとメールの往復の中に埋もれます。後から「これは確認済みか」と聞かれたとき、受信箱を掘り返すことになります。

社外の人に見せる方法を比べる

公開前のページを社外の人に見せる方法は、主に4つです。

方法 良いところ 気をつけること
スクショ・PDFを送る 誰でも開ける。手元に残る。赤を入れやすい 作り直し、版の混在、実物との差
Web会議で画面を共有する 実物をその場で見せられる。質問にすぐ答えられる 日程を合わせる必要がある。相手が自分のペースで読めない。記録が残りにくい
管理画面やテスト環境のアカウントを渡す 相手が好きなときに実物を見られる 発行と削除の手続き。操作を覚えてもらう必要がある。見せなくてよい画面まで見える
公開前のページを見られるURLを渡す 相手はブラウザで開くだけ。リンクや画面幅を実物で確かめられる URLをいつまで、誰に見せるかを決めておく必要がある

どれか一つがいつも正しいわけではありません。PDFは、記録として残すことには向いています。たとえば、実物の確認はURLで行い、最終的にOKが出た時点の内容はPDFで保存しておく、というように役割を分けることもできます。

URLで見せる方法にも注意が要ります。共通のパスワードを掛けたテスト環境を、期限を決めずに置いたままにすると、確認が終わってからも見られる状態が続きます。発表前の新製品や価格のように、公開日まで外に出てはいけない情報では、これが問題になります。

確認用URLで見せるときに決めておくこと

URLで見せる場合、渡す前に次のことを決めておきます。

いつから見せるか
準備が整う前に開かれると、未完成の状態を見られてしまいます。見せてよい時点を決めておきます。

いつまで見せるか
確認の期間が終わったら、見られなくなるのが基本です。公開前の情報が、確認のあとも見える状態で残らないようにします。確認が長引いたときに延ばすのか、出し直すのかも決めておくと迷いません。

誰が見られるか
URLは、転送されれば誰でも開けます。パスワードを掛けておけば、URLだけが出回っても開けません。パスワードはURLと同じメールに書かず、別の手段で伝えるほうが安全です。

何を見せるか
見てもらうのはそのページだけか、関連するページもか。確認してほしい範囲をはっきりさせておくと、見なくてよい部分への指摘が減ります。

確認の依頼と、指摘の受け取り方

URLを渡すだけでは、確認はうまく回りません。依頼の出し方と、指摘の受け取り方も決めておきます。

依頼に書くこと

  • 確認してほしいURL(パスワードは別の手段で)
  • 見てほしい観点(表現、数値、固有名詞、リンク先など)
  • いつまでに返してほしいか
  • URLがいつまで見られるか
  • 指摘の返し方

指摘の返し方を決める

どの箇所への指摘かが分かれば、形式は問いません。見出しの名前や段落の書き出しで場所を示してもらう方法もあれば、確認者が自分で撮ったスクショに赤を入れて返してもらう方法もあります。大事なのは、こちらが確認のための資料を作らなくて済むことです。

確認者が複数いるとき

順番に回すのか、同時に見てもらうのか。指摘がぶつかったときに、誰の判断を優先するのか。先に決めておかないと、直した内容が別の人の指摘で元に戻る、ということが起きます。

OKの記録を残す

最終的に何を確認してもらい、いつOKが出たのか。確認が問われる業務なら、OKが出た時点の記録を残しておきます。

writeWiredでは

writeWiredには、公開前のコンテンツを、管理画面にログインしていない人に見てもらうためのURLを発行する機能があります(外部確認URL)。

  • 公開前のコンテンツについて、ログインなしで確認できるURLを発行する
  • 表示の開始日時、有効期限、パスワードを指定する
  • 確認する人は、公開されるときと同じ見た目のページを、ブラウザで開いて確かめる
  • 有効期限内に内容を修正すると、同じ確認用URLのまま修正後の内容が表示される
  • 確認が済んだURLは、有効期限で失効する

先に挙げた「いつから」「いつまで」「誰が」は、URLを発行するときに、開始日時・有効期限・パスワードとして指定します。確認者は管理画面を使わず、渡されたURLを開いて内容を確かめます。

スクショ・PDFでの確認で起きる問題には、次のように当たります。確認用の資料は作りません。修正しても確認用URLを出し直す必要はなく、渡したURLがいつも最新の内容を指すので、新旧のファイルが混ざることもありません。確認者が見るのは、画像ではなく、公開されるときと同じ見た目のページです。

確認の依頼の書き方や、指摘の受け取り方は、この機能の外側にある運用です。指摘は、これまでどおりメールなどで受け取ります。

この記事の根拠となる機能

運用の困りごと 一覧へ