思考支援：雑誌連載の内容：第35回 |
今回はいよいよ最終回。取りあげるテーマは、「既存OSのアプリケーションに相当する機能を実現するための方法」である。項目定義や処理定義に表現フレームを加え、目的に直結した形のシステムとして仕上げる。こうしたシステムは、拡張しやすいことに加え、ユーザーの自由度も高い。アプリケーションという制限から解放され、情報をより自由に扱える環境が得られる。
既存OSでは、ほとんどのソフトがアプリケーションの形態を取っている。ところが、情報中心システムには、アプリケーションという概念がない。そのため、アプリケーションに相当する機能は、まったく異なる方法で実現する。情報中心システムでの作成方法を解説する前に、既存OSでのアプリケーションの位置付けを分析してみよう。
一般にアプリケーションと呼んではいるが、正確にはアプリケーション・プログラム（注１）で、ソフトウェアの形態の１つを指す。現在のほとんどのソフトは、アプリケーションの形でつくられている。特定業務用のソフトから、開発ツールやユーティリティまで、幅広い範囲におよぶ。ざっと挙げてみよう。ワープロ、表計算、データベース、コンパイラ、各種ユーティリティ、画像編集、ムービー編集、財務会計、プロジェクト管理……。このように、ありとあらゆる分野が含まれる。
これらをよく見ると、汎用的な目的に使うソフトが多いことに気づく。例を挙げるならば表計算ソフト。これは、計算を含む内容なら何にでも使える。計算を含まない住所録の管理に使う人もいる。Excelのようにプログラム機能を持つソフトなら、簡単な業務ソフトもつくれる。コンパイラやデータベースも同様で、いろいろな用途のシステム作成に使われる。素材をつくるためのソフトも多い。グラフィック、サウンド、ムービーの編集などだ。素材をつくるのが目的なので、どんな分野でも使える。
こうして全体像を見ると、幅広く使えるソフトが多い。だが逆の見方をするなら、実際に役立てるためには、ユーザーの作成する部分が多いともいえる。いわば、原石に近いソフトの集まりだ。
注１：アプリケーションという言葉は「適用業務」と訳される。最初は、開発ツールではない特定業務プログラムのことを指していた
「市販のソフトウェアは確かに幅広く使えるが、
ユーザーの負担も大きくなるのが難点」
情報中心システムでも、既存OSのアプリケーションに相当する機能（ここでは目的別サブシステムと呼ぶ）を構築できる。ただし、実現方法はまったく異なる。システム内で利用可能な部品を組み合わせ（図１）、同じ目的を達成する（注２）。
図１、既存のアプリケーションに相当する目的別サブシステムをつくる際に、用意する構成要素。システムが持たない特殊な処理や表現が必要なら、ドライバなどを追加する。これは、ほかの目的別サブシステムでも利用できる
扱うデータを規定するのは、項目定義と構造体定義だ。数値でも動画でも、システム内で扱えるデータなら、何でも受け付ける（注３）。構造体定義によって、関連する項目が管理できるため、画像に名前やタグをつけるのも簡単だ。異なる種類の構造体は、リンクによって結びつけられる。この関連も構造体定義で設定する。
データを加工する処理は、処理定義として用意する。数値の計算だけでなく、画像処理や集計なども可能だ。システムで用意してある関数を呼び出す形で、処理内容を定義する。画像処理も関数に含まれ、パラメータを指定すれば、ユーザーが操作せずに処理が進む。パラメータを指定しないときは、処理を実行するときにユーザーの操作を求める。
以上の定義だけだと、データを処理する基本部分しかないことになる。しかし、データを入力したり、決められた形式で表示する機能も必要だ。表示形式に関しては、表現フレーム機能を利用する。そのシステムに必要な数だけ表現フレームを定義する。表現フレームには、対象データの抽出条件や表現方法も指定できるため、似たような表示内容でも目的ごとに用意する。１日分の入力内容を確認するような特別用途の表現フレームも、必要に応じて作成する。
データの入力に関しては、システム側の入力制御機能（注４）を利用する。入力すべき項目を規定すれば、入力用の表示書式を生成してくれる。また、実際にユーザーが入力する段階では、正しいデータが入力できるように助けてくれたりもする。許された範囲でない値の入力を検出したり、登録された項目データの一覧を表示して選ばせたり、既存のデータベースが持つ機能を提供する。値のチェックでは、項目定義に登録してある条件を使用する。
注２：あくまで同じ目的を達成するのであって、同じ機能を実現するわけではない
注３：もし新しいデータを扱いたければ、それ用のドライバソフトを組み込むことで対応する
注４：システムが標準で持つ重要な機能だが、本連載の中では説明していない
表１、既存のアプリケーションに相当する機能の作成に関して、OSの世代ごとに比較した結果。情報中心システムでは、表現フレーム機能が重要な役割を果たす
OSの進歩 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＞
以上のような構築方法なので、扱うデータは項目定義が必要となる（注５）。そうすれば、その扱うデータは何のデータなのかということは明確になり、表計算のように汎用的なソフトにはならない。この点も、既存のアプリケーションとは根本的にちがう。すべて目的がハッキリしている点は、業務用ソフトに近い。といっても、人物データのように、特定の業務に限定されないデータも扱うので、業務用ソフトでもない。既存の区分けに当てはめようとするのがまちがいのようだ。
仕組みが異なるため、使い方もアプリケーションとはちがう。データを見る場合、何種類かの方法が使える。もっとも使用頻度の高いのが、表現フレームを指定する方法（図２）。抽出条件や表現方法を含んでいるため、ユーザーの指示が最小限で目的のデータを表示できる。
図２、表現フレームでは、ユーザーによる抽出条件や表現方法の変更が可能。用意された表現形式以外の表示内容も簡単につくれる
そのほかでは、Object First機能を呼び出す一般的な方法も使える（図３）。構造体名や抽出条件を指定して一覧を表示するとか、同じ構造体の複数データを比較するとか、組織図や関連図を描かせるとか、最低限の指定だけで見たいデータを表示できる。表示した抽出条件や表現が気に入れば、登録することも可能だ。再び見たいときに、条件を指定する必要がない。
図３、Object First機能を利用した操作では、知識ベースを参照しながら作成結果をつくったあとで、表現ルールを用いた表示内容を自動生成する
これらの機能で表示するときは、内部で抽出や加工の処理が呼ばれている。たんにデータを表示するのではなく、加工しながら表示しているわけだ。内部での加工処理は、データを入力するときにも呼ばれる。入力制御機能が設定内容を参照し、関連する機能を自動的に呼び出す。ユーザーが意識しないところで、いろいろな加工処理が働いている。その分だけ、ユーザーの操作が減り、覚えなければならない知識も少なくてすむ。
加えて、情報中心システムが持つ多重取り消し機能も、すべての入力＆編集作業で使える。現在よりも安心して入力できるだけでなく、取り消し機能をつくる必要もない。
注５：一般的なデータに関しては、システム側で用意した項目定義を利用するので、ユーザーが定義する必要はない
既存OSでは、異なるアプリケーション間でのデータ交換が難しい。ファイル形式を意識する必要があり、データを流用するのが面倒になることがしばしばだ。一部のデータしか変換できないこともあるし（注６）、同じファイル形式をサポートしていなければ、データをわたすことすらできない。全体として、ファイル形式をユーザーに意識させる仕組みである。その結果、本来の目的とは異なる知識をユーザーに求めるし、使いやすいわけでもない。複数のソフトを一緒に使うのが面倒なので、各ソフトがどんどん機能を追加し、似たような機能が増える。システム全体として見れば、同じ機能を重複して持つという無駄が生じている。
情報中心システムでは、アプリケーションという区切りが存在しない。必要とあれば、どの目的別サブシステムでもデータや処理を共有できる。たとえば人物データで、もし項目が不足するならば、追加で定義すればよい。一般的なデータに関しては、項目定義や処理定義が最初から用意してあるので、不足する分だけ追加する。
定義は共有するが、それを参照して入力するデータは分ける。目的別サブシステムごとに作業ステージを用意し、別々に入れるので混乱することもない。もし一緒に処理したい場合には、対象データの抽出条件に複数の作業ステージを指定する。それだけで、どのデータでも同一に扱える。
項目定義や処理定義を共通で使えることは、目的別サブシステムの構築でもメリットがある。一度でも定義した項目や処理は、別なサブシステムでも利用できる。すべて同じことはないにしても、不足する項目や処理だけを追加すればよいので、手間は最小限で済む。とくに有効なのは、関連する業務を段階的に追加するケースだ。共通する部分は定義しなくてよいので、作成の作業は新しく追加する分だけでよい。少しずつつくりながら、つくった分だけ使い始めるという、段階的な構築方法も可能である。
注６：たとえば、データベースに入ったデータを書き出すとき、画像も含めた汎用的なファイル形式がない
「アプリケーションの垣根をとっ払い、
データそのものを自由にやりとりする環境を実現」
情報中心システム上で構築した目的別サブシステムは、対話機能を持つ点も大きな特徴だ。すべての場面で、システムの持つ対話機能を利用できる。表現フレームや一覧表示なら、表示したあとで抽出条件（図４）や加工処理を変更し、見たい形でデータを表示する。どんな目的別サブシステムでも、読み手の自由度を確保できる。
図４、対象データの抽出条件の設定では、データの種類、作業ステージ、データ属性などを指定する
ユーザーが機能を追加できる点も重要。新しい項目の追加や処理の一部を変えることは、比較的簡単に行える。ただし、元に戻せる機能は必須。処理定義を変更するのではなく、新しい処理を追加して、それに入れ替える方法に限られる。実際には、目的別サブシステムの処理を変更する機会は少ない。ほとんどの用途では、対話機能ですませられるからだ。
対話機能による表示内容は、特定の目的別サブシステムだけを対象とするわけではない。同じ項目のデータを持つなら、異なる業務システムのデータでも、一緒に処理できる。対象データの抽出条件に、複数の作業ステージ（注７）を指定するだけだ。どの作業ステージのデータなのか把握しながら処理したいなら、所属する作業ステージで色分けしてデータを表示すればよい。アプリケーションやファイルという垣根がないからこそ、可能なことである。
以上のような自由度は、既存OSにはないものである。アプリケーションの内部を変更できないため、元から持っている機能の範囲内で使うしかない。表計算ソフトやデータベースで全部をつくれば、ユーザーによる変更も可能だ。しかし、複雑な機能をつくるのは大変で、一部の変更によるバグが発生しやすい。実際には、自由度の確保は不可能といえる。
注７：業務システムごとに別々の作業ステージを用意するので、同じ項目のデータであっても、通常は混在しない
情報中心システムでは、表計算ソフトやデータベースソフトが存在しない。すべてのデータや処理は、項目定義や処理定義を中心に進める。どんなデータなのか意識して入力し、計算結果の項目名を選ぶだけで、自動的に該当する処理が呼び出され、計算がすんでしまう。計算結果も一覧形式で表示し、必要ならば合計や平均も自動的に付加される（図５）。データベースの機能は、該当データを抽出するとか、一覧表として整形するなど、内部的に利用されている。既存のデータベースのように、ユーザーが勉強しながら使うケースはほとんどない。もちろんマクロやプロシージャをつくらなくても大丈夫だ。つまり、既存OSとは、使い方がまったく異なるのである。
図５、自動生成される一覧表示には、データ件数、平均値、最大値などが加わる。どの計算値を含めるかは、知識ベース内の項目定義を参照して決める
数少ない例外は、絵を描くグラフィック機能で、既存のシステムに近い。ただし、組織図などは自動生成するし、簡単な絵は項目定義内のシンボルを利用できるので、本当に絵を描くときしか使わない。絵の好きな人を除くと、使用する機会は極端に少ないだろう。また、既存ソフトのように、最終的なレイアウトまで絵に含めず、絵も部品の１つとして作成する。その絵やほかのデータを一緒にして、Auto Expression機能が最終的な表示内容を生成する。絵も含めて、すべてのデータは部品として入力し、関連性をリンクとして設定して、表示するときにレイアウトを決定する。このような仕組みなので、使い方がまったく異なり、現在のようにグラフィックソフトを長時間操作する必要はない。
多くのデータは、その目的に合った形で入力する。加工処理や表示も、目的に合わせて選ばれる。扱うデータのすべてが、目的別サブシステムの一部として組み込まれる。現在は住所録として入力するデータが、情報中心システムでは人物データや場所データになり、多くの目的別サブシステムで利用できる。
もっとも多く使うワープロソフトも、情報中心システムでは存在しない。説明技術をもとにした説明内容の作成支援機能により、全体の構成や中身を重視したつくり方に変わる。見栄えの向上を中心にサポートする現在のワープロソフトとは、根本的に異なる。作成する内容を全体的に把握しながら、つくり進むことができる。
把握といえば、作業やデータの把握も重要だ。情報中心システムでは、いろいろな把握機能を用意して（図６）、ユーザーの混乱を最小限にとどめる。
図６、作業ステージ内の全データを把握する機能では、データの種類ごとに件数や内容を表示できる。このほかに、処理の把握機能もある
そのほか、プロジェクト管理、CAD、3D、シミュレーションなどの機能も、項目定義と処理定義に合わせた形で実現する。CADや3Dは個々の部品が項目になり、専用のドライバソフトを用意する。複数の部品を合成する機能も、2Dや3Dごとに標準化して、すべての部品が一緒に使える環境に仕上げる。このような形にすると、動画でもCADでも一緒に使えるシステムに仕上がる。
情報中心システムの時代には、今よりもデータの中身を重視した使い方に変わる。コンピュータを操作するのではなく、情報を直接扱っている感覚で使えるシステムだからだ。
この連載も長いもので、今回で35回に達してしまった。にもかかわらず、まだ紹介していない機能が数多くある。既存システムとはまったく異なる仕組みなので、何から何まで説明する必要があり、いくらスペースがあっても足りないようだ。
この雑誌の性格上、システム内部の難しい話は避けなければならない。そのため、情報中心システムの内部構造に関しては、深く突っ込まずに話を進めた（注８）。結果として、どんなシステム環境になるのかと、既存システムの使いにくさを中心に述べることとなった。少なくとも、既存のコンピュータの欠点だけは、かなり理解してもらえたと思う。多くの技術者が当たり前だと思っていることの中にも、冷静に分析すると良くない部分がかなりある。そのほとんどが、システムの構造を根本から改良すれば解決できる。その解答こそ、情報中心システムだ。
最後になったが、連載させていただいた、MacUser編集部の皆さん（とくに松尾編集長）に感謝したい。また、応援していただいた読者の皆さんにも、同様に感謝している。
情報中心システムの研究は、まだまだ続く。その最終段階となる「思考支援コンピュータ」は十分に可能で、その基礎技術は確立しつつある。そこまで達するのは、かなり先のことだろう。その前として、情報中心システムの初期段階（本連載で説明した内容）が位置づけられ、こちらは作成できるレベルに達している。それが実現するまでの間は、非常に使いづらい現在のコンピュータを使い続けるしかない（注９）。
注８：実際には、内部構造に触れた部分もある。その中には、情報中心システムをつくる際に必要なヒントが、いくつも埋め込んである。それを理解できる人は、非常に少ないだろうが
注９：非常に残念なことだが、最近発表される技術を見る限り、劇的に使いやすくなる可能性はほとんどない
「情報中心システムの最初の段階は既に作成可能
そのデータ重視の世界には新たな可能性が……」
表現フレームを利用し、既存のアプリに相当する機能を実現 |
