JP2010244103A - 設計工程管理装置 - Google Patents

Abstract

【課題】複数の設計工程を有する開発プロジェクトにおいて、すでに終了した作業工程をも含めて、実際に行われた作業に無駄や問題がなかったかを把握するのに有用な各種の情報を、できるだけ見易い形で提供する。
【解決手段】
各設計工程において作成すべき仕様書の作成計画が登録される工程管理データベースと、作成された仕様書に一意の図番が付されてその更新履歴とともに登録される図面管理データベースとを備え、クライアント端末からの要求にしたがって、工程管理データベース及び図面管理データベースを検索して、各仕様書の作成及び更新実績を、一方の軸を時間、もう一方の軸を設計工程とする座標平面上に、前記各仕様書の作成開始時刻を始点としてダイヤグラム表示させるようにした。
【選択図】図１０

Description

本発明は、複数の設計工程を有する開発プロジェクトを対象とする設計工程管理装置に関する。

近年、システムや製品の大規模複雑化が進むに連れて、プロジェクト管理の重要性が増してきている。従来より、ウォーターフォール型、スパイラル型（反復型）、並列型などの開発モデルに有用ないくつかのプロジェクト管理の技術が開示されている。

例えば、特許文献１には、ガントチャートを拡張した生産プロセスマネジメントチャートを利用して生産管理を行う技術が開示されている。また、特許文献２には、スパイラル型の開発モデルに適したプロジェクト管理や作業管理の技術が、特許文献３には、並列型の開発モデルにおける作業の手戻りを最小限にするための技術が開示されている。

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

しかしながら、これら従来のプロジェクト管理技術はいずれもプロジェクトの進捗状況をリアルタイムで把握することに主眼が置かれているため、すでに終了した作業工程が実際にどのように行われ、それらの作業に無駄や問題がなかったかを把握することは困難であった。

本発明は、前記従来技術の問題点を解決するためになされたものであり、すでに終了した作業工程をも含めて、実際に行われた作業に無駄や問題がなかったかを把握するのに有用な各種の情報を、できるだけ見易い形で提供することを目的とする。

前記の目的を達成するために、本発明では、複数の設計工程を有する開発プロジェクトを管理の対象とする設計工程管理装置において、各設計工程において作成すべき仕様書の作成計画が登録される工程管理データベースと、作成された仕様書に一意の図番が付されてその更新履歴とともに登録される図面管理データベースとを備え、クライアント端末からの要求にしたがって、前記工程管理データベース及び図面管理データベースを検索して、前記各仕様書の作成及び更新実績を、前記クライアント端末の表示部に表示される、一方の軸を時間、もう一方の軸を設計工程とする座標平面上に、前記各仕様書の作成開始時刻を始点としてダイヤグラム表示させるようにした。

本発明によれば、複数の設計工程を含む開発プロジェクトにおける各設計工程の成果物である仕様書の作成及び更新履歴が、時刻を軸としてダイヤグラム表示されるので、プロジェクトマネージャなどが、実際に行われた作業に無駄や問題がなかったかを容易に把握することができる。

設計工程管理システムの全体構成を示すブロック図である。 工程管理処理部及び工程管理データベースの詳細構成図である。 ウォーターフォール型開発モデルの説明図である。 スパイラル型（反復型）開発モデルの説明図である。 仕様書作成計画テーブルの構成及びデータ例である。 図面管理処理部及び図面管理データベースの詳細構成図である。 図面管理テーブルの構成及びデータ例である。 図面履歴テーブルの構成及びデータ例である。 仕様書作成計画ダイヤグラムの表示例である。 図面履歴ダイヤグラム表示画面の表示例である。 図面作成実績ダイヤグラムの表示例である。 図面更新履歴ダイヤグラムの表示例である。 上位図面連結ダイヤグラムの表示例である。 詳細表示ダイヤグラムの表示例である。 障害対策時のダイヤグラムの表示例である。 設計工程管理装置の動作を示すフローチャートである。

以下、本発明に係る設計工程管理装置を実施するための好適な形態（以下、「本実施形態」という。）について、適宜図面を参照しながら詳細に説明する。なお、本実施形態において、「ダイヤグラム」とは、交通機関の運行状況を表す線図と同様に、設計作業などの工程の進捗状況を時間を軸として表した線図全般を指す。

［システム構成］
図１は、本発明に係る設計工程管理装置を含んだ設計工程管理システムの全体構成を示すブロック図である。設計工程管理システム１００は、本発明に係る設計工程管理装置としての設計工程管理サーバ１と複数のクライアント端末２とが、ＬＡＮ（Local Area Network）３によって接続されたクライアントサーバ形のコンピュータシステムとして構築されている。

設計工程管理サーバ１は、ＣＰＵ、メモリ、ハードディスクなどを備えるコンピュータであり、ＬＡＮ３を介してクライアント端末２との間の通信を行う通信インタフェース１１、工程管理処理部１２、工程管理データベース１３、図面管理処理部１４、及び図面管理データベース１５を有して成る。

工程管理処理部１２及び図面管理処理部１４は、いずれもハードディスクなどに記録された所定のプログラムがメモリにロードされてＣＰＵによって実行されることによって実現される機能を表しており、工程管理処理部１２は、設計工程全体についての計画と実績の管理を司り、図面管理処理部１４は、設計工程の出力として作成され、次の設計工程の入力となる仕様書や図面の管理を司る。

工程管理データベース１３及び図面管理データベース１５は、各種の情報を系統的に記憶し検索できるように構築され、工程管理データベース１３には、設計工程全体を管理するための情報が、図面管理データベース１５には、仕様書や図面の本体及びそれらを管理するための情報が、それぞれ登録される。

クライアント端末２は、ＣＰＵ、メモリ、ハードディスク、入力装置、表示装置などを備えるパーソナルコンピュータであり、入力装置によって入力された指示や要求などをＬＡＮ３を介して設計工程管理サーバ１に送信し、設計工程管理サーバ１から受信した情報に基づいて表示装置に表示する画面を生成する。

［工程計画及び仕様書作成計画の登録］
図２に詳細構成を示すように、工程管理処理部１２は、工程計画登録部２１と仕様書作成計画登録部２２とを有して成り、工程管理データベース１３は、工程計画テーブル３１と仕様書作成計画テーブル３２とを有して成る。
まず、工程計画登録部２１によって工程計画テーブル３１に工程計画の情報を登録する方法につき、概略を説明する。

製品開発の標準的なモデルとして、主に、ウォーターフォール型の開発モデルとスパイラル型（反復型）の開発モデルとが利用されている。
ウォーターフォール型の開発モデルとは、図３のガントチャートに示すように、開発工程全体を、例えば、「基本設計」、「機能設計」、「詳細設計」、「テスト設計」、「製造・テスト」というように、標準的な単位であるいくつかのステップに分割し、それぞれのステップの作業を、１つ前のステップの成果物に基づいて行うというモデルであり、原則として各ステップの作業は上流工程から順番に実行され、前工程への後戻りは行われない。

一方、スパイラル型（反復型）の開発モデルとは、前記と同様な工程から成るプロトタイプ開発を複数回繰り返すことによって、それらの結果をフィードバックしつつ最終的に製品開発にまでもっていくというモデルである。図４は、スパイラル型（反復型）の開発モデルにおいて計３回の繰返しを行う場合の開発計画の例をガントチャート表示したものである。なお、図４の例では、３回目の繰返し（サイクル３）においてステップ１が省略され、ステップ２から繰返しを開始するようになっている。このように、スパイラル型（反復型）の開発モデルにおいては、それぞれのステップが複数回繰り返して実行されるため、通常、各ステップにおいて作成された成果物は、繰返しの都度見直され、修正や補充が行われる。

工程計画登録部２１は、クライアント端末２に対して、例えば前記の開発モデルに基づいた工程計画のガントチャートを作成する機能を提供し、作成されたガントチャートを工程計画テーブル３１に登録する。その過程で、工程計画登録部２１から仕様書作成計画登録部２２が呼び出され、仕様書作成計画登録部２２は、工程計画を構成する各ステップにおいて作成すべき仕様書の作成計画を、仕様書作成計画テーブル３２に登録する機能を提供する。

仕様書作成計画テーブル３２は、図５にその構成を示すように、「仕様書ＩＤ」欄３２１、「サイクル」欄３２２、「ステップ」欄３２３、「カテゴリ」欄３２４、「仕様書名」欄３２５、「着手予定日」欄３２６、「完成予定日」欄３２７、「作成ページ数」欄３２８、「その他」欄３２９、「上位仕様書リスト」欄３３０を有して成り、それぞれの行は、作成すべき各仕様書に対応する仕様書レコードを表している。

これら仕様書レコードの「仕様書ＩＤ」欄３２１を除いた各欄には、各欄に対応してクライアント端末２に表示される入力欄に入力され、設計工程管理サーバ１へ送信された情報が仕様書作成計画登録部２２によって登録される。これらの入力欄は、キーボードなどからデータを入力するものでもよいし、ラジオボタン、チェックボックス、ドロップダウンリストなどを用いて選択入力するものでもよい。

「仕様書ＩＤ」欄３２１には、作成すべき仕様書を新規に登録するときに仕様書作成計画登録部２２によって付与される、それぞれの仕様書を一意に識別するために識別情報が格納される。「サイクル」欄３２２、「ステップ」欄３２３、及び「カテゴリ」欄３２４には、その仕様書が成果物として作成される工程のサイクル番号、ステップ番号、及びカテゴリ種別がそれぞれ格納される。ここで、「カテゴリ」とは、例えば「基本仕様書」、「詳細仕様書」など仕様書の種類を示す既定の文字列である。

「仕様書名」欄３２５には、クライアント端末２から入力された仕様書名が格納される。この仕様書名は、すでに登録済みの他の仕様書と名称が重複しないことが好ましいが、重複する名称を排除しないようにしてもよい。「着手予定日」欄３２６及び「完成予定日」欄３２７には、仕様書の着手予定年月日及び完成予定年月日がそれぞれ格納される。「作成ページ数」欄３２８には、仕様書の予定作成ページ数を示す整数値が格納される。「その他」欄３２９には、その他の情報を示す文字列が格納される（何も入力しなくてもよい）。

また、「上位仕様書リスト」欄３３０には、その仕様書を作成する上で参照する必要があり、それが完成しないと当該仕様書の作成に着手できない上位の仕様書を特定する情報が、仕様書ＩＤのリストとして格納される。この「上位仕様書リスト」欄３３０のデータは、ある仕様書の作成計画を登録するときに、例えば、それまでに登録済みの仕様書の一覧をクライアント端末２の入力画面にリスト表示させ、上位仕様書リストに登録すべきものを選択入力させることなどによって生成する。後記するように、この「上位仕様書リスト」欄３３０のデータは、仕様書または図面間の依存関係の表示や、図面に変更が加えられたときの影響範囲の推定に用いられる。

図５に示したデータ例は、図４に例示したスパイラル型（反復型）の開発計画に対応した仕様書作成計画のデータ登録の様子を示したものであり、このデータ例は、以下のような仕様書作成計画の情報を含んでいる。

・サイクル１のステップ１では、「○○基本」なる名称の１０ページの仕様書を作成する（仕様書ＩＤ：ｄ１の行を参照）。
・サイクル１のステップ２では、「○○機能Ａ」なる名称の３０ページの仕様書と「○○機能Ｂ」なる名称の５０ページの仕様書とを作成する（仕様書ＩＤ：ｄ２、ｄ３の行を参照）。
・サイクル１のステップ３では、「○○詳細α」なる名称の１００ページの仕様書と「○○詳細β」なる名称の２００ページの仕様書とを作成する（仕様書ＩＤ：ｄ４、ｄ５の行を参照）。
・サイクル１のステップ４では、「○○テスト」なる名称の３００ページの仕様書を作成する（仕様書ＩＤ：ｄ６の行を参照）。
・サイクル２のステップ１では、サイクル１のステップ１で作成した１０ページの仕様書「○○基本」をバージョンアップする（仕様書ＩＤ：ｄ２１の行を参照）。
・サイクル２のステップ２では、サイクル１のステップ２で作成した仕様書「○○機能Ａ」と「○○機能Ｂ」をバージョンアップし、それぞれ５０ページと７０ページの仕様書に更新する（仕様書ＩＤ：ｄ２２、ｄ２３の行を参照）。
・サイクル２のステップ３では、サイクル１のステップ３で作成した仕様書「○○詳細α」をバージョンアップし、３００ページの仕様書に更新する（仕様書ＩＤ：ｄ２４の行を参照）。
・サイクル３のステップ２では、サイクル２のステップ２で作成した仕様書「○○機能Ａ」と「○○機能Ｂ」をバージョンアップし、それぞれ７０ページと９０ページの仕様書に更新する（仕様書ＩＤ：ｄ３１、ｄ３２の行を参照）。

なお、「カテゴリ」欄３２４のデータ値の最後に”Ｖ”が付されているものは、それが既存の同一名称の仕様書のバージョンアップ版であることを表す。したがって、例えば、仕様書「○○機能Ａ」については、仕様書ＩＤ：ｄ２で新規に作成し、仕様書ＩＤ：ｄ２２で１回目のバージョンアップ版を、仕様書ＩＤ：ｄ３１で２回目のバージョンアップ版を作成する計画であることを表している。

［仕様書の図面登録と更新］
続いて、工程計画の登録が完了して、開発プロジェクトの各設計工程が開始された後に、その成果物である仕様書を図面管理処理部１４によって図面管理データベース１５に登録したり更新したりする方法について説明する。

図６に詳細構成を示すように、図面管理処理部１４は、図面管理部４１、図番採番部４２、図面履歴登録部４３、及び図面履歴検索部４４を有して成り、図面管理データベース１５は、図面管理テーブル５１、図面履歴テーブル５２、及び図面データファイル群５３を有して成る。

図面管理テーブル５１は、図７にその構成を示すように、「図番」欄５１１、「仕様書ＩＤ」欄５１２、「バージョン」欄５１３、「リビジョン」欄５１４、「ステータス」欄５１５、「ファイル名」欄５１６、及び「その他属性」欄５１７を有して成り、それぞれの行は、図番が採番されて図面登録された仕様書の各更新版に対応する図面レコードを表している。

「図番」欄５１１には、図番採番部４２によって付与され、図面登録された仕様書を一意に識別するために使用される図番が格納される。図７のデータ例では、図番をｆｎ１、ｆｎ２、・・・と表しているが、これらの値は採番が行われた順番に図番採番部４２によって自動的に付与されるものである。「仕様書ＩＤ」欄５１２には、仕様書作成計画テーブル３２への作成計画の登録時に付与された、各仕様書を一意に識別するための識別情報が格納される。

「バージョン」欄５１３及び「リビジョン」欄５１４には、図面登録された仕様書のバージョン数及びリビジョン数がそれぞれ格納される。このバージョン数は、初回の登録時が”０１”であり、仕様書がバージョンアップされる都度１ずつ値が増加し、リビジョン数は、それぞれのバージョンの初回の登録時が”００”であり、仕様書がリビジョンアップされる都度１ずつ値が増加する。ここで、バージョンアップとは、スパイラル型（反復型）の開発計画において、同一のステップが繰り返されるときに１つ前のサイクルで作成された仕様書を更新するときのような、計画された主要な更新を意味し、リビジョンアップとは、前以て計画にはなかったその他の更新を意味するものとする。したがって、ウォーターフォール型の開発計画においては、バージョンアップは存在せずに、リビジョンアップだけが行われ、スパイラル型（反復型）の開発計画においては、原則としてそれぞれの仕様書は計画された回数だけバージョンアップが行われる。

「ステータス」欄５１５には、図面登録された各仕様書が「未登録」、「承認待ち」、「入庫」、「出庫」のいずれの状態にあるかを示すステータスが格納される。各仕様書のステータスは、図面管理部４１によってクライアント端末２に表示される不図示の画面から、「採番」、「登録」、「承認」、「入庫」、「出庫」、「再登録」、「再入庫」などの操作を行うことによって、以下のような順序で遷移する。

（１）図番を採番することによって「未登録」のステータスとして図面レコードが追加される（仕様書ＩＤ：ｄ３２の行を参照）。
（２）担当者が仕様書の図面ファイルを作成してそのファイルを図面管理データベース１５に登録することによってステータスが「未登録」から「承認待ち」に更新される（仕様書ＩＤ：ｄ３１の行を参照）。
（３）図面の承認権限を有する承認者が「承認待ち」のステータスにある仕様書の承認を行った後に担当者が入庫を行うことによって図面登録が完了し、他部署からも参照可能な「入庫」のステータスとなる（仕様書ＩＤ：ｄ１、ｄ２１他の行を参照）。
（４）図面の更新（バージョンアップまたはリビジョンアップ）を行うために、担当者が図面の更新を予約する出庫を行うことにより「出庫」のステータスとなる（仕様書ＩＤ：ｄ２２、ｄ２９の行を参照）。
（５）担当者が更新した仕様書の図面ファイルを作成してそのファイルを図面管理データベース１５に再登録することによってステータスが「承認待ち」の図面レコードが追加される（仕様書ＩＤ：ｄ３１の行を参照）。
（６）図面の承認権限を有する承認者が「承認待ち」のステータスにある更新された仕様書の承認を行った後に担当者が再入庫を行うことによって図面の再登録が完了し、更新された仕様書のレコードのステータスが「承認待ち」から「入庫」となり、同時にステータスが「出庫」となっていた更新前の仕様書のレコードは「入庫」のステータスに戻る（仕様書ＩＤ：ｄ２２、ｄ３１の行を参照）。

「ファイル名」欄５１６には、図面ファイルの登録時にクライアント端末２から入力された図面ファイル名が格納される。この図面ファイル名は、すでに登録済みの他の図面ファイル名と同一ディレクトリ内で重複しないものとする必要がある。また、「その他属性」欄５１７には、図面登録された仕様書の入庫者名、出庫者名、承認者名、採番者名などの情報が格納される。

図７に示したデータ例は、図５に例示した仕様書作成計画のサイクル３が開始されたときの様子を示したものである。

図面履歴テーブル５２は、図８にその構成を示すように、「日時」欄５２１、「イベント種別」欄５２２、「図番」欄５２３、「バージョン」欄５２４、「リビジョン」欄５２５、及び「その他」欄５２６を有して成り、それぞれの行は、図面登録された仕様書に関して発生したイベントに対応するイベントレコードを表している。これらのイベントレコードは、該当するイベントが発生する都度、図面履歴登録部４３によって図面履歴テーブル５２の末尾に追加して登録される。

「日時」欄５２１には、イベントが発生した日時が格納される。「イベント種別」欄５２２には、発生したイベントの種別として、「採番」、「登録」、「承認」、「入庫」、「出庫」、「再登録」、「再承認」、「再入庫」などが格納される。「図番」欄５２３、「バージョン」欄５２４、及び「リビジョン」欄５２５には、イベントの対象となった仕様書の図番、バージョン数、及びリビジョン数がそれぞれ格納される。また「その他」欄５２６には、採番者名、登録者名、承認者名、入庫者名、出庫者名などの情報が格納される。

図８に示したデータ例は、図７に例示した図面管理テーブル５１のデータに対応するデータ例を表したものである。

［ダイヤグラム表示］
以下、前記のようにして工程管理データベース１３と図面管理データベース１５とに蓄積された仕様書作成計画とその作成実績の履歴情報とから、設計工程管理に有用な各種のダイヤグラムを表示する方法について説明する。

図９は、仕様書作成計画登録部２２によってクライアント端末２に表示される仕様書作成計画ダイヤグラムの表示例である。仕様書作成計画ダイヤグラムは、横軸を時間、縦軸を設計工程を構成する各ステップとし、仕様書の作成に着手する日（図５の「着手予定日」欄３２６）と仕様書の作成を完了する日（図５の「完成予定日」欄３２７）とを斜線９１で結んだ線図である。同一のステップ内で複数の仕様書を作成する場合には、それぞれの仕様書に対応する複数の斜線が描かれる。

また、ステップとステップとの間のやや狭い空間には、仕様書間に依存関係が存在する場合に、対応する仕様書を示す斜線９１の端点間に実線９２が描かれる。また、マウスカーソル９３などによって斜線９１を選択することによって、吹出し９４の中に対応する仕様書の詳細情報が表示される。

なお、図９に示したデータ例では、各仕様書を区別するために便宜的に斜線９１に仕様書ＩＤを付しているが、実際の画面上には、仕様書ＩＤを表示してもよいし、表示しなくてもよい。

図９の表示例は、図５の仕様書作成計画テーブル３２の「上位仕様書リスト」欄３３０に登録された以下のような仕様書間の依存状態を表したものである。
・仕様書ｄ２とｄ３の双方が仕様書ｄ１に依存している。
・仕様書ｄ４は仕様書ｄ２に依存している。
・仕様書ｄ５は仕様書ｄ３に依存している。
・仕様書ｄ６は仕様書ｄ４とｄ５の双方に依存している。
このような仕様書作成ダイヤグラムから、開発プロジェクトを構成する各設計工程の依存関係の把握が容易となり、仮にある設計工程に遅延が生じた場合に、それが下流のどの工程に影響するかを推測することができる。

図１０は、図面履歴検索部４４によってクライアント端末２に表示される図面履歴ダイヤグラム表示画面の基本構成を示したものである。図面履歴ダイヤグラム表示画面は、画面の中央付近で詳細データ表示部１０１とダイヤグラム表示部１０２とに２分割される。詳細データ表示部１０１には、ダイヤグラム表示部１０２に表示されているダイヤグラムに関する詳細な情報が表示される。「単独」ボタン１０３及び「連結」ボタン１０４は、ダイヤグラムを１つのステップ（設計工程）のみについて単独で表示させるか、上位のステップを連結して表示させるかを選択入力するためのボタンであり、その選択結果に応じてダイヤグラム表示部１０２の表示内容が切り換えられる。

「詳細」ボタン１０５は、後記する詳細表示ダイヤグラム画面を別ウィンドウに表示させるためのボタンであり、「計画」ボタン１０６及び「実績」ボタン１０７は、それぞれ計画のダイヤグラムだけを表示させるか、実績と計画のダイヤグラムを重ね合わせて表示させるかを選択入力するためのボタンである。

図１０に示すように、計画のダイヤグラムを破線で、実績のダイヤグラムを実線で表示した場合、計画と実績とが一致した場合には計画を示す破線のダイヤグラムが実績を示す実線のダイヤグラムに隠されて判別できなくなる。そのようなときに「計画」ボタン１０５を選択入力すれば、隠されていた計画のダイヤグラムだけを表示させることができる。

図１１は、ダイヤグラム表示部１０２に表示されるダイヤグラムから計画と実績との差異を分析する方法を説明するための図であり、横軸を時間、縦軸をステップの開始と終了として、計画を破線１１３で、実績を実線１１４で描いたダイヤグラムである。また▽記号１１１は計画上の着手予定日を、△記号１１２は計画上の完成予定日をそれぞれ示している。

なお、仕様書の作成に着手するときには始めに採番を行うことを前提とし、実績の開始時刻は採番が行われた時刻、完了時刻は入庫が完了した時刻として実績のダイヤグラムを作成する。

まず、図１１（ａ）は、計画の破線１１３と実績の実線１１４とが一致しており（説明の都合上、図では近接して描いてある）、計画通りに仕様書が作成された場合の表示例を示したものである。このようなダイヤグラムからは、特に問題なく設計作業が実行されているものと推定できる。

図１１（ｂ）は、計画の破線１１３の右側にほぼ一定の間隔を置いて実績の実線１１４が描かれている。このようなダイヤグラムからは、仕様書作成への着手が遅れ、そのために仕様書の完成が遅延したものと推定できる。

図１１（ｃ）は、計画の破線１１３と実績の実線１１４とは、始点がほぼ一致し、終点は計画より実績の方がかなり右に来ている。このようなダイヤグラムからは、例えば予想したよりも工数がかかったか、人員不足などによって作業に遅延が生じたものと推定できる。

図１１（ｄ）は、計画の破線１１３と実績の実線１１４とは、始点がほぼ一致し、終点は計画より実績の方が左に来ている。このようなダイヤグラムからは、例えば予想工数が過大であったか、必要以上に人員を投入した結果として作業が前倒しで完了したものと推定できる。

また、図１１（ｅ）は、計画の破線１１３がなく実績の実線１１４だけが描かれている。このようなダイヤグラムからは、当初の計画にはなかった仕様書の作成作業が実行されており、計画そのものが不十分であったか、予想外の原因によって、仕様書の構成の見直しが必要になったものと推定できる。

図１２は、ある１つ図番が採番された仕様書の更新履歴を単独でダイヤグラム表示した例を示したものである。図１２（ａ）と（ｂ）とは、サイクル１〜３から成る同一の計画ダイヤグラムに対して、異なる実績ダイヤグラムが描かれた場合を示している。図１２（ａ）では、破線１１３ａ、１１３ｂ、１１３ｃで示される３回の仕様書のバージョンアップ計画に対して、実際には太い実線１１４ａと１１４ｂとで示される２回しかバージョンアップが実行されておらず、細い実線１１５で示される予定外のリビジョンアップ作業が発生しており、その影響によって当初計画したステップの繰返し回数が３回から２回に削られて、製品開発が何とか予定の期間で終了したものと推定できる。

また、図１２（ｂ）では、同様な３回の仕様書のバージョンアップ計画に対して、実際には実線１１４ａ〜１１４ｄで示される４回のバージョンアップが実行されており、何らかの理由で３回のステップの繰返しでは製品仕様を収束することができず、もう１回余分にステップを繰り返すことになった結果、全体の工程が遅延することになったものと推定できる。

図１３は、ある１つの仕様書の作成実績を上位の仕様書と連結してダイヤグラム表示した例を示したものである。図１３（ａ）のステップｉの計画の破線１１３ｉは、その上位ステップであるステップｉ−１の計画の破線１１３ｈと連結されているため、ステップｉの仕様書はステップｉ−１の仕様書が完成してからでないと作成に着手できないことが分かる。そのため、実績の実線１１４ｉもその上位ステップの実績の実線１１４ｈの終点と連結されており、このようなダイヤグラムから、上位のステップの遅延によってこのステップの着手が遅れたために、結果としてこのステップの仕様書の完成も遅延してしまったものと推定できる。

また、図１３（ｂ）においては、同様に仕様書の作成に依存関係があり、実線１１４ｈと１１４ｉで示されるように、２つの仕様書が作成された後に、細い実線１１４ｊで示されるように何らかの理由でステップｉ−１において予定外の仕様書のリビジョンアップが行われた場合を示している。このように依存関係にある２つの仕様書の内、上位の仕様書が更新された場合には、通常はその下位の仕様書にも上位の仕様書の変更内容を反映する必要が生じる。この例では、下位の仕様書の更新作業が行われていないので、吹出し１１６に例えば「上位図面が修正されています」というような警告メッセージを表示して更新作業が必要なことを明示する。あるいは、その仕様書を作成した担当者宛に、同様なメッセージを電子メールで配信したり、その担当者がログインしているクライアント端末２の画面上に同様のメッセージを表示させるようにしてもよい。

図１４は、図１０の「詳細」ボタン１０５が選択入力されたときに別ウィンドウに表示される詳細表示ダイヤグラム画面の表示例を示したものである。この詳細ダイヤグラム表示画面は、図１０において、ダイヤグラム表示部１０２に表示されているダイヤグラム中の実線または破線の１つをマウスカーソルなどで選択状態にしてから「詳細」ボタン１０５を選択入力することによって、選択状態となっている実線または破線に該当する情報が別ウィンドウに表示される。

このような詳細表示ダイヤグラムは、前記した図面履歴テーブル５２に蓄積された当該仕様書に関するイベントレコードを抽出して作成するものであり、図１４に示したような詳細表示ダイヤグラムを作成するためには、前記の図面管理部４１に、「チームリーダによるチェック」、「差戻し」などの操作を行う機能を追加するとともに、図面履歴テーブル５２にもそれらのイベントの履歴を追加登録する必要がある。また、工程管理処理部１２には、担当者、チームリーダ、プロジェクトマネージャなどの情報を登録する機能が必要となる。また、それぞれの標準作業手順における標準的な作業工数も前以て設計工程管理サーバ１内に登録しておく必要がある。

詳細表示ダイヤグラム表示画面は、横軸を時間、縦軸をその仕様書の作成に関わる人として、作業を実行する人の欄に横線を描いたダイヤグラムである。図１４の例では、縦軸はプロジェクトマネージャ、チームリーダ、担当者の３名が仕様書の作成に関与し、破線１４１で示した標準的な作業手順は、まず担当者が仕様書の原案を作成し、それをチームリーダがチェックし、さらにプロジェクトリーダの承認を得た後に、担当者が「入庫」作業を行うことを想定している。これに対して図１４（ａ）の実線１４２に示した実績のダイヤグラムからは、チームリーダから担当者への差戻しが発生して担当者が修正を加えた後に再度チームリーダのチェック作業が行われたために、△記号１４３で示される標準完了予定日よりも▲記号１４４で示される実際の完了日が遅れてしまったことを把握できる。

また、図１４（ｂ）の実線１４２に示した実績のダイヤグラムからは、チームリーダによるチェックが完了してからプロジェクトマネージャがその承認作業に着手するまでに時間的なロスが生じていることが分かり、例えば何らかの理由によってプロジェクトマネージャが不在だったことによって遅延が発生したものと推定できる。

図１５は、開発の過程において予想外の障害が発生し、その対策のために仕様書をリビジョンアップした場合のダイヤグラムの表示例を示したものである。図１５（ａ）は、実線１１４で示される仕様書の完成後に△記号１５１で示される時点で障害が発生し、その対策のために実線１１５で示される予定外の仕様書のリビジョンアップが実行されたことを表している。また図１５（ｂ）と図１５（ｃ）とは、障害対策が担当者による仕様書の修正によって完結する破線１４１で示した標準の作業手順に対して、実際にはチームリーダまたはプロジェクトマネージャによる仕様書の見直し作業が発生したために、実際の作業手順は実線１４２で示されるようなものとなり、障害対策により多くの時間を要する結果となったことを表している。

このような、詳細表示ダイヤグラムを用いることにより、ある設計工程において行われた実際の作業手順をより詳細に分析することができ、無駄や問題の把握に役立つ。

図１６は、設計工程管理サーバ１の動作の概要を示したフローチャートである。以下、図１６のフローチャートに沿って設計工程管理サーバ１の動作概要を説明する。

まず初めに、設計工程管理サーバ１は、ステップＳ１において、クライアント端末２からの仕様書作成計画登録要求の有無を判定し、登録要求がなければ（ステップＳ１でＮｏ）ステップＳ３に処理を進め、登録要求があれば（ステップＳ１でＹｅｓ）ステップＳ２において、仕様書作成計画登録部２２が、仕様書作成計画表示・登録処理を実行し、入力された仕様書作成計画を仕様書作成計画テーブル３２に登録する。

次に設計工程管理サーバ１は、ステップＳ３において、クライアント端末２からの図面情報登録・更新要求の有無を判定し、登録要求がなければ（ステップＳ３でＮｏ）ステップＳ６に処理を進め、登録要求があれば（ステップＳ３でＹｅｓ）ステップＳ４において、図面管理処理部１４が、図面管理情報表示・登録処理を実行し、図面管理情報及び図面データファイルを図面管理テーブル５１及び図面データファイル群５３に登録するとともに、ステップＳ５において、図面履歴テーブル５２に図面登録された仕様書に関して発生したイベントの登録を実行する。

次に設計工程管理サーバ１は、ステップＳ６において、クライアント端末２からの図面履歴検索要求の有無を判定し、検索要求がなければ（ステップＳ６でＮｏ）ステップＳ８に処理を進め、検索要求があれば（ステップＳ６でＹｅｓ）ステップＳ７において、図面履歴検索部４４が、図面履歴検索処理を実行し、クライアント端末２からの要求にしたがって各種のダイヤグラムを表示する。

次にステップＳ８において、クライアント端末２からの終了指示の有無を判定し、終了指示がなければ（ステップＳ８でＮｏ）ステップＳ１に戻って前記の処理を繰り返し、終了指示があれば（ステップＳ８でＹｅｓ）処理を終了する。

以上説明したように、本実施形態に係る設計工程管理システムによれば、開発プロジェクトを構成する各設計工程の作業実績が、計画と対比した形でダイヤグラム表示されるので、プロジェクトマネージャなどが、実際に行われた作業に無駄や問題がなかったかを容易に把握することができる。さらに、そのような無駄や問題に対する対策を講じることによる開発プロジェクトの生産性向上も期待できる。

以上で本実施形態の説明を終えるが、本発明を実施する態様はこれらに限定されるものではない。例えば、工程管理処理部１２と図面管理処理部１４とをそれぞれ別のコンピュータで実行させてもよいし、設計工程管理サーバ１にＷｅｂサービスの機能を加えて、Ｗｅｂクライアント端末から各種ダイヤグラムを表示できるようにしてもよい。その他、各種画面の表示形態やテーブル構成などについても、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ 設計工程管理サーバ（設計工程管理装置）
２ クライアント端末
３ ＬＡＮ
１１ 通信インタフェース
１２ 工程管理処理部
１３ 工程管理データベース
１４ 図面管理処理部
１５ 図面管理データベース
２１ 工程計画登録部
２２ 仕様書作成計画登録部
３１ 工程計画テーブル
３２ 仕様書作成計画テーブル
４１ 図面管理部
４２ 図番採番部
４３ 図面履歴登録部
４４ 図面履歴検索部
５１ 図面管理テーブル
５２ 図面履歴テーブル
５３ 図面データファイル群
１００ 設計工程管理システム

Claims (6)

1. 複数の設計工程を有する開発プロジェクトを管理の対象とする設計工程管理装置であって、
   各設計工程において作成すべき仕様書の作成計画が登録される工程管理データベースと、
   作成された仕様書に一意の図番が付されてその更新履歴とともに登録される図面管理データベースとを備え、
   クライアント端末からの要求にしたがって、前記工程管理データベース及び図面管理データベースを検索して、前記各仕様書の作成及び更新実績を、前記クライアント端末の表示部に表示される、一方の軸を時間、もう一方の軸を設計工程とする座標平面上に、前記各仕様書の作成開始時刻を始点とし、その作成終了時刻を終点としてダイヤグラム表示させる
   ことを特徴とする設計工程管理装置。
2. 前記各仕様書の作成開始時刻は、前記各仕様書の図番を採番した時刻または出庫した時刻であり、その作成終了時刻は、仕様書を入庫した時刻である
   ことを特徴とする請求項１に記載の設計工程管理装置。
3. 前記座標平面上に、前記各仕様書の作成及び更新実績を示すダイヤグラムとともに、当該仕様書の作成開始予定時刻と完成予定時刻とを結んだ計画ダイヤグラムを表示させる
   ことを特徴とする請求項１または請求項２に記載の設計工程管理装置。
4. 前記各仕様書の作成及び更新実績を示すダイヤグラムを描くときに、前記仕様書の作成計画に登録されていた仕様書と、登録されていなかった仕様書とで異なる種類の線を用いる
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の設計工程管理装置。
5. 前記仕様書の作成計画に、さらに仕様書間の依存関係を登録し、登録された仕様書間の依存関係を前記作成及び更新実績を示すダイヤグラムに表示するとともに、依存関係にある２つの前記仕様書の内、上位の仕様書が更新され、下位の仕様書が更新されていないときに、警告メッセージを表示またはメール送信する
   ことを特徴とする請求項１から請求項４のいずれか一項に記載の設計工程管理装置。
6. 前記各仕様書の作成及び更新実績を示すダイヤグラムから選択された直線に対応する仕様書に関して実行された作業の履歴を図面管理データベースから検索し、その仕様書の作成に関わったメンバーが行った作業の履歴を、一方の軸を時間、もう一方の軸をメンバーとする座標平面上に、前記各作業の開始時刻と終了時刻を時系列順に接続した直線によってダイヤグラム表示させる
   ことを特徴とする請求項１から請求項５のいずれか一項に記載の設計工程管理装置。

Images