JP2004272919A

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

Info

Publication number: JP2004272919A
Application number: JP2004068239A
Authority: JP
Inventors: Trevor Bryan Davies; デイヴィス，トレボー，ブライアン．
Original assignee: Individual
Current assignee: Individual
Priority date: 1993-10-27
Filing date: 2004-03-10
Publication date: 2004-09-30
Anticipated expiration: 2024-07-29
Also published as: US6002396A; DE69429630T2; AU687457B2; JPH09504394A; EP0725954A1; JP2007004822A; CA2175367A1; JP2008004127A; AU7999294A; ATE211840T1; JP4303617B2; EP0725954B1; WO1995012174A1; DE69429630D1; GB9322137D0

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同様に、マウスは、スクリーン上に表示されているアイコンまたは文字を「捕らえる」(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 financial plan'（財務計画を開発）の存在を正当化（またはその逆）するのに役立つ。正当化は、質問ＷＨＹ？に対する追加の返答に付加された重みと関連づけられる。従って、カーソルをプロセスに対して移動すると、質問ＨＯＷ？とＷＨＹ？がアドレスされるので、複数のプロセスを特定のタスク・ステージに組み入れることができる。

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

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

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

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

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

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

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

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

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

関係がプロセスおよび／または右側のプロセスＰＳＦセクションに依存することは合成(Compounding) と呼ばれる。合成は、Ｈｏｗモードでプロセス・モデルを左へ移動していくと続けられる。図１８は、さらに左への合成を示している。プロセス"Establish Product Concept" は"Electric Car"がＰＳＦへプロモートされている。プロセス"Identity Requirements" は"Energy Shortage" がＰＳＦへプロモートされている。Ｗは"Electric Car 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-break またはNormalを表示する。図１９はチェインブレークとセットされたプロセス"Assess Probability"（可能性をアクセス）を示し、ＰＳＦエントリと"30%" のＷＨＡＴ？インベントリをもつプロセス"Assess Probability"を示している。このような（チェインブレーク）状況の下では、"Probability"(可能性）"30%" は、プロセス"Establish Product Concept"(製品コンセプトを確立）でどのようなコンテキストがセットされているかに関係なく、"Requirements"（要件） "Energy Shortage"（エネルギー不足）と関連づけられている。

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

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

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

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

タスク・モデルの一部として、また、システムが異なるスキル要件に対して柔軟性があることを例示するものとして、ボタンバー２４に'Calc'ボタンがあるので、ユーザは数字を計算するためのプロセスをタスク・モデルに作ることができる。図２３は、プロセス"Develop 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（第１次）を作成し、これと上記３で作成した名詞フレーズとのOBJECT ASSOCIATION（オブジェクト関連）を作成する。
６．最後に、上記４と５で作成したOBJECT間の関係を、OBJECT ASSOCIATIONエンティティを用いて作成する。

（010 HOW コネクション）
HOWプロセスがユーザによって入力されると、そのプロセスについて005を実行し、次に、HOWコネクション（結合）を次のように行う。
１．OBJECT（第１次）を作成する。これと以下のものとの間は、別々のOBJECT ASSOCIATIONを有する。(1) このHOW プロセス（子プロセス）の005/4OBJECT (2) HOWプロセスを結合しようとするプロセス（親プロセス）の005/3OBJECT
２．010/1を親プロセスの005/4 と結合する。
３．これが最初の HOWプロセスでなければ、結合ロジック、つまり、AND、 OR、 THEN (AOT)がユーザによって入力されている。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を入力したとき適用される。しかし、THEN結合子が入力されたときはロジックは若干異なる。その違いは次のとおりである。
１．010/1 (1)で定義されたOBJECTは、010/1で作成されたオブジェクトで置き換えられる。

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

(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

タスクを実行するためのプロセス構造を作成するシステムであって、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能であるデータをストアしているデータ・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのステップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義を受け取ったときの応答として、第１プロセス定義を実行すると予想される結果となる第２プロセス定義をデータ入力手段から入力することをユーザに要求するように構成されていることを特徴とするシステム。
コンピューティング・デバイスは、プロセス定義のディスプレイをディスプレイ手段上に生成するように動作可能であり、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特徴とする請求項１に記載のシステム。
タスクのステップの進行はディスプレイ手段上を水平方向にわたっていることを特徴とする請求項２に記載のシステム。
ステップは左から右へ進行していくことを特徴とする請求項３に記載のシステム。
データ入力手段はキーボードを含むことを特徴とする請求項１に記載のシステム。
タスクを実行するためのプロセス構造を作成するシステムであって、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能なデータをストアしているデータ・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのステップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義を実行するとき予想される構成ステップとなる第２プロセス定義を入力することをユーザに要求するように構成されていることを特徴とするシステム。
コンピューティング・デバイスは、プロセス定義のディスプレイをディスプレイ手段上に生成するように動作可能であり、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特徴とする請求項６に記載のシステム。
タスクのステップの進行はディスプレイ手段上を水平方向にわたっていることを特徴とする請求項７に記載のシステム。
ステップは左から右へ進行していくことを特徴とする請求項８に記載のシステム。
コンピューティング・デバイスは、あらかじめ決められたプロセス定義をデータ・ストレージ手段から取り出すように構成され、該プロセス定義は、ユーザによってキーボードから入力された第２プロセス定義を実行するときの構成ステップであることを特徴とする請求項６に記載のシステム。
タスクを実行するためのプロセス構造を作成するシステムであって、該システムは、
コンピューティング・デバイスと、
コンピューティング・デバイスによってアクセス可能なデータをストアしているデータ・ストレージ手段と、
コンピューティング・デバイスに接続されていてデータを入力する手段と、
同じくコンピューティング・デバイスに接続されていてデータを表示するディスプレイ手段とを備えており、コンピューティング・デバイスは、少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義をデータ入力手段を通してユーザから受け取るように構成され、該プロセス定義はタスクまたはタスクのステップを定義しており、コンピューティング・デバイスは、さらに、第１プロセス定義のオブジェクト・ワードの意味の範囲に入る特定のオブジェクトを指定することをユーザに要求するように構成されていることを特徴とするシステム。
コンピューティング・デバイスはデータ入力手段から入力されたコマンドを受けると、その応答として、第１プロセス定義の少なくとも１つのオブジェクト・ワードの意味の範囲に入るオブジェクト・ワードに関連する検索可能データ・ディスプレイを作成することを特徴とする請求項１１に記載のシステム。
データ・ディスプレイは表形式であり、コンピューティング・デバイスは、データ入力手段からコマンドを受けたとき、その応答として、ディスプレイ手段上のプロセス定義にデータ・ディスプレイをオーバライトするように構成されていることを特徴とする請求項１２に記載のシステム。
タスクを実行するためのプロセス構造をモデル化するシステムであって、該システムは、
コンピューティング手段と、
コンピューティング手段によってアクセス可能であるデータ・ストレージ手段と、
コンピューティング手段に接続されていてデータを入力する手段と、
同じくコンピューティング手段に接続されていて、プロンプトと、入力手段からおよびコンピューティング手段から入力されたデータを表示するディスプレイ手段とを備えており、コンピューティング手段は、ユーザによってデータ入力手段から入力された第１プロセス定義を求めるプロンプトをディスプレイ手段から選択的に表示して、少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを要求するように構成されていると共に、第１プロセス定義を実行すると予想される結果となる、あるいは第１プロセス定義を実行してタスク・プロセス構造内の一連のステージを作成するときに予想される構成ステップとなる第２プロセス定義を入力することをユーザに要求する、コンピューティング手段からの別の入力プロンプトを選択することをユーザに要求するようにあるいは第１プロセス定義のオブジェクトの意味の範囲に入る特定のオブジェクト・ワード（１つまたは複数）を指定することをユーザに要求するように構成されており、コンピューティング手段は、さらに、１つのステージでの１つのプロセスに関連する検索可能な表形式データ・ディスプレイを作成するように動作可能であり、そこでは、前記１つのプロセス定義の前のステージにおける構成プロセス定義のオブジェクト・ワード（１つまたは複数）は、列見出しとして配列され、該１つのプロセス定義の特定のオブジェクトは、行見出しとして配列されていることを特徴とするシステム。
タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスクのステップを定義しているものと、
第１プロセス定義を実行すると予想される結果となる第２プロセス定義を入力することをユーザに要求するステップとを含むことを特徴とする方法。
プロセス定義のディスプレイをディスプレイ手段上に生成するステップを含み、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特徴とする請求項１５に記載の方法。
タスクのステップはスクリーン上を水平方向に進行していくことを特徴とする請求項１６に記載の方法。
ステップは左から右へ進行していくことを特徴とする請求項１７に記載の方法。
タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスクのステップを定義しているものと、
第１プロセス定義を実行するとき予想される構成ステップとなる第２プロセス定義を入力することをユーザに要求するステップとを含むことを特徴とする方法。
プロセス定義のディスプレイをディスプレイ手段上に生成するステップを含み、タスクのステップの１つにおけるプロセス定義は行に配列され、ステップにおけるプロセス定義の行はディスプレイ手段を横切って進行していくことを特徴とする請求項１９に記載の方法。
タスクのステップはスクリーン上を水平方向に進行していくことを特徴とする請求項２０に記載の方法。
ステップは左から右へ進行していくことを特徴とする請求項２１に記載の方法。
ユーザによってキーボードから入力された第１プロセス定義を実行するときの構成ステップとなる、あらかじめ決められたプロセス定義を取り出すステップを含むことを特徴とする請求項１９に記載の方法。
タスクを実行するためのプロセス構造をコンピュータ上で作成する方法であって、該方法は、
少なくとも１つの動詞ワードと少なくとも１つのオブジェクト・ワードを含んでいる第１プロセス定義を入力するステップであって、該第１プロセス定義はタスクまたはタスクのステップを定義しているものと、
特定のオブジェクト・ワードを指定することをユーザに要求するステップであって、該オブジェクト・ワードは第１プロセス定義のオブジェクト・ワードのインスタンスであることを特徴とする方法。
データ入力手段から入力されたコマンドを受けると、その応答として、第１プロセス定義のオブジェクト・ワードのインスタンスであるオブジェクト・ワードに関連する検索可能データ・ディスプレイを作成するステップを含むことを特徴とする請求項２４に記載の方法。
コンピューティング手段はデータ入力手段から入力されたコマンドを受けると、その応答として、ディスプレイ手段上のプロセス定義に表形式のデータ・ディスプレイをオーバライトすることを特徴とする請求項２４に記載の方法。