はじめに

以前こんな記事を書きました。

take-she12.hatenablog.com

混乱を解決するために必要な情報設計。（混乱が起きないように、情報の見せ方、扱い方を予め整理して利用しやすいように設計すること）そして情報設計をやる上で避けては通れないのが分類です。

分類というものははじめにしっかり設計しないとそれこそ混乱を生むきっかけになります。何がどこにあるのか誰もわかっていない状態になりえます。そのため分類に関する汎用的な考えがないか自分で振り返ってみようと思います。

身近な分類

みなさんにとって最も身近な分類は、PC内データのフォルダ分けではないでしょうか。メールボックスのフォルダ分けでもいいです。このブログのカテゴリ分けもそうですね。昔だったら携帯の連絡帳をグループ分けしていましたし、持っているCDをジャンル分けして並べるかもしれないし、読んだ本をジャンルごとに分けるかもしれません。

このように身近に分類する場面はたくさんあります。これら全てに共通する方法はないか考察していきます。

粒度を揃える

これは必須だと思います。トップのフォルダに「料理」と「カレー」があってはいけませんし、「Ruby」と「プログラミング」が同じ階層にあってもいけません。

では異なる粒度が存在したときにどうするか。そのためには抽象化の作業が必要です。「歌詞」「ギター録音」「作曲」とあれば「音楽」と抽象化できます。

この抽象化の作業がテクニックが必要になってくると考えます。抽象化するときに「複数フォルダに存在しうるもの」が出てくるからです。

同一階層の粒度が全て揃っていることをゴールとして、どのように粒度を揃えるか、抽象化をしていくかを考えていきます。

複数フォルダへの所属可否

これを許すか許さないかのポリシーは最初に決めておくべきです。連絡帳に「会社」「大学」というグループを作っておいたとして、大学も会社も同じのひとが出てきたらどちらに所属させますか？連絡帳の場合はどちらにも登録するということができそうですが、単一の「データ」の場合、同一ファイルを複数フォルダ配下に置くことは、データをアップデートする際のコストになります。「録音」のフォルダと、やっているバンド名のフォルダがあった場合、そのバンド演奏の録音は「録音」であり「（特定の）バンド」配下の資産になります。

（この点はlinuxであればシンボリックリンクを使えばうまくやれそうだな、と今思いました。）

この点は複数フォルダにまたがるようなフォルダ分けをしなければ良い、という問題にも帰着します。しかしこれは所有するリソースに依存するため、汎用的な手法がなく、実データを見ながら抽象化して、粒度を揃えるというプロセスが必要になると思います。

トップダウンかボトムアップか

便宜上よく聞く言葉を使いましたが、実データを見ながらそれに合わせてフォルダを考えていく方法をボトムアップとし、最初にフォルダ階層を決めてからそれにデータを所属させていく方法をトップダウンと呼ぶことにします。

実際はどちらも進めていくことになるんですが、実データを観察してそこから特徴を抽出する、という方法は人間にできますが機械にはまだまだ出来ない分野だと思っています。（機械的なクラスタリング手法はあるものの、それは事前に特徴量を与えた上での方法であり、特徴量自体の抽出はディープラーニングが今やりだしたところで、まだまだ我々の私生活で必要としてくるグループ分けには適用できないと考えています。）

ボトムアップのアプローチは書いてある通りデータを眺めてこれとこれは仲間だな、と出していくしかないんですが、トップダウンに関しては工夫のしようがあると考えています。

それは「このデータ群は何のためのものか」を考えることです。アドレス帳であれば連絡するためのものなので、自分が連絡するときの利用シーンを考えて、利用しやすいグループわけを予め作る。社内のプロジェクトで共有で使うファイルサーバであれば、何を主目的としてチームで使うかを考える。それは「報告資料の共有」であれば資料の種別がトップに来るでしょうし、isoやソフトウェア・パッケージの共有であればOS別にできます。そしてその両方であればトップ階層は「報告資料」「パッケージ」になるでしょう。(粒度が揃っているようないないような。。。）