JPWO2018225228A1 - プロセス管理システムおよびプロセス管理方法 - Google Patents

Abstract

記憶装置は、過去プロジェクトに関する、前提プロセスの情報を含む過去プロジェクト情報と、担当者の過去プロジェクト実行中の行動を示す過去人間行動情報と、摘出不具合およびその作り込みプロセスの情報を含む過去不具合情報とを記録する。処理装置は、過去プロジェクトに含まれる各プロセスを次プロセスとし、次プロセスを作り込みプロセスとする摘出不具合に関する過去次プロセス不具合件数情報と、過去人間行動情報から求まる、前提プロセスにおいて実施されたレビューの過去前提プロセス対話状況との相関度を算出して第１の係数情報とし、現在プロジェクトにおける前提プロセスのレビューに関する入力前提プロセス対話状況との相関度が最も高い次プロセス不具合件数を第１の係数情報に基づいて取得し、次プロセス不具合件数に応じて、現在のプロジェクトの次プロセスにおけるレビューの追加要否を判定する。

Description

本発明は、プロセスの改善を支援する技術に関する。

製造業では、グローバルな競争激化により、コスト低減、納期短縮が求められている。また、製造業の業務の内、上流の設計業務がコストの７割を決めている状況である。しかし、その設計業務における作業手順（プロセス）の属人化、技術継承の遅れ、レビュー実施時間の不足が原因で、レビュー時に摘出しきれなかった不具合が後工程で発生し、手戻りあるいは工程遅延が発生している。

従来の業務プロセスの改善を目的としたシステムでは、過去の類似プロセスにおける進捗状況あるいは発生した不具合に関する実績情報を蓄積し、参照することによって、作業開始前に自動でＷＢＳ（Ｗｏｒｋ Ｂｒｅａｋｄｏｗｎ Ｓｔｒｕｃｔｕｒｅ）を提案する。また、作業の進捗状況として遅延があればメールで作業者に注意を喚起する。しかし、決まったプロセスとスケジュールに従って作業するだけでは、レビューの品質を向上したり、作業の引き継ぎの正確さを向上したりすることはできない。そのため、レビューで不具合を十分に摘出できず、あるいは作業の引き継ぎ不足により発生する不具合を効果的に削減することができない。

これに対して、特許文献１には、人間の行動を分析し、業務の品質向上に役立てる技術が開示されている。特許文献１の技術では、作業者にウェアラブル端末を装着させ、様々な作業中の情報を取得する。具体的には、ウェアラブル端末から、作業者が誰と対面したかなどに関する対面データ、および作業者がどのような行動をしたかを表す加速度データなどの個人情報を取得する。その個人情報を分析し、作業者個人の業務の質、作業者が他者と行った対話に対する積極性、および複数の作業者が属する組織としての業務品質を示す指標が算出される。

また、特許文献２には、業務プロセスを改善するための技術が開示されている。特許文献２の開発プロセス評価管理システムは、
レビューにかけるべき工数であるレビュー工数と、レビューを実施すべき時期であるレビュー時期を開発工程毎のスケジュールに設定しておき、レビューの実施状況の情報の入力を受け、レビューが適切な時期に適切な工数をかけて実施されているか判定し、判定結果を管理者に通知する。管理者はレビューが適切に実施されているか否かを知得することができ、業務プロセスの改善に役立てることができる。

国際公開ＷＯ２００９／１４５１８７号 特開２０１１−１４５９８２号

特許文献１の人間行動分析システムを導入すれば、ウェアラブル端末から取得した対面データや加速度データなどの個人情報により、個人の業務の質および対話積極性と複数のユーザが属する組織の業務品質指標とを算出できる。特許文献１の技術では、レビュー時の対話積極性を算出するので、レビューを実施したかを判定することが可能である。しかし、特許文献１の技術では、レビューを実施した時間（レビュー時間）と摘出した不具合の件数（不具合件数）との関係を分析しない。不具合を十分に摘出するのに十分な時間のレビューを実施したか否かを判断することができない。

特許文献２の開発プロセス評価管理システムは、開発のそれぞれの工程のスケジュールにレビュー工数とレビュー時期を予め設定しておき、実際のレビューの実施状況を判定し、判定結果を管理者に通知する。この開発プロセス評価管理システムは、工程毎に予め設定された、全体工数のうちレビューの工数がどの程度の割合を占めるかレビュー比率と、工程毎に要した工数とに基づいて適切なレビュー工数とレビュー時期を算出する。しかし、特許文献２のシステムでは、同じ工数をレビューにかけてもプロジェクトに参加しているメンバー毎に他のメンバーとどの程度情報が共有されるかが異なることが考慮されていない。そのため、レビューにおけるメンバーの貢献の程度に応じた適切なレビューの提案ができない。

本発明の目的は、不具合を摘出するのに十分な対話を実施したか否かを判定でき、かつ、メンバー個人のレビューの貢献の程度に応じてレビューの実施を提案することを可能にする技術を提供することである。

本発明の一つの実施態様に従うプロセス管理システムは、過去に実施したプロジェクトである過去プロジェクトに関する、該過去プロジェクトに含まれる複数のプロセスのそれぞれを実行するための前提となるプロセスである前提プロセスの情報を含む過去プロジェクト情報と、前記過去プロジェクトの各プロセスを担当する者の該過去プロジェクト実行中の行動を示す過去人間行動情報と、前記過去プロジェクトにおいて摘出された不具合である摘出不具合および該摘出不具合の原因が作り込まれたプロセスである作り込みプロセスの情報を含む過去不具合情報とを記録する記憶装置と、前記過去プロジェクトに含まれる各プロセスを次プロセスとし、前記次プロセスを作り込みプロセスとする摘出不具合の件数に関する情報である過去次プロセス不具合件数情報と、前記過去人間行動情報から求まる、該次プロセスの前提プロセスにおいて実施されたレビューの参加者の属性、時期、および時間を含む過去前提プロセス対話状況との相関度を算出して第１の係数情報とし、追加レビュー要否判定の入力とする、評価対象のプロジェクトである現在プロジェクトにおける前提プロセスのレビューに関する対話状況である入力前提プロセス対話状況との相関度が最も高い、次プロセスで作り込まれる不具合の件数である次プロセス不具合件数を前記第１の係数情報に基づいて取得し、取得した前記次プロセス不具合件数に応じて、前記現在のプロジェクトの次プロセスにおけるレビューの追加要否を判定する処理装置と、を有する。

レビュー参加者個人をパラメータとする対話状況に基づき、過去の実績に基づき次のプロセスで作り込まれる不具合を抑えるのに効果的なレビューが実施されたか否かを判定し、かつ、実施された対話状況に応じてレビューの追加を提案するので、十分なレビューを実施したか否かを判定でき、かつ、参加者個人のレビューの貢献の程度を考慮に入れたレビューの追加実施を提案することができる。

実施例１による業務プロセス管理システムのブロック図である。 業務プロセス管理装置の処理イメージを示す概念図である。 人間行動情報テーブルの一例を示す図である。 不具合情報テーブルの一例を示す図である。 プロジェクト情報テーブルの一例を示す図である。 プロジェクト情報テーブルの一例を示す図である。 プロジェクト情報テーブルの一例を示す図である。 レビュー追加要否判定処理のフローチャートである。 第１の実績情報の一例を示す図である。 第１の係数情報の一例を示す図である。 第１の相関情報リストの一例を示す図である。 追加レビュー条件決定処理のフローチャートである。 追加レビュー参加者属性決定処理のフローチャートである。 追加レビュー時期時間決定処理のフローチャートである。 第１の実績情報からエントリを絞り込む処理について説明するための図である。 第２の係数情報の一例を示す図である。 第２の相関情報リストの一例を示す図である。 追加レビュー参加者人数決定処理のフローチャートである。 第２の実績情報の一例を示す図である。 第３の係数情報の一例を示す図である。 第３の相関情報リストの一例を示す図である。 実施例２において表示されるプロジェクト工程表の一例を示す図である。 実施例３において生成される活発度情報の一例を示す図である。

以下、本発明の実施例について図面を参照して説明する。

実施例１では製造業の設計業務の業務プロセスを管理するシステムを例示する。ここでは、すでにＷＢＳが定義されているプロジェクトにレビューを追加するか否か判定し、必要に応じて追加する例について説明する。ここでいうレビューは複数のユーザによる対話を伴う会合によるレビューである。

図１は、実施例１による業務プロセス管理システムのブロック図である。

図１を参照すると、業務プロセス管理システムは、業務プロセス管理装置１０、人間行動情報取得装置２０、ウェアラブル端末３０、クライアント端末４０、入力装置５０、および出力装置６０を有している。業務プロセス管理装置１０、人間行動情報取得装置２０、およびクライアント端末４０は通信ネットワーク７０を介して通信可能に接続される。通信ネットワーク７０は例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）あるいはＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）あるいはそれらの複合である。人間行動情報取得装置２０とウェアラブル端末３０は無線通信で情報を送受信することができる。入力装置５０および出力装置６０はクライアント端末４０と接続されている。

業務プロセス管理装置１０は、ハードウェアとしては一般的なコンピュータで構成され、中央演算処理装置１１、主記憶装置１２、および補助記憶装置１６を有している。中央演算処理装置１１はＣＰＵである。主記憶装置１２および補助記憶装置１６は中央演算処理装置１１からアクセス可能な記憶装置である。また、業務プロセス管理装置１０は、ソフトウェアにより実現される、実績情報処理部１３、相関度算出部１４、および作業管理部１５を有している。実績情報処理部１３、相関度算出部１４、および作業管理部１５は、それらを実現するソフトウェアプログラムが主記憶装置１２に格納されており、ソフトウェアプログラムを中央演算処理装置１１が実行することにより実現される。補助記憶装置１６には、プロジェクト情報テーブル１０１、不具合情報テーブル１０２、および人間行動情報テーブル１０３が格納されている。プロジェクト情報テーブル１０１、不具合情報テーブル１０２、および人間行動情報テーブル１０３には、過去に実行されたプロジェクトの実績情報から現在実行中のプロジェクトの情報まで格納されている。これらのテーブルは業務プロセス管理装置１０が業務プロセスを管理する各種処理を実行するために利用される。

実績情報処理部１３は、過去に実行されたプロジェクトにおける各種実績情報のうち処理に必要な情報を補助記憶装置１６の上記各種テーブルから取得し、作業管理部１５に提供する。作業管理部１５は、複数のプロセスからなるプロジェクトの計画を作成し、必要に応じて計画を更新し、更にプロセスの実行を管理する。それに伴い、作業管理部１５は、プロジェクト情報テーブル１０１、不具合情報テーブル１０２、および人間行動情報テーブル１０３を作成し、更新する。相関度算出部１４は、作業管理部１５から指示された相関度に関する演算を実行する。

ウェアラブル端末３０は、各プロセスを担当するユーザ（担当者）が着用する首下げ式のウェアラブル端末である。ウェアラブル端末３０は、ユーザの行動を示す人間行動情報を取得し、人間行動情報取得装置２０経由で業務プロセス管理装置１０に通知する。具体的には、ウェアラブル端末３０は、不図示の加速度センサを備え、ユーザの身体の動きを示す加速度情報を取得し、ユーザの活動状態を算出し、人間行動情報取得装置２０経由で業務プロセス管理装置１０に通知する。

また、ウェアラブル端末３０は、ユーザの視界に入る前方の画像を撮影し、画像データから、ウェアラブル端末３０を着用しているユーザに対面している対面者の人数および個人名を判定し、人間行動情報取得装置２０経由で業務プロセス管理装置１０に通知する。例えば、首下げ式のウェアラブル端末３０の表側に、対面するユーザのウェアラブル端末３０から読み取り可能な個人情報を表示してもよい。対面するユーザのウェアラブル端末３０が相互に相手の個人情報を読み取り、対面者を判別することができる。

また、ウェアラブル端末３０は、不図示のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機を備え、ユーザの現在位置を算出し、音声データを人間行動情報取得装置２０経由で業務プロセス管理装置１０に通知する。また、ウェアラブル端末３０は、不図示のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機を備え、ユーザの現在位置を算出し、音声データを人間行動情報取得装置２０経由で業務プロセス管理装置１０に通知する。

人間行動情報取得装置２０は、ウェアラブル端末３０から取得した人間行動情報を業務プロセス管理装置１０に送信する。例えば、人間行動情報取得装置２０は、定期的にウェアラブル端末３０にアクセスして人間行動情報を読み出し、業務プロセス管理装置１０に送信することにしてもよい。

クライアント端末４０は、業務プロセス管理装置１０を管理者が利用するための端末であり、ハードウェアとして中央処理装置４１および主記憶装置４２を有している。管理者はクライアント端末４０を利用して、例えば業務プロセス管理装置１０に情報を登録したり、業務プロセス管理装置１０に蓄積された情報を参照したりすることができる。クライアント端末４０は、ソフトウェアにより実現される画面表示部４３を有している。画面表示部４３を実現するソフトウェアプログラムは主記憶装置４２に格納されており、中央処理装置４１により実行される。入力装置５０はクライアント端末４０に付属するキーボードおよびマウスなどの入力装置である。管理者は入力装置５０を操作することでクライアント端末４０を利用することができる。出力装置６０はクライアント端末４０に付属するディスプレイなどの出力装置である。クライアント端末４０の処理結果などが出力装置６０に表示される。

図２は、業務プロセス管理装置の処理イメージを示す概念図である。

過去に実行されたプロジェクトの実績情報は予め補助記憶装置１６の人間行動情報テーブル１０３、プロジェクト情報テーブル１０１、および不具合情報テーブル１０２に蓄積されている。新たなプロジェクトの計画から実行まで、作業管理部１５により、当該プロジェクトの情報の作成および蓄積が行われる。

プロジェクト実行中に各プロセスのユーザが着用しているウェアラブル端末３０はユーザが特に操作をしなくても自動的に人間行動情報２０２を取得し、業務プロセス管理装置１０に送信する。業務プロセス管理装置１０には、ウェアラブル端末３０から人間行動情報２０２が入力される。一例として、人間行動情報２０２には、ウェアラブル端末３０を着用しているユーザの個人名、ユーザが対面している対面者、対面者の人数、ユーザがいる場所、ユーザの活動状態の情報が含まれている。業務プロセス管理装置１０では、作業管理部１５が、受信した人間行動情報２０２を人間行動情報テーブル１０３に蓄積する。

また、クライアント端末４０は、プロジェクトの計画段階において、業務プロセスを管理するユーザ（管理者）の操作に従い、プロジェクト情報２０１を業務プロセス管理装置１０に送信する。一例として、プロジェクト情報２０１には、プロジェクトの名称、プロジェクトに含まれる各プロセスの種別、プロセス同士の関係、各プロセスの進捗の実績、各プロセスの担当者、各プロセスの成果物、ＷＢＳ情報が含まれる。プロセスの種別の例として、レビュー、成果物作成、検討などがある。プロセス同士の関係として、あるプロセス（後続プロセス）を実行するために他のプロセス（前提プロセス）が完了していることが必要とされるという前提／後続関係がある。ＷＢＳ情報は、プロジェクトとプロセスの関係を示す構造情報である。また、クライアント端末４０は、プロジェクトの実行段階において、管理者の操作あるいは他の方法で取得したプロセスの進捗実績を送信する。業務プロセス管理装置１０では、作業管理部１５がクライアント端末４０から受信したプロジェクト情報２０１をプロジェクト情報テーブル１０１に記録する。

また、業務プロセス管理装置１０は、作業管理部１５により、例えば現在実行中のプロジェクトを評価対象として、そのプロジェクトのプロジェクト情報テーブル１０１におけるレビューの設定を評価し、十分に不具合を摘出するためにレビューを追加する必要があるか否か判定する。その際、業務プロセス管理装置１０は、評価対象のプロジェクトにおいて取得された人間行動情報テーブル１０３を判定に利用する。人間行動情報テーブル１０３から各プロセスを担当しているユーザのレビューにおける行動が分かり、レビューがどの程度有効に不具合摘出を実現しているかが分かる。

また、業務プロセス管理装置１０は、過去のプロジェクトの実績情報を判定に活用する。具体的には、業務プロセス管理装置１０は、補助記憶装置１６に蓄積している過去のプロジェクトにおいて取得された実績情報である人間行動情報２０２、プロジェクト情報２０１、および不具合情報を、レビュー追加の要否判定に活用する。実績情報により、過去の実績として、どの時期にどのぐらいの時間をかけてレビューを行ったことで不具合をどの程度事前に摘出できたかが分かる。

業務プロセス管理装置１０は、レビューの追加が必要と判定したら、追加のレビューをどの時期にどのぐらいの時間をかけて行うべきか、追加のレビューに参加すべきメンバー等、追加のレビューを設定するのに必要な情報を生成し、レビューを追加した提案ＷＢＳ情報２０３、追加を提案するレビューの設定に関するレビュー情報２０４を出力する。出力された情報は、クライアント端末４０に付属する出力装置６０に表示される。ＷＢＳ情報２０３は、プロジェクトにおける各プロセスと各プロセスに含まれる子プロセスを実行順序と本願関係を表した情報であり、例えば、プロジェクト、プロセス、子プロセスをノードとする階層構造ツリーで表現される。

図３は、人間行動情報テーブルの一例を示す図である。人間行動情報テーブル１０３には各ユーザの行動を示す人間行動情報２０２が記録される。図３の人間行動情報テーブル１０３は、過去に実行されたプロジェクトにおいて取得された実績の人間行動情報２０２を示す。現在実行中のプロジェクトで取得された人間行動情報２０２も人間行動情報テーブル１０３に記録される。

図３を参照すると、人間行動情報テーブル１０３には、個々のユーザを特定する個人識別情報として「個人名」と、ユーザが行動をした日時を示す「日時」と、ユーザがした行動を示す「活動状態」と、ユーザが対面していた他のユーザの人数を示す「対面人数」と、ユーザが対面していた他のユーザの個人名を示す「対面者」と、ユーザが行動をした場所を示す「場所」という項目が含まれている。ユーザの行動はウェアラブル端末３０で取得された加速度データを基に判定され、「活動状態」に設定される。「活動状態」に含まれる項目として、「個人作業」、「発言」、「双方向」、「聞き手」などがある。「個人作業」はユーザが個人で何らかの作業を行うという行動を示す。「発言」は、レビューなどの会合にてユーザが発言するという行動を示す。「双方向」は、会合にてユーザが他のユーザと双方向の対話をするという行動を示す。「聞き手」は、会合にてユーザが他のユーザの発言を聞くという行動を示す。

例えば、図３の一番上のエントリ（行）には、個人名Ａというユーザが、日時２０１５／０２／１４：１０：００に、執務室にて、対面者のいない個人作業という行動を行ったことが示されている。

図４は、不具合情報テーブルの一例を示す図である。不具合情報テーブル１０２には、プロジェクトの各プロセスで摘出された不具合を示す不具合情報が記録される。図４の不具合情報テーブル１０４は、過去に実行されたプロジェクトにおいて摘出された不具合の実績の不具合情報を示す。現在実行中のプロジェクトにおいて摘出された不具合の不具合情報も不具合情報テーブル１０２に記録される。

図４を参照すると、不具合情報テーブル１０２には、個々のプロジェクトを特定する「プロジェクト名称」と、摘出された不具合の内容を示す「不具合内容」と、不具合が摘出されたプロセスを示す「摘出プロセス」と、不具合の原因が作り込まれたプロセスを示す「作り込みプロセス」という項目が含まれている。「不具合内容」として、「テーブルの定義に誤りがある」、「画面遷移図が不足している」、「エラー時の挙動について明記していない」、「クライアントとサーバのエラーが区別できない」、「エラー表示用の画面がない」、「入力チェックの内容が記載されていない」というものなどがある。通常、不具合は仕様の中に作り込まれて設計書などの成果物に反映され、レビューにて摘出されるので、「摘出プロセス」の多くはレビューのプロセスとなり、「作り込みプロセス」は設計書などの成果物を作成するプロセスとなる。

例えば、図４の一番上のエントリには、プロジェクト名称ＸＸ開発というプロジェクトの基本設計書作成というプロセスで、テーブルの定義に誤りがある、という不具合が作り込まれ、基本設計書レビューというプロセスで摘出されたことが示されている。

図５、図６、図７は、プロジェクト情報テーブルの一例を示す図である。本実施例では、プロジェクト情報テーブル１０１は、プロジェクト情報テーブル１０１ａ、１０１ｂ、１０１ｃという３つのテーブルで構成されている。図５、図６、図７には、過去に実行されたプロジェクトのプロジェクト情報テーブル１０１を示すが、現在実行中の評価対象のプロジェクト情報２０１もプロジェクト情報テーブル１０１記録される。

図５には、プロジェクトに含まれるプロセスに関する情報が記録されるプロジェクト情報テーブル１０１ａが示されている。プロジェクトに含まれるプロセスに関する情報は、具体的にはプロジェクトのＷＢＳ情報である。ＷＢＳ情報は、プロジェクト開始時に、ユーザが業務プロセス管理装置１０に登録し、蓄積する。業務プロセス管理装置１０が追加のレビューを提案し、ユーザがそれを採用した場合、追加のレビューに関するデータがプロジェクト情報テーブル１０１ａに追加される。

図５を参照すると、プロジェクト情報テーブル１０１ａには、「プロジェクト名称」、「プロセス名称」、「子プロセス名称」、「成果物」、「種別」、「前提プロセス」、「プロセス順番」、「システムで提案したプロセス」という項目がある。

「プロジェクト名称」には、評価対象のプロジェクトを識別する名称が記録される。「プロセス名称」には、プロジェクトに含まれる各プロセスを識別する名称が記録される。プロセスには更に子プロセスが含まれる場合がある。「子プロセス名称」には、プロセスに含まれる子プロセスを識別する名称が記録される。「成果物」には子プロセスにおいて作成される成果物を示す情報が記録される。「種別」には、子プロセスで行う作業の種別が記録される。「種別」としては、「検討」、「成果物作成」、「レビュー」のいずれが登録される。「レビュー」の場合には更に、当該プロセスにおいてレビューを実施する時期を示す情報も登録される。レビューの実施時期として、完成レベルの成果物ができた段階でレビューを行うことを示す「（完成レベル）」、第一版の成果物ができた段階でレビューを行うことを示す「（第一版）」などがある。

「前提プロセス」には、その子プロセスを実行するための前提となるプロセスを識別する名称が記録される。子プロセスの種別がレビューであれば、「前提プロセス」には、レビューで検査する成果物を作成する子プロセスの名称が「前提プロセス」に記載される。子プロセスの種別がレビュー以外であれば、「前提プロセス」には、子プロセスを実行する前提として終了しておくべき他の子プロセスの名称が「前提プロセス」に記載される。例えば、「基本設計書作成」という子プロセスで作成する成果物が基本設計書であり、この基本設計書が「機能実現方式検討」という子プロセスの作業のインプット情報となる場合、「基本設計書作成」という子プロセスが「機能実現方式検討」という子プロセスの「前提プロセス」となる。

「プロセス順番」には、各子プロセスの実行順序を示す順序番号が記録される。この子プロセスの順序番号は、業務プロセス管理装置１０が自動的に付与する。ＷＢＳ情報２０３の階層構造ツリーの子プロセスの各ノードに先頭から順番に付与される。「システムで提案したプロセス」には、業務プロセス管理装置１０が追加を提案したプロセスであるか否かを示すフラグが記録される。業務プロセス管理装置１０が追加を提案したレビューの子プロセスの「システムで提案したプロセス」には「１」が記録され、予め設定されていた子プロセスの「システムで提案したプロセス」には「０」が記録される。

図６には、プロセスの担当者およびスケジュールに関する情報が記録されるプロジェクト情報テーブル１０１ｂが示されている。プロセスの担当者は、子プロセスごとの担当者を示す情報であり、プロジェクト開始時にユーザが登録する。スケジュールは、具体的には、予定したスケジュール（予定スケジュール）と実行されたスケジュール（実績スケジュール）を含む予定実績情報である。予定スケジュールはプロジェクト開始時にユーザが設定し、実績スケジュールはプロジェクトが進捗する過程で業務プロセス管理装置１０が記録する。

図６を参照すると、プロジェクト情報テーブル１０１ｂには、「プロジェクト名称」、「プロセス名称」、「子プロセス名称」、「担当者数」、「担当者」、「開始日(予定)」、「開始日(実績)」、「完了日(予定)」、「完了日(実績)」という項目がある。「プロジェクト名称」、「プロセス名称」、および「子プロセス名称」は図５に示したプロジェクト情報テーブル１０１ａのものと同じものである。

「担当者数」には、当該子プロセスの担当者の人数が記録される。「担当者」には、当該子プロセスの担当者を識別する個人名が記録される。

「開始日(予定)」には、当該子プロセスの開始が予定された日が記録される。「開始日(実績)」には、当該子プロセスが実際に開始された日が記録される。「完了日(予定)」には、当該子プロセスの完了が予定された日が記録される。「完了日(実績)」には、当該子プロセスが実際に完了した日が記録される。

図７には、プロセスで摘出される予定の不具合に関する情報が記録されるプロジェクト情報テーブル１０１ｃが示されている。プロジェクト情報テーブル１０１ｃはプロセス毎に不具合が摘出される予定の件数を蓄積するテーブルである。本テーブルはプロジェクト開始時にユーザが登録する。

図７を参照すると、プロジェクト情報テーブル１０１ｃには、「プロジェクト名称」、「プロセス名称」、「摘出予定の不具合件数」という項目がある。「プロジェクト名称」および「プロセス名称」は、プロジェクト情報テーブル１０１ａ、１０１ｂのものと同じである。「摘出予定の不具合件数」は、当該子プロセスにて不具合が摘出される予定の件数である。

図８は、レビュー追加要否判定処理のフローチャートである。

レビュー追加要否判定処理は例えば実行中のプロジェクトにおいて１つのプロセスが完了する毎に実行される（ステップＳ１０１）。作業管理部１５は、まず、次に実施するプロセスの種別がレビューかそれ以外かを判定する（ステップＳ１０２）。次のプロセスがレビューの場合は、作業管理部１５はレビューの追加は不要と判断し（ステップＳ１１６）、処理を終了する。一方、次のプロセスがレビュー以外のプロセスである場合、作業管理部１５はステップＳ１０３に進む。

実績情報処理部１３はステップＳ１０３〜Ｓ１０７の５つのステップで（１）〜（５）の５つの情報をそれぞれ取得する。

実績情報処理部１３は、まず（１）ステップＳ１０３〜（３）ステップＳ１０５にて、次プロセスと同じ名称の過去のプロセス（プロセス１とする）についての情報を取得する。

（１）ステップＳ１０３
不具合情報テーブル１０２を参照し、プロセス１にて作り込まれた不具合の件数を取得する。

（２）ステップＳ１０４
プロジェクト情報テーブル１０１を参照し、プロセス１の作業期間と担当者を取得する。作業期間は、開始日（実績）から完了日（実績）までの期間である。

（３）ステップＳ１０５
人間行動情報テーブル１０３を参照し、プロセス１の作業期間中の担当者間の対話時間を取得する。その際、ステップＳ１０４で取得した作業期間と担当者の情報を利用して、人間行動情報テーブル１０３から、作業期間中の担当者の行動の情報を抽出し、抽出した情報から対話時間を算出する。

続いて、実績情報処理部１３は、（４）ステップＳ１０６、（５）ステップＳ１０７にて、次プロセスの前提プロセスと同じ名称の過去のプロセス（プロセス２とする）についての情報を取得する。

（４）ステップＳ１０６
プロジェクト情報テーブル１０１を参照し、プロセス２の作業期間と担当者を取得する。作業期間は、開始日（実績）から完了日（実績）までの期間である。

（５）ステップＳ１０７
人間行動情報テーブル１０３を参照し、プロセス２の作業期間中の担当者間の対話時間を取得する。その際、ステップＳ１０６で取得した作業期間と担当者の情報を利用して、人間行動情報テーブル１０３から、作業期間中の担当者の行動の情報を抽出し、抽出した情報から対話時間を算出する。

続いて、作業管理部１５が、ステップＳ１０１〜Ｓ１０７で取得された情報を用いて、第１の実績情報を作成する（ステップＳ１０８）。

図９は、第１の実績情報の一例を示す図である。第１の実績情報３０１には、「不具合件数範囲」、「前提プロセスの時期および対話時間」、「次プロセスの時期および対話時間」、「参加担当者属性」という項目がある。

「不具合件数範囲」には、ステップＳ１０３にて取得された不具合件数が複数の件数範囲に離散化して設定される。図９の例では、不具合件数範囲として、「０〜９件」、「１０〜１９件」・・・が用いられている。該当する不具合件数範囲には「１」が設定され、それ以外の不具合件数範囲には「０」が設定される。

「前提プロセスの時期および対話時間」には、ステップＳ１０５にて取得された対話時間を複数の時間範囲に離散化し、ステップＳ１０４にて取得された作業期間を対話の種別に分類した情報が設定される。図９の例では、対話時間は「０〜２ｈ（時間）」、「２ｈ〜４ｈ」、「４ｈ〜６ｈ」・・・に離散化されている。ここで「０〜２ｈ」は０時間以上２時間未満を意味し、「２ｈ〜４ｈ」は２時間以上４時間未満を意味し、「４ｈ〜６ｈ」は４時間以上６時間未満を意味するものとする。

プロセスの時期は、レビューによる検査対象の成果物の版数により表現されている。具体的には、成果物を作成する前の時期を示す「事前」、成果物の目次ができてそれを検査する段階を示す「目次レベル」、成果物の第一版ができてそれを検査する段階を示す「第一版レベル」、成果物が完成しそれを検査する段階を示す「完成レベル」がある。

「次プロセスの時期および対話時間」には、ステップＳ１０７にて取得された対話時間を複数の時間範囲に離散化し、ステップＳ１０６にて取得された作業期間を対話の種別に分類した情報が設定される。図９の例では、対話時間は「０〜２ｈ」、「２ｈ〜４ｈ」、「４ｈ〜６ｈ」・・・に離散化されている。作業期間の分類は、レビューによる検査対象の成果物の版数で表現された作業の分類となっている。具体的には、成果物を作成する前の時期を示す「事前」、成果物の目次ができてそれを検査する段階を示す「目次レベル」、成果物の第一版ができてそれを検査する段階を示す「第一版レベル」、成果物が完成しそれを検査する段階を示す「完成レベル」がある。

「参加担当者属性」は、次プロセスのレビューに参加した担当者がどのプロセスの担当者なのかを示す情報が記載されている。「参加担当者属性」の情報として「前提／次プロセス担当」と「同じプロセス担当」とがある。参加担当者の属性（担当プロセス）が該当する項目には「１」が設定され、該当しない項目には「０」が設定される。「参加担当者属性」には、ステップＳ１０４で取得された担当者の属性の情報とステップＳ１０６にて取得された担当者の属性の情報に基づき、次プロセスのレビューに参加した担当者の属性に関する情報が設定される。例えば、レビューに前提プロセスの担当者と次プロセスの担当者が参加した場合には「前提／次プロセス」に「１」に設定され、レビューに次プロセスの担当者同士が参加した場合には「同じプロセス担当」に「１」が設定される。「前提／次プロセス」と「同じプロセス担当」の両方に「１」が設定されることもありうる。

図８に戻り、続いて、作業管理部１５は、不具合件数範囲を目的変数とし、前提プロセスの時期および対話時間と参加担当者属性とを説明変数とする目的関数を用いた重回帰分析により、不具合件数範囲毎に前提プロセスの時期および対話時間と参加担当者属性との相関度を算出する（ステップＳ１０９）。作業管理部１５は、算出結果に基づいて第１の係数情報を生成する。

図１０は、第１の係数情報の一例を示す図である。図１０のテーブルには、ある不具合件数範囲（例えば「０〜９件」）についての第１の係数情報３０２が示されている。図１０を参照すると、第１の係数情報３０２は、目的変数である不具合件数範囲と、説明変数である参加担当者属性、前提プロセスの時期および対話時間との相関度を示す情報である。相関度は係数とＰ値とにより示されている。係数は目的変数と説明変数の間にどれだけ相関があるかを示す係数である。Ｐ値は、その目的変数および説明変数の値の組み合わせが起こりうる確率を示している。

図１０のテーブルにおける一番上のエントリの例は、参加担当者属性は前提／次プロセス担当であり、前提プロセスの時期および対話時間は事前の対話が０〜２ｈであり、目次レベルでの対話が０〜２ｈであり、第１版レベルの対話が０〜２ｈであり、・・・である場合における、不具合件数という目的変数と、参加担当者属性、前提プロセスの時期および対話時間という説明変数との相関度は、係数が＋３．５であり、Ｐ値が０．２であるということを示している。

続いて、作業管理部１５は、第１の係数情報３０２に基づいて第１の相関情報リストを生成する（ステップＳ１１０）。第１の相関情報リストは、不具合件数範囲と相関度の高い参加担当者属性、時期および対話時間の値の組のリストを示す情報である。

図１１は、第１の相関情報リストの一例を示す図である。第１の相関情報リスト３０３には、参加担当者属性ごとにエントリを挙げることにしてもよい。図１１に示した第１の相関情報リスト３０３の一番上のエントリには、不具合件数範囲０〜９件である場合にその目的変数と相関度の高い説明変数の値の組は、参加担当者属性が前提／次プロセス、事前のレビューの対話時間が２〜４ｈであり、目次レベルのレビューの対話時間が０〜２ｈであり、第１版レベルのレビューの対話時間が０〜２ｈであることを示している。なお、ここでは、Ｐ値が所定値以上ありかつ係数の値が大きい場合に相関度が高いと判断することにする。

作業管理部１５は、ステップＳ１１１とステップＳ１１２で（１）（２）の２つの情報をそれぞれ取得する。作業管理部１５は、まず（１）ステップＳ１１１にて、プロジェクト情報テーブル１０１より、次プロセスの前提プロセス（プロセス３とする）の作業期間および担当者の情報を取得する。作業期間は、実績としての開始日から完了日までの期間である。作業管理部１５は、次に（２）ステップＳ１１２にて、人間行動情報テーブル１０３より、担当者間の対話時間の情報を取得する。その際、作業管理部１５は、ステップＳ１１１で取得した作業期間と担当者の情報を利用して、人間行動情報テーブル１０３から、作業期間中の担当者の行動の情報を抽出し、抽出した情報から対話時間を算出する。

次に、作業管理部１５は、第１の相関情報リスト３０３とプロセス３の条件とに基づき、次のプロセスで作りこまれる不具合の件数を予測する（ステップＳ１１３）。その際、作業管理部１５は、第１の相関情報リスト３０３から、説明変数の値の組がプロセス３の条件に合致するエントリの不具合件数範囲の情報を取得し、その不具合件数範囲を代表される値を、次プロセスで作りこまれる不具合の件数の予測値とすればよい。

次に、作業管理部１５は、次プロセスで作りこまれる不具合件数の予測値を所定の閾値と比較する（ステップＳ１１４）。閾値はシステムに課される条件などに応じて適宜設定される。不具合件数の予測値が閾値より多ければ（ステップＳ１１４のＹｅｓ）、作業管理部１５は、レビューを追加すべきと判定する（ステップＳ１１５）。不具合件数の予測値が閾値以下であれば（ステップＳ１１４のＮｏ、作業管理部１５は、レビューを追加する必要はないと判定する（ステップＳ１１６）。

以上説明したレビュー追加要否判定処理にて、レビューを追加すべきと判定したら、追加レビュー条件決定処理を実行することにより、どのような条件のレビューを追加するかを決定する。図１２は、追加レビュー条件決定処理のフローチャートである。

作業管理部１５は、まず、追加するレビューに参加するメンバーの担当者属性を決定する（ステップＳ２０１）。ステップＳ２０１の詳細は図１３を用いて後述する。次に、作業管理部１５は、レビューを行う時期およびレビューにかける時間を決定する（ステップＳ２０２）。ステップＳ２０２の詳細は図１４を用いて後述する。最後に、作業管理部１５は、レビューに参加する担当者の人数を決定する（ステップＳ２０３）。ステップＳ２０３詳細は図１８を用いて後述する。

図１３は、追加レビュー参加者属性決定処理のフローチャートである。第１の相関情報リスト３０３とプロセス３の条件に基づいて、追加するレビューの参加担当者属性を決定する（ステップＳ３０１）。

その際、作業管理部１５は、まず、第１の相関情報リスト３０３から、プロセス３（次プロセスの前提プロセス）の条件に合致するエントリを抽出する。「参加担当者属性」が「前提／次プロセス」であるエントリと「同じプロセス」であるエントリが抽出される可能性がある。次に、作業管理部１５は、抽出されたエントリの不具合件数範囲を所定の閾値と比較する。不具合件数範囲が閾値を超えるエントリがあれば、作業管理部１５は、次に、そのエントリの参加担当者属性の情報を取得する。次に、作業管理部１５は取得した参加担当者属性を、追加するレビューの参加担当者属性と決定する。以上の処理は、次プロセスで作りこまれる不具合の件数が多くなる要因となっている参加担当者属性のレビューの回数を増やし、作りこまれる不具合の摘出を強化する意図である。

図１４は、追加レビュー時期時間決定処理のフローチャートである。作業管理部１５は、ステップＳ３０３で決定した参加担当者属性を処理対象とし、ステップＳ４０２〜Ｓ４０５の処理を処理対象の件数分だけ繰り返し実行する（ステップＳ４０１）。

まず、作業管理部１５は、第１の実績情報３０１から、処理対象となっている参加担当者属性と同じ参加担当者属性に該当し、前提プロセスにおける説明変数の値の組がプロセス３の条件（説明変数の値の組）に合致するエントリを抽出する（ステップＳ４０２）。これは、蓄積された過去の実績の情報を、参加担当者属性が処理対象と同じであり、前提プロセスが現在実施中のプロジェクトのものと同じ条件であるもののみに絞り込む処理である。

図１５は、第１の実績情報からエントリを絞り込む処理について説明するための図である。図１５を参照すると、楕円により囲まれた部分がステップＳ４０２においてエントリを絞り込む条件となる部分である。四角形で囲まれた部分が、絞り込まれたエントリから取得したい情報である。楕円で示された部分により前提プロセスの時期および対話時間と参加担当者属性とにより絞り込みが行われる。

次に、作業管理部１５は、ステップＳ４０２で第１の実績情報３０１から抽出されたエントリを対象とし、次プロセスで作り込まれる不具合についての不具合件数範囲ごとに、その不具合件数範囲を目的変数とし、次プロセスの時期および対話時間と参加担当者属性とを説明変数とする重回帰分析により、不具合件数範囲の値と次プロセスの時期および対話時間の値の組との相関度を算出する（ステップＳ４０３）。図１５における四角形で囲まれた部分の情報を用いて相関度が算出される。説明変数である次プロセスの時期および対話時間と、算出した相関度との対応づけが第２の係数情報として記録される。

図１６は、第２の係数情報の一例を示す図である。図１６には、ある不具合件数範囲（例えば「０〜９件」）についての第２の係数情報４０１が示されている。実際は、図１６に示したような情報が各不具合件数範囲のそれぞれに対して生成される。図１６を参照すると、第２の係数情報４０１には、説明変数である次プロセスでのレビューの時期および対話時間の値の組と、その値の組と不具合件数範囲との相関度とが示されている。相関度は係数とＰ値で示されている。例えば、一番上のエントリには、次のプロセスでのレビューの時期および対話時間は、事前のレビューが０〜２ｈで、目次レベルでのレビューが０〜２ｈで、第１版レベルでのレビューが０〜２ｈである場合、それらの値の組と不具合件数範囲（例えば「０〜９件」）と相関度は、係数が＋３．５であり、Ｐ値が０．２であるということが示されている。

次に、作業管理部１５は、ステップＳ４０３で生成した第２の係数情報４０１から、相関度が最も高い時期および対話時間の値の組を抽出してリスト化し、第２の相関情報リスト４０２を生成する（ステップＳ４０４）。図１７は、第２の相関情報リストの一例を示す図である。第２の相関情報リスト４０２には、不具合件数範囲と、その不具合件数範囲との相関度の最も高い次プロセスにおけるレビューの時期および対話時間の値の組とが示されている。図１７の一番上のエントリには、不具合件数範囲０〜９件と最も相関度の高い次プロセスのレビューの時期および対話時間は、事前のレビューが２〜４ｈで、目次レベルのレビューが０〜２ｈで、第１版レベルのレビューが０〜２ｈであるということが示されている。

次に、作業管理部１５は、ステップＳ４０４で生成した第２の相関情報リスト４０２から、次プロセスで作り込まれる不具合の件数が減る時期および対話時間を取得し、追加するレビューの時期および時間とする（ステップＳ４０５）。次プロセスで作り込まれる不具合の件数が減る時期および対話時間は、例えば、第２の相関情報リスト４０２から、不具合件数範囲が所定の閾値以下のエントリを選択し、そのエントリの時期および対話時間の情報を取得すればよい。あるいは、第２の相関情報リスト４０２から、不具合件数範囲が最も小さい（図１７の例では不具合件数範囲が０〜９件）エントリを選択し、そのエントリの時期および対話時間の情報を取得してもよい。あるいは、第２の相関情報リスト４０２から、予想されている件数よりも少ない不具合件数範囲のエントリを選択し、そのエントリの時期および対話時間の情報を取得してもよい。

図１８は、追加レビュー参加者人数決定処理のフローチャートである。作業管理部１５は、ステップＳ４０５で決定した追加レビューの時期を処理対象とし、ステップＳ５０２〜Ｓ５０８の処理を処理対象の件数分だけ繰り返し実行する（ステップＳ５０１）。

作業管理部１５は、ステップＳ５０２〜Ｓ５０４にて、過去に実施されたプロジェクトにおける次プロセスと同じ名称のプロセスについて、（１）〜（３）という３つの情報を取得する。

まず、（１）ステップＳ５０２にて、作業管理部１５は、不具合情報テーブル１０２においてプロセス１で作り込まれた不具合の件数をカウントする。次に、作業管理部１５は、（２）ステップＳ５０３にて、プロジェクト情報テーブル１０１に記録された情報を基にしてプロセス１の作業期間を算出する（ステップＳ５０３）。更に、作業管理部１５は、（３）ステップＳ５０４にて、人間行動情報テーブル１０３の情報を基に、プロセス１の作業期間中に担当者間で行われた対話へ参加した担当者の人数を判定する。

次に、作業管理部１５は、ステップＳ５０２〜Ｓ５０４で取得した情報を第２の実績情報として記録する（ステップＳ５０５）。図１９は、第２の実績情報の一例を示す図である。第２の実績情報５０１は、過去に実施されたプロジェクトにおける、次プロセスで作り込まれた不具合の件数を複数の範囲に離散化した不具合件数範囲と、次プロセスにおけるレビューの時期および参加者の人数とを対応づけた情報である。図１９の一番上のエントリには、不具合件数が２０〜２９件の範囲であった次プロセスにおいて、事前のレビューが参加者２人で行われ、完成レベルでのレビューが参加者４人で行われたことが示されている。

次に、作業管理部１５は、第２の実績情報５０１を用い、不具合件数を目的変数とし、レビューの時期および対話人数を説明変数として重回帰分析を行い、不具合件数範囲と、その不具合件数と、レビューの時期および対話人数との相関度を算出し、第３の相関情報リストに記録する（ステップＳ５０６）。相関度は係数およびＰ値により示される。図２０は、第３の係数情報の一例を示す図である。説明変数である対話人数と、相関度を示す係数およびＰ値とが対応づけられている。図２０には、ある不具合件数範囲（例えば「０〜９件」）についての第３の係数情報が示されているが、実際には図２０に示したような情報が不具合件数範囲毎に記録される。図２０の一番上のエントリには、ある不具合件数範囲（例えば「０〜９件」）と、事前のレビューに２人の担当者が参加したという時期および対話人数の値との相関度は、係数が＋３．５であり、Ｐ値が０．２であることが示されている。

次に、作業管理部１５は、第３の係数情報５０２から、各不具合件数範囲について、不具合件数範囲との相関度が最も高い、レビューの時期および対話人数を抽出し、第３の相関情報リストに記録する（ステップＳ５０７）。図２１は、第３の相関情報リストの一例を示す図である。第３の相関情報リスト５０３には、不具合件数範囲と、その不具合件数範囲との相関度が最も高いレビューの時期および対話人数とが対応づけられている。例えば、０〜９件という不具合件数範囲と相関度が最も高い次プロセスの時期および対話人数は、事前のレビューを３人で行ったという時期および対話人数である。

最後に、作業管理部１５は、第３の相関情報リスト５０３から、次プロセスにて作り込まれる不具合の件数が減る対話人数を取得し、その対話人数を追加レビューの参加者の人数に決定する（ステップＳ５０８）。次プロセスで作り込まれる不具合の件数が減るレビューの参加者の人数は、例えば、第３の相関情報リスト５０３から、不具合件数範囲が所定の閾値以下のエントリを選択し、そのエントリの対話人数の情報を取得すればよい。あるいは、第３の相関情報リスト５０３から、不具合件数範囲が最も小さい（図２１の例では不具合件数範囲が０〜９件）エントリを選択し、そのエントリの対話人数の情報を取得してもよい。あるいは、第３の相関情報リスト５０３から、予想されている件数よりも少ない不具合件数範囲のエントリを選択し、そのエントリの時期および対話時間の情報を取得してもよい。

以上、本実施例に記載した内容の一部を以下のように整理することができる。

本実施例の業務プロセス管理システムでは、主記憶装置１２あるいは補助記憶装置１６にて、過去に実施したプロジェクトである過去プロジェクトに関する、過去プロジェクトに含まれる複数のプロセスのそれぞれを実行するための前提となるプロセスである前提プロセスの情報を含む過去プロジェクト情報と、過去プロジェクトの各プロセスを担当する者の過去プロジェクト実行中の行動を示す過去人間行動情報と、過去プロジェクトにおいて摘出された不具合である摘出不具合およびその摘出不具合の原因が作り込まれたプロセスである作り込みプロセスの情報を含む過去不具合情報と、を記録する。中央演算処理装置１１は、過去プロジェクトに含まれる各プロセスを次プロセスとし、次プロセスを作り込みプロセスとする摘出不具合の件数に関する情報である過去次プロセス不具合件数情報と、過去人間行動情報から求まる、その次プロセスの前提プロセスにおいて実施されたレビューの参加者の属性、時期、および時間を含む過去前提プロセス対話状況との相関度を算出して第１の係数情報とする。更に、中央演算処理装置１１は、追加レビュー要否判定の入力とする、評価対象のプロジェクトである現在プロジェクトにおける前提プロセスのレビューに関する対話状況である入力前提プロセス対話状況との相関度が最も高い、次プロセスで作り込まれる不具合の件数である次プロセス不具合件数を第１の係数情報に基づいて取得し、取得した次プロセス不具合件数に応じて、現在のプロジェクトの次プロセスにおけるレビューの追加要否を判定する。

レビュー参加者個人をパラメータとする対話状況に基づき、過去の実績に基づき次のプロセスで作り込まれる不具合を抑えるのに効果的なレビューが実施されたか否かを判定し、かつ、実施された対話状況に応じてレビューの追加を提案するので、十分なレビューを実施したか否かを判定でき、かつ、参加者個人のレビューの貢献の程度を考慮に入れたレビューの追加実施を提案することができる。ここでいう不具合件数情報は、上述した不具合件数範囲および不具合件数そのものも含む概念である。また、ここでいう担当者の属性というのは、担当者がプロジェクトにどのように関わっているかを示す属性であり、例えば、その担当者が担当するプロセスである。

また、中央演算処理装置１１は、次プロセスで作り込まれる不具合件数を複数の範囲に分けてその範囲を次プロセス不具合件数範囲と定め、過去不具合情報に基づき、次プロセス不具合件数範囲毎に、次プロセス不具合件数範囲と前提プロセス対話状況との相関度を第１の係数情報として算出する。更に、中央演算処理装置１１は、第１の係数情報に基づいて各前提プロセス対話状況との相関度が最も高い次プロセス不具合件数範囲をそれぞれ決定して第１の相関情報として記録し、第１の相関情報に基づいて、入力前提プロセス対話状況との相関度が最も高い次プロセス不具合件数を決定する。次プロセスの不具合件数を複数の不具合件数範囲に離散化して次プロセス不具合件数と前提プロセス対話状況との相関度を算出するので、相関度を算出する処理を効率よく行うことができる。

また、中央演算処理装置１１は、次プロセス不具合件数が所定の閾値より多ければレビューを追加すると判定し、次プロセス不具合件数が閾値より少なければレビューを追加しないと判定する。レビュー追加の要否を不具合件数と閾値を比較する数値大小判定により決定することができるので、レビュー追加要否を簡単処理で判定できる。

また、この閾値は、前提プロセスにおいて予定された不具合の摘出件数に基づいて決定される。次プロセスで摘出を予定した件数に対して多数の不具合が次プロセスで作り込まれることが予測される場合にレビューを追加することで不具合を事前に摘出しようとすることができる。

また、中央演算処理装置１１は、次プロセスにおけるレビューの追加が必要と判定したら、第１の相関情報において、前提プロセス対話状況の時期および時間が入力前提プロセス対話状況と一致する情報を抽出し、抽出した情報の中から、次プロセス不具合件数範囲が所定の閾値より大きい情報を選択し、選択した情報における前提プロセス対話状況の参加者の属性を知得し、その参加者の属性に基づいて、追加するレビューの参加者の属性を決定する。多数の不具合が作り込まれることと相関度が高い参加者のレビューを追加することで不具合の摘出を強化できるように、追加するレビューの参加者を適切に選択することが可能となる。

また、主記憶装置１２または補助記憶装置１６にて、更に摘出不具合が摘出されたプロセスである摘出プロセスの情報を前記過去不具合情報に含めて記録する。中央演算処理装置１１は、決定した追加するレビューの参加者の属性について、前提プロセスがその参加者の属性および入力前提プロセス対話状況の両方に一致するという条件で過去のプロジェクトのプロセスを絞り込む。更に、中央演算処理装置１１は、絞り込んだプロセスの情報において、次プロセス不具合件数範囲と、過去人間行動情報から求まる、次プロセスにおけるレビューの参加者の属性、時期、および時間を含む次プロセス対話状況との相関度を算出して第２の係数情報とする。更に、中央演算処理装置１１は、次プロセス不具合件数範囲が所定の閾値より小さい次プロセス対話状況を第２の係数情報に基づいて取得し、取得した次プロセス対話状況に基づいて、追加するレビューの時期および時間を決定する。過去に実行されたプロジェクトの情報の中から次プロセスで作り込まれる不具合が少なくなるように選択した次プロセス対話状況に基づいて、追加するレビューの時期や時間を決定するので、効果的に不具合の摘出もれを抑制するように、追加するレビューの時期および時間を設定することができる。

また、中央演算処理装置１１は、時期が決定した追加するレビューについて、次プロセス不具合件数と、実績人間行動情報から求まる、次プロセスにおけるレビューの参加者の人数である次プロセス対話人数との相関度を算出して第３の係数情報とし、次プロセス不具合件数が所定の閾値より小さい次プロセス対話人数を第３の係数情報に基づいて取得する。更に、中央演算処理装置１１は、取得した次プロセス対話人数に基づいて、追加のレビューの参加者の人数を決定する。追加するレビューの参加者の人数を適切に選択することが可能となる。

また、中央演算処理装置１１は、次プロセス不具合件数を複数の範囲に分けてその範囲を次プロセス不具合件数範囲とし、次プロセス不具合件数範囲毎に、次プロセス不具合件数範囲と次プロセス対話人数との相関度を第３の係数情報として算出する。更に、中央演算処理装置１１は、第３の係数情報に基づいて各次プロセス対話人数との相関度が最も高い次プロセス不具合件数範囲をそれぞれ決定して第３の相関情報として記録する。更に、中央演算処理装置１１は、第３の相関情報に基づいて、次プロセス不具合件数が閾値より少ない次プロセス対話人数を取得する。過去に実行されたプロジェクトの情報の中から次プロセスで作り込まれる不具合が少なくなるように選択した次プロセス状況に基づいて、追加するレビューの参加者の人数を決定するので、効果的に不具合の摘出もれを抑制する追加するレビューの参加者の人数を設定することができる。

また、業務プロセス管理システムでは、業務プロセス管理装置１０が中央演算処理装置１１、主記憶装置１２、および補助記憶装置１６を有している。業務プロセス管理システムは、各プロセスを担当する者に着用され、そのプロジェクト実行中の行動に関する情報である端末取得情報を取得し、業務プロセス管理装置１０に送信するウェアラブル端末３０を更に有する。中央演算処理装置１１は、ウェアラブル端末３０から端末取得情報を受信し、その端末取得情報から実績人間行動情報を取得する。担当者が着用したウェアラブル端末３０で各担当者の行動に関する情報を取得するので、担当者が自身で入力作業を行わなくても行動に関する情報を取得することができる。

本実施例によれば、過去のプロジェクトで取得された人間行動情報、プロジェクト情報、不具合情報から得られた相関関係に基づき、実施中のプロジェクトのプロセスにおけるレビューの時期および時間の条件に対応して効果的なレビューの追加をユーザに提案することができる。さらに、会合レビューのメンバー、実施タイミング、時間、参加人数も合わせて提案することができる。その結果、ユーザ間の情報伝達の量を向上し、レビュー時に潜在的な不具合を摘出できるので、後工程での不具合の発生を低減できる。

実施例２では、業務プロセス管理システムは、実施例１の業務プロセス管理システムが備えた機能に加え、プロジェクトの工程表を表示する機能を備えている。実施例２の業務プロセス管理システムは図１に示した実施例１のものと同様の構成である。実施例２の業務プロセス管理システムでは、業務プロセス管理装置１０がプロジェクト工程表を生成し、クライアント端末４０がそのプロジェクト工程表を表示する。

業務プロセス管理装置１０では、作業管理部１５がプロジェクト工程表のデータを作成して主記憶装置１２あるいは補助記憶装置１６に記録し、そのデータを随時更新している。クライアント端末４０は、業務プロセス管理装置１０にアクセスし、業務プロセス管理装置１０が管理しているプロジェクト管理表のデータを取得し、出力装置６０に表示する。

図２２は、実施例２において表示されるプロジェクト工程表の一例を示す図である。プロジェクト工程表には、対象とするプロジェクトに含まれるプロセスにおいて作り込まれる不具合の件数に関する情報（図２２の「作り込み不具合件数」）と、そのプロセスの開始日および完了日の予定および実績の情報（図２２の「スケジュール」）と、そのプロセスに子プロセスとして含まれるレビュープロセスに関連する情報とが含まれる。業務プロセス管理装置１０は、プロジェクト情報テーブル１０１に記録されている子プロセスの中からレビューを行う子プロセスを抽出し、レビュープロセスとする。プロセスの開始日および完了日の予定および実績は、プロジェクト情報テーブル１０１から取得される。

プロセスで作り込まれる不具合の件数に関する情報には、システムが提案するレビューを追加しない初期状態での不具合の予測件数と、システムが提案するレビューを追加した場合の予測件数と、実際に当該プロセスで作り込まれた不具合の件数の実績値とが含まれる。初期状態での不具合の予測件数は第１の係数情報３０２に基づく重みづけ加算演算により算出される。レビューを追加した場合の不具合の予測件数は、第２の係数情報４０１および第３の係数情報５０２に基づく重みづけ加算演算により算出される。実績値は不具合情報テーブル１０２からカウントされる。

レビュープロセスに関連する情報には、レビュープロセスについて、レビュープロセス名称、そのレビュープロセスがシステムにより提案されたものか否かを示すフラグ、実施済か否かを示すフラグ、そのレビュープロセスの実施の有無を示すフラグ、そのレビュープロセスで摘出された不具合の件数（図２２の「プロセス不具合件数」）の実績値が含まれる。不具合件数の予定値はプロセスにおける値（図２２の「プロセス不具合件数」）の予定値はプロセスの単位で設定される。予定値はプロジェクト情報テーブル１０１から取得される。実績値は不具合情報テーブル１０２からカウントされる。レビュープロセスが実施されていない場合には、実績値に「−」が表示される。

レビュープロセスがシステムにより提案されたものか否かを示すフラグとして、システムにより提案されたレビュープロセスには「〇（丸印）」が表示され、システムにより提案されたものでないレビュープロセスには「×（バツ印）」が表示される。レビュープロセスの実施の有無を示すフラグとして、実施されたレビュープロセスには「〇（丸印）」が表示され、実施されていないレビュープロセスには「×（バツ印）」が表示される。

本実施例では、中央演算処理装置１１は、レビューを追加すると判定すると、追加するレビューを、予め設定されていたレビューと判別できるように、表示する。システムが提案したレビューを初期状態から設定されていたレビューと区別可能に表示するので、システムによるレビューの追加をユーザが容易に把握することができる。

本実施例によれば、実施例１に加え、プロジェクトの工程状況、不具合件数の予実績を表示するので、本システムで提案したレビューの実施有無による不具合削減効果を確認でき、プロジェクトの品質予測や工程遅延防止ができる。

実施例３では、業務プロセス管理システムは、実施例１の業務プロセス管理システムが備えた機能に加え、各担当者がどの程度活発に対話や議論を行ったかを計測し、対話や議論が不十分な担当者が関わった成果物を通知する機能を備えている。対話や議論が不十分な担当者が関わった成果物というのは、例えば、その担当者が一部あるいは全部を作成した成果物である。また、その担当者がレビューに参加した成果物を含めてもよい。

実施例３の業務プロセス管理システムは図１に示した実施例１のものと同様の構成である。実施例３の業務プロセス管理システムでは、業務プロセス管理装置１０が、レビューにおける対話状況を取得し、議論が十分活発に行われたか否か判定する。そして、業務プロセス管理装置１０は判定結果に基づき、議論が不十分なレビューで検査した成果物を判定し、通知する。クライアント端末４０にて出力装置６０に表示される。

図２３は、実施例３において生成される活発度情報の一例を示す図である。活発度情報７０１には担当者ごとの対話時間と活発度が記録されている。作業管理部１５は、活発度は、対話時間に対する活発に活動している時間の割合である。活発に活動しているかどうかはウェアラブル端末３０に搭載された加速度センサで得られる加速度情報から算出することができる。例えば、対話時間の中で上半身が前傾している時間は活発に活動している時間と判断してもよい。あるいは、上半身が前後あるいは左右に動く頻度が所定値以上に高いときに活発に活動していると判断することにしてもよい。図２３において担当者Ａは対話時間が１ｈであり、活発度が６０．２％である。

作業管理部１５は、レビューの参加者の活発度を所定の閾値と比較し、活発度が閾値を下回っている参加者を抽出する。更に、作業管理部１５は、活発度が閾値を下回った参加者が参加したレビューにおける議論は不十分と判断する。そして、作業管理部１５は、議論が不十分なレビューで検査された成果物の情報を通知する。例えば、活発度の閾値が５０％であるとする。担当者Ｃは活発度が４９．５％なので、担当者Ｃの参加したレビューでは議論が不十分になっていると判断し、そのレビューで検査された成果物の情報を通知する。

本実施例では、中央演算処理装置１１は、実績人間行動情報に基づいて、各プロセスを担当する者がどの程度活発に対話を行っているかを示す活発度を算出し、活発度が所定の閾値より低い者が関わった成果物の情報を提示する。活発度の低い担当者が関わった成果物は不具合が発生する可能性が高いと考えられるので、その成果物を提示し、重点的な確認などを促すことができる。

本実施例によれば、実施例１に加え、対話時の参加者の活発度を取得し、活発度が低い参加者が関わった成果物を通知する。活発度の低い参加者が関わった成果物を通知することで、レビューの際にその成果物を重点的に検査するように促し、担当者の認識誤りや勘違いといったプロジェクトのリスクを早期発見できる。

上述した本発明の実施例は、本発明の説明のための例示であり、本発明の範囲をそれらの実施例のみに限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１０…業務プロセス管理装置、１１…中央演算処理装置、１２…主記憶装置、１３…実績情報処理部、１４…相関度算出部、１５…作業管理部、１６…補助記憶装置、２０…人間行動情報取得装置、３０…ウェアラブル端末、４０…クライアント端末、４１…中央処理装置、４２…主記憶装置、４３…画面表示部、５０…入力装置、６０…出力装置、７０…通信ネットワーク

Claims (12)

1. 過去に実施したプロジェクトである過去プロジェクトに関する、該過去プロジェクトに含まれる複数のプロセスのそれぞれを実行するための前提となるプロセスである前提プロセスの情報を含む過去プロジェクト情報と、前記過去プロジェクトの各プロセスを担当する者の該過去プロジェクト実行中の行動を示す過去人間行動情報と、前記過去プロジェクトにおいて摘出された不具合である摘出不具合および該摘出不具合の原因が作り込まれたプロセスである作り込みプロセスの情報を含む過去不具合情報と、を記録する記憶装置と、
   前記過去プロジェクトに含まれる各プロセスを次プロセスとし、前記次プロセスを作り込みプロセスとする摘出不具合の件数に関する情報である過去次プロセス不具合件数情報と、前記過去人間行動情報から求まる、該次プロセスの前提プロセスにおいて実施されたレビューの参加者の属性、時期、および時間を含む過去前提プロセス対話状況との相関度を算出して第１の係数情報とし、追加レビュー要否判定の入力とする、評価対象のプロジェクトである現在プロジェクトにおける前提プロセスのレビューに関する対話状況である入力前提プロセス対話状況との相関度が最も高い、次プロセスで作り込まれる不具合の件数である次プロセス不具合件数を前記第１の係数情報に基づいて取得し、取得した前記次プロセス不具合件数に応じて、前記現在のプロジェクトの次プロセスにおけるレビューの追加要否を判定する処理装置と、
   を有するプロセス管理システム。
2. 前記処理装置は、
   次プロセスで作り込まれる不具合件数を複数の範囲に分けて該範囲を次プロセス不具合件数範囲と定め、
   前記過去不具合情報に基づき、前記次プロセス不具合件数範囲毎に、前記次プロセス不具合件数範囲と前記前提プロセス対話状況との相関度を前記第１の係数情報として算出し、
   前記第１の係数情報に基づいて前記各前提プロセス対話状況との相関度が最も高い次プロセス不具合件数範囲をそれぞれ決定して第１の相関情報として記録し、
   前記第１の相関情報に基づいて、前記入力前提プロセス対話状況との相関度が最も高い次プロセス不具合件数を決定する、
   請求項１に記載のプロセス管理システム。
3. 前記処理装置は、前記次プロセス不具合件数が所定の閾値より多ければ前記レビューを追加すると判定し、前記次プロセス不具合件数が前記閾値より少なければ前記レビューを追加しないと判定する、請求項１に記載のプロセス管理システム。
4. 前記閾値は、前記前提プロセスにおいて予定された不具合の摘出件数に基づいて決定される、
   請求項３に記載のプロセス管理システム。
5. 前記処理装置は、前記次プロセスにおけるレビューの追加が必要と判定したら、前記第１の相関情報において、前記前提プロセス対話状況の時期および時間が前記入力前提プロセス対話状況と一致する情報を抽出し、抽出した該情報の中から、前記次プロセス不具合件数範囲が所定の閾値より大きい情報を選択し、選択した該情報における前記前提プロセス対話状況の参加者の属性を知得し、該参加者の属性に基づいて、前記追加するレビューの参加者の属性を決定する、
   請求項２に記載のプロセス管理システム。
6. 前記記憶装置は、更に前記摘出不具合が摘出されたプロセスである摘出プロセスの情報を前記過去不具合情報に含めて記録し、
   前記処理装置は、
   決定した前記追加するレビューの参加者の属性について、前記前提プロセスが該参加者の属性および前記入力前提プロセス対話状況の両方に一致するという条件で前記過去のプロジェクトのプロセスを絞り込み、
   前記絞り込んだプロセスの情報において、前記次プロセス不具合件数範囲と、前記過去人間行動情報から求まる、前記次プロセスにおけるレビューの参加者の属性、時期、および時間を含む次プロセス対話状況との相関度を算出して第２の係数情報とし、
   前記次プロセス不具合件数範囲が所定の閾値より小さい次プロセス対話状況を前記第２の係数情報に基づいて取得し、
   前記取得した次プロセス対話状況に基づいて、前記追加するレビューの時期および時間を決定する、
   請求項５に記載のプロセス管理システム。
7. 前記処理装置は、
   前記時期が決定した前記追加するレビューについて、前記次プロセス不具合件数と、前記実績人間行動情報から求まる、前記次プロセスにおけるレビューの参加者の人数である次プロセス対話人数との相関度を算出して第３の係数情報とし、
   前記次プロセス不具合件数が所定の閾値より小さい次プロセス対話人数を前記第３の係数情報に基づいて取得し、
   前記取得した次プロセス対話人数に基づいて、前記時期に実施する追加のレビューの参加者の人数を決定する、
   請求項６に記載のプロセス管理システム。
8. 前記処理装置は、
   前記次プロセス不具合件数を複数の範囲に分けて該範囲を次プロセス不具合件数範囲とし、
   前記次プロセス不具合件数範囲毎に、前記次プロセス不具合件数範囲と前記次プロセス対話人数との相関度を前記第３の係数情報として算出し、
   前記第３の係数情報に基づいて前記各次プロセス対話人数との相関度が最も高い次プロセス不具合件数範囲をそれぞれ決定して第３の相関情報として記録し、
   前記第３の相関情報に基づいて、前記次プロセス不具合件数が前記閾値より少ない次プロセス対話人数を取得する、
   請求項７に記載のプロセス管理システム。
9. 前記処理装置は、前記レビューを追加すると判定すると、前記追加するレビューを、予め設定されていたレビューと判別できるように、表示する、請求項２に記載のプロセス管理システム。
10. 前記記憶装置および前記処理装置を有する業務プロセス管理装置と、
    前記各プロセスを担当する者に着用され、その前記プロジェクト実行中の行動に関する情報である端末取得情報を取得し、前記業務プロセス管理装置に送信するウェアラブル端末と、を有し、
    前記処理装置は、前記ウェアラブル端末から前記端末取得情報を受信し、該端末取得情報から前記実績人間行動情報を取得する、
    請求項１に記載のプロセス管理システム。
11. 前記処理装置は、前記実績人間行動情報に基づいて、各プロセスを担当する者がどの程度活発に対話を行っているかを示す活発度を算出し、該活発度が所定の閾値より低い者が関わった成果物の情報を提示する、請求項１に記載のプロセス管理システム。
12. 記憶手段が、過去に実施されたプロジェクトである過去プロジェクトに関する、該過去プロジェクトに含まれる複数のプロセスのそれぞれを実行するための前提となるプロセスである前提プロセスの情報を含む実績プロジェクト情報と、前記過去プロジェクトの各プロセスを担当する者の該プロジェクト実行中の行動を示す実績人間行動情報と、前記プロジェクトにおいて摘出された不具合である摘出不具合および該摘出不具合の原因が作り込まれたプロセスである作り込みプロセスの情報を含む実績不具合情報と、を予め記憶し、
    作業管理手段が、前記プロジェクトに含まれるプロセスを次プロセスとし、前記次プロセスを作り込みプロセスとする摘出不具合の件数に関する情報である次プロセス不具合件数情報と、前記実績人間行動情報から求まる、該次プロセスの前提プロセスにおいて実施されたレビューの参加者の属性、時期、および時間を含む過去前提プロセス対話状況との相関度を算出して第１の係数情報とし、
    前記作業管理手段が、追加レビュー要否判定の入力とする、評価対象のプロジェクトである現在プロジェクトにおける前提プロセスのレビューに関する対話状況である入力前提プロセス対話状況との相関度が最も高い、次プロセスで作り込まれる不具合の件数である次プロセス不具合件数を前記第１の係数情報に基づいて取得し、
    前記作業管理手段が、取得した前記次プロセス不具合件数に応じて前記次プロセスにおけるレビューの追加要否を判定する、
    を有するプロセス管理方法。

Images