BLOG

ネコの手も借りたい情報設計
三匹目「カモノハシ問題」

Fujii

ネコの手も借りたい情報設計<br>三匹目「カモノハシ問題」

こんばんは。キャットパッド藤井です。

実践で役に立つ設計キーワードをぼちぼち取り上げています。三匹目は「カモノハシ問題」についてです。表紙のチャトラさんは、台湾の九汾で出会った飼い猫さんです。

カモノハシ?

新学期が始まった動物学校に、新入生のカモノハシくんがやってきた。「みんな、グループに分かれましょう」と先生は言うけれど、誰とも少しずつ違うカモノハシくんは、「ぼく、いったいどのグループに入ったらいいの?」と泣きながら、教室を出ていってしまった。さあたいへん。(カモノハシくんはどこ?―生きものの分類学入門より)

「グループに分けようとしたところ、所属先が分からない」というような分類上の問題を、私は「カモノハシ問題」と呼んでいます。情報設計的に言うなれば「階層型分類におけるジレンマ」でしょうか。

階層型分類とは情報群を整理する際に用いるもっともメジャーな手法です。フォルダの中にフォルダを作って、情報をカテゴライズして細分化していきます。たとえばWindowsのフォルダを思い浮かべて下さい。

以下は、猫好き猫山さんのPCの中身です。ちょうど「三毛猫のミケ」と「白猫のタマ」の動画を整理しているので見てみましょう。

/movieフォルダ
  ┣/0630フォルダ
      ┣/MIKE/沢山のミケ動画
      ┗/TAMA/潤沢なタマ動画
  ┗/0701フォルダ
      ┣/MIKE/どっさりミケ動画
      ┗/TAMA/わんさとタマ動画

日付別、猫別と丁寧に整理されていますね。ミケもタマも幸せです。このように、階層型分類は「整理箱の中に、整理箱をいれて、その中に整理箱を・・・」という単純かつ汎用性の高い整理方法です。現実世界の整理術に似ているため、だれでも直観的に使いこなすことができます。

しかし猫山さんには悩みがありました。「ミケとタマを一緒に撮った動画をどのフォルダに格納すればいいのかわからない!」とのこと。さあ、あなたならどうしますか?

カモノハシ問題を理解する

カモノハシ問題に陥るパターンは、2あります。

  1. 格納できそうな場所が複数ある場合
  2. どこにも格納先が無い場合

「ミケとタマを一緒に撮った動画をどのフォルダに格納すればいいのかわからない!」という課題は、どちらのパターンにも当てはまりそうです。その上で、考えられる対応は「ミケ&タマ動画は、[MIKE-TAMA]という名称のフォルダを作って格納する」となるはずです。

/movie
  ┣/0630
      ┣/MIKE
      ┣/MIKE-TAMA
      ┗/TAMA
  ┗/0701
      ┣/MIKE
      ┣/MIKE-TAMA
      ┗/TAMA

普段使う分には、この解決方法で大丈夫でしょう。しかし情報設計の現場では、これだけでは不十分です。なぜなら、この手の問題は運用をすればするほど沸いて出てくるからです。

「二日に渡って動画を撮影した」「動画じゃなくて写真を撮ってみた」「2017になっちゃった」「新しい猫トラキチの出現」「タマの出奔」などなど。

これらの問題にできるだけ対応力のある設計を行う必要があります。カモノハシ問題に対する対応策の代表例を挙げておきます。

カモノハシ問題に挑む

第一の対応策 「ソフトリンク」

ある要素が複数のカテゴリーに属する場合、どれかひとつを本体、他を分身とする方法。(OSファイルシステムからの引用。エイリアス、ショートカット、シンボリックリンクなどとも呼ばれます。)

この解決法は「実体が必ず1つしか存在しない」という分かりやすさとメンテナンス性の良さから、サーバ構築やWeb構造設計などで、よく採用されます。結果を見てみましょう。

/movie
  ┗/0630
      ┣/MIKE/ミケ&タマ動画の実体ファイル
      ┗/TAMA/ソフトリンク

TAMAフォルダに、実体ファイルを置かずにソフトリンク(Windowsならショートカット。Macならエイリアス)を設置して対処しています。実体ファイルは1つだけです。ソフトリンクはリンクをしているだけなので、削除しても実体ファイルには影響はありません。

第二の対応策 「ダブル」

ある要素が複数のカテゴリーに属する場合、どちらも本体として扱って実体を複数存在させる方法。

/movie
  ┗/0630
      ┣/MIKE/ミケ&タマ動画の実体ファイル
      ┗/TAMA/ミケ&タマ動画の実体ファイル

ミケ&タマ動画の実体ファイルが2つ存在しています。ソフトリンクと違ってちゃんと実体が2つあるのでファイル容量は倍になっています。また片方だけを更新するとバージョンズレ(同期ズレ)が起こるのでメンテナンスは注意です。

合理主義の観点からは幾分か抵抗を感じるかとおもいますが、情報設計的にはアリです。デメリットもありますが、CMS(コンテンツマネジメントシステム・要はブログなど)ではよく見られる解決方法です。どれも実体になるのでユーザーから見た遷移文脈がブレません。

解決法の本質

これらの対応策の本質は「新しいルールを作らない」という点にあります。難しく言い換えると「体系を変化させていない」という点で、拡張性に優れます。体系とは、目的を持ったシステムのことを指します(猫もヤカンもECサイトも「体系」)。ちょっと難しくなっちゃったので、例を挙げてみます。

課題:コーポレートサイトを作っているとき「会社の所在地」をどこに置けば良いのか分からなくなってしまった。「お問合せ」と「会社概要」のどちらかだと思うのだが。

Webサイト制作あるあるですね。四つの解決法が考えられるので、並べてみます。

  1. ×:とりあえず「お問合せ」だけに置いておいた。
  2. △:新しく「所在地」というカテゴリーを作って記載。(カテゴリーが増設されたので体系が変化している)
  3. ○:会社概要に所在地を記載。お問合せからリンクを貼った。(ソフトリンクで対応。体系は変化せず。)
  4. ◎:会社概要とお問合せの両方に所在地を記載した。(ダブル。体系変化せず。こちらのほうがオススメ)

情報設計の現場において、問題に対する解決法は時間軸を意識して当るべきです。キレイに解決できた!と思っても、体系は運用を重ねる内に必ずほころびが出てきます。その経年劣化をできるだけ抑制するようなアイデアが求められるのです。

カモノハシ問題は解決した?

カモノハシ問題に対するソフトリンクとダブルという解決策は、あくまで対処法です。問題の悪影響を最小化することはできますが、根治することはできません。

そもそも、カモノハシ問題を起こらないようにするには?

さて、ここからが本番・・・でも長くなったので続きはまた今度!

カオスな明日にネコパンチ! キャットパッド藤井でした〜。

  • SHARE