デジタルアセット管理（DAM）実装のためのベストプラクティスを全5回のシリーズでお届けしています。この記事はその4回目です。
このDAM実装ガイドのこれまでの記事は、以下のリンクからご覧いただけます。
DAMの実装に着手した最初の段階でしばしば出くわすのが「バベルの塔」です。特にこれは、それまでDAMを使ったことがない組織に導入する場合や、新しいDAMの導入範囲が既存のシステムよりも社内の広い範囲にわたる場合にありがちです。
バベルの塔とは何かと言うと、同じ社内でもブランドや事業部門によって資産を説明する際に使う業界用語や専門用語が異なっていて、ファイル名やフォルダ名の付け方も異なっている状況です。しかも、グローバルな企業ともなれば、使われている言葉がそもそも異なることは、言うまでもありません。
ゆえに、デジタル資産を見つけるプロセスが、ラスベガスのカジノで出口を見つけるより難しくなってしまうのです。
この問題に対応するひとつのやり方が、同義語を使って様々な事業部門が独自の用語を使い続けられるようにすることです。しかし、これには、その能力に優れたDAMが必要になります。
Pasta Buddyというパスタソースのメーカーの事例を考えてみましょう。同社では、商品パッケージの写真に対して使う用語がブランドごとに異なっていました。あるグループが「前面」と呼んでいる写真を、別のグループでは「前面上」か「前面下」としていました。同様のことが、パッケージ上部の写真にも起こっていました。
これらすべての名前を同義語としてキープすれば、使われている用語にかかわらず、同じ種類のコンテンツを見つけられるようになります。
しかし、Pasta Buddyでは、このアプローチを取れば、社内のすべてのブランドを扱っている広告部門で混乱が生じることが分かりました。寄せられるリクエストを解釈できず、結果として、しばしば写真の再撮を余儀なくされたのです。言うまでもなく、これは時間と経費の無駄使いでした。
また、Pasta Buddyにおいて、DAMは、大きな企業文化の一部でもあり、デジタル革命プロジェクトを担うものと位置付けられていました。このため、共通の語彙を会社全体に導入するほうが、はるかに有益な目標と言えました。そこで同社は、DAMのソリューションで使う用語を標準化することにしました。つまり、バベルの塔の解体・撤去を選択したのです。
社内の全員から賛同を得るというのは、容易なことではありません。
しかし、優れたDAMのソリューションがあれば、柔軟性のあるモジュラー式のデータモデルをこのプロセスに活かすことができます。
Pasta Buddyでは、メタデータモデルに様々なスキーマが混在していて、すべてのコンテンツタイプに独自の構造がありました。これらすべてを合体させれば、何かをひとつ変えるごとに、すべてに反映させなければなりません。
例えば、システムのレイアウトや画面それぞれに、関連する使用権の様々な情報が付けられていることが多々ありました。しかし、画像、動画、文書、プロジェクトによって、レイアウトは異なっている可能性があります。そんな状況にあって、使用権の定義を変えたり、あるグループ（国際事業部門など）のニーズに対応して定義を詳細化したりすれば、突如としてすべてのレイアウトを変更しなければならなくなるのです。この結果、設定ミスやエラーの可能性が高まります。この変更プロセスに伴って混乱が巻き起こるであろうことは、言うまでもありません。しかも、作業量が増大するため、ITチームにバックログが生じ、プロジェクトは遅々として進まず、おそらく望んでいる変化も起こせなくなってしまうでしょう。
そこで私たちは、情報を次のように分けて取り扱うことにしました。
- 製品と資産の定義（それが何であるかを記述する）
- 使用権（どのように使えるかを説明する）
- リクエストとプロジェクト（どのように管理するかを定義する）
こうすることにより、それぞれを個別に変更できるようになり、変更が自動的に関連コンテンツに反映されるようになったのです。
これはまた、エンドユーザにとっても非常に価値のあるアプローチでした。画像と製品の間の関係性を構築できるようになったためです。画像に対してあるメタデータモデル、製品に対して別のメタデータモデルが存在して、それらがリンクされた結果、片側を検索すればもう片側も見つかるようになりました。
コンテンツとは、コンテキストの中に存在するものです！
例えば、ハンバーガーの写真を撮影したとしましょう。この写真には、マヨネーズ、タマネギ、レタス、トマト、チーズ、牛肉、パンという7つの製品が含まれています。誰かが1ポンドの冷凍ハンバーガー・パティを見つけようとする際に、この写真をフルに検索可能にするには、関連する製品情報をすべて、このハンバーガーのメタデータとして入力しなければならなくなります。そして、同じ入力を7つの製品すべてに繰り返すのです。なんと手間のかかることでしょうか！
しかし、製品と画像データが分かれていて、リンク可能になっていれば、単純に写真に入っている製品を参照する（7つの項目を選択する）だけで、それら製品のそれぞれのメタデータがすべて記録の一部となり、検索可能になって、このハンバーガーを見つけるのが実に簡単になります。
同じことをファッション業界で考えてみましょう。帽子、スカーフ、ドレス、シューズを着たモデルの写真を撮影して、春カタログの6ページ目に使用します。リンクを確立しておけば、サイズ7のパンプスを検索するだけで、この服装を見つけられるようになるのです。
PIMの統合に向けたプランニングについて解説した前回の記事のポイントにも触れておきましょう。Pasta Buddyは、自社のメタデータモデルに存在するコアの要素が製品の定義にかかわる2、3のフィールドであることに気付きました。
この製品定義のスキーマを分離することによって、PIMが導入された際に、製品に関してはるかにリッチなモデルを持てると確信したのです。つまり、他の部分にまったく変更を加えることなく、フィールドを追加し、人間のデータを追加し、マーケティングコピーを追加できることを意味しました。
次回の記事では、あまりにも時期尚早に多くをやりすぎずに、事業が抱える現実の問題を解決するために取るべき実装の最初のステップについての考え方を解説します。