(57)【要約】【課題】一般エンジニアに向けた上流設計の支援を可能にする。【解決手段】設計支援装置は、設計原理モデルのフェーズ間の順序規則と、フェーズモデルの情報とを含む設計原理モデル情報を記憶する設計原理モデル記憶手段６０１と、現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則と、プロセス単位とフェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する開発プロセス情報入力手段６０２と、設計原理モデル情報と、開発プロセス情報とに基づいてタスクを導出するタスク導出手段６０３と、フェーズ間の順序規則と、プロセス単位間の順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、現場プロセスにおけるタスクの進捗状況を更新する進捗管理手段６０４と、タスクの進捗状況を表示する表示手段６０５とを備える。【選択図】図１４
2018028831.tif 000002
【特許請求の範囲】
【請求項１】
設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報を記憶する設計原理モデル記憶手段と、
開発現場における設計プロセスである現場プロセスに関する情報であって、前記現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、前記プロセス単位と前記フェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する開発プロセス情報入力手段と、
前記設計原理モデル情報と、前記開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出するタスク導出手段と、
前記第１順序規則と、前記第２順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記タスクの進捗状況を更新する進捗管理手段と、
前記タスクの進捗状況を表示する表示手段とを備えた
ことを特徴とする設計支援装置。
【請求項２】
フェーズモデルのデータが変更された場合に、前記第１順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記変更の影響のあるタスクである影響タスクを抽出する影響タスク抽出手段を備え、
進捗管理手段は、変更前のカレントタスクと、前記影響タスクとに基づいて、現在の作業対象とされるタスクであるカレントタスクを更新する
請求項１に記載の設計支援装置。
【請求項３】
表示手段は、変更前のカレントタスクよりも上流に位置するタスクにカレントタスクが変更された場合に、その旨を強調表示する
請求項２に記載の設計支援装置。
【請求項４】
表示手段は、変更前のカレントタスクよりも上流に位置するタスクにカレントタスクが変更された場合に、前記影響タスクを強調表示する
請求項２または請求項３に記載の設計支援装置。
【請求項５】
開発プロセス情報には、設計文書に関する現場プロセスである文書プロセスに関する情報と、設計文書以外の設計作業に関する現場プロセスである作業プロセスに関する情報と、作業プロセスのプロセス単位とされる状態ごとに、文書プロセスのプロセス単位とされる設計文書または該設計文書に含まれる見出しとの対応関係を示す情報と、作業プロセスのプロセス単位とされる状態ごとに、前記設計原理モデルのフェーズモデルまたは該フェーズモデルのデータとの対応関係を示す情報とが含まれ、
タスク導出手段は、文書プロセスに関する情報からプロセス単位とされる設計文書を文書タスクとして導出し、作業プロセスに関する情報からプロセス単位とされる状態ごとの設計内容を作業タスクとして導出し、導出された各作業タスクの情報に、前記文書タスクとの対応関係を示す情報および前記設計原理モデルのフェーズモデルまたは該フェーズモデルのデータとの対応関係を示す情報を付与し、
影響タスク抽出手段は、フェーズモデルのデータが変更された場合に、各タスクに付与された前記設計原理モデルのフェーズモデルまたは該フェーズモデルのデータとの対応関係を示す情報に基づいて、前記影響タスクとして前記変更の影響のある作業タスクを抽出し、
進捗管理手段は、前記第１順序規則と、文書タスクが対応する第２順序規則とに基づいて、作業プロセスにおける作業タスクの進捗状況を更新し、
表示手段は、作業プロセスにおける作業タスクの進捗状況を、前記影響タスクとして抽出された作業タスクの情報および該作業タスクに対応する文書タスクの情報とともに表示する
請求項２に記載の設計支援装置。
【請求項６】
表示手段は、作業プロセスに含まれる全ての作業タスクを、プロセスグループごとに、当該プロセスグループにおける第２順序規則に沿って並べるとともに、達成状態の作業タスクと未達成状態の作業タスクとで領域を区別して表示することによって、作業プロセスにおける作業タスクの進捗状況を表示する
請求項５に記載の設計支援装置。
【請求項７】
設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報を予め記憶しておき、
開発現場における設計プロセスである現場プロセスに関する情報であって、前記現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、前記プロセス単位と前記フェーズとの対応関係を示す情報とを含む開発プロセス情報を入力し、
前記設計原理モデル情報と、前記開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出し、
前記第１順序規則と、前記第２順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記タスクの進捗状況を更新し、
前記タスクの進捗状況を表示する
ことを特徴とする設計支援方法。
【請求項８】
フェーズモデルのデータが変更された場合に、前記第１順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記変更の影響のあるタスクである影響タスクを抽出し、
タスクの進捗状況を更新する際に、変更前のカレントタスクと、前記影響タスクとに基づいて、現在の作業対象とされるタスクであるカレントタスクを更新する
請求項７に記載の設計支援方法。
【請求項９】
設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報にアクセス可能なコンピュータに、
開発現場における設計プロセスである現場プロセスに関する情報であって、前記現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、前記プロセス単位と前記フェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する処理、
前記設計原理モデル情報と、前記開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出する処理、
前記第１順序規則と、前記第２順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記タスクの進捗状況を更新する処理、および
前記タスクの進捗状況を表示する処理
を実行させるための設計支援プログラム。
【請求項１０】
設計原理モデル情報にアクセス可能なコンピュータに、
フェーズモデルのデータが変更された場合に、前記第１順序規則と、各タスクが対応するプロセス単位と前記フェーズとの対応関係とに基づいて、前記変更の影響のあるタスクである影響タスクを抽出する処理を実行させ、
タスクの進捗状況を更新する処理で、変更前のカレントタスクと、前記影響タスクとに基づいて、現在の作業対象とされるタスクであるカレントタスクを更新させる
請求項９に記載の設計支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスシステムの開発における上流設計を支援する設計支援装置、設計支援方法および設計支援プログラムに関する。
【背景技術】
【０００２】
新規サービスシステムの開発における顧客要件の探索からシステムの概念設計までの上流設計は、仮説と検証による繰り返し作業である。そのような上流設計の実践は、企画部や設計部などの一部のエキスパートの能力や経験に依存して行われていた。
【０００３】
しかし、一部のエキスパートだけでなく開発現場の一般エンジニアでも上流設計を行えるようにすることが望まれている。
【０００４】
そこで、上流設計のプロセスをモデル化することが考えられている。上流設計のモデリング手法として、例えば、ペルソナ（Persona）やカスタマージャーニーマップ（customer Journey Map）やエクスぺリンスマップ（experience Map）やサービスブループリント（Service Blueprint）などが挙げられる。
【０００５】
また、開発の進捗を支援する手法として、アジャイル開発手法と呼ばれる手法がある（非特許文献１，２参照）。アジャイル開発手法は、反復（イテレーション）と呼ばれる短い開発期間単位を採用することで、ソフトウェアの開発を迅速かつ適応的に支援する開発手法である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】金丸真之、“第１回アジャイル開発（前編）”、［online］、ＮＥＣ情報システムズ、［平成２８年８月１０日検索］、インターネット＜URL：http://www.nec-nis.co.jp/ja/column/01_agile.html＞
【非特許文献２】金丸真之、“第２回アジャイル開発（後篇）”、［online］、ＮＥＣ情報システムズ、［平成２８年８月１０日検索］、インターネット＜URL：http://www.nec-nis.co.jp/ja/column/02_agile.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、上記のようなモデリング手法は、上流設計の全体のプロセスのうちの一部の過程に対する支援しかできず、例えばプロセス全体を管理することはできない。また、繰り返し作業に適した開発手法は、開発現場での実践が困難であるという課題がある。
【０００８】
開発現場の多くでは、ＳＩ（System Integration）を対象としたウォーターフォール型の開発手法を用いて、システム開発を行うことが多い。一方、上流設計では、顧客要求が段階的に確定することや、ビジネス面や技術面の制約から概念設計の見直しが発生するなど、仮説と検証の繰り返しによる漸次的開発となる。このように、開発現場でこれまでに培われてきたウォータフォール型の開発プロセスと、上流設計における設計プロセスとの親和性が低いことが、開発現場での上流設計の実践を妨げる大きな原因となっている。
【０００９】
また、開発現場では、レビュー可能な文書を用いて内容確認や進捗管理を行うなど、文書をベースに開発を行うことが多い。このような文書ベースの開発では、上流設計の全体工程を管理することが困難である。なお、このような文書ベースの開発に対してアジャイル開発手法を適用できれば、繰り返し作業の進捗を管理することは可能である。しかし、その適用方法は確立されておらず、例えば、イテレーションをどのように区切るのか、また文書には表れてこない上流設計の作業やモデリング手法との関係などといった事項をアジャイル開発手法に組み込むための具体的方法などは、一部のエキスパートが現場ごとに対応しているのが現状である。
【００１０】
すなわち、制約条件として、現場ではプロジェクト管理に文書が必須であるが、ウォータフォール型の開発の場合、これらの文書（設計文書）と担当者の役割に応じたタスクとの関係は一意的であった。この為、これらの関係を管理する仕組みは特に必要なかったが、上流設計のような漸次的開発の場合、段階的に要求や機能や構造が固まることもあって、設計段階ごとにタスクの内容が異なりうる。したがって、上流設計では、設計文書とタスクとの関係は流動的になるが、このような設計文書とタスクとの関係は明らかにされていないというのが第１の課題である。さらに、そのような担当者の役割に応じた各タスクの実行が、設計工程全体において統制がとれているか、すなわちあらゆる人工物に共通して見られる一般的な設計プロセスに沿って行われているかまでを考慮することが困難である。すなわち、タスクと一般的な設計プロセスとの関係が明らかにされていないというのが第２の課題である。
【００１１】
一般エンジニアが上流設計を行えるようになるためには、担当者の漸次的開発における役割に応じたタスクを、あらゆる人工物に共通して見られる一般的な設計プロセスに従う規律を与えつつ、現場の設計文書と関連づけて管理する仕組みを提供するのが有効であると考えられる。しかしながら、現場での設計文書を中心としたプロジェクト進行管理と、担当者の漸次的開発における役割に応じたタスクの進行管理と、設計プロセスの原理・原則とを対応づけて管理する機構は現状では存在していない。
【００１２】
そこで、本発明は、一般エンジニアに向けた上流設計の支援が可能な設計支援装置、設計支援方法および設計支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明による設計支援装置は、設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報を記憶する設計原理モデル記憶手段と、開発現場における設計プロセスである現場プロセスに関する情報であって、現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、プロセス単位とフェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する開発プロセス情報入力手段と、設計原理モデル情報と、開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出するタスク導出手段と、第１順序規則と、第２順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、タスクの進捗状況を更新する進捗管理手段と、タスクの進捗状況を表示する表示手段とを備えたことを特徴とする。
【００１４】
本発明による設計支援方法は、設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報を予め記憶しておき、開発現場における設計プロセスである現場プロセスに関する情報であって、現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、プロセス単位とフェーズとの対応関係を示す情報とを含む開発プロセス情報を入力し、設計原理モデル情報と、開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出し、第１順序規則と、第２順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、タスクの進捗状況を更新し、タスクの進捗状況を表示することを特徴とする。
【００１５】
本発明による設計支援プログラムは、設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報にアクセス可能なコンピュータに、開発現場における設計プロセスである現場プロセスに関する情報であって、現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、プロセス単位とフェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する処理、設計原理モデル情報と、開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出する処理、第１順序規則と、第２順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、タスクの進捗状況を更新する処理、およびタスクの進捗状況を表示する処理を実行させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、一般エンジニアでも上流設計を行うことが可能になる。
【図面の簡単な説明】
【００１７】
【図１】設計原理モデルの例を示す説明図である。
【図２】設計インスタンスの例を示す説明図である。
【図３】モデルチェーンの基となるフェーズモデルとその相互関係の例を示す説明図である。
【図４】関心事マップの例を示す説明図である。
【図５】本発明が用いるモデル間の相互関係の例を示す説明図である。
【図６】文書ベースのプロセス管理からタスクベースのプロセス管理への変換例を示す説明図である。
【図７】表示方法の例を示す説明図である。
【図８】表示方法の例を示す説明図である。
【図９】第１の実施形態の設計支援装置の例を示すブロック図である。
【図１０】第１の実施形態の設計支援装置の動作の一例を示すフローチャートである。
【図１１】第１の実施形態の設計支援装置の動作の一例を示すフローチャートである。
【図１２】第１の実施形態の設計支援装置の一実施例を示すブロック図である。
【図１３】本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。
【図１４】本発明の概要を示すブロック図である。
【図１５】本発明による設計支援装置の他の構成例を示すブロック図である。
【発明を実施するための形態】
【００１８】
まず、本発明の技術コンセプトを説明する。上流設計のような漸次的開発では、企画担当者や設計担当者などが、抽象から具体化へといった設計原理に基づき、要求の探索、要求に基づく構成の設計、構成に基づく提供プロセスの設計を行う。このような上流設計を支援するためには、上流設計における基本的なプロセスをモデリングにより形式化し、そこで用いるモデルを共通言語として、仮説と検証を繰り返していくのが有効である。
【００１９】
本発明では、設計原理に基づき、上流設計のプロセスを形式化した設計原理モデルを予め用意しておき、設計原理モデルにおける各過程（フェーズ）に対して共通言語とするモデルを定める。
【００２０】
図１は、設計原理モデルの例を示す説明図である。図１に示す設計原理モデルは、「要求」、「機能」および「構造」を主要なフェーズとして含み、そのようなフェーズ単位で仮説と検証を繰り返す設計プロセスを形式化した例である。図１に示す設計原理モデルでは、「要求」フェーズから「機能」フェーズへ、「構造」フェーズから「構造」フェーズへといった抽象から具体化への順方向の矢印だけでなく、各フェーズからそれよりも上流のフェーズへと戻る逆方向の矢印を付与することによって、仮説と検証を繰り返す設計プロセスが表現されている。また、各フェーズには、当該フェーズに対応するモデリング手法を示す情報が付与されている。なお、「要求」フェーズは「要求探索」フェーズの略である。また、「機能」フェーズは「機能設計」フェーズの略である。また、「構造」フェーズは「構造設計」フェーズの略である。
【００２１】
ここで、「要求」は顧客の要求を表す。「機能」は「要求」を実現するために必要なサービスシステムの機能その他機能的な要素（チャネル、リソース等）を表す。「構造」は「機能」を実装するためのサービスシステムの構造を表す。
【００２２】
また、図２は、設計原理モデルのインスタンスである設計インスタンスの例を示す説明図である。本発明では、様々な開発現場に対応するため、設計原理モデルのオブジェクトとして、設計インスタンスを保持、管理する。設計インスタンスは、設計原理モデルの各フェーズと、現場での具体的なデータとを対応させたものであればよい。設計インスタンスは、例えば、設計原理モデルの各フェーズの共通言語に設定されたモデル（以下、フェーズモデルと呼ぶ）の各々に、具体的なデータを当てはめる（登録する）ことによって生成してもよい。以下、設計原理モデルのフェーズモデルの各々に具体的なデータを当てはめることを設計原理モデルの実体化と呼ぶ場合がある。設計原理モデルの実体化には、フェーズモデルに対してデータを当てはめるだけでなく、当てはめたデータ間の対応関係を付与することも含まれる。
【００２３】
データ間の対応関係は、例えば、要求モデルにおける要求名を、機能モデルにおける機能名に展開する場合に、モデル間の相互関係として要求項目と機能名とを対応付けることによって付与できる。例えば、要求から機能、機能からリソースへの落とし込みを行う第１のモデル、リソースの配置（空間的相互関係）を決定する第２のモデル、およびリソース間の提供プロセス（時間的相互関係）を決定する第３のモデルを用いる場合において、これらモデル間の相互関係は、「要求」→「機能」→「資源（リソース）」に転写を行う公理的設計に対応する。設計インスタンスにおけるデータ間の対応関係は、モデル間の相互関係に基づいて自動的に抽出してもよいし、ユーザに指定させてもよいし、フェーズモデルの実体データに相当するファイルからデータ要素名等を抽出し、名称の類似度などから自動的に抽出することも可能である。
【００２４】
このようにして、図２に示すような設計原理に基づいたモデルチェーンを構築する。
【００２５】
図３は、モデルチェーンの基となるフェーズモデルとその相互関係の例を示す説明図である。図３において、符号５０１は、第１のモデルの一例としてのＲＦＲ（requirement-function-resource）ツリーを表す。ＲＦＲツリーは、ユーザや顧客の要求を包括的に記述するとともに、それらの要求を実現するためにどのような種類の機能その他機能的要素が必要かを明確化するために用いられる。第１のモデルは、例えば“Ｗｈａｔ”や“Ｗｈｉｃｈ”をキーワードにサービスを分析することによって生成される。
【００２６】
また、符号５０２は、第２のモデルの一例としてのアクターズマップを表す。アクターズマップは、サービスの機能的な配信のために、利害関係者（人に限らず、物も含まれる）とＩＣＴモジュール（例えば、ソフトウェア、ハードウェアおよびネットワーク）との関係を記述するために用いられる。第２のモデルは、例えば“Ｗｈｏ”や“Ｗｈｏｍ”をキーワードにサービスを分析することによって生成される。
【００２７】
また、符号５０３は、第３のモデルの一例としてのサービスブループリントを表す。サービスブループリントは、サービスの配信手順、特にサービスが出会うユーザのフェーズと、各フェーズにおける機能の配信および行動のフローを記述するために用いられる。第３のモデルは、例えば“Ｗｈｅｎ”や“Ｈｏｗ”をキーワードにサービスを分析することによって生成される。
【００２８】
これらのモデルは互いに独立ではなく、例えば、要求項目が機能名に変換されたり、機能名がリソースやチャネルに展開されるなど、相互に関係している。このようなモデル間の相互関係に基づいて、設計原理モデルにおけるモデルチェーンを構築してもよい。
【００２９】
以下は、上流設計の手順の一例である。
（１）顧客の課題の観察
（２）クライアントの理想的な行動を記述する
（３）エクスペリエンスマップを用いて、上記行動を実現するための解決策を概念化する
（４）ペルソナシナリオを用いて、ユーザの理想的な行動を設計する
（５）ＲＦＲツリーを用いて、要件を明確化するとともに、上記の要件を機能およびリソースに書き換える（機能設計）
（６）アクターズマップを用いて、上記の機能やそれらの間の機能的な関係を提供するためのエンティティ（実体）を設計する
（７）サービスブループリントを用いて、機能の配信手順を設計する
（８）概念設計を完了し、概念実証のためのトライアルを開始する
【００３０】
上記の例では、ステップ（１）〜（４）が「要求」フェーズに対応する。また、ステップ（５）が「機能」フェーズに対応する。また、ステップ（６）〜（７）が「構造」フェーズに対応する。なお、ステップ（８）はフェーズ間の矢印に対応する。また、各フェーズには、対応するモデルのデータから、要求、機能、利害関係者に関する事項や配信手順等のレビューに必要な内容を文書化する作業も含まれる。また、上流設計には、このようなシステムの概念設計以外にも、ビジネスボリュームの決定やサービス配信計画、セールス計画なども含まれうる。なお、このような詳細な項目に関しては、設計インスタンスを生成する際に新たなフェーズを設けたり、各フェーズにおける達成条件として別途作業項目として定めることによって対応可能である。なお、新たなフェーズとして設ける場合には、基本的なフェーズと同様、他のフェーズとの関係と、設計内容を記述する方法（モデル）とを定めた上で、実体化の際にモデル間のデータの対応関係を設定することで、設計原理モデルのモデルチェーンに組み込むことができる。
【００３１】
このようにして、設計原理モデルの各フェーズの成果物として、フェーズモデルの成果物であるモデルデータ（ツリー構造図、ネットワーク図およびタイミングチャート等）と、モデルデータ間の対応関係とが設定されれば、モデルデータの変更や追加等に伴う影響範囲を設計原理モデルに沿って決定できる。
【００３２】
例えば、ペルソナシナリオが「要求」フェーズの成果物とされ、ツリー構造図が「機能」フェーズの成果物とされ、ネットワーク図およびタイミングチャートが「構造」フェーズの成果物とされた場合に、それらのモデルデータ間の対応関係として、例えば、ペルソナシナリオにおける要求項目Ａがツリー構造図の機能ＡＡに対応し、ツリー構造図の機能ＡＡが、ネットワーク構造図のブロックＡＡＡおよびタイミングチャートのフローＡＡＡＡに対応する等が設定されていたとする。ここで、ツリー構造図の機能ＡＡが変更となった場合、設計原理モデルの順方向の流れから、下流フェーズの対応モデルデータであるネットワーク構造図のブロックＡＡＡおよびタイミングチャートのフローＡＡＡＡに影響があると判定できるだけでなく、上流フェーズの対応モデルデータであるペルソナシナリオの要件項目Ａにも影響があると判定できる。上流フェーズに対する影響は、具体的には、機能ＡＡの変更によっても要件項目Ａが満たされているか否かを確認するといった作業や、要求フェーズで作成した文書内の要件項目Ａに関する部分を改訂する必要があるといった作業などである。
【００３３】
しかし、設計原理モデルに基づいてデータの影響範囲を特定して示すだけでは、ユーザが漸次的開発における具体的なプロセスやそれらの進捗を把握することは難しい。そこで、本発明では、さらに、漸次的開発における作業の見通しを良くして、進捗管理を容易にするために、設計インスタンスに対応づけられたタスクを用いて、進捗管理を行う仕組みを提供する。本発明において、タスクは、上流設計においてすべきことを所定の単位で表現したものである。換言すると、本発明では、上流設計の全プロセスを所定の方法で分割したものを、タスクと表現する。タスクの導出は、例えば、予め用意しておいた関心事マップに基づいて行うことができる。関心事マップは、上流設計における関心事を、様々立場における様々な状態別に示す情報である。関心事を、例えば、設計プロセスを次の段階に進めるための条件と読み替えてもよい。
【００３４】
図４は、関心事マップの例を示す説明図である。図４に示す例は、上流設計における関心事を、その主体や目的に対応するアクタ単位でピックアップし、さらにアクタごとに、複数の状態に分けて示した例である。アクタの分類は、例えば、顧客側や企画側や実装側や提供側といった立場に応じて行われてもよいし、さらに各立場における物理的な制約や要件の違いなどに基づいて行われてもよい。なお、アクタには、人だけでなく、物や技術や事象なども含まれる。また、状態の分類は、例えば、それら関心事の達成進度やタイミングの違いなどに基づいて行われていもよい。なお、アクタごとに状態数が異なっていてもよい。例えば、図４において、顧客側の利害関係者に対応するアクタＡの観点からの関心事は、「認定」、「表現」、「関与」、「合意」、「展開の満足」、「使用時の満足」の６つの状態に分けられているのに対して、実装側の要件に対応するアクタＢの観点からの関心事は、「考案」、「境界」、「コヒーレント」、「受諾」、「対処」、「成就」の６つの状態に分けられている。
【００３５】
このような関心事マップは、例えば、予めサービス化する分野や顧客の種類別に、標準的な関心事をアクタ別および状態別に記憶した関心事モデルを用意しておき、ユーザがそのうちの１つの関心事モデルに具体的なデータを当てはめることによって生成できる。
【００３６】
タスクの導出は、このようにして生成された関心事マップにおける関心事の最小グループ、すなわちアクタおよび状態によって分割された関心事のグループ（図中の破線で囲った単位）の各々を１つのタスクとして抽出することにより行ってもよい。また、タスクの導出は、関心事マップに含まれる関心事の最小単位すなわち関心事の各々を１つのタスクとして抽出することにより行ってもよい。
【００３７】
図４に示すように、本発明の関心事マップでは、関心事マップにおける順序規則が設定されるプロセスの単位に相当する状態の各々に対して、関連するフェーズモデルを割り当てる。関連するフェーズモデルは、例えば、その状態内の関心事を達成した際に結果が反映されるフェーズモデルや、そのグループ内の関心事を達成する際にレビューが必要な成果物に相当するモデルデータを有するフェーズモデルであればよい。
【００３８】
このような設計時における関心事の最小グループまたは最小単位をタスクとして導出し、各タスクに設計原理モデルのフェーズモデルを対応づけることによって、各タスクを設計原理モデルに基づいて制御、管理することを可能にする。
【００３９】
すなわち、関心事やレビュー内容に着目してタスクを導出しただけでは、次に何をすべきかといった順序関係の見通しが悪い。このため、本発明では、さらに各タスクに対して設計原理モデルにより規律（順序関係の制約）を与えることで順序関係の見通しを良くする。より具体的には、設計インスタンスが有する設計原理モデルの各フェーズに対応したモデルデータとタスクとを対応づけることにより、タスクベースの進捗管理において、各タスクに対して関心事マップにおける状態に基づく規律に加えて、設計原理モデルに基づく規律を与える。
【００４０】
なお、タスクの導出は上記の関心事マップに基づく方法に限られない。例えば、上流設計で必要とされるレビューにおけるレビューイとレビュー目的の組み合わせに基づいてタスクの導出を行ってもよい。この場合、レビューイが上記のアクタに対応し、レビュー目的が上記の状態に対応し、各レビューに必要な事項を決定することが各関心事に相当する。その場合、レビューに必要な成果物を作成するために必要なデータを保持するモデルが関連するフェーズモデルとなる。また、例えば、ユーザが直接、タスクに関する情報（タスク内容、タスク間の順序規則および関連するフェーズモデルの情報等）を入力してもよい。
【００４１】
さらに、本発明では、タスクと開発文書とを対応づけることにより、タスクベースの進捗管理に付加して、文書ベースの進捗管理も可能にする。より具体的には、現場との親和性の高い文書ベースの設計プロセスに対して、設計原理モデルに基づく規律と、ユーザが次にどのような行動をとればよいのかといった情報を提示可能にする。
【００４２】
図５は、本発明が用いるモデル間の相互関係の例を示す説明図である。図５には、開発文書の作成プロセスのモデルである文書プロセスモデルのインスタンスと、関心事モデルのインスタンスである関心事マップと、設計原理モデルのインスタンスである設計インスタンス間の相互関係の例が示されている。図５によれば、例えば、設計インスタンスのフェーズまたはフェーズ内のモデルデータと、関心事マップのアクタグループが有する状態または状態内のモデルデータ（関心事）との間にリンク（対応関係）が設定されている。また、例えば、関心事マップのアクタグループが有する状態または状態内のモデルデータと、文書モデルのインスタンスの文書または文書内のモデルデータ（項目や任意のブロック等）との間にリンクが設定されている。
【００４３】
このように、本発明では、文書による管理を制約条件としつつ、上流設計における繰り返し作業を管理するために、担当者の役割に応じた関心事や作業内容に対してタスクという概念を導入する。かつ、それらタスクのかたまりを状態の達成度とし、各タスクの状態を、文書と対応づけて管理する。その上で、各タスクの実行が設計原理に沿って行われるように、各タスクと設計原理モデルのフェーズまたはそのインスタンスとを対応づけて、設計原理モデルによる規律を与える。これにより、各タスクに対して繰り返し作業における関連性だけでなく、抽象から具体化へという設計原理に基づく関連性を与えることができる。
【００４４】
本発明では、このような大きく３つの観点（文書、役割に応じた関心事や作業、設計原理）に基づくプロセスを構造化してそのデータ構造として少なくとも順序規則を示す情報を保持し、さらに各観点での順序規則の単位とされるプロセス同士の対応関係を示す情報を保持することによって、これら観点での作業内容および順序規則とを統合した進捗管理を可能にする。
【００４５】
一例として、例えば、文書のアンカー（見出し）とタスクとの対応関係を示す文書アンカータスク情報を記憶しておいてもよい。文書アンカータスク情報は、例えば、ユーザが現場に応じた関心事モデルのインスタンスと、文書プロセスモデルのインスタンスとを生成した際に、各文書の各アンカーについて、関連するタスクを関心事モデルのインスタンスから導出されタスク一覧の中から選択させることによって生成できる。
【００４６】
また、タスクと設計原理モデルのフェーズモデルとの対応関係は、予め関心事モデルに登録しておいてもよい。また、文書プロセスモデルのインスタンスは、一連の開発文書の順序付きリストであってもよい。
【００４７】
このようにして、設計原理とタスクと文書とを対応づけることにより、タスクベースでの進捗管理だけでなく、設計内容の変更により影響する文書を、設計原理に基づいて導出することができる。
【００４８】
図６は、文書ベースのプロセス管理からタスクベースのプロセス管理への変換例を示す説明図である。図６に示すように、文書プロセスモデルの各フェーズに対応するプロセス（本例の場合、成果物とされる開発文書またはそのアンカー）に、関心事マップ等から導出したタスクを関連づけることにより、文書プロセスモデルのプロセスを、設計原理に規律されるタスクベースのプロセスに変換できる。
【００４９】
例えば、実証段階で要求や機能や構造に変更が生じた場合、設計原理モデルの共通言語とされたフェーズモデルのモデルデータが変更されることになる。そのような場合に、本発明は、設計原理モデルのフェーズモデル間の相互関係に基づいて、該変更の影響を受ける他のフェーズのモデルデータを導出する。次いで、関心事マップ等から予め導出しておいたタスクとフェーズモデルとの対応関係に基づいて、変更されたモデルデータに対応するタスクに加えて、変更の影響を受けるとして導出されたモデルデータに対応するタスクを導出する。そして、導出されたタスク群に基づいて、現在の作業対象とされるタスクであるカレントタスクを更新する。例えば、導出されたタスク群に変更前のカレントタスクよりも上流に位置するタスクが含まれていた場合に、カレントタスクを最も上流に位置するタスクに変更すればよい。このようにして、カレントタスクを設計原理に基づいて変更するとともに、変更後のカレントタスクの情報をユーザに提供する。
【００５０】
また、本発明では、変更の影響を受けるタスクが導出されると、該タスクに対応する文書またはそのアンカーの情報をユーザに提供する。
【００５１】
表示方法としては、カレントタスクやカレント文書を強調して表示する方法や、タスクベースおよび文書ベースで全体の工程を表示する中に変更の影響のあるタスクや文書を強調して表示する方法などが挙げられる。
【００５２】
図７および図８は、表示方法の例を示す説明図である。図７に示す例では、タスクベースで全体プロセスを表示する中に、アクタごとに達成したタスク群と未達成のタスク群とを領域を分けて表示することにより、各アクタのカレントタスクを強調している。なお、タスクベースでの各アクタのタスクの順序は、関心事モデルの状態順である。例えば、アクタ１のデータの変更前のカレントタスクがタスク５であったとしても、データの変更による影響範囲にタスク３が含まれていた場合には、タスク３に戻り、再度タスク３→タスク４→タスク５という順序で設計を行う必要があることがわかる。また、図７では、カレントタスク以外にも変更の影響のあるタスクを網掛けで表示している。このようにすることにより、網掛け表示されたタスクには、上流フェーズのやり直しによる影響だけでなく、やり直しの基となったデータの変更による影響があるといった注意喚起を行うことができる。
【００５３】
また、図８に示す例では、タスクベースでの全体プロセスの表示と併せて、文書ベースでの全体プロセスを表示し、かつその表示中に、データの変更に影響のある文書を強調して表示している。なお、図８における“タスク１−１”との表記は、アクタ１のタスク１を表している。
【００５４】
ユーザは、例えば、カレントタスクとされたタスクに対応する関心事の内容や関連するフェーズモデルを関心事マップで確認することにより、設計作業の漏れや見落としをすることなく、上流設計における漸次的開発を進めることができる。
【００５５】
以下、図面を参照して本発明の実施形態を説明する。
【００５６】
実施形態１．
図９は、本発明の第１の実施形態の設計支援装置の例を示すブロック図である。図９に示す設計支援装置１００は、開発プロセス情報入力部１１０と、ドキュメントマイルストン抽出部１２０と、タスク導出部１３０と、設計インスタンス情報入力部１４０と、タスク記憶部２３０と、設計原理モデル記憶部２１０と、設計インスタンス記憶部２２０と、影響タスク抽出部１５０と、進捗管理部１６０と、表示部１７０とを備える。
【００５７】
開発プロセス情報入力部１１０は、開発現場における設計プロセスに関する情報である開発プロセス情報を入力する。開発プロセス情報は、例えば、開発現場における設計プロセスを単純化したモデルに具体的なデータを登録したものであってもよい。例えば、開発プロセス情報は、上述した文書プロセスモデルのインスタンスの情報を含んでいてもよい。また、例えば、開発プロセス情報は、上述した関心事モデルのインスタンスの情報を含んでいてもよい。また、例えば、開発プロセス情報は、文書プロセスモデルや関心事モデル以外の他のウォータフォール型の開発モデルのインスタンスの情報を含んでいてもよい。例えば、開発プロセス情報は、設計プロセスにおける設計目標とその成果物（レビュー文書等）を、順序付きで示すレビューリスト情報であってもよい。また、開発プロセス情報は、ウォータフォール型の開発モデルのインスタンスの情報に限らず、開発現場での設計プロセスにおける順序規則の単位とされるプロセス単位ごとの設計内容と、それらの順序規則とを示す情報を含む情報であればよい。
【００５８】
また、開発プロセス情報は、モデルデータ同士の対応関係を示す情報を含む。ここでのモデルデータには、開発プロセス情報に含まれるモデルデータだけでなく、設計インスタンスのモデルデータが含まれうる。なお、開発プロセス情報には、設計インスタンスのモデルデータとの対応関係ではなく、設計原理モデルのフェーズモデルとの対応関係が含まれていてもよい。なお、開発プロセス情報に複数種類のモデルのインスタンスの情報が含まれる場合には、そのうちの１つのモデルで、プロセス単位ごとに、設計原理モデルのフェーズモデルまたはそのデータとの対応関係を示す情報が含まれていればよい。例えば、開発プロセス情報が、文書プロセスモデルのインスタンスの情報と、関心事モデルのインスタンスの情報とを含む場合であって、それらのモデル間でモデルデータ同士の対応関係を示す情報が含まれている場合には、文書プロセスモデルにおけるプロセス単位または関心事モデルにおけるプロセス単位のいずれか一方のプロセス単位を対象に、設計原理モデルのフェーズモデルまたはそのデータとの対応関係を示す情報が含まれていればよい。
【００５９】
開発プロセス情報入力部１１０は、例えば、後述する設計原理モデル記憶部２１０に記憶されている設計原理モデルの情報を提示して、ユーザに、開発プロセス情報に含まれるプロセス単位の各々について、設計原理モデルのフェーズモデルとの対応関係を指定させてもよい。
【００６０】
ドキュメントマイルストン抽出部１２０は、開発プロセス情報入力部１１０が入力した情報から、開発文書に関連するマイルストン（工程上の区切り）であるドキュメントマイルストンを抽出する。また、ドキュメントマイルストン抽出部１２０は、ドキュメントマイルストンの抽出とともに、各ドキュメントマイルストンにおいて必要とされる開発文書の情報を抽出する。
【００６１】
ドキュメントマイルストン抽出部１２０は、例えば、開発プロセス情報に含まれる文書プロセスモデルのインスタンスに含まれる、文書プロセスモデルのフェーズに関する情報（例えば、フェーズ数と各フェーズの識別子）および各フェーズに対応づけられた開発文書の情報（例えば、文書名）を抽出してもよい。また、ドキュメントマイルストン抽出部１２０は、例えば、開発プロセス情報に含まれるレビューリスト情報から、成果物が割り当てられた設計目標間を１つのフェーズとみなして、フェーズ数と各フェーズの識別子とレビュー文書の情報とを抽出してもよい。
【００６２】
タスク導出部１３０は、開発プロセス情報と、ドキュメントマイルストンと、設計原理モデルの情報または設計インスタンスの情報に基づいて、設計原理モデルによる規律対象とするタスクを導出する。以下、タスク導出部１３０が導出する、設計原理モデルによる規律対象とするタスクをモデリングタスクと呼ぶ場合がある。
【００６３】
タスク導出部１３０は、少なくとも開発プロセス情報において順序規則が設定されているプロセス単位以下の単位の設計プロセスに関する情報であって、設計原理モデルのフェーズモデルと対応づけられている設計プロセスに関する情報を、モデリングタスクとして導出すればよい。
【００６４】
タスク導出部１３０は、例えば、タスク導出部１３０は、開発プロセス情報に含まれる文書プロセスに関する情報から、ドキュメントマイルストンで区切られたフェーズに対応する文書プロセスに関する情報の各々を、モデリングタスクとして導出してもよい。以下、文書プロセスに対応するモデリングタスクを、文書タスクという場合がある。
【００６５】
また、タスク導出部１３０は、例えば、開発プロセス情報に含まれる関心事に関する情報から、アクタ別および状態別の関心事グループの情報を、モデリングタスクとして導出してもよい。また、タスク導出部１３０は、開発プロセス情報に含まれる関心事に関する情報から、各関心事の情報を、モデリングタスクとして導出してもよい。また、タスク導出部１３０は、モデリングタスクの導出とともに、導出したモデリングタスク間の対応関係（特に、順序規則）を抽出する。以下、文書タスク以外のモデリングタスクを、作業タスクという場合がある。
【００６６】
なお、開発プロセス情報には、一連のプロセスに関する情報が複数含まれていてもよく、例えば、文書プロセスと、関心事プロセスとを互いに独立のプロセスグループであるとして、プロセスグループごとに、プロセスに関する情報が含まれていてもよい。また、関心事プロセスであっても、アクタごとの関心事は互いに独立のプロセスグループであるとしてもよい。このような場合には、タスク導出部１３０は、独立したプロセスグループごとに、モデリングタスク間の順序規則を抽出すればよい。
【００６７】
タスク記憶部２３０は、タスク導出部１３０が導出したモデリングタスクに関する情報を記憶する。タスク記憶部２３０は、例えばモデリングタスクの識別子に対応づけて、モデリングタスクの種別や、対応する開発プロセス情報へのリンク情報（アドレス等）や、順序規則等を記憶する。
【００６８】
設計原理モデル記憶部２１０は、設計原理モデルの情報を記憶する。設計原理モデル記憶部２１０は、設計原理モデルの情報として、当該モデルが有するフェーズやフェーズ間の順序規則や、各フェーズの共通言語とされるモデルであるフェーズモデルの情報等を記憶してもよい。なお、１つのフェーズに割り当てられるフェーズモデルは複数であってもよい。また、フェーズに割り当てられたフェーズモデルの全てが現場で採用されなくてもよく、ユーザによる取捨選択を可能とする。
【００６９】
設計インスタンス情報入力部１４０は、設計インスタンスに関する情報を入力する。設計インスタンス情報入力部１４０は、設計インスタンスの情報を直接入力してもよいし、例えば、設計原理モデル記憶部２１０に記憶されている設計原理モデルの情報に基づいて、ユーザに、フェーズモデルの具体的なデータ（モデルデータ）やモデルデータ間の対応関係を入力させて設計インスタンスを生成してもよい。
【００７０】
設計インスタンス記憶部２２０は、設計インスタンスの情報を記憶する。
【００７１】
影響タスク抽出部１５０は、設計の任意の時点で設計内容に変更があった場合に、設計原理モデルの順序規則および設計インスタンスのモデルデータ間の相互関係に基づいて、該変更の影響範囲に含まれるモデリングタスクを抽出する。以下、影響タスク抽出部１５０が抽出したモデリングタスクを、影響タスクと表現する場合がある。
【００７２】
進捗管理部１６０は、タスク記憶部２３０に記憶されているモデリングタスクに関する情報に基づいて、タスクを単位にした進捗管理を実行する。進捗管理は、タスクの進行度を随時更新することによって行われる。進捗管理部１６０は、例えば、開発プロセス情報において順序が規定されるプロセスのグループであるプロセスグループごとに、モデリングタスクを、それらの順序規則に沿ってチェーンでつないで、順次達成状態を更新することによって進捗管理を行ってもよい。例えば、進捗管理部１６０は、プロセスグループ内の未達成状態のモデリングタスクのうち最も早い順番に位置するモデリングタスクをカレントタスクとし、該カレントタスクに対して達成した旨の情報が入力された場合に、次に位置するモデリングタスクをカレントタスクとして更新する等によって、進捗管理を行ってもよい。
【００７３】
また、進捗管理部１６０は、設計の任意の時点で設計内容に変更があった場合には、変更前のカレントタスクと、影響タスクとに基づいて、カレントタスクを設定しなおす等によって進捗状況を更新する。このとき、カレントタスクが対応するデータに対して、異なるプロセスグループのモデリングタスクのデータと対応関係が設定されている場合には、さらに該対応関係に基づいて、カレントタスクを設定しなおす。
【００７４】
例えば、進捗管理部１６０は、プロセスグループごとに、影響タスクに変更前のカレントタスクよりも上流に位置するモデリングタスクが含まれているか否かを判定し、含まれている場合には最も上流に位置するモデリングタスクを当該プロセスグループのカレントタスクに設定する。さらに、進捗管理部１６０は、第１のプロセスグループの設定後のカレントタスクが、他のプロセスグループのカレントタスクよりも上流に位置するモデリングタスクとの間にデータの対応関係にあった場合に、対応関係にあるモデリングタスクを第２のプロセスグループのカレントタスクに設定してもよい。なお、進捗管理部１６０は、プロセスグループを跨ぐカレントタスクの更新は行わずに、変更の影響がある旨を登録するだけであってもよい。これにより、設計原理モデルを基に、モデリングタスクを経由して影響のある文書や関心事を特定することができる。
【００７５】
表示部１７０は、進捗管理部１６０によって更新されるモデリングタスクの進捗状況を、ユーザに表示する。表示部１７０は、例えば、プロセスグループごとに、達成済みのモデリングタスクと未達成のモデリングタスクとを区別可能に並べて配置することによって、進捗状況を提示してもよい。また、変更に伴って進捗状況が変化した場合や、変更の影響がある旨が登録されている場合には、その旨を表示したり、変化後のカレントタスクや変更の影響のあるモデリングタスクを強調表示してもよい。
【００７６】
このとき、表示部１７０は、変更の影響がある旨の登録先のモデリングタスクが、文書タスクである場合には、文書の更新が必要である旨や、変更対象の見出しの情報を表示してもよい。
【００７７】
次に、本実施形態の動作を説明する。図１０および図１１は、本実施形態の設計支援装置の動作の一例を示すフローチャートである。なお、図１０は、設計支援を開始する際の動作の例を示すフローチャートである。また、図１１は、設計内容に変更が生じた際の動作の例を示すフローチャートである。
【００７８】
まず、図１０を参照して、設計支援を開始する際の本実施形態の動作を説明する。図１０に示す例では、まず、開発プロセス情報入力部１１０が、開発プロセス情報を入力する（ステップＳ１１０）。
【００７９】
次に、ドキュメントマイルストン抽出部１２０が、開発プロセス情報から、開発文書に関連するマイルストンを抽出する（ステップＳ１１１）。
【００８０】
また、その一方で、設計インスタンス情報入力部１４０が、設計インスタンスに関する情報を入力する（ステップＳ１１２）。
【００８１】
次に、タスク導出部１３０が、開発プロセス情報と、ドキュメントマイルストンとに基づいて、モデリングタスクを導出する（ステップＳ１１３）。このとき、タスク導出部１３０は、開発プロセス情報と、ドキュメントマイルストンと、必要に応じて設計原理モデルおよび／または設計インスタンスに基づいて、モデリングタスクを導出してもよい。
【００８２】
モデリングタスクを導出すると、タスク導出部１３０は、導出したモデリングタスクに関する情報を、タスク記憶部２３０に記憶させる（ステップＳ１１４）。
【００８３】
以上のようなステップにより、進捗管理に用いるタスク（文書タスクや作業タスク等）に、現場での開発プロセス情報に基づく順序規則に加えて、設計原理モデルに基づく順序規則を付与できる。
【００８４】
次に、図１１を参照して、設計内容に変更が生じた際の本実施形態の動作を説明する。図１１に示す例では、進捗管理部１６０が、タスク記憶部２３０に記憶されているモデリングタスクに関する情報に基づいて、開発現場での設計プロセスにおける順序規則に沿って、タスクを単位にした進捗管理を実行している（ステップＳ１２０）。
【００８５】
このような状態において、設計内容に変更が生じたとする。
【００８６】
このとき、影響タスク抽出部１５０は、ユーザ入力等に応じて、変更内容に変更が生じたか否かを判定し、変更が生じたと判定した場合には（ステップＳ１２１のＹｅｓ）、該変更の影響範囲に含まれるモデリングタスク（影響タスク）を抽出する（ステップＳ１２２）。
【００８７】
次に、進捗管理部１６０は、変更前のカレントタスクと、影響タスクとに基づいて、進捗状況を更新する（ステップＳ１２３）。進捗管理部１６０は、具体的には、カレントタスクの更新や変更の影響範囲を設定する。そして、ステップＳ１２４に進む。
【００８８】
一方、ステップＳ１２１で、影響タスク抽出部１５０が変更が生じていないと判定した場合には（ステップＳ１２１のＮｏ）、特に処理を行わずに、ステップＳ１２４に進む。
【００８９】
ステップＳ１２４では、表示部１７０が、モデリングタスクの進捗状況を、ユーザに表示する（ステップＳ１２４）。
【００９０】
以上のようなステップにより、変更があった際に、進捗状況を、設計原理に基づく規律に沿って適切に更新できる。また、変更に影響のある作業や開発文書の改訂部分をユーザに提示できる。
【００９１】
このように、本実施形態は、開発現場での設計プロセスにおける関心事や実作業や設計目標や文書化作業の最小単位もしくはそれらの中で順序が規定される単位をタスクとして抽出し、抽出されたタスク単位で進捗管理を行うように構成されている。このため、現場の開発スキームに適合しやすく、かつ期待実施順が変更しやすい進捗管理手段を実現している。これにより、開発現場での設計プロセス（設計の仕方や文化等）に適合したサービスの設計を支援できる。
【００９２】
また、本実施形態は、そのようなタスクと、設計原理を単純化した設計原理モデルとを対応づけることにより、漸次的開発に対応した進捗管理手段を実現している。このため、出戻り作業が発生した場合であっても進捗状況を適切に更新できるので、ユーザに変更の影響のある作業を提示できる。また、本実施形態によれば、開発文書に関するプロセスから文書タスクを抽出し、文書タスクと設計原理モデルとの対応づけや、文書タスクと作業タスクとの対応づけを行っているので、設計内容に変更があった場合に、その変更の影響を受ける文書を特定し、改訂や見直しが必要な文書としてユーザに提示できる。
【００９３】
また、このように、文書と設計原理または文書と他の作業プロセスとを、一旦タスクに変換した上でタスクベースで対応づけることによって、開発現場ごとに設計プロセス（ドキュメント構成や関心事やレビュー内容やレビュー順序等）が異なっていても、その違いを適合させやすいため、開発現場に適合したサービスの設計プロセスの進捗を適切に管理できる。
【００９４】
図１２は、本実施形態の設計支援装置の一実施例を示すブロック図である。図１２には、開発プロセス情報として、文書プロセス情報と、作業プロセス情報と、文書−作業対応情報と、作業−原理対応情報とが入力される例が示されている。
【００９５】
本例の文書プロセス情報は、例えば、開発文書の順序付きリストであってもよい。文書プロセス情報は、例えば、｛事業企画書，要件定義書，機能仕様書，詳細設計書，テスト仕様書，テスト報告書｝といったように、作業順に並べられた文書名を含む情報であってもよい。なお、文書プロセス情報は、現場ごとに異なっていてもよい。
【００９６】
また、作業プロセス情報は、例えば、一連の設計プロセスにおける状態とその状態を達成するための作業項目とを示す情報の順序付きリストであってもよい。作業プロセス情報は、例えば、｛｛状態名，｛作業名＋｝｝，｛状態名，｛作業名＋｝｝，・・・｝といったように、作業順に並べられた、状態名と１つ以上の作業名の組を含む情報であってもよい。ここで｛作業名＋｝の“＋”は直前の要素が１つ以上含まれることを表している。
【００９７】
また、文書−作業対応情報は、文書プロセスと作業プロセスとを対応づける情報である。文書−作業対応情報は、例えば、文書プロセス情報におけるプロセス単位（上記の例では文書名）または該プロセス単位が含む要素（例えば、見出し名）と、作業プロセス情報におけるプロセス単位（上記の例では状態名）または該プロセス単位が含む要素（例えば、作業名）とを対応づける情報であってもよい。文書−作業対応情報は、例えば、｛（文書名．見出し名，状態．作業名）＋｝といったように、文書の見出しと作業とを対応づけた情報の一覧であってもよい。
【００９８】
作業−原理対応情報は、作業プロセスと設計原理とを対応づける情報である。作業−原理対応情報は、例えば、作業プロセス情報におけるプロセス単位（上記の例では状態名）または該プロセス単位が含む要素（例えば、作業名）と、後述する設計原理モデル情報におけるプロセス単位または該プロセス単位が含む要素とを対応づける情報であってもよい。文書−作業対応情報は、例えば、｛（状態，設計原理モデルのフェーズ）＋｝といったように、状態と設計原理モデルのフェーズ名（要件、機能、構造等）とを対応づけた情報であってもよい。また、文書−作業対応情報は、例えば、｛（状態，設計データファイル名）＋｝といったように、状態と、設計インスタンス情報において設計原理モデルのフェーズ名と対応づけられた設計インスタンスの情報である設計データファイル名とを対応づけた情報の一覧であってもよい。なお、｛（状態，設計データファイル名．データ要素名）＋｝というように、さらに設計データファイルに含まれるデータ要素を指定することも可能である。
【００９９】
また、本例の設計原理モデル記憶部２１０には、設計原理モデル情報が記憶される。設計原理モデル情報は、設計プロセスの原理を示す情報である。設計原理モデル情報は、｛（フェーズ名＋），（フェーズ名→フェーズ名）＋｝といったように、設計原理モデルが含むフェーズ名の一覧と、２フェーズ間の順序関係の一覧とを含む情報であってもよい。なお、設計原理モデル情報は、さらに｛｛フェーズ名｛フェーズモデル＋｝＋｝といったフェーズ名に対応づけられたフェーズモデルの一覧を含んでいてもよい。
【０１００】
また、本例の設計インスタンス情報入力部１４０には、設計インスタンス情報が入力される。設計インスタンス情報は、設計原理モデルが含む各フェーズについて、該フェーズが対応するモデル（フェーズモデル）のインスタンスの情報を含む情報である。設計インスタンス情報は、例えば｛｛フェーズ名｛設計データファイル名＋｝＋｝といったように、フェーズ名に対応づけられた設計データファイル名の一覧であってもよい。ここで、設計データファイル名は、そのフェーズ名が示すフェーズのフェーズモデルのいずれに対応した設計データを含むファイルのファイル名であるとする。
【０１０１】
また、本例のドキュメントマイルストン抽出部１２０は、文書プロセス情報においてプロセス単位とされる文書名の情報を基に、「事業企画書完了」，「要件定義書完了」，「機能仕様書完了」，「詳細設計書完了」，「テスト仕様書完了」，「テスト報告書完了」といったドキュメントマイルストンを抽出してもよい。また、ドキュメントマイルストン抽出部１２０は、各ドキュメントマイルストンにおいて必要とされる開発文書として、対応する文書名を抽出してもよい。
【０１０２】
また、本例のタスク導出部１３０は、文書プロセス情報とドキュメントマイルストンが抽出した文書名とから、文書タスクとして、「事業企画書タスク」，「要件定義書タスク」，「機能仕様書タスク」，「詳細設計書タスク」，「テスト仕様書タスク」，「テスト報告書タスク」を導出してもよい。また、その際、タスク導出部１３０は、これらの文書タスクの順序規則として、「事業企画書タスク」→「要件定義書タスク」→「機能仕様書タスク」→「詳細設計書タスク」→「テスト仕様書タスク」→「テスト報告書タスク」を導出する。なお、矢印は、矢印が示す方向での遷移が許可されることを表している。
【０１０３】
また、タスク導出部１３０は、作業プロセス情報から、作業タスクとして、プロセス単位である状態名に対応したタスクや、その要素である作業名に対応したタスクを導出してもよい。また、その際、タスク導出部１３０は、作業プロセス情報によって示される状態名に付与された順序規則を、その状態名に対応したタスクまたはその状態名の要素である作業名に対応するタスクに適用した順序規則を、作業タスクの順序規則として抽出する。例えば、状態名Ａ→状態名Ｂといった順序規則が作業プロセス情報により示されていた場合には、状態名Ａに対応する作業タスクＡ→状態名Ｂに対応する作業タスクＢといった順序規則が抽出される。
【０１０４】
また、本例のタスク記憶部２３０には、開発プロセス情報として入力された各種情報に加えて、導出された作業タスクの情報および文書タスクの情報が記憶される。
【０１０５】
また、本例の進捗管理部１６０は、タスク記憶部２３０に記憶された情報に基づいて、タスクを単位にした進捗管理を実行する。進捗管理部１６０は、例えば、文書タスク群に対して、それらの順序規則に基づく進捗管理を行えばよい。例えば、進捗管理部１６０は、順序規則において最初に位置する文書タスクである事業企画書タスクを最初のカレントタスクに設定し、ユーザから事業企画書の完了を示す情報が入力されたタイミングで、カレントタスクを次の文書タスクである要件定義書タスクに設定するといった進捗状況の更新処理を行ってもよい。
【０１０６】
なお、進捗管理部１６０は、文書タスクの完了条件に、ユーザから完了を示す情報の入力だけでなく、対応する作業タスクの完了を含めてもよい。すなわち、進捗管理部１６０は、ユーザからの完了を示す情報に加えて、文書−作業対応情報に基づいて、文書タスクのカレントタスクに対応づけられている全ての作業タスクが完了していた場合に、カレントタスクが完了したと判定してもよい。
【０１０７】
また、進捗管理部１６０は、例えば、作業タスク群に対して、それらの順序規則に基づく進捗管理を行う。例えば、進捗管理部１６０は、順序規則において最初に位置する作業タスクである状態Ａを最初のカレントタスクに設定し、ユーザから状態Ａに含まれる作業名の全てに対して完了を示す情報が入力されたタイミングで、カレントタスクを次の作業タスクである状態Ｂに設定するといった進捗状況の更新処理を行ってもよい。
【０１０８】
次に、本例において設計内容が変更された場合について説明する。例えば、あるタイミングで機能仕様の変更が生じたとする。より具体的には、設計原理モデルの機能フェーズに対応するフェーズモデルの設計データファイルが更新されたとする。
【０１０９】
本例の影響タスク抽出部１５０は、上記更新を検知すると、設計データファイル名から、変更先のフェーズ名を特定する。これにより、機能フェーズで変更が生じた旨が特定される。影響タスク抽出部１５０は、例えば、設計原理モデルの順序規則として｛機能フェーズ→構造フェーズ｝，｛機能フェーズ→要求フェーズ｝，・・・｝が登録されていた場合、変更の影響あるフェーズとして、構造フェーズと要求フェーズとを抽出する。このとき、影響タスク抽出部１５０は、設計インスタンス情報に設計データファイルのデータ要素間の対応関係が含まれている場合には、該対応関係に基づいて、変更の影響があるデータ要素を抽出してもよい。例えば、設計インスタンス情報において、変更先である機能フェーズに対応する設計データファイルＣのデータＤと、要求フェーズに対応する設計データファイルＥのデータＦとの間に対応関係が設定されている場合、変更の影響のあるデータ要素としてデータＦを抽出する。
【０１１０】
また、影響タスク抽出部１５０は、このようにして設計原理モデルに基づいて変更の影響のあるフェーズまたはデータ要素を特定すると、作業−原理対応関係情報に基づいて、特定されたフェーズまたはデータ要素と対応関係にある作業タスクを抽出する。例えば、作業−原理対応情報において、変更の影響のある要求フェーズと作業タスクＧとが対応づけられていた場合、作業タスクＢを影響タスクとして抽出する。また、例えば、作業−原理対応情報において、変更の影響のあるデータ要素Ｄと作業タスクＨとが対応づけられていた場合、作業タスクＨを影響タスクとして抽出する。
【０１１１】
進捗管理部１６０は、抽出された影響タスクと、各プロセスグループのカレントタスクとに基づいて、カレントタスクの更新および変更の影響のある作業タスクおよび文書タスクの特定を行う。例えば、影響タスクに含まれる最も上流に位置する作業タスクが作業タスクＨであって、作業タスクグループのカレントタスクがそれよりも下流工程に位置する作業タスクＢである場合には、作業タスクグループのカレントタスクを作業タスクＨに変更する。このとき、進捗管理部１６０は、カレントタスクが作業タスクＨに変更された場合であって、作業タスクＨと対応関係にある文書タスクが、文書タスクグループのカレントタスクよりも上流工程に位置していた場合には、その文書タスクを文書タスクグループのカレントタスクに変更してもよい。もしくは作業タスクＨをカレントタスクに変更したことによって、上流工程の文書タスクの完了条件が満たされなくなった場合には、完了条件が満たされていない最も上流工程の文書タスクを、カレントタスクに変更してもよい。また、進捗管理部１６０は、影響タスクとして抽出された作業タスクの全てについて、対応関係にある文書タスクやその要素（満たし）を、変更の影響のある要素として抽出してもよい。
【０１１２】
表示部１７０は、カレントタスクに変更があった場合や、変更の影響のあるタスクやその要素が抽出された場合に、その情報をユーザに提示する。
【０１１３】
このようにして、開発プロセス情報における順序規則だけでは現れてこない見直し作業や文書の改訂作業を、ユーザに知らせることができる。
【０１１４】
次に、本発明の実施形態にかかるコンピュータの構成例を示す。図１３は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５と、入力装置１００６とを備える。
【０１１５】
上記の実施形態の設計支援装置は、コンピュータ１０００に実装されてもよい。その場合、設計支援装置の動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って実施形態における所定の処理を実施する。
【０１１６】
補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、上記の実施形態における所定の処理を実行してもよい。所定の処理を実行する際には、コンピュータ１０００は、入力装置１００６を介して情報を入力したり、ディスプレイ装置１００５を介して情報を出力してもよい。
【０１１７】
また、プログラムは、上記の実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。
【０１１８】
また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、設計支援装置がユーザに情報を直接表示せず、ネットワークで接続された他の装置を介して表示を行う場合には、ディスプレイ装置１００５は省略可能である。
【０１１９】
また、各装置の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【０１２０】
各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【０１２１】
次に、本発明の概要について説明する。図１４は、本発明の概要を示すブロック図である。図１４に示すように、本発明による設計支援装置は、設計原理モデル記憶手段６０１と、開発プロセス情報入力手段６０２と、タスク導出手段６０３と、進捗管理手段６０４と、表示手段６０５とを備えていてもよい。
【０１２２】
設計原理モデル記憶手段６０１（例えば、設計原理モデル記憶部２１０）は、設計プロセスを単純化した設計原理モデルの情報であって、設計原理モデルに含まれるプロセス単位であるフェーズ間の順序規則である第１順序規則と、各フェーズが対応するモデリング手法であるフェーズモデルを示す情報とを含む設計原理モデル情報を記憶する。
【０１２３】
また、開発プロセス情報入力手段６０２（例えば、開発プロセス情報入力部１１０）は、開発現場における設計プロセスである現場プロセスに関する情報であって、現場プロセスにおけるプロセス単位ごとのプロセス内容と、プロセス単位間の順序規則である第２順序規則と、プロセス単位とフェーズとの対応関係を示す情報とを含む開発プロセス情報を入力する。
【０１２４】
プロセス単位とフェーズとの対応関係を示す情報は、例えば、プロセス単位またはプロセス単位に含まれる所定の単位と、設計原理モデルのフェーズモデルまたは該フェーズモデルのデータとの対応関係を示す情報であってもよい。
【０１２５】
タスク導出手段６０３（例えば、タスク導出部１３０）は、設計原理モデル情報と、開発プロセス情報とに基づいて、現場プロセスにおけるプロセス単位以下の単位でのプロセス内容をタスクとして導出する。
【０１２６】
進捗管理手段６０４（例えば、進捗管理部１６０）は、第１順序規則と、第２順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、タスクの進捗状況を更新する。
【０１２７】
表示手段６０５（例えば、表示部１７０）は、現場プロセスにおけるタスクの進捗状況を表示する。
【０１２８】
このような構成により、現場プロセスにおけるプロセス単位であるタスクをベースにしつつも設計原理に基づく進捗状況をユーザに提示できるので、一般エンジニアでも上流設計を行うことが可能になる。
【０１２９】
また、図１５に示すように、本発明による設計支援装置は、さらに影響タスク抽出手段６０６を備えていてもよい。
【０１３０】
影響タスク抽出手段６０６（例えば、影響タスク抽出部１５０）は、フェーズモデルのデータが変更された場合に、第１順序規則と、各タスクが対応するプロセス単位とフェーズとの対応関係とに基づいて、変更の影響のあるタスクである影響タスクを抽出する。
【０１３１】
そのような構成において、進捗管理手段は、変更前のカレントタスクと、影響タスクとに基づいて、現在の作業対象とされるタスクであるカレントタスクを更新してもよい。
【０１３２】
また、設計原理モデルは、フェーズとして要求探索フェーズと機能設計フェーズと構造設計フェーズとを含んでいてもよい。
【０１３３】
また、開発プロセス情報は、現場プロセスにおけるプロセス単位ごとのプロセス内容とプロセス単位間の順序規則として、上流設計における関心事をアクタ別および順次達成すべきプロセス単位である状態別に示す情報である関心事マップを含んでいてもよい。
【産業上の利用可能性】
【０１３４】
本発明は、サービスシステム開発における上流設計を支援するだけでなく、抽象から具体化へといった所定の設計原理に基づいて行われる任意の設計プロセスを支援する用途に好適に適用可能である。
【符号の説明】
【０１３５】
１００  設計支援装置
１１０  開発プロセス情報入力部
１２０  ドキュメントマイルストン抽出部
１３０  タスク導出部
１４０  設計インスタンス情報入力部
１５０  影響タスク抽出部
１６０  進捗管理部
１７０  表示部
２１０  設計原理モデル記憶部
２２０  設計インスタンス記憶部
２３０  タスク記憶部
６０１  設計原理モデル記憶手段
６０２  開発プロセス情報入力手段
６０３  タスク導出手段
６０４  進捗管理手段
６０５  表示手段
６０６  影響タスク抽出手段
【図１】
2018028831.tif 000003
【図２】
2018028831.tif 000004
【図３】
2018028831.tif 000005
【図４】
2018028831.tif 000006
【図５】
2018028831.tif 000007
【図６】
2018028831.tif 000008
【図７】
2018028831.tif 000009
【図８】
2018028831.tif 000010
【図９】
2018028831.tif 000011
【図１０】
2018028831.tif 000012
【図１１】
2018028831.tif 000013
【図１２】
2018028831.tif 000014
【図１３】
2018028831.tif 000015
【図１４】
2018028831.tif 000016
【図１５】
2018028831.tif 000017