要点
- 呼び方の揺れにはシソーラス、置き場所の迷いにはタクソノミーが役立ちます
- 複数の情報がどう関係するかまで扱うなら、オントロジーを検討できます
- すべてを整えず、目の前の困りごとに合う方法から小さく始められます
Slackで共有された仕様を探し、Notionの議事録とFigmaの画面を見比べ、GitHubのIssueで変更の経緯をたどる。情報は揃っているのに、呼び方や置き場所が違うだけで確認に時間がかかることがあります。そんな状況を整理する手がかりとして、シソーラス・タクソノミー・オントロジーという3つの考え方を眺めてみます。
情報の量だけでなく、整理の基準にも目を向ける
情報過多というと、保存する量を減らすことに目が向きがちです。ただ、同じものが違う名前で呼ばれ、保存場所が人によって変わり、情報同士の関係も見えにくいことが負担になっている場合があります。
同じ「ユーザー」という言葉でも、仕様書ではサービスの利用者、データモデルではログイン済みのアカウントを指しているかもしれません。反対に、「モーダル」「ダイアログ」「ポップアップ」のように、違う言葉で同じ画面を指していることもあります。認識を揃えないまま設計と実装が進み、後から齟齬が分かって仕様変更になった経験もあるかもしれません。
言葉と分類と関係を整理することは、情報を探しやすくするだけでなく、こうした手戻りを減らす助けにもなりそうです。3つの考え方は、それぞれ次の役割を担います。
- シソーラス:言葉を揃える
- タクソノミー:置き場所を決める
- オントロジー:意味のつながりを記述する
シソーラス:呼び方を揃える
シソーラスは、言葉同士の関係を整理した語彙集です。同じ意味の言葉を代表語にまとめるほか、上位語・下位語や関連語も記録します。
たとえば、チーム内で同じUIを「ダイアログ」「モーダル」と呼んでいるなら、代表語を一つ決め、もう一方を同義語として結び付けられます。「オーバーレイ」を上位語、「ドロワー」を関連語として扱うこともできます。仕様書とデザインシステムで表記が違っていても、同じ情報へたどり着きやすくなるでしょう。
タグの表記揺れを抑えたいときや、社内検索で資料の取りこぼしを減らしたいときに使いやすい方法です。よく使うUI用語を一覧にして、代表語・同義語・関連語を記録するだけでも、小さなシソーラスになります。
教育文献データベースのERICでは、シソーラスの統制語を各文献に付与しています。「Indexing」には同じ検索先へ導く語や上位語、関連語がまとめられ、表現が異なる文献も共通の語彙から探せます(ERIC Thesaurus)。
タクソノミー:置き場所を決める
タクソノミーは、情報を一定の基準で分類し、主に階層として整理する仕組みです。たとえばデザインシステムなら、「基礎」の下に「色」「余白」「文字」、「コンポーネント」の下に「入力」「ナビゲーション」「フィードバック」を置く、といった構造が考えられます。
上位の分類から下位へたどれるため、情報の全体像を見渡しやすくなります。ドキュメント、社内Wiki、デザインシステムなど、共通の置き場所を用意したい場面に向いています。
一方で、複数の軸を一つの階層へ押し込むと、迷いが生まれることもあります。「エラー表示付きの入力フォーム」は、「入力」と「フィードバック」のどちらにも置けそうです。この場合は主となる分類軸を一つ選び、ほかの軸をタグで補う方法もあります。
Google Merchant Centerでは、商品を「Apparel & Accessories > Clothing > Outerwear」のように、大きな分類から具体的な分類へ配置します。独自の商品名でも共通の階層に対応させることで、商品群の整理や広告運用の軸として使えます(Google Merchant Centerの商品データ仕様)。
オントロジー:意味のつながりを記述する
オントロジーは、ある領域に存在するものの種類、性質、関係、必要に応じて制約を明示したモデルです。単に「近い言葉」「同じカテゴリ」として結ぶだけでなく、何と何が、どのような意味で関係しているかを表します。
たとえば、「機能」「画面」「コンポーネント」「API」「Issue」という種類を定義し、「画面は機能を提供する」「画面はコンポーネントを使う」「機能はAPIに依存する」「Issueは機能を変更する」といった関係を記述できます。すると、「このAPIの変更で影響を受ける画面と関連Issue」のような、複数の関係をたどる問いにも答えやすくなります。
Schema.orgには「Person」「Event」「Product」などの型と属性が定義されています。Webページの情報を意味のある関係として記述することで、検索エンジンが内容を理解する手がかりになります。Google検索の構造化データでも、主にこの語彙が使われています。
情報同士の関係そのものを利用したい場面では力を発揮しますが、設計と維持には手間がかかります。表記揺れを直したいだけなら、まずはシソーラスから試すほうが負担は小さそうです。
3つの違いと使い所
| 整理術 | 解決したい問題 | 中心となる構造 | 表現できる関係 | 主な使い所 | 具体例 |
|---|---|---|---|---|---|
| シソーラス | 呼び方が揺れ、検索から情報が漏れる | 用語のネットワーク | 同義語、上位語・下位語、関連語 | タグ管理、検索支援、用語統一 | 「ダイアログ」と「モーダル」を結ぶ |
| タクソノミー | どこに置くか、どこを探すか迷う | 分類の階層 | 上位分類と下位分類 | ドキュメント、デザインシステムの分類 | 「コンポーネント > 入力 > テキストフィールド」と分ける |
| オントロジー | 情報同士の意味関係をたどりにくい | 概念・属性・関係のモデル | 任意に定義した意味関係や制約 | 影響調査、データ統合、ナレッジグラフ | 「画面が機能を提供し、機能がAPIに依存する」と表す |
3つは、どれか一つを選ぶものではありません。タクソノミーで大きな分類を作り、シソーラスで使う言葉を揃え、複雑な検索やデータ連携が必要になった部分だけをオントロジーで表現する、という組み合わせも考えられます。
いま困っていることから小さく試す
どれを選ぶか迷ったら、利用するときに起きている問題から考えてみます。
- 同じ意味のタグが増えているなら、シソーラスが役立つかもしれません
- 保存場所の判断が人によって異なるなら、タクソノミーを試せそうです
- 機能・画面・APIの関係を横断して調べたいなら、オントロジーを検討できます
最初から完全な仕組みを作る必要はありません。まずは頻繁に使うUI用語を揃える、ドキュメントの大分類を見直す、といったところから始められます。それでも追えない変更や影響範囲が見えてきたら、必要な関係だけをモデル化する。この順序なら、日々の開発にも取り入れやすそうです。
おわりに
この記事では、情報が増えたときの整理を「言葉」「分類」「関係」という範囲に絞って眺めました。3つを比べてみると、高度な仕組みを導入する前に、まず呼び方や置き場所を揃えるだけでも変わることがありそうです。次に資料を探して手が止まったとき、迷いの原因がどこにあるのかを確かめるところから始めてみるのもよいかもしれません。
This article was originally published by DEV Community and written by miho.
Read original article on DEV Community