エンジニアリング・デザインの連携強化と、膨大なコンテンツの溢れたこの時代に合わせた情報の構造化に興味があり、社内のエンジニアさんに勧められて読了。

本書の最後の章に、著者のこのようなコメントがあります。

私の今の課題感もまさにここにあります。

「デジタルプロダクトが取り扱う情報が複雑化している」とよく言われます。情報量自体の増加もそうですし、ある一つの情報をウェブブラウザ版・アプリ版でそれぞれ見せることなどはごく当たり前に行われています。
その複雑化している情報をどのように管理するかというのは、データベースが担っている部分が多く、エンジニア任せであるというのが実情である気がします。

完全に安定させるのは無理でも、より堅牢性のあるコンテンツにするにはどうすれば良いのか。
私は、この部分の検討にこそコンテンツデザイン・編集・管理の考え方をもっと取り入れる必要があり、コンテンツディレクターやコンテンツデザイナー、編集者という情報編集のプロフェッショナルがもっと携わるべきだと思うのです。

そんな今の課題感を拾ってくれる本でした。

どうしても見た目が重視される

まず前提として、本書のテーマである見た目 ＜ 構造ファースト的な考え方は、共通の情報を繰り返しさまざまな箇所で表示するECやカタログなど、情報を迅速に正しく提供することが至上のコンテンツには抜群に向いている考え方だと思いますし、数千・万ページに及ぶコンテンツを持つ企業サイトなどにも応用できる考え方です。
一方で、ブランドイメージを単体で訴求するようなLPなどには必ずしも応用しなくても良い考え方かもしれません。要は、向き不向きです。

しかし企業の扱う情報量が日に日に膨大になっている今、ページ単位で見た目を整えるだけの時代は終わった感を感じます。取り入れる量の寡多はあれど、本書の考え方を頭の隅に置いて情報設計することはデジタル・コンテンツにおいてはもはや必須ではないでしょうか。

コンテンツ運用が徐々に乱れていくのは、何も見た目に関わる問題ばかりではありません。
というより、コンテンツにおいて見た目の細部のみにこだわることで、裏側の仕組みに非常な負荷がかかり、目に見えないルールを破綻させているという事実にコンテンツオーナーが気づいていない事態が多いと思うのです。

この事態が明るみに出ないのはウォーターフォール開発で定着しすぎたプロジェクト様式が悪さをしていると考えています。デザインから設計、エンジニアからデザインまたは設計側へのボトムアップコミュニケーションをするという認識が開発の現場にはほぼなく、その警鐘をデザイナーやエンジニアが鳴らすことができないという体制の落とし穴が確実にあると思うのです。

これを回避するためには、開発の考え方を変えていくしかありません。
データベースに知見のあるエンジニアが企画・編集フェーズに参加することが必要ですし、設計者はプロジェクトの目的を踏まえてエンジニアと積極的にコミュニケーションし、破綻のない堅固な情報設計を行うべきだと考えますし、UIデザイナーはそれらを全て踏まえてデータを正しくスムーズにユーザーに認識させるインタフェースを制作する必要があります。
そして、いずれにも情報編集の知見がいかせると思います。

つまり、デザイナーにせよ、エンジニアにせよ、川上から降ってきた内容をただ形に落とし込むことで対応する時代は過去のものになっているということです。
そして逆も然りで、コンテンツオーナーや設計者はデザインやエンジニアリングとの双方向のコミュニケーションをもっと重視すべきだと思います。

堅固な情報設計は可能なのか

すべてを見通すことはできないことを前提に、「普遍」「汎用」を最大限達成するためには何が必要か。
それは、本書にも書いてある必要な形で情報を分類し取り出せるようにしておくことです。
情報さえきちんと整理してあれば、たとえ時代の流行り廃りで表側の表現を変える必要がある時もいちいち裏の情報構造まで整理し直す手間が省けます。

たとえページの主要構成要素である本文コンテンツに独自性があるニュースサイトであれ、発信する支局、記者名、発信日時、媒体名、カテゴリなど当該ページだけでなくサイト全体もしくはそのメディアが持つ多様なプラットフォーム全体に波及する情報を内包しているということを忘れない。そしてそれらが「どこで」ユーザーの目に触れると効果を発揮するものなのか、「どのように」更新していくのが正しいのか。その構造を考えることが、今のコンテンツ設計には肝要なのだと思います。

「コンテンツを構造化する」とは？

コンテンツの構造はどのように考えていくべきか。本書の内容を元にまとめると大まかには下記のような流れになります。

• まずはコンテンツのテーマと意味を考える

• コンテンツをテーマと意味をふまえて分解・分析する

• それらを再度モデリングして構造化する

序盤にあるテーマと意味の設定を間違えると、その先が迷走する構図ですが、その事態を避けるために必要なのが「調査」だと著者は述べます。

コンテンツ設計者が主観で考えていく方法は、独りよがりで反省のないものになりがちです。第三者の意見を入れることが必要です。
調査対象はステークホルダーの中で、コンテンツ検討に必要な人にスポットを当てれば良く、本書では、専門家・ユーザーに分けて例をあげています。
また、私自身の所感としてはクライアントサイドのみでなく、開発側の体制においても「構造化」のための知見に弱い部分がある時には、積極的にプロジェクト外のメンバーに協力を仰ぎ、自発的に情報を収集することが必要な時もあると思います（ここも見積化できればなおいいのですが、なかなか理解が得られないことがネックです）。
そしてその案を、全員で叩き、合意を取るというプロセスを忘れないようにすることが重要であると本書でも述べられています。

構造化による恩恵はどこにあるのか。
その例として、例えばイベントであれば、会場や公演内容、出演者などの「コンテンツの中身」は変化します。しかし「会場」ー「公演内容」ー「出演者」の各情報の関係性（構造）は、そうそう変化するものではありません。
コンテンツの中身を差し替える必要がある時、いちいち該当箇所ごとに情報を入力し直すのでしょうか？　すべて個別に入力したその結果、見落としがないと言えますか？　そもそもその入力、時間の無駄ではありませんか？
しかし、そういう構造になっているデジタルコンテンツが世の中にはまだたくさんあることも事実です。
構造を堅固にしておけば、データを一つだけ入力し直すだけで、関連する全ての情報が最新化される。それが、この時代のコンテンツ設計のベースにあるべき考え方だと私も思うのです。

しかし特に短期的には成果が見えにくいので、説得が難しい。

初期体制と連携に手を抜かない

とめどなく肥大化するデジタルプロダクトのコンテンツは、そして、その大元にある情報は、クライアント・コンテンツオーナー・編集スキルを持つ設計者・エンジニアいずれにしても一人の手には追えなくなってきているといえます。

ここで冒頭に引用した一文再掲します。

完全には無理であっても、コンテンツ構造の堅牢性を担保するためには、プロジェクト初期からのデザイナー・エンジニアの参画、必要な調査の実施、プロジェクト全体の連携がますます必須になってきていると感じます。