(57)【要約】【課題】  従来の見える化の仕組みは個別の様々なシステムから一旦データウエアハウスのような容れ物にデータを収集し加工分析するのが一般的であり、情報とその発生現場の間に距離が生まれ、またタイムラグもあり、問題解決ツールとして不十分であった。【解決手段】  タイムラグなしに、プロジェクト当事者と同じ深さの情報を見える化するために、プロジェクト管理ツールを機能拡大し、あらゆるプロセスにも適用可能とし、ＰＤＣＡサイクルを統一的に管理できるプロジェクト管理兼見える化のツールにした。【選択図】図１
2016062342.tif 000002
【特許請求の範囲】
【請求項１】
データベース部と計画作成部と実績登録部と実績集約部の各機能部分を有し、データベース部はプロセス情報とその関係情報と実績スタック情報を持ちかつプロセス情報のうち計画と実績は作業単位情報と年月日別情報とを併せ持ちかつ関係情報は計画情報や実績情報とは別に切り離して持つ構造を有し、かつ実績集約部は実績スタック情報の差分情報を使って実績情報を集約する機能を有し、かつ実績登録部はプロセス計画情報を利用して稼働情報を収集する機能を有し、かつ計画作成部はプロジェクト計画を自動生成する機能を有するプロジェクト管理システムまたは統合プロセス管理システム。
【請求項２】
個人別のプロセス計画情報をプロセス管理モニタ画面に表示する差立情報処理部と、プロセス管理モニタ画面に表示されたプロセス計画を選択することでリアルタイムに個人稼働情報を収集しそれをプロセス管理モニタ画面に表示する個人稼働情報処理部と、かつ収集した個人稼働情報を作業単位実績情報と稼動管理情報へ変換して作業単位の実績情報と稼働管理情報とを同時に収集できる実績スタック情報書込部とを実績収集部として持つことを特徴とする請求項１記載のプロジェクト管理システムまたは統合プロセス管理システム。
【請求項３】
新たに発生した実績情報を階層関係情報で繋がるプロセス実績情報として集約するについて、その直前の実績情報との差分を使って階層関係情報を辿りながら上位層の一連のプロセス実績情報の集約処理をする差分集約部と、またはそれと同時に階層の途中で一時的に差分情報を中間スタック情報に格納し、一定時間後にスタックされた差分情報を集約した差分情報で更に上位層の集約処理をするようにした差分スタック処理部とを実績集約部として持つことを特徴とする請求項１記載のプロジェクト管理システムまたは統合プロセス管理システム。
【請求項４】
開発工程とその工程内作業の構成とを定義した作業スコープ定義情報と開発対象のシステム構成情報を持つシステム構造情報とから作業単位を自動作成する作業単位生成部と、生成した作業単位の所要工数をシステム構造情報の導出属性から見積ることができる開発工数見積部と、標準開発期間−総開発工数対比表を用いて作業単位の配置パターンを決めることで作業単位計画を自動作成するスケジューリング部を計画作成部として持つことを特徴とする請求項１記載のプロジェクト管理システムまたは統合プロセス管理システム。
【請求項５】
開発工程とその工程内作業の構成とを定義した作業スコープ定義情報と開発対象のシステム構成情報を持つシステム構造情報とから作業単位を自動作成する作業単位生成部と、生成した作業単位の所要工数をシステム構造情報の導出属性から見積ることができる開発工数見積部と、前後関係情報の制約をうけた作業単位を並列の前後関係情報を優先的に辿りながら後続タスクの開始日を決めまた標準開発期間−総開発工数対比表からタスクの開発期間を決めて順次自動作成するスケジューリング部を計画作成部として持つことを特徴とする請求項１記載のプロジェクト管理システムまたは統合プロセス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
統合プロセス管理システムとはプロジェクト管理ツール（注１）の機能を持ちかつ様々な異質な業務プロセスのＰＤＣＡ／ＨＤＣＡサイクル（注２）に関する情報をプロジェクトの当事者並みの深さでタイムラグなしに収集し見える化できる新しいコンセプトのシステムである。統合プロセス管理システムをプロジェクト管理機能を持ちかつプロセスＰＤＣＡをリアルタイムに見える化するシステムと言うこともできるし、またプロセスＰＤＣＡをリアルタイムに見える化する機能を持つプロジェクト管理システムと言い換えることもできる。従来のツールやシステムと比較して、統合プロセス管理システムの概念を次に簡潔に述べる。
【０００２】
（従来のプロジェクト管理ツールとの違い）
従来のプロジェクト管理ツールは部門ローカルに使用されるオフィスツール＋α程度の機能を持つツールであり、主に特定プロジェクトの計画管理等に適用されるのに対し、統合プロセス管理システムはプロジェクトとは限らないあらゆる業務プロセスに適用され、ＰＤＣＡサイクルを見える化する包含関係にあるシステムである。
【０００３】
（従来の見える化ツールとの違い）
従来の多くの見える化のツールは、個別な縦割りのシステムで収集したＶＱＣＤ情報（注３）を一旦データウエアハウス等に集めて加工分析するのに対し、統合プロセス管理システムではこれらの情報を縦割りにせずプロセス情報の異なる側面を示すＶＱＣＤ情報として捉え、ひとつのツールでひとつのプロセス情報として全て同一形式で取り込む。特にプロジェクト管理ツールを内部で持っているためにプロジェクトの当事者と同等の深さのリアルタイムな情報を共有できるようになる。システム開発では失敗が後を絶たないが、その抑止策として極めて重要である。
【０００４】
（従来の業務システムとの違い）
従来の業務システムは決められた業務管理ポイントの時点状況を取り込むだけであるが、統合プロセス管理システムは最初から業務プロセス自体をどう変えるかが重要であり、全てのＶＱＣＤ情報をＰＤＣＡ／ＨＤＣＡサイクルの見える化の観点で取り込む。
【０００５】
（注１）プロジェクト管理ツールは、マスタ計画管理中心、作業管理中心、問題・障害対応中心、会計中心など得意なサポート分野が分かれる。マスタ計画管理ツールは管理者向け、作業管理ツールは作業かんばんと似た現場向けのツールである。プロジェクト管理ツールにはオープンソースがいくつかある。代表例としてマスタ計画管理ツールではＯｐｅｎＰｒｏｊ、作業管理ツールではＲｅｄｍｉｎｅやＴＲＡＣ、更に両者の機能を実績情報で繋ぎ合わせたＥＰＭ−Ｘなどがある。
【０００６】
（注２）ＨＤＣＡサイクルはＰＤＣＡサイクルに倣った造語。そもそも仮説（ｈｙｐｏｔｈｅｓｉｓ）を全く含まないＰＤＣＡサイクルなど考えられないが、Ｐｌａｎとして明確に立てられない段階の仮説を元にして廻す管理サイクルである。ＰＤＣＡサイクルはその下位にある多くの主体的なＨＤＣＡサイクルによって支えられている。
（注３）ＶＱＣＤ情報とは通常のＱＣＤ情報に量的要素（売上とか受注量、開発量とか）を加えた造語である。一般にはＶが成果、目標（達成実績、達成目標）を示すのに対し、ＱＣＤがその原因になる要素と考えられる。ＶとＱＣＤの間には通常顧客満足度などを介した因果関係が仮定されることが多い。
【背景技術】
【０００７】
従来技術とその問題点
（従来のプロジェクト管理ツールの機能）
統合プロセス管理システムのベースとなるプロジェクト管理ツールは作業単位計画を作成し、それを差立て、実績を収集する点ではどれも良く似ているが、ツールによって管理の重点ポイントが異なる。
マスタ計画管理ツールはプロジェクト全体のマスタ計画のスケジュール管理が中心であり、全体で俯瞰する計画を持ち、またチーム単位の大きなボリュームの作業単位（タスク）で構成される。一方作業管理ツールはタスクを細分化した作業単位（チケット）を扱い、チケットは最終的には個人別の作業にまで分割される。また障害チケット・問題対応チケットなど計画外に起こる作業単位を扱うことができ、また現場の裁量で作業かんばん的な運用で調整できる自由度を持つ。
【０００８】
マスタ計画管理ツールと作業管理ツールの主要な機能構成を図２に示す（注４）。ただし図２では使用情報の一部は省略して示している。いずれも計画と実績の登録、編集機能、および参照機能（分析診断機能）を持つが、資源割当機能はマスタ計画管理ツールのみが持つ。
（注４）あくまで現時点の参考情報だが、作業管理ツールでは操業暦を持たず、マスタ計画管理ツールにはある。そのためチケット計画では休日を人が考慮する。またマスタ計画管理ツールでは資源情報（人など）を持ち、個人別の日当り稼動時間などを考慮できるが作業管理ツールではそれがない。
【０００９】
（１）  タスクとチケットの役割の違い
（マスタ計画か差立計画か）
タスクとチケットはマスタ計画か差立計画かに本質的な違いがある。一般的にマスタ計画は一旦作られたら安易には変更しない。もし変更する場合は基準マスタ計画として変更前の計画を保存して、保存した基準マスタ計画の推移を画面上に表示することができる。一方差立計画は作業かんばんのように現場の裁量で作業順序が調整できる自由度がある。つまり上位のマスタ計画（タスク）を安易には動かさず、差立て計画（チケット）を作業かんばんのように使って柔軟に計画を運用する。
マスタ計画も差立計画も図３のような基底ビュー画面で表示され、ビューバーから呼ばれるサブ画面で参照、登録、編集される。マスタ計画管理ツールでまずマスタ計画を作成し、次に作業管理ツールでチケットに細分化し、最下位層のチケットには作業者を個人別に割り当てる。その関係を図４に示す。
【００１０】
（前後関係情報の有無の違い）
タスクもチケットも階層関係情報で階層化されるが、タスクは更に前後関係情報でも先行・後続の接続情報を持つ（注５）。チケットにはない。また関係情報は複雑に分岐する関係は持たない。従って現在はプロセス情報に関係情報を埋め込む形でも保持できる。
（計画外作業単位の有無の違い）
チケットの特徴的な機能として、計画外に発生する障害や問題を随時計画外のチケット（注６）に取り込める。
【００１１】
（作業単位計画、年月日別計画、資源割当計画の持ち方の違い）
タスクもチケットも総開発工数と開始日、開発期間などの作業単位全体としての計画情報を持つ（作業単位計画）。チケットは短期間な個人割当作業なので、年月日別にまで展開された計画（年月日別計画（注７））が常に必要とは限らないかもしれないが、タスクは長期間で複数人が関係するので、操業暦と資源割当部を使った資源割当計画を必要とする。しかし、資源割当以前に、最適なタスク配置パターン（即ち資源割当で決まる以前の自由度のある年月日別計画）があるという考え方はとっていない。
【００１２】
（注５）タスクでは次のようなスケジューリングで使う固有の情報を持つ。
（i）先行タスクと後続タスクの依存関係情報（ＦＳ，ＳＳ，ＦＦ，ＳＦの４種類ほど）
（ii）タスクの展開制約条件（プロジェクト開始日からの前倒しスケジューリング、プロジェクト終了日からの後倒しスケジューリングなど８種類ほど）
（iii）タスクのタイプ（３種類：スケジュールを変更する場合に期間（開発日数）、単位数（日当たりの稼働時間）、作業時間（総開発工数）の何を軸として計算するか）
（iv）ワークカウンタ：タスクに資源を割り当てる配分の型（８種類ほど：均等、後比重、前比重など）
【００１３】
（注６）タスクから細分化されるチケットはＷＢＳ（Ｗｏｒｋ  Ｂｒｅａｋｄｏｗｎ  Ｓｔｒｕｃｔｕｒｅ）チケットと呼ばれ予めスケジューリングされている。これに対し計画外に起こってくるチケットは障害チケットや問題対応チケットと呼ばれ、チケットの種別を自由に追加定義でき、ＷＢＳチケットと同様に状態をトレースしたり、種別ごとに稼働実績を集計したりできる。
【００１４】
（注７）プロセス計画情報は作業単位の計画情報を持ち、資源（人）を割当てると資源割当計画として決まる。しかし統合プロセス管理システムでは資源割当計画の前に面積イメージの年月日別情報を考え、後述する計画の自動生成ではこの面積イメージの計画を上位層から下位層へ段階的に展開する。実際には人を割当てる前にどの程度の面積イメージ（期間、平均投下工数）で開発すべきか大まかなプランを必要とする。この考え方の方が実際に人が計画を作成するときの自然な流れを踏まえている。
【００１５】
（２）計画情報登録機能
プロジェクト管理ツールはプロセス固有の管理情報をツール自体であまり持たず（空に近い）、登録する項目数は多くはない。具体例としてＲｅｄｍｉｎｅを機能拡張したＥＰＭ−Ｘが扱うＶＱＣＤ情報例を図５に示す。開始日、開発期間などの計画情報とチケット自体の管理項目が大部分で、ＥＰＭ−Ｘで拡張された囲み線で囲んだテスト評価実績を除けば大した項目数を持っていない。ただし必要に応じて項目はユーザが追加できる。
計画を登録するには図３に示すような基底ビュー画面から呼ぶサブ画面で登録する。画面からの手入力ばかりではなく、あらかじめタスクやチケット情報をｃｖｓデータ形式などで作成しておき、そこから取り込むことも可能である。プロジェクト規模が小さい場合はこれで対応可能であるが、規模が大きくなると作業単位（チケットやタスク）を作成するだけでも結構な工数がかかる。
【００１６】
（３）資源割当機能
タスク計画の場合は大きな作業単位に複数の作業者を割当てると同時に年月日別にも展開して作業者の作業配分の負荷を確認する必要がある。従って図２に示すようにマスタ計画管理システムにはタスク資源（人）を割り当てるための機能部がある。一方チケット計画の場合は短期間でかつ作業者単位にまで細分化するので、資源割当て機能を持つまでのことはない。したがって作業管理システムにはタスク資源の割当機能部がない。これについては図６に示す。チケットの稼働実績は最下位の対応するチケット計画に対してあがるが、タスクの稼働実績は日別に展開された資源割当て情報に対してあがる。
【００１７】
（４）実績情報登録機能
タスクとチケットのデータ項目数は多くないので、計画と同様に図３のような基底ビュー画面からサブ画面を呼んで登録する。手入力が原則であり、必要に応じてｃｖｓ形式のデータを一括して取り込むことができる。ただし、もし精度の高い生産性や品質管理指標などを得たい場合やリアルタイムに進捗を管理したい場合には、小ロット単位でかつ作業と並行して工数収集が必要なので、手入力では対応しきれないし、また作業単位実績情報と稼働管理情報を重複収集する無駄は排除しなければならない。
ところで実績収集は稼働情報が全てではなく、経費情報もあり品質情報もある。品質管理機能を強化したい場合などは今のマスタ計画管理ツール、作業管理ツールの収集情報だけでは物足りない。障害の抑止策をとっても、例えば開発ロット単位の開発レビュー時間比率や障害発生比率などのレビュー情報などは今後取り込みたい情報がある。
【００１８】
（実績スタック情報を経由した実績情報の取り込み）
実績情報はプロセス情報に直接書き込まず実績スタック情報に一旦書き込んだ後集約する。例えば一日で同じチケットに複数回実績が挙がる場合、個々の実績情報と収集時間を一旦実績スタック情報に保存し、プロセス実績情報としてはその集約結果を持つようにする。それによって個々の実績情報も集約結果もともに参照できる。また登録済みの実績を更新する場合も実績スタック情報を更新した後、プロセス実績情報で集約する。
【００１９】
以上説明したような既存のプロジェクト計画ツールの機能と、統合プロセス管理のめざす機能を考慮すると、次のような問題点が浮かび上がる。
（問題点１）プロジェクト管理ツールは適用範囲が限定的。
（プロセスＰＤＣＡサイクル情報は共通化できる）
プロジェクト管理ツールの適用範囲は開発プロジェクトなどの特定業務が中心であり、それ以外の主要なプロセス、例えば販売や購買、人材育成活動、リクルート活動などは対象外である。どんなプロセスであれ、中間または最終のアウトプットを区切りにプロセスを分割すると、各分割プロセス（作業単位）は分割プロセスの作業計画と実績およびアウトプットレビュー、レビューに基づく問題対応をセットとするＰＤＣＡサイクルをなすと見なせる。レビューでは分割プロセスのアウトプットを様々なＶＱＣＤの観点で評価する。レビューに基づく問題対応とは、不具合が見つかった場合計画外の作業単位を起こして対応することである。そのＰＤＣＡサイクル情報は図１２に示すようなどれも同じ形式の作業単位情報と計画外の作業単位情報とで表現しうる。但し異なるプロセスのＶＱＣＤ情報が、全てデータ項目単位まで同じことはありえないが、共通の管理項目と固別の管理項目を切り分けて管理すれば、考え方を統一できる。
【００２０】
（企業のプロセスＰＤＣＡサイクルの階層構造）
図１１に示すように分割されたプロセスが複数集まってある機能をなす上位のプロセスを形成し、更に複数のプロセスが集まってプロジェクト層の集約プロセスを形成し、それが更にいくつか集まって組織層の集約プロセスを形成し、企業規模のＰＤＣＡサイクルを形成する。分割プロセスも集約プロセスも、あらゆる種類、階層のプロセスも同じ形式で捉えられると、プロセスがきわめて分かり易いものとなり、階層的にもまた横通しでも見え易く、また異なるプロセス間の違いもはっきりしてくる。すなわち全てのプロセスのＰＤＣＡサイクルを統一的に扱うことで企業全体のすっきり、さっぱりした見える化のシステムを構築できる可能性がある。
【００２１】
（異なるプロセス間の情報を連携したい）
現状では図１７に示すような幾つかの異なる部門に跨る異質なプロセスの関連を簡単に見ることが困難である。営業が契約した案件が、パートナーの採用やプロジェクトによる開発を経て検収、回収に至る複数の関係するプロセスの状況をひと目で把握するには、別々の業務システムを繋ぎ合わせて見るしかないし、現実には情報の壁に阻まれてなかなか見えるようにならない。プロセス情報を最初から全て統一的に見えるようにし、それぞれの部門のチケットの仕掛り状況、進行状況がひと目で分り、しかもどんな計画外のトラブルや問題が発生しているのか、どんな対応策がとられているのか、関連する異質なプロセスを横通しで見えるようにできる可能性がある。
【００２２】
（問題点２）類似データを別々のシステムで収集、処理する非効率
中期予実管理、年次予実管理、マスタ計画管理、作業管理、稼働管理、品質管理、人事実績考課などで扱う情報は元々同じプロセスの過程で発生するものであり、プロジェクトの当事者にとってはひとつのプロセスのＶＱＣＤ情報のさまざまな側面として一緒に見たい情報である。それにも係わらず、現状では別々のシステムで収集され、異なるスタッフ管理部門で管理され、縦割りに管理される弊害がある。例えば、作業単位稼動実績と稼働管理システムの実績情報は似たような作業実績を重複して入力する非効率が発生しており、人事業績考課ではプロセスの個人別の事実ベースの実績情報がないので、わざわざそのための評価情報を別に作成する。また中期や年次計画を従来のようにプロジェクト計画とは別物として扱うよりは、プロセス情報が中期や年次や月次の時間軸のスパンの違いとして見えた方がずっとすっきりする。このようにどれも元は発生源がひとつで相互に絡んだプロセス情報であるにも関わらず、情報が縦割に管理されている弊害がある。
【００２３】
（問題点３）作業単位実績の登録手段が非効率
プロジェクト管理ツールの作業単位実績は手入力で登録されている。その入力負荷はデータ量や入力項目数が少ない間は許容範囲内であっても、プログラム数本単位の小さな開発ロットで収集して品質や生産性の管理精度を高めようとすると、手作業では困難になる。また問題点２でも述べたように、プロセスの作業単位稼動実績と稼働管理システムの実績情報は似たような作業実績を重複して入力する非効率が発生している。これは統合プロセス管理システムの問題である先に、現行のプロジェクト管理ツールの問題でもあり、これがクリアできなければ先に進めなくなってしまう。
【００２４】
（問題点４）プロジェクト計画作成の非効率
計画作成過程では３つの非効率がある。作業単位生成の非効率、作業単位の工数見積りの非効率、そしてスケジューリングの非効率である。もしこの問題点４がクリアできれば問題点３の解決方法としてこのプロセス計画情報を作業単位実績の収集単位として利用できるので両方の問題が一挙に解決できる。これは統合プロセス管理システムの問題である先に、現行のプロジェクト管理ツールの問題でもある。
【００２５】
（作業単位生成の非効率）
システム開発には開発標準があり、開発工程とその下の細かな作業工程の構成や順序関係が定義されている。プロジェクトの作業単位とは、結局この定義された作業工程が開発対象となるシステムの各システム階層の開発ロットに対しそれぞれ適用されたものである。大規模開発や、開発ロットを細分化したい場合は作業単位の数はかなり多くなる。これをいちいち人手で作成し、スケジューリングしては大変な工数になってしまう。
【００２６】
（作業単位の工数見積りの非効率）
ソフトウエア開発の見積り精度は人的要素の影響が大きいためにかなり低い。上流工程での見積りは基本的にはシステム構造の導出属性から幾つかの機能量を計算し、それに変換係数を乗じて概算する（ＦＰ法）。下流になるにつれ、多くの場合は作業計画をＷＢＳに分解した後、各ＷＢＳの工数を経験的な感で算出している。精度の問題と工数見積りの非効率の両方の問題がある。
【００２７】
（スケジューリングの非効率）
現状ではスケジューリングは手作業が中心だが、作業単位がチケットにまで落ちてさえいれば、作業単位に人を割当てることも、或いは人に作業単位を割当てることも比較的簡単である。問題なのはタスクレベルの計画まで落とす方である。システムからサブシステム、サブシステムからビジネスフロー、ビジネスフローからプログラムという具合に、上位層から段階的に下位層の面積イメージの作業単位計画を構成する部分を人がやる非効率がある。
【００２８】
（問題点５）統合プロセス管理システムのアクセス量、排他制御の頻度増加によるレスポンス悪化の懸念
統合プロセス管理システムでは従来別々のツールで扱ったタスク情報とチケット情報とを１システム内に併せ持ち、更に異質なプロセス情報をも取り込み、更には作業単位情報に加えて年月日別情報をも併せ持つようなデータベースを形成する。情報量が増加し階層関係も深くなるうえに、プロセス情報自体が階層的な集約情報をなすために、例えば実績集計の度に上位層程更新が集中する特徴を持つ。つまり最下位層に実績データが発生するたびに、階層関係で繋がった上位層ほどデータの集中度合が増す。この排他待ちを避けるために上位層へ集中する一連の集約処理を単純化、高速化して処理時間を短縮しかつ差分データを中間層にスタックするなどして処理の集中を緩和する必要がある。
【００２９】
（問題点６）マスタ計画管理ツールと作業管理ツールの機能バランスの問題
マスタ計画管理ツールと作業管理ツールは予めそれを連結して使うことを前提に開発されたものではないため、利用する側から見るとあたかもひとつの機能を二つのツールに分けて使うような機能バランスの不味がみられる。マスタ計画管理ツールと作業管理ツールを繋ぎ合わせてその問題が解決するわけではない。
【００３０】
（機能バランスの不具合点）
（i）マスタ計画管理ツールでは操業暦が考慮され、作業管理ツールでは考慮されない。
（ii）資源（人）別の日別稼働調整がタスク計画では考慮され、チケット計画では考慮されない。もしタスク計画段階での人の割当てが現実的でなくチケット計画で割当てるとすれば、その場合人の日別稼働調整はできないことになる。
（iii）マスタ計画は本来粗くて構わないが、作業者を指定するチケット計画では、例えば個人のｐｆが反映させるとか、資源別情報を考慮されるべきであろう。使うか使わないかはケースバイケースで選べば良い。
【００３１】
（iv）二つの違うシステムを単に繋ぎ合わせただけだとシステムの重複や無駄が発生する。例えばタスク計画とチケット計画が別々の形式のファイルに分かれ、タスクとチケットの境界で情報内容を一致させたり、チケット実績からチケット実績へ繋げるための余計な手間暇が発生する。また似たような診断・分析機能が別なツールになる、など。
【先行技術文献】
【特許文献】
【００３２】
【特許文献１】特開2013-178618ソフトウエア開発工数見積り方法とシステム
【特許文献２】特願2013-148758ソフトウエア開発方法
【非特許文献】
【００３３】
【非特許文献１】「ひと目でわかるＰｒｏｊｅｃｔ２０１３」、大石守著、日経ＢＰ社、2013
【非特許文献２】「ＯｐｅｎＰｒｏｊ入門」、E-Trainer.JP、オーム社、2009
【発明の概要】
【発明が解決しようとする課題】
【００３４】
１．統合プロセス管理システムのコンセプト
統合プロセス管理システムの全体のコンセプトについてまず述べておく。図７に示す５項目に更に＋２項目を追加している。
【００３５】
（１）リアルタイムな問題把握と対応のスピード化
ラグタイム無しに、プロジェクトの当事者と同じ深さの情報を収集して見える化する。従来のように一旦データウエアハウスのような容れ物に収集して加工するようでは、もはやリアルタイム性も現場との密着性も失ってしまう。唯ひとつのシステムであらゆるプロセス情報をリアルタイムに取り込み、直ちに最上位層まで集計し、プロセス情報がＰＤＣＡサイクルとして見えるようにする。従来のような別々のシステムで収集した情報をまた加工し直すような無駄を省き、またＶＱＣＤ情報の推移が直ぐに見え、全社のＰＤＣＡサイクルが階層方向にも横通しにも見える化する。データの論理的整合性だけをひたすらに唱える従来の統合データベースの考え方ではだめである。これが統合プロセス管理システムのもっとも基本にあるコンセプトである。
【００３６】
（２）縦割りの情報収集型からプロセス中心型へ
従来の情報システムは図８左に示すように元々ひとつのプロセス情報をまったく別々の情報システムで収集している。従来のデータベースではキー情報で相互の参照関係を持つ重複の無い正規化情報程度の意味でしかなく、プロセスをどう変えるかの視点がないので、リアルタイム性やプロセス情報のＰＤＣＡサイクルなどはあまり意識されない。現実にそれぞれのスタッフ部門で管理された縦割りシステムがあり、情報が分断され、見えない壁ができ、そこではシステムや情報の重複も避けられない。それに対しプロセス中心型では図８右で示すようにひとつのシステムで情報の発生元であるプロセス単位に様々なＶＱＣＤ情報を取り込み、プロセス情報だけを見て仕事を進められるようにする。
【００３７】
（３）異質なプロセスを共通な形式で標準化
ここは「背景技術とその問題点」の（問題点１）で述べた部分と重複がある。企業全体では様々なプロセスがあるが、システム開発のプロセス例を図９に、人材育成プロセス例を図１０に示す。この二つは全く異なったプロセスであるにも係わらず、ＰＤＣＡサイクルの観点で見ると共通点がある。プロセス内の中間のまたは最終のアウトプット単位でプロセスを分割したとき（それを分割プロセスまたは作業単位と呼ぶ）、どの分割プロセスの情報もプロセス計画（Ｐ）とプロセス実績（Ｄ）とアウトプットレビュー（Ｃ）をセットで持つ形をとる。各レビューではアウトプットをＶＱＣＤの観点でチェックする。もしそこで不具合が出れば、計画外の作業単位が生成され対応がとられる（Ａ）。ＶＱＣＤ情報は項目レベルで見れば異質なプロセス間で全て同じではないが、ＶとＱを除いては共通項目が多い。そこでＶＱＣＤ情報をプロセス共通部とプロセス固有部に分離して管理すれば全てのプロセスの作業単位は図１２に示すように計画情報（Ｐ）と実績情報（Ｄ）、レビュー情報（Ｃ）を持つ共通形式に統一できる。
【００３８】
この共通形式のプロセス情報を階層関係情報で繋げば図１３に示すように最上位層から最下位層まで関連づけられたプロセス情報の体系図となる。上位には組織層の集約プロセス情報があり、その下にプロジェクト層の集約プロセス情報がある。
【００３９】
（４）プロセス単位のＰＤＣＡ／ＨＤＣＡサイクルの複層的な連鎖
ＰＤＣＡ／ＨＤＣＡサイクルは図１１で示すように上位層では組織ＰＤＣＡが廻り、その下にプロジェクトＰＤＣＡが廻り、さらにその下に試行的性格の強いＨＤＣＡサイクルが廻る。ＰＤＣＡサイクルが下位の多くの主体的なＨＤＣＡサイクルに支えられており、この複層的なＰＤＣＡサイクルの構造が企業活動を支えている。特に下位構造の豊かさが社員の主体性の深度を計る指標ともなる。
【００４０】
（ＰＤＣＡサイクルの廻り方の違い）
タスクとチケットはマスタ計画か差立計画かに本質的な違いがあるがそれはＰＤＣＡサイクルの廻し方の違いでもある。上位層の実績は下位層の実績の単なる集約値になるが、上位層の計画やレビューは経営会議や運営会議で図られる戦略的なものであり、下位層の計画やレビューの単なる集約結果ではない。またアクションについても、下位層では差立てられた作業指示に不具合が生じてもタスク計画自体は変えず、遅れ進みを残業や休日出勤、リソースの増減、計画外チケットの追加などで対応できるが、上位層では、マスタ計画そのものの見直し（つまりタスクの追加や削除）やリソースや体制の変更等の対策がとられる。
【００４１】
（５）真実・事実の見える化
（失敗プロジェクトの多い現状）
システム開発では失敗プロジェクトが多い。何年経っても解決しない。開発では多くの部分が開発者の判断に委ねられるが、人の知識には限界があり分からない領域やリスクとすら認識できない部分が必ず残り、それを補う手段であるコミュニケーションもまた欠陥だらけなことが根本にある。それ故、リスクに気づかないままプロジェクトが進行し、後になってから問題が発覚する。見えない問題や見え難い問題を浮かび上がらせるにも、まず足元の易しい問題がきちんと整理されていなければならない。またプロジェクトを後からでも追跡でき、また第三者の目からも計測データや記録データを通して実証的に見えることが重要である。プロセスが計量化できていないことと、失敗プロジェクトの多いことと根は繋がるところがある。
【００４２】
（定量データを収集し事実を追跡できる仕組みへ）
ソフトウエア開発の見積精度は低く生産性も満足に取れているとは言えない。開発作業は人に依存する部分が甚だ大きく、定型的な標準作業が少ない（そこまで標準化できていない）。従って製造業より計量ベースのきちんとしたプロセス管理ができていない。
このような状況でプロセスの合間に機械的な品質レビューやチェックをやるだけではほとんど失敗を減らせない。人のパーフォーマンスを高め、ユーザとの目標品質ギャップを減らし、事実が定量的に追跡できるまで、プロセスが計量化されてこないとうまくいかない。
【００４３】
（非定量情報とリスク評価の重要性）
開発初期段階でのユーザと開発者の目標品質のギャップが致命的な失敗を引き起こす。失敗リスクの要因はいろいろだが、双方の勝手な、都合のよい解釈でギャップが埋まらないことが一番大きな影響をもたらす。このギャップは当事者には見えていないことが多く、機械的な品質チェックでは捉えられず、ユーザとの打ち合せ記録やユーザ側の懸念材料などをユーザにも第三者にも見える化して、できるだけ早期に問題が挙がるようにする必要がある。プロジェクトの当事者はまず目の前のスケジュールを最優先してしまう。そのためには、図１５のようなプロセス内で生まれる打合せ記録などの非定量情報も取り込む。更にはひとつのプロジェクトのプロセスの流れに沿って、定量情報、非定量情報を図１６に示すように取り出し、プロセスを追跡できるようにする。多くの関係者の思惑が絡んでむような領域では、多くの場合プロジェクトの当事者だけの解決能力を越えると見なして対処されるべきである。
【００４４】
（６）人を育成できる、すっきり、さっぱりした見える化システムへ
見える化の現場でも雲がかかっているようで実態が良く見えないことがある。まだ対象に対して集中する力ができていない場合である。しっかり考える時間を作るために極力無駄を減らし、すっきり、さっぱりした見える化システムにしなければならない。そのために統合プロセス管理システムではただひとつのシステムであらゆるプロセス情報を同じ形式でリアルタイムに収集し、直ちに階層的に集計され、プロセスＰＤＣＡサイクルが見えるようにする。見える化で人材を育成するには、作業者は常に次の見えない問題を考えなけらばならない状況に置かれることが重要である。最初から答えが見えては人の育成にはほとんど役に立たないが、課題を見出すこともまた見える化の課題である。そして見えないことを繰り返し追い込んでゆく過程があってこそ、真実の見える化の意味に向き合うことができる。
【００４５】
（７）１０年の長期的なスケールで人を作る見える化システム
統合プロセス管理システムでは、中長期計画なども従来のように他の計画と切り離された独立した計画ではなく、下位のプロジェクト管理の作業単位情報と関連づけたまま保有する。そのために数年に渡る企業全体のＰＤＣＡサイクルの推移をもプロセス情報を元に取りだすことができるし、それらを過去の成功体験、失敗体験として生かすことができる。またリクルーテングや人材育成プロセスなど長期的な視野が必要なプロセスこそ企業の基盤を作るうえで最も重要であり、そのために長期スケールの大きなＰＤＣＡサイクルを廻すことができるようにする。
【００４６】
２．発明が解決しようとする技術課題
先に述べたシステムコンセプトを実現するためには、プロジェクト活動に踏み込んでＰＤＣＡサイクル情報を収集可能なプロジェクト管理機能を内部に持つことが非常に重要なポイントになる。但し単にプロジェクト管理機能を取り込むだけでは新しいコンセプトの見える化の機能として不十分であるので、次のように機能を拡大する必要がある。
（i）全てのプロセスのＶＱＣＤ情報をリアルタイムに収集
（ii）収集データを直ちに階層軸、時間軸で集約する
（iii）データベース中の計量データ・記録データから事象の追跡ができるようにする
（iv）全て同一形式の階層集約型プロセス情報でＰＤＣＡサイクルの階層を作る
これらはデータベース構造と強く係わる。更に従来技術の問題点で挙げた６項目を一緒に解決するために、プロジェクト管理システムの次の四つの技術課題（図１９で示す）として集約する。これらは統合プロセス管理を成熟化するための技術というよりは、統合プロセス管理を成り立たせるための基本要件となる技術である。
【００４７】
（１）作業単位、年月日別計画を併せ持ち、プロセス固有情報も取り込んだ階層集約型データベース構造
タスクとチケットのマスタ計画管理機能と作業管理機能とをそのまま生かしながらひとつのプロセス情報形式に統合する。また中期計画や年次計画や予実情報を取り込むために従来の作業単位情報の他に、年月日別情報を併せて持つようにする。またチケットにもタスク同様に年月日別情報を適用して作業者別の日別の稼働調整ができるようにする。更には開発プロセス以外の任意の固有プロセス情報をも取り込む。またそれらのプロセス情報が共通の階層関係情報を持てるようにし、階層関係に従って上位のプロセス情報が下位のプロセス情報の集約値となるようなデータベースの構造にする。
【００４８】
（２）小ロットのプロセス実績情報、稼働管理情報の効率的な、同時収集方法
生産性や品質指標の精度を高めるために不可欠となる小ロットのプロセス実績情報と稼働管理情報とを効率的に同時収集するための技術課題であり、統合プロセス管理システムのテーマである以前に、プロジェクト管理ツールのテーマである。
【００４９】
（３）差分によりプロセス実績情報の集約処理を高速化・単純化する技術および中間スタック情報を使ったリアルタイム集計処理の実現
リアルタイムに取り込んだ実績情報を階層関係情報で繋がる上位の実績情報を直ちに効率的に集計するための技術課題。チケットとタスクを別々のファイルに保持すると途中で処理の分断が起きるのでチケットとタスクは作業単位の種類の違いとして統一する。統合プロセス管理システムでは従来のプロジェクト管理システムに較べてデータ量が増え、データ階層が深くなり、上位層のタスクにアクセスが集中し易くなる不利な環境になる。
【００５０】
（４）プロジェクト計画の自動作成技術
作業単位の生成方法、開発工数の見積り方法、プロジェクト計画のスケジューリング方法を自動化し、プロジェクト計画作成の負荷を軽減するための自動化技術であり、統合プロセス管理システムのテーマである以前に、プロジェクト管理ツールのテーマである。
【００５１】
この４つの課題を、図１に示す統合プロセス管理システムの機能構成の中に位置づける（注８）。統合プロセス管理システムは８つの機能部とその下位の幾つかのサブ機能部に分かれる。
（i）データベース部
（ii）計画作成部  サブ機能部（作業単位計画作成部、年月日別計画作成部）
（iii）計画編集部  サブ機能部（作業単位計画編集部、年月日別計画編集部）
（iv）実績登録部  サブ機能部（作業単位実績登録部、年月日別実績登録部）
（v）実績集約部  サブ機能部（作業単位実績集約部、年月日別実績集約部）
（vi）実績編集部  サブ機能部（作業単位実績編集部、年月日別実績編集部）
（vii）資源割当部
（viii）プロセス情報参照部
（注８）図１中では省略している情報やサーバとして次のようなものがある。
（省略情報）システム構造情報、作業スコープ定義情報
（サーバ）  非定量情報保有サーバ
【００５２】
図２の既存のプロジェクト管理ツールの機能と比較すると分かるように、この機能構成の中には統合プロセス管理で新規に追加される機能(年月日別情報にかかわる機能)と、従来のプロジェクト管理ツールの機能と全く同じではないがそこから容易に類推できる機能（主に作業単位情報にかかわる機能）とがある。また似たような機能名で内容的には異なる機能を含むもの（資源割当機能）もある。容易に類推できる機能は補足説明に止め、特許請求項に直接関係する４つの機能部／サブ機能部の技術課題を取り挙げる。また資源割当機能は特許請求項の対象外であるので、これも補足説明に止める。
【００５３】
課題１．データベース部の構成：作業単位、年月日別情報を併せ持ち、プロセス固有情報も取り込んだ階層集約型データベース構造
異質なプロセス情報の形式を統一したデータベース構造にする。中期計画／実績、年次計画／実績、予実情報などを取り込むために、データベース部のプロセス情報に従来の作業単位情報と併せて、年月日別情報を取り込む。タスクの階層関係情報と前後関係情報、チケットの階層関係情報はプロセス情報から独立した関係情報として括り出し、作業単位情報および年月日別情報および他のプロセス情報から共有する。そのほか（i）タスクとチケットを種類が異なる作業単位情報として統一する、（ii）チケットにも年月日別計画を持ち、日々のチケット別稼働時間調整ができるようにする、（iii）開発プロセス以外の異質なプロセス情報も共通情報部分と固有情報部分を分けて取り込むようにする。これらのプロセス情報は別々の論理テーブルとして持ち、論理テーブルをアクセスする処理もできるだけローカライズして資源の競合を避ける。
【００５４】
課題２．実績登録部の構成：小ロットのプロセス実績情報、稼働管理情報の効率的な同時収集方法
プロセス実績収集部では作業単位稼動実績や個人別稼動情報ばかりではなく、諸経費情報や品質のレビュー情報等も収集するが、圧倒的に入力負荷が高いのは作業単位稼動実績と稼動管理情報であり、各種の実績を収集する機能のなかで最も重要な課題である。特に作業単位稼動実績を個人別やプログラム単位の小ロット単位の細かさで管理精度を高めようとした場合、手入力では全く困難になる。また従来のような作業単位稼動実績と稼動管理情報との類似情報の重複入力を除く。
【００５５】
課題３．実績集約部の構成：差分情報を使った集約処理の高速化、単純化および中間スタック情報を使ったリアルタイム集約処理の実現
実績収集部でリアルタイムに取り込む最下層のプロセス稼働情報を一旦実績スタック情報に取り込む。そこから階層関係情報で繋がる上位のプロセス情報を直ちに集約する部分で、実績スタック情報の差分情報を使って一連の階層軸方向、時間軸方向の集約処理を高速化、単純化する。それに加えて中間階層に差分情報の中間スタック情報を設け、上位層への集約処理の集中を回避するとともに下位層のリアルタイムな集約処理を同時に実現する。また既に集約した過去の最下位層のプロセス情報を修正したい場合は実績スタック情報を更新し、そこから差分情報で同様に上位層の修正ができるようにする。
【００５６】
課題４．計画作成部の構成：プロジェクト計画の自動作成
プロジェクト計画作成作業を効率化する課題である。まず構成する作業単位を階層関係情報とともに作成する。作業単位はシステム規模や要求管理精度によっては、多数生成され、人手でやれば大きな工数が発生する。そこでプロセスを定義する作業スコープ定義と開発対象システムのシステム階層別の開発ロット情報を持つシステム構造情報を使って自動的に作業単位を生成する。次に作業単位別の開発工数が見積られ、その後で上位層から下位層へ段階的に面積イメージの計画が展開される。実績とは違い計画は一般に上位層から下位層へ、つまりシステムからサブシステムへ、更にサブシステムからビジネスフローへ、更にはプログラムへとブレークダウンされ、ある時点の計画情報を見ると様々の段階まで展開された計画が混在する場合がある。
【００５７】
補足１．統合プロセス管理システムのシステム基盤の構成
図２０のハードウエア構成例はシステム機能を満足させるための唯一の構成ではなく、いくつもの選択肢がありうる。大きく分ければ、サーバ集中型かまたは図２１の例のように部門サーバと全社の参照系サーバとで構成する分散型がある（注１３）。また処理部分に関してはクライアント側で独立したアプリケーションを持つタイプとサーバ側に機能を集中するタイプがある。
（注１３）図２０、図２１では必要情報を全て表現してはいない。（注８）を参照。
【００５８】
（集中サーバ型か分散サーバ型か）
データベースや処理をひとつのサーバに集中させる集中サーバ型と、例えば部門サーバとそれを統合した全社サーバとで構成するような分散サーバ型とが考えられる。集中型はシンプルな構成なので運用管理が分散型より単純になるが、負荷が集中サーバに集まる問題がある。分散型の場合は、例えば部門サーバへの参照更新は部門内だけに使用制限し、他部門の情報は全体サーバから参照するように役割を分けることができる。但しそのとき部門サーバ側では部門で必要とする組織階層の階層情報までしかないので全体サーバ側で全社の最上位の組織階層の階層情報を持たせる工夫は必要である。分散型にすると部門サーバのデータ量とアクセス量を減らせかつ集約処理の階層を浅くできるのでレスポンスを高めることができ、同時に全体サーバ側でもアクセス量を減らすことができる。また情報セキュリテイの管理を部門に任せられ、新しいプロセスの追加が容易にできるなどの利点がある。しかし部門サーバ側の更新情報を全体サーバ側に反映させる必要がある点が集中型より難しくなる。ここでは集中サーバ型を仮定する。
【００５９】
（注１０）分散型で部門サーバと全体サーバのデータを同期化させる方法はいくつかある。代表例は部門サーバのデータベースログ情報を使ってリアルタイムにレプリケーションを作る方法である。実際数個の分散サーバの更新情報をレプリーションで１個の統合サーバへ反映させるツールも存在する。
【００６０】
（クライアント処理かＰＣ独立型処理か）
実績収集部のクライアント側の処理でこの選択肢が出てくる。開発者がクライアントから自社サーバへ常に接続できる環境であれば、データをダウンロードしたり、アップロードする面倒がなくＷｅｂシステムだけで単純に構成できる。しかしさまざまの理由で、その環境があるとは限らない。従って作業実績の収集ではサーバとオフラインでＰＣ側単独でもできる機能を持つ方が望ましい。その場合はサーバ側から作業実績の収集に必要な情報を一旦クライアント側にダウンロードし、サーバと切り離してＰＣ側だけで作業と並行して、あるいは作業後に一括してプロセス実績を登録し、サーバ側に送信する方法がある。この場合はＰＣ側で独立して動くプログラムが必要になる。ただしこの場合はプロセス実績をリアルタイムに収集できない。
【００６１】
（情報セキュリテイ管理）
情報セキュリテイを管理する方法は幾通りもあるなかで、情報の階層構造を利用する方法がある。ある特定のタスク以下の全階層の情報を更新、参照できるアクセス権限とか、あるタスク階層以下の全情報を参照できるアクセス権限とかを定義し、利用者のアクセス権限をセキュリテイ管理者が予め登録しておく。このアクセス権限は、図３４の基底ビュー画面で表示できる最初の階層情報としても利用できる。尚、データベース構造は、プロセス情報を計画情報、実績情報、プロセス共通情報、プロセス固有情報等に論理テーブルを分けて構成するので、更に細かくアクセス権限を設定することができる。
【００６２】
補足２．計画編集部の構成
プロセス計画情報を画面編集する部分であり、作業単位計画の編集と年月日別計画の編集とに分けられる。
（作業単位計画の対話修正）
作業単位計画の編集は従来のプロジェクト管理ツールと基本は同じであり図３の基底ビュー画面に対応した図３４の基底ビュー画面から必要ならサブ編集画面を呼び出して編集処理をする。
（年月日別計画の対話修正）
個別作業単位の作業単位計画を年月日別計画に落とす場合がある。その場合は各作業単位で使用する操業暦の操業パターンを指定して日別稼働時間を取り込み自動展開する。特にチケット計画では作業単位に作業者を割り当てるので、資源情報を使えば個人の生産性ｐｆをも考慮できる。自動展開したあとの年月日別計画を図３４の年月日別情報のビュー画面に表示し、必要なら図２５のような編集画面を呼び出して編集する。
【００６３】
計画を更新した場合必要ならばその上位層の計画へ反映させる。普通はタスクの最下層まで展開した後に行う。また一般的には計画情報の上位層の集約には図４７に示すごとく直接集約方法を適用する。差分集約法が適用できるのは、上位層の集計領域のデータ整合性が保証される状況にある場合である。この処理の流れは次のようになる（図６３に示す）。
（i）作業単位計画の編集。必要なら上位層の作業単位計画の集約も行う。
（ii）必要な場合、作業単位計画を年月日別計画に自動展開する。
（iii）年月日別計画の編集。必要なら上位層への集約も行う。
（iv）上位層の集約を行うについては通常は直接集約方法を適用。もし差分集約法を使う場合には集約対象となる影響範囲を予めクリアするなどの考慮が必要。
【００６４】
（注１１）既存のプロジェクト管理ツールの計画編集は図３で示すビュー画面から行う。ビュー画面に表示する情報はビューバーから選択する。ビューバーにはガント（計画表示）、トラッキングガント（実績表示）、ネットワーク（ＰＥＲＴ図）、リソース（資源構造情報）、プロジェクト（プロジェクト構造情報）、ヒストグラム、チャート等１２種類ほどの表示情報の選択肢があり、ガントビューが基底画面である。統合プロセス管理システムではこの図３の画面に対応して図３４のような基底ビュー画面に拡張される。表示データとして作業単位情報に加えて、年月日別情報、プロセス固有情報などが増える。
【００６５】
補足３．その他の実績処理の各機能部の構成
（１）作業単位実績登録部の構成
実績登録部では直接プロセス実績情報を更新せず、一旦実績スタック情報に取り込む。実績スタック情報は通常入力画面単位にあり、これを差分としてプロセス実績情報に集約してゆく。作業単位実績情報の登録は従来のチケットの実績の登録と同じに図３に対応した図３４の基底ビュー画面から必要ならサブ画面（注１２）を呼び出して登録する。ビューバーの選択肢が増えかつタスクとチケット情報を作業単位情報の種類の違いとして扱う以外は従来の機能と類似している。
ただし、実績登録作業を効率化するために工夫が必要な場合は例えば２．４で述べるような方法を用いる。
【００６６】
（２）実績編集部の構成
プロセス実績情報を画面編集する機能であり、実績スタック情報に対して追加モードで更新し、プロセス実績情報の差分集約処理がその後実行される。稼働実績の修正では一旦実績登録部にまで戻って修正することも可能ではあるが、この場合は実績スタック情報を修正する方法である。
実績スタック情報を編集する部分と同じに図３のビュー画面を元にした図３４のビュー画面から必要なサブ画面（注１２）を呼び出して編集する。
（注１２）サブ画面：プロセス情報をビュー画面に一覧で表示しておき、そこで更新対象となる情報を指定し（絞り込み）、サブ画面に表示して更新する場合が多い。実績スタック情報の編集画面も対象プロセス実績情報を指定して呼出される。
【００６７】
（３）プロセス情報参照部の構成
データベースに保管したプロセス情報を全社で参照する部分であり、プロジェクト管理ツールでは図２の実績参照部に該当する。データベース中で時間軸、階層軸の集約情報をプロセス単位で保持し、図１３のプロセス情報の階層関係がシステム上は図３４の基底ビュー画面として可視化される。基底ビュー画面の初期画面の最上位データはセキュリテイ管理のアクセス制限範囲で制御することができる。基本的にはそこから次のような幾つかの視点の見える化情報を取り出すことができる。
【００６８】
（i）定量データの見える化：計画進捗情報や品質の定量データのバラツキ状況や工程間の品質指標の推移などのあらゆる定量データをグラフで表現。上位層の実績は集約データで表現される。具体的には図１３の情報体系から抽出データを３つの切取り軸（階層範囲軸、時間軸、データ項目軸）で取り込んで図１４のようなグラフで表現する。
（ii）非定量データの見える化：図１５に示すように、プロセス情報の中からデレクトリパス名などで指示される非定量情報保有サーバ中の各種の非定量情報が参照できる。プロセス関連図、品質レビュー記録、テスト記録、会議記録など。
（iii）テーマ別トレース情報の見える化：定量データ、非定量データを併せて、テーマ別のプロセスのトレース情報を加工表示する。例えばＡプロジェクトの失敗原因を追究するためとかプロジェクトの途中経過を見える化するためとか。
（iv）異質プロセスに跨るＰＤＣＡサイクルの見える化
統合プロセス管理システムでは、あらゆる異質なプロセスが同じように見える点が重要である。例えば図１７では異質なプロセス間の情報連携を示しているが、ある受注案件が営業活動から購買プロセス、開発プロセス、品質管理プロセスを経て、検収に到るまでの関連プロセスが、全て同じ形で見える。営業システムや購買システム、品質管理システムなど全く別々なシステムの情報を組み合わせるのではなく、最初から異質なプロセスの作業の仕掛状況や問題発生状況が同じように見える。
（v）採算情報の見える化
図１８は様々なプロセスからの採算情報がリアルタイムに上がってプロジェクト階層、組織階層で集計される流れを示している。この過程でプロジェクト採算情報や組織採算情報が統合プロセス管理システムの中のひとつの情報として見える化される。
【００６９】
補足４．資源割当部の機能
人を手配するには、上位層の見積段階で保有技術スキルレベルを含めて予測資源のシミュレーションができなければならない。その機能を担う部分であるが、基本は標準開発期間−総開発工数対比表から要員数を決め、作業スコープ定義から必要技術スキルを決め、プロパー、協力会社要員に配分する。
【課題を解決するための手段】
【００７０】
１．課題１「データベース部の構成：作業単位計画、年月日別計画を併せ持ち、プロセス固有情報も取り込んだ階層集約型データベース構造」の解決手段
（請求項１に対応）
【００７１】
１．１．プロセス情報のデータ項目
プロセス情報とは作業単位ごとの生成物に係わるＶＱＣＤデータ項目であり、システム開発プロセス、運用立上げプロセスのＶＱＣＤ項目例を図３１に、人材育成プロセスのＶＱＣＤ項目例を図３２に示す。Ｖに属する項目には開発ボリュームや運用ボリューム、売上金額、人材スキル×人員数などが含まれ、Ｑに属する項目には各種の設計品質、製造品質、レビュー品質指標などがあり、Ｃに属する項目には投下工数や投下コストや諸経費などがあり、Ｄに属する項目には作業納期や開発リードタイム、開発進捗度などが含まれる。ＶＱＣＤのうちＣ，Ｄに属する項目はほぼプロセスに係わらず共通であり、Ｖ，Ｑに属する項目はアウトプットの対象物に依存する固有情報が多くなる。但し共通情報とは、各プロセスで共通に発生する情報の意味ではなく、プロセス横通しで見た方が良い情報と解釈すれば、プロセス固有の情報を共通情報に含める場合もでてくる。分類そのものをあまり厳密に考えることはない。
【００７２】
１．２．プロセス情報の分類と論理テーブル構造
プロセス情報にはいくつかの分け方があるが、（i）タスク情報かチケット情報か、（ii）計画情報か実績情報か（iii）作業単位情報か年月日別情報か、（iv）プロセス共通情報かプロセス固有情報かに分けられる。このうち（i）、（ii）は既存のプロジェクト管理ツールのなかにすでにある分け方であり、（iii）、（iv）が統合プロセス管理で新たに追加する分け方である。プロセス情報には年月日別情報が多くこれを取り込むために、作業単位情報に加えて、年月日別情報が併せて必要になってくる（図２４参照）。
（i）タスク情報かチケット情報か
タスクとチケットは作業単位の種類の違いとして区別はするが、論理テーブルとしてはひとつに統合する。
（ii）計画情報か実績情報か
作業単位情報も年月日別情報も計画と実績が同時に更新されることが少ないため計画情報と実績情報とを別々の論理テーブルに分ける。
【００７３】
（iii）作業単位情報か年月日別情報か
（年月日別情報の意味）
タスク計画ならば作業単位計画と同時に面積イメージ（日別の投下人員や稼動時間がある、要するに日平均、月平均ではない）の年月日別計画を持ち、実績ならば作業単位実績と同時に年月日別実績を持つようにして、タスク横通しで年月日別でも管理できる方が便利である。現に中期計画や年次計画では月別に展開された年月日別計画を用い、予実管理では年月日別実績で管理するのが一般的である。他にも、日別に人員配置を検討する必要も出る。作業単位情報と年月日別情報は論理テーブルを分ける。
【００７４】
（作業単位情報と年月日別情報の関係づけ）
計画情報は図２４上図に示すように常に作業単位情報から年月日別情報へ展開する。年月日別情報は日別の稼動時間と投下人員で日単位数の調整が可能である。例えば作業単位で３．５人月平均のタスクを年月日別計画では前半は３人月で後半は４人月で配分することができる。ただし、作業単位計画と年月日別計画で整合性をとらなければならないので、総工数は両者で等しく、また年月日別の作業の開始日、終了日は作業単位の開始日、終了日の間になる。一方実績集約については、常に年月日別実績から作業単位実績へ集約される。
【００７５】
（iv）プロセス共通情報かプロセス固有情報か
共通部の作業単位計画が計画管理上の中心情報とすると固有情報は従であり、作業単位計画のようなスケジューリングは発生しない。共通情報、固有情報とも基本的には作業単位別情報と年月日別情報とに分かれる。固有情報はプロセスごとに異なる情報を持つため、共通情報とは切り離してプロセスごとに独立した論理テーブルを保有する。
【００７６】
具体的なプロセス情報の論理的に分割したテーブル構成例を図２８に示す。
（イ）共通情報の作業単位計画（１個）    ：図２８のテーブルＡ
共通情報の作業単位実績（１個）    ：図２８のテーブルＤ
（ロ）共通情報の年月日別計画（１個）    ：図２８のテーブルＢ
共通情報の年月日別実績（１個）    ：図２８のテーブルＣ
（ハ）固有情報の作業単位計画（１個）    ：図２８のテーブルＡ１〜ｎ
固有情報の作業単位実績（１個）    ：図２８のテーブルＤ１〜ｎ
（ニ）固有情報の年月日別計画（１個）    ：図２８のテーブルＢ１〜ｎ
固有情報の年月日別実績（１個）    ：図２８のテーブルＣ１〜ｎ
【００７７】
異質なプロセスの種類数をnとすると原則４（ｎ＋１）個の論理テーブルで構成する。もし後からプロセスを追加、削除をする場合、この構造だと固有部分のみを追加削除すれば済む。またアクセス権の設定をプロセス単位にも分けて設定でき、セキュリテイ管理がやりやすくなる。
（注１３）中期計画や年次計画は組織計画情報やプロジェクト計画情報と別々に存在するわけではなく、組織計画情報やプロジェクト計画情報の年月日別情報のなかに、タイムスパンの異なるデータがあるだけである。例えば図２８の年月日別情報の中で、月単位の情報は年月日の日をゼロしたデータと取り決め、年単位の情報は月と日をともにゼロとしたデータと取り決める。
【００７８】
１．３．論理テーブル構造と処理のローカライズ
統合プロセス管理システムの各機能部と論理テーブルの更新アクセスのマトリクスを図２７で示す。このようにアクセスをローカライズする理由は、ひとつは実績データのように頻繁に発生するデータ更新で、排他待ちやデッドロックが発生することを回避するため、もうひとつはシステムの機能構成をシンプルで分かり易くするためである。更には特定プロセス自体を追加・削除するごとに発生する保守作業を局所に限定できる。但し排他待ちを回避する根本的な対応策は課題３で行う。
【００７９】
１．４．作業単位を繋ぐ階層関係情報、前後関係情報の構造
作業単位を階層関係、前後関係の２軸方向につなぐ関係情報は、プロセス作業単位情報の中に含めず外に切り出し、関係情報は４（ｎ＋１）個の論理テーブルから共有される（ｎはプロセスの種類数）。前後関係情報については、前後の作業単位の繋がり方の依存関係情報をも含むことができる（（注７）（i）参照）。関係情報をプロセス情報から独立させることで必要ならば関係情報自体を種類複数持たせることも可能になる。それによって例えば関係性が途中分岐するような構造をも作り出せる。実際に結構頻繁にある組織変更などは予実情報を扱うとき頭痛の種になり易いが、分岐構造を使えば、関係性情報の有効期間を判断することでこの問題を回避できる。但し、そこには上位階層の排他制御が絡むので計画更新時の処理の配慮が必要になる。
【００８０】
１．５．実績スタック情報
実績情報は直接プロセス情報に書き込まないで、一旦実績スタック情報に追加モードで書き込む。その後実績集約部で差分集約法を適用してプロセス情報の上位階層を集約する。例えばｋ個の実績が上がる場合はｋ件の実績情報が実績スタック情報に一旦書きこまれ、一方プロセス情報にはそれが差分として集約された情報として書き込まれる（図２９下、右参照）。もしｍ個の実績登録画面があるとすると、ｍ個の実績スタック情報の論理テーブルがあり得る。またもし実績登録後に修正が発生した場合は、実績スタック情報にこれも追加モードで更新をかける。そのために実績スタック情報ではシリアル番号とプロセスキーと作業者名と開始時刻、終了時刻、稼働時間は必ず持つ。このシリアル番号に対して修正をかけ、更新後の開始時刻、終了時刻が有効になり、稼働時間は差分が書き込まれる。後述する図３７、図４３、図４４の異なる実績登録のいずれの場合も実績スタック情報を使用している。
【００８１】
１．６．操業暦
休日や操業形態（始業時間、終業時間、稼働時間など）の異なる幾つかの操業パターンを持つことができる（図２９上参照）。稼働時間を日別に調整する場合は、操業パターンのどれかをプロセス情報の年月日別情報に取り込み、それを調整する。
【００８２】
２．課題２「実績登録部の構成：小ロットの作業単位稼動実績、稼働管理情報の効率的な同時収集方法」の解決手段
（請求項２に対応）
実績登録部の機能構成は図３５中央図で示すようにプロセス管理モニタ画面と差立情報処理部、個人別稼働状況処理部、実績スタック情報書込部を持つ。実績情報には稼動実績ばかりでなく、旅費や他の諸経費や品質レビュー情報など様々なＶＱＣＤ情報があるが、どのプロセスにも共通に発生し、圧倒的に入力負荷が高いのは稼動実績情報である。特に稼働実績情報を個人別や小ロットの開発単位まで詳細に収集し管理精度を高めたい場合、手入力では収集困難になる。またプロセス実績情報と稼働管理情報とを別々に収集する無駄を省く。但し従来の稼働管理情報では作業の種類ごとの作業時間を収集しているが、この方法では個別の作業ロット単位の作業時間を収集する違いが出る。
【００８３】
２．１．プロセス実績情報、稼働管理情報取集手順
プロセス計画情報作成からプロセス実績情報および稼動管理情報を収集するまでの全体のフローを図３６に示す。その流れは次のようになる。
（１）計画作成部、計画編集部で個人別チケット計画を作成
計画作成部および計画編集部でタスク計画とその下位層のチケット計画を作成し、最下層のチケットには作業者を指定して差立てる。
【００８４】
（２）実績登録部の機能
（差立情報処理部）
（i）作業者毎にプロセス管理モニタを起動。差立情報処理部で当日の個人別作業単位情報をプロセス計画情報から取り込み、差立情報としてメモリ上に作成。当日の個人別作業単位情報とはプロセス計画情報中のある作業者に当日までに差立てられた作業単位情報のうち、未完状態または未着手の作業単位計画である。
（ii）差立情報をプロセス管理モニタ画面の差立情報部に作業状況ステータスアイコンと一緒に表示し、作業者が随時、作業状況ステータスのアイコンをマウスクリックして選択できるようにする。
もし計画外チケットをプロセス管理モニタ画面に表示する場合は、まず計画外チケットを計画編集部で生成する。作成した計画外チケットを途中でプロセス管理モニタ画面に直ちに表示させる場合は、例えば計画編集部で対象チケットを指定し、差立情報処理部の当日作業を追加する処理を起動するようにする。その処理は単純なので説明は省く。
（iii）プロセス管理モニタ画面の作業状況ステータスアイコンの操作により、差立情報の作業状況ステータスを変え、差立情報部の表示を変える。
【００８５】
（個人別稼働状況処理部）
（iv）差立情報の作業状況ステータスが変化し作業中になったプロセスを個人別稼働状況情報に追加モードで書き込む。
（v）一定の時間間隔でタイマ起動され差立情報が作業中のステータスのプロセスについて個人別稼働状況情報の終了時刻と稼働時間を更新する。プロセス管理モニタ画面の個人別稼働状況部に、作業中のプロセスの稼働時間を帯の長さで表示する。
（vi）プロセス管理モニタ画面の作業状況ステータスアイコンの操作により、ステータスが変化し作業が終了する都度、個人別稼働状況情報のステータスを変更し作業終了時刻と作業時間を更新する。
（実績スタック情報書込部）
プロセス管理モニタ画面の作業状況ステータスアイコンの操作によりステータスが変化し作業が終了する都度、該当プロセスの個人別稼働状況情報を実績スタック情報に追加モードで書き込む。実績スタック情報は実績集約部でプロセス実績の集約処理が実行され、また稼働管理情報へも提供される。
【００８６】
２．２．個人別稼働状況処理部の機能詳細
プロセス管理モニタ画面から稼働実績を収集する処理部。作業同期型と作業非同期型の収集方法の違いや得失について図３８に示す。同期型は作業と並行して実績を収集する方法で、作業状況ステータスの変化によって作業状況の変化を、またタイマ起動によって自動的に作業時間の変化（終了時刻と稼働時間）を取り込む。一方非同期型は作業とは同期せず、作業後に１日分の稼動情報を一括で取り込む。通常は同期型で収集するが、非同期型はリアルタイムで実績収集できない作業環境の場合に必須の機能である。
【００８７】
（１）作業同期型稼働実績収集方法
プロセス管理モニタの画面イメージを図３９に示す。差立情報（個人別の当日の作業単位計画）が画面の差立情報部に作業状況ステータスアイコンと並べて表示される。作業状況ステータスアイコンをマウスでクリックして、作業状態を変えることができる。当日の作業開始時点から現時点までの作業状況は、個人作業稼働状況部に、作業単位計画と同じ識別色の、稼働時間に比例する帯の長さで表示される。例えば画面中のＰ０００２の開発作業を開始するとき、画面の差立情報部のＰ０００２に対応する「Ｐ直接」ステータスアイコンをクリックすると次に他のステータスアイコンがクリックされるまでＰ０００２の作業時間が継続するものとして自動計時され、個人作業稼働状況部に作業時間の長さが帯の長さで表示される。ステータスアイコンがクリックされなくとも（それは同じ作業が継続されていることを意味する）、ある時間間隔でタイマ起動されて作業時間を計時し、画面の個人別稼働状況部の作業時間の帯の長さを表示し直す。ステータスアイコン操作の働きの一例を図４０で更に詳しく説明する。
【００８８】
（図４０の説明）    チケットの作業状況ステータスの変化
このプロセス管理モニタ画面の例ではチケットの作業状況ステータスとして、Ｐ直接、Ｐ間接、停止、完了、廃棄と５つの状態を持っている。このステータスアイコンをマウスでクリックし作業状態を選択することができる。例えば
（i）プロセス管理モニタ画面のプロセスａのＰ直接アイコンをクリックするとプロセスａの作業開始となり、個人別稼働状況情報がメモリ上に追加作成され、プロセスａが個人別稼動状況部に表示される（タイマによる自動計時が始まる）
（ii）プロセス管理モニタ画面のプロセスａのＰ間接アイコンをクリックするとプロセスａの直接作業が中断され、個人別稼働状況情報の終了時間、ステータスが更新され、新たにプロセスａの個人別稼働状況情報が追加されプロセスａの間接作業が個人別稼動状況部に表示される（タイマによる自動計時が始まる）
【００８９】
（iii）再びプロセス管理モニタ画面のプロセスａのＰ直接アイコンをクリックすると間接作業が中断され、個人別稼働状況情報の終了時間、ステータスが更新され、プロセスａの個人別稼働状況情報が新たに追加作成され、プロセスａの直接作業が個人別稼動状況部に表示される（タイマによる自動計時が始まる）。
（iv）プロセス管理モニタ画面のプロセスチケットの停止アイコンもしくは完了アイコンをクリックして作業停止。完了の場合は１００％作業が終了したことを意味する。停止の場合は未完了で必要ならば達成率を入力できる。停止または完了したプロセスの個人別稼働状況情報の終了時間、ステータスが更新される。
（v）いずれの場合でも稼動中のプロセスが終了状態または停止状態に変わったとき、該当プロセスの個人別稼働状況情報が実績スタック情報部を通して実績スタック情報へ書き込まれる。
【００９０】
（２）作業非同期型稼働実績収集方法
この場合も画面構成としては図３９と同じである。また差立情報、差立情報部、個人別稼働状況情報、個人別稼働状況部の持ち方も同じである。但し作業状況ステータスアイコンをクリックしても作業の選択を示すだけで同期型のように自動計時は始まらず、個人別稼働状況部の表示もしない。その代わり非同期型ではステータスアイコンを選択した状態で、マウスを使って直接、個人別稼働状況部の作業開始点から終了点までドラッグして開始時間、終了時間を指定する。ドラッグされた作業開始点から終了点の間が作業時間となる。ドラッグを終えると同期型の作業終了状態となり、個人別稼働状況情報に追加して書き込まれる。そのとき個人別稼働状況情報が実績スタック情報部を通して実績スタック情報へ書き込まれる。
【００９１】
２．３．実績スタック情報書込部の機能詳細
個人別稼働状況情報で作業ステータスが作業中から作業終了または停止状態に変わった情報を実績スタック情報へ書き出す処理部である。個人別稼働状況情報も実績スタック情報も内容は同じ情報であるが、実績スタック情報にはある作業が終了または停止したタイミングで書き込まれる。また個人別稼働状況情報は当日分だけメモリ上に保存するが、実績スタック情報は過去の実績修正にも用いるので複数日分データを保存する。実績スタック情報書込み部の処理内容を図４１に示す。
（図４１の説明）
個人別稼働状況部に表示される情報は個人別稼働状況情報に保存されるデータと同じで、同じプロセスの作業単位の作業が繰り返し実行、中断されれば、同じプロセスキーを持ち、作業時間帯の異なるレコードが複数件作成される。これをこの段階でプロセスキーで集約せず、作業の繰り返しや停止の記録をそのまま残す。個人別稼働状況情報および実績スタック情報には作業開始、終了時間、稼働時間とともにシリアル番号と登録時間を持つ。実績スタック情報に修正をかける場合は同じシリアル番号を持つ新しい登録時間のレコードを追加で書き込み、稼動時間は差分にする。集約処理部ではこの差分値を使う。
【００９２】
２．４．（参考）その他の実績登録
（請求項対象外）
統合プロセス管理システムでは、ＰＤＣＡサイクルに係わるさまざまなＶＱＣＤ情報を取り込む。稼動実績以外は入力負荷が軽いので通常の入力画面からの登録でよいが、それでも他の業務システムと入力が重複しないように配慮する必要がある。そのための入力方法の工夫例を示す。
（１）ワークフロー連携による売上、諸経費情報等の収集
例えば図４３で示すように従来の基幹系業務システムのデータ登録ワークフローを経由して各種実績（売上、旅費等）を登録する。プロセス中に発生するデータは、ワークフローを使って幾つかの承認手続きを経て基幹系業務システムに登録されることが多いので、その仕組みを利用し、プロセスキーを付加したプロセス情報として統合プロセス管理システムに取り込む。プロセス情報の年月日別実績に取り込まれるが、この場合も実績スタック情報に一旦取り込み、差分集約する。
【００９３】
（２）品質実績収集（レビュー実績情報）の収集
（i）品質レビュー情報の収集
各作業単位の品質レビューの結果は、非定量データであることが多く例えば図４４のスプレッドシートのような形式で纏め、それを図１５に示すような共有サーバに保存する。そのスプレッドシート形式のデータから必要ならば品質指標データを加工して、共有または固有作業単位情報としてプロセス情報に登録する。スプレッドシート形式の情報は作業単位実績登録部の画面で非定量情報保有サーバのデレクトリパス名を指定し、プロセス情報の参照テーブル項目に書き込む。このデレクトリパスから保存したスプレッドシートを参照する方法は幾通りかある。
【００９４】
（ii）各種プロジェクト管理表の登録・・リスク評価登録収集
失敗プロジェクトはプロセスのチェック手順を踏んだかどうかというような手続き的なことよりも、顧客ユーザ側と開発側の目標品質のギャップがあるにも係わらず、それをリスクと認識できないところに生まれ易い。普通は対象システムに関する知識や技術が十分でないために、その潜在リスクを直覚することができない。最初から分かるリスクならば当事者で意識的に管理できないこともない。また業務であれ、システムであれ、技術であれ、ともかく未知な領域には未知のリスクが潜む可能性が高く、その未知なリスクに早めに気づくように、当事者以外の者からも、ユーザからも、問題のとらえ方や理解の状況が事実として見える方が良い。そのためには主要管理ポイントでのプロジェクト管理表やリスク評価結果や議事録や覚書きを非定量情報として作成し見える化する。これらもまた品質レビュー情報のひとつであり、扱い方は（i）の品質レビュー情報収集の場合と全く同じである。
【００９５】
３．課題３．「実績集約部の構成：差分情報を使った集約処理の高速化、単純化および中間スタック情報を使ったリアルタイム集約処理の実現」の解決手段
（請求項３に対応）
実績集約部の機能構成は図３５に示すように集約処理部とスタック処理部を持つ。実績集約部の機能を説明するため、図４８で実績集計処理の回数を見てみよう。図４８の縦方向には階層関係情報で繋がれた４つの階層がある。それぞれの階層には年月日別実績として該当日、該当月、該当年の実績、および作業単位の実績情報がある。作業単位実績は作業単位が年跨りでない限り、該当年実績と同じ値になる。１件の実績データが発生するたびに、年月日別実績情報テーブルで、３×階層数の更新が発生し、作業単位実績情報テーブルで１×階層数の更新が発生する。特に問題なのは、上位層のアクセス頻度である。仮に企業全体を集約するひとつの最上位の作業単位がある場合、実績データが発生するたびにその作業単位にも更新が発生する。一般には上位階層ほど更新頻度が高くなる。このアクセスの集中を避けるために差分を利用した集約方法の効率化と、中間スタック情報を使った上位層のアクセス頻度の制御を併せて行えるようにする。
【００９６】
（注１４）プロセス情報は、時間軸の全ての階層で集約処理されるわけではない。その例を図５２、図５３に示す。図５２は共通情報であり、作業進捗はリアルタイムで必要であろうし、稼動時間は日別情報として必須であろうし、プロジェクト経費などは月別情報で十分かもしれない。日別情報が必須の場合と月別情報で十分な場合、また参照テーブルのように作業単位情報で良い場合もある。各ＶＱＣＤ情報の取り込み頻度を図５２、図５３のように予め整理しておき、図５１の集約処理フローの中に取り込むようにする。
【００９７】
３．１．直接集約処理と差分集約処理の比較
（１）差分を使わない直接集約処理
階層関係情報で繋がれた作業単位情報の集約の流れを図４５に示す。図中で実績スタック情報から一つの作業実績が差分で上がった場合、これに繋がる一連の上位の３階層の作業単位情報にも更新がかかるので、合計４つの階層の作業単位情報に１トランザクションの間排他制御がかかる。それぞれの階層の作業単位の集約演算にはそれと直接つながる直ぐ下位の作業単位の実績全てが参照されて集約される。その他の各階層でも同様の集約演算が起こる。もし階層数が深かったり、階層の分岐数が増えると、１回の集約時間が長くなり、当然１トランザクション当りのアクセス回数が増えるため全体の処理時間が長くなり、かつ排他待ちの可能性は高くなる。
従ってこの方法を使う集約処理では階層の深さなどの制限がかかり得る。一方この方法は、処理は面倒だが、毎回下位の情報を使って上位の情報が再計算されるメリットがある。
【００９８】
（２）差分集約処理
図４６は図４５と同じ集約計算を差分を使う場合で示している。合計４つの階層の作業単位情報に排他制御がかかる点は同じであるが、更新される作業単位以外は参照不要なので、処理はずっと単純で早くなる。既に集約したデータを訂正する場合も差分を用いるが、その場合には差分がマイナスになる更新もある。差分集約法ではずっと集約処理を単純化、効率化できる利点がある。
【００９９】
（３）直接集約法と差分集約法の適性
図４７にプロセス情報の種類（計画情報か実績情報か）と二種類の集約方法（直接集約法と差分集約法）との適性関係を示す。プロセス情報を計画情報と実績情報に分けると、実績情報については極めてアクセス頻度が高く、情報の階層が深く、データ項目数も多く、また必ず最下位層から上位層へデータが集約されるのでデータの不整合が発生せず、この場合は差分集約処理に向いている。
一方計画情報は一般に上位層から下位層へと計画がブレークダウンされ、部分部分によって展開の深さが一様でなく、上位層に整合性のとれないデータが残るリスクがある。直接集約処理の場合は、全てのデータを使って再計算するので、この論理的不整合が除去できる。この場合差分集約法では論理的不整合がそのまま残ることがありうる。また計画情報はアクセス頻度が実績ほど高くはなく、階層が浅く、データ項目数が少ないので、このような場合は直接集約処理が向いている。勿論計画情報の集約でも差分集約法の利点を使うことはできるが、集約処理のタイミングを考慮するとか、集約領域を事前に意識的にクリアにするなどのデータの整合性が保障される状況にする必要がある。
【０１００】
３．２．差分集約法と中間スタック情報を併用した集約処理の流れ
３．２．１．差分集約部の機能詳細
（１）実績スタック情報による集約処理の頻度の制御
排他によるデッドロックを確実に回避するには、同時に複数の上位層実績集約処理が走らないようにすれば良い。具体的には、ひとつの差分集約法による処理が終わってから次の集約処理を流す方法がある。他にも差分集約処理を実行するインタバル時間を長くして、その間に書き込まれた実績スタック情報をプロセスキーで一旦集約して上位の集約処理を流せば、集約処理の頻度を制御することができる。ただしこの方法では、プロセス情報の集約処理を上位層も下位層も一様に遅れる問題がある。
【０１０１】
（３）差分集約法による実績集約処理フロー
図５０は実績スタック情報から差分情報を読み出してから、それを使ってプロセス実績情報を集約するための一連の処理のフローを示す。差分情報をひとつ取り込むごとに、階層関係情報を辿ってその上位のプロセス情報が次々読み出されて、「差分によるプロセス実績集約計算」が実行される。ひとつの差分情報を使った一連の集約処理が終了したら（トランザクション開始から終了まで完了したら）、実績スタック情報の処理済フラッグをセットし、実績スタック情報から次の未処理の差分情報を読み出し、同様の集約処理の流れを繰り返す。
【０１０２】
図５０の中の「差分によるプロセス実績集約計算」を、図５１で説明している。図５２、図５３に示すように集約対象となるデータ項目のタイプはいろいろあり、差分集約とはいっても単純な加減算ばかりではない。
【０１０３】
３．２．２．差分スタック処理部の機能詳細
中間スタック情報による集約処理の頻度の制御
実績スタック情報を使う場合は、下位層から上位層まで一様に一定時間の処理の遅れが起きてしまうことが避けられない。しかし現実には下位層だけはリアルタイムに情報が欲しいが、上位層は時間単位の集約で十分な場合がある。このような場合中間階層の適当な位置に差分情報を中間スタック情報に溜めこんで、一定時間間隔を置いてから集約処理を再開する方法がある。実績スタック情報も中間スタック情報も内容は同じである。再開後にスタックされたすべての差分情報をまず集約してから、上位階層の集約処理を流す。このようにすれば、中間スタック情報より下位の階層ではリアルタイムに集約処理が行われ、上位の階層では再起動するインタバル時間で調整される集約処理が行われる。
【０１０４】
４．課題４「計画作成部の構成：プロジェクト計画の自動作成」の解決手段
（請求項４、請求項５に対応）
計画作成部の機能構成を図３５で示す。計画編集画面と作業単位作成部、開発工数見積部、スケジューリング部を持つ。プロジェクト計画が上位層から下位層まで一気に展開されることは無くマスタ計画（タスク計画）どまりである。それも開発が進捗するにつれて１，２階層づつ段階的に展開されることもある。差立計画（チケット計画）もまたプロジェクトの進捗に応じて部分的に展開される。作成されたマスタ計画は差立計画に多少の遅れが出たとしても、計画と実績のギャップを見るため簡単には変えない。余りにも計画との差異が開き過ぎて計画管理の用をなさないような場合にマスタ計画を見直す。そのとき修正前の元のマスタ計画は基準マスタ計画として保存してから見直し更新する。
【０１０５】
チケット計画はタスク計画を元にして、日々の作業者単位の細かい作業にまで分割して差立てる。大規模システムの開発では多くのパートナー企業が開発に参加し、各パートナー企業はサブシステム以下の特定部分の開発を担う。そのとき上位の計画はシステム全体を受注するプライム企業が展開するが下位の計画はパートナー企業が個別に展開することが多い。プライム企業はマスタ計画のみを管理し、パートナー企業は下位のタスクとチケットを管理する。チケット計画はチケットが細かな作業単位なので資源割当機能だけでもスケジューリングできる。計画作成の観点からはタスク計画の方が作業単位のビリュームが大きくまた前後関係情報があり複雑である。そこでここではタスク計画の自動生成を中心に説明し、必要な都度チケット計画について補足する。
【０１０６】
４．１．プロジェクト計画自動生成の流れ
プロジェクト計画自動作成のフローは図５４に示すように次の３ステップで構成される。
（１）作業単位生成部による作業単位の生成
プロジェクト計画では多数の作業単位を生成することになるので、スケジューリングの前に作業単位そのものを作業スコープ定義（注１５）とシステム構造情報（注１６）を使って自動的に生成する。作業スコープ定義は開発標準に基づいた開発工程や工程内作業の定義であり、システム構造情報は、対象システムをシステム階層に分けたシステム括り単位で、開発単位、開発ロットともなる括りである。作業スコープ定義の作業単位と、システム構造情報で階層化されたシステム開発単位をクロスに対応づけ（図５５の作業スコープ定義の工程との対応づけ参照）、開発プロセス作業単位を自動的に生成することができる（詳細は４．２参照）。また作業スコープ定義内の工程や工程内作業で階層関係が存在する場合、または前後の順序付けがある場合は、この段階でそれぞれ階層関係情報と前後関係情報をも自動作成できる（詳細は４．３参照）。
【０１０７】
（注１５）作業スコープ定義は図５６に示すように、開発工程と工程内作業を定義したもので、この例の場合、新規開発、標準規模保守、小規模保守の３つの標準タイプの作業スコープ定義がある。新規開発と保守ではかなり作業内容が異なってくるからである。
【０１０８】
（注１６）システム構造情報は特願2013-148758「ソフトウエア開発方法」で提案されたシステム階層ごとに括られたシステム単位で上位層から下位層へシステム、サブシステム、ビジネスフロー、プログラム等のシステム括り単位の情報を持つ。システム開発の進行につれ上位層から下位層へと構造情報が詳細化され、この構造情報と部品情報からプログラムが自動生成される。本特許請求の中では、システム構造情報を開発工程ごとの開発ロット情報として、および工数見積りのための導出属性のソース情報として利用する。
【０１０９】
（２）開発工数見積り部による開発工数見積り
生成された全ての作業単位について開発工数を自動的に見積もる。開発工数を見積るにはシステムの開発規模の指標となる導出属性（注１７）が把握できていなければできないし、最低限そこまでシステム化分析が進んでいなければならない。この導出属性を用いて機能量を計算し、更に機能量に工数変換係数を乗じて見積り工数に換算する。ここまでの処理は工数見積システムで行う。（図５９参照）
（注１７）導出属性はデータファンクションとトランザクションファンクションの要素に分かれ、データファンクションにはファイルの種別、レコード数、データ項目数等が係わり、トランザクションファンクションにはトランザクション種類、ファイル数、データ項目数等が係わる。導出属性は分析が充分進んでいればシステム構造情報から抽出可能であるが、図５５に示すユースケース図から読み取って人が入力する形でも構わない。
【０１１０】
（３）スケジューリング部による作業単位のスケジュール生成
（１）（２）で作成した既に階層情報をもつ作業単位は図３４の基底ビュー画面から参照できる。スケジューリングは上位層から下位層へと段階的に行われる。先ず画面でスケジュールする対象階層を指定し標準開発期間‐開発工数対比表（注１８）などを使って面積イメージのタスク計画を自動生成する。この生成した計画は普通はタスクの最下層まで落とした段階で上位層へ反映させる。タスク計画レベルでは作業単位がまだ大きくこのスケジューリングが有効である。チケット計画では作業単位が小さいので資源割当機能でスケジューリングができ、また作業者が割り当てられるので、資源情報の個人の生産性パーフォーマンス情報を反映させて日別展開できる。
【０１１１】
（注１８）標準開発期間‐総開発工数対比表：総開発工数に対して開発期間が短か過ぎると、開発要員に必要なシステム知識や開発技術の取得が追い付かなかったりコミュニケーションが不十分になったりして失敗リスクが高くなる。逆に開発期間を長くし過ぎると失敗リスクは減るがビジネスチャンスを失うトレードオフの問題がある。そこには総開発工数に対して適正な開発期間とその許容範囲があるという経験則があると考えられ、それを経験的にグラフまたは表で表したものが標準開発期間‐総開発工数対比表(図６４)である。
これは企業のプロジェクトマネージメント能力を含めた総合開発力の指標を示すとも言える。また新技術を使う開発や業務ノウハウが不十分な場合はこの対比表は調整されるべきである。
【０１１２】
４．２．作業単位生成部の機能詳細：タスクやチケットの作業単位の生成方法
作業単位は二つの情報を組み合わせて作成される。ひとつは図５６の作業スコープ定義で開発標準に基づく開発工程や各工程内作業が定義されている。開発工程に工程順があるように工程内作業も前後の順番が決められる場合がある。いまひとつは図５５に示すシステム構造情報である。これは対象システムのシステム、サブシステム、ビジネスフロー、プログラム等のシステム括り単位の構造情報を持ち、開発の進捗とともに下位層が詳細化され、また工数を見積もるための導出属性の精度も上がる。システム構造情報の例としては、特願2013-148758ソフトウエア開発方法を参照願いたい。
【０１１３】
システム構造情報の階層をなすシステム、サブシステム等のシステム括り単位（開発ロット単位でもある）と、作業スコープ定義の工程および工程内作業とは図５５の作業スコープ定義の工程との対応づけで示される。その対応関係を使って図５７に示すような作業単位を生成する。その生成方法について次に示す。
（図５７の説明）
システム構造情報の中の各階層のシステム括り単位がそれぞれ集約作業単位として生成され、その集約作業単位と並んで作業スコープ定義の対応する開発工程の作業単位が生成される。一般的には作業スコープ定義の開発工程の括りからタスクを展開し、工程内作業の括りからチケットを展開することが多い。
図５７の図中にあるサブシステム階層の例で作業単位の作り方を具体的に説明する。サブシステム１に３つのビジネスフローがあれば、上位のサブシステム１集約単位の下に、３つのビジネスフローの集約単位が作られる。その各集約単位はビジネスフロー以下の開発工程の全プロセス情報の集約単位である。一方サブシステム１自体の概要設計とシステムテストで生成するプロセス情報については、もしその下に更に工程内作業をチケットで分割する場合は、概要設計の集約単位とシステムテストの集約単位が作られたうえで、それぞれの下に工程内作業のチケットが作成される。工程内作業のチケットに分割しない場合は、サブシステム１の概要設計とシステムテストが集約単位とならず直接の作業単位として作成される。サブシステム階層以外の階層も考え方は同じである。
詳細設計やプログラム開発工程のタスクかチケットの作業単位を括りだす場合は、システム構造情報のプログラムを開発ロットとして何本で括り出すのかこれも予めルールを決めておく必要がある。開発ロットは作業者にデスパッチする仕事の単位になるが、それをビジネスフロー単位にするか、プログラム単体か、あるいは一定数のプログラム数単位にするかルールを決めておき自動的に処理する。
【０１１４】
４．３．階層関係情報、前後関係情報の生成
階層関係情報、前後関係情報もシステム構造情報と作業スコープ定義で決まる範囲内で作成する。階層関係情報は図５７で示す上位層と下位層を繋ぐ全ての線分に該当し、システム構造情報と作業スコープ定義から作業単位を生成するのと同時に自動作成される。タスクの前後関係情報はシステム構造情報と作業スコープ定義からは決まらないものも多い。前後関係情報は工程作業の順序から生成され、図５７下図の上流工程〜下流工程までの（１）〜（８）に示すタスクの順番で前後関係情報が作られる。工程作業の下にも工程内作業の順序はあるが、チケットでは前後関係情報は持たないので不要である。この段階で自動的に関係情報をつけられるのはこれくらいである。これ以外の理由で後から付加される前後関係情報はスケジュール作成上重要である（図６２参照）。
【０１１５】
４．４．開発工数見積り部の機能詳細
生成された全ての作業単位の開発工数を図５８に示すフローで見積もる。このフローでは図５９に示す特開2013- 178618ソフトウエア開発工数見積り方法を応用している。その見積り方法では拡大FP法（注１９）を使い、プログラムのような小さな単位でも新規開発や保守の開発工数の見積りができるように工夫されている。システム構造情報の各階層のシステム括り単位ごとにまず導出属性が求められ、更にそれが小処理単位機能量に変換され、さらに工数変換係数を使って見積り工数が計算される。統合プロセス管理システムでは図５８に示すように、この変換された小処理単位の工数を取り込むだけである。
（注１９）従来のＦＰ法は導出属性から機能量（ＦＰ）へ変換し、固定的に一定の経験的な重みづけ係数を乗じて唯一の代表ＦＰを算出する方法であるが、導出属性から機能量への変換方法が粗くてプログラム単位のようなきめ細かな見積りが困難なこと、作業の構成の配分の違いによる見積り工数の違いを考慮できないなどの問題があった。拡大ＦＰ法はこれに改良を加え機能拡大した見積り方法。
【０１１６】
４．５．スケジューリング部の機能詳細：開発計画作成
スケジューリングは一般にはシステム構造情報の階層に従って、上位から下位に段階的に展開されてゆく。各階層では、作業単位計画が作成され、タスクの最下層で年月日別計画まで展開され、作成された年月日別計画は再び下位層から上位層へ集約される。そのフローを図６０に示す。スケジュールの展開方法は（i）全体の標準開発期間を優先する方法、（ii）前後関係情報を優先させる方法、あるいは（iii）人的資源にタスクやチケットを当て嵌める方法など場合に応じていろいろある。
【０１１７】
（i）は全体計画の開発量と開発期間のバランスを考慮してサブシステムやビジネスフローを面積イメージでタイムスパンの中に位置づけてゆく方法であり、階層関係情報を辿って同一階層ごとに段階的に展開する。これに対し（ii）は（i）のように全体バランスを考慮する機能がない。既に前後関係情報でタスクの位置関係が決められた条件で、日別展開に落とし込む。実用的には両方の長所を組み合わせた図６２に示すようなやり方がある。先ずは上位階層のタスクを（i）の方法を適用し全体バランスを考慮したタスクの位置関係を決め、そこで決まる位置関係から前後関係情報を付加する。ここまでは日別展開する必要はなくタスクの順序関係だけ決まればよい。それをタスク階層全てにやった上で、最下位層のタスクについて（ii）の方法を適用して日別に展開する。最下位タスクの展開した結果のみを上位層の集約に展開する。この場合は差分集約を適用できる。
ここでは（i）（ii）の二つの方法の自動化について説明する。
【０１１８】
４．５．１．標準開発期間を優先してスケジューリングする方法
（請求項４に対応）
タスク配置の自由度がある場合、計画の全体バランスを重視してスケジューリングする方法である。
・  作業単位のスケジュールの作成
（作業単位のタスク配置パターン）
作業単位のタスク配置パターンには図６４に示すように、直列型、並列型、複合型の３つが考えられる。（複合型は並列型のひとつともみなしうる。）総開発工数は日単位数×稼働日数（時間）の面積（注２０）なので、投下人員枠や開発効率を無視すれば面積の形は如何様にも変形でき、全てを直列型、または並列型で構成することも論理的には可能である。しかし（注１８）で述べたように総開発工数に対する適正な開発期間の経験則があるとみなすので、なるべく全体開発ボリュームと個々の開発ボリュームがこの経験則から逸脱しないように（注２１）、かつ負荷の変動幅を抑えるように、計画展開パターンを決める。
（注２０）日単位数：１日当たりの作業単位の総稼働時間で、一人当り日別稼働時間×日別投下人員に等しい。一人当り日別稼働時間は操業暦の標準的な稼働時間から取り込むが、年月日別情報で時間外の調整をすることができる。日別投下人員は、日当りの実人員数である。
（注２１）標準開発期間−総開発工数対比表が適用できるのは、投下人員数が自由である場合であり、投下人員枠が最初から固定される場合は使う意味がない。
【０１１９】
（タスク配置パターンの決定）
前後に繋がる一連の作業単位をひとつの直列な流れと定義すれば、全体を何本の直列な流れで構成するのかを決める。全体の総開発工数から標準開発期間‐総開発工数対比表を使って求めた標準開発期間をａ，個別の作業単位の開発工数から求めた標準開発期間の和をｂとする。ｂ／（ａ＋α）の切上げ値ｎを仮の直列な流れの本数とする（αは調整値：０＝＜α＜１、図６４参照）。各流れに作業単位を割り当てるには、図６５左図に示すように個別の作業単位の開発工数の大きい順に縦方向に作業単位を並べておき、但し既に前後関係で繋がる作業単位はそれらの標準開発期間の和を持つあたかもひとつの仮想の作業単位を考えて並べておき、このテーブルから順番に標準開発期間の和がａ＋αを超えないように順に取り出し、直列の流れの作業単位を割り当ててゆく。
【０１２０】
この処理の流れを図６５、図６６に示す。図６５の中の幾つかの処理について補足する。
（投下人員枠を与える作業単位の扱い方）
標準開発期間‐総開発工数対比表を適用できない投下人員枠があるタスクが混じる場合は、投入人員枠で定まる開発期間を標準開発期間とする作業単位とみなして並べておき、このテーブルから順番に標準開発期間の和がａ＋αを超えないように順に取り出し、直列の流れの作業単位を割り当ててゆく。
【０１２１】
（作業単位に納期がある場合の調整）
図６５で作業単位に納期がある場合は図６５右図のように並べる順番を調整する。最初は標準開発期間の大きい順に並べるが、納期があるタスクは納期を優先させて配置する。流れに作業単位を割り当てる時に、概算の終了日で納期チェックを行い、納期が間に合わない場合は次の流れへと廻される（次の流れを作るときに取り込む）。納期が原因でｎ本の流れに収まらない場合も出てくる。
【０１２２】
（直列な流れの負荷の平準化）
もし、直列な流れの負荷を平準化したい場合は、既にひとつの直列な流れとして割り当てた一連の作業単位について、総開発工数を計算し、総開発工数／標準開発期間ａを平均日別投下人員とする。その平均日別投下人員を各作業単位で共通にして、各作業単位の開始日、終了日、開発期間を確定する。（ただし、投下人員枠がある場合は、投下人員枠をそのタスクの上限として決める。）ただし無理な平準化になる場合もあるので、元の標準開発期間をそのまま残して、対話修正で調整したほうが無難な場合もある。
【０１２３】
（日別展開処理／作業単位展開処理）
二つの自動スケジューリング処理で共通であり、４．５．２（２）を参照。
【０１２４】
（２）タスク計画とチケット計画の連動
チケット計画は資源割当て機能を使って割当てが可能であるが、タスクと同じ自動割り付けの手法を用いて自動展開することも可能である。
ところでもし計画が実績と同じように、下位チケットから上位タスクまで連動してしまったらどうなるか。上位層の作業単位の計画はその下位層の作業単位の計画が集約されたものであり、ある下位層の作業単位の計画は更にその下位層の作業単位の計画が集約されたものである。つまり下位層が決まらないうちは最終的に上位層も決まらない。また日々チケット計画が修正されると、それがいちいち上位層の計画として反映される。しかしこれではマスタ計画の機能が不全に陥ってしまうだろう。タスク計画に基づいてチケット計画が展開されるのは当然だが、チケット計画はタスク計画には直接連動させない方が妥当であろう。
【０１２５】
４．５．２．前後関係情報を優先してスケジューリングする方法
（請求項５に対応）
標準開発期間を優先するスケジューリング方法である。４．５．１の方法で上位層を展開した後の最下層のタスクのスケジューリングに良く適合する方法である。前後関係情報で繋がる複雑なクリテカルパスの流れをその複雑な形のまま整列してスケジューリングする。その他の個別タスクのスケジューリングは対話で配置し日別展開すればよい。
【０１２６】
（１）前後関係情報を辿り一括でタスク展開する処理方法
直列なタスクの流れでは前後関係情報があっても単純な構成であるが、タスクの下位層の展開の場合では複雑な前後関係情報で繋がる場合も考えられる。この場合は各作業単位の作業開始日と作業終了日は複数の流れの前後関係情報を辿って順次決める必要がある。
このとき前後関係情報の辿り方に二通りの方法がある。ひとつは図６８左で示す並列優先の辿り方、もうひとつは図６８右で示す直列優先の辿り方である。並列優先か直列優先かのどちらを採るかは選択できるが、先行タスクの処理待ちを抑えるには並列優先の方が有利である。どちらも前後関係情報が複数に分岐する場合、分岐点にまで戻って別な選択肢を再計算する。その複雑な分岐情報を誤らずに処理するために分岐点まで来たらその選択肢を保存領域に一旦保存し、ひとつの選択肢の処理が終了したら保存領域から情報を取り出し、別な選択肢の処理を始める。
【０１２７】
並列優先と直列優先では基本の考え方は同じだが、少し手法が違う。並列関係情報では先入、先出の保存領域（並列関係情報）にエンキューし、ひとつの選択肢の計算が終了したら、並列関係情報からデキューして未終了の選択肢を取り出し、処理を続ける。こうして並列関係情報が空になるまで繰り返す。この処理フローを図６９に示す。並列関係情報から前後関係情報を取り出し、先行タスクの終了日と前後関係情報の依存関係情報から後続タスクの開始日を決め、更に日別展開処理（図７０参照）を実行し、後続タスクの年月日別計画が作成される。一方複数の先行タスクがある場合は、複数の先行タスクの日別展開が終了し終了日が全て揃っているかどうかを確認するために、複数先行タスク情報を先に用意する。その中に自タスク名と先行タスク数と先行タスク名とそれぞれの先行タスクの終了日を保存し、既に先行タスクの日別展開が終了済であるかチェックする。この複数先行タスク情報を参照してまだ未決の終了日が残っていたら、もう一度この前後関係情報を並列関係情報にエンキューする。
【０１２８】
（２）日別展開処理／作業単位展開処理
処理の流れを図７０に示す。タスクの日別展開の場合であり、タスクは複数のメンバに割当てられるので、資源情報の生産性ｐｆは使う必要がない。しかしチケットレベルの日別展開ではそれを利用して、標準開発工数を作業者別に調整できる。
作業単位の展開処理に止める場合、次のやり方がある。ひとつは月平均の日別稼働時間を使って（休日も月平均の日別稼働時間で動くと仮定して）開始日、開発期間、終了日を決め、開発計画を作る方法である。いまひとつは、日別展開まではやらないが、日々の稼働時間を使って（きちんと休日も考慮して）開発計画を作る方法である。図７０のフローでは左分岐の流れが日別展開処理であり、右分岐の流れが日々の稼働時間を使った作業単位展開処理である。図７０の処理フローの中で、各作業単位の開始日、投下人員、終了日の算出方法を次に示す。
【０１２９】
（i）前後関係情報中の依存関係情報によるが、一般的には後続タスクの開始日は並列関係情報の関係性情報の先行タスクの終了日、あるいは複数ある場合は複数先行タスク情報の最も遅い終了日である。
（ii）各タスクの開発期間を決めるのはやはり標準開発期間‐総開発工数対比表である。
それから平均の日当り投下人員を計算する。
（iii）操業暦のデフォルトパターンまたは指定パターンを読んで日々の稼働時間を取り込む。
（iv）チケットの場合、作業者が指定され、資源情報がある場合は、生産性ｐｆで開発工数を調整
（v）日単位数を計算、累積日単位数を計算
（vi）累積日単位数＞＝開発工数となるまで日時をインクリメントし終了日を決定
（vii）終了日を並列関係情報の関係性情報の後続タスクの終了日に設定し更新
【発明の効果】
【０１３０】
統合プロセス管理システムおよびプロジェクト管理システムとしての効果。
１．請求項１：統合プロセス管理システムによる期待効果
（定量効果）
（１）管理負荷の軽減。管理コストの削減。
（２）失敗コストの劇的な削減
（定性効果）
（計測データに基づくＰＤＣＡサイクル管理の徹底）
（３）問題分析や計測に基づく見える化の深化
（４）リアルタイムな実績把握と課題へのスピーデイな対応
（計画遅れ、標準外・規格外、異常対応、問題対応）
（５）ＰＤＣＡ、ＨＤＣＡサイクルの徹底
（６）派遣者にも適用できる見える化
（人材育成）
（７）自己責任意識を持たせるための個人ベース情報の見える化（生産性、品質など）
（８）人の訓練と育成
（情報のオープン化・事実の見える化）
（９）事実の見える化、事実に基づく経営
（１０）組織・プロジェクトの情報の壁を取り除く、オープン化
（標準化・単純化）
（１１）プロジェクト管理の単純化・標準化
（１２）システムの単純化
【０１３１】
２．請求項２：作業単位計画を利用した実績収集方法による期待効果
（定量効果）
（１１）稼働管理実績の重複入力排除、稼働実績収集の簡単化・効率化
（定性効果）
（１２）社外派遣者にも適用できる見える化
３．請求項３：差分集約方法および中間スタック情報を利用したデータ集約方法による期待効果
（定量効果）
（１３）管理工数・コストの削減（運営会議、見える化資料作成負荷軽減）
（１４）リアルタイムな実績集約方法の実現
【０１３２】
４．請求項４、請求項５：作業単位計画自動作成方法による期待効果
（定量効果）
（１５）計画作成の単純化・効率化
【図面の簡単な説明】
【０１３３】
【図１】統合プロセス管理システム機能構成図
【図２】マスタ計画管理・作業管理システム機能構成図
【図３】プロジェクト管理の基底ビュー画面例
【図４】プロジェクト管理・タスクとチケットの役割
【図５】作業管理・チケットのデータ項目例
【図６】タスクとチケットの計画と資源割当機能の違い
【図７】統合プロセス管理のコンセプト
【図８】縦割り情報収集型からプロセス中心型のシステムへ
【図９】システム開発プロセス例
【図１０】人材育成プロセス例
【図１１】企業のＰＤＣＡ／ＨＤＣＡサイクルの複層的な連鎖
【図１２】全階層の作業単位のＰＤＣＡサイクルを同一形式で表現
【図１３】プロセス情報階層軸の構成例
【図１４】事実の見える化１：定量情報の見える化
【図１５】事実の見える化２：プロセス内で生産される非定量情報の見える化
【図１６】事実の見える化３：プロセスの流れに沿って主要情報がトレースできる
【図１７】事実の見える化４：異質なプロセス情報が横通しで繋がって見える
【図１８】事実の見える化５：プロジェクト情報として採算がリアルタイムで見える
【図１９】統合プロセス管理のコンセプトと４つの技術技術
【図２０】統合プロセス管理システムハードウエア構成図（集中処理型）
【図２１】統合プロセス管理システムハードウエア構成図（分散処理型）
【図２２】データ階層構造を利用した情報セキュリテイ管理
【図２３】関係情報を外付けで共有するデータベース部の構造
【図２４】作業単位情報と年月日別情報との関係
【図２５】資源（作業者）を中心にした割当方法
【図２６】統合プロセス管理の計画作成と資源割当機能
【図２７】論理テーブルとアクセス処理のマトリックス
【図２８】データベースの論理テーブルの構成
【図２９】データベースの論位テーブルの構成（２）
【図３０】プロセス情報の分類例
【図３１】システム開発プロセスのＶＱＣＤデータ例
【図３２】人材育成プロセスのＶＱＣＤデータ例
【図３３】チケットデータ項目例（開発プロセス）
【図３４】統合プロセス管理システムの基底ビュー画面構成
【図３５】計画作成部・実績登録部・実績集約部の機能構成
【図３６】実績登録部の処理フロー
【図３７】実績登録部の機能構成
【図３８】作業同期、作業非同期の実績収集方法の比較
【図３９】プロセス管理タスク画面
【図４０】個人別稼働状況処理部の作業状況ステータスの操作
【図４１】実績スタック情報書込部の処理
【図４２】登録済み実績の修正方法
【図４３】年月日別予実情報の取り込み
【図４４】非定量化情報の取り込み
【図４５】差分を使わない直接集約処理
【図４６】差分集約＋スタック方式を使う集約処理
【図４７】プロセス情報の種類と集約処理方法の適性
【図４８】実績スタック情報による２軸集計機能の違い
【図４９】スタック処理の機能比較
【図５０】差分集約部の実績集約の処理フロー
【図５１】差分による実績集約演算の種類例
【図５２】２軸方向の実績データの集約レベル例（１）
【図５３】２軸方向の実績データの集約レベル例（２）
【図５４】計画作成部の機能構成
【図５５】作業単位生成部の処理
【図５６】作業スコープの定義の例
【図５７】タスク・チケット作業単位作成方法
【図５８】開発工数見積り部の処理
【図５９】統合プロセス管理システム、開発支援システム、見積りシステムの関係
【図６０】タスクスケジューリング部の処理
【図６１】二種類のスケジューリング方法の比較
【図６２】タスク展開と前後関係情報の作り方
【図６３】作業単位計画から年月日別計画への展開
【図６４】標準開発期間優先のスケジューリング方法
【図６５】タスク配置パターンへの作業単位割当て
【図６６】標準開発期間優先のスケジューリング処理フロー（１）
【図６７】標準開発期間優先のスケジューリング処理フロー（２）
【図６８】前後関係情報優先のスケジューリング方法
【図６９】前後関係情報優先のスケジューリング処理フロー
【図７０】日別展開部の処理フロー
【実施例】
【０１３４】
統合プロセス管理システムを使って、計画を作成し実績を収集するまでのシステムの操作とそれに伴う処理の流れを示す。
（１）中期計画、年次計画の作成（タスク計画）
統合プロセス管理システムでは中期計画、年次計画という通常の計画とは異なる特別な計画があるわけではなく、年月日別情報に対して見るタイムスパンが違うだけである。通常は最上位に組織レベル（全社、部門、グループ）の集約作業単位が作られ、中期計画、年次計画はプロジェクトレベル程度の階層まで展開される。中期計画は毎年ローリングされるので自動展開する余地が殆どない。年次計画も中期計画の初年度を詳細化するだけなので自動展開をする意味がない。中期、年次レベルでは作業単位の計画を計画編集部の画面で編集し月単位の年月日別計画までブレークダウンすることが多い。（特許請求項の対象外ではあるが、中期計画と年次計画のオリジナルは基準マスタ計画として保存し、期計画の運用は年次計画をそのまま更新して使う。保存した基準マスタ計画は基底レビュー画面で呼出して実績との対比で使うことができる。）
【０１３５】
（２）計画の運用管理（タスク計画）
プロジェクトレベル以下の展開では通常システム開発などの業務の進行に従って行う。システム構造情報の階層に従って上位から下位へとタスク層までを展開する。タスク計画では、作業スコープ定義の工程作業程度まで詳細化される。ここでは計画の自動展開を適用でき、自動展開の方法にはそれぞれの階層に適した標準開発期間を優先させる方法、前後関係情報を優先させる方法がある。自動化生成時には対象階層を計画編集部のビュー画面で指定（例えばある作業単位を指定するとそれに繋がる１階層下の作業単位を展開するとか決める）して自動展開、その結果を編集画面に表示する。自動生成後は必要ならそこで計画を対話修正する。タスク下位層の計画を上位層へ反映させるタイミングはタスクの最下位層の展開が終了した時点で、この場合は直接集約法でなく差分集約法を使える。
【０１３６】
（３）チケット計画の展開
チケット計画ではタスクの開発工程を更に小さな作業工程まで細分化し最下層の作業単位には作業者を指定する。チケット計画でもタスク計画の場合と同様に自動展開できるが、対話画面から資源枠に当て嵌める方法がある。チケット計画には作業者が指定されるので、もし必要性があれば個人別の資源情報（生産性ｐｆ情報）を使って標準工数を調整したり、年月日別計画で日別の稼働時間を調整することもできる。チケット計画の場合は前後関係情報を使わないため、実績の計画遅れによって上位のチケット計画が自動的に修正されることもない。
【０１３７】
（４）実績収集
ＶＱＣＤに関わる実績情報はプロセスの違いによって異なるが、代表的な実績例を４つ取り上げる。このうち特許請求項に係わるのは（i）のみである。
（i）作業稼働実績収集
作業実績登録部のプロセス管理モニタ画面に個人別の当日の差立情報を表示しながら、作業と平行しリアルタイムに当日分個人別稼動情報を収集する。作業状況ステータスが変わった時点で時点経過実績として取り込み個人別稼働状況情報に保存される。個人別稼働状況情報はさらに実績スタック情報に変換され、それは差分情報に変換されて上位階層の作業単位実績情報が集約される（差分集約法）。このとき中間スタック情報を使って上位階層のアクセスの集中を緩和する場合もある。一方個人別稼働状況情報は稼働管理情報として転用し、そのための重複入力を回避する。
（ii）品質実績収集（レビュー実績情報）
各作業単位の品質レビュー結果は、非定量データであることが多く図４４のスプレッドシートのような形式で纏め共有の非定量情報保有サーバに保存する。そのとき作業単位実績登録部のサブ画面から、非定量情報のデレクトリパス名をプロセス情報の参照テーブル項目に書き込み、プロセス情報から参照できるようにする。また必要ならば共有データまたは固有データとして管理すべき項目をスプレッドシートなどから抽出・加工し、レビュー情報として作業単位情報に自動的に登録する。それによってレビュー時間比率や不具合指摘件数比率などの品質管理指標を、普通のＱＶＣＤ管理項目として扱える。
【０１３８】
（iii）各種プロジェクト管理表登録、リスク評価表登録
各開発工程の主要管理ポイントでプロジェクト管理表を作成したり、その一部としてリスク評価結果を(ii)の場合と同様に作成することは頻繁にある。これもレビュー実績のひとつであり、扱い方は（ii）の品質実績収集の場合と同じにできる。
（iv）ワークフロー経由各種実績収集
図４３で示すようにワークフロー経由で各種実績（売上、旅費等）を登録する。従来の基幹系のシステムは幾つかの承認手続きを経てワークフローで登録されることが多いので、重複入力の手間を省いてその仕組みを利用してプロセス情報に取り込む。
【０１３９】
（５）プロセス情報参照
（特許請求項対象外）収集したあらゆるプロセス情報を全て同じように見ることができる。基底ビュー画面で図１３のように全体情報体系を表示しておき、そこから（階層範囲軸、時間軸、データ項目軸）を指定して図１４のように任意のグラフを表示する。または図１５のようにテーマ別のＰＤＣＡサイクル情報を加工して提供する。図１７のような関連する異質なプロセス情報を繋げて見たり、図１８のように予決算情報を見ることも可能である。
【産業上の利用可能性】
【０１４０】
ＰＤＣＡサイクルで作業を管理するあらゆる法人や官公庁、特に情報システム部門、ソフトウエア開発産業で幅広く利用可能。
【符号の説明】
【０１４１】
１    計画作成部                                          図１
２    計画編集部                                          図１
３    実績登録部                                          図１
４    実績集約部                                          図１
５    実績編集部                                          図１
６    資源割当部                                          図１
７    プロセス情報参照部                                  図１
８    データベース部                                      図１、図２
９    タスク計画登録編集部                                図２
１０  タスク実績登録編集部                                図２
１１  タスク資源割当部                                    図２
１２  チケット計画登録編集部                              図２
１３  チケット実績登録編集部                              図２
１４  基底ビュー画面                                      図３
１５  ガントチャート                                      図３
１６  ビューバー                                          図３
１７  基準マスタ計画                                      図４
１８  ＷＢＳチケット                                      図５
１９  課題チケット                                        図５、図９
２０  障害チケット                                        図５、図９
２１  資源割当                                            図６
２２  縦割り情報収集型                                    図７
２３  プロセス中心型                                      図７
２４  プロジェクト管理                                    図８
２５  マスタ計画管理                                      図８
２６  作業管理                                            図８
２７  稼動管理                                            図８
２８  品質管理                                            図８
２９  予実管理                                            図８
３０  人事業績考課                                        図８
３１  プロセス                                            図９
３２  システム開発プロセス                                図９
３３  人材育成プロセス                                    図１０
３４  ＰＤＣＡサイクル                                    図１１
３５  ＨＤＣＡサイクル                                    図１１
３６  計画情報                                            図１２
３７  実績情報                                            図１２
３８  レビュー情報                                        図１２
３９  ＶＱＣＤ                                            図１２
４０  課題対応アクション                                  図１２
４１  組織集約単位                                        図１３
４２  プロジェクト集約単位                                図１３
４３  作業単位情報                                        図１４
４４  年月日別情報                                        図１４
４５  生データ                                            図１４
４６  集約データ                                          図１４
４７  非定量データ                                        図１５
４８  プロセス関連図                                      図１５
４９  リスク検討記録                                      図１５
５０  レビュー詳細記録                                    図１５
５１  テスト詳細記録                                      図１５
５２  階層集約型データベース構造                          図１９
５３  前後関係情報                                        図２０
５４  階層関係情報                                        図２０
５５  操業暦                                              図２０
５６  プロセス管理モニタ                                  図２０
５７  集中処理型                                          図２０
５８  分散処理型                                          図２１
５９  分散処理型                                          図２１
６０  情報セキュリテイ管理                                図２２
６１  資源情報                                            図２５
６２  操業暦パターン                                      図２５
６３  標準稼働時間                                        図２５
６４  投下人員                                            図２５
６５  日単位数                                            図２５
６６  資源割当機能                                        図２６
６７  処理のマトリクス                                    図２７
６８  作業単位計画                                        図２８
６９  年月日別計画                                        図２８
７０  作業単位実績                                        図２８
７１  年月日別実績                                        図２８
７２  年月日別プロセス固有情報                            図２８
７３  依存関係情報                                        図２８
７４  前後関係種別情報                                    図２８
７５  作業単位キー                                        図３３
７６  個人別稼働状況情報                                  図３７
７７  実績スタック情報                                    図３７
７８  作業同期収集                                        図３８
７９  作業非同期収集                                      図３８
８０  作業状況ステータス                                  図４０
８１  ワークフロー                                        図４３
８２  参照テーブル                                        図４４、図１５
８３  直接集約                                            図４５
８４  差分集約                                            図４６
８５  中間スタック情報                                    図４７
８６  作業スコープ定義                                    図５４、図５７
８７  システム構造情報                                    図５４、図５７
８８  ビジネスフロー                                      図５５
８９  ＦＰ計算                                            図５８
９０  工数計算                                            図５８
９１  小処理単位工数情報                                  図５８、図５９
９２  工数変換係数履歴情報                                図５８、図５９
９３  開発支援システム                                    図５９
９４  見積りシステム                                      図５９
９５  抽出単位導出属性情報                                図５９
９６  面積イメージの計画                                  図６０
９７  標準開発期間−総開発工数対比表                      図６４
９８  並列型                                              図６４
９９  直列型                                              図６４
１００  複合型                                            図６４
１０１  タスク配置パターン                                図６５
１０２  タスクの流れ本数                                  図６５
１０３  整列ワークテーブル                                図６６、図６７
１０４  並列優先                                          図６８
１０２  直列優先                                          図６８
１０５  並列関係情報                                      図６９
１０６  日別展開処理                                      図６７、図６９
１０７  先入先出キュー領域                                図６９
１０８  累積日単位数                                      図７０
【図１】
2016062342.tif 000003
【図２】
2016062342.tif 000004
【図３】
2016062342.tif 000005
【図４】
2016062342.tif 000006
【図５】
2016062342.tif 000007
【図６】
2016062342.tif 000008
【図７】
2016062342.tif 000009
【図８】
2016062342.tif 000010
【図９】
2016062342.tif 000011
【図１０】
2016062342.tif 000012
【図１１】
2016062342.tif 000013
【図１２】
2016062342.tif 000014
【図１３】
2016062342.tif 000015
【図１４】
2016062342.tif 000016
【図１５】
2016062342.tif 000017
【図１６】
2016062342.tif 000018
【図１７】
2016062342.tif 000019
【図１８】
2016062342.tif 000020
【図１９】
2016062342.tif 000021
【図２０】
2016062342.tif 000022
【図２１】
2016062342.tif 000023
【図２２】
2016062342.tif 000024
【図２３】
2016062342.tif 000025
【図２４】
2016062342.tif 000026
【図２５】
2016062342.tif 000027
【図２６】
2016062342.tif 000028
【図２７】
2016062342.tif 000029
【図２８】
2016062342.tif 000030
【図２９】
2016062342.tif 000031
【図３０】
2016062342.tif 000032
【図３１】
2016062342.tif 000033
【図３２】
2016062342.tif 000034
【図３３】
2016062342.tif 000035
【図３４】
2016062342.tif 000036
【図３５】
2016062342.tif 000037
【図３６】
2016062342.tif 000038
【図３７】
2016062342.tif 000039
【図３８】
2016062342.tif 000040
【図３９】
2016062342.tif 000041
【図４０】
2016062342.tif 000042
【図４１】
2016062342.tif 000043
【図４２】
2016062342.tif 000044
【図４３】
2016062342.tif 000045
【図４４】
2016062342.tif 000046
【図４５】
2016062342.tif 000047
【図４６】
2016062342.tif 000048
【図４７】
2016062342.tif 000049
【図４８】
2016062342.tif 000050
【図４９】
2016062342.tif 000051
【図５０】
2016062342.tif 000052
【図５１】
2016062342.tif 000053
【図５２】
2016062342.tif 000054
【図５３】
2016062342.tif 000055
【図５４】
2016062342.tif 000056
【図５５】
2016062342.tif 000057
【図５６】
2016062342.tif 000058
【図５７】
2016062342.tif 000059
【図５８】
2016062342.tif 000060
【図５９】
2016062342.tif 000061
【図６０】
2016062342.tif 000062
【図６１】
2016062342.tif 000063
【図６２】
2016062342.tif 000064
【図６３】
2016062342.tif 000065
【図６４】
2016062342.tif 000066
【図６５】
2016062342.tif 000067
【図６６】
2016062342.tif 000068
【図６７】
2016062342.tif 000069
【図６８】
2016062342.tif 000070
【図６９】
2016062342.tif 000071
【図７０】
2016062342.tif 000072