JP2008004127A - タスク実行のためのプロセス構造を定義するシステムおよび方法 - Google Patents

Abstract

【課題】タスクを実行するためのプロセス構造の定義等をするためのシステム等を提供す
る。
【解決手段】ユーザは、動詞ワードとオブジェクト・ワードを含んでいて、その構造を作
成しようとしているタスクを定義している第１プロセス定義を入力する。そのあと、ユー
ザは第１プロセス定義を実行すると予想される結果となる、あるいは第１プロセス定義を
実行するときの予想される構成ステップとなる後続のプロセス定義を定義することができ
る。各ステージでの各プロセス定義を分析することにより、タスクを実行するための完全
なプロセス構造を構築し、改良していくことができる。また、ユーザはある特定のプロセ
ス定義のオブジェクト・ワードの意味の範囲に入る特定のオブジェクト・ワードを指定し
、これらをスクリーン上に表形式で呼び出して、プロセス構造内のプロセス定義のディス
プレイにオーバライトすることもできる。
【選択図】図４

Description

本発明は、タスク（仕事）を実行する上で必要なステップ（段階）を判別しおよび／ま
たは改良できるような形で、さらに、タスクでのプロセス・ステップの実行をモニタでき
るような形で、プロセス構造を作成またはモデル化するためのシステムおよび方法に関す
る。

ユーザがシステム構造を分析して、システム・ステップのシーケンスのどこでホールド
アップ（停止、休止、停滞など）が起こるおそれがあるかを明らかにできるようにする方
法は公知である。そのような方法の例として、ＧＡＮＴチャートまたはＰＥＲＴソフトウ
ェアがあり、この方法による分析はクリティカル・パス分析法(critical path analysis)
に基づいている。これらの方法は、ユーザがどのような方法で、タスクでのステップの判
別を識別すべきかのガイダンスを提供していない。

タスクを実行するときによく起こることは、不必要なステップを実行したり、相対的に
重要でないステップや単純なステップに集中したりすることに大量の時間が浪費され、他
方では、もっと注意すべきステップを避けたり、そのようなステップに殆ど時間をかけな
いことである。タスクの実行において、より関心のあるステップや特定の作業員の得意な
分野を反映するようなステップに大量の時間や注意力を消費するのは、人間の常である。
これらの得意な分野が最大の詳細を必要とするステップと一致していれば、結果は満足す
べきものとなる可能性がある。しかし、あるタスクがその性質上いくつかの分野にまたが
るときや、多少でも作業員の経験外にあるときは、作業員は相対的に得意な分野に集中す
る傾向があるか、あるいはどの分野に最大の努力を向けるべきかを明確化できないことに
なる。

この問題は、いくつかの分野にまたがるチームを利用すると解決できるかもしれないが
、それでもなお、チームのメンバに任せられる重要な分野を判別できる能力が必要になる
。大規模で複雑なタスクを実行する場合には、これが、タスク・ステップとその実行を識
別する重要な側面となる場合がある。しかし、小規模である場合や、タスクのステップを
定義する初期ステージにおいて、対象のタスクがそのような入力を判断できないステージ
では、作業員の時間が大量に浪費されることになる。

タスクを定義する人は、特定のタスクを実行する上で必要なステップ自体の認識と定義
を論理的に進めて行くのを支援するツールを使用すると、便利なことがある。

さらに、タスクのセットアップが完了したとき、タスクの進行状況を各タスク・ステッ
プのステータス（状況）に従ってモニタすると役に立ち、そうすることが不可欠であるこ
とがよくある。従って、タスクとタスクを構成するステップの進行状況を追跡するのを支
援するツールがあると、ユーザにとっては好都合である。

本発明の第１の側面によれば、タスクを実行するためのプロセス構造を構築するシステ
ムが提供され、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセスされるデータをストアするデータ・ス
トレージ手段と、
コンピューティング・デバイスに接続されて、データを入力する手段と、
同じくコンピューティング・デバイスに接続されて、データを表示するディスプレイ手
段とを備えており、コンピューティング・デバイスは、１つまたは複数の動詞ワード(ver
b word) と１つまたは複数のオブジェクト・ワード(object word) を含んでいて、タスク
またはタスクのステップを定義している第１プロセス定義(process definition)を、デー
タ入力手段を通してユーザから受け取るように構成されていると共に、第１プロセス定義
を受け取ったときの応答として、第１プロセス定義を実行すると予想される結果となるよ
うな第２プロセス定義をデータ入力手段から入力することをユーザに要求するように構成
されていることを特徴としている。

本発明の第２の側面によれば、タスクを実行するためのプロセス構造を構築するシステ
ムが提供され、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセスされるデータをストアするデータ・ス
トレージ手段と、
コンピューティング・デバイスに接続されて、データを入力する手段と、
同じくコンピューティング・デバイスに接続されて、データを表示するディスプレイ手
段とを備えており、コンピューティング・デバイスは、１つまたは複数の動詞ワードと１
つまたは複数のオブジェクト・ワードを含んでいて、タスクまたはタスクのステップを定
義している第１プロセス定義をデータ入力手段を通してユーザから受け取るように構成さ
れていると共に、第１プロセス定義を受け 取ったときの応答として、第１プロセス定義
を実行するとき予想される構成ステップとなるような第２プロセス定義をデータ入力手段
から入力することをユーザに要求するように構成されていることを特徴としている。

本発明の第３の側面によれば、タスクを実行するためのプロセス構造を構築するシステ
ムが提供され、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセスされるデータをストアするデータ・ス
トレージ手段と、
コンピューティング・デバイスに接続されて、データを入力する手段と、
同じくコンピューティング・デバイスに接続されて、データを表示するディスプレイ手
段とを備えており、コンピューティング・デバイスは、１つまたは複数の動詞ワードと１
つまたは複数のオブジェクト・ワードを含んでいて、タスクまたはタスクのステップを定
義している第１プロセス定義をデータ入力手段を通してユーザから受け取るように構成さ
れていると共に、第１プロセス定義を受け 取ったときの応答として、第１プロセス定義
のオブジェクト・ワードの意味の範囲に入る特定のオブジェクト・ワードを指定すること
をユーザに要求するように構成されていることを特徴としている。

また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構築する方
法にも範囲が及び、該方法は、
１つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを含んでい
て、タスクまたはタスクのステップを定義している第１プロセス定義を入力し、
第１プロセス定義を実行すると予想される結果となるような第２プロセス定義を入力す
ることをユーザに要求することを含んでいることを特徴としている。

また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構築する方
法も包含しており、該方法は、
１つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを含んでい
て、タスクまたはタスクのステップを定義している第１プロセス定義を入力し、
第１プロセス定義を実行する際に予想される構成ステップとなるような第２プロセス定
義を入力することをユーザに要求することを含んでいることを特徴としている。

また、本発明は、タスクをコンピュータ上で実行するためのプロセス構造を構築する方
法にも範囲が及び、該方法は、
１つまたは複数の動詞ワードまたは１つまたは複数のオブジェクト・ワードを含んでい
て、タスクまたはタスクのステップを定義している第１プロセス定義を入力し、
第１プロセス定義のオブジェクト・ワードのインスタンスとなる特定のオブジェクト・
ワードを入力することをユーザに要求することを含んでいることを特徴としている。

また、本発明によれば、タスクを実行するためのプロセス構造を構築するシステムが提
供され、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセスされるデータをストアするデータ・ス
トレージ手段と、
コンピューティング・デバイスに接続されて、データを入力する手段と、
同じくコンピューティング・デバイスに接続されて、データを表示するディスプレイ手
段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと少
なくとも１つのオブジェクト・ワードを含んでいるデータ・プロセス定義をデータ入力手
段を通してユーザから受け取るように構成され、各プロセス定義は複数のステージから構
成されたタスクのステップを定義していくことにより最終的にタスクのプロセス定義が得
られるようになっており、さらに、コンピューティング手段は、タスクのステージの少な
くとも１つのステージの１つのプロセス定義に関連するデータをストアするように動作可
能であることを特徴としている。

本発明によれば、タスク・ステップがプロセス構造の構成部分としてどのように行うべ
きかを検討することにより、プロセス構造を明確化し、あるいは開発することが可能であ
る。また、本発明によれば、ユーザは、タスク・ステップがプロセス構造定義ルーチンの
構成部分として行うときの方法を検討することにより、プロセスを改善することも可能で
ある。データベースとプロセス構造は、ユーザがコンピューティング手段からのプロンプ
トを選択して応答すると、自動的に開発され、動的に調整可能になっている。

好ましくは、前記１つのプロセス定義の前のステージでの構成プロセス定義のオブジェ
クト・ワード（１つまたは複数）は、検索可能データ・ディスプレイにコンピューティン
グ手段によって配置されている。

従って、本発明によれば、情報ウィンドウを、モデル化したタスクの中のプロセスのい
ずれか、あるいはすべてと関連づけることが可能である。これらは標準情報ウィンドウの
形体にして、プロセス完了／未完了、完了日といったチェックリスト・エントリ（項目）
を指定することが可能である。しかし、プロセスをカストマイズした情報ウィンドウの中
で使用して、モデル化したタスクの先行ステップを表すようにすると、タスクに関する種
々のデータをそのステップで表示して評価および分析を行うことも可能である。

好ましくは、本発明は、オプションとして、モデル化したタスクの中の各プロセスごと
に情報ウィンドウを構築するように構成されている。例えば、ある与えられたプロセスに
ついて、本発明は、その与えられたプロセスのステージの直前に置かれたモデル・ステー
ジでのプロセスの各々ごとに、関連情報ウィンドウに列見出し（column header −カラム
・ヘッダ）を生成するように構成することが可能である。

好ましくは、データ・ディスプレイは表形式になっている。例えば、先行ステージの関
連構成プロセス定義のオブジェクト・ワード（１つまたは複数）は列見出し(column head
ing)として配列され、前記１つのプロセス定義の特定のオブジェクトは行見出し(row hea
ding) として配列されている。

大部分のデータは前記構成プロセス定義と関連づけられるが、他方では、コンピューテ
ィング手段は、データ・ディスプレイの配置においてさらに別のオブジェクト・ワードを
受け付けるように構成されていることも望ましい。コンピューティング手段は、オブジェ
クト・ワード（１つまたは複数）がユーザに よってデータ・ディスプレイに追加された
とき、構成プロセス定義を作成するように構成することが可能である。好ましくは、コン
ピューティング手段は、オブジェクト・ワード（１つまたは複数）がユーザの裁量でデー
タ・ディスプレイに追加されたとき、構成プロセス定義の作成を禁止するように構成され
ている。

特定の形体では、本発明はタスクを実行するためのプロセス構造をモデル化するシステ
ムからなり、該システムは、
コンピューティング手段と、
コンピューティング手段によってアクセスされるデータ・ストレージ手段と、
コンピューティング手段に接続されて、プロンプトと、入力手段からおよびコンピュー
ティング手段から入力されたデータを表示するように動作可能であるディスプレイ手段と
を備えており、コンピューティング手段は、第１プロセス定義を求めるプロンプトを選択
的に表示して、ユーザによってデータ入力手段から入力された１つまたは複数の動詞ワー
ドと１つまたは複数のオブジェクト・ワードを要求するように構成されていると共に、コ
ンピューティング手段からの別のプロンプトを選択することをユーザに要求して、第１プ
ロセス定義を実行するとその結果となるような、あるいは第１プロセス定義を実行すると
きの構成ステップとなってタスク・モデルの一連のステージを作成し、最終的にタスクを
実行するモデルが得られるような第２プロセス定義を入力することをユーザに要求し、あ
るいは、第１プロセス定義のオブジェクト・ワードのインスタンスとなる特定のオブジェ
クト・ワード（１つまたは複数）を指定することをユーザに要求するように構成されてお
り、コンピューティング手段は、さらに、１つのステージでの１つのプロセスに関連づけ
られていて、前記１つのプロセス定義の直前に置かれたステージでのプロセス定義の構成
オブジェクト・ワード（１つまたは複数）が列見出しとして配列され、該１つのプロセス
の特定オブジェクトが行見出しとして配列されている検索可能データ・ディスプレイを生
成するように動作可能であることを特徴としている。

本発明によれば、作業の計画と管理を単純な方法で行うことができる。基本的プロンプ
トを通して、ユーザは、経験が不足している分野では小さなステップをとってタスク構造
を定義することができ、また、経験が十分にあり、複数の中間の、より基本的なステップ
を注意して調べる必要のないような分野では、より大きなステップをプロセス定義間で定
義または明確化することができる。従って、タスクを実行する各プロセス構造は、論理的
に、しかもユーザの経験レベルまたは分野を反映するように定義することができる。従っ
て、開発されたプロセス構造またはモデルは、システムのプロンプトのガイドに従って重
要な考慮をしてきたユーザにユニークに適合したものになる。ユーザの経験が乏しい分野
ではタスクのステップをモニタする必要性は、より詳細化されたステージを使用すること
により自動的に満たされる。

好ましくは、コンピューティング手段は、プロセスの第２またはそれ以降のステージを
ディスプレイ手段上に順番に追加することを要求するように構成されている。例えば、第
１プロセス定義を実行するとその結果となる第２プロセス定義の要求（ＷＨＹ？プロンプ
ト）は、ディスプレイ手段の一方向に配列され、第１プロセス定義を実行するときの予備
的ステップとなる第２プロセス定義の要求（ＨＯＷ？プロンプト）は、ディスプレイ手段
の反対方向に配列される。これらのプロセス定義の要求は相互に対立するものと扱われる
。従って、２つの要求を受けてプロセス定義を反対方向に順序を付けると、トランスペア
レントなタスク・モデル(transparent task model)が作成されるので、ユーザの経験度を
反映するように各ステージごとにより詳細化するように、あるいは詳細度が粗くなるよう
に構築していくことができる。

正しい順序にするためには、タスク・モデルまたはプロセス構造の開発は、基本的タス
ク・プロセスから始めて種々のプロセス・ステージを経て、基本的初期化プロセスに到達
するように進めていくことが望ましい。この進め方はディスプレイ手段の右から左へ行う
のが望ましいが、左から右へ行っても、ディスプレイ手段の上下のどちらの方向に行って
も、その効果は同じである。

好ましくは、コンピューティング手段は、同じタスク・ステージ・レベルのプロセス定
義を、ディスプレイ手段上で並列に配列するように構成されている。このようにすると、
同じレベルの各ステップは、プロセス定義の別々のシーケンスをサポートすることになる
。

第１プロセス定義のオブジェクト・ワードの意味の範囲に入る特定のオブジェクト・ワ
ードをユーザが指定するように求める、コンピューティング手段の要求は、オーバーレイ
したイメージまたはウィンドウとしてディスプレイ手段上に現れて、そこにオブジェクト
・タイプに従った特定オブジェクトのより詳細化した例がリストされるように配置するこ
とが可能である。

上述した特定形体の本発明を利用すると、ユーザはタスク・モデルをどちらの方向にも
構築していくことができる。例えば、タスクの初期特定をガイドとすると、ユーザはＨＯ
Ｗ？プロンプトに対する応答に基づいてモデルを構築していき、モデル内の特定オブジェ
クトを必要な個所に定義していくことができる。また、オプションとして、ユーザは、Ｗ
ＨＹ？プロンプトに応答しながら逆方向に作業を進めていくと、タスクまたはタスクのス
テップの値を確かめることもできる。

本発明には、カルキュレータ動詞(calculator verb) を含めることも可能であり、その
場合、コンピューティング手段は、カルキュレータ動詞に応答して、タスク・ステージに
配列されているオブジェクトの値（これはデータ・ストレージ手段にストアされている）
について算術演算プロセスを実行するように構成されている。これは、金額またはオブジ
ェクト数といった、オブジェクトの数値に関係するオブジェクトに対するものである。

好ましくは、コンピューティング手段は、プロセスに関するデータ入力手段からのコマ
ンドに応答して、テキスト・サブファイルおよび／またはドキュメント・ヘッダを作成す
るように構成されており、テキスト・サブファイルはデータ入力手段から送られたユーザ
のコマンドに応答して、ディスプレイ手段から表示可能になっている。ヘッダで示された
ドキュメントは、コンピューティング手段と関連づけられたテキスト処理言語で書いて、
タスク・モデルからアクセスすることが可能である。このようにすると、ユーザはコンピ
ューティング手段の基礎となるデータ構造を使用して、特定のオブジェクトに関係する他
のファイルをアクセスすることができる。

コンピューティング手段は、データ入力手段からユーザによって与えられ、タスク・モ
デルの各プロセスに関連づけられた重み付け(weighting) から、困難度の等級を生成する
ように構成することも可能である。例えば、重み付けはユーザによる割当てが可能な数値
にすることができる。

本発明によれば、あるプロセス・オブジェクトを選択することができる。この方法によ
ると、選択されたオブジェクトはプロセスのインスタンスとなるので、オリジナル・プロ
セス動詞と選択されたオブジェクトとを含む別の現プロセスが定義されることになる。Ｈ
ｏｗタスクまたはＷｈｙタスクは、あるオブジェクトと関連をもつプロセスと関連づける
ことができる。この方法によると、ＨｏｗタスクまたはＷｈｙタスクは、別の現プロセス
およびそのオブジェクト・プロセスだけのオブジェクトを更に細分化したものと特定の関
係をもつことになる。

ＨｏｗタスクまたはＷｈｙタスクは、あるオブジェクトと関係をもつ現プロセスによっ
て継承することができる。この方法によると、プロセス・オブジェクト関係の上位レベル
・オブジェクトのＨｏｗタスクまたはＷｈｙタスクは、現プロセスと別々に関連づけられ
ているＨｏｗタスクとＷｈｙタスクのほかに、現プロセスにも適用されることになる。

Ｈｏｗプロセスは合成(compound)することが可能である。この方法によると、Ｈｏｗプ
ロセスは、それ自体も合成できる先行Ｗｈｙプロセスの選択されたオブジェクトと関連づ
けられることになる。

プロセスはチェインブレーキング(chainbreaking) を含むことが可能である。この方法
によると、Ｈｏｗプロセス・オブジェクトは、合成の有無に関係なく、そのプロセスのオ
ブジェクトとだけ関連づけられることになる。Whatと情報ウィンドウ内のオブジェクトは
継承できるので、表示されるオブジェクトは、Ｗｈｙプロセス・オブジェクトと関係づけ
れたものと一緒に、Ｗｈｙプロセス・オブジェクトの上位レベル・オブジェクトと関係づ
けられたものになる。

なお、本発明は、以下の項目１〜２６に示す形態をとることもできる。

１．タスクを実行するためのプロセス構造を作成するシステムであって、該システムは
、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能であるデータをストアしているデ
ータ・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ
手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと
少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段
を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのス
テップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義を
受け取ったときの応答として、第１プロセス定義を実行すると予想される結果となる第２
プロセス定義をデータ入力手段から入力することをユーザに要求するように構成されてい
ることを特徴とするシステム。

２．コンピューティング・デバイスは、プロセス定義のディスプレイをディスプレイ手
段上に生成するように動作可能であり、タスクのステップの１つにおけるプロセス定義は
行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行し
ていくことを特徴とする項目１に記載のシステム。

３．タスクのステップの進行はディスプレイ手段上を水平方向にわたっていることを特
徴とする項目２に記載のシステム。

４．ステップは左から右へ進行していくことを特徴とする項目３に記載のシステム。

５．データ入力手段はキーボードを含むことを特徴とする項目１に記載のシステム。

６．タスクを実行するためのプロセス構造を作成するシステムであって、該システムは
、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能なデータをストアしているデータ
・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ
手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと
少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段
を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのス
テップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義を
実行するとき予想される構成ステップとなる第２プロセス定義を入力することをユーザに
要求するように構成されていることを特徴とするシステム。

７．コンピューティング・デバイスは、プロセス定義のディスプレイをディスプレイ手
段上に生成するように動作可能であり、タスクのステップの１つにおけるプロセス定義は
行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行し
ていくことを特徴とする項目６に記載のシステム。

８．タスクのステップの進行はディスプレイ手段上を水平方向にわたっていることを特
徴とする項目７に記載のシステム。

９．ステップは左から右へ進行していくことを特徴とする項目８に記載のシステム。

１０．コンピューティング・デバイスは、あらかじめ決められたプロセス定義をデータ
・ストレージ手段から取り出すように構成され、該プロセス定義は、ユーザによってキー
ボードから入力された第２プロセス定義を実行するときの構成ステップであることを特徴
とする項目６に記載のシステム。

１１．タスクを実行するためのプロセス構造を作成するシステムであって、該システム
は、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能なデータをストアしているデータ
・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ
手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと
少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段
を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのス
テップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義の
オブジェクト・ワードの意味の範囲に入る特定のオブジェクトを指定することをユーザに
要求するように構成されていることを特徴とするシステム。

１２．コンピューティング・デバイスはデータ入力手段から入力されたコマンドを受け
ると、その応答として、第１プロセス定義の少なくとも１つのオブジェクト・ワードの意
味の範囲に入るオブジェクト・ワードに関連する検索可能データ・ディスプレイを作成す
ることを特徴とする項目１１に記載のシステム。

１３．データ・ディスプレイは表形式であり、コンピューティング・デバイスは、デー
タ入力手段からコマンドを受けたとき、その応答として、ディスプレイ手段上のプロセス
定義にデータ・ディスプレイをオーバライトするように構成されていることを特徴とする
項目１２に記載のシステム。

１４．タスクを実行するためのプロセス構造をモデル化するシステムであって、該シス
テムは、
コンピューティング手段と、
コンピューティング手段によってアクセス可能であるデータ・ストレージ手段と、
コンピューティング手段に接続されていてデータを入力する手段と、
同じくコンピューティング手段に接続されていて、プロンプトと、入力手段からおよび
コンピューティング手段から入力されたデータを表示するディスプレイ手段とを備えてお
り、コンピューティング手段は、ユーザによってデータ入力手段から入力された第１プロ
セス定義を求めるプロンプトをディスプレイ手段から選択的に表示して、少なくとも１つ
の動詞ワードと少なくとも１つのオブジェクト・ワードを要求するように構成されている
と共に、第１プロセス定義を実行すると予想される結果となる、あるいは第１プロセス定
義を実行してタスク・プロセス構造内の一連のステージを作成するときに予想される構成
ステップとなる第２プロセス定義を入力することをユーザに要求する、コンピューティン
グ手段からの別の入力プロンプトを選択することをユーザに要求するようにあるいは第１
プロセス定義のオブジェクトの意味の範囲に入る特定のオブジェクト・ワード（１つまた
は複数）を指定することをユーザに要求するように構成されており、コンピューティング
手段は、さらに、１つのステージでの１つのプロセスに関連する検索可能な表形式データ
・ディスプレイを作成するように動作可能であり、そこでは、前記１つのプロセス定義の
前のステージにおける構成プロセス定義のオブジェクト・ワード（１つまたは複数）は、
列見出しとして配列され、該１つのプロセス定義の特定のオブジェクトは、行見出しとし
て配列されていることを特徴とするシステム。

１５．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって
、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第
１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスク
のステップを定義しているものと、
第１プロセス定義を実行すると予想される結果となる第２プロセス定義を入力すること
をユーザに要求するステップとを含むことを特徴とする方法。

１６．プロセス定義のディスプレイをディスプレイ手段上に生成するステップを含み、
タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセ
ス定義の行はディスプレイ手段を横切って進行していくことを特徴とする項目１５に記載
の方法。

１７．タスクのステップはスクリーン上を水平方向に進行していくことを特徴とする項
目１６に記載の方法。

１８．ステップは左から右へ進行していくことを特徴とする項目１７に記載の方法。

１９．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって
、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第
１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスク
のステップを定義しているものと、
第１プロセス定義を実行するとき予想される構成ステップとなる第２プロセス定義を入
力することをユーザに要求するステップとを含むことを特徴とする方法。

２０．プロセス定義のディスプレイをディスプレイ手段上に生成するステップを含み、
タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセ
ス定義の行はディスプレイ手段を横切って進行していくことを特徴とする項目１９に記載
の方法。

２１．タスクのステップはスクリーン上を水平方向に進行していくことを特徴とする項
目２０に記載の方法。

２２．ステップは左から右へ進行していくことを特徴とする項目２１に記載の方法。

２３．ユーザによってキーボードから入力された第１プロセス定義を実行するときの構
成ステップとなる、あらかじめ決められたプロセス定義を取り出すステップを含むことを
特徴とする項目１９に記載の方法。

２４．タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって
、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第
１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスク
のステップを定義しているものと、
特定のオブジェクト・ワードを指定することをユーザに要求するステップであって、該
オブジェクト・ワードは第１プロセス定義のオブジェクト・ワードのインスタンスである
ことを特徴とする方法。

２５．データ入力手段から入力されたコマンドを受けると、その応答として、第１プロ
セス定義のオブジェクト・ワードのインスタンスであるオブジェクト・ワードに関連する
検索可能データ・ディスプレイを作成するステップを含むことを特徴とする項目２４に記
載の方法。

２６．コンピューティング手段はデータ入力手段から入力されたコマンドを受けると、
その応答として、ディスプレイ手段上のプロセス定義に表形式のデータ・ディスプレイを
オーバライトすることを特徴とする項目２４に記載の方法。

本発明によれば、タスクを実行するためのプロセス構造の定義等をするためのシステム
等を提供することができる。

本発明は種々の態様で実施することが可能であるが、以下では、その一部を例示して添
付図面を参照して説明することにする。

システムの主要エレメントは図１にブロック形式で示されている。これらのエレメント
はユーザ１０によって使用され、データがユーザによってそこからコンピュータ１４に入
力されるキーボード１２を含んでいる。データはコンピュータによってモニタ・ディスプ
レイ・スクリーン１６上に表示される。当業者ならば理解されるように、コンピュータに
は、データをストアするメモリ１８が関連づけられている。

以下には、「カーソル」と言及している個所があるが、カーソルとは、当業者ならば理
解されるように、あるアクションまたは機能がそこでまたはそこにアドレスされている、
スクリーン上の「現在の」(current) エリアを示すマークのことである。カーソルは「マ
ウス」によってスクリーン上のどこにでも移動することが可能である。アクションまたは
実行スイッチはマウスに一体になっている。カーソルは、従来のＱＷＥＲＴＹワードプロ
セシング・キーボード上の上向き／下向き／左向き／右向きキーなどの、従来のキースト
ロークで移動することも 可能である。従来、キーボード上でのコマンドまたは機能の実
行は、例えば、“ＲＥＴＵＲＮ”または“ＳＰＡＣＥ”キーをたたたくか、マウスを「ク
リック」することにより行われている。理解を容易にするために、カーソルの移動とコマ
ンドまたは機能の実行は、従来のように、マウスまたはキーボードとマウス・スイッチの
作動（クリック）またはキーストロークによってカーソルを移動したときの結果であるも
のとする。スクリーンのあるエリアまで移動し、そこで特定の機能を指示し、それを実行
するプロセスは上記と同じであるものとし、以下の説明では、これを「セレクション(sel
ection：選択）」と呼ぶことにする。

同様に、マウスは、スクリーン上に表示されているアイコンまたは文字を「捕らえる」
(capture) ためにも使用できる。捕らえたアイテム（項目）はスクリーン上で「ドラッグ
」して、ユーザがそれを必要とする個所に置くことができる。これらは公知の操作である
。

ユーザ１０は、特定のタスクを効率よく実行するにはどのように進めていくかを明確化
する仕事を担当している。本発明の１つの見方として、有形、無形を問わず、定義できる
オブジェクトの概念がある。例として、作成する報告書、行われるセールス、サービスを
提供されるカストマ（顧客）がある。どのオブジェクトも、ＷＨＡＴ？アイコンを選択す
ることにより、ユーザが要求する通りにカテゴリに分割し、さらにサブカテゴリに分割す
ることができる。オブジェクトは従業員であることもあり、従業員のカテゴリはセールス
マンであることもあり、セールスマンのサブカテゴリは名前別の個人セールスマンにする
こともできる。

オブジェクトに関連づけられるものとして、動詞(verb)／目的語（オブジェクト）のペ
ア（「プロセス」）を作成する動詞があり、これは実行すべきタスク全体またはそれを達
成するまでの途上にあるステップを包含している。ユーザがシステムでモデルとして管理
したいタスクを、上で定義したように、動詞／オブジェクト・プロセスの形で設定したあ
と、ユーザはアイコンＨＯＷ？とＷＨＹ？のどちらかを選択することができる。

ＨＯＷ？について説明すると、理解されるように、ユーザは、なにを次のステップにす
るか、現在のステップに特有のものにするか、あるいは以前に定義したステップ・レベル
またはステージのステップの１つにするかを、作業を進めていく過程で考える必要がある
。最終的に、タスク・モデルが開発され、そこには、異なるタスク・ステージでの中間プ
ロセスの階層(hierarchy) が含まれている。各プロセスは、タスク・モデルのステージに
おけるステップである。

ＷＨＹ？はＨＯＷ？の逆方向と見ることができる。実際には、ＨＯＷ？をアドレスする
と、タスクの開始または初期化ステップに導かれるのに対し、ＷＨＹ？を使用すると、基
本的タスク・プロセスに向かって作業することにより、タスクのプロセス・ステップを改
良することができる。ささいなプロセスや重要でないプロセス、あるいは無関係なプロセ
スに不釣り合いに努力を向けると、タスクを実行するとき大量の時間が浪費されることが
よくある。従って、ＷＨＹ？という質問にアドレスすることによりタスク・プロセスに向
かって作業を行える能力は、タスク・モデルを構築するときの改良ツールとなることを目
的としている。

以下、具体例について説明する。システムは、INTEL（登録商標）486DX/3-MHz マイク
ロプロセッサをベースとし、４Ｍバイト・メモリとＶＧＡモニタ・ディスプレイによって
サポートされたパーソナル・コンピュータ上で稼働する。コンピュータには、Microsoft
（登録商標）Windows（登録商標）3.1 とDOS 5 （または以降のバージョン）オペレーテ
ィング・ソフトウェアが、本発明によるシステムを実行するプログラムと共に、ロードさ
れている。このケースでは、本発明によるシステムのプログラムは、Windows（登録商標
）およびDOS オペレーティング・ソフトウェアと互換性があることが必要である。このよ
うなプログラムの作成は、その大部分が、熟練したソフトウェア・プログラマにとっては
ルーティンの開発の問題である。また、当業者ならば理解されるように、本発明のエレメ
ントは、適当なソフトウェア言語ならば、どの言語で書くことも可能である。本発明の場
合は、Ｃ++プログラミング言語が使用されている。付録ＡとＢは、本発明の基礎となる概
念に関連するソース・コードの一部をリストしたものである。これについては、以下で詳
しく説明する。

システム・プログラムがMicrosoft（登録商標）Windows（登録商標）プログラム・マネ
ージャを通してインストールされると、図２に示すプロセス・シートをＶＧＡモニタのス
クリーン上に呼び出すことが可能になる。スクリーン・ディスプレイはタイトルバー２０
、メニューバー２２およびボタンバー２４を含んでいる。モデルを作るには、オプション
'File'（ファイル）をメニューバー２２から選択する。これにより、ユーザは既存のファ
イルを名前で指定することも、新しいモデルを作ることもできる。新しいモデルを作るこ
とを例にして、本発明を説明する。これの結果はフィールド・スクリーンとなるが、これ
はプロセス・エントリ・ボックス２６を除き、大部分がブランクになっている。まず最初
に、モデル化しようとするタスク・プロセス全体になると考えられるものはなんであるか
を定義するには、物理的エンティティまたは抽象的概念となり得るオブジェクトを、さら
に、オブジェクトに対して行いたいものはなんであるかを定義した動詞を、エントリ・ボ
ックス２６に入力する必要がある。キーボード上のＴＡＢキーを押すと、ボックス２６の
動詞とオブジェクトの領域の間で移動することが可能である。

図３は、オブジェクト'business'（ビジネス）に適用される動詞'set up'（設定）を含
んでいる仮想上のタスク・プロセスのスクリーン・ディスプレイを示す図である。タスク
の必要なすべての構成プロセスを含めるようにモデルを取り扱うには、カーソルを既存プ
ロセスの左側へ移動し、マウスをクリックするか、キーボード上の'return'キーをたたく
だけでよい。'set up business' （ビジネスを設定）プロセスのすぐ左側に別のエントリ
・ボックス２６′がスクリーンに現れる。

これはＨＯＷ？モードである。システムは、スタートアップ時にＨＯＷ？モードがデフ
ォルトになるように構成されている。ボタンバー２４からＷＨＹ？またはＷＨＡＴ？モー
ドを選択すると、ＨＯＷ？モードから出る。同様に、ボタンバー２４からＨＯＷ？を選択
すると、ＨＯＷ？モードに入る。

これを受けて、ユーザは基本タスクを実行するときの構成ステップになると思われる動
詞／オブジェクト・プロセスを自由に定義することができる。このケースでは、予備的プ
ロセスは 'build a business plan'（ビジネス・プランを構築）になっている。モデルは
ＨＯＷモードに応答して、スクリーン上を右から左へ向かって開発されていく。第２ステ
ージからの引き継ぎとして、図４は、タスク・モデルを開発する際に必要なステップであ
るとユーザが示した一連のプロセスを示している。ＨＯＷ？モードでは、開発中のタスク
・モデルの隣接ステージの関連ステップは、右から左へ向かうように（つまり、オリジナ
ル・タスク・プロセスから離れて、初期化するプロセスへ向かうように）指している矢印
と'HOW' という記号でリンクされている。

図に示すように、タスク・モデルの各ステージは並列プロセスの縦方向のカラム（列）
からなっている。あるステージのすべてのプロセスは、これらがすぐ右側のステージでリ
ンク（'AND' （かつ）で結ばれている）されていると示されているプロセスを達成する上
で必要なものと扱われる。ビジネス・プランのセットアップに経験のあるユーザの場合は
、ビジネス・プランの各詳細側面の定義は、定義されるプロセス数が少なくなるまで狭め
ていくことができるので、ユーザはビジネス・プランの構築を経験度に応じて管理するこ
とができる。経験のある人は、担当するプロセスに自信があれば、取り扱うステップ数を
少なくし、あるいはタスク・ステップにおけるプロセスを詳しく記述しないで済むはずで
ある。もっと多くのガイダンスを必要とするユーザは、投入するステージ数を増やし、プ
ロセスを詳細化すると、関係するプロセスの判別が容易化し、実際になにが必要であり、
なにを改良する必要があるかを判断しやすくなる。この例は、図４に示す追加のプロセス
でさらに展開される。

上述したように、ＨＯＷ？の反対はＷＨＹ？である。本発明のシステムによれば、ユー
ザは特定のプロセスから戻るように作業すると、タスク・モデルにおいてそのプロセスが
適切かどうかを明確に確かめることができる。タスク・モデルのあるプロセスがなぜそこ
に置かれているかの、正確な理由にユーザが集中できるようにすると、モデルを効率化し
、タスク向きにすることが容易化される。

図４に示すように、'develop financial plan'（財務計画を開発）というプロセスがあ
る。ここで、ユーザはボタンバー２４からＷＨＹモードを選択することができる。この例
でのユーザは逆方向に作業を行い、ＷＨＹ？という質問を尋ねると、このプロセスの適切
性をモデルに合わせて定義することができる。これを示したのが図６であり、そこでは、
'build a business plan'(ビジネス・プランを構築）と'secure finances'(資金を確保）
の基本タスク・プロセスが示されている。この場合も、ブランク・エントリ・ボックスが
現れて、モデルに組み入れようとしているプロセスの理由を考慮するようにユーザに要求
する。

同じタスク・ステージでエントリ・ボックスを追加するには、カーソルを下方に動かし
、マウスをクリックするか、キーボード上の“ＴＡＢ”キーをたたくと、新しいブランク
・エントリ・ボックスが呼び出される。これらのプロセス は、プロセス'develop a fin
ancial plan"（財務計画を開発）の存在を正当化（またはその逆）するのに役立つ。正当
化は、質問ＷＨＹ？に対する追加の返答に付加された重みと関連づけられる。従って、カ
ーソルをプロセスに対して移動すると、質問ＨＯＷ？とＷＨＹ？がアドレスされるので、
複数のプロセスを特定のタスク・ステージに組み入れることができる。

モデルのいずれかのステージで、プロセスのオブジェクトをもっと具体的に定義する必
要が起こることがある。図６は、カーソルを特定のプロセスの上に置いてボタンバー２４
からＷＨＡＴ？アイコンを選択したとき生成されるオンスクリーン・ディスプレイを示し
たものである。このケースでは、プロセスはプロダクトの概念を確立するためのものであ
る。ＷＨＡＴ？ウィンドウをタスク・モデル・スクリーンの上にオーバーレイさせると、
ユーザはオブジェクトのリスト（このケースでは、問題のプロセスが関係するプロダクト
概念）をキーボードから入力することが可能になる。従って、同一オブジェクト定義のも
とに異なるアイテムを指定する必要のある、タスクのプロセスについては、システムは、
関係アイテムを追加または削除できる、オプションのインベントリを提供するように構成
されている。ＷＨＡＴ？ウィンドウには、図７に示すように関連のツールバーがある。ツ
ールバー３４はツールボタン群からなり、これらは下述するように個々の機能をアクチベ
ートさせるものである。ツールバーは、ツール・アイコン３２上でクリックし、ボタンを
上下させると、オープンし、クローズする。

ＷＨＡＴ？照会の結果としてインベントリに入れられたアイテムは、いずれも、別のＷ
ＨＡＴ？照会の対象にすることができる。図８は、インベントリ"WHAT PRODUCT CONCEPT"
( 製品コンセプトは何？）内の"talking tree"（話せる木）オブジェクト・アイテムと関
係づけて、これを示したものである。
"talking tree"の下にインデントされたサブアイテム・リストは言語のインベントリを列
挙している。インデントされたリストは、Tool Bar（ツール・バー）のWhat 38 とNot Wh
at 40 上でクリックすると、オープンまたはクローズする。

ＷＨＡＴ？リストは、ユーザが必要とするレベル数までインデントすることができる。
図９は、"Talking Tree"（話せる木）オブジェクトの "French"(フラング語）オブジェク
トを示し、これを展開すると、現在入力されているフランス語の方言４２が表示される。

図９に示すインデントされたリストのほかに、ユーザは、図１０に示すようにＷＨＡＴ
？リスト内の特定のオブジェクト層に集中することができる。あるオ ブジェクトとその
細分化されたものに集中するには、ユーザはリスト内の必要 とするオブジェクト（この
例では、"Talking Tree"）までカーソルを移動し、Focus ボタン４８上でクリックする。
ＷＨＡＴ？ウィンドウが再表示され、"What Talking Tree?"（話せる木は何？）はタイト
ルバー４６に置かれ、オブジェクトとインデントしたオブジェクトのリストは"Talking T
ree"４４の細分に限定されている。

ユーザは、オブジェクトをオブジェクト・インベントリからプロセス選択フィールド(P
rocess Selection Field - PSF) へプロモートすることにより、プロセス・モデルのコン
テキストを変更することができる。これを行うには、ユーザはＰＳＦセレクションをもつ
プロセスの左側に表示されている、すべての情報のコンテキストを変更する。ＰＳＦセレ
クションの例は図１１に示されているが、そこでは、"Talking Tree"がＰＳＦ５２へプロ
モートされている。ユーザは、必要とするオブジェクト５０をハイライトにし、ツール・
バー(Tool Bar)のSelect（選択）ボタン５４上でクリックすることによりオブジェクトを
ＰＳＦへプロモートする。ユーザがDe-Select(選択解除）ボタン５６上でクリックすると
、オブジェクト・コンテキストがＰＳＦから除去される。

オブジェクト・コンテキストがプロセスＰＳＦコントロールを使用して変更されると、
ＷＨＡＴ？のインベントリが表示される。図１２は、プロセス"Establish Product Conce
pt" （プロダクト概念の確立）のＰＳＦへプロモートされたオブジェクト"Electric Car"
（電気自動車）を示している。プロセス"Identify Requirements"(要件を特定）でオープ
ンされたＷＨＡＴ？ディスプレイは、"Product Concept" "Electric Car"に関係する"Req
uirements"（要件）のインベントリ(inventory) を示している。

プロセスのＰＳＦが右側にあるとき表示されるオブジェクト・インベントリは、オブジ
ェクト階層でＰＳＦオブジェクトよりも上位にあるオブジェクトの オブジェクト・イン
ベントリにも従属している。この振舞い（作用）はオブジェクト継承(Object Inheritanc
e)であり、図１３と図１４に示されている。図１３に示すように、オブジェクト"Financi
al Support"(財務援助）はプロセス"Identify Requirements"(要件を特定）のインベント
リに入力され、右側のプロセスはＰＳＦセレクションがない "Establish Product Concep
t"（製品コンセプトを確立）６４になっている。従って、"Requirements"（要件）の "Fi
nancial Support"（財務援助）は"Product Concept"(製品コンセプトおよび"Product Con
cept"（製品のコンセプト）に対するオブジェクトの完全インベントリと関連づけられて
いる。図１４は、"Establish Product Concept" のＰＳＦへプロモ連トされた"Electirc
Car"を示しており、図１２に最初に示したように、"Product Concept" "Electric Car"に
関連するプロセス"Identify Requirements" の関連ＷＨＡＴ？はインベントリの一部とし
て"Financial Support"を含んでいるが、これは、"Financial Support" が"Product Con
cept" から継承されたためである（"Electric Car"は"Product Concept" のＷＨＡＴ？の
インベントリの一部である）。

オブジェクトのインベントリ内のすべてのオブジェクトは、コンテキストに関係なく、
ＷＨＡＴ？ディスプレイをＡｌｌモードにセットすると、表示することが可能である。図
１５は、Ａｌｌモードにあるプロセス "Identify Requirements" （要件を特定）のＷＨ
ＡＴ？インベントリを示す図であり、インベントリに存在するオブジェクトのすべてをコ
ンテキストに関係なく示している。ＷＨＡＴ？ディスプレイを通常モードからＡｌｌモー
ドに変更するには、ユーザはツール・バーのボタン７０上でクリックする。ＷＨＡＴ？デ
ィスプレイを通常（非Ａｌｌ）モードで再表示するには、同じＡｌｌボタン７０をクリッ
クする（上げる）。ＷＨＡＴ？ディスプレイがＡｌｌモードになると、ディスプレイ内の
各オブジェクトの右側のボックス・アイコンは、オブジェクトが右側のプロセスと関係（
コンテキスト）があるかどうかを示している。コンテキストがあるオブジェクトはボック
ス７２にチェックがあり、コンテキストのないオブジェクトはボックス７４にチェックが
ない。

ユーザは、Ａｌｌモード Select とDe-Select を使用すると、オブジェクトと右側のプ
ロセスとの関係を作成し、あるいは削除することができる。ＡｌｌモードSelectと De-Se
lectは図１６と１７に示されている。図１６に示す"Requirement" "Aluminium Body"（ア
ルミ・ボディ）は、オブジェクト"Aluminium Body"をハイライトにし、ツール・バーのDe
-Select ボタン７８をクリックすると、"Product Concept" "Electric Car"との関係から
除去される。"Requirement" "Energy Shortage"（エネルギ不足）は、オブジェクト"Ene
rgy Shortage" をハイライトにし、ツール・バーのSelectボタン７６をクリックすると、
"Product Concept" "Electric Car"との関係に入る。図１７は、上記の関係変更の結果を
示したものである。"Identity Requirements" のＷＨＡＴ？ディスプレイは、ツール・バ
ーのボタン８６をクリックし、持ち上げることにより通常モードに変更されて、"Require
ment" "Aluminium Body"はインベントリに表示されなくなるのに対し、"Requirement" "E
nergy Shortage" はインベントリに表示されている。

関係がプロセスおよび／または右側のプロセスＰＳＦセクションに依存することは合成
(Compounding) と呼ばれる。合成は、Ｈｏｗモードでプロセス・モデルを左へ移動してい
くと続けられる。図１８は、さらに左への合成を示している。プロセス"Establish Produ
ct Concept" は"Electric Car"がＰＳＦへプロモートされている。プロセス"Identity Re
quirements" は"Energy Shortage" がＰＳＦへプロモートされている。Ｗは"Electric Ca
r Energy Shortage"９２のように合成されている。"Identify Requirements" の左側のプ
ロセス"Assess Probability"（可能性をアクセス）はＰＳＦセレクションと "60%"のＷ
ＨＡＴ？インベントリをもっている。このことは、"Electric Car Energy Shortage"（電
気自動車「エネルギー不足」）が "Probability"（可能性）"60%"をもち、"Probability"
"60%" が "Energy Shortage"と合成され、"Energy Shortage"が"Electric Car"と合成さ
れていることを示している。

合成は、プロセスでチェインブレークすると中止することができる。プロセスがチェイ
ンブレーク(chain-break) であるときは、これは、左側の別の依存関係がそのプロセスか
ら合成を開始することを意味する。図１８と図１９はチェインブレークと通常プロセスを
示している。プロセスをチェイン・ブレークにセットするには、通常(Normal)ボタン８８
をクリックするか、あるいは押す。ボタン８８はチェインブレーク(chain-break) という
ワードを表示する。チェインブレーク・プロセスを通常(Normal)に戻すには、同じボタン
（現在Chain-break というワード９４を表示している）を押すと、ボタンはNormalという
ワードを表示する。ボタン８８／９４は、各プロセスごとにそれがプロセス・モデルの中
で選択されると、プロセスでどちらのモードがセットされているかに応じて、Chain-brea
k またはNormalを表示する。図１９はチェインブレークとセットされたプロセス"Assess
Probability"（可能性をアクセス）を示し、ＰＳＦエントリと"30%" のＷＨＡＴ？インベ
ントリをもつプロセス"Assess Probability"を示している。このような（チェインブレー
ク）状況の下では、"Probability"(可能性）"30%" は、プロセス"Establish Product Con
cept"(製品コンセプトを確立）でどのようなコンテキストがセットされているかに関係な
く、"Requirements"（要件） "Energy Shortage"（エネルギー不足）と関連づけられてい
る。

ＰＳＦセレクションをもつプロセスは、そのＰＳＦセレクションをもつプロセスとだけ
関係づけられたＨｏｗ？とＷｈｙ？プロセス関係をもつことができる。図２０はＨｏｗプ
ロセス関係をもつＰＳＦプロセスを示している。プロセス"Identify Climate Changes"（
気候変化を特定）１００は、オブジェクト"Energy Shortage"が選択されて"Identify Req
uirements"１０２のＰＳＦに入れられたときだけ、"Identify Requirements"のＨｏｗ？
になっている。図２１は、Ｗｈｙ？プロセス関係をもつＰＳＦプロセスを示している。プ
ロセス"Manage Finances"（資金を管理）は、オブジェクト"Financial"（財務）が選択さ
れて"Manage Actions"（活動を管理）のＰＳＦに入れられたときだけ、"Manage Actions"
のＷｈｙ？になっている。なお、継承はプロセス関係にも適用される。図２０において、
プロセス"Assess Probability"がＰＳＦセレクションをもつプロセス"Identify Requirem
ents" のＨｏｗ？のままになっているのは、プロセス"Assess Probability"がプロセス "
Identify Requirements"と関連づけられ、ＰＳＦセレクション"Energy Shortage" がプロ
セス"Identify Requirements" のインベントリの一部になっているためである。

Ｉｎｆｏボタンを選択すると、情報ウィンドウが生成され、そこでは、行見出し(row h
eadings)は情報テンプレートの場合と同様に、現プロセスのサブオブジェクトのそれにな
っている。しかし、列見出し(column heading)は、現プロセスより下位の（左側の）ステ
ージの構成プロセスのオブジェクトから自動的に派生される。関連プロセスが追加または
削除されると、情報ウィンドウ内の列はそれに応じて変化する。プロセスがモデルに追加
されると、特定プロセスの情報ウィンドウは自動的に列見出しを生成し、これは、Ｈｏｗ
？方向に沿った次のモデル・ステージの構成関連プロセスのオブジェクト・ワードから取
り出される。これにより、プロセスのステータスを表形式で表わしたものを呼び出すこと
ができるので、そこで、先行プロセス・オブジェクトのステータスをレイアウトすること
ができる。図２２は、プロセスと情報ウィンドウの列見出しとの関係を示す図である。

必要とするオブジェクトを選択すると、関係の情報ウィンドウが表示される。明らかな
ように、ユーザは、プロセス構造と情報ウィンドウを使用して構造をブレンドすることに
より、タスク・モデルを構築することができる。本発明によれば、情報ウィンドウに追加
された列見出しに対して情報ウィンドウが関連づけられている構成レベルで、プロセス・
ボックスが自動的に作成される。従って、テンプレートに追加されたプロセス・オブジェ
クトはタスク・モデルにプロセス・ボックスとして現われるが、そこに付加された動詞が
脱落している。この脱落した動詞はユーザのオプションでタスク・モデルに追加すること
が可能である。また、本発明によれば、プロセス・ボックスが表示されたタスク・モデル
に現われるのを望まなければ、テンプレートを通して追加されたプロセス・ボックスを、
ユーザのオプションで削除することが可能である。

システムには、関係する人々のアドレス・リストといったように、いずれかのタスク・
モデルと必ずしも関連づけられていない事前に準備したテンプレートを日常的に使用する
ように用意しておくことも可能である。例えば、標準プロセス"contact people"（連絡先
）は、定期的に連絡する人達に関する基本データをリストする情報テンプレートが関連づ
けられているシステムにインストールすることが可能である。ここで注意すべきことは、
これは必ずしもタスク・モデルの一部でないプロセスであるが、独立に呼び出すことがで
きることである。同様に、日常的な機能を、タスク・モデルまたはプロセスとリンクされ
ていない別ルーチンとしてインストールすることも可能である。

タスク・モデルの一部として、また、システムが異なるスキル要件に対して柔軟性があ
ることを例示するものとして、ボタンバー２４に'Calc'ボタンがあるので、ユーザは数字
を計算するためのプロセスをタスク・モデルに作ることができる。図２３は、プロセス"D
evelop Financial Plan"（財務計画を開発）用に計算が設定されたとき、表示されるタス
ク・モデルを示す図である。この計算のステップはタスク・プロセスとして設定されてい
る。

計算は、タスク・モデルのステップにおいて重要なデータを表わしている。計算は、図
２３に示す関連の情報ウィンドウのオブジェクトに適用される。数値データは、計算の対
象となるオブジェクトについて入力され、その結果は、情報ウィンドウの'Profit'（利益
）行見出しの個所に自動的に表示される。従って、情報ウィンドウは、情報ウィンドウに
表形式で自動的に配列された'Calc'プロセスに対して、スプレッドシート計算を行う機能
を備えている。計算は、情報ウィンドウ内の行、列、および特定のセルに対して行なうこ
とができる。さらに、ユーザは、事前定義した数値および会計関数(financeial function
) の中から選択して、計算の中で使用することが可能である。

タスク・モデルを詳細に見直したり、全体を概観するために、OPTIONS メニュー・アイ
テムにはFEEDBACK（フィードバック）があり、これを選択すると、タスク・モデルの詳細
フィードバックまたは概要フィードバックのどちらかを選択することができる。詳細ビュ
ーによると、タスク・モデルの完全性とロジックについて診断することができ、タスクの
プロセスをハイライトした時間ベース経過セクションがあり、そこでは、アクション・ウ
ィンドウの日付ベースの目標と共に、期日(due date)が設定されていなかったか、期日を
経過したかが示されている。詳細フィードバック・モードで比較を呼び出すと、ターゲッ
トが設定された目標の実際の達成度を知ることもできる。

概観モードでは、フィードバックは、メニュー・バー２２からOPTIONS メニュー・アイ
テムを選択すると、図２４に示すように表示される。各プロセスには、赤の三角形の注釈
が付けられ、プロセス実行の困難度が数字で示されている。この数字は、例えば、０から
９９までの適当な範囲から割り当てることができる。数字が大きくなると、特定プロセス
に関連する困難度が大になる。リストされたプロセスのいずれについても、システムがモ
デル全体を調べていくとき、重み付けがシステムによって使用される。見つかった各条件
のインスタンスの数にこの重み付けをかけて、その条件の合計スコアが求められる。ユー
ザがフィードバックに詳細モードを選択していれば、情報はユーザ条件について条件別に
表示される。概観モードでは、三角形が表示されて、プロセスのすべての条件の合計が０
から９９までの数字になるように計算される。

モデルはブランク・スクリーンからユーザによって作ることができるが、公知のタスク
や特定されたタスクについては、事前に書かれたモデルをシステムに ロードすることも
可能である。これはシステムの一部として得ることも、既存システムにロードされる別フ
ァイルとして得ることも可能である。

理解されるように、同じタスク・ステージでの並列プロセスは'AND' という ワードで
リンクされており、これはロジカル（論理）ＡＮＤであり、そのステージのすべてのプロ
セスが満足されてから、右側の上にある、次のステージの関連プロセスが完成できること
を示している。もちろん、ロジカルＡＮＤをロジカルＯＲまたはＴＨＥＮに置き換えて、
それぞれ選択プロセスまたは順次プロセスを示すことも可能である。

特定のユーザは、種々のキー・オブジェクトや動詞ワードおよびフレーズを異なるタス
ク・モデルの中で再使用することが起こり得る。システムは、そのようなワードとフレー
ズをすべて維持していて、ディクショナリから取り出せるようにしている。オブジェクト
・ディクショナリは、サブオブジェクトがあればそれらと一緒に、すべてのオブジェクト
の記録をとっている。オブジェクトは多数の異なるモデルの中に存在することができ、モ
デル内で異なるレベルで存在することができる。従って、ある特定のオブジェクトが使用
されると、後続のＨＯＷ？ステップは最高レベルからのステップ、つまり、モデル化して
いる基本タスク・プロセスに最寄りのステップになる。これは計算にも適用されるので、
一度だけ定義しておけば、異なるモデルの中で、あるいは同じモデルの異なる部分の中で
再使用することができる。その結果として、あるオブジェクトに関連づけられた情報やテ
キストは、そのオブジェクトがタスク・モデルの中で再使用されている個所と関連づけて
、あるいはオブジェクトがあとで表示される任意のタスク・モデルと関連づけて、取り出
すことが可能になる。以上のように、本発明によると、モデル間の相互参照データベース
(cross referenced database) を得ることができる。

動詞ディクショナリは、すべての動詞と動詞がその中で使用されるプロセスの記録をと
っている。プロセス・ディクショナリはすべてのプロセスとプロセスが使用されている場
所の記録をとっている。

ロードされたタスク・モデルを変更するには、モデルのステージで変更を行おうとする
位置までカーソルを移動する。変更としては、ステップを追加する場合と、すでにモデル
に存在するステップを補足する場合とがある。後者の場合は、補足ステップを置こうとし
ている、モデルの既存ステップの下の縦方向のエリア内にカーソルを移動する。図２５に
示すように、プロセス"achieve sales target"(売上げ目標を達成）がタスク・モデルに
追加されている。このケースでは、この新プロセスに従属する他の種々オブジェクトも、
ＨＯＷ？モードによって追加されており、各ステージでの並列プロセスは上述したように
、カーソルを下方向に移動することにより追加される。参照ディクショナリにエントリが
あるタスク・モデルにプロセスを挿入する必要が起こった場合は、これらのプロセスも自
動的に追加するようにシステムを構成することが可能である。

図１７のエンティティ関係図および付録ＡとＢを参照して、ソース・コードの抜粋と関
連付けながら本発明について説明することにする。

付録Ａは、ディスプレイ（Ｗｈａｔ，Ｈｏｗ，Ｗｈｙウィンドウ）上の移動を管理する
Ｃ++クラスである。付録Ｂは、第１次オブジェクトと第２次オブジェクトを作成するＣ++
クラスである。これらの付録は、データ構造と関連処理から見た論理設計の基本原理を示
している。

（001 第１次と第２次の関係）
１．第１次関係は、任意のプロセスOBJECTとその直接のHOW プロセスの各々との関係を示
し、ストアするために使用される。
２．第２次関係は、あるプロセスのすべての第１次関係の集合を示し、ストアするために
使用される。また、情報ウィンドウとしては、タスク・モデルの一部を表示する別の方法
となるだけである。
３．情報ウィンドウ内の行(row) は第２次関係である。
４．情報ウィンドウ内の各列(column)は、その列と左端の列との第１次関係である（WHAT
リスト）。

（005 プロセス）
１．プロセスは動詞フレーズと名詞フレーズとして捕獲される。
２．動詞フレーズをOBJECTCATEGORYのOBJECT（第２次）として、またユーザが入力したテ
キストをOBJECT TEXT インスタンスとしてストアする。
３．名詞フレーズをCATEGORYのOBJECT (オブジェクト・プリミティブ) としてストアする
。このOBJECT PRIMITIVEのOBJECT TEXT インスタンスを作成して、ユーザが入力したテキ
ストをストアできるようにする。
４．CATEGORYのOBJECT（第２次）を作成し、これを上記２で定義したOBJECTの子として、
OBJECT INHERITANCE（オブジェクト継承）関係を用いて結合する。
５．CATEGORYのOBJECT（第１次）を作成し、これと上記３で作成した名詞フレーズとのOB
JECT ASSOCIATION（オブジェクト関連）を作成する。
６．最後に、上記４と５で作成したOBJECT間の関係を、OBJECT ASSOCIATIONエンティティ
を用いて作成する。

（010 HOW コネクション）
HOW プロセスがユーザによって入力されると、そのプロセスについて005 を実行し、次
に、HOW コネクション（結合）を次のように行う。
１．OBJECT（第１次）を作成する。これと以下のものとの間は、別々のOBJECT ASSOCIATI
ONを有する。(1) このHOW プロセス（子プロセス）の005/4OBJECT (2) HOW プロセスを結
合しようとするプロセス（親プロセス）の 005/3OBJECT
２．010/1 を親プロセスの005/4 と結合する。
３．これが最初の HOWプロセスでなければ、結合ロジック、つまり、AND、 OR、 THEN (A
OT)がユーザによって入力されている。010/1 OBJECTのOBJECT CHARACTERISTICS (AOT) を
作成して結合子をストアする。

（020 WHY コネクション）
WHY コネクションはHOW コネクションを逆方向から見たものである。従って、まず、ユ
ーザが入力した WHYプロセスについて005 を実行する。次に、010 を実行するが、ユーザ
が入力したプロセスを親プロセスとして使用し、現プロセスを子プロセスとして使用して
実行する。

（030 WHATリスト）
オブジェクトがユーザによってWHATリストに追加されたときは、
１．入力された名詞フレーズについてOBJECT(PRIMITIVE OBJECT)を作成する。これは005/
3 と同じルーチンである。
２．030/1 とのOBJECT INHERITANCE関係を子として作成し、WHAT IS OBJECTを親として作
成する。
３．入力されたOBJECTをWHATコマンドを使用してさらに細分化する場合は、030/1 とでさ
らにOBJECT INHERITANCE関係を親として、追加のOBJECTS を子として作成する。
４．ユーザが入力した別の細分については、以下同様。

（040 THENロジックの影響）
定義010 と020 はユーザが結合子AND またはORを入力したとき適用される。しかし、TH
EN結合子が入力されたときはロジックは若干異なる。その違いは次のとおりである。
１．010/1 (1) で定義されたOBJECTは、010/1 で作成されたオブジェクトで置き換えられ
る。

（情報ウィンドウ）
（050 情報ウィンドウの表示）
情報ウィンドウは、Ｙ軸（行）を表すWHATリストを延長したものである。Ｘ軸（列）は
システムによって設定されたデフォルトとして作成されるか、ユーザによる明示の指示に
従って作成される（出力の定義を参照）。デフォルトの情報 ウィンドウは次のように計
算される。
１．現プロセスのOBJECT（第２次）を取り出す。
２．050/1 の005/3 を取り出す。
３．050/3 のOBJECTINHERITANCE 関係を調べ、各インスタンスをWHATリストとして表示す
る。
４．次に、050/1 のOBJECT ASSOCIATIONS を調べて、050/1 が関連づけられている各OBJE
CT (第１次）を見つける。
５．見つかった各OBJECT (第１次) ごとに、OBJECT ASSOCIATES をもう一度調べて010/1
(1) OBJECTを見つける。
６．CATEGORY（第２次）に属する各010/1 (1)OBJECT ごとに、OBJECT ASSOCIATION をも
う一度調べて005/5OBJECT を見つける。各005/5OBJECT ごとに、OBJECT ASSOCIATIONをも
う一度調べて 005/3OBJECTを見つける。このOBJECTとその関連OBJECT TEXT インスタンス
は列見出しを表している。

（060 出力の定義）
ユーザは出力定義関数を使用すると、デフォルト情報ウィンドウをオーバライドするこ
とができる。
１．デフォルト列の削除が示されていれば、該当のCHARACTERISTICS(特性）インスタンス
を作成することにより、データ構造内でこれにフラグを付ける。
２．追加の列が示されていれば、CATEGORYのOBJECT (OBJECT PRIMITIVE) として入力され
たテキストを005/3 と同じようにストアする。
３．これらの追加列について、010/1 (1) OBJECTが上記 060/2で作成された OBJECTで置
き換えられることを除き、010/1 と同じようにOBJECT（第１次）も作成する。

注意：このユーザ定義列オブジェクトがHOW プロセスでなく、かつ表示しないことを指
示するにはCHARACTERISTICS を使用する。

（070 行）
左端列は現プロセスのWHATリストであり、定義030 が適用される。ユーザが列エントリ
を作る行について、次のことを行う。
１．ユーザがこの行に到達するまでたどっていったWHAT階層の各レベルごとにOBJECT（第
１次）を作成する。
２．これらの第１次の各々ついて、第１次と次のものとの間の別々のOBJECT ASSOCIATION
Sを作成する。

(1) 行の030/1 OBJECT
(2) 上のレベルで作成された070/2 OBJECT。

上のレベルがプロセス・オブジェクトであれば、該当の 005/3 OBJECT を使用する。
３．最下位レベルの070/1 OBJECT（必要とする行）はその行のプロセス・オブジェクト、
つまり、合成オブジェクトを表している。
４．次に、行のOBJECT（第２次）を作成し、これと070/3 との間のOBJECT ASSOCIATION
を作成する。
５．次に、この第２次と現プロセスの005/4 との間のOBJECT INHERITANCEインスタンスを
作成する。
６．ユーザが作ろうとしている列エントリについて、カーディナリティ - 080をチェック
する。
７．各列エントリについて、まだ存在していなければOBJECT (PRIMITIVE OBJECT) を作成
し、列エントリとのOBJECT INHERITANCE関係を子として、列見出しとの関係を親として作
成する。
８．次に、各列エントリについて、OBJECT（第１次）を作成し、これと次のものとの間の
別々のOBJECT ASSOCIATIONを作成する。

(1) 070/7
(2) 070/3
９．070/8 を 070/4に結合する。

（075 タスク・モデル・ウィンドウ内の行の選択）
ユーザは情報ウィンドウを使用すると行を作成することもできる。行は親プロセスおよ
びその近親のHOW プロセスと等価である。Sub object（サブオブジェクト）を選択してプ
ロセス選択フィールドに入れることは、関連情報ウィンドウ内の該当列に入れることとま
ったく同じである。

（078 WHATとSELECTの比較）
WHATコマンドは、OBJECT INHERITANCE構造を徐々に詳細化するレベルまでたどっていく
ために使用される。必要とするOBJECTが判別されると、SELECTコマンドは、そのOBJECTと
OBJECT INHERITANCEネットワーク内の関係する「子」が現在の関係に結合されたことを示
している。070 と075 に関しては、これは行内の列とプロセス選択フィールドに適用され
る。

（080 カーディナリティ(Cardinality) ）
出力定義ウィンドウを使用すると、ユーザはカーディナリティを定義することができる
。最小関係と最大関係の指定が許される。これらの各々は、1:n の形式で指定する。ただ
し、ｎは整数または'many'のワードである。最小関係を指定すると、ユーザは列を必須ま
たは任意として指定することができる。また、ユーザは、列エントリが列見出しのサブオ
ブジェクトとして存在しなければならないことを指定することもできる。

ユーザが論理結合子にONLYを指定していれば（CHARACTERISTICとしてストアされている
）、この結合子の両辺のプロセスは相互排他的であり、この結合子の両辺のエントリは、
同一列内では、禁止しなければならない。

（090 構造シーケンス）
データベースへ入力する順序は次の場合には重要である。
１．OBJECT INHERITANCEでは、順序はユーザ入力順序を反映していなければならない。
２．OBJECT ASSOCIATIONでは、ルーチン050 と070 で使用されるときは、列と関連行エン
トリ間の順序は、関連のOBJECT INHERITANCEをたどっていくとき保たれていなければなら
ない。

ボタン・バー２４はハッピ・フェース（喜んでいる顔）とサッド・フェース（悲しんで
いる顔）の２つのシンボルももっている。これらは、ユーザが判別されたプロセスに自信
があるか否かを示すようにタスク・モデルがセットアップされるとき使用することができ
る。これらのフェースは、マウスで選択したときスクリーン上のどこにでも「ドラッグ」
することができる。システムは、一時的表示を目的に基本タスク・モデルにオーバーレイ
する動詞／オブジェクト・プロセルおよびウィンドウ・フィールドをもつオンスクリーン
・ディスプレイを中心にして説明されているが、タスク・モデルの他の構成および配置が
可能であることももちろんである。例えば、タスク・モデルのプロセス・ステップをディ
スプレイの上下に進めていくことが可能である。日々の日記のように、他の周辺機能をシ
ステムに含めることも可能である。日記をシステム上の１つまたは２つ以上のモデルのプ
ロセスにリンク可能にすると、日記に記載したイベントを使用して、例えば、デッドライ
ンが近づいたことをユーザに警告することができる。同様に、システムには、電話、ファ
ックスおよびアドレス・リスト・テンプレートがプリインストールされているので、カー
ソルが'contact people'（人物と連絡）プロセスを示すボックス内に置かれているときに
アクションボタンを選択することにより、標準プロセス'contact people'からアクセスす
ることができる。テンプレートが現れているとき、該当する人または企業までスクロール
することができる。アクションボタンを再度選択すると、関係の詳細を記載した入力テン
プレートが現れることになる。

法の規定に従って、構造上および機能上の特徴に関して多少でも分かりやすく本発明を
説明してきたが、本発明は上述した特定の特徴に限定されないことはもちろんである。こ
れまでに開示してきた構造の手段と方法は、本発明を実施するときの好適な実施態様を示
したにすぎない。この分野の当業者ならば理解されるように、装置および方法は他の改良
および他の変形形態も可能である。従って、上述してきた説明は単なる例示であり、それ
に限定されるものではない。本発明は種々の形態または改良形態で請求の範囲に明確化さ
れているが、その合法的かつ有効な範囲は均等論に従って正しく解釈されるものである。
［付録Ａ］

[付録Ｂ]

本発明をインストールできるコンピュータ・システムを示す概略ブロック図である。 本発明の一実施例の基本ディスプレイ・スクリーンを示す図である。 タスク・モデルの始まりが形成されているディスプレイ・スクリーンを示す図である。 より完成したタスク・モデルのディスプレイ・スクリーンを示す図である。 改良されたタスク・ステップの細部のディスプレイ・スクリーンを示す図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、タスク・ステップ・プロセス内のオブジェクトが指定されている図である。 図６と同じようにオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、ツールボタン(Tool Button) が押され、ツールバー(Tool Bar)がオープンしている図である。 図７と同じようにオーバーレイしたウィンドウのディスプレイ・スクリーンを示す図であり、オブジェクトが２つの追加レベルに展開されている図である。 図７と同じようにオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、オブジェクトが２つの追加レベルに展開されている図である。 図６と同じようにオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、１つの特定オブジェクトに焦点を当てている図である。 図６と同じようにオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、そのウィンドウからのオブジェクトが選択されて、プロセス選択フィールドに入れられている図である。 ２つのオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、オブジェクトの関連づけを示している図である。 図６と同じようにオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図である。 ２つのオーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、オブジェクト継承を示している図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、Ａｌｌモードを示している図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、ＡｌｌモードのSelect（選択）とDe-select(選択解除）を示している図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、Normal（通常）モードを示している図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、プロセス・ボックスはオブジェクトの合成を示している図である。 オーバーレイされたウィンドウのディスプレイ・スクリーンを示す図であり、プロセス・ボックスはプロセスとオブジェクトのチェイン・ブレークを示している図である。 Ｈｏｗモードのプロセス・ボックスのディスプレイ・スクリーンを示す図であり、ＨｏｗプロセスがPSF の設定値に依存することを示している図である。 Ｗｈｙモードのプロセス・ボックスのディスプレイ・スクリーンを示す図であり、ＷｈｙプロセスがPSF の設定値に依存することを示している図である。 プロセスの情報ウィンドウのディスプレイ・スクリーンを示す図である。 プロセスの情報ウィンドウと計算プロセスのディスプレイ・スクリーンを示す図である。 重み付けされたタスク・モデルのディスプレイ・スクリーンを示す図であり、プロセスの困難度を示している図である。 タスク・モデルの一部のディスプレイ・スクリーンを示す図である。 ここで説明している本発明の実施例の場合のエンティティ関係図である。

符号の説明

１０ ユーザ
１２ キーボード
１４ コンピュータ
１６ モニタ・ディスプレイ・スクリーン
１８ メモリ
２０、４６ タイトルバー
２２ メニューバー
２４ ボタンバー
２６ エントリ・ボックス
３２ ツール・アイコン
３４ ツール・バー
４８ Ｆｏｃｕｓボタン
５０ オブジェクト
５２ ＰＳＦ
５４、７６ Ｓｅｌｅｃｔボタン
７０、８６ ツール・バーのボタン
７２、７４ ボックス
７８ Ｄｅ−Ｓｅｌｅｃｔボタン
８８ 通常ボタン
９４ ボタン

Claims (1)

1. データを入力するデータ入力手段と、データを表示するディスプレイ手段と、複数のプ
   ロセスの各々についての複数のインスタンスをストアするデータストレージ手段とを備え
   るコンピュータで実行される、１つの軸およびもう１つの軸を有する２次元グリッド中に
   複数のインスタンスを表示する方法であって、
   前記データ入力手段から、前記複数のプロセス中の第１のプロセスと第２のプロセスと
   の関係の入力を受けるステップと、
   前記第１のプロセスと前記第２のプロセスとの関係を前記データストレージ手段にスト
   アするステップと、
   前記データストレージ手段から、前記複数のプロセス中の１つのプロセスについての複
   数のインスタンスを取り出す第１取出ステップと、
   前記ディスプレイ手段上において、前記第１取出ステップで取り出した複数のインスタ
   ンスを、前記１つの軸に沿って表示するステップと、
   前記データストレージ手段から、前記関係に基づいて、前記複数のプロセス中の前記１
   つのプロセスがどのように実行されるかを定義するプロセスについての複数のインスタン
   スを取り出す第２取出ステップと、
   前記ディスプレイ手段上において、前記第２取出ステップで取り出した複数のインスタ
   ンスを、前記１つの軸に沿って表示するステップとを備え、
   前記第２取出ステップは、前記複数のプロセス中の前記１つのプロセスが前記第２のプ
   ロセスであり、かつ前記データストレージ手段が、前記第１のプロセスが、前記第２のプ
   ロセスがどのように実行されるかを定義するという関係をストアしている場合には、前記
   第１のプロセスについての複数のインスタンスを取り出すことを特徴とする方法。

Images