JP2016177567A - タスク管理装置、方法及びプログラム - Google Patents

Abstract

【課題】汎用性を持った、処理の進捗管理ツールを提供する。
【解決手段】進捗管理プログラム１１８は、タスク情報記憶部１１０、タスク管理部１１３、表示制御部１１４等を有する。タスク情報記憶部は、プログラムに実行させるタスクの種類毎に、タスクの進捗状況を把握するためのタスクの設定情報（Ｐ１進捗〜Ｐ４進捗）を記憶し、タスク管理部は、タスクを実行するプログラム（プログラム１〜プログラム４）が出力する出力結果とは異なる副次的な情報出力（ログ等）とタスクの設定情報に基づいて、各タスクの進捗状況を把握し、表示制御部が進捗率を表示出力する。
【選択図】図３

Description

本発明は、タスク管理装置、方法及びプログラムに関し、特に、タスクの進捗状況を把握するための技術に関する。

情報処理装置、コンピュータの技術分野において、アプリケーションプログラムの処理の進捗を算出し、その進捗状態を表示する方法は既に知られている。

例えば、特許文献１には、Ｗｅｂブラウザなどでの処理の進捗を表示する目的で、ＵＲＬアドレス欄を進捗バーとしても利用する方法などが開示されている。開示されている実施形態では、Ｗｅｂページ読み込み処理を例としており、表示方法は、背景色が進捗経過と共に右側に広がっていくものを開示している。また、完全な進捗を把握できなくても予測した「完了時間」をもとに、進捗バーを推移させる工夫をしている。

しかし、従来の技術は、単一プログラムの処理の進捗を把握、表示するのみであり、複数のプログラムにより行われる処理の進捗を把握することは難しかった。特に、情報処理装置の外部にある外部プログラムの進捗を管理することはできない。

例えば、プログラムＡとプログラムＢの複数のプログラムによるマルチタスクで一連の処理が実行される場合、プログラムＡが自身において実行する処理の進捗が把握されていたとしても、そこで使用したツールをプログラムＢにも適用し、プログラムＢにおける処理の進捗を把握する、といったことはできなかった。

ここで、プログラムＢも独自に進捗を把握するツールを備えていれば、各プログラムにおける処理の進捗を把握することはできるが、これはあくまで各自のプログラムにおける処理の進捗であって、一連の処理における進捗率の管理となるとできなかった。

よって、従来の進捗を把握、管理する進捗管理ツールは、単一のプログラムに専用のツールであり汎用性に欠けるという問題があった。

本発明は、上記実情に鑑みてなされたものであって、汎用性を持った、処理の進捗管理ツールを提供することを目的とする。

上記目的を達成するための本発明の装置は、プログラムに実行させるタスクの種類毎に、タスクの進捗状況を把握するための情報を記憶するタスク情報記憶部と、前記タスクの進捗状況を把握するための情報に基づいて、タスクを実行するプログラムが出力する出力結果とは異なる副次的な情報出力から、タスクの進捗状況を把握するタスク管理部と、を備えることを特徴とする。

本発明によれば、汎用性を持った、処理の進捗管理ツールを提供することが可能となる。

本発明の実施形態のネットワーク構成を示すブロック図である。 上記実施形態の配信サーバ１００のハードウェア構成を示す図である。 上記実施形態の配信サーバ１００の機能構成を示すブロック図である。 上記実施形態におけるワークフローの概念を説明するための図である。 上記実施形態におけるタスクの設定情報を説明するための図である。 上記実施形態における進捗管理処理のフローを示す図である。 上記実施形態の複合機１０６に出力する表示画面の一例を示す図である。

以下に説明する実施形態は、実行中のソフトウェアプログラムの進捗を、そのプログラムの出力やログの量などに基づいて把握することに特徴がある。そのため、進捗表示や通知の機能を有しない既存のソフトウェアプログラムを利用する場合であっても進捗表示できる。また、予測時間ではなくログの内容などに基づいて進捗率に基づいた進捗表示できる。

＜ネットワーク構成＞
図１は、実施の形態にかかるネットワーク配信システムのネットワーク構成を示す説明図である。本実施の形態にかかるネットワーク配信システムは、図１に示すように、ネットワーク１０４に接続された配信サーバ１００と、ネットワーク１０４に接続されたファイルサーバ１０１と、ＥＤＭＳ（Enterprise Document Management System）１０２と、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ１０３と、配信サーバ１００と、ＬＡＮまたはインターネット等のネットワーク１０５に接続された複合機１０６と携帯情報端末１０７とを主に備えている。

複合機１０６は、スキャン機能、コピー機能、プリンタ機能、ファクシミリ機能などを一つの筐体に搭載したものである。この複合機１０６は、スキャナ機能により紙媒体等をスキャン処理して画像データを生成し、生成された画像データを配信サーバ１００に送信する。

配信サーバ１００は、複合機１０６でスキャンされた画像データを受信して、後述するフロー定義データに従って種種の処理や配信処理を実行するワークステーション等のコンピュータである。

携帯情報端末１０７は、配信サーバ１００での情報処理の進捗状況を確認するための一手段であり、例えば、スマートフォンが一実施例である。複合機１０６が有する液晶表示装置なども進捗状況の確認のための手段としてよい。

ファイルサーバ１０１は、ネットワーク１０４上で共有するファイルを蓄積して管理するコンピュータであり、ＥＤＭＳ１０２は、いわゆる文書管理システムであり、ＳＭＴＰサーバ１０３は、メール送信プロトコルであるＳＭＴＰに準拠した電子メールの送信するためのサーバである。ファイルサーバ１０１、ＥＤＭＳ１０２，ＳＭＴＰ１０３のいずれも配信サーバ１００による配信処理によりアクセスされる。

＜配信サーバ＞
図２に、配信サーバ１００のハードウェア構成例を示す。図２に示すように、配信サーバ１００は、一般的なサーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等の情報処理端末と同様の構成を有する。即ち、配信サーバ１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）４０及びＩ／Ｆ５０がバス８０を介して接続されている。また、Ｉ／Ｆ５０にはＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）６０及び操作部７０が接続されている。

ＣＰＵ１０は演算手段であり、会議出欠管理サーバ２全体の動作を制御する。ＲＡＭ２０は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、ＣＰＵ１０が情報を処理する際の作業領域として用いられる。ＲＯＭ３０は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。ＨＤＤ４０は、情報の読み書きが可能な不揮発性の記憶媒体であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や各種の制御プログラム、アプリケーション・プログラム等が格納される。

Ｉ／Ｆ５０は、バス８０と各種のハードウェアやネットワーク等を接続し制御する。ＬＣＤ６０は、ユーザが会議出欠管理サーバ２の状態を確認するための視覚的ユーザインタフェースである。操作部７０は、キーボードやマウス等、ユーザが会議出欠管理サーバ２に情報を入力するためのユーザインタフェースである。なお、図１において説明したように、配信サーバ１００は、サーバとして運用される。したがって、ＬＣＤ６０及び操作部７０等のユーザインタフェースは省略可能である。

このようなハードウェア構成において、ＲＯＭ３０やＨＤＤ４０若しくは図示しない光学ディスク等の記憶媒体に格納されたプログラムがＲＡＭ２０に読み出され、ＣＰＵ１０の制御に従って動作することにより、ソフトウェア制御部が構成される。このようにして構成されたソフトウェア制御部と、ハードウェアとの組み合わせによって、以下に述べるような機能を実現する機能ブロックが構成される。

図３に、本発明の一実施形態である配信サーバ１００の機能構成を示す。
図示のように、配信サーバ１００では、進捗管理プログラム１１８及びタスクプログラム群１１７がいわゆるデーモンやサービスと呼ばれるような態様で実行されている。進捗管理プログラム１１８は、タスク情報記憶部１１０、検証部１１１、設定部１１２、タスク管理部１１３、表示制御部１１４、ワークフロー定義取得部１１５、処理要求制御部１１６とを有する。

ユーザが複合機１０６や携帯情報端末１０７から、何らかの処理要求（例えば、スキャンした画像データを電子書類化する処理など）を発行すると、配信サーバ１００の処理要求制御部１１６が処理要求（例えば、処理対象である画像データと、処理を指定するリクエスト情報とを含むデータ）を受信する。処理要求制御部１１６は、当該処理要求に必要なタスク及びプログラムをワークフロー定義取得部１１５に問い合わせる。

ワークフロー定義取得部１１５は、処理要求に応じて実行する処理が定義された情報であるワークフロー定義を取得し、処理要求制御部１１６に返す。ワークフローは、図４に示すように、処理要求毎に、実行するべきプログラムや、実行の順番などが定義されている。図４の例は、処理対象のデータに対して圧縮解凍処理を行い、圧縮解凍処理を行った次にＯＣＲ処理を行い、ＯＣＲ処理を行った次に画像変換処理を行う、という一連の処理と、処理対象のデータをメール配信するＥ−ｍａｉｌ配信処理を行う、という処理とを並列して行うワークフローを示している。

処理要求制御部１１６は、ワークフロー定義取得部１１５により取得されたワークフロー定義にしたがって、タスクプログラム群１１７から、各処理に対応するプログラムに処理の実行を要求することで処理要求に応じた処理を実行する。処理に対応するプログラムとは、図４の例で言えば、圧縮解凍処理、ＯＣＲ処理、画像変換処理、Ｅ−ｍａｉｌ配信処理のそれぞれを実行する各プログラムのことである。

なお、タスクプログラム群１１７は、配信サーバ１００が全て備えていなくてもよく、例えば、図１のファイルサーバ１０１、ＥＤＭＳ１０２，ＳＭＴＰ１０３などが提供するプログラムを利用してもよい。以下では、１つのプログラムにより実行される処理を、１つの処理単位として扱うときに、この処理単位を「タスク」と呼ぶ。

ここで、タスクは、一つでも処理を完結することが可能である。図４の例で言えば、例えばＯＣＲ処理は、ＯＣＲ処理単体だけを実行することができ、圧縮解凍処理と連携するか否かは適宜ユーザにより選択される。つまり、ユーザはタスク単位でプログラムを選択して扱うことができる。

＜タスクの進捗状況の把握＞
本実施形態においては、処理要求制御部１１６が取得したワークフロー定義に基づいて各プログラムに処理の実行を要求するにあたり、ワークフロー定義に基づくタスクの一覧とタスク実行の順番を、タスク管理部１１３に通知する。

タスク管理部１１３は、タスクの一覧とタスク実行の順番を得て、一覧に含まれるタスクの設定情報をタスク情報記憶部１１０に問い合わせる。ここで言うタスクの設定情報は、タスクの進捗率をどのような基準で判定するかが定義された情報である。各タスクプログラムは、それぞれ進捗状況の出力の方式が違ったり、進捗状況として明示的に出力するものがなかったりするため、タスク情報記憶部１１０には、各タスクプログラムの進捗状況を把握するための設定情報がそれぞれ記憶される。

タスク管理部１１３は、各タスクの設定情報を取得し、検証部１１１に設定情報が更新されていないか問い合わせた上で、タスクプログラムが処理の実行に伴い出力する情報（ログ等）と設定情報とに基づいて、各タスクの進捗率を判断する。また、各タスクの進捗率とタスク実行との順番に基づいて、全体の進捗率について判断する。ここで言うタスクプログラムが処理の実行に伴い出力する情報とは、処理対象データに対する処理を実行する過程で出力される情報であり、情報の内容は、タスクプログラムに依存する。

タスク管理部１１３は、各タスクに対応する設定情報から、対応するタスクプログラムが出力する情報のうち、進捗率の判断のためにどの情報を用いるかを特定する。そして、タスクプログラムが出力する情報から特定した情報（進捗率判断に使用する情報）を取得し、タスクの進捗率を判断する。

以下、タスク情報記憶部１１０に記憶されているタスクの設定情報について説明する。図５に、タスク情報記憶部１１０に記憶されているタスクの設定情報の例を示す。タスク情報記憶部１１０は、以下に述べるようなタスクの設定情報をタスクの数分記憶している。

図５の左側に、タスクの進捗率進捗状況を確認するためのタスクの設定情報の凡例を示す。右側には、その一例としてＺＩＰファイルの解凍を行うタスクの場合を示す。図示のように、各タスクの設定情報には、タスクの進捗率を判定する方法が含まれる。具体的に本実施形態では、以下の判定方法を含む。
１．ログファイルの行数
２．ログファイル内の文字列
３．画面の照合
４．画面のＯＣＲ結果の照合
５．外部プログラムで判定

また、各タスクの設定情報は、上記判定方法の詳細設定情報、特に、どのような値であれば何割の進捗率であると判定するための情報を含む。例えば、図５右側に示したＺＩＰファイルの解凍を行うタスクの場合であれば、ログファイルの行数で進捗率の判定を行うことが規定されており、実行完了したときの全ログの行数の期待値が「どのような値であれば何割の進捗率であると判定するための情報」として設定される。例えば、進捗の割合＝（出力されたログの行数）／（期待値）といった詳細設定情報が登録される。

タスクプログラムが処理の実行を開始してから完了するまでに全ログが最終的に１０００行出力される場合（つまり、期待値が１０００である場合）、４８３行ログが出力されれば、全体の１０００行における割合から４８．３％の進捗率と判断することができる。タスク管理部１１３は、設定情報に基づいてこの判断を行う。ログの数を見る方法は、１度のタスク処理において吐き出されるログの数が決まっているものに対して有効であり、タスクの実行において特定のログが何個吐き出されるか（出力されるか）の数を予め設定しておき、ログの数との割合で進捗率を表示する。

判定方法がログファイル内の文字列の場合、例えば、"unzip started"の文字列を発見したら５％の進捗率と判断し、"succeed"や"complete"などの文字列を発見したら１００％と判断するといった情報が、「どのような値であれば何割の進捗率であると判定するための情報」として設定されている。例えば、文字列と進捗率とが対応付いた詳細設定情報が登録される。

また、ログを吐かずに何割の処理を実行したかを示す画面を出力するプログラムもあり、その場合は、出力画面の画像を詳細設定情報に記憶しておき、画像同士を照合することによって進捗率を判定する（判定方法が画面の照合の場合）。この方法では、詳細設定情報として、このタスクプログラムが進捗率（当該タスクプログラムのみにおける処理の進捗率）を表示する表示画面の画面データを複数の進捗率のそれぞれに対して用意する。

また、画面のＯＣＲ結果の照合を判定方法とする場合は、表示画面において進捗率を表示している領域に対してＯＣＲ処理を行い、ＯＣＲ結果（表示されている進捗率）を取得する。詳細設定情報としては、表示画面のうちＯＣＲ処理を行う領域が登録される。

判定方法「外部プログラムで判定」とは、本発明のプログラムとは別のプログラムを利用する方法である。つまり、外部プログラムにおいて進捗が取得できるため、詳細設定情報としてこの外部プログラムが登録される。

本実施形態においては、進捗率の判定に加えて、さらに処理結果（処理の成否）を判定するための情報も記憶しておき、処理結果の判定に用いる（図５）。例えば、現在表示されている画面をＯＣＲして抽出される文字列と、事前登録された文字列が一致したらエラーとみなすという情報を、結果（成否）を判定する情報及びその詳細情報に、記憶する。

図６に、進捗管理プログラム１１８が実行する処理の流れを示す。図６のフローは、処理要求制御部１１６がユーザからの処理要求を受信したときに開始される。処理要求制御部１１６が処理要求を受信すると、ワークフロー定義取得部１１５が、処理要求に応じて実行する処理が定義された情報であるワークフロー定義を、配信サーバ１００ないし外部のサーバから取得する（Ｓ１０１）。

ワークフロー定義は処理要求制御部１１６に返され、ワークフロー定義に基づいてタスクプログラム群１１７を利用した処理の実行が行われるが、その一方でタスク管理部１１３もワークフロー定義に基づいて、処理実行されるタスクプログラムおのおのに対応する設定情報をタスク情報記憶部から取得する（Ｓ１０２）。

Ｓ１０２の処理は、例えば、ワークフロー定義が図４に示したようなものであったとすると、「圧縮解凍」タスクプログラムと、「ＯＣＲ」タスクプログラムと、「画像変換」タスクプログラムと、「電子メール配信」タスクプログラム、４つのプログラムそれぞれの設定情報を、取得する処理となる。

次に、タスク管理部１１３は、タスクプログラム群１１７が処理要求制御部１１６に逐次出力する情報（処理の実行に伴い出力する情報（ログ等））を、取得する（Ｓ１０３）。

Ｓ１０３の処理で取得する情報は、タスクプログラム毎に異なる。タスク管理部１１３は、図５に示した各タスクの設定情報に基づいて、ログ行数を判断材料とする場合はログ行数を、表示画面を判断材料とする場合は表示画面を、処理要求制御部１１６から取得する。

次に、タスク管理部１１３は、Ｓ１０３で取得した判断材料情報に基づいて、各タスクの進捗率を推定ないし判断する（Ｓ１０４）。例えば、ログファイルの行数で判断する場合は、進捗の割合＝（出力されたログの行数）／（期待値）のような判断基準を用いて、進捗率を判断する。

さらに、タスク管理部１１３は、Ｓ１０４で判断した各タスクの進捗率と、ワークフロー定義から得られるタスク実行の順番とに基づいて、ワークフロー全体の進捗率について判断する（Ｓ１０５）。

ただし、Ｓ１０５で言う「ワークフロー全体」は、直列に行われる一連のタスクであることとする。例えば、ワークフロー定義が図４に示したようなものであったとすると、直列に並ぶ「圧縮解凍」、「ＯＣＲ」、「画像変換」からなるタスクグループを「ワークフロー全体」として、このタスクグループの進捗率を判断する。並列に行われるタスクである「電子メール配信」については、前記タスクグループとは別に進捗率を判断する。

なお、ワークフロー全体の進捗率を判断する際に、各タスクを同じ重みで扱ってもよいし、処理の計算量に応じて重みを付けてもよい。前者は例えば、「圧縮解凍」が完了すると全体としては１／３が終わったと判断するものである。後者は例えば、「圧縮解凍」には他のタスクに比べて２倍の時間がかかるととして、「圧縮解凍」が完了すると全体としては１／２が終わったと判断するものである。

＜タスクの進捗状況の表示出力＞
タスク管理部１１３は、上述のようにして各タスクの進捗率を把握し、これに基づいて表示制御手段が進捗率を表示出力する。表示出力先は、ユーザの側にある複合機１０６や携帯情報端末１０７である。またあるいは、配信サーバ１００のディスプレイであるＬＣＤ６０であってもよい。図７に、複合機１０６に出力する表示画面の一例を示す。図７は、処理実行が「全自動インストール」である場合の例を示している。

図７に示すように、タスク管理部１１３が判定した判定し把握した進捗率に基づいて、各タスクの進捗状況がビジュアライズされる。並列して実行しているタスクがあれば並べて表示してもよく、また、処理要求全体の進捗率を示すことも好ましい。

また、表示制御部１１４は、複合機１０６に進捗率表示をする場合、二次元バーコードを生成して表示する。ユーザは、携帯情報端末１０７で二次元バーコードを読み取ることで処理要求の進捗率を表示する一時的なＷｅｂページにアクセスすることができる。

＜タスク定義の設定及び検証＞
配信サーバ１００の管理者は、図３の設定部１１２を用いて、図５に示したタスクの設定情報を編集したり、新たなタスクの設定情報を追加したりすることができる。タスクの設定情報は、バージョン情報を持っている（図５参照）。検証部１１１は、外部のレポジトリなどを参照して、タスクの設定情報のバージョンが最新であるか否かを検証する。タスクの進捗状況の把握の前に、検証部１１１が検証を行うことで、正確な進捗状況把握が可能になる。

＜変形実施例＞
以上で述べたように、本実施形態の配信サーバ１００は、汎用的な進捗状況把握の構成を備える。すなわち、タスクを実行するプログラムごとに進捗状況を提示する方式が違っていたり、そのような仕組みが備わっていないプログラムであっても、各プログラムが処理実行にあたり副次的に出力する情報に基づいて進捗状況を判定するため、各プログラムの進捗状況を把握することができ、またそれを表示することができる。

また、汎用的な進捗状況把握の構成は、配信サーバへの適用だけでなく、他のサーバ／パソコン／タブレット端末／複合機などの電子機器への適用も可能である。その場合、ひとつもしくは複数のタスクにより実行されるワークフローを登録することで、さまざまな条件でタスクを実行できる。

なお、上記実施形態においては、タスクとして、従来から電子機器に存在する既存のプログラムを想定している。例えば、ＺＩＰファイルを解凍するｕｎｚｉｐコマンドプログラム、ネットからファイルをダウンロードするｗｇｅｔフリーソフトなど、従来から実行可能なすべてのプログラムを含む。オペレーティングシステムに標準で入っているプログラムや、フリーソフト、有償のソフトなども含む。しかし、これら既存プログラムに限定されず、新しいプログラムを追加する場合であっても上記実施形態同様の効果がもたらされる。

１００ 配信サーバ
１０１ ファイルサーバ
１０２ ＥＤＭＳ（Enterprise Document Management System）
１０３ ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ
１０４，１０５ ネットワーク
１０６ 複合機
１０７ 携帯情報端末
１１０ タスク情報記憶部
１１１ 検証部
１１２ 設定部
１１３ タスク管理部
１１４ 表示制御部
１１５ ワークフロー定義取得部
１１６ 処理要求制御部
１１７ タスクプログラム群
１１８ 進捗管理プログラム

特開２０１３−１８６９０７号公報

Claims (10)

1. プログラムに実行させるタスクの種類毎に、タスクの進捗状況を把握するための情報を記憶するタスク情報記憶部と、
   前記タスクの進捗状況を把握するための情報に基づいて、タスクを実行するプログラムが出力する出力結果とは異なる副次的な情報出力から、タスクの進捗状況を把握するタスク管理部と、
   を備えることを特徴とする、タスク管理装置。
2. 前記副次的な情報出力は、プログラムが出力するログである場合を含むことを特徴とする、請求項１に記載のタスク管理装置。
3. 前記タスクの進捗状況を把握するための情報が、前記ログの期待される出力行数であり、
   前記タスク管理部は、前記ログの行数と、前記期待される出力行数とに基づいて、タスクの進捗状況を把握する
   ことを特徴とする、請求項２に記載のタスク管理装置。
4. 前記タスクの進捗状況を把握するための情報が、前記ログにおいて出力が期待される文字列であり、
   前記タスク管理部は、前記ログにおいて出現した文字列と、前記期待される文字列とに基づいて、タスクの進捗状況を把握する
   ことを特徴とする、請求項２に記載のタスク管理装置。
5. 前記副次的な情報出力は、プログラムが出力する画面である場合を含むことを特徴とする、請求項１から４のいずれか１項に記載のタスク管理装置。
6. 前記タスクの進捗状況を把握するための情報が、出力が期待される画面であり、
   前記タスク管理部は、プログラムが出力した画面と、出力が期待される画面とを照合することで、タスクの進捗状況を把握する
   ことを特徴とする、請求項５に記載のタスク管理装置。
7. 前記タスクの進捗状況を把握するための情報が、出力が期待される画面に表示される文字列であり、
   前記タスク管理部は、プログラムが出力した画面から文字を読み取って得られるテキストの中に、前記文字列が含まれるか否かを判定することによって、タスクの進捗状況を把握する
   ことを特徴とする、請求項５に記載のタスク管理装置。
8. 前記タスク管理部が把握したタスクの進捗状況を表示する表示制御部を有することを特徴とする、請求項１から７のいずれか１項に記載のタスク管理装置。
9. プログラムに実行させるタスクの種類毎に、タスクの進捗状況を把握するための情報を記憶するコンピュータが、
   前記タスクの進捗状況を把握するための情報に基づいて、タスクを実行するプログラムが出力する出力結果とは異なる副次的な情報出力から、タスクの進捗状況を把握する
   タスク管理工程を含むことを特徴とする、タスク管理方法。
10. プログラムに実行させるタスクの種類毎に、タスクの進捗状況を把握するための情報を記憶するコンピュータに、
    前記タスクの進捗状況を把握するための情報に基づいて、タスクを実行するプログラムが出力する出力結果とは異なる副次的な情報出力から、タスクの進捗状況を把握する
    タスク管理処理を実行させることを特徴とする、タスク管理プログラム。

Images