特開 2022-47732 進捗管理システム、方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022047732

(43)【公開日】2022-03-25

(54)【発明の名称】進捗管理システム、方法、およびプログラム

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20220317BHJP

   G06Q 50/10 20120101ALI20220317BHJP

【ＦＩ】

G06Q10/06

G06Q50/10

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2020153667

(22)【出願日】2020-09-14

(71)【出願人】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(71)【出願人】

【識別番号】301063496

【氏名又は名称】東芝デジタルソリューションズ株式会社

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100162570

【弁理士】

【氏名又は名称】金子 早苗

(72)【発明者】

【氏名】宮田 真紀子

(72)【発明者】

【氏名】北川 貴之

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA09

5L049CC12

(57)【要約】      （修正有）

【課題】ソフトウェア設計ドキュメントの作成状況を可視化し、これにより開発の進捗を効果的に管理できる進捗管理システム、方法及びプログラムを提供する。
【解決手段】進捗管理システムは、設計書情報保持部と、活動記録保持部と、設計情報解析部と、プロジェクト管理部とを具備する。設計書情報保持部は、プロジェクトに係わる設計書情報を保持する。活動記録保持部は、プロジェクトの開発担当者が実施した設計書レビュー結果の実施記録、開発担当者間で行われた会議の記録及びプロジェクトの活動の記録に関連する議論情報を保持する。設計情報解析部は、設計書情報保持部に登録された設計書情報と、活動記録保持部に登録された議論情報とを取得し、これらの情報を相互に関連付ける。プロジェクト管理部は、関連付けされた情報に基づいて、プロジェクトの進捗に伴って作成されるソフトウェア設計ドキュメントのページ数を保持する。
【選択図】図１

【特許請求の範囲】

【請求項1】

プロジェクトに係わる設計書情報を保持する設計書情報保持部と、
前記プロジェクトの開発担当者が実施した設計書レビュー結果の実施記録、前記開発担当者間で行われた会議の記録、および前記プロジェクトの活動の記録に関連する議論情報を保持する活動記録保持部と、
前記設計書情報保持部に登録された設計書情報と、前記活動記録保持部に登録された議論情報とを取得し、これらの情報を相互に関連付ける設計情報解析部と、
前記関連付けされた情報に基づいて、前記プロジェクトの進捗に伴って作成されるソフトウェア設計ドキュメントのページ数を保持するプロジェクト管理部とを具備する、進捗管理システム。

【請求項2】

前記設計情報解析部に保持される情報と、前記プロジェクト管理部に保持される情報とを取得し、前記ソフトウェア設計ドキュメントの作成状況を表すグラフを生成する進捗状況解析部をさらに具備する、請求項１に記載の進捗管理システム。

【請求項3】

前記作成されたグラフを視覚的に表示する進捗状況表示部をさらに具備する、請求項２に記載の進捗管理システム。

【請求項4】

コンピュータが、プロジェクトに係わる設計書情報を保持する工程と、
コンピュータが、前記プロジェクトの開発担当者が実施した設計書レビュー結果の実施記録、前記開発担当者間で行われた会議の記録、および前記プロジェクトの活動の記録に関連する議論情報を保持する工程と、
コンピュータが、前記設計書情報と前記議論情報とを取得し、これらの情報を相互に関連付ける工程と、
コンピュータが、前記関連付けされた情報に基づいて、前記プロジェクトの進捗に伴って作成されるソフトウェア設計ドキュメントのページ数を保持する工程と
を含む、進捗管理方法。

【請求項5】

プロジェクトに係わる設計書情報を保持する機能と、
前記プロジェクトの開発担当者が実施した設計書レビュー結果の実施記録、前記開発担当者間で行われた会議の記録、および前記プロジェクトの活動の記録に関連する議論情報を保持する機能と、
前記設計書情報と前記議論情報とを取得し、これらの情報を相互に関連付ける機能と、
前記関連付けた情報に基づいて、前記プロジェクトの進捗に伴って作成されるソフトウェア設計ドキュメントのページ数を保持する機能と
をコンピュータに実行させるための命令を含む、プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、進捗管理システム、方法、およびプログラムに関する。

【背景技術】

【0002】

ソフトウェア開発などのプロジェクトにおいては、進捗を管理することが重要であるが、様々な要因が複雑に絡み合って予定通りにはいかない。例えば、プログラムの設計工程ひとつをとってみてもその進捗度合いを判断することは難しく、従来は進捗確認のために工程表を書いたり、進捗の度合いを報告したりしていた。

【0003】

従来の手法では、工程表や報告のうえでは「設計完了」となっていても開発者間での議論が相変わらず続いていたり、設計書の修正が生じたりする。このように、現場からの報告とプロジェクト進捗とが乖離していることは、たびたび経験される。また、工程表（ガントチャート）上では終わっていることになっているのに議論が続いていたり、設計書の修正が繰り返される箇所には問題が潜んでいるケースがある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００９-２４５２８５

【特許文献2】特開２００２-１４８１１

【特許文献3】特開２００７-３４５６８

【発明の概要】

【発明が解決しようとする課題】

【0005】

以上述べたように、プロジェクトの進捗を客観的に把握することは難しい。報告書の作成を厳密に義務付けることは、作業者に負担を感じさせる場合があり、アジャイル開発においては特にその傾向が強い。そもそも、報告書や成果物に完全な客観性を求めることは困難で、このことが、進捗の把握をますます難しくしている原因の一つといえる。

【0006】

そこで、目的は、ソフトウェア設計ドキュメントの作成状況を可視化し、これにより開発の進捗を効果的に管理できるようにした進捗管理システム、方法、およびプログラムを提供することにある。

【課題を解決するための手段】

【0007】

実施形態によれば、進捗管理システムは、設計書情報保持部と、活動記録保持部と、設計情報解析部と、プロジェクト管理部とを具備する。設計書情報保持部は、プロジェクトに係わる設計書情報を保持する。活動記録保持部は、プロジェクトの開発担当者が実施した設計書レビュー結果の実施記録、開発担当者間で行われた会議の記録、およびプロジェクトの活動の記録に関連する議論情報を保持する。設計情報解析部は、設計書情報保持部に登録された設計書情報と、活動記録保持部に登録された議論情報とを取得し、これらの情報を相互に関連付ける。プロジェクト管理部は、関連付けされた情報に基づいて、プロジェクトの進捗に伴って作成されるソフトウェア設計ドキュメントのページ数を保持する。

【図面の簡単な説明】

【0008】

【図1】図１は、実施形態に係わる進捗管理システムの一例を示すシステム図である。

【図2】図２は、設計情報解析部１０１の一例を示す機能ブロック図である。

【図3】図３は、設計書情報解析結果保持部１０１３のデータテーブルの一例を示す図である。

【図4】図４は、活動情報保持部１０１５のデータテーブルの一例を示す図である。

【図5】図５は、プロジェクト管理部１０６のデータテーブルの一例を示す図である。

【図6】図６は、設計書構造管理部１０１２のデータテーブルの一例を示す図である。

【図7】図７は、図１の進捗管理システムにおける処理の流れの一例を示す図である。

【図8】図８は、チケット登録画面の一例を示す図である。

【図9】図９は、進捗状況表示部１０５に表示されるグラフの一例を示す図である。

【図10】図１０は、設計情報解析部１０１における処理の流れの一例を示す図である。

【図11】図１１は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【図12】図１２は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【図13】図１３は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【図14】図１４は、方法３において用いられるチケットの一例を示す図である。

【図15】図１５は、（方法３）における処理の流れの一例を示す図である。

【図16】図１６は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【図17】図１７は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【図18】図１８は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。

【発明を実施するための形態】

【0009】

図１は、実施形態に係わる進捗管理システムの一例を示すシステム図である。このシステムは、設計情報解析部１０１、設計書情報保持部１０２、活動記録保持部１０３、進捗状況解析部１０４、進捗状況表示部１０５、および、プロジェクト管理部１０６を具備する。

【0010】

設計情報解析部１０１は、設計書情報保持部１０２に登録された設計書情報と、活動記録保持部１０３に登録された議論情報とを取得し、これらの情報を相互に関連付ける。また、設計情報解析部１０１は、設計書情報保持部１０２に保持される情報と、活動記録保持部１０３に保持される情報とを、項目ごとに分解して保持する。また、設計情報解析部１０１は、設計書情報保持部１０２から取得した複数の設計書情報のＩＤ（要件ＩＤ、機能ＩＤ、画面ＩＤ等）を、互いに関連付ける処理を行う。さらに、設計情報解析部１０１は、設計書情報保持部１０２から取得した設計書情報の各項目の更新履歴を保持する。

【0011】

設計書情報保持部１０２は、例えばサーバにより管理されるデータベースの構成要素であり、プロジェクトに係わる設計書情報を保持する。また設計書情報保持部１０２は、開発担当者が作成した設計書を保持するとともに、設計書の履歴の管理も行う。

【0012】

活動記録保持部１０３は、開発担当者が実施したＷＴ（ウォークスルー：設計書レビュー）結果の実施記録、開発担当者間で行われた会議の記録（会話記録、議事録）、ならびにプロジェクトの活動の記録を保持する。それぞれの記録は、例えば「チケット」と称される、タスク管理用のツールを用いてシステムに登録することができる。チケットについては後述する。

【0013】

進捗状況解析部１０４は、設計情報解析部１０１、およびプロジェクト管理部１０６にそれぞれ保持される情報を取得し、設計ドキュメントの作成状況を表すグラフを生成する。進捗状況表示部１０５は、進捗状況解析部１０４により作成された、作成状況を表すグラフを視覚的に表示する。
プロジェクト管理部１０６は、プロジェクトのスケジュールや作成予定の成果物、およびその成果物のページ数を保持する。

【0014】

ここで、設計書情報保持部１０２、活動記録保持部１０３は、それぞれ担当者１０によりアクセスされる。進捗状況表示部１０５は、プロジェクトマネージャ２０、あるいは専任の担当者によりアクセスされる。プロジェクト管理部１０６は、プロジェクトマネージャ３０によりアクセスされる。

【0015】

図２は、設計情報解析部１０１の一例を示す機能ブロック図である。設計情報解析部１０１は、機能ブロックとして設計書情報取得・解析部１０１１、設計書構造管理部１０１２、設計書情報解析結果保持部１０１３、活動情報取得部１０１４、活動情報保持部１０１５、および、ドキュメント作成情報統合部１０１６を備える。

【0016】

設計書情報取得・解析部１０１１は、プロジェクト管理部１０６からアクセスされて、設計書情報保持部１０２に登録された設計情報を取得する。また、設計書情報取得・解析部１０１１は、設計書構造管理部１０１２において管理されている設計書の構造を読み取り、取得した設計書情報を設計項目ごとに分解する。この分解された設計書情報は、設計書情報解析結果保持部１０１３に格納される。

【0017】

設計書構造管理部１０１２は、設計書の構造を管理する。
設計書情報解析結果保持部１０１３は、取得した設計書の情報を格納する。
活動情報取得部１０１４は、活動記録保持部１０３に保持されている活動情報を取得し、活動情報保持部１０１５に格納する。なお、活動記録保持部１０３には、複数の種類の活動記録が登録されている。活動情報（活動記録）としては、例えばＷＴ記録、議論記録、および課題などがある。

【0018】

活動情報保持部１０１５は、活動情報取得部１０１４により取得された活動情報を保持する。ここで、活動情報取得部１０１４、および活動情報保持部１０１５は、活動の記録の観点ごとに保持される。観点とは、例えばＷＴ記録、議論記録、あるいは課題記録などである。

【0019】

ドキュメント作成情報統合部１０１６は、設計書情報解析結果保持部１０１３に格納されているドキュメントの作成情報と、活動情報保持部１０１５に格納されている活動情報を、「設計書の識別子」に基づいて関連付けする。

【0020】

図３は、設計書情報解析結果保持部１０１３のデータテーブルの一例を示す図である。図３において、例えば１行目のテーブルにおいて、設計書の分類は「画面」、設計書名は「画面レイアウト」、設計書の分類ＩＤは「Ｉ１」である。よって当該テーブルは「Ｉ１画面の画面レイアウト」となる。同様に、例えば３行目のテーブルは「Ｆ１機能の機能概要」となる。ここで、設計書テンプレートＩＤ、設計書名、設計書の分類ＩＤ、および関連機能ＩＤは、設計書に記載されている内容から取得することができる。また、設計書ページ数は、更新回数に相当する。また、１つの画面には、例えば画面レイアウト、画面項目仕様書、あるいは画面項目処理仕様書のように、複数の設計書がある。

【0021】

図４は、活動情報保持部１０１５のデータテーブルの一例を示す図である。図４に示されるように、活動記録の分類、対象の設計書の識別子、等の項目があり、プロジェクトに関係する各メンバの活動の履歴が管理される。

【0022】

図５は、プロジェクト管理部１０６のデータテーブルの一例を示す図である。プロジェクト管理部１０６に登録される設計書は、設計書情報解析結果保持部１０１３に登録される設計書より上位に位置づけられる。つまり、「機能設計書」には「画面レイアウト」や「機能概要」といった設計書が含まれる。

【0023】

図６は、設計書構造管理部１０１２のデータテーブルの一例を示す図である。このデータテーブルには、設計書の親子関係が登録される。例えば、要件定義書は、要件一覧表やシステム関連図などを含む。さらに、要件一覧表は、要件名、要件ＩＤといった設計項目を含む。次に、上記構成における作用を説明する。

【0024】

図７は、図１の進捗管理システムにおける処理の流れの一例を示す図である。図７において、先ず、プロジェクトマネージャ３０が、主要成果物作成のためのスケジュール、成果物の作成予定、主要設計書の識別子をプロジェクト管理部１０６に入力する（ステップＳ１）
次に、担当者１０は、作成した設計書を、設計書を識別する情報［識別子］とともに設計書情報保持部１０２に登録する（ステップＳ２）。［識別子］としては（Ｉ１画面のＡ設計書）などの情報が付与される。付与の仕方についての詳細は後述する。また、担当者１０は、活動記録をチケットにして活動記録保持部１０３に登録する（ステップＳ３）。

【0025】

図８は、チケット登録画面の一例を示す図である。チケットとは、活動記録保持部１０３において、タスクを管理するために用いられる情報である。例えば、実施すべき作業、修正すべきバグなどの一つ一つのタスクを、チケットとして登録することができる。図８において、［分類］欄には、ＷＴ記録、議論記録、課題などを選択して入力できる。［タイトル］欄には、識別子としての設計書のタイトルを入力する。［説明］欄には、ＷＴでの指摘事項や、会話の記録を記述することができる。また、［親チケット］欄には、親チケットの識別子が自動で入力される。つまり親チケットから子チケットを生成する際に、この欄に情報が自動的に入力される。このほかチケット登録画面には、［ステータス］、［優先度］など、各種の情報を入力するための欄が設けられる。１件のタスクにつき１件のチケットを作成し、タスクの内容・優先度・担当者・期日・進捗状況などを記録する。

【0026】

図７に戻って説明を続ける。設計情報解析部１０１（設計書情報取得・解析部１０１１）は、プロジェクト管理部１０６に登録されている主要設計書情報を取得する（ステップＳ４）。また、設計書情報取得・解析部１０１１は、設計書情報保持部１０２から設計書情報を取得する（ステップＳ５）。

【0027】

さらに、設計情報解析部１０１（活動情報取得部１０１４）は、活動記録保持部１０３からチケットを取得する（ステップＳ６）。また、設計情報解析部１０１は、設計書情報とチケット情報との関連付けを行う（ステップＳ７）
プロジェクトマネージャ２０、または担当者は進捗状況表示部１０５（ブラウザなど）を操作して、プロジェクトの進捗状況を見る（ステップＳ８）。例えば、設計書の変更状況を見ることができる。ユーザの操作に応じて、進捗状況表示部１０５は、進捗状況解析部１０４に、設計書分類「画面」の変更状況のグラフ作成を依頼する（ステップＳ９）。

【0028】

これに応じて進捗状況解析部１０４は、各設計書の実施日、更新回数（レビジョン）を設計書情報解析結果保持部１０１３から取得するとともに、プロジェクト管理部１０６から開始日、完了日の予定と実績を取得する（ステップＳ１０）。取得した各種の情報に基づいて、進捗状況解析部１０４は進捗を視覚的に示すグラフを作成する（ステップＳ１１）。進捗状況表示部１０５は、進捗状況解析部１０４にグラフ情報取得要求を出し（ステップＳ１２）これに応じて返送されたレスポンスデータを、グラフに表示する（ステップＳ１３）
図９は、進捗状況表示部１０５に表示されるグラフの一例を示す図である。図９に示されるグラフは、設計書の変更状況を示すグラフである。図９において、Ｉ１画面、Ｉ２画面、Ｉ３画面、Ｉ４画面、…ごとに異なる色（図中ハッチング）で、画面レイアウト、画面項目仕様書、…の各項目ごとに、更新回数が縦軸にプロットされる。グラフは、設計書情報解析結果保持部１０１３の実施日を参照し、日ごとに表示させるようにしてもよい。日を進めたり、戻したりして日々の進捗具合をグラフで表示させることもできる。また、プロジェクト管理部１０６に登録されている設計書の作成開始予定日、完了予定日に基づいて、作成開始より前、作成中、作成完了日より後の３種類でグラフの色分けをしてもよい。

【0029】

図１０は、設計情報解析部１０１における処理の流れの一例を示す図である。図１０において、設計情報解析部１０１の設計書情報取得・解析部１０１１は、設計書構造管理部１０１２から設計書の構造を取得する（ステップＳ５－１）。また設計書情報取得・解析部１０１１は、設計書情報を設計項目ごとに分解し（ステップＳ５－２）、設計書情報を分解した内容を設計書情報解析結果保持部１０１３に転送し、登録する（ステップＳ５－３）。

【0030】

一方、活動情報取得部１０１４は、活動情報保持部１０１５に活動記録を登録する（ステップＳ６－１）。また、ドキュメント作成情報統合部１０１６は、設計書情報解析結果保持部１０１３から設計書情報を取得する（ステップＳ７－１）とともに、活動情報保持部１０１５から活動記録を取得する（ステップＳ７－２）。さらに、ドキュメント作成情報統合部１０１６は、ステップＳ７－１とステップＳ７－２で取得した情報の関連付けを行う（ステップＳ７－３）。関連付けの方法としては主に３つのパターンを考えることができるが、詳しくは後述する。ここで、進捗状況表示部１０５に表示されるグラフについて他の幾つかの例を説明する。

【0031】

図１１は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。図１１に示されるグラフは、設計書の変更状況を機能ごとに示すグラフである。すなわち、機能Ｆ１、Ｆ２、Ｆ３、Ｆ４、…ごとに、設計書の変更状況が縦軸にプロットされる。このグラフを視覚化するため、進捗状況表示部１０５は、進捗状況解析部１０４に、機能毎の設計書の更新状況のグラフ作成を依頼する（ステップＳ９）。これに応じて進捗状況解析部１０４は、各設計書の更新回数を、機能毎にカウントした情報を設計情報解析部１０１から取得する（ステップＳ１０）。ここでは、設計書情報解析結果保持部１０１３の関連機能ＩＤを利用し、関連機能の画面の設計書についても更新回数を取得する。

【0032】

図１２は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。図１２に示されるグラフは、設計書ごとの進捗率を示すグラフである。このグラフを視覚化するため、進捗状況表示部１０５は、進捗状況解析部１０４に、設計書ごとの進捗率のグラフの作成を依頼する（ステップＳ９）。これに応じて進捗状況解析部１０４は、設計書情報解析結果保持部１０１３とプロジェクト管理部１０６から、主要設計書ごとに、設計書の現在のページ数、予定ページ数を取得する（ステップＳ１０）。そして、現在のページ数を予定ページ数で除算すれば、進捗率（現在のページ数／予定ページ数）を算出することができる。

【0033】

図１３は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。図１３に示されるグラフは、担当者の負荷を見える化したグラフである。このグラフを視覚化するため、進捗状況表示部１０５は、進捗状況解析部１０４に、担当の負荷状況のグラフ作成を依頼する（ステップＳ９）。これを受けて進捗状況解析部１０４は、設計書ごとのＷＴ記録の『活動に対する次アクションの担当者』と『次のアクションの難易度』を、活動情報保持部１０１５から取得する（ステップＳ１０）そして進捗状況解析部１０４は、『活動に対する次アクションの担当者』として割り当てられている作業の『次のアクションの難易度』の合計を担当者ごとにカウントし、合計値を縦軸にプロットしてグラフを作成する（ステップＳ１１）。

【0034】

以上のグラフのほか、例えば設計書ごとの議論実施時間数をグラフ化することも可能である。このようなグラフを作成するにあたり、進捗状況表示部１０５は、進捗状況解析部１０４に、設計書ごとの議論実施時間数のグラフ作成を依頼する（ステップＳ９）。これに応じて進捗状況解析部１０４は、活動情報保持部１０１５に記録されたデータから、設計書ごとの議論実施時間数を算出する（ステップＳ１０）。

【0035】

次に、設計書情報保持部１０２の設計書情報と活動記録保持部１０３の活動記録情報とをドキュメント作成情報統合部１０１６により関連付けるための、幾つかの方法について説明する。ここでは第１の方法、第２の方法、第３の方法について説明する。関連付けの目的は、各設計書を識別するための情報（識別子）を、設計書、およびチケットに付与することにある。

【0036】

［方法１：ルールを決めて識別子を手入力する］
例えば次のようなルールを考えることができる。図７のステップＳ１において、主要設計書を登録する際に、主要設計書の識別子を登録する。ステップＳ２において、コメント欄に識別子を入力して登録する。さらに、ステップＳ３において、チケットのタイトル欄に識別子を入力する。

【0037】

［方法２：設計書の情報から識別子を自動生成する］
図７のステップＳ１において、主要設計書を登録する際に、主要設計書の識別子を登録する。ステップＳ５において、設計書情報取得・解析部１０１１に設計書を読み込む際に、識別子を自動生成する。なお識別子の作成方法については予めルールを決めておく。例えば『設計書テンプレートＩＤ＿設計書の分類ＩＤ』のような識別子を与えることができる。そうして、ステップＳ３で、チケットのタイトルに識別子を手入力する。

【0038】

［方法３：チケットドリブンにする］
図７のステップＳ１において、主要設計書を登録するときに、主要設計書の識別子を登録する。このとき、設計書構造管理部１０１２から主要設計書と内部設計書の親子関係を取得し、チケットを自動生成する。チケットには設計書構造管理部１０１２から取得した親子関係を反映する。

【0039】

ステップＳ２において、作成した設計書を設計書情報保持部１０２に登録する際に、コメント欄に設計書のチケットＩＤを入力する。例えば『ｒｅｆｓ ＃１２３４５』などのチケットＩＤを与えることができる。ステップＳ３において、各設計書の子チケットとして、ＷＴ記録・議論記録を登録する。なお、識別子の手入力は不要となる。

【0040】

ステップＳ５において、設計書を読み込む際に、コメント欄の「ｒｅｆｓ ＃１２３４５」も取得する。またステップＳ６において、チケットを取得する際に、親チケットＩＤ（＃１２３４５）も取得する。そしてステップＳ７－３において、『ｒｅｆｓ ＃１２３４５』と親チケットＩＤ（＃１２３４５）とを関連付けることで、設計書とチケットが紐付くことになる。
図１４は、方法３において用いられるチケットの一例を示す図である。Ａ，Ｂ，Ｃ…がチケットに対応し、チケットには『＃１２３４５』などのＩＤが自動的に付与される。

【0041】

図１５は、（方法３）における処理の流れの一例を示す図である。図１５においてプロジェクトマネージャＰＭは、主要成果物作成のためのスケジュール、成果物の作成予定、主要設計書の識別子をプロジェクト管理部１０６に入力する（ステップＳ３１）。プロジェクト管理部１０６は、設計情報解析部１０１の設計書構造管理部１０１２にアクセスして、主要設計書と内部設計書の親子関係を取得する（ステップＳ３２）。また、プロジェクト管理部１０６は、チケットを自動生成して活動記録保持部１０３に入力する（ステップＳ３３）
図１６～図１８は、進捗状況表示部１０５に表示されるグラフの他の例を示す図である。図１６は、メンバ（Ａ，Ｂ，Ｃ、…）、および機能（Ｆｕｎｃ０１、Ｆｕｎｃ０２、Ｆｕｎｃ０３、…）ごとに、ＷＴ回数、議論回数、設計書更新回数などを縦軸にプロットしたグラフである。このグラフを参照すればメンバの負荷状況を把握することができ、例えばＣさんの負荷が高そう、といった状況を把握することができる。このグラフでは時間を動かすことも可能である。時間を動かすとそれに伴ってグラフも変化する。これにより、特定のメンバの負荷が常に高いのか、あるいは低いのか、または一時的なのかを把握することもできる。

【0042】

図１７は、機能および設計書名（ＩＤ）ごとに、更新回数を縦軸にプロットしたグラフである。例えば機能Ｆｕｎｃ０１の変更が多いならば、Ｆｕｎｃ０１周りの仕様に問題があるかもしれないことが分かる。画面レイアウトの変更が多いならば、レイアウト全体に問題があるかもしれないことがわかる。このように、図１７のグラフを参照すれば、機能や設計書の変更状況を把握することができる。このグラフでは時間を動かすことも可能である。時間を動かしてみて、ＳＤ工程に入っても画面仕様の変更回数が相変わらず多い場合は、何か問題が起きているのかもしれないことがわかる。
図１８は、時間経過とともに変化する折れ線グラフを用いてグラフ化した例を示す。図１８のグラフによれば、時間の経過に伴う進捗の変化を一目で把握することができる。

【0043】

以上述べたように実施形態によれば、管理者にとっては以下の利点がある。
・議論や設計書変更の回数が見えるようになるので、報告がなくても状況の把握ができる。
・問題が具体化されていなくても兆候を伺うことができる。
・議論が多くされていたり、設計書の修正が頻繁に行われている場合は、問題が発生している可能性が高いと判断できる。
・すでに工程表上では終わっていることになっている項目について、継続して議論が行われていたりする場合は、そこに問題が発生している可能性が高いと判断できる。
・工程表上では始まっていることになっているのに議論がなされていない、設計書の変更がないといった箇所はフォローすることができる。
・工程表上では始まっていないのにすでに議論がなされている場合、優先度をあげるかどうかの判断基準になる。
・開発者の負荷の状況を把握することができ、人員配置の検討をしやすくなる。

【0044】

また、開発者にとっては以下の利点がある。
・プロジェクトの状況が可視化されているので、事実を示しながら説明をすることができる。
・リアルタイムで状況を捉えることができるので、管理者だけでなく開発者も状況を把握しやすい。

【0045】

以上のように実施形態では、プロジェクトで発生している議論内容や設計書の更新履歴（更新回数等）を記録しておき、視覚的に状況を把握できるようにした。これにより、設計書の更新回数や議論の回数が見えるようになり、頻度を把握することができる。つまり、頻度の多い所は問題が発生している可能性が高いと判断することができる。また、工程表上では既に終了していることになっている項目について、継続して議論が行われていたりする場合は、そこに問題が発生している可能性が高いと判断できる。

【0046】

また、工程表上では始まっていることになっているのに議論がなされていない、設計書の更新がないといった箇所はフォローすることができる。さらに、工程表上では始まっていないのにすでに議論がなされている場合、優先度をあげるかどうかの判断基準になる。

【0047】

これらのことから、実施形態によれば、ソフトウェア設計ドキュメントの作成状況を可視化し、これにより開発の進捗を効果的に管理できるようにした進捗管理システム、方法、およびプログラムを提供することが可能となる。

【0048】

例えば、既存の技術では、「タスク」にスケジュールが含まれており、タスクを読み込むことによって、画面に機器ごとの進捗状況を示す。システムを構成する機器全体のスケジュール把握は自動と言えるが、各機器のスケジュールは担当者がタスクを更新することによって行うため、自動ではない。各機器のスケジュール入力が的確でないと、正確な進捗把握はできない。

【0049】

また別の既存の技術では、ファイルサーバの特定の場所に保存された成果物の文字数を進捗度合として計測するが、ファイルの文字数だけでは記載内容の正しさまでは解析できないので、不適当な文字列が書かれていても、進捗があると判断される可能性があると思われる。

【0050】

また別の既存の技術では、成果物の各項目の記載量やソースコード行数などで進捗度合を把握し、記載量から次工程の作業規模を予測するが、設計書の記載内容の正しさまでは解析できないので、不適当な文字列が書かれていても、進捗があると判断される可能性がある。

【0051】

これに対し実施形態によれば、設計書の更新履歴やＷＴ記録、議論記録等から、機能単位にとどまらず、設計書の項目単位でも進捗把握を自動で行うことができる。担当者が進捗を報告するために入力するデータは特にないため、管理者に表示される進捗状況は常に的確である。

【0052】

また実施形態では、成果物の更新履歴（記載量ではない）、担当者の会話履歴、ＷＴ履歴などを統合して可視化することで作業状況を把握し（進捗状況の把握材料が成果物だけではない）、進捗遅れや問題発生などの予兆を見ることができる。すなわち実施形態によれば、プロジェクト（ＰＪ）で発生している議論内容や設計書の更新履歴（更新回数等）を記録しておき、視覚的に状況を把握できるようになる。

【0053】

なお、実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。プログラムは、実施形態に記載された方法をコンピュータに実行させるための命令を含む。

【0054】

また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。

【0055】

さらに、各実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。

【0056】

また、記憶媒体は１つに限らず、複数の媒体から上記の各実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。

【0057】

なお、各実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記の各実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。

【0058】

また、各実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。

【0059】

本発明の実施形態を説明したが、この実施形態は、例として提示するものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0060】

１０…担当者、２０，３０…プロジェクトマネージャ、１０１…設計情報解析部、１０２…設計書情報保持部、１０３…活動記録保持部、１０４…進捗状況解析部、１０５…進捗状況表示部、１０６…プロジェクト管理部、１０１１…設計書情報取得・解析部、１０１２…設計書構造管理部、１０１３…設計書情報解析結果保持部、１０１４…活動情報取得部、１０１５…活動情報保持部、１０１６…ドキュメント作成情報統合部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】