この記事はLITALICO Engineers Advent Calendar 2022 カレンダー3 の 12月24日の記事です
はじめに
自己紹介
はじめまして、LITALICOの榎本です。普段はCQO(Chief Quality Officer/最高品質責任者)という仕事をしています。
コンテンツマネジメント統括部という部署とクオリティマネジメント室/LITALICO研究所という部署で働いています。
LITALICO研究所については、サイトを見てみてください。
CQOの仕事については、CTO市橋さんとの対談記事を見てみてください。
この記事で書くこと・書かないこと
書くこと
- コンテンツポリシー・ガイドライン・レギュレーションとは
- コンテンツポリシー・ガイドライン・レギュレーションをまとめる過程で得た個人的な学び、気づき
書かないこと
- LITALICOのコンテンツポリシー・ガイドライン・レギュレーション
- まだ作成中のため
- 今後適切な形で公開できると良いな
- 普遍的なコンテンツポリシー・ガイドライン・レギュレーションの型
- 企業や状況によって固有の文脈があり、一概に言えない
- 一方で、用字用語やライティングスタイルなどはある程度普遍性があると思います
対象読者
- コンテンツ制作にかかわる方
- 業務プロセスにおけるルールメイキングにかかわる方
前提・背景
(1)コンテンツマネジメントについて
LITALICOは、様々なサービス/プロダクトを展開しています(図の引用元は2023年3月期第2四半期決算説明資料)。
そして、サービス/プロダクトの構成要素の一つであるコンテンツもまた、多様です。
このような背景の中、サービス/プロダクトのコンテンツに関わるスタッフも各部署に所属しており、徐々にコンテンツ制作担当者が困る場面が生まれていました。
具体的には、下記のようなものです。
- 部署間で品質水準や担保の仕組み、判断基準のばらつきがある
- 「作っているコンテンツが本当にこの内容で良いのか不安」
- 「部署間で用いる言葉が異なっており、表現のOK/NGの判断が不明」
- コンテンツ制作に関わる育成の仕組みやナレッジマネジメントが不十分
- 「自部署でライティング担当者が少なく、フィードバック機会が充分にない」
- 「コンテンツ制作担当者になったけれども、具体的にどのようなプロセスやルールで進めていったら良いかが手探り」
こういったコンテンツ制作者の方々の困りごとや悩みポイントを踏まえて、全てのサービス/プロダクトに対して横断的に関わる組織を立ち上げました。
それが、冒頭でも示した「コンテンツマネジメント統括部」です。
この部署は、部署というより「横のつながり」として運営しています。
各部署に所属するコンテンツ制作担当者が、主にSlackのチャンネル上で
- 情報交換をしたり
- 「◯◯のイベントおすすめです!」
- 「◯◯の情報がアップデートされました、関係する方は読んでおくと良いと思います」
- 質問をしたり
- 「◯◯について知っている方いませんか?」
- 「◯◯のときって誰に聞けばいいですか?」
- 「〇〇のフォーマット持っている方共有してください!」
- 横断的な取り組みを呼びかけたり
- 「◯◯を取りまとめますので、ご協力お願いします」
- 「◯◯に対する意見を皆さんから公募します!」
- 自部署のコンテンツリリース情報を提供したり
- 「◯◯をリリースしました、ぜひ御覧ください」
- 「◯◯のイベントを動画にもしてみました」
しています。
ある種「半開き」の場として運営しており、コンテンツ制作に関わる人だけでなく、その周辺の職種の方も参加してくださり所属の人数よりも多いチャンネルとなっています。
(2)この記事におけるコンテンツとは
辞書的な意味合いは一旦おいておき、この記事においてコンテンツは、下記の2種類を指すものとしています。
- マーケティングに用いるコンテンツ(SEO記事、ホワイトペーパー、ウェビナー動画、等)
- サービス提供に用いるコンテンツ(利用者向け教材、ツール、社員向け研修資料、等)
コンテンツポリシー・ガイドライン・レギュレーションとは
ここから本題です。
表題にもある通り「コンテンツポリシー・ガイドライン・レギュレーション」とはなにか、を説明します。
下図をご覧ください。
記載のとおりですが、
- コンテンツポリシーとは、LITALICOで制作されるコンテンツがどうありたいか・制作者がどう取り組みたいか等の考え方や姿勢を明文化したものです。一番大上段にくるもので、このポリシーに準じてガイドラインでの考え方や各種レギュレーション・マニュアル等が存在すると考えます。
- コンテンツガイドラインとは、ポリシーに則ってコンテンツを制作するために用いる判断基準を、各種コンテンツごとにまとめたものです。
- レギュレーションとは、ガイドラインに書かれた基準に則ってコンテンツを制作する際の具体的な作業手順や決まり事をまとめたものです。各部署でもこれは作っている場合が多いです。
たとえて言うなら、憲法・法律・政省令・条例の関係性に似ています。
三角形の上にあるほど、効力が強く、より大事であり、抽象度が高く、幅広い適用範囲である、ということです。
別の言い方をするならば、「大事なもの順」に並んでいるとも考えられます。
このうち、ポリシーとガイドラインは、1つのドキュメントにまとめています。
Googleドキュメント上で下記のような構成でまとめています。
個人的な推しポイントは、「改訂」への言及です。詳細について、後述します。
部署新設後に、このポリシーとガイドラインをまとめていく過程に取り組んでいます。
まだ完成版はなく、原案を作っては、何名かに見せてフィードバックを得て改善していっています。
学び、気づき
ここからは、コンテンツポリシー・ガイドライン・レギュレーションをまとめる過程で得ることができた学び、気づきについて列挙します。
【1】「Do's list」と「Don'ts list」を対比で示して抽象と具体を同時に示す
「Do's list」は「することリスト」、「Don'ts list」は「しないことリスト」です。
ポリシーはどうしても抽象的にならざるを得ません。
一方で、そのおかげで、強い効力・メッセージ力をもち、汎用的でありえるのです。
ただ、それだけでは、実務の上で迷うことは解決できなかったり、初任者にとってはわかりくくイメージができないものとなってしまいます。
一方で、超具体的なことを列挙したとしても、その 「思想」「意図」「背景」 などが理解されづらくなってしまい、かえって誤った判断をしてしまったり文脈に合った柔軟な思考ができなくなったりするという”罠”に陥ります。
なので、ちょうど抽象と具体を橋渡しするような表現として、「Do's list」と「Don'ts list」を対比で示すということをしてみました。
これはなかなか良さそうだと感じています。
【2】「ルール」に関するスタンスを考える
ポリシー・ガイドライン・レギュレーションは、いわゆる「ルール」として認識されるものです。
皆さんにとって「ルール」とはどのようなイメージでしょうか。
例えば、
- ルールはすでにあるもの、変えられないものである
- どうせ作っても守られなくて意味ない
- ルールに縛られて、自由にできないのが嫌だ
- ・・・
などなど。どちらかというと、ポジティブなイメージよりはネガティブなイメージのほうが多いのではないでしょうか。
実際に、コンテンツ制作者の方と話してみると、上記のようにルール作りについてのネガティブなイメージや不安の声もありました。
そこで、「ルール」であるポリシー・ガイドライン・レギュレーションについてのスタンスを考えてみて、言葉にしてみました。先程「推しポイント」とも書いた、「改訂」についての言及です。
下記内容です。
ポリシー・ガイドライン・レギュレーション類は、永遠に変わらないものではありません。
コンテンツ制作に携わる人たちには、コンテンツ制作をしていく中で、
制作チーム内や関係部署、または顧客との対話プロセスを推奨します。
その過程で、より良いコンテンツ制作をするためにはどうしたら良いかを探索し、適応していくことを推奨します。
その探索と適応の結果、このポリシー・ガイドライン・レギュレーション類を改善していくことを推奨します。
コンテンツ制作に携わる誰もが、疑問を投げかけ、より良くしていくための議論を経て、改訂が実現されます。
定期的な議論や振り返りを通して、ポリシー・ガイドライン・レギュレーションの質を担保するようにします。
言葉にする過程でヒントにしたのは、3つあります。
詳細を述べるのは割愛します。
要は、「ルールの目的・ルールに込めている思い・ルールメイキングのプロセス」を示すということが重要であるということです。
【3】作り込むプロセスは協働的に
原案としてドラフトを作ったら、いろいろな人に作りかけの段階で公開しました。
その中で、気になった点や疑問、修正提案などをGoogleドキュメントの「コメント」機能を用いてフィードバックしてもらうようにしました。
図のように、ドキュメントの最上部に、コメントください、という旨を示しました。
これにより、自分が想定できていないこと・想像できていないこと・経験していないこと・担当者の中の暗黙知になっていることなどがコメントの中で可視化されていきました。
ポリシー類を使うのは、僕一人ではなく、コンテンツ制作に携わる方々なので、「一緒に作っていく」というプロセスをすることで、確実により良いものができてきているなあという手応えを得ることができました。
先程紹介した江崎貴裕さんの著書「数理モデル思考で紐解く RULE DESIGN -組織と人の行動を科学する」の中でも、ルールを守ってもらうためのやり方の一つとして、
新しいルールを作る際には、関係者を巻き込んで一緒にどのようなルールを策定すれば良いかを議論するのも非常に有効です。
と言及され、人々がルールに従いやすくなる実験 1 を引用しています。
作り込んでいくプロセスを協働的にするということは、自分が気づいていないことへの気付きが得られ、かつ、納得して運用されやすくなるルールメイキングができるということです。
この学びは汎用的だなあと感じています。
【4】デザインシステムとの関係性(巨人の肩に立つ)
「デザインシステム」
その言葉は知っていたし、中身もなんとなくは認識していたものの、今回のポリシー類をまとめるまではそこまで自分の業務とは関係ないと思いこんでいました。
ただ、調べていくうちに、「これはどうやら、自分が取り組んでいるものに真正面から関係あるものでは・・・?と認識を改め、公開されている事例(民間・行政)を中心に勉強をしています。
デザインシステムの定義や取り扱う射程は、世の中に有益な記事やソースがたくさんあるかと思いますのでそれらに譲りつつ、ぼくはコンセントさんが述べている「良いデザインを一貫性をもって提供するための仕組みである」2というのがシンプルでしっくりくる表現だなあと思っています。
企業やプロダクトによっても、デザインシステムで扱う要素には様々なバリエーションがあります。
その中で、「コンテンツ」という要素を扱っている企業やプロダクトがあります。
「コンテンツ」では、言葉の表現のガイドラインや用字用語、ライティングガイドなどを取り扱っています。
・・・まさに、コンテンツポリシー・ガイドライン・レギュレーション類の策定に関わる内容だ!と今更ながら気づいたのです。
せっかくある先人たちの知恵の恩恵に預からない手はありません。
「巨人の肩に立つ」という言葉もありますが、他の事例を参考に、LITALICOナイズしていければなと思って色々なデザインシステムを読んでいます。
個人的にいいなと思って、参考にしているデザインシステムは・・・Spotifyの Polaris です。
「デザイン」「パターン」「アイコン」「コンポーネント」などと同じ粒度で「コンテンツ」があるという構成を取っています。
下記は「コンテンツ」のページ(上記URL同じ)の画面キャプチャーです。
左上にある「Accessible and inclusive language(アクセスしやすくインクルーシブなことば)」という要素があり、ここに書かれている思想がとても参考になりました。ご興味がある方は、英語なので、DeepLしてぜひ読んでみてください。
昨今「ポリティカル・コレクトネス」という言葉が普及しましたが、本来は「言葉狩り」のような形で言葉表現の規制がなされたり、運用されたりすることは目指したい姿ではないと思います。
「どのような思想で、物事を考え表現するか」ということが本質的にはより重要であると考えます。
このページでは、「私たちのミッションは、すべての人にとってより良いコマースを実現すること。すべての人のための製品を作るということは、インクルーシブなコンテンツを作るということです。」と掲げられています。
言葉には力があり、ときに言葉は不必要に人を傷つけ排除するように作用します。
コンテンツの多くは、なんらかの「言葉」を用いて表現されています。
したがって、コンテンツを制作する上では、多様な背景がある人が受け取ることを前提に、その表現の妥当性・必要性・合理性を考えなければならないと考えます。
日本で生まれ暮らし、日本語を用いてきた自分にとって、海外の文化多様性のあることを想定したデザインシステムはとても学びに溢れました。
また、「デザインシステム」という表現方法があることによって、このポリシー類の運用が、コンテンツのみに閉じず、プロダクト一体となって用いられていく可能性も見出すことができたことは大きな学びです。
おわりに
まだまだ整備しなければいけないことが多いですが、少しずつ、先述の課題を解決しつつ、更にLITALICOのお客さんに対して提供するコンテンツの品質を向上させ、新たな提供価値を創造していきたいと思っています。
この記事を読んで、LITALICOにおけるコンテンツづくりに関して興味が湧いた方はぜひコメントなどをください。
それでは、Happy Holidays!
-
Ostrom, E. (1990). Governing the commons: The evolution of institutions for collective action. Cambridge university press. ↩