川村渇真の「知性の泉」

データ検索や表示を助ける作業ステージ機能


作成したデータを整理したり検索する機能は、使い勝手に大きな影響を与える。今回は、情報中心システムにおけるデータ整理と検索の仕組みを、既存OSと比較してみよう。


 既存OSやオブジェクト指向OSは、データをファイル単位で保存する。階層型のディレクトリで整理するが、上手に整理できる人は非常に少ない。
 情報中心システムでは、「人間は情報整理が苦手」という前提で仕組みをつくる。整理しないでデータを作成し、呼び出すとき、条件に該当するものだけを見せる。
 また、仕事の目的ごとに作業ステージを定義する。そこでは、対象分野に加えて、数値の単位や言語なども設定する。これらは、知識ベースからの項目検索や、表示結果の作成に利用する。

既存OSのデータ管理はファイル中心だ

 ユーザーが作成したデータを表示、加工するには、そのデータを呼び出す仕組みが必要だ。それは、データを保存する方法に依存する。既存OSやオブジェクト指向OSの場合、ファイルが最小の単位だ。データを呼び出すときは、目的のファイルを指定する方式となる。
 どのようなデータがディスク内に入っているかを表示するのも、ファイル単位となる。Mac OSならFinderの役目で、アイコンとファイル名をセットにして表示する。
 ファイルの数が増えると、これらを整理するための機能が必要だ。それが階層型ディレクトリで、Macintoshではフォルダとして表示する。フォルダには名前をつけ、分類名としての役割もある。どのように分類するかはユーザーしだいで、多くの人は上手でない。目的のファイルがどこにあるのか探すために、いろいろなフォルダを行き来する。目的のファイルの場所が明らかな場合でも、そこに行き着くためには、オープンダイアログをなんども開いてクリックしていく必要がある。また、ファイル名から中身がわからないと、ファイルを開いて見ることもある。
 TaligentやCairoなどのオブジェクト指向OSになっても、この種の欠点はあまり改善されない。小さなファイルを組み合わせる方式なので、現在よりもファイルの数は増え、同じ仕組みなら混乱度は増すことになる。ただ、ファイルのリンク機能が向上するので、少しだけは改善されるだろう。

情報中心システムの基本は整理不要である

 情報中心システムでは、数値や日付や言葉といった単位でデータを保存する。ファイルよりも細かな単位なので、データの数は膨大になる。既存のファイルシステムのように整理したのでは、収拾がつかない。
 ところが、データを呼び出す機能(検索機能に相当する)が格段に向上することになる。それがObjectFirst機能だ。最終的に得たいデータの種類を指定すると、それに必要なデータだけを検索して表示してくれる。肥満率を求めるなら、身長と体重のデータを検索するというようにだ(図1)。条件に該当するデータを一覧表形式で表示し、その中から目的のデータを選ぶのだ。だから、Finderのようにファイルを並べて表示する必要も、ディレクトリを行き来する必要もない。

図1、肥満率を求めるときに、候補データを一覧表示した状態の例。身長と体重の値を持つ人物データだけを抽出して表示する。抽出条件を変更する機能で、男性だけとか身長の範囲などを指定できる。個々の人物データの詳細を表示する機能もある

図1

 情報中心システムでは、ユーザーが作成した全データを大きなデータベースに入れる。何種類もの検索キーがついていて、いろいろな属性を指定しながら読み出す。だから、目的の条件に該当するデータだけが、素早く検索できる。
 ただし、全データを一覧できる機能は必要だ。中に何が入っているのか調べるときに用いる。まれにだが、データを検索するときにも利用できる。この部分は、Finderの階層リスト表示に近いが、内容を細かく表示する機能が加わる。
 情報中心システムでは、「整理はコンピュータにやらせ、ユーザーは問題解決に集中する」というのが基本方針だ。つまり、ユーザー自身は整理しなくてよい。よく考えてみると、多くのデータを整理することは、人間に向いておらず、非常に苦手なのだ。どんなに几帳面な人でも、データが増えた状態では、ハードディスク上のファイルを整理できない。その意味では、整理しなくてすむ仕組みを用意することが重要で、既存OSもオブジェクト指向OSも、この点は満たせない。

「情報中心システムでは、          
  『整理はコンピュータにやらせ、     
    ユーザーは問題解決に集中する』   
           というのが基本方針だ」

作業ステージでは作業目的ごとに分類する

 情報中心システムの基本が整理不要だといっても、まったく分類しないのでは、さすがに効率が悪い。たとえば、肥満率を求める場合を考えてみよう。関係ない仕事のデータにも、身長や体重のデータが含まれていると、それも一緒に候補として現れてしまう。候補データの数が増え、選択操作が効率悪くなる。
 このような状況を改善するために、作業ステージという概念を導入する。作業ステージというのは、作業ごとにデータを分類する機能だ。仕事と趣味で分類するとか、プロジェクトごとに分けるとか、明らかにデータを区別できるような分類で用いる。仕事で2つのプロジェクトを担当しているなら、プロジェクトごとに作業ステージを定義する。趣味が3つあるなら、各趣味ごとに作業ステージを用意する。
 ユーザーが作成するデータは、必ずどれか1つの作業ステージに入れる。これで、大きなデータベースが、いくつかに分割できるわけだ。
 作業ステージを定義すると、最初に作業ステージを選ぶ必要が生じる。これから作成するデータが、どの作業ステージに入るのか、システムに知らせるためだ。カレント作業ステージとでも呼ぶとよいだろう。
 カレント作業ステージは、候補データの検索にも影響する。条件に該当するデータを探すとき、まずカレント作業ステージから始め、その次に他の作業ステージを続ける。検索した順番に候補データを表示するので、最初にカレント作業ステージ内が並び、他の作業ステージのデータが続く。
 ここで重要なのは、他の作業ステージも検索する点だ。作業ステージは、あくまで大雑把な分類でしかない。どこに入っていようと、必ず検索できることが「ユーザーが整理しなくてすむ」ことに通じるからだ。カレント作業ステージを利用する理由の1つは、その中のデータが候補の先頭に並ぶことである。カレント作業ステージに目的データが存在する確率は高く、先頭のほうに位置する可能性は高い。結果として、操作の量を減らす効果があり、作業効率を向上できる。
 作業ステージを用意するほどでもない雑多なデータを入れる目的で、汎用作業ステージも用意する。これは、システムで最初から定義しておく。最初はここにデータを入れ、データが増えたら作業ステージを定義して、データを移動するような使い方も可能にする。
 ずぼらな人は、汎用作業ステージだけですませるだろう。条件に該当する候補データは、システム側で自動検索してくれるので、作業ステージを定義しなくても、さほど不便だと感じないからだ。

作業ステージの階層化で整理好きの要望も満たす

 作業ステージが大雑把な分類だといっても、整理が好きな人なら、もう少し厳密に分類したいと思うだろう。そのような要望に応えるために、作業ステージの階層化もサポートする。この階層化はネットワーク型で、複数の親が1つの子供を共有できる(図2)。たとえば、一人が2つのプロジェクトに参加していて、重複しないようにスケジュール管理する場合を考える。スケジュール管理部分だけ独立した作業ステージを用意し、両方のプロジェクトの子供としてリンクする。

図2、ユーザーが作成したデータは、どれかの作業ステージに入る。データのリンクは、作業ステージをまたがることも可能。作業ステージは階層化して定義できる

図2

 リンクするメリットは、候補データの検索順序にある。スケジュール管理がカレント作業ステージの場合を考えよう。まず最初に、カレント作業ステージを探す。次は、カレントの子供の作業ステージ、カレントの親の作業ステージ、カレントの親の他の子供の作業ステージ、汎用作業ステージ、その他の作業ステージと続く。このような順序なので、関係が深い作業ステージほど、候補データが前に並ぶ。結果として、目的のデータが上位に位置する可能性が向上し、選択操作での作業効率が増すことになる。
 実際のところ、このように作業ステージを定義する人は少ないと思われる。前にも述べたように、作業ステージを定義しなくても、条件に該当するデータだけが候補として出てくるからだ。逆に、上手に使える人は、作業ステージを細かく定義して、作業効率を向上させられる。両方の条件を満たしつつ、使いやすい仕組みといえる。

作業ステージごとに対象分野を設定して効率化

 作業ステージを設ける本当の理由は別にある。作業ステージは、その名前が示すとおり、仕事の目的ごとに別々なステージを用意する。各ステージごとに、目的に合わせて環境を設定することで、効率よく操作することや、目的に合った表示内容を自動生成することに役立てる。  設定項目の1つは、対象分野だ。分野というのは、医療や財務や電気工学といったもので、各作業ごとの専門分野を示す。各データは、知識ベースの項目定義に関係している。すべての項目定義には分野があり、違う分野なら同じ言葉も定義できる。
 分野の設定が生きるのは、最終的に得たいデータの項目名を知識ベースから検索するときだ。特に項目名が不明の場合、あいまいな条件で探すことが多い。たとえば、条件を「『率』のつく言葉」とすると、多くの項目が該当する。効率よく探すためには、分野を限定する必要がある。しかし、項目を探すたびに分野を入力していたのでは、非効率だ。そこで、作業ステージごとに分野を設定し、項目名を探すときの条件に含める。これで毎回指定する必要はない。
 作業ステージごとに指定できる分野は、1つではない。優先度の高い順に複数設定する。もう1つの重要な点は、指定する分野の深さだ。たとえば、最初に「医療:麻酔」という第2レベルまでの分野を指定し、2番目に「医療」という第1レベルまでの分野を指定する。すると、「医療:麻酔」に該当する項目名が上位に並び、「医療」に該当する項目名が次に続く。ここでも、確度の高い候補が先に並ぶわけだ。
 項目定義を検索するときに参照する分野は、カレント作業ステージだけではない。カレントの親や子供の作業ステージに設定した分野も、カレントの次に参照する。この仕組みなら、分野の設定を最小限に抑えながら、目的の項目名を探しやすくできる。

作業ステージごとに数値単位などを設定

 作業ステージの環境設定は、他の環境条件にも利用できる。その1つが、デフォルトとなる数値単位の設定だ。
 たとえば、米国向けの資料を作成する仕事を考える。専用の作業ステージを用意し、長さと重さのデフォルト単位をインチとポンドに設定する。その中でつくった資料は、元データの単位がなんであれ、AutoExpression機能が作成する最終表示結果は、インチとポンドの値に変換される。数値を変換するだけでなく、表の見出しにつける単位もインチやポンドに変更される。
 もっと簡単にするなら、各国で使用する単位をまとめて定義し、作業ステージでは国名を指定するだけという仕組みにもできる。そうすれば、単位や項目の表記を、その国の言葉へと自動的に変換する機能も加えられる。
 作成したデータを別な作業ステージに移動すると、その環境設定に合わせて、表示内容が変わる。AutoExpression機能が、環境設定を参照して、新しい表示内容を自動生成するからだ。日本向けにつくった資料を、米国用の作業ステージに移動すれば、数値を米国の単位に変換して自動表示する。
 作業ステージの根本的な役割は、作業の目的ごとに環境を整えることにある。分野やデフォルト単位のほかにも、目的ごとに自動設定してほしい属性があるはずだ。それは、ソフトウェアを中心に考えたものではなく、情報を中心に考えたものだ。このような視点も、情報中心システムならではのものといえる。既存OSで用いられている、アプリケーションやファイル単位での環境設定とは、大きな差がある。
 今回は、データの整理と検索に注目しながら、環境設定まで含めてみた(表1)。情報中心システムでは、既存OSやオブジェクト指向OSと違って、ユーザーがデータを整理しなくてすむ仕組みを持つ。それにもかかわらず、目的のデータを検索するのは簡単だ。比べると、使い勝手では歴然とした差が出る。

表1、既存OSから情報中心システムまでの、データ検索と整理の機能比較。オブジェクト指向OSの詳細は不明だが、この部分が改善される見込みは少ない

               OSの進歩 =================>

表1

「作業ステージの根本的な役割は、           
    作業目的ごとに環境を整えること。       
  分野やデフォルト単位のほかにも、         
    目的ごとに自動設定してほしい属性があるはずだ」


下の飾り