こんにちは、オウンドメディア運用チームLIGMOのハマです。
突然ですが、私から提案があります。クライアントからのクレームが止まらないときは、コンパクトな作業ガイドラインを作りなおしてみませんか。
今回はそんな記事を書いてみようと思います。
言われてみれば当たり前のことかもしれませんが、日々の業務に追われると、ついないがしろになってしまいがちではないでしょうか。少なくとも、私は見事に失敗したことがあります。
- 【失敗事例】30代・男性・ハマ（仮名）のケース
- 前職で、日本語メディアのコンテンツを多言語化するというプロジェクトを担当していたときのことです。ある日「●●は『A』の方向性で翻訳をするのが自然でしょうが！（怒）」とのクレームがクライアントから届きました。早速、外注先の翻訳者さんたちへ指示を出したところ、現場はパニックに陥ることになりました。
というのも、「●●は『B』の方向性で翻訳をするのが自然でしょうが！（怒）」とのクレームが、クライアントから以前にあったからのようでした。
しかも、「A」と「B」は矛盾する内容なのです。
ただ、メールの履歴を見返しても、そのクレームは見つかりません。詳しく調べると、ある翻訳者に対してクライアントが、メッセンジャーサービスを通して直接伝えた内容であり、それが翻訳者同士の間で広まっていたことがわかりました。
クライアントに電話で問い合わせると、先方の担当者自身もそのことをうっかり忘れておられたようでした。「ハハハハ、なんだかすみません」と笑い合ったときに、背中へ突き刺さった翻訳者さんたちの冷たい視線は今でも忘れられません。
なぜ、このような事態が起きてしまったのでしょうか。
それは「クライアント」「社内担当者」「外部作業者」の全員が、バラバラの地図を見て進んでいたからです。現に、年中無休で飛び込む翻訳作業のディレクションを言い訳に、プロジェクト開始時に作成した作業ガイドラインは放置されたままになっていました。
このような場合に備えて、常に最新の状態に更新され、すべてのメンバーがいつでも参照できる「共通の作業ガイドライン」を策定する必要があります。具体的かつ論理的なルールを整備し、曖昧で感覚的なフィードバックを横行させない。そうしなければ、現場が正確な作業を達成することは難しく、無用なクレームは続き、プロジェクトに関わっているメンバーたち全員が疲弊していくことになってしまうでしょう。
ガイドラインを策定するための7ステップ
では、作業ガイドラインを策定するためには、具体的にどのようなステップを踏めば良いのでしょうか。参考までに、私が行った「7つのステップ」をご紹介いたします。
STEP1: クライアントの理解を得る
まずは、ガイドラインを策定する目的について、作業品質に怒り心頭のクライアントへ説明し、理解を得るように努めました。
以下に続く、ガイドライン策定のステップへ進むためには、クライアントの協力が不可欠です。なかには、クライアントの作業手法に対して、新たな制限を設けるルールもあったりするからです。
立場は違えど、「良質なコンテンツを作る」という目指すゴールは同じです。根気よく伝えれば、きっと分かってくれるでしょう。
STEP2: ガイドライン草案をクライアントから提出してもらう
ガイドラインの草案を用意する際には、こちらからではなく「クライアントから」提出してもらうようにしました。
これは作業を押し付けているわけでもなく、「よくもこれまで意味不明なクレームをしてくれたじゃないか。それなりの根拠はもっているんだろうな」と喧嘩を売っているわけでもありません。単純に、クライアントがプロジェクトの品質要求について最も詳しいからこそ、お願いするのです。
時間も限られているので、最初はコンパクトなものをサササッと作り、少しずつ増やしていくのが現実的かと思います。「まずは必要最低限のコンパクトなもので構いませんので」と伝え、協力を仰ぎましょう。
ただ、クライアント担当者が「どうしても時間を割けない」ということもあるかと思います。そんなときにも諦めず、ボイスレコーダを持って先方へ出向きましょう。各作業項目に対する要望について担当者へインタビューし、こちらでまとめるのも効果的です。
STEP3: ガイドライン草案を現場作業者とともに検証する
クライアントから提出されたガイドライン草案の各項目をこちらで検証していきます。必ず、社内担当者だけではなく、実際の作業に携わる現場のメンバーと一緒にひとつひとつの項目を精査するようにしました。
不思議なことに、フィードバックを「される側」から「する側」へ回ることになるわけですが、決して日々の恨みを晴らそうとしてはいけません。あくまでプロジェクトの成功に向けて冷静に取り組みましょう。
主なチェックポイントは以下の通りです。
- 曖昧で主観的な表現は含まれていないか
- 項目間で矛盾しあう表現は含まれていないか
- 参照事例を豊富に提示できているか（あるいは、提示できそうか）
- 分かりやすくシンプルな表現か
要件を言語だけで明確に定義できない項目には、「これらのケースはOK、これらのケースはNG」と、画像なども交えて事例集化することで対処するのも有効です。
STEP4: ガイドライン草案をブラッシュアップする
おそらく、ガイドライン草案には、多くの問題点が見つかると思います。
しかしながら、ここで遠慮していては意味がありません。クライアント担当者に対して、ガイドライン草案に対するフィードバックを忌憚なく伝えましょう。そして、お互いの見解を納得がいくまですり合わせなければなりません。
STEP5: 完成したガイドラインを関係者全員に掲げる
これまでのステップで、ようやく「ガイドラインVer.1.0」が完成することになります。早速、プロジェクトに携わるメンバーがいつでもどこからでも見られるようにしましょう。
例えば、Googleスプレッドシードも活用できます。社内担当者には編集権限、現場の作業者には閲覧権限のみを与えましょう。スプレッドシートであれば、ガイドラインの内容が変更された際にメンバーへ通知する設定も可能です。
STEP6: ガイドラインに一定の権威を与える
当然「ガイドラインVer.1.0」では、すべてのケースを網羅できません。プロジェクトが続いていくなかで、不測の問題点が発生し、大幅な改定が求められることもあるでしょう。
ただ、「ガイドラインは絶対だ！」と言えないにしても、一定の権威を与えなければなりません。そうしなければ、結局は放置され、形骸化してしまうことになるでしょう。
そこで、私は以下の原則をクライアントと取り決めました。
作業品質に対するクレームは、当該ガイドラインのみを論拠に行う
クライアントから、ガイドラインにない項目について「フィードバック」があれば当然対応しますし、新たな項目としてガイドラインに追加することも検討します。次回より、更新後のガイドラインで作業を行うことにもなるでしょう。
ただし、「クレーム」については「現行のガイドラインにない項目はやめましょう」とお願いし、「フィードバック」と「クレーム」を明確に分けることにしました。これにより、「ガイドラインを遵守しても、どうせ怒られるから意味がない」と、現場作業者のガイドラインに対する信頼を無用に下げていた構造を改善することができます。
一見、「少なくとも現行ガイドラインに基づく作業には問題なかったんだから我慢してくださいよ」と言っているようにも聞こえるかもしれませんが、「ガイドラインの形骸化を防ぐため」との目的をしっかり伝えれば、クライアントも納得してくれるはずです。
STEP7: クレームやフィードバックのチャネルを限定する
電話、メール本文、メール添付ファイル、メッセンジャーサービス……ありとあらゆる方法で届くクライアントからのクレームやフィードバックのチャネルも限定させていただくことにしました。
例えば、Googleスプレッドシートに「クレーム」と「フィードバック」という2つのシートを作成します。
まず、「ガイドラインに記載があるのに達成されていない作業項目」については「クレーム」シートに記載してもらうことになります。内容については社内担当者が日々確認し、現場作業者を指導します。
一方、「ガイドラインに記載はないが修正すべき作業項目」については「フィードバック」シートに記載してもらうことになります。内容については社内担当者だけではなく現場作業者も含めて検証し、疑問点があればクライアントに回答を求めます。
やりとりの結果、疑問点が解消されれば、新たな項目としてガイドラインにも追加し、事前に取り決めておいた、いずれか1つのツールにてガイドラインが更新された旨を全メンバーへ共有します。もし、「必ずメールにてガイドラインの更新情報を共有すること」と決めるのであれば、当該メールのタイトルや文面もテンプレート化することで、視認性を高めておくのも良いかもしれません。
これにより、現在の作業状況をガイドライン、もしくは現場メンバーに漏れなく反映することができるようになります。現場メンバーとしても「クレーム」については素直に反省しつつも、「最新のガイドラインさえ理解していれば大丈夫」という一定の安心感が生まれるため、全体の雰囲気が明らかに良くなっていきました。
プロジェクトが継続していくと、ガイドラインは少しずつ大きく育っていくでしょう。そのときに、この「最新のガイドラインだけはしっかり理解しておこう」という基本的な姿勢が当初から現場に根付いているかどうかは、特に重要な意味をもってくるのではないかと思います。
まとめ
いかがでしたでしょうか。
ガイドラインを策定したとしても、品質に「クレーム」がほとんどつかなくなるまでには時間が掛かると思います。ただ、最終的に細かな修正対応だけで済むようになれば嬉しいですね。また、ガイドラインがしっかりすると、新しいリソースの教育に費やす時間が短縮されるなどのメリットもあります。
何よりもプロジェクトに携わるすべてのメンバーのモヤモヤがすっきりしますし、共通のガイドラインを「クライアント」「社内担当者」「外部作業者」の皆で見ながら試行錯誤し、より良いものに更新していこうとするなかで、信頼関係のようなものが立ち上がっていきやすいのではないかと思います。
クライアントのクレームにお悩みの方、あるいは外部委託先の作業品質にお悩みの方。ぜひ一度、コンパクトなガイドラインを作りなおしてみてくださいね。
- おまけ：クライアントから聞いた後日談
-
- クレームが止まらない状況に陥っているとき、実はクライアント自身も混乱し、悩んでいたそうです。なので、ガイドライン策定には前向きに取り組めたとのことでした
- 実は当時、クライアントは、クレームの根拠となるルールなんて「草案ですら」持っていなかったとのことでした。ただ、それでは格好がつかないので、急遽作ってくれたそうです
- 赤字だらけの草案フィードバックが突き返されたとき、クライアントは「正直、腹が立った」そうです。ただ、社内担当者ではなく、現場作業者の目線によるリアルな検証結果のため「何も言えなかった」とのことです
- 実際に草案に対するフィードバック内容を読んでみて、「自分たちが意味不明なクレームをしていた面もあったのかもしれない」とクライアント自身も気づいたらしく、そんな状況でも丁寧に対応しつづけてくれていたことを知り、見方が少し変わるきっかけになったそうです
