JP5786041B2 - 業務支援装置、業務支援方法及び業務支援プログラム - Google Patents

Description

本発明は、業務支援装置、業務支援方法及び業務支援プログラムに関する。

プラント、製品等の設計においては、どのような設計業務をどのような順番で行うか、又は、個々の設計業務がどのような階層関係にあるかを示す雛形的なチャートである「標準業務プロセス」を作成することが一般的である。そして、実際の設計業務に入る前に、又は、実際の設計業務に入った後設計変更が生じた場合等に、設計者であるユーザは、当該「標準業務プロセス」を構成する個々の「タスク」の変更、入れ換え、削除等を行い、当該案件において要求される仕様に合致した固有の業務プロセスを作成（カスタマイズ）する。
特許文献１においては、業務支援システムが、要求仕様と雛形との差異を抽出し、抽出された差異に基づいて、タスクを抽出し、抽出されたタスクに基づいて、最終的な業務プロセスを作成する。
特許文献２においては、業務支援装置が、予め「標準業務プロセス」を用意し、当該「標準業務プロセス」に対して個々のユーザが行った変更内容をユーザ全体で共有する。

特開２００９−１０４５６２号公報（段落０００７） 特開２００５−１０８１４２号公報（段落０００６）

特許文献１のシステムでは、予め設定しておいたルールに基づいてタスクを切り替える。しかしながら、切り替えの判断は属人化されておりルール化されていない。したがって、案件ごとの最適な業務プロセスをユーザに提示することはできない。
特許文献２の業務支援装置では、１つの標準業務プロセスを基準にしている。そのため、要求される仕様に合わせてカスタマイズする場合に、又は、設計変更の場合に、標準業務プロセスを構成する個々のタスクのすべてを検討することが必要である。その結果、要求される仕様又は設計変更の影響を受けることがない、検討を省略してもよいタスクについても検討するようにユーザを誘導することになり、カスタマイズされた業務プロセスを完成させるのに時間を要した。
そこで、本発明は、標準業務プロセスの中の特定のタスクを省略した場合の悪影響度を提示し、省略可能なタスクを特定することなどを容易にすることを目的とする。

本発明の業務支援装置は、業務プロセスを構成する複数のタスクのそれぞれが、業務プロセスに従って実行される案件に対して及ぼす影響を算出する業務支援装置であって、過去の案件に関連付けて、タスクと、実行された案件においてタスクが省略されたか否かを示す有無値と、過去の案件に対する事後の評価を示す値である評価値と、が記憶される第１のデータベースと、過去の案件に関連付けて、過去の案件に対して要求された仕様が記憶される第２のデータベースと、が格納される記憶部と、新たな案件について要求される仕様を受け付け、受け付けた仕様に基づいて、第２のデータベースを検索し、仕様が所定の基準を満たす程度に類似する過去の案件を取得し、取得した案件についてのレコードを第１のデータベースから抽出し、抽出したレコードについて、有無値に対して乗じられる係数を悪影響度とし、抽出したレコードのタスクごとに、有無値に悪影響度を乗じた値の総和を算出し、算出した総和と評価値との差分を算出することによって、取得した案件について最適化された悪影響度をタスクごとに算出し、算出した悪影響度と所定の閾値との大小関係を比較し、比較に基づいて特定された悪影響度に対応するタスクを、新たな案件において省略可能であるタスクとして出力する制御部と、を有することを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、標準業務プロセスの中の特定のタスクを省略した場合の悪影響度を提示し、省略可能なタスクを特定することなどを容易にすることが可能になる。

第１及び第２の実施形態に係る標準業務プロセス表示画面の一例である。 第１の実施形態に係る設計業務支援装置の構成図である。 第１の実施形態に係る根拠データベースの一例を示す図である。 第１の実施形態に係る要求仕様データベースの一例を示す図である。 （ａ）は、第１及び第２の実施形態に係る案件最終結果データベースの一例を示す図である。（ｂ）は、第１及び第２の実施形態に係る悪影響度データベースの一例を示す図である。 第１の実施形態に係る根拠登録処理手順のフローチャートである。 第１の実施形態に係る案件最終結果入力処理手順のフローチャートである。 第１の実施形態に係る要求仕様登録処理手順のフローチャートである。 第１の実施形態に係るタスク省略誘導処理手順のフローチャートである。 第１の実施形態に係る根拠登録画面の一例である。 第１及び第２の実施形態に係る案件最終結果入力画面の一例である。 第１の実施形態に係る要求仕様登録画面の一例である。 第１の実施形態に係るタスク検討要否判断・根拠表示画面の一例である。 第１及び第２の実施形態に係る標準業務プロセス表示画面の一例である。 第１及び第２の実施形態に係る標準業務プロセス表示画面の一例である。 第２の実施形態に係る設計業務支援装置の構成図である。 第２の実施形態に係る見直し根拠データベースの一例を示す図である。 第２の実施形態に係る仕様変更データベースの一例を示す図である。 第２の実施形態に係る見直し根拠登録処理手順のフローチャートである。 第２の実施形態に係る案件最終結果入力処理手順のフローチャートである。 第２の実施形態に係る仕様変更登録処理手順のフローチャートである。 第２の実施形態に係るタスク見直し誘導処理手順のフローチャートである。 第２の実施形態に係る見直し根拠登録画面の一例である。 第２の実施形態に係る仕様変更登録画面の一例である。 第２の実施形態に係る見直しタスク・根拠表示画面の一例である。

以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。本実施形態は、第１の実施形態及び第２の実施形態を含む。請求項の業務支援装置は、設計業務に限らずおよそ業務プロセスに従う業務全般について適用可能である。以降では、業務支援装置の一例としての、設計業務支援装置を説明する。設計業務支援装置は、第１の実施形態においては、省略することができるタスクの候補を示し、第２の実施形態においては、見直すべきタスクの候補を示す（詳細後記）。まず、第１の実施形態を詳しく説明し、その後、第２の実施形態について、第１の実施形態との相違点を中心に説明する。

＜第１の実施形態＞
（用語等）
案件とは、受注及び評価の対象となる業務の単位である。
タスクとは、案件を構成する単位である。タスクは、通常階層化されており、上位のタスク及び下位のタスクが存在する。ユーザは、このタスクを単位として、案件の一部を省略（一部のタスクを省略）することが可能である。そして、悪影響度（詳細後記）は、タスクごとに算出される。

業務プロセスとは、案件を構成する１又は複数のタスクを、タスクの階層関係及びタスクが実行される順番とともに示したデータである。業務プロセスは、通常、フローチャートに類似した形状で、出力装置等に対して表示可能である。
標準業務プロセスとは、雛形となる業務プロセスである。例えば、ユーザが互いに類似した案件を実行する場合、１つの標準業務プロセスをもとにして、その一部であるタスクを変更、省略等することによって、派生的なカスタマイズされた業務プロセスを容易に作成することができる。

根拠とは、あるタスクを検討することを省略すること、すなわち、業務プロセスからあるタスクを省略することを正当化する理由である。
悪影響度とは、あるタスクを検討することを省略する場合、当該省略が、案件の成否にどれだけの影響を及ぼすかを示す指標である。

図１を参照すると、標準業務プロセス表示画面５１のなかに、標準業務プロセス３１が表示されている。標準業務プロセス３１は、標準業務プロセス名称１０１、タスク１０２〜１０４、説明欄１０８を有する。タスク１０２〜１０４のそれぞれが、１又は複数の（下位の）タスクを有する。ここでは、（上位の）タスク１０４の下位にあるタスク１０５〜１０７のみを表記した。

当該標準業務プロセス３１は、空調設備の設計に関するものであり、当該標準業務プロセス３１の標準業務プロセス名称は「設備設計」である。「概略容量の把握」、「冷房能力の計算」及び「熱源システムの検討」は、それぞれタスク１０２〜１０４の名称である。そして、これらのタスクは、「概略容量の把握」→「冷房能力の計算」→「熱源システムの検討」の順番で実行される。「空冷・水冷パッケージ」、「鋳鉄ボイラ」及び「開放型ターボ冷凍機」は、それぞれタスク１０５〜１０７の名称である。そして、これらのタスクは、タスク「熱源システム検討」を実行する際に、原則、「空冷・水冷パッケージ」→「鋳鉄ボイラ」→「開放型ターボ冷凍機」の順番で、ユーザによって検討される。しかしながら、個々のタスクは必ず検討すべきものではなく、検討を省略することが可能である。

説明欄１０８は、各タスクの詳細説明であり、例えば、ユーザがマウス等の入力装置を使用してタスク１０２にカーソルを合わせると、「概略容量の把握」とは具体的にどのようなタスクであるのかを説明する文言が説明欄１０８に表示される。

（設計業務支援装置）
図２に沿って、設計業務支援装置１を説明する。設計業務支援装置１は、一般的なコンピュータであり、中央制御装置１１、キーボード、マウスなどの入力装置１２、ディスプレイなどの出力装置１３、主記憶装置１４及び補助記憶装置１５を有する。これらはバスによって相互に接続されている。補助記憶装置１５は、標準業務プロセス３１、根拠データベース３２、要求仕様データベース３３、案件最終結果データベース３４及び悪影響度データベース３５を記憶している（詳細後記）。主記憶装置１４における、標準業務プロセス誘導部２１、根拠登録部２２、案件成否入力部２３、タスク省略誘導部２４及び悪影響度フィードバック部２５は、プログラムである。以降、「○○部は」と主体を記した場合は、中央制御装置１１が、補助記憶装置１５から各プログラムを読み出し、主記憶装置１４にロードしたうえで、各プログラムの機能を実現するものとする（詳細後記）。
なお、「第１のデータベース」及び「第２のデータベース」には、それぞれ、「案件最終結果データベース３４」及び「要求仕様データベース３３」が相当する。

（根拠データベース）
図３に沿って、根拠データベース３２を説明する。根拠データベース３２においては、根拠ＩＤ欄２０１に記憶された根拠ＩＤに関連付けて、根拠欄２０２には根拠が、タスクＩＤ欄２０３にはタスクＩＤが、タスク名欄２０４にはタスク名が、適用案件欄２０５には案件ＩＤが、案件最終結果平均値欄２０６には案件最終結果平均値が記憶されている。

根拠ＩＤ欄２０１の根拠ＩＤは、根拠を一意に特定する識別子である。
根拠欄２０２の根拠は、根拠の文言そのものである。
タスクＩＤ欄２０３のタスクＩＤは、タスクを一意に特定する識別子である。
タスク名欄２０４のタスク名は、タスクの名称である。
適用案件欄２０５の案件ＩＤは、案件を一意に特定する識別子である。ここでは、当該根拠を適用することによって当該タスクが省略された実績を有する１又は複数の案件（適用案件）を特定している。
案件最終結果平均値欄２０６の案件最終結果平均値は、適用案件のそれぞれについて定義される案件最終結果値（詳細後記）の平均値である。
なお、「評価値」には、「案件最終結果値」が相当する。
根拠データベース３２のレコードは、根拠ＩＤとタスクＩＤとの組合せの数だけ存在する。

因みに、図３の１行目のレコードを参照すると以下のことがらがわかる。
（１）「熱源タイプが温熱源であるため」という根拠を適用することによって、タスク「空冷・水冷パッケージ」を検討することが省略された案件は、少なくとも２つある。１つは、案件「Ｐ００１」であり、もう１つは、案件「Ｐ００２」である。
（２）「熱源タイプが温熱源であるため」という根拠を適用することによって、タスク「空冷・水冷パッケージ」を検討することが省略された案件の１つ１つについて案件最終結果値が定義され、それらの平均値は「０.８０」である。

（要求仕様データベース）
図４に沿って、要求仕様データベース３３を説明する。要求仕様データベース３３においては、案件ＩＤ欄２１１に記憶された案件ＩＤに関連付けて、案件名欄２１２には案件名が、項目欄２１３には項目を見出しとして有する小欄２１３ａ〜２１３ｃが記憶されている。
案件ＩＤ欄２１１の案件ＩＤは、案件を一意に特定する識別子である。
案件名欄２１２の案件名は、案件の名称である。
項目欄２１３を構成する小欄２１３ａ〜２１３ｃの見出しである項目は、案件に対して要求される仕様のカテゴリである。ここでは、項目として「熱源タイプ」、「電源タイプ」及び「制御タイプ」を例として記載した。小欄２１３ａ〜２１３ｃに記憶されている項目の値は、それぞれの項目について要求される仕様そのものである。
要求仕様データベース３３のレコードは、案件ＩＤの数だけ存在する。

因みに、図４の１行目のレコードを参照すると以下のことがらがわかる。
（１）案件ＩＤが「Ｐ００１」である案件の名称は「案件Ａ」である。
（２）当該案件の仕様について３つの要求がある。それらは、「熱源タイプ」は「温熱源」であること、「電源タイプ」は「一般商用電源」であること、及び、「制御タイプ」は「遠隔制御」であることである。

（案件最終結果データベース）
図５（ａ）に沿って、案件最終結果データベース３４を説明する。案件最終結果データベース３４においては、案件ＩＤ欄２２１に記憶された案件ＩＤに関連付けて、案件名欄２２２には案件名が、有無値欄２２３にはタスクＩＤを見出しとして有する小欄２２３ａ〜２２３ｄが、案件最終結果値欄２２４には案件最終結果値が、根拠欄２２５にはタスクＩＤを見出しとして有する小欄２２５ａ〜２２５ｄが記憶されている。

案件ＩＤ欄２２１の案件ＩＤは、図４の案件ＩＤと同じである。
案件名欄２２２の案件名は、図４の案件名と同じである。
有無値欄２２３を構成する小欄２２３ａ〜２２３ｄの見出しであるタスクＩＤは、図３のタスクＩＤと同じである。小欄２２３ａ〜２２３ｄに記憶されている値は、「０」又は「１」の何れかである。「０」は、そのタスクＩＤが特定するタスクが検討されたことを示す。「１」は、そのタスクＩＤが特定するタスクが検討されずに省略されたことを示す。なお、「１」及び「０」を以降で「有無値」と呼ぶことがある。
案件最終結果値欄２２４の案件最終結果値は、「ある案件の仕損費／その案件の受注金額」／「すべての案件の（仕損費／受注金額）の値のうちの最大値」の計算式によって、案件ごとに定義される値である（詳細後記）。案件最終結果値が大きいほど、案件としての成績が悪い。
なお、図５（ａ）の案件最終結果値欄２２４には、（ ）を付した案件最終結果値及び（ ）を付さない案件最終結果値が併記されている。（ ）を付した案件最終結果値は、専ら、後記する第２の実施形態についての説明用のものであるので、ここでは無視する。

根拠欄２２５を構成する小欄２２５ａ〜２２５ｄの見出しであるタスクＩＤは、図３のタスクＩＤと同じである。小欄２２５ａ〜２２５ｄに記憶されている値は、根拠ＩＤそのものである。ここでは、根拠ＩＤは、タスクを検討せずに省略する際に適用された根拠を特定する。なお、有無値欄２２３のうち有無値が「１」である小欄の見出しのタスクＩＤを見出しに有する根拠欄２２５の小欄に、根拠ＩＤが記憶される。有無値欄２２３のうち有無値が「０」である小欄の見出しのタスクＩＤを見出しに有する根拠欄２２５の小欄は、空欄のままである。
案件最終結果データベース３４のレコードは、案件ＩＤの数だけ存在する。

因みに、図５（ａ）の１〜６行目のレコードを参照すると、例えば以下のことがらがわかる。なお、図５（ａ）において例示した根拠ＩＤ等の具体的な番号は、専ら図５（ａ）の説明のために選定されており、図３における根拠ＩＤ等の具体的な番号と符号しているものではない。
（１）終了し、評価がなされている案件が少なくとも６つ存在する。
（２）これらの６つの案件のすべてについて、少なくとも１つのタスクが検討されずに省略されている。つまり、すべてのレコードは、有無値欄２２３に少なくとも１つの有無値「１」を有する。
（３）これらの６つの案件のうち、案件最終結果値が最大である（案件としての成績が悪い）のは、「案件Ｂ」である。「案件Ｂ」では、タスクＩＤ「Ｔ００２」及び「Ｔ００４」が特定する２つのタスクが検討されずに省略されている。前者のタスクを省略した際に適用された根拠の根拠ＩＤは「Ｒ０２３」であり、後者のタスクを省略した際に適用された根拠の根拠ＩＤは「Ｒ０４１」である。

（４）１つのタスクを省略し、案件最終結果値を最小にする（案件としての成績を最もよくする）ためには、「Ｔ００３」を省略するべきである。１、３及び５行目を比較すると、「Ｔ００３」が省略されている３行目の案件最終結果値が最小であることから、このことが理解できる。
（５）２つのタスクを省略し、案件最終結果値を最小にするためには、「Ｔ００３」及び「Ｔ００４」を省略するべきである。２、４及び６行目を比較すると、「Ｔ００３」及び「Ｔ００４」が省略されている６行目の案件最終結果値が最小であることから、このことが理解できる。
（６）２つのタスクを省略した結果、１つのタスクを省略するよりも案件最終結果値が小さくなるのであれば、当然２つのタスクを省略する。しかしながら、図５（ａ）を参照する限りそのような事実はない。

（悪影響度データベース）
図５（ｂ）に沿って、悪影響度データベース３５を説明する。今、以下のような最小二乗法を使用した学習処理を考える。
（１）案件ｎ（ｎ＝Ａ、Ｂ、・・・）についての、タスクＩＤ「Ｔ００１」、「Ｔ００２」、・・・の有無値をＸ_ｎ１、Ｘ_ｎ２、・・・とする。Ｘ_ｎ１、Ｘ_ｎ２、・・・は、「０」または「１」の何れかである。
（２）Ｘ_ｎ１、Ｘ_ｎ２、・・・に対して乗じられる係数を、Ｗ_１、Ｗ_２、・・・とする。なお、添字の１、２、・・・は、タスクＩＤに由来する。
（３）案件ｎについての案件最終結果推定値（Ｐ_ｎ）を次のように定義する。
案件最終結果推定値（Ｐ_ｎ）＝Ｗ_１Ｘ_ｎ１＋Ｗ_２Ｘ_ｎ２＋・・・
（４）Ｗ_１、Ｗ_２、・・・のそれぞれに適当な初期値（例えば「０.５」）を代入する。
（５）すべての案件ｎについて、Ｐ_ｎを算出する。
（６）案件ｎについての案件最終結果値（図５（ａ）欄２２４）をＱ_ｎとする。なお、Ｑ_ｎは実績値（案件に対する事後の評価を示す値）である。
（７）（Ｐ_Ａ−Ｑ_Ａ）^２＋（Ｐ_Ｂ−Ｑ_Ｂ）^２＋・・・を算出する。
（８）Ｗ_１、Ｗ_２、・・・の値を所定の方法で僅かに変化させて、（５）〜（７）の処理を所定の回数だけ繰り返す。例えば、Ｗ_１、Ｗ_２、・・・の値を、それぞれ独立に、０〜１の範囲で無作為に変化させてもよい。
（９）（Ｐ_Ａ−Ｑ_Ａ）^２＋（Ｐ_Ｂ−Ｑ_Ｂ）^２＋・・・の値が最小になるような、Ｗ_１、Ｗ_２、・・・の値の組合せを取得する。

このようにして取得されたＷ_１、Ｗ_２、・・・の値を、タスク「Ｔ００１」の悪影響度、タスク「Ｔ００２」の悪影響度、・・・と呼ぶ。図５（ｂ）においては、このような悪影響度が、タスクＩＤに関連付けて記憶されている（欄２３１〜２３４）。

（処理手順の概略）
以降において、処理手順を説明する。処理手順には、（１）根拠登録処理手順、（２）案件最終結果入力処理手順、（３）要求仕様登録処理手順及び（４）タスク省略誘導処理手順の４つがある。これらは、通常、（１）→（２）→（３）→（４）の順番で実行される。それぞれの手順の内容は、フローチャート及び画面例に沿って詳しく後記するが、まず、それぞれの手順の概略を説明する。なお、通常、（１）、（２）及び（３）の手順は、システム管理者により実行され、（４）の手順は、システム利用者によって実行される。すなわち、（１）、（２）及び（３）の手順は、（４）の手順を基準にすればその「事前」に実行される。

（１）根拠登録処理手順は、標準業務プロセス３１が完成していることを前提に、将来発生することになる個々の案件において、標準業務プロセス３１に含まれるタスクを省略する際に適用される根拠を登録するための手順である。根拠登録処理手順は、通常、標準業務プロセス３１が作成された時点で実行される。

（２）案件最終結果入力処理手順は、終了した過去の案件について、どの根拠を適用してどのタスクを省略した結果、案件最終結果値はどのようになったか、を示すデータを作成するための手順である。案件最終結果入力処理手順は、個々の案件が終了した時点で実行されてもよいし、ある時点で、その時点までに終了している複数の案件についてまとめて実行されてもよい。

（３）要求仕様登録処理手順は、終了した過去の案件の仕様を登録するための手順である。要求仕様登録処理手順は、個々の案件が終了した時点で実行されてもよいし、ある時点で、その時点までに終了している複数の案件についてまとめて実行されてもよい。
（４）タスク省略誘導処理手順は、新たな案件用にカスタマイズされた業務プロセスを作成するために、標準業務プロセス３１のタスクのうちから省略できるタスクを決定するための手順である。タスク省略誘導処理手順は、新たな案件が実行される直前に実行される。そして、タスク省略誘導処理手順の最初の段階において、（３）要求仕様登録処理手順と類似の手順が実行される。すなわち、新規案件について、要求された仕様が入力される。

（根拠登録処理手順）
図６に沿って、根拠登録処理手順を説明する。
ステップＳ３０１において、標準業務プロセス誘導部２１は、標準業務プロセス３１を表示する。具体的には、標準業務プロセス誘導部２１は、第１に、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、補助記憶装置１５から標準業務プロセス３１を取得する。
標準業務プロセス誘導部２１は、第２に、出力装置１３に標準業務プロセス表示画面５１（図１）を表示する。標準業務プロセス表示画面５１には、取得した標準業務プロセス３１が表示されるものとする。
ここでは、「設備設計」に関する標準業務プロセス３１が表示されることとした。しかしながら、複数の標準業務プロセス３１が補助記憶装置１５に記憶されており、ユーザは、そのうちから任意の標準業務プロセス３１を選択するようにしてもよい。

ステップＳ３０２において、根拠登録部２２は、タスクの指定を受け付ける。具体的には、根拠登録部２２は、ユーザが、表示されている標準業務プロセス３１のタスクのうちから、根拠を関連付けるべき任意の１つのタスクをマウス等の入力装置１２を介して指定するのを受け付ける。ここでは、「空冷・水冷パッケージ」１０５が指定されたとする。

ステップＳ３０３において、根拠登録部２２は、根拠登録画面５２（図１０）を表示する。具体的には、根拠登録部２２は、根拠登録画面５２（図１０）を出力装置１３に表示する。根拠登録部２２は、根拠登録画面５２の「タスク」欄１１１に、ステップＳ３０２において指定されたタスクの名称を表示するものとする。

ステップＳ３０４において、根拠登録部２２は、根拠の入力を受け付ける。具体的には、根拠登録部２２は、第１に、ユーザが、根拠登録画面５２の「タスクの検討が省略可能である根拠」欄１１２に、キーボード等の入力装置１２を介して、根拠を入力するのを受け付ける。
根拠登録部２２は、第２に、ユーザが登録ボタン１１３を押下するのを受け付ける。
なお、キャンセルボタン１１４（図１０、２３）については、入力された特定の文字列等をカーソル等で指定したうえで当該ボタンが押下された場合は、その文字列等が消去され、とくに指定がないまま当該ボタンが押下された場合は、当該画面が消去されるものとする。後記する、キャンセルボタン１２６（図１１）、キャンセルボタン１３６（図１２、２４）及びキャンセルボタン１４９（図１３、２５）についても同様である。

ステップＳ３０５において、根拠登録部２２は、根拠を登録する。具体的には、根拠登録部２２は、第１に、根拠データベース３２（図３）の新たなレコードを作成する。
根拠登録部２２は、第２に、新たなレコードの根拠欄２０２及びタスク名欄２０４に、それぞれ、ステップＳ３０４において受け付けた根拠及びステップＳ３０２において指定されたタスクの名称を記憶する。
根拠登録部２２は、第３に、新たなレコードの根拠ＩＤ欄２０１に、根拠ＩＤを採番したうえで記憶し、新たなレコードのタスクＩＤ欄２０３に、タスクＩＤを採番したうえで記憶する。根拠登録部２２は、標準業務プロセス３１の各タスクを特定するタスクＩＤを予め準備しておいてもよい。
なお、新たなレコードの適用条件欄２０５及び案件最終結果平均値欄２０６は空欄のままとする。その後、根拠登録処理手順を終了する。

（案件最終結果入力処理手順）
図７に沿って、案件最終結果入力処理手順を説明する。
ステップＳ３２１において、案件成否入力部２３は、案件最終結果入力画面５３（図１１）を表示する。具体的には、案件成否入力部２３は、第１に、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、出力装置１３に、案件最終結果入力画面５３を表示する。入力のタイミングは、通常案件が終了した時点以降である。

ステップＳ３２２において、案件成否入力部２３は、案件名等を受け付ける。具体的には、案件成否入力部２３は、第１に、ユーザが、案件名欄１２１に案件名を、受注金額欄１２２に受注金額を、仕損費欄１２３に仕損費を入力するのを受け付ける。受注金額は、当該案件の対価として顧客等から受け取る報酬の金額である。仕損費は、仕損品（何らかのタスクを省略したことに起因して発生した不合格製品）の製造等に要したコストである。

案件成否入力部２３は、第２に、ユーザが、「タスク及び根拠」欄１２４に対して、当該案件において省略したタスクのタスクＩＤ及びそのタスクを省略した際に適用された根拠の根拠ＩＤを、相互に関連付けられた組合せとして入力するのを受け付ける。
案件成否入力部２３は、第３に、ユーザが、登録ボタン１２５を押下するのを受け付ける。案件成否入力部２３は、ステップＳ３２２の処理を、終了したすべての案件について繰り返す。

ステップＳ３２３において、案件成否入力部２３は、「仕損費／受注金額」の値を算出する。具体的には、案件成否入力部２３は、第１に、案件最終結果データベース３４（図５（ａ））の新たなレコードを、ステップＳ３２２の「第２」において受け付けた組合せの数だけ作成する。
案件成否入力部２３は、第２に、ステップＳ３２２の「第１」において受け付けた受注金額及び仕損費に基づいて、それぞれの案件についての、「仕損費／受注金額」の値を算出し、その値を主記憶装置１４に一時的に記憶する。案件成否入力部２３は、ステップＳ３２３の処理を、終了したすべての案件について繰り返す。

ステップＳ３２４において、案件成否入力部２３は、案件最終結果値等を登録する。具体的には、案件成否入力部２３は、第１に、案件最終結果データベース３４の新たなレコードのそれぞれについて、案件最終結果値を算出する。前記したように、案件最終結果値は、「ある案件の仕損費／その案件の受注金額」／「すべての案件の（仕損費／受注金額）の値のうちの最大値」として定義される。「すべての案件の（仕損費／受注金額）の値」は、ステップＳ３２３の「第２」において一時的に記憶した値を参照して取得する。

案件成否入力部２３は、第２に、新たなレコードの案件名欄２２２に、ステップＳ３２２の「第１」において受け付けた案件名を記憶し、案件ＩＤ欄２２１に、当該案件の案件ＩＤを記憶する。そして、案件最終結果値欄２２４に、ステップＳ３２４の「第１」において算出した案件最終結果値を記憶する。
案件成否入力部２３は、第３に、ステップＳ３２２の「第２」において受け付けたタスクＩＤを見出しとして有する根拠欄２２５の小欄に、ステップＳ３２２の「第２」において受け付けた根拠ＩＤを記憶する。そして、テップＳ３２２の「第２」において受け付けたタスクＩＤを見出しとして有する有無値欄２２３の小欄に、有無値「１」を記憶し、有無値欄２２３の他の小欄に、有無値「０」を記憶する。

ステップＳ３２５において、案件成否入力部２３は、根拠データベース３２（図３）を完成させる。具体的には、案件成否入力部２３は、第１に、根拠データベース３２の任意のレコードを１つ取得する。取得したレコードの適用案件欄２０５及び案件最終結果平均値欄２０６は空欄である。当該取得したレコードを、以降「対象レコード」と呼ぶことがある。

案件成否入力部２３は、第２に、対象レコードの根拠ＩＤ及びタスクＩＤを検索キーとして、案件最終結果データベース３４（図５（ａ））の根拠欄２２５を検索し、該当したレコードの案件ＩＤ及び案件最終結果値を取得する。通常、複数のレコードが該当する。そして、取得した案件最終結果値の平均値を算出する。
案件成否入力部２３は、第３に、対象レコードの案件最終結果平均値欄２０６に、算出した平均値を記憶し、対象レコードの適用案件欄２０５に、取得したすべての案件ＩＤを記憶する。
なお、ステップＳ３２５の処理は、すべての未処理の対象レコードについて繰り返す。その後、案件最終結果入力処理手順を終了する。

（要求仕様登録処理手順）
図８に沿って、要求仕様登録処理手順を説明する。
ステップＳ３４１において、標準業務プロセス誘導部２１は、要求仕様登録画面５４（図１２）を表示する。具体的には、標準業務プロセス誘導部２１は、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、出力装置１３に、要求仕様登録画面５４を表示する。

ステップＳ３４２において、標準業務プロセス誘導部２１は、案件名及び要求仕様を受け付ける。具体的には、標準業務プロセス誘導部２１は、第１に、ユーザが、要求仕様登録画面５４の案件名欄１３１に案件名を入力するのを受け付ける。
標準業務プロセス誘導部２１は、第２に、ユーザが、要求仕様登録画面５４の要求仕様欄１３２の項目欄１３３及び仕様欄１３４に、項目及び仕様を対応付けて入力するのを受け付ける。仕様については、標準業務プロセス誘導部２１が予め項目ごとに用意してある仕様の候補を表示し（図１２では、候補として「温熱源」及び「冷熱源」が表示されている）、ユーザがそのうちから１つを選択するのを受け付けてもよい。
標準業務プロセス誘導部２１は、第３に、ユーザが登録ボタン１３５を押下するのを受け付ける。

ステップＳ３４３において、標準業務プロセス誘導部２１は、要求仕様を登録する。具体的には、標準業務プロセス誘導部２１は、第１に、要求仕様データベース３３（図４）の新たなレコードを作成する。
標準業務プロセス誘導部２１は、第２に、新たなレコードの案件名欄２１２に、ステップＳ３４２の「第１」において受け付けた案件名を記憶し、新たなレコードの案件ＩＤ欄２１１に、案件ＩＤを採番したうえで記憶する。
標準業務プロセス誘導部２１は、第３に、ステップＳ３４２の「第２」において受け付けた仕様を、その仕様に対応する項目を見出しに有する、新たなレコードの項目欄２１３の小欄に記憶する。なお、ステップＳ３４２の「第２」において受け付けた仕様に対応する項目が存在しない場合は、その項目を見出しとする小欄を新設する。
なお、ステップＳ３４２及びステップＳ３４３の処理は、過去のすべての案件について繰り返す。その後、要求仕様登録処理手順を終了する。

（タスク省略誘導処理手順）
図９に沿って、タスク省略誘導処理手順を説明する。
ステップＳ３６１において、悪影響度フィードバック部２５は、新規案件の要求仕様を受け付ける。具体的には、悪影響度フィードバック部２５は、第１に、要求仕様登録画面５４（図１２）を出力装置１３に表示する。
悪影響度フィードバック部２５は、第２に、ユーザが、要求仕様登録画面５４の案件名欄１３１に新規案件の案件名を、要求仕様欄１３２の項目欄１３３及び仕様欄１３４に項目と仕様の組合せを入力し、登録ボタン１３５を押下するのを受け付ける。新規案件とは、案件最終結果データベース３４（図５（ａ））に登録されていない案件であり、ユーザが、今後その案件を実行するに先んじて、何らかのタスクを省略することを考えている案件である。

ステップＳ３６２において、悪影響度フィードバック部２５は、類似案件を取得する。具体的には、悪影響度フィードバック部２５は、第１に、ステップＳ３６１の「第２」において受け付けた項目と仕様の組合せを検索キーとして、要求仕様データベース３３（図４）を検索し、該当したすべてのレコードの案件ＩＤを取得する。このとき、悪影響度フィードバック部２５は、検索キーとしたすべての組合せが一致することをもって「該当」することとしてもよい。しかしながら、検索キーとしたすべての組合せのうち所定の数が一致すること、又は、検索キーとしたすべての組合せの数に所定の比率を乗じた数の組合せが一致すること、をもって「該当」することとしてもよい。例えば、ステップＳ３６１の「第２」において受け付けた項目と仕様の組合せが、（熱源タイプ、温熱源）、（電源タイプ、一般商用電源）及び（制御タイプ、遠隔制御）であり、これら３つの組合せを検索キーとして、要求仕様データベース３３を検索するとする。このとき、１行目のレコード（３つの組合せが完全一致）だけでなく、２行目のレコード（２つの組合せが一致）も「該当」するものとしてよい。

悪影響度フィードバック部２５は、第２に、案件最終結果データベース３４（図５（ａ））のコピーを作成する。そして、ステップＳ３６２の「第１」において取得した案件ＩＤを検索キーとして、作成したコピーを検索し、該当したレコードを残して他のレコードを消去する。この段階で残されたレコードを、以降「類似レコード」と呼ぶことがある。

ステップＳ３６３において、悪影響度フィードバック部２５は、悪影響度を算出する。具体的には、悪影響度フィードバック部２５は、すべての類似レコードの案件について前記した学習処理を行い、Ｗ_１、Ｗ_２、・・・の値の組合せを取得（算出）し、取得したＷ_１、Ｗ_２、・・・の値を悪影響度データベース３５（図５（ｂ））として記憶する。

ステップＳ３６４において、タスク省略誘導部２４は、悪影響度が小さいタスクを表示する。具体的には、タスク省略誘導部２４は、第１に、ステップＳ３６３において取得した悪影響度（Ｗ_１、Ｗ_２、・・・）のうち、所定の閾値より小さい悪影響度を特定し、その悪影響度に対応するタスクＩＤを取得する。ここでは、所定の閾値より小さい悪影響度が１つだけ存在し、その値が「０．２０」であったとする。
タスク省略誘導部２４は、第２に、出力装置１３に、標準業務プロセス３１を表示し（図１４）、悪影響度をタスクに関連付けて表示し、かつ悪影響度「０.２０」及びタスク名を強調表示する。

ステップＳ３６５において、タスク省略誘導部２４は、タスク検討要否判断・根拠表示画面５５（図１３）を表示する。具体的には、タスク省略誘導部２４は、第１に、出力装置１３にタスク検討要否判断・根拠表示画面５５を表示し、そのタスク名欄１４１に、ステップＳ３６４の「第１」において取得したタスクＩＤが特定するタスクの名称を表示し、「上記タスクを省略した際の悪影響度」欄１４２に、ステップＳ３６４の「第１」において特定した悪影響度を表示する。
タスク省略誘導部２４は、第２に、ステップＳ３６４の「第１」において取得したタスクＩＤを検索キーとして、根拠データベース３２（図３）を検索し、該当したすべてのレコードの根拠、案件ＩＤ（適用案件欄２０５）及び案件最終結果平均値を取得する。

タスク省略誘導部２４は、第３に、タスク検討要否判断・根拠表示画面５５の「上記タスクが不要である根拠」欄１４３の根拠欄１４５に、ステップＳ３６５の「第２」において取得した根拠を表示し、適用案件数欄１４６に、ステップＳ３６５の「第２」において取得した案件ＩＤの数を表示し、案件最終結果平均値欄１４７に、ステップＳ３６５の「第２」において取得した案件最終結果平均値を表示する。このとき、「上記タスクが不要である根拠」欄１４３に表示されるレコードの数は、ステップＳ３６５の「第２」において該当したレコードの数に等しい。

ステップＳ３６６において、タスク省略誘導部２４は、根拠を受け付ける。具体的には、タスク省略誘導部２４は、第１に、ユーザが、「上記タスクが不要である根拠」欄１４３のレコードのうち任意の１つを選択するのを受け付ける。タスク省略誘導部２４は、ラジオボックス欄１４４を表示しておき、ユーザが任意の１つのラジオボックスを選択するのを受け付けるものとする。
タスク省略誘導部２４は、第２に、ユーザが、適用ボタン１４８を押下するのを受け付ける。

ステップＳ３６７において、タスク省略誘導部２４は、省略するタスクを表示する。具体的には、タスク省略誘導部２４は、ステップＳ３６４の「第２」において強調表示した悪影響度及びタスク名を、省略決定済みであることを示す他の形態（例えば、グレー表示、図１５参照）で表示する。

なお、ステップＳ３６７において、タスク省略誘導部２４は、ステップＳ３６１の「第２」において受け付けた案件名、項目及び仕様、並びに新たに採番する案件ＩＤに基づいて、新規案件について、要求仕様データベース３３（図４）のレコードを作成してもよい。さらに、タスク省略誘導部２４は、ステップＳ３６１の「第２」において受け付けた案件名、新たに採番する案件ＩＤ、ステップＳ３６４の「第１」において取得したタスクＩＤ、及び、ステップＳ３６６の「第１」において受け付けた根拠に基づいて、新規案件について、案件最終結果データベース３４（図５（ａ））のレコードを作成してもよい。ただし、案件最終結果値欄２２４は空白とする。
その後、タスク省略誘導処理手順を終了する。

（第１の実施形態の効果）
ユーザは、従来は経験に基づきタスクの要否判断を行っていた。第１の実施形態では、例えば、図１３において、タスク名「空冷・水冷パッケージ」、根拠「熱源タイプが温熱源であるため」及び悪影響度「０.５０」が表示される。これらを視認したユーザは、自らの新規の案件の要求仕様が「温熱源」であることと照らし合わせることによって、当該タスクを検討することなく省略可能であることが容易にわかる。さらに、当該タスクを省略した場合の悪影響度を数量的に理解できる。

＜第２の実施形態＞
ある案件において、要求仕様が一旦決定された後、変更される場合がよくある。この場合、どのタスクに戻って検討をし直すかを決定することは実際には困難である。第２の実施形態においては、設計業務支援装置１は、ユーザが直面していると思われる状況を「見直し根拠」として表示する。同時に、その状況が発生した際に検討し直すべきタスクを「見直しタスク」として表示する（図２５）。

第１の実施形態においては、設計業務支援装置１は、悪影響度の小さいタスクを省略可能なタスクとして表示した。設計業務支援装置１は、第２の実施形態においては、信頼度（詳細後記）の大きいタスクを「見直しタスク」として表示する。

（用語等）
見直し根拠とは、あるタスクを見直す（再度検討する）ことを正当化する理由である。
見直しタスクとは、見直し根拠を適用することによって再度検討されるべきタスクである。
信頼度とは、悪影響度が大きくなるほど小さくなる指標である。一般的に、悪影響度と信頼度との関係は、悪影響度を入力値とし、信頼度を出力値とし、入力値が大きくなるほど出力値が小さくなる関数によって定義される。ここでは、当該関数は、「信頼度＝１−悪影響度」であるとする。
これら以外の用語は、第１の実施形態における用語と同じである。

（設計業務支援装置）
図１６に沿って、設計業務支援装置１を説明する。図２における根拠登録部２２、タスク省略誘導部２４、悪影響度フィードバック部２５、根拠データベース３２及び要求仕様データベース３３が、図１６においては、それぞれ、見直し根拠登録部２２ｂ、タスク見直し誘導部２４ｂ、信頼度フィードバック部２５ｂ、見直し根拠データベース３２ｂ及び仕様変更データベース３３ｂに置換されている。図１６のその他の構成は、図２と同じである。
なお、例えば、根拠データベース３２に対し、見直し根拠データベースの符号を「３２ｂ」としたのは、それらのデータベースが対応しており、構成も類似しているからである。類似しているデータベース間において、同じ欄には同じ符号を付し、類似している欄にはもとの符号に「ｂ」を加えた符号を付した（詳細後記）。
また、「第１のデータベース」及び「第２のデータベース」には、それぞれ、「案件最終結果データベース３４」及び「仕様変更データベース３３ｂ」が相当する。

（見直し根拠データベース）
図１７に沿って、見直し根拠データベース３２ｂを説明する。図３における、根拠ＩＤ欄２０１、根拠欄２０２、タスクＩＤ欄２０３及びタスク名欄２０４が、図１７においては、それぞれ、見直し根拠ＩＤ欄２０１ｂ、見直し根拠欄２０２ｂ、見直しタスクＩＤ欄２０３ｂ及び見直しタスク名欄２０４ｂに置換されている。図１７のその他の構成は、図３と同じである。

見直し根拠ＩＤ欄２０１ｂの見直し根拠ＩＤは、見直し根拠を一意に特定する識別子である。
見直し根拠欄２０２ｂの見直し根拠は、見直し根拠の文言そのものである。
見直しタスクＩＤ欄２０３ｂの見直しタスクＩＤは、見直しタスクを一意に特定する識別子である。
見直しタスク名欄２０４ｂの見直しタスク名は、見直しタスクの名称である。
適用案件欄２０５の案件ＩＤは、案件を一意に特定する識別子である。ここでは、当該見直し根拠を適用することによって当該見直しタスクが見直された実績を有する１又は複数の案件を特定している。
案件最終結果平均値欄２０６の案件最終結果平均値は、適用案件のそれぞれについて定義される案件最終結果値（詳細後記）の平均値である。
見直し根拠データベース３２ｂのレコードは、見直し根拠ＩＤと見直しタスクＩＤとの組合せの数だけ存在する。

（仕様変更データベース）
図１８に沿って、仕様変更データベース３３ｂを説明する。仕様変更データベース３３ｂにおいては、案件ＩＤ欄２１１に記憶された案件ＩＤに関連付けて、案件名欄２１２には案件名が、項目欄２１４には項目が、変更前欄２１５には変更前の項目の値が、変更後欄２１６には変更後の項目の値が記憶されている。
案件ＩＤ欄２１１の案件ＩＤは、案件を一意に特定する識別子である。
案件名欄２１２の案件名は、案件の名称である。
項目欄２１４の項目は、案件に対して要求される仕様のカテゴリである。例えば、項目として、「床面積」及び「天井高さ」が存在する。
変更前欄２１５の変更前の項目の値は、その項目について要求される仕様そのもののうち、変更前のものである。
変更後欄２１６の変更後の項目の値は、その項目について要求される仕様そのもののうち、変更後のものである。
仕様変更データベース３３ｂのレコードは、案件ＩＤと項目の組合せの数だけ存在する。

（案件最終結果データベース）
第２の実施形態においては、第１の実施形態と同じ案件最終結果データベース３４（図５（ａ））が使用される。しかしながら、第２の実施形態における有無値（欄２２３）の意味は、第１の実施形態における有無値の意味とは異なる。第２の実施形態においては、有無値「０」は、そのタスクＩＤが特定するタスクが見直されなかったことを示す。有無値「１」は、そのタスクＩＤが特定するタスクが見直されたことを示す。

したがって、第２の実施形態における、図５（ａ）の１〜６行目のレコードを参照すると、例えば以下のことがらがわかる。なお、図５（ａ）の案件最終結果値欄２２４には、（ ）を付した案件最終結果値及び（ ）を付さない案件最終結果値が併記されている。（ ）を付さない案件最終結果値は、専ら、前記した第１の実施形態についての説明用のものであるので、ここでは無視する。
（１）仕様の変更がなされた後終了し、評価がなされた案件が少なくとも６つ存在する。
（２）これらの６つの案件のすべてについて、少なくとも１つのタスクが見直されている。つまり、すべてのレコードは、有無値欄２２３に少なくとも１つの有無値「１」を有する。
（３）これらの６つの案件のうち、案件最終結果値が最大である（案件としての成績が悪い）のは、「案件Ａ」である。「案件Ａ」では、タスクＩＤ「Ｔ００２」のタスクが見直されている。当該タスクを省略した際に適用された根拠の根拠ＩＤは「Ｒ０２１」である。

（４）１つのタスクを見直し、案件最終結果値を最小にする（案件としての成績を最もよくする）ためには、「Ｔ００４」を見直すべきである。１、３及び５行目を比較すると、「Ｔ００４」が見直されている５行目の案件最終結果値が最小であることから、このことが理解できる。
（５）２つのタスクを見直し、案件最終結果値を最小にするためには、「Ｔ００１」及び「Ｔ００４」を省略するべきである。２、４及び６行目を比較すると、「Ｔ００１」及び「Ｔ００４」が見直されている４行目の案件最終結果値が最小であることから、このことが理解できる。
（６）１つのタスクを見直した結果、２つのタスクを見直すよりも案件最終結果値が小さくなるのであれば、当然１つのタスクのみを見直す。しかしながら、図５（ａ）を参照する限りそのような事実はない。
なお、第２の実施形態の根拠欄２２５の根拠ＩＤの例は、第１の実施形態の例と同じものを便宜的に使用している。例えば１行目のレコードについて、「Ｔ００２」に対して「Ｒ０２１」が対応するものとして第２の実施形態を説明している。当然のことながら、タスクを省略する根拠とタスクを見直す根拠は別のものである。よって、ここでの、例えば「Ｒ０２１」が特定する見直し根拠は、第１の実施形態における「Ｒ０２１」が特定する根拠とは別のものである。

（処理手順の概要）
以降において、処理手順を説明する。処理手順には、（１）見直し根拠登録処理手順、（２）案件最終結果入力処理手順、（３）仕様変更登録処理手順及び（４）タスク見直し誘導処理手順の４つがある。これらは、通常、（１）→（２）→（３）→（４）の順番で実行される。それぞれの手順の内容は、フローチャート及び画面例に沿って詳しく後記するが、まず、それぞれの手順の概略を説明する。なお、通常、（１）、（２）及び（３）の手順は、システム管理者により実行され、（４）の手順は、システム利用者によって実行される。すなわち、（１）、（２）及び（３）の手順は、（４）の手順を基準にすればその「事前」に実行される。

（１）見直し根拠登録処理手順は、標準業務プロセス３１が完成していることを前提に、要求仕様が一旦決定された後変更された個々の案件において、標準業務プロセス３１に含まれるタスクを見直す際に適用される見直し根拠を登録するための手順である。見直し根拠登録処理手順は、通常、標準業務プロセス３１が作成された時点で実行される。

（２）案件最終結果入力処理手順は、終了した過去の案件のうち、要求仕様が一旦決定された後変更された個々の案件（以降「仕様変更があった案件」とも呼ぶ）について、どの見直し根拠を適用してどの見直しタスクを見直した結果悪影響度及び信頼度はどのようになったか、を示すデータを作成するための手順である。案件最終結果入力処理手順は、個々の案件のうち仕様変更があった案件が終了した時点で実行されてもよいし、ある時点で、その時点までに終了している、そのような複数の案件についてまとめて実行されてもよい。

（３）仕様変更登録処理手順は、終了した過去の案件のうち仕様変更があった案件の変更前後の仕様を登録するための手順である。仕様変更登録処理手順は、個々の案件のうち仕様変更があった案件が終了した時点で実行されてもよいし、ある時点で、その時点までに終了している、そのような複数の案件についてまとめて実行されてもよい。
（４）タスク見直し誘導処理手順は、仕様変更があった案件用にカスタマイズされた業務プロセスを作成するために、標準業務プロセス３１のタスクのうちから、再度検討すべきタスクの起点となるべきタスクである、見直しタスクを決定するための手順である。タスク見直し誘導処理手順は、ある案件の仕様が変更される都度実行される。そして、タスク見直し誘導処理手順の最初の段階において、（３）仕様変更登録処理手順と類似の手順が実行される。すなわち、仕様変更があった案件について、変更前後の仕様が入力される。

（見直し根拠登録処理手順）
図１９に沿って、見直し根拠登録処理手順を説明する。
ステップＳ４０１において、標準業務プロセス誘導部２１は、標準業務プロセス３１を表示する。具体的には、標準業務プロセス誘導部２１は、第１に、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、補助記憶装置１５から標準業務プロセス３１を取得する。
標準業務プロセス誘導部２１は、第２に、出力装置１３に標準業務プロセス表示画面５１（図１）を表示する。標準業務プロセス表示画面５１には、取得した標準業務プロセス３１が表示されるものとする。
ここでは、「設備設計」に関する標準業務プロセス３１が表示されることとした。しかしながら、複数の標準業務プロセス３１が補助記憶装置１５に記憶されており、ユーザは、そのうちから任意の標準業務プロセス３１を選択するようにしてもよい。

ステップＳ４０２において、見直し根拠登録部２２ｂは、見直しタスクの指定を受け付ける。具体的には、見直し根拠登録部２２ｂは、ユーザが、表示されている標準業務プロセス３１のタスクのうちから、見直し根拠を関連付けるべき任意の１つのタスクをマウス等の入力装置１２を介して指定するのを受け付ける。ここでは、「概略容量の把握」１０２が指定されたとする。

ステップＳ４０３において、見直し根拠登録部２２ｂは、見直し根拠登録画面５２ｂ（図２３）を表示する。具体的には、見直し根拠登録部２２ｂは、見直し根拠登録画面５２ｂを出力装置１３に表示する。見直し根拠登録部２２ｂは、見直し根拠登録画面５２ｂの「見直しタスク」欄１１１ｂに、ステップＳ４０２において指定されたタスクの名称を表示するものとする。

ステップＳ４０４において、見直し根拠登録部２２ｂは、見直し根拠の入力を受け付ける。具体的には、見直し根拠登録部２２ｂは、第１に、ユーザが、見直し根拠登録画面５２ｂの「タスクを見直す根拠」欄１１２ｂに、キーボード等の入力装置１２を介して、見直し根拠を入力するのを受け付ける。
見直し根拠登録部２２ｂは、第２に、ユーザが登録ボタン１１３を押下するのを受け付ける。

ステップＳ４０５において、見直し根拠登録部２２ｂは、見直し根拠を登録する。具体的には、見直し根拠登録部２２ｂは、第１に、見直し根拠データベース３２ｂ（図１７）の新たなレコードを作成する。
見直し根拠登録部２２ｂは、第２に、新たなレコードの見直し根拠欄２０２ｂ及び見直しタスク名欄２０４ｂに、それぞれ、ステップＳ４０４において受け付けた見直し根拠及びステップＳ４０２において指定されたタスクの名称を記憶する。
見直し根拠登録部２２ｂは、第３に、新たなレコードの見直し根拠ＩＤ欄２０１ｂに、見直し根拠ＩＤを採番したうえで記憶し、新たなレコードの見直しタスクＩＤ欄２０３ｂに、見直しタスクＩＤを採番したうえで記憶する。見直し根拠登録部２２ｂは、標準業務プロセス３１の各タスクを特定する見直しタスクＩＤを予め準備しておいてもよい。
なお、新たなレコードの適用条件欄２０５及び案件最終結果平均値欄２０６は空欄のままとする。その後、見直し根拠登録処理手順を終了する。

（案件最終結果入力処理手順）
図２０に沿って、案件最終結果入力処理手順を説明する。
ステップＳ４２１において、案件成否入力部２３は、案件最終結果入力画面５３（図１１）を表示する。具体的には、案件成否入力部２３は、第１に、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、出力装置１３に、案件最終結果入力画面５３を表示する。入力のタイミングは、通常案件が終了した時点以降である。

ステップＳ４２２において、案件成否入力部２３は、案件名等を受け付ける。具体的には、案件成否入力部２３は、第１に、ユーザが、案件名欄１２１に案件名を、受注金額欄１２２に受注金額を、仕損費欄１２３に仕損費を入力するのを受け付ける。受注金額は、当該案件の対価として顧客等から受け取る報酬の金額である。仕損費は、仕損品（何らかのタスクを省略したことに起因して発生した不合格製品）の製造等に要したコストである。

案件成否入力部２３は、第２に、ユーザが、「タスク及び根拠」欄１２４に対して、当該案件において見直したタスクの見直しタスクＩＤ及びそのタスクを見直した際に適用された見直し根拠の見直し根拠ＩＤを、相互に関連付けられた組合せとして入力するのを受け付ける。
案件成否入力部２３は、第３に、ユーザが、登録ボタン１２５を押下するのを受け付ける。案件成否入力部２３は、ステップＳ４２２の処理を、終了したすべての案件のうち仕様変更があった案件について繰り返す。

ステップＳ４２３において、案件成否入力部２３は、「仕損費／受注金額」の値を算出する。具体的には、案件成否入力部２３は、第１に、案件最終結果データベース３４（図５（ａ））の新たなレコードを、ステップＳ４２２の「第２」において受け付けた組合せの数だけ作成する。
案件成否入力部２３は、第２に、ステップＳ４２２の「第１」において受け付けた受注金額及び仕損費に基づいて、それぞれの案件についての、「仕損費／受注金額」の値を算出し、その値を主記憶装置１４に一時的に記憶する。案件成否入力部２３は、ステップＳ４２３の処理を、終了したすべての案件のうち仕様変更があった案件について繰り返す。

ステップＳ４２４において、案件成否入力部２３は、案件最終結果値等を登録する。具体的には、案件成否入力部２３は、第１に、案件最終結果データベース３４の新たなレコードのそれぞれについて、案件最終結果値を算出する。前記したように、案件最終結果値は、「ある案件の仕損費／その案件の受注金額」／「すべての案件の（仕損費／受注金額）の値のうちの最大値」として定義される。「すべての案件の（仕損費／受注金額）の値」は、ステップＳ４２３の「第２」において一時的に記憶した値を参照して取得する。

案件成否入力部２３は、第２に、新たなレコードの案件名欄２２２に、ステップＳ４２２の「第１」において受け付けた案件名を記憶し、案件ＩＤ欄２２１に、当該案件の案件ＩＤを記憶する。そして、案件最終結果値欄２２４に、ステップＳ４２４の「第１」において算出した案件最終結果値を記憶する。
案件成否入力部２３は、第３に、ステップＳ４２２の「第２」において受け付けた見直しタスクＩＤを見出しとして有する根拠欄２２５の小欄に、ステップＳ４２２の「第２」において受け付けた見直し根拠ＩＤを記憶する。そして、テップＳ４２２の「第２」において受け付けた見直しタスクＩＤを見出しとして有する有無値欄２２３の小欄に、有無値「１」を記憶し、有無値欄２２３の他の小欄に、有無値「０」を記憶する。

ステップＳ４２５において、案件成否入力部２３は、見直し根拠データベース３２ｂ（図１７）を完成させる。具体的には、案件成否入力部２３は、第１に、見直し根拠データベース３２ｂの任意のレコードを１つ取得する。取得したレコードの適用案件欄２０５及び案件最終結果平均値欄２０６は空欄である。当該取得したレコードを、以降「対象レコード」と呼ぶことがある。

案件成否入力部２３は、第２に、対象レコードの見直し根拠ＩＤ及び見直しタスクＩＤを検索キーとして、案件最終結果データベース３４（図５（ａ））の根拠欄２２５を検索し、該当したレコードの案件ＩＤ及び案件最終結果値を取得する。通常、複数のレコードが該当する。そして、取得した案件最終結果値の平均値を算出する。
案件成否入力部２３は、第３に、対象レコードの案件最終結果平均値欄２０６に、算出した平均値を記憶し、対象レコードの適用案件欄２０５に、取得したすべての案件ＩＤを記憶する。
なお、ステップＳ４２５の処理は、すべての未処理の対象レコードについて繰り返す。その後、案件最終結果入力処理手順を終了する。

（仕様変更登録処理手順）
図２１に沿って、仕様変更登録処理手順を説明する。
ステップＳ４４１において、標準業務プロセス誘導部２１は、仕様変更登録画面５４ｂ（図２４）を表示する。具体的には、標準業務プロセス誘導部２１は、ユーザが入力装置１２を介して所定の指示を入力するのを契機として、出力装置１３に、仕様変更登録画面５４ｂを表示する。

ステップＳ４４２において、標準業務プロセス誘導部２１は、案件名及び変更前後の仕様を受け付ける。具体的には、標準業務プロセス誘導部２１は、第１に、ユーザが、仕様変更登録画面５４ｂの案件名欄１３１ｂに案件名を入力するのを受け付ける。
標準業務プロセス誘導部２１は、第２に、ユーザが、仕様変更登録画面５４ｂの仕様変更欄１３２ｂの項目欄１３３ｂ及び仕様欄１３４ｂに、項目、変更前の仕様及び変更後の仕様を対応付けて入力するのを受け付ける。仕様については、標準業務プロセス誘導部２１が予め項目ごとに用意してある仕様の候補を表示し（図２４では、候補として「１００ｍ^２」及び「２００ｍ^２」が表示されている）、ユーザがそのうちから２つを選択するのを受け付けてもよい。標準業務プロセス誘導部２１は、ユーザが最初に選択した仕様を変更前の仕様として扱い、ユーザが次に選択した仕様を変更後の仕様として扱う。
標準業務プロセス誘導部２１は、第３に、ユーザが登録ボタン１３５を押下するのを受け付ける。

ステップＳ４４３において、標準業務プロセス誘導部２１は、仕様変更を登録する。具体的には、標準業務プロセス誘導部２１は、第１に、仕様変更データベース３３ｂ（図１８）の新たなレコードを作成する。なお、ステップＳ４４２の「第２」において受け付けた項目が複数ある場合は、その項目の数だけ、新たなレコードを作成する。
標準業務プロセス誘導部２１は、第２に、新たなレコードの案件名欄２１２に、ステップＳ４４２の「第１」において受け付けた案件名を記憶し、新たなレコードの案件ＩＤ欄２１１に、案件ＩＤを採番したうえで記憶する。
標準業務プロセス誘導部２１は、第３に、ステップＳ４４２の「第２」において受け付けた項目、変更前の仕様及び変更後の仕様を、新たなレコードの、それぞれ、項目欄２１４、変更前欄２１５及び変更後欄２１６に記憶する。
なお、ステップＳ４４２及びステップＳ４４３の処理は、過去のすべての案件のうち仕様変更があった案件について繰り返す。
その後、仕様変更登録処理手順を終了する。

（タスク見直し誘導処理手順）
図２２に沿って、タスク見直し誘導処理手順を説明する。
ステップＳ４６１において、信頼度フィードバック部２５ｂは、変更前の仕様及び変更後の仕様を受け付ける。具体的には、信頼度フィードバック部２５ｂは、第１に、仕様変更登録画面５４ｂ（図２４）を出力装置１３に表示する。
信頼度フィードバック部２５ｂは、第２に、ユーザが、仕様変更登録画面５４ｂの案件名欄１３１ｂに今次仕様変更があった案件の案件名を、仕様変更欄１３２ｂの項目欄１３３に変更があった項目を、仕様変更欄１３２ｂの仕様欄１３４ｂに変更前の仕様及び変更後の仕様を入力し、登録ボタン１３５を押下するのを受け付ける。今次仕様変更があった案件とは、案件最終結果データベース３４（図５（ａ））に登録されていない案件であり、ユーザが、仕様変更に対応して何らかのタスクを見直すことを考えている案件である。

ステップＳ４６２において、信頼度フィードバック部２５ｂは、類似案件を取得する。具体的には、信頼度フィードバック部２５ｂは、第１に、ステップＳ４６１の「第２」において受け付けた、項目、変更前の仕様及び変更後の仕様の組合せを検索キーとして、仕様変更データベース３３ｂ（図１８）を検索し、該当したすべてのレコードの案件ＩＤを取得する。このとき、信頼度フィードバック部２５ｂは、検索キーとした組合せに含まれる、項目、変更前の仕様及び変更後の仕様のそれぞれが、厳密に一致することをもって「該当」することとしてもよい。しかしながら、検索キーである変更前の仕様及び／又は変更後の仕様に対して、その仕様の値を含む誤差範囲を定義し、その範囲で該当する場合も「該当」することとしてもよい。

例えば、ステップＳ４６１の「第２」において受け付けた、項目、変更前の仕様及び変更後の仕様の組合せが、それぞれ、「床面積」、「１００ｍ^２」及び「２００ｍ^２」であり、変更前の仕様についての誤差率及び変更後の仕様についての誤差率が、それぞれ、「±２０％」及び「±３０％」であったとする。この場合、信頼度フィードバック部２５ｂは、項目「床面積」、変更前「８０ｍ^２〜１２０ｍ^２」及び変更後「１４０ｍ^２〜２６０ｍ^２」を検索キーとして、仕様変更データベース３３ｂを検索する。すると、例えば、項目「床面積」、変更前「９０ｍ^２」及び変更後「２２０ｍ^２」を有するレコードも該当することとなる。

信頼度フィードバック部２５ｂは、第２に、案件最終結果データベース３４（図５（ａ））のコピーを作成する。そして、ステップＳ４６２の「第１」において取得した案件ＩＤを検索キーとして、作成したコピーを検索し、該当したレコードを残して他のレコードを消去する。この段階で残されたレコードを、以降「変更内容類似レコード」と呼ぶことがある。

ステップＳ４６３において、信頼度フィードバック部２５ｂは、信頼度を算出する。具体的には、信頼度フィードバック部２５ｂは、すべての変更内容類似レコードの案件について、前記した（第１の実施形態と同じ）学習処理を行い、Ｗ_１、Ｗ_２、・・・の値の組合せを取得（算出）し、取得したＷ_１、Ｗ_２、・・・の値を悪影響度データベース３５（図５（ｂ））として記憶する。そして、Ｚ_１＝１−Ｗ_１、Ｚ_２＝１−Ｗ_２、・・・の値を、信頼度として、図５（ｂ）と同様な形で補助記憶装置１５に記憶する（図示せず）。

ステップＳ４６４において、タスク見直し誘導部２４ｂは、信頼度が大きいタスクを表示する。具体的には、タスク見直し誘導部２４ｂは、第１に、ステップＳ４６３において取得した信頼度（Ｚ_１、Ｚ_２、・・・）のうち、所定の閾値より大きい信頼度を特定し、その信頼度に対応する見直しタスクＩＤを取得する。ここでは、所定の閾値より大きい信頼度が１つだけ存在し、その値が「０．７５」であったとする。
タスク見直し誘導部２４ｂは、第２に、出力装置１３に、標準業務プロセス３１を表示し、信頼度を見直しタスクに関連付けて表示し、かつ信頼度「０.７５」及び見直しタスク名を強調表示する（図１４において、強調表示箇所が「概略容量の把握（０.７５）」となっている状態）。

ステップＳ４６５において、タスク見直し誘導部２４ｂは、見直しタスク・根拠表示画面５５ｂ（図２５）を表示する。具体的には、タスク見直し誘導部２４ｂは、第１に、ステップＳ４６４の「第１」において取得した見直しタスクＩＤを検索キーとして、見直し根拠データベース３２ｂ（図１７）を検索し、該当したすべてのレコードの見直し根拠、案件ＩＤ（適用案件欄２０５）、見直しタスク名、及び案件最終結果平均値を取得する。

タスク見直し誘導部２４ｂは、第２に、見直しタスク・根拠表示画面５５ｂの「見直しタスク及び根拠」欄１４３ｂの見直しタスク欄１５０に、ステップＳ４６５の「第１」において取得した見直しタスク名を表示し、見直し根拠欄１４５ｂにステップＳ４６５の「第１」において取得した見直し根拠を表示し、適用案件数欄１４６に、ステップＳ４６５の「第１」において取得した案件ＩＤの数を表示し、案件最終結果平均値欄１４７に、ステップＳ４６５の「第１」において取得した案件最終結果平均値を表示し、信頼度欄１５１にステップＳ４６４の「第１」において特定した信頼度を表示する。このとき、「見直しタスク及び根拠」欄１４３ｂに表示されるレコードの数は、ステップＳ４６５の「第１」において該当したレコードの数に等しい。

ステップＳ４６６において、タスク見直し誘導部２４ｂは、見直し根拠を受け付ける。具体的には、タスク見直し誘導部２４ｂは、第１に、ユーザが、「見直しタスク及び根拠」欄１４３ｂのレコードのうち任意の１つを選択するのを受け付ける。タスク見直し誘導部２４ｂは、ラジオボックス欄１４４を表示しておき、ユーザが任意の１つのラジオボックスを選択するのを受け付けるものとする。
タスク見直し誘導部２４ｂは、第２に、ユーザが、適用ボタン１４８を押下するのを受け付ける。

ステップＳ４６７において、タスク見直し誘導部２４ｂは、見直しタスクを表示する。具体的には、タスク見直し誘導部２４ｂは、ステップＳ４６４の「第２」において強調表示した見直しタスク名を、見直し決定済みであることを示す他の形態（例えば、グレー表示）で表示する。このとき、例えば、「概略容量の把握（０.７５）」がグレー表示される（図１５において、グレー表示箇所が「概略容量の把握（０.７５）」となっている状態）。

なお、ステップＳ４６７において、タスク見直し誘導部２４ｂは、ステップＳ４６１の「第２」において受け付けた案件名、項目、変更前の仕様及び変更後の仕様、並びに、すでに採番済みの案件ＩＤに基づいて、仕様変更があった案件について、仕様変更データベース３３ｂ（図１８）のレコードを作成してもよい。さらに、タスク見直し誘導部２４ｂは、ステップＳ４６１の「第２」において受け付けた案件名、並びに、ステップＳ４６６の「第１」において選択されたレコードの見直しタスク及び見直し根拠に基づいて、仕様変更があった案件について、案件最終結果データベース３４（図５（ａ））のレコードを作成してもよい。ただし、案件最終結果値欄２２４は空白とする。
その後、タスク見直し誘導処理手順を終了する。

（第２の実施形態の変形例）
前記したステップＳ４６４においては、タスク見直し誘導部２４ｂは、単純に信頼度の大きいタスクを表示した。しかしながら、すべてのタスクを、ユーザが現在実行中のタスクの上流に位置するタスク（ユーザが過去に実行したタスク）に絞り込んだうえで、絞り込んだタスクのうちから信頼度の高いタスクを「見直しタスク」として表示することも可能である。
例えば、補助記憶装置１５は、タスクの階層関係を示す「タスク階層情報」（図示せず）を格納しているものとする。タスク階層情報は、当該タスクのタスクＩＤに関連付けて、当該タスクの上流に位置する１つのタスクのタスクＩＤと、当該タスクの下流に位置する１又は複数のタスクの見直しタスクＩＤとを記憶しているものとする。すなわち、タスク見直し誘導部２４ｂは、タスク階層情報を参照することによって、標準業務プロセス３１（図１）の階層関係及び分岐状態を知ることができる。

ステップＳ４６４の「第１」において、タスク見直し誘導部２４ｂは、以下の処理を実行する。
（１）ユーザが、現在実行中のタスクを指定するのを受け付ける。
（２）受け付けたタスクのタスクＩＤを検索キーとして、タスク階層情報を検索し、現在実行中のタスクを起点として遡ることができるすべてのタスクのタスクＩＤを取得する。
（３）取得したタスクＩＤが特定するタスクのうちから、信頼度が所定の閾値よりも大きいタスクを見直しタスクとして特定する。ここで複数のタスクが特定される場合がある。その場合は、そのうち最も下流にある１つのタスク（上流にあるタスクに比較して一般的に見直す手間が少ない）を見直しタスクとして特定してもよい。

（第２の実施形態の効果）
ユーザは、従来は経験に基づきタスクの見直し判断を行っていた。第２の実施形態では、例えば、図２５において、見直しタスク名「概略容量の把握」、見直し根拠「床面積が変更となり、容量が変わるため」及び信頼度「０.５０」が表示される。これらを視認したユーザは、自らの案件において仕様「床面積」が変更となったことと照らし合わせることによって、当該見直しタスクを再度検討することが有益であることが容易にわかる。さらに、当該見直しタスクを再度検討した場合の信頼度を数量的に理解できる。

本発明は、前記した実施形態に限定されることなく、本発明の主旨を逸脱しない範囲で、変更実施が可能である。

１ 設計業務支援装置
１１ 中央制御装置（制御部）
１２ 入力装置
１３ 出力装置
１４ 主記憶装置（記憶部）
１５ 補助記憶装置（記憶部）
２１ 標準業務プロセス誘導部
２２ 根拠登録部
２２ｂ 見直し根拠登録部
２３ 案件成否入力部
２４ タスク省略誘導部
２４ｂ タスク見直し誘導部
２５ 悪影響度フィードバック部
２５ｂ 信頼度フィードバック部
３１ 標準業務プロセス
３２ 根拠データベース
３２ｂ 見直し根拠データベース
３３ 要求仕様データベース（第２のデータベース）
３３ｂ 仕様変更データベース（第２のデータベース）
３４ 案件最終結果データベース（第１のデータベース）
３５ 悪影響度データベース
５１ 標準業務プロセス表示画面
５２ 根拠登録画面
５２ｂ 見直し根拠登録画面
５３ 案件最終結果入力画面
５４ 要求仕様登録画面
５４ｂ 仕様変更登録画面
５５ タスク検討要否判断・根拠表示画面
５５ｂ 見直しタスク・根拠表示画面

Claims (6)

1. 業務プロセスを構成する複数のタスクのそれぞれが、前記業務プロセスに従って実行される案件に対して及ぼす影響を算出する業務支援装置であって、
   過去の前記案件に関連付けて、前記タスクと、前記実行された案件において前記タスクが省略されたか否かを示す有無値と、過去の前記案件に対する事後の評価を示す値である評価値と、が記憶される第１のデータベースと、
   過去の前記案件に関連付けて、過去の前記案件に対して要求された仕様が記憶される第２のデータベースと、
   が格納される記憶部と、
   新たな前記案件について要求される仕様を受け付け、
   前記受け付けた仕様に基づいて、前記第２のデータベースを検索し、前記仕様が所定の基準を満たす程度に類似する過去の前記案件を取得し、
   前記取得した案件についてのレコードを前記第１のデータベースから抽出し、
   前記抽出したレコードについて、前記有無値に対して乗じられる係数を悪影響度とし、
   前記抽出したレコードのタスクごとに、前記有無値に前記悪影響度を乗じた値の総和を算出し、前記算出した総和と前記評価値との差分を算出することによって、前記取得した前記案件について最適化された前記悪影響度を前記タスクごとに算出し、
   前記算出した悪影響度と所定の閾値との大小関係を比較し、前記比較に基づいて特定された悪影響度に対応する前記タスクを、新たな前記案件において省略可能であるタスクとして出力する制御部と、
   を有することを特徴とする業務支援装置。
2. 業務プロセスを構成する複数のタスクのそれぞれが、前記業務プロセスに従って実行される案件に対して及ぼす影響を算出する業務支援装置であって、
   過去の前記案件に関連付けて、前記タスクと、前記実行された案件において前記タスクが見直されたか否かを示す有無値と、過去の前記案件に対する事後の評価を示す値である評価値と、が記憶される第１のデータベースと、
   過去の前記案件に関連付けて、過去の前記案件の仕様の項目、変更前の項目値及び変更後の項目値が記憶される第２のデータベースと、
   が格納される記憶部と、
   前記案件についての仕様の項目、変更前の項目値及び変更後の項目値を受け付け、
   前記受け付けた仕様の項目、変更前の項目値及び変更後の項目値に基づいて、前記第２のデータベースを検索し、前記仕様の項目、変更前の項目値及び変更後の項目値が所定の基準を満たす程度に類似する過去の前記案件を取得し、
   前記取得した案件についてのレコードを前記第１のデータベースから抽出し、
   前記抽出したレコードについて、前記有無値に対して乗じられる係数を悪影響度とし、
   前記抽出したレコードのタスクごとに、前記有無値に前記悪影響度を乗じた値の総和を算出し、前記算出した総和と前記評価値との差分を算出することによって、前記取得した前記案件について最適化された前記悪影響度を前記タスクごとに算出し、
   前記算出した悪影響度が大きくなるほど小さくなる信頼度を算出し、
   前記算出した信頼度と所定の閾値との大小関係を比較し、前記比較に基づいて特定された信頼度に対応する前記タスクを、前記案件において見直すべきタスクとして出力する制御部と、
   を有することを特徴とする業務支援装置。
3. 前記第１のデータベースには、
   前記タスクのそれぞれが省略されたか否か又は見直されたか否かを示す有無値に関連付けて、前記タスクのそれぞれが省略された又は見直された根拠が記憶されており、
   前記制御部は、
   前記出力したタスクに関連付けて、前記根拠を出力すること、
   を特徴とする請求の範囲第１項又は第２項に記載に業務支援装置。
4. 前記制御部は、
   前記取得した前記案件のすべてについての前記差分の二乗和が最小になるように、前記悪影響度を最適化すること、
   を特徴とする請求の範囲第１項又は第２項に記載に業務支援装置。
5. 業務プロセスを構成する複数のタスクのそれぞれが、前記業務プロセスに従って実行される案件に対して及ぼす影響を算出する業務支援装置の業務支援方法であって、
   前記業務支援装置の記憶部は、
   過去の前記案件に関連付けて、前記タスクと、前記実行された案件において前記タスクが省略されたか否かを示す有無値と、過去の前記案件に対する事後の評価を示す値である評価値と、が記憶される第１のデータベースと、
   過去の前記案件に関連付けて、過去の前記案件に対して要求された仕様が記憶される第２のデータベースと、
   を格納しており、
   前記業務支援装置の制御部は、
   新たな前記案件について要求される仕様を受け付け、
   前記受け付けた仕様に基づいて、前記第２のデータベースを検索し、前記仕様が所定の基準を満たす程度に類似する過去の前記案件を取得し、
   前記取得した案件についてのレコードを前記第１のデータベースから抽出し、
   前記抽出したレコードについて、前記有無値に対して乗じられる係数を悪影響度とし、
   前記抽出したレコードのタスクごとに、前記有無値に前記悪影響度を乗じた値の総和を算出し、前記算出した総和と前記評価値との差分を算出することによって、前記取得した前記案件について最適化された前記悪影響度を前記タスクごとに算出し、
   前記算出した悪影響度と所定の閾値との大小関係を比較し、前記比較に基づいて特定された悪影響度に対応する前記タスクを、新たな前記案件において省略可能であるタスクとして出力すること、
   を特徴とする業務支援方法。
6. 業務プロセスを構成する複数のタスクのそれぞれが、前記業務プロセスに従って実行される案件に対して及ぼす影響を算出する業務支援装置を機能させる業務支援プログラムであって、
   前記業務支援プログラムは、
   前記業務支援装置の記憶部に対し、
   過去の前記案件に関連付けて、前記タスクと、前記実行された案件において前記タスクが省略されたか否かを示す有無値と、過去の前記案件に対する事後の評価を示す値である評価値と、が記憶される第１のデータベースと、
   過去の前記案件に関連付けて、過去の前記案件に対して要求された仕様が記憶される第２のデータベースと、
   を格納させ、
   前記業務支援装置の制御部に対し、
   新たな前記案件について要求される仕様を受け付け、
   前記受け付けた仕様に基づいて、前記第２のデータベースを検索し、前記仕様が所定の基準を満たす程度に類似する過去の前記案件を取得し、
   前記取得した案件についてのレコードを前記第１のデータベースから抽出し、
   前記抽出したレコードについて、前記有無値に対して乗じられる係数を悪影響度とし、
   前記抽出したレコードのタスクごとに、前記有無値に前記悪影響度を乗じた値の総和を算出し、前記算出した総和と前記評価値との差分を算出することによって、前記取得した前記案件について最適化された前記悪影響度を前記タスクごとに算出し、
   前記算出した悪影響度と所定の閾値との大小関係を比較し、前記比較に基づいて特定された悪影響度に対応する前記タスクを、前記新たな前記案件において省略可能であるタスクとして出力する処理を実行させること、
   を特徴とする業務支援プログラム。

Images