思考支援：雑誌連載の内容：第10回 |
Macintoshが非常に強いといわれるグラフィックソフトの分野。しかし、そのアプリケーションは本当に使いやすいのだろうか。『描くこと』自体が目的でなければ、『自分で描かなくてもすむ』機能は、とても便利なはず。さて、新世代OSに組み込まれるべきグラフィック機能の内容とは......。
今回は、グラフィックソフトの利用分野に焦点を当ててみた。絵を描ける人は限られているので、グラフィックソフトは、絵を描く以外の目的で利用されることが多い。AV機能の普及により、この傾向はますます強まるだろう。
情報中心システムでは、各種説明図を自動生成する。また、物や行動を抽象化した簡単な絵をシンボルとして登録する機能を持ち、それを自動生成した説明図に使う。シンボルは知識ベースの一部になるため、自動的に呼び出すことが可能だ。結果として、本当に絵を描きたいとき以外は、グラフィックツールを使わなくてすむ環境が実現できる。
GUI（グラフィカル・ユーザー・インタフェース）ベースのシステムは、テキストベースのシステムと比べて、グラフィックデータの扱いが得意だ。そのため、絵を描くためのグラフィックソフトが揃っている。しかし、それを利用して絵を描いているユーザーは少ない。理由は簡単で、多くの人は思ったように絵を描けないのだ。
とはいうものの、グラフィックソフトは確実に使われている。しかし、その多くは、絵を描く目的ではない。ビジネス用途を例にするなら、会社の組織図や作業の流れ図の作成に利用する。テキストでは伝わりにくい内容を表現するのがおもな目的で、これなら多くの人にも描ける。
また、説明図の中で用いる簡単な絵の作成にも用いられる。これも、絵を描くというよりは、抽象的なシンボルとして描いているという傾向が強い。芸術的やデザイン的な意味での絵とは異なるものだ。このような視点でグラフィックソフトの利用状況を見ると、純粋に絵を描く目的での比率はかなり低いといえる。
「グラフィックソフトを利用して、
絵を描いているユーザーは少ない。
理由は簡単で、
多くの人は思ったように絵を描けないのだ」
Macintoshを筆頭に、AV機能を持った機種が増えている。そのうちで重要なのは、ビデオ信号から映像を取り込む機能だ。これがあれば、ビデオカメラと組み合わせて、どんなものでも写真画像として取り込める。画面に表示したり、書類に張り付ける程度であれば、AV機能でも解像度は十分だ。
写真として取り込める機能が一般化すると、グラフィックソフトで絵を描く機会は減少する。絵を描くよりも、画像として取り込んで張り付けたほうが簡単だからだ。その結果、グラフィックソフトの利用目的のうち、絵を描くことの比率は、今後ますます減少するだろう。写真で代替する対象となるのは、シンボルよりも絵に近い用途といえる。絵を描く目的で用いるのは、描くのが好きな人だけになるだろう。
筆者は、グラフィックソフトの現在の使用状況から、利用目的を次の３つに分けた。組織図や流れ図などを描く「説明図」、物や行動や属性などを簡単なマークで示す「シンボル」、デザイン性や芸術性を意識した「絵」だ。
このうち「シンボル」というのは、作業の流れ図などで利用する、物を抽象化した簡単な絵のことだ。これを「絵」と分けることが、今回の重要なポイントとなる。シンボルの対象となるのは、人物や自動車といった形あるものだけでなく、走ることや歩くことのような行動も含まれる。また、人物の一部である手や足も入る。
これらのシンボルは、情報をわかりやすく表現する目的で使われている。たとえば輸送の流れ図なら、荷物やトラックの抽象的な絵を入れたほうが、文字と矢印だけで構成するよりも、直感的に理解できる。このような用途で用いるのがシンボルだ。特にビジネスの現場で頻繁に利用する。
「説明図」と「シンボル」を作成する目的は、残りの「絵」と明確に違っている。「絵」は、美しいとか雰囲気が出ているとか、絵自体の芸術的な仕上がりが重要だ。また、物の形やデザインを正確に伝える写実性を求めることもある。しかし、「説明図」と「シンボル」は、含む内容を明確に伝えることが目的であって、芸術的や写実的な仕上がりはそれほど重要ではない。それよりも、何の絵なのかハッキリとわかることのほうが重要といえる。自動車のシンボルなら、誰もが自動車であると認識することを重要視して描く。「説明図」である作業の流れ図なら、作業の流れを読みとりやすいことが大切だ。同様に組織図なら、組織構成をわかりやすく伝えることを第一目的とする。つまり、含まれる情報の視認性を重要視するのが「説明図」や「シンボル」なのだ。
とすれば、同じシンボルを多くの人が別々につくるのは非効率であり、最も目的に合ったものをひとつ用意して利用したほうがよい。説明図をつくることや、シンボルの目的で絵を描くことなどは、わざわざ人間がやる必要はない。できるだけ省いて、人間はもっと創造的な作業に集中すべきである。
このように考えると、今後のコンピュータでは、「説明図」と「シンボル」の作成作業をどれだけ自動化するかが重要だ。現在のグラフィックソフトのおもな利用目的が「説明図」と「シンボル」だとすれば、これを自動化することは、グラフィックソフトを使わなくてすむということにつながる。
情報中心システムでは、その点を十分に考慮している。つまり、本当に必要なとき以外は、絵を描かなくてすむ機能を組み込んであるのだ。既存OSやオブジェクト指向OSと比較しながら（表１）、「説明図」や「シンボル」を作成する機能を順番に見ていこう。
表１、現在のグラフィックソフトがカバーしている説明図やシンボルや絵を、システム内でどのように扱うかの比較。また、作成した絵などをどのように管理するかのデータベース機能も含む
OSの進歩 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＞
「説明図」に含まれる組織図や流れ図や関連図などは、既存OSの環境では、グラフィックソフトを用いて作成する。最近では、クラリスインパクトのように（図１）、ビジネスで用いる説明図を簡単につくれるソフトも出始めた。これを用いると、比較的簡単につくれる。オブジェクト指向OSも、基本的に同じだ。
図１、クラリスのクラリスインパクトは、ビジネス用グラフィックに限定されてはいるが、ユーザーの最小限の労力で目的の画像を作成できる。情報中心システムでは、この種の図は元データから自動生成するので、ユーザーが描く必要はない
情報中心システムでは、組織図や流れ図などの「説明図」をAutoExpression機能が自動生成する。ユーザーが指定するのは、どんな種類の図を描くかと、どのデータをもとにして描くかだ。あとはAutoExpression機能が自動的につくり出す。そのとき表現ルール集を参照するので、内容をわかりやすく表現するようにつくる。
ただし、図のもととなるデータが入力ずみでなければ、入力する必要がある。構造体データとして入力するため、ほかの目的にも流用できるメリットがある。会社の組織構成データを１つつくると、組織図を描く以外にも、社内報の配布先をリストアップしたり、給与計算や人事管理にも使える。
より正確にいうなら、まず最初に社員の人物データがあり、それにリンクする形で、会社の組織構造図を構成する（図２）。つまり、会社の人事情報や組織構成などが、それぞれに関連を持ちながら、ひとつの大きなデータを形づくっているのだ。だからこそ、データの幅広い流用が可能となる。
図２、情報中心システムでは、細かなデータをリンクしながら構造体データに組み立てる。構造体データもリンクして、より大きな構造体になる。企業データであれば、その中の全部のデータがリンクしていて、大きなデータベースのように扱える
構造体データから各種説明図を自動生成するので、できあがった組織図自体は保存しない。保存するのは、自動生成するときに指定した細かなオプションだけだ。また見たくなったときに、AutoExpression機能に生成させればよい。
このような構造のため、組織構成に変化があっても、組織構成データだけを直せばよい。見たいときに自動生成するので、そのときの最新状態で組織図が描かれる。
既存OSやオブジェクト指向OSでは、組織に変化が起こったとき、給与計算や人事情報のデータを更新するとともに、組織図を描いたグラフィックデータも更新しなければならない。それらは別なファイルとして保存してあるため、直し忘れも発生する。
元データから自動生成する仕組みは、違うメリットも生む。組織図を描くとき、東京在住の社員だけを抽出して描くとか、一部の部門だけで描くとか、元データに条件を加えられる点だ。ほかの説明図に関しても、同様の機能が使える。
これが可能になるのは、元データがすべての情報を含んだ大きな構造体であることに加え、組織図などを自動生成する機能のためだ。
情報中心システムでは、「シンボル」を知識ベースに入れる。項目定義や構造体定義の一部として組み込む。人物のシンボルなら、人物の構造体定義に含めるといった具合にだ。必ずシンボルを入れる必要はないが、使用頻度の高いものだけは標準で用意する。
シンボルは、説明図をわかりやすくつくるだけでなく、一覧表形式で画面に表示するときにも役立つ。項目や構造体の名前よりは、シンボルのほうが表示面積が少なくてすむし、パッと見たときの認識性も高い。また、項目や構造体だけでなく、処理にもシンボルを持たせる。それにより、処理の流れの表示を抽象化して画面表示することも可能だ。
既存OSとオブジェクト指向OSでは、「シンボル」をサポートする機能を持たない。もともとの発想として、情報をわかりやすく表現することなど、ほとんど考慮していない。アプリケーション側でも同様で、ユーザーが工夫しながら実現すべきことだと思っている。唯一の例外はソフトの操作で、これだけはわかりやすくしようと工夫している。しかし、ユーザーが作成する情報自体をわかりやすくすることには、まったく無関心だ。このような古い考え方でシステムを構築しているので、サポートを期待するのが無理というものだろう。
結果として、通常の「絵」と同じように、グラフィックソフトで描いて、ドローソフトの書類へ張り付けるしかない。もちろん、ユーザーがすべて手動で作成する。
「シンボル」のデータは、拡大縮小可能なグラフィックデータが適する。抽象的な絵でかまわないので、簡単なドロー機能があれば十分だ。小さく表示するときのことも考慮して、アイコンのように何種類かのドット数のビットマップ画像も含められたほうがよいだろう。
情報中心システムの「シンボル」は、流れ図などを自動生成するときに用いる。たとえば、輸送の流れ図を描くとき、トラックの絵をシンボルとして加える。そのとき重要なのは、トラックの絵の向きだ。それが進行方向を示す矢印と一致していなければ、見る人に不自然な感じを与える。
この問題を解決するためには、シンボルの絵に関して、前を示す方向情報の属性を持つ必要がある。また、前向きと横向きのシンボルの絵を用意して、最適なものを選んで使えるようにする。各シンボルに加える属性は、方向以外にも何種類か標準化することになるだろう。
「絵」を描く機能に関しては、既存OSとそれほど違わない。情報中心システムでも、グラフィック機能を利用して絵を描く。
最も違う点は、絵を管理する機能だ。既存OSでは、画像データベースソフトを用い、キーワードを手動で加えながら管理する。オブジェクト指向OSでも基本的に同じだが、画像の引き出し方が多少改善されるだろう。
しかし、情報中心システムでは、構造体データの中に絵や写真も入れる。ある人物の顔を描いた絵であれば、その人の人物データに含める。テキストや数値データと一緒にだ。このような仕組みのため、キーワードをつけて整理する必要がない。似顔絵のグラフィックデータなら、対象となる人物データへ、顔データとしてリンクするだけだ。あとはObjectFirst機能が持つ抽出機能によって、必要なときに呼び出される。それも、同じ人物データに含まれるテキストや数値と一緒にだ（図３）。
図３、企業データ内の人物データに似顔絵や顔写真を顔データとして入れておくと、組織図を描くときに利用できる。ユーザーが顔データ入りを指定することで、似顔絵または顔写真入りの組織図を自動生成する。
結果として、情報中心システムは、画像データベースを標準で内蔵することになる。それも、既存OSのように、画像データベースとして独立しておらず、ほかの機能と上手に融合した形でだ。
ここまで解説したように、情報中心システムでは、できるだけ絵を描かなくてすむような仕組みを、最初から用意してある。これにより、ユーザーは内容そのものの充実へと労力を集中できる。
「情報中心システムは、
画像データベースを標準で内蔵することになる」
できるだけ絵を描かずにすませる |
