Blog

この記事は、効果的なコンテンツモデリングに関するシリーズの第2部であり、前の部分で取り上げたトピックと基礎について続けます。最初の記事を読んで、コンテンツモデリングの基礎を最初に理解することをお勧めします。

コンテンツモデリングの抽象化を理解するための概要

この記事では、シンプルで直感的で強力な効果的なコンテンツモデルの設計について詳しく説明します。すばらしいカスタマーエクスペリエンスを提供する洗練された完成品に到達する前に、ユーザーとビジネスの両方を理解するという最初から始める必要があります。コンテンツモデルを設計するタスクを実行すると、さまざまな動機と期待を持つ多くの利害関係者がやりくりすることになります。私たちにとって、効果的なコンテンツモデルを設計するプロセスは芸術であると同時に科学でもあります。この記事では、コンテンツモデリングの職人になるために必要なツールを身に付けようとします。

なぜコンテンツモデルを「設計」するのですか？

ウェブサイトやモバイルアプリなどの優れたデジタル製品を提供する場合、特にさまざまな利害関係者がいる大規模なプロジェクトで作業する場合、見過ごされがちな側面の1つは、システムの開発者と保守担当者の経験です。

シンプルで直感的で強力なコンテンツモデルを設計することは、非常に難しい配信と、開発者の関心を維持し、興奮させ、配信チーム全体とユーザーに永続的な印象を残すモデルとの違いになります。やる気があれば、最高の作品を生み出し、配信チームの想像力をサポートする強力なコンテンツモデルがまさにそれを実現します。

すばらしいので、シーンを設定し、優れたコンテンツモデルの設計が重要であることを確認したので、この記事の詳細と、コンテンツモデリングのお気に入りのトピックの1つに取り掛かりましょう。

例1：抽象化とは何ですか？

コンテンツモデリングに関しては抽象化について聞いたことがあるかもしれませんが、なぜそれが役立つのか、そしてそれをどのように機能させるのかがわからないかもしれません。それは確かに個々のプロジェクトに独自の癖があるものの1つですが、この記事の内容は、コンテンツモデリングの抽象化の概念とそれらすべてを理解する方法を身に付けることを目的としています。

シーンを設定する簡単な例から始めましょう。図1は、ユーザーが物件を購入したり、近くの賃貸物件を見つけたりできるモバイルアプリを示しています。現在の画面では、ユーザーが「購入」オプションを選択し、1つの家と2つのアパートの3つのアイテムが表示されていることがわかります。コンテンツモデリングの初心者は、最初に目にするもの、つまり家のモデル、アパートのモデルなどのモデルをすぐに作成する傾向があります。ただし、この特定のシナリオに対するより簡単な解決策はありますか？

リスト内の新しいタイプのアイテムをサポートするために、将来アプリを更新する必要がある場合はどうなりますか？売り手は、売りに出されている空き地、駐車スペース、さらにはシェアハウスのシングルルームを投稿したいと思うかもしれません。代わりに、これらすべてをシンプルで直感的なモデルに取り込む方法はありますか？

具象型から抽象型に移行するプロセスでは、通常、物理的な名詞を記述する型から、より象徴的な性質のモデルに移行する必要があります。最初の物理オブジェクトからより一般的なコンテンツタイプにジャンプするには、多くの場合、頭の中でいくつかの飛躍が必要になることがあります。

いつ抽象化を使用する必要がありますか？

コンテンツモデリングの抽象化の世界に足を踏み入れる機会があったので、おそらく足を適切に濡らしたいと思うでしょう。抽象化を使用して複雑なモデリングシナリオを解決する方法について知りたい場合は、この記事の次の例が役立ちます。この知識は、最終的にはプラットフォームやツールにとらわれず、ヘッドレスCMSのコンテンツモデルを設計するユースケース以外のさまざまな技術的状況に適用できます。

コンテンツモデリングの抽象化の世界に足を踏み入れる機会があったので、おそらく足を適切に濡らしたいと思うでしょう。抽象化を使用して複雑なモデリングシナリオを解決する方法について知りたい場合は、この記事の次の例が役立ちます。この知識は、最終的にはプラットフォームやツールにとらわれず、ヘッドレスCMSのコンテンツモデルを設計するユースケース以外のさまざまな技術的状況に適用できます。

以下は、モデルで抽象化を使用する機会を警告するためにアラームベルが鳴る最も一般的なシナリオです。これらの各状況の詳細な例を提供します。

• アイテムのリストを扱っているとき、特にそれらの間にバリエーションのポイントがあるとき。
• さまざまな種類のものがあり、バリエーションはあるものの、最終的には、顧客が製品内でそれらとどのようにやり取りするかという観点から同じプロセスを経る場合。
• あなたの自然な直感が、あなたが特定のものの異なる「タイプ」または「カテゴリー」を扱っていることをあなたに告げるとき。

ことわざにあるように、大きな力には大きな責任が伴います。抽象型とより単純な具象型をいつ使用するかについては、慎重に判断する必要があります。特定の状況では、具体的な非抽象型もより適切な選択である理由に注意する必要があります。大規模なエンタープライズレベルのサイトとアプリの構築と保守の経験から、システムの保守と寿命を成功させるための鍵は、日常の使用の単純さです。コンテンツモデルの設計の主な目的の1つは、システムの観点からだけでなく、モデルの動作を直感的に理解する能力に関して人間の観点からも、シンプルにすることです。ヘッドレスCMSは確かに、コード内のAPIを介して消費されるデジタルツールですが、さらに重要なことに、人間が読み取り、共同作業し、保守する必要があります。

ソリューションをよりシンプルで直感的にするのに役立つコンテンツモデルの抽象化に目を向ける必要があります。

例2：Eコマース衣料品店

次の例は、ストアで販売されているアイテムに関して、eコマースストアのモデル化をどのように考えるかを示しています。この特定の例では、私たちがシャツ、ズボン、ジーンズ、スーツ、靴下などのさまざまなアイテムを販売している衣料品店であると想像してみてください。

前の例と同じ考え方を使用して、物理オブジェクトの1つを表す具象型から始めて、シンボリック型、そして最後に完全に抽象化された型に進むことができるかどうかを見てみましょう。

完全に抽象化された「製品」コンテンツタイプができたので、他のすべてのアイテムをモデルに簡単に取り込む方法を簡単に考えることができる、よりクリーンで明確なモデルができました。象徴的なタイプの「衣料品」は、靴、ベルト、サングラスなど、必ずしも「衣料品」に分類されない可能性のあるさまざまなアイテムを扱うときに制限がありますが、簡単に説明すると"製品"。

物理的な具体的なタイプから象徴的なタイプへ、そして最後に抽象化されたタイプへと進むこれらの簡単な演習は、コンテンツモデリングの筋肉を訓練するのに役立ちます。さらにいくつかの例を調べて、これと同じアプローチを他のタイプのアプリケーションに使用できるかどうかを確認しましょう。

例3：シンボリックセマンティックタイプを使用する場合

すべてのタイプが現実世界を完全に表しており、抽象化すら必要ない、完全にセマンティックなモデルを持つという夢からコンテンツモデリングの演習を開始するのが一般的です。多くの場合、これは実際には設計を開始するときに非常に有効な目的です。抽象化のための抽象化は強く避ける必要があります。次の例では、アイテムのリストをモデル化するという課題が再び発生します。これらのアイテムは、一般的な性質において適切なレベルの変動があります。この場合、クレジットカード、住宅ローン、定期預金などの具体的なタイプの作成は避けますが、代わりに、これらすべてに対応できる単一のアカウントタイプを使用できます。この例は、純粋に一般的なモデリングの観点からのものです。銀行口座はヘッドレスCMS内に保存されません。

ヒント

この例では、完全に抽象化され、「リスト」や「カード」など、リスト内のアイテムを表す目的のみを果たすタイプを導入したくなるかもしれませんが、この状況では、これはそうではありません。シンボリックアカウントタイプは、リストに表示する必要のあるさまざまなアイテムすべてを十分に表すことができるため、必要です。

例4：シンボリックタイプが正しい別の状況

次の例では、シンボリックタイプだけが必要な状況が再び見られます。この場合、扱っている特定のタイプすべてを十分にキャプチャできる製品タイプがあります。このシナリオでの興味深い落とし穴は、製品とポリシーの違いです。保険分野では、「保険契約」は保険会社と保険契約者の間の実際の契約です。この例では、顧客が見積もりを取得できるように利用可能な保険商品のリストを表示しています。これは、シンボリックタイプの名前を決定する際の課題の1つを示しています。ある用語が別の魅力的な用語よりも正しい場合があります。

ヒント

一見問題ないように見えるいくつかの異なる用語から選択する必要があることに気付いた場合：

• 用語の理解を深めるには、ビジネスの対象分野の専門家を参照してください。
• あるタイプを別のタイプに「バインド」するものを実際に指す用語にだまされないでください（たとえば、「注文」または「購入」タイプは「顧客」を「製品」にバインドするものです）。

特定のタイプに固有の特性を扱う

複数の異なるタイプを1つのシンボリックタイプに結合しようとすると、処理しているこれらのタイプの一部に、それらにのみ適用され、適用されない非常に特殊な特性と特性のセットがある可能性があるという事実に困惑する可能性があります。他のタイプ。これにより、最初の混乱や、タイプを組み合わせることに抵抗が生じる可能性があります。

簡単な例を考えてみましょう。購入またはレンタルできる物件のリストを表示するモバイルアプリを扱っていると想像してください。私たちが扱っているさまざまなタイプのリストのすべてについて考えると、次のようになる可能性があります。

• 住宅
• アパート
• 空の土地
• 駐車場
• 商業スペース

これらのいずれかを調べると、そのタイプに特に意味があるだけのプロパティがあることがわかります。たとえば、「寝室の数」の概念は、家とアパートのタイプにのみ実際に意味があり、空き地、駐車場、商業スペースには適用できません。では、これらの違いを組み合わせたタイプでキャプチャするにはどうすればよいでしょうか。

特定のタイプの特性を表すコンテンツタイプの作成

具体的なタイプの1つに固有の特性を処理するための1つのアプローチは、それに固有の特性を表すコンテンツモデルを作成することです。これらの特性は、「詳細」や「特性」などの名前を付けることができるリレーションシップを介してリストにリンクできます。

このアプローチの主な利点は、特定の具体的なタイプの特性のみを処理する一口サイズのコンテンツモデルがあることです。これにより、特定のタイプに関係のないコンテンツ要素に大量のnull値を送信することなく、特定のコンテンツアイテムに必要なデータのみを転送して、APIペイロードを軽量に保つことができます。

上記の点を示す例として、このアプローチでは、家のリストを処理している場合、他の未使用の特性要素はAPIを介して取得されません。

私の効果的なコンテンツモデリングシリーズのこの第2部は、コンテンツタイプを効果的に抽象化する方法の決定をガイドすることを目的としています。さまざまな異なるコンテンツタイプを単一のシンボリック名または完全に抽象化された名前に一般化する機能は、コンテンツモデラーとしての武器の強力なツールになります。ただし、このツールを控えめに、必要な場合にのみ使用することを忘れないでください。抽象化のための抽象化は、人々が日常的に実際に使用するのが困難になる可能性のある過剰に設計されたコンテンツモデルをすばやく作成する可能性があります。

コンテンツモデルの設計者として、コンテンツタイプの抽象化によって、人間が維持しやすい直感的でありながら、製品の将来をサポートするのに十分強力なモデルの作成に近づくかどうかを慎重かつ積極的に評価する必要があります。

コンテンツタイプの抽象化を検討するときは、次のガイドに注意してください。

• それぞれの抽象化が本当に必要かどうかを自問してください。
• 特にシンボリックタイプや抽象タイプを扱う場合は、ビジネスSMEに相談して、コンテンツタイプの名前が理解していることを確認してください。
• 具体的なタイプの特性として機能するコンテンツタイプを作成するときは、その関係で使用可能なコンテンツタイプを制限するようにしてください。これは、コンテンツ作成者がコンテンツアイテムを入力するときに非常に役立ちます。