WordPressからデータ構造設計のヒントを得る / Data Structure Design Tips from WordPress

データ構造やオブジェクトに焦点を当てて、アプリケーション設計時に意識したい点をまとめました。コンテンツ管理システムのWordPressからデータ構造のヒントを得たいと思います。

関連記事：ユーザーインターフェイス設計メモ
https://yuyakinoshita.com/blog/2022/06/08/user-interface-note/

----
Website: https://yuyakinoshita.com
Twitter: https://twitter.com/yuyaink

Transcript

2. ⽊下 裕哉 Yuya Kinoshita デザイナー フロントエンドエンジニア yuyakinoshita.com @yuyaink
3. はじめに
4. この資料のゴール データ構造について知ることで 情報設計のヒントを得る
5. さらなる狙い ユーザーにとってより使いやすい データ構造を意識できるようになること
6. 主な対象者 Webサイト、アプリなどの ユーザーインターフェイス設計に関わる⽅ UIデザイナー、ディレクター、フロントエンドエンジニアなど。
7. Index 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. データの流れについて基本を振り返る データ構造を意識するメリット WordPressを題材に選んだ理由 コンテンツ管理システムの全体像 WordPressにおけるオブジェクトの全体像 記事のデータ構造 記事の公開状態 記事の公開⽇時と並び順 記事の分類属性（カテゴリーとタグ） カテゴリー分類とタグ分類の違い 階層あり分類のコウモリ問題とは？ 複数の検索⼿段が必要な理由（検索キーの設計） データの⾏き来のしやすさ
8. データの流れについて 基本を振り返る 1
9. まずはデータの流れの基本を知る （共通の基本要素を抑える） ※前回の資料の内容からの振り返りです。
10. データのアクションは作成、読み出し、変更、 削除の4つが基本です。
11. データの基本アクション •作成（Create） •読み出し（Read） •変更（Update） •削除（Delete） Data Create Update Delete Read 4つの頭⽂字からCRUDとも 呼ばれるようです。
12. データ構造を意識するメリット 2
13. そもそもデータ構造って何？
14. “コンピュータプログラミングでの、データの集 まりの形式化された構成である。格納された各 データの参照や修正といった管理を容易にする ための構成である” From: Wikipedia Wikipediaから引⽤
15. このように解釈しています •データを扱いやすくするための構造 •⻑期的にサービスを拡張するための⾻組み •⼤事なのは拡張性とデータの⾏き来のしやすさ
16. データ構造を意識するメリットは？
17. データ構造を意識するメリット •データのつながりを把握しやすくなる •データへのアクセス⽅法がシンプルになる •サービス全体の構造を整理しやすくなる ユーザーにとってより使いやすいサービスに近づくと考えています。
18. データ構造について知るために、WordPress を参考にしながら⾒ていきます。 ※構造の参考であり、WordPressの使い⽅紹介は⽬的としていません。
19. 3 WordPressを 題材に選んだ理由
20. そもそもWordPressってどんなもの？
21. Webサイトのコンテンツを管理するためのシス テムです。主にブログ、メディアサイト、企業サ イトなどのコンテンツ管理に使われています。
22. 管理画⾯ WordPressの管理画⾯で す。時系列によるコンテンツ 管理に優れています。
23. 表⽰されるページ 管理画⾯から登録したデータ （データベース）と、構築し たデザインテンプレートを元 にページが⽣成されます。
24. なぜデータ構造を学ぶために WordPressを題材にするの？
25. 主な理由 •データの基本構成を学べる •時系列の概念やデータ分類について学べる •アプリケーション開発やUI設計に応⽤できる オープンソースで⼿軽に試しやすいことも理由の1つです。
26. 過去にフルスクラッチによる約180画⾯のシス テムのUI設計や開発にも関わったのですが、デ ータをどう扱うかの基礎として、WordPress から応⽤できることが多いと感じています。 Movable Type、WordPress、MODXなどのCMSに触れてきました。
27. 4 コンテンツ管理システムの全体像
28. WordPressについて⾒ていく前に、まずはコ ンテンツ管理システム（CMS）の概要や全体像 を⾒ていきたいと思います。
29. 突然ですが質問です。次の図のXとYは何かを表 しています。何を表しているでしょうか？ Q
30. 閲覧ユーザー ?????? ??? データの 登録・読み出し・ 編集・削除 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 管理ユーザー X Y
31. CMS アプリケーション、業務システム、コンテンツ 管理画⾯、WordPressなども正解です。 DB、phpMyAdmin、リレーショナルデータ ベースなども正解です。 データベース X Y 正解は
32. データベースって何？ いろいろ新しい⽤語が出てきた…
33. “データベース（英: database）は、電⼦的に 保存され、アクセスできる組織化されたデータ の集合である。” From: Wikipedia Wikipediaから引⽤
34. どういうこと？
35. ⼤まかにこのように解釈しています •たくさんのデータの集合体 •データは「種類」と「値」で構成される •Googleスプレッドシートのようなイメージ データの種類はキー（Key）、値はバリュー（Value）と表現されます。
36. 簡略化したイメージで データベースを⾒てみます
37. 名前 ID ⾊ リンゴ バナナ ブドウ 1 2 3 ⾚ ⻩ 紫
38. データベースでは、データが種類（Key）と値 （Value）によって管理されます。
39. 名前 ID ⾊ リンゴ バナナ ブドウ 1 2 3 ⾚ ⻩ 紫 Key Key Key
40. ⻩⾊いセルの部分がデータの種類（Key）を表 しています。この表では、ID、名前、⾊がデー タベース上の種類（Key）です。
41. 名前 ID ⾊ リンゴ バナナ ブドウ 1 2 3 ⾚ ⻩ 紫 Value Value Value Value Value Value Value Value Value
42. データの種類に対する値がValueです。例えば IDが「1」のデータでは名前に「リンゴ」とい うデータを持っています。IDが「2」の場合は名 前に「バナナ」というデータを持っています。
43. ⼀般的にデータの主軸となる種類（Key）はID であることが多いと感じます。例えば『IDが 「2」のデータの名前は「バナナ」です』という 使われ⽅が多いのではないかと思います。 IDは他と重複しない（ユニークである）とう前提があるからだと考えます。
44. 実際のデータベースはより多くのデータを扱いま すが、イメージとしてはこのように捉えておけば ⼤丈夫だと思います。 データベースの概念について⼤まかに捉えたうえで、全体図を⾒てみます。
45. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 管理ユーザー
46. 情報量が多くやや複雑なので、それぞれのユー ザーごとに注⽬してみます。
47. 管理ユーザーの場合 ユーザーごとの視点
48. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 管理ユーザー
49. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 構造化された データの集まり 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 データ 管理画⾯ データ管理⽤の インターフェイス（接点） データの登録・読み出し・ 編集・削除 管理ユーザー
50. 管理ユーザーの視点でのコンテンツ管理システム（CMS）とは？ •CMSを通してデータベースにアクセスする •データの登録・読み出し・編集・削除ができる •データ管理⽤のインターフェイス（接点） と⼤まかに考えられます。
51. 閲覧ユーザーの場合 ユーザーごとの視点
52. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 管理ユーザー
53. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 構造化された データの集まり 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 デザイン テンプレート 管理ユーザー ページ⽣成⽤の インターフェイス（接点） データの 読み出し
54. 閲覧ユーザーの視点でのコンテンツ管理システム（CMS）とは？ •CMSを通してデータベースにアクセスする •データの読み出しができる •ページ⽣成⽤のインターフェイス（接点） と⼤まかに考えられます。
55. 全体像を⾒てみます
56. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 構造化された データの集まり 構造化された データの集まり 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 データ 管理画⾯ データ管理⽤の インターフェイス（接点） データの登録・読み出し・ 編集・削除 デザイン テンプレート 管理ユーザー ページ⽣成⽤の インターフェイス（接点） データの 読み出し
57. 役割に注⽬してみると、コンテンツ管理システ ム（CMS）がおこなっていることはデータベー スへのデータの登録・読み出し・変更・削除の どれかだということが⾒えてきます。
58. データの基本アクション •作成（Create） •読み出し（Read） •変更（Update） •削除（Delete） Data Create Update Delete Read 実はCMSがやっていること も基本アクションの4つ。 CMSも同じ
59. •CMSを通してデータベースにアクセスする •CMSはデータへアクセスを簡単にしている •UIデザインとはデータへのアクセス⽅法の設計 と考えられるのではないでしょうか。 まとめると
60. 5 WordPressにおける オブジェクトの全体像
61. WordPressで特に重要な記事、カテゴリー、 タグ、ユーザーのデータ構造を⾒ていきます。 カテゴリー タグ ユーザー 記事
62. データを機能名と区別して対象物として捉える ため、ここではオブジェクトと呼びます。 記事 オブジェクト ユーザー オブジェクト タグ オブジェクト カテゴリー オブジェクト
63. 全体像を知りたい
64. 全体像とつながり 記事オブジェクトと各オブジ ェクトが紐付いた構造になっ ています。 •記事 •カテゴリー •タグ •ユーザー 補⾜ オブジェクトの種類 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト
65. 記事のデータ構造 6
66. WordPressが扱うメインのデータが記事で す。記事オブジェクトがどんな属性を持ってい るかを⾒ていきます。
67. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This
68. 記事オブジェクト メインコンテンツ 概要情報 分類属性（ひも付いているオブジェクト） •記事タイトル •記事本⽂・画像・動画など •表⽰状態（公開 / ⾮公開） •公開⽇時 •URLスラッグ •アイキャッチ画像 •カテゴリー •タグ
69. それぞれの記事オブジェクトがこれらの属性 （情報）を持っています。ユーザーは新規に記事 をつくり、関連する属性情報を合わせて登録す ることでコンテンツを管理します。
70. アプリケーション設計に活かす観点は？
71. •対象物をオブジェクト（名詞）として捉える •データの核となるオブジェクトが何かを考える •そのオブジェクトにひも付ける属性を考える Point
72. 記事の公開状態 7
73. 記事の公開状態 WordPressでは記事の公開状態に、公開、⾮ 公開、パスワード保護の3種類があります。
74. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This
76. 公開状態 •公開 •⾮公開 •パスワード保護 •ラジオボタンで単⼀選択 •初期状態は「公開」 属性 補⾜
77. どういった使い分けが考えられるか？ •公開：記事を公開するための通常の状態 •⾮公開：公開後に⼀時的に⾮公開にする •パスワード保護：特定ユーザーのみに表⽰する
78. アプリケーション設計に活かす観点は？
79. •要素に⾮公開の状態が必要か？ •パスワード保護のアクセス⼿段を⽤意するか？ •公開・⾮公開のどちらを初期状態とするか？ オブジェクトの公開管理機能の設計観点に役⽴つかもしれません。 Point
80. 記事の公開⽇時と並び順 8
81. 公開⽇時と並び順 WordPressの初期設定では、公開⽇時が新し い記事から表⽰されます。記事の並び順（ソー ト順）を公開⽇時によって管理します。
82. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This
84. 公開⽇時 •⽇付 •時刻 属性 •作成時点の⽇時が⾃動反映 •カレンダーピッカーを併⽤ 補⾜
85. アプリケーション設計に活かす観点は？
86. •要素は公開⽇時順で表⽰するか？ •ユーザーにとってより便利な並び順の条件は？ •そもそも公開⽇時が属性として必要なのか？ 他の並び順には、名前、更新⽇時、価格、⼈気（評価）などもあります。 Point
87. 記事の分類属性 （カテゴリーとタグ） 9
88. 記事の分類属性 カテゴリーやタグは、WordPressに備わって いる記事の分類属性です。ここではタグがどん なユーザーインターフェイスとして表現されてい るかを⾒てみます。
89. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This
90. タグ⼀覧 •タグ名 •タグスラッグ（URL) •タグの説明 属性 •オブジェクトで管理 •フリーワードで検索できる •複数タグを⼀括削除できる •該当する記事数がわかる •該当の記事⼀覧へ遷移する 補⾜
91. タグオブジェクト •タグ名 •タグスラッグ（URL) •タグの説明 属性 •オブジェクトで管理 •いつでも再編集が可能 •詳細ページからも削除可能 補⾜
92. アプリケーション設計に活かす観点は？
93. •カテゴリーやタグはいつでも編集できるように •対象要素とのアクセスの双⽅向性を保つ •フリーワード検索など、検索しやすい構造に Point
94. カテゴリー分類とタグ分類の違い 10
95. WordPressには記事の分類⽅法として、カテ ゴリー分類とタグ分類の2種類が存在します。こ れらによって記事を分類して管理します。 カテゴリー分類とタグ分類の違い
96. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This This
97. WordPressのカテゴリー分類とタグ分類は 何が違うでしょうか？ Q
98. 正解は階層構造になっているかどうかです 階層あり カテゴリー分類 階層なし タグ分類
99. “categories: a hierarchical taxonomy that organizes content in the post Post Type tags: a non-hierarchical taxonomy that organizes content in the post Post Type” From: WordPress Developer Resources 公式ドキュメントからの引⽤
100. カテゴリーは階層構造を持っており、タグは階 層構造を持っていません。
101. この考え⽅をデザインにどう活かすの？
102. データを分類するときに「階層構造にする・し ない」の判断基準として活⽤します。
103. どういうこと？
104. データの分類は「階層構造あり」が適した場合 と「階層構造なし」が適した場合があり、状況 によって使い分ける必要があると考えています。
105. ⼀般的なフォルダ構造は階層ありだし、 階層ありだけじゃ駄⽬なの？
106. 階層ありのほうが⼈間にとってわかりやすく、 適している場合が多いと思います。その⼀⽅で 階層ありにはコウモリ問題と呼ばれる分類上の 問題が存在します。
107. 階層あり分類の コウモリ問題とは？ 11
108. 例えば「デザイン」と「コーディング」という 分類属性があるとして、その両⽅に当てはまる 記事の場合にどちらに分類すれば良いのか迷っ てしまうことはないでしょうか？
109. 「複数の属性から何を選んで分けるか」という 悩みは、コウモリ問題という名前が付いている ほどに⼀般的な問題のようです。
110. “すべてのものや情報は、利⽤される⽂脈に応じて複数の属性を持ち得る。し かし、階層構造のように、各項⽬を⽊構造の末端にあてはめて分類する⽅式 （図書館資料など）では、項⽬が持つ複数の属性のうちの⼀つだけに着⽬し なければならないという制約がある。” From: Wikipedia Wikipediaから引⽤
111. コウモリ問題を解決する⼀般的な⽅法が、複数 の属性付けを可能にするタグ分類だと考えてい ます。
112. それならタグ分類のような 階層なしの分類にしておけば良いの？
113. いいえ、扱うデータやユーザーが使う状況によ って「階層あり」と「階層なし」の使い分けが 必要だと考えています。 それぞれにメリットとデメリットがあります。
114. データの親⼦関係や構造が わかりやすい。 2つ以上の分類属性を持っ たままデータを管理でき、 分類に悩まなくて済む。 2つ以上の分類属性を持つ ことができず、1つに絞ら なければならない。 親⼦関係のようなデータの 関係性は持てない。 メリット デメリット 階層あり 階層なし
115. 階層ありと階層なしの 使い分けはどうすれば良い？
116. 状況によって判断が必要になりますが、⼤まか にどちらに向いているかを整理してみました。
117. •明確な整理ルールが必要 •構造のわかりやすさ重視 •厳格な管理者がいる •⼤まかな整理に留める •複数の属性を持たせたい •厳格な管理者がいない •⼤まかな整理に留める •複数の属性を持たせたい •厳格な管理者がいない •明確な整理ルールが必要 •構造のわかりやすさ重視 •厳格な管理者がいる 向いている 向いていない 階層あり 階層なし
118. WordPress以外にも参考に なるサービスやアプリケーシ ョンはたくさんあります。 階層の有無や、どういった分 類を使いやすいと感じるかを 意識してみるのも⾯⽩いかも しれません。 Which is better? Hierarchical Non- Hierarchical
119. アプリケーション設計に活かす観点は？
120. •要素の分類に階層構造が必要かを考える •⼤まかに分類するのか、細かく管理するのか？ •要素の分類を管理する体勢は整っているか？ Point
121. 複数の検索⼿段が必要な理由 （検索キーの設計） 12
122. 検索キーが複数あること WordPressには記事の検索⽅法として、カテ ゴリー、タグ、投稿者、⽇付、フリーワードな どによる検索機能が標準で備わっています。
123. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This
124. 記事⼀覧 •投稿者 •カテゴリー •タグ •フリーワード 検索キー（Key） •属性で絞り込める •フリーワードで検索できる 補⾜
125. 記事⼀覧 •⽇付（⽉別表⽰） •カテゴリー 絞り込み条件 •⽉ごとに絞り込める •検索キーと組み合わせ可能 補⾜
126. もし検索機能がなかったら？
127. データ件数が増えるにつれて、1つ1つ探すのは とても⼤変です。その解決策として何らかの絞 り込み検索が必要になります。
128. メインオブジェクト（記事）が 1000件以上のように ⼤量のデータになった場合の課題は？ 例えば
129. 1つの検索キー（Key）では、必要な記事を絞り 込めない可能性が⾼いことです。もしくは記事 に付けたカテゴリーやタグを覚えていない場合 に記事を⾒つけにくくなります。
130. 設定したカテゴリーやタグを覚えていない場合 の解決⽅法に、フリーワード検索があります。 フリーワード検索は多くのアプリケーションに 備わっており、ユーザーが基本機能として期待 している可能性が⾼いです。
131. フリーワード検索は⼀般的な検索機能である⼀ ⽅で、検索結果の出し⽅によって使い勝⼿に⼤ きく差が出る機能だと考えています。使いやす いフリーワード検索機能を実装するためには、 必要な観点が多いです。
132. •曖昧なキーワードによる検索を許容するか？ •検索対象とするデータベースの範囲は？ •複数キーワードによる絞り込みを許可するか？ 例えば 検索結果を出⼒する反応速度やサーバーへの負荷も検討が必要です。
133. アプリケーション設計に活かす観点は？
134. •投稿者、カテゴリーなどの属性で絞り込める •公開⽇時や更新⽇時で絞り込める •フリーワードで検索できる（検討事項が多い） これらの検索機能の必要性は優先的に検討したいです。 Point
135. データの⾏き来のしやすさ 13
136. 検索キーが複数あること ここではデータ同⼠のつながりに注⽬してみま す。記事とタグはそれぞれがオブジェクトとして のデータ構造を備えつつ、データのつながりが あります。
137. 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト This This
138. 記事⼀覧 記事オブジェクトにはタグが 設定でき、設定済みのタグが 関連付けられています。
139. 記事⼀覧 試しに「制作環境」というタ グを選ぶと、制作環境タグの 付いている記事オブジェクト が並びます。
140. 次はタグ側から⾒てみます
141. タグ⼀覧 カウントという表⽰項⽬があ ります。これはこのタグが関 連付けられている記事数を表 しています。 試しに制作環境タグの右側に あるカウント欄の「4」を選 んでみます。
142. 遷移先の記事⼀覧 そうすると「制作環境」タグ で絞り込んだ記事⼀覧ページ が表⽰されました。 記事オブジェクトとタグオブ ジェクトがデータのつながり によって関連付けられている ので、スムーズにアクセスで きます。
143. 関連情報にアクセスしやすい構造 記事⼀覧ページ タグ⼀覧ページ
144. 関連データへの⾏き来のしやすさ（アクセスの 双⽅向性）を考えて設計すると、より使いやす いUIに近付くと考えています。 WordPressのタグ⼀覧ページから記事⼀覧ページへの導線は⼀⽅通⾏です が、データの関連付けの参考になります。
145. アプリケーション設計に活かす観点は？
146. •データの⾏き来のしやすさ（双⽅向性）を意識 •オブジェクトはそれぞれで常時編集できる •ユーザーが使いやすいデータのつながりを探す ⼿書きメモやプロトタイプで⾏き来してみると、改善点に気付きやすいです。 Point
147. この資料で重要な ポイントをおさらい
148. データの核となる対象物をオ ブジェクト（名詞）として捉 え、そのオブジェクトにひも 付く属性を考える。
149. 対象物は何か？ WordPressなら、記事、カ テゴリー、タグ、ユーザーを 主要オブジェクトと捉えてい ます。 オブジェクトとして捉える 記事オブジェクト カテゴリー オブジェクト タグ オブジェクト ユーザー オブジェクト
150. オブジェクトは、それぞれが 常時編集できる構造とする。
151. 常に編集できる 例えばタイトルを変える、 URLを変えるなどの属性の 編集・追加・削除が常にでき る構造として設計すると、耐 久性が上がり⻑持ちします。 常時編集できる構造に
152. データの⾏き来のしやすさと して、アクセスの双⽅向性を 保てているかを意識する。 ユーザーがより便利にサービスを使えるよう に、データオブジェクト同⼠をスムーズに⾏き 来できるように設計することが望ましいです。
153. データの双⽅向性を意識する 記事⼀覧ページ タグ⼀覧ページ
154. 迷ったら全体像を⾒直して、 誰に向けて何をつくっているのかを 振り返ってみる
155. 閲覧ユーザー データベース CMS データの 登録・読み出し・ 編集・削除 構造化された データの集まり 構造化された データの集まり 管理画⾯に ログイン ページを表⽰ ページが⾒たい データの読み出し データの要求 データ 管理画⾯ データ管理⽤の インターフェイス（接点） データの登録・読み出し・ 編集・削除 デザイン テンプレート 管理ユーザー ページ⽣成⽤の インターフェイス（接点） データの 読み出し
156. おわりに
157. デザイナーやディレクターがデータベースを設計 することは稀かもしれません。ですがどんなデ ータがあったらユーザーにとってより便利かを 考え、提案する機会はあると思っています。 この資料がそのようなきっかけになったら幸いです。
158. ありがとうございました