JP5346141B1 - データベースシステムおよびその制御方法 - Google Patents

Abstract

オープン環境において、ステークホルダ間で対象システムのライフサイクル全般に亘ってディペンダビリティを維持するための合意形成手段を提供するとともに、ステークホルダ間での合意内容に従って対象システムを適切に運用する。
合意形成支援ツールは、対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う。合意形成の過程において得られた履歴は、合意グラフとしてデータベース層に記憶される。モニタノードツールは、対象システムの実際の運用状態と合意グラフとから対象システムにおける通常の運用状態からの逸脱を検出する。契約書生成ツールは、対象システムにおいて通常の運用状態からの逸脱が検出された際に、合意グラフから合意形成に関する情報データを抽出する。

Description

本発明は、データベースシステムに関する。詳しくは、対象システムのディペンダビリティを担保するためのデータベースシステムおよびその制御方法に関する。

情報（ＩＴ）システムには、そのシステムの提供するサービスを安心して継続的に利用できることが要求される。情報システムは巨大化し、社会インフラとしても非常に重要な役割を担っているため、ひとたび事故が起こると全国民、さらに場合によっては世界中にその影響を及ぼすことになる。銀行システム、通信システム、鉄道システム、そしてクラウドシステムにおいて深刻な障害を起こし、巨額の賠償金に発展するケースもある。もし、大きな事故が起これば責任の追及が行われ、過誤が認定されれば厳しい罰則を受けることをステークホルダは覚悟しなければいけない。

従来からコンピュータシステムの信頼性、可用性、保守性、安全性、完全性、および、機密性に関しては、コンピュータシステムの備えるべき性質としてディペンダビリティが議論されてきている（例えば、非特許文献１参照。）。組込みシステム開発においては、最初に開発計画を立て、対象システムやサービスの機能要件や非機能要件を仕様として書き出し、検証やテストを長期にわたって行い、デプロイするような手法がとられてきた。しかし、障害は日ごとに件数を増してきている。ＣＭＭＩやＩＳＯ ２６２６２をはじめとする規格では、人為的エラーを減らす試みもなされている。しかし、これら既存の技術や規格ではオープン環境におけるシステムという特性の考慮が欠けている。

そこで、情報システムのディペンダビリティを担保する技術体系をまとめ、制度化さらには事業化を目指すべく、２００６年に独立行政法人科学技術振興機構（ＪＳＴ）はＣＲＥＳＴプログラムの１つとしてＤＥＯＳプロジェクトをキックオフした。その様な技術体系を一言で言えば、システムの安全基準を定義して、それを逸脱するようなことがあれば、異常事態に陥る前に回避するか、異常事態に陥ってもすぐさま復旧させることができる技術体系であり、発明者等はオープンシステムディペンダビリティ（Open Systems Dependability）として定義した。

このオープンシステムディペンダビリティはプロセスの観点から整理され、ＤＥＯＳプロセスとしてまとめられた（例えば、非特許文献２および特許文献１参照。）。ＤＥＯＳプロセスの特徴を一言で表現するなら、企画や設計という上流から運用までの対象システムに関するライフサイクル全体に係るオープンシステムディペンダビリティを担保するために、対象システムに係る人と物の行動を律するプロセスであり、対象システムに関わる人々（ステークホルダ）からの対象システムに対する要求に関する合意を始めとしたあらゆる議論に関する合意をベースに、対象システムを通常の運用状態に維持する。各プロセス間での共通言語としてＤ−Ｃａｓｅが設計されている（例えば、非特許文献３参照。）。

国際公開第２０１２／０７３６８６号

Algirdas Avizienis, et al.: "Basic Concepts and Taxonomy of Dependable and Secure Computing", IEEE Transactions on Dependable and Secure Computing, vol.1, no.1, p.11-33 (2004) Mario Tokoro: "Open Systems Dependability - Dependability Engineering for Ever-Changing Systems", ISBN: 978-1-4665-7751-0, CRC Press (2012) Ｄ−Ｃａｓｅ入門, ISBN: 978-4-8629-3079-8, 株式会社ダイテックホールディング (2012)

システム規模の拡大や複雑度の増大は、そのシステムやそれが提供するサービスに関する仕様をも複雑にし、すべての仕様を完全にシステム開発前に記述することを不可能にしている（仕様の不完全性）。このような仕様の不完全性は、対応する実装の不完全性をもたらし、そのシステムが提供するサービスの振る舞いも完全には把握することができず、何をどこまで保証したら良いのか、保証可能なのかも分からなくなる。また、これらの不完全性はステークホルダ間でのシステムやサービスに対する要求理解の違い（誤解）を招き、また、人為的なミスを誘導する。

さらに、そのシステムを取り巻く環境の変化に対応するための要求が新たに発生する。また、開発時点の要求にも修正が必要になる。環境の変化は事前にはわかり得ないため、現在のシステムの動作がその環境変化に確実に対応できるかは分からない。このような変化に対する不確実性はシステム動作予測を困難にし、その変化にシステムが対応する際にシステム障害が最も発生しやすい。

上述の非特許文献２および特許文献１においては、目的や環境の変化に対応するプロセス（変化対応サイクル）と、障害予兆が検知された際または障害が発生した際に起動されるプロセス（障害対応サイクル）との間の共通の表現形式として、Ｄ−Ｃａｓｅを導入している。システム開発時点で想定される障害対応をＤ−Ｃａｓｅとして記述し、ステークホルダ間で合意することで、障害発生時点でのステークホルダの説明責任の達成を可能にしている。しかし、ステークホルダ間で合意されるＤ−Ｃａｓｅは記述全体に対する合意であるため、システム規模の拡大に伴ってＤ−Ｃａｓｅも複雑化し、その合意に至る時間も長期化する。

本発明はこのような状況に鑑みて生み出されたものであり、不完全性と不確実性が潜在的に存在するオープン環境において、ステークホルダ間で対象システムのライフサイクル全般に亘ってディペンダビリティを維持するための合意形成手段を提供することを目的とするとともに、ステークホルダ間での合意内容に従って対象システムを適切に運用する手段を提供することを目的とする。

本発明は、上述の問題点を解消するためになされたものであり、その第１の側面は、対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う合意形成部と、上記合意形成の過程において得られた履歴を合意グラフとして記憶する合意グラフ記憶部と、上記対象システムの実際の運用状態と上記合意グラフとから上記対象システムにおける上記通常の運用状態からの逸脱を検出する検出部と、上記対象システムにおいて上記逸脱が検出された際に上記合意グラフから上記合意形成に関する情報データを抽出する抽出部とを具備するデータベースシステムである。これにより、合意形成の過程において得られた合意グラフに基づいて対象システムの通常の運用状態からの逸脱を検出し、必要な情報データを抽出するという作用をもたらす。

また、この第１の側面において、上記合意形成部は、上記対象システムを定義する複数のモデルを基底として上記合意グラフを生成し、上記複数のモデルの各々は、上記対象システムに関する言葉の意味を一義的に定義し、上記対象システムに関する操作の効果を一義的に定義し、上記対象システムに関するデータの論理的定義と物理的定義とを一義的に関係付けるようにしてもよい。これにより、対象システムを定義する複数のモデルを基底として合意グラフを生成するという作用をもたらす。

また、この第１の側面において、上記対象システムのライフサイクルを構成する複数の段階における複数のステークホルダの活動を通じて生成される上記対象システムに関する文書を上記合意グラフと関連付けて記憶する文書記憶部をさらに具備してもよい。これにより、対象システムに関する文書を合意グラフと関連付けて記憶するという作用をもたらす。

また、この第１の側面において、上記合意グラフは、上記対象システムの目的または環境の変化に対して上記対象システムを継続的に変更していくための変化対応サイクル、および、上記対象システムにおける障害に対応するための障害対応サイクルの両サイクルにおいてアクセスされるようにしてもよい。これにより、合意グラフを変化対応サイクルおよび障害対応サイクルにおいて利用するという作用をもたらす。

また、本発明の第２の側面は、対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う合意形成手順と、上記合意形成の過程において得られた履歴を合意グラフとして記憶する合意グラフ記憶手順と、上記対象システムの実際の運用状態と上記合意グラフとから上記対象システムにおける上記通常の運用状態からの逸脱を検出する検出手順と、上記対象システムにおいて上記逸脱が検出された際に上記合意グラフから上記合意形成に関する情報データを抽出する抽出手順とを具備するデータベースシステムの制御方法である。これにより、合意形成の過程において得られた合意グラフをデータベースシステムに記憶し、その合意グラフに基づいて対象システムの通常の運用状態からの逸脱を検出し、必要な情報データを抽出するという作用をもたらす。

本発明によれば、不完全性と不確実性が潜在的に存在するオープン環境において、ステークホルダ間で対象システムのライフサイクル全般に亘ってディペンダビリティを維持するための合意形成手段を提供するとともに、ステークホルダ間での合意内容に従って対象システムを適切に運用する手段を提供するという優れた効果を奏し得る。特に、ＤＥＯＳプロセスを適切に運用することを可能にすることにより、対象システムに係るオープンシステムディペンダビリティを維持するという効果を奏し得る。

さらに、対象システムを取り巻く環境の変化やビジネス目的の変化等に起因して対象システムを変更する際に最も問題となるディペンダビリティの低下を、従来の開発フェーズと運用フェーズの垣根を無くし、合意グラフを介して密結合することにより、ステークホルダのアカウンタビリティを達成し、オープンシステムディペンダビリティを維持するという効果を奏し得る。

本発明の実施の形態において想定するＤＥＯＳプロセスの概要を示す図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の構成例の概略を示す機能ブロック図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１および対象システム２１０−０１のハードウェア構成例を示す図である。 本実施の形態におけるモデルを説明するための図である。 本実施の形態における合意グラフを説明するための図である。 本実施の形態の合意グラフ演算におけるグラフ構造化ログを説明するための図である。 トゥールミンの提案する議論モデルの一例を示す図である。 本実施の形態に係る合意形成モデル２００−０９に関するＵＭＬ記述例を示す図である。 本実施の形態に係るトゥールミンモデル２００−１０に関するＵＭＬ記述例である。 本実施の形態に係る会議モデル２００−１２に関するＵＭＬ記述例である。 本実施の形態に係る組織モデル２００−１１に関するＵＭＬ記述例である。 本実施の形態に係る基本データモデル２００−１３のＵＭＬ記述例である。 本実施の形態における合意形成に係るモデルの全体像を示す図である。 本実施の形態における議論の対象の設定について説明するための図である。 本実施の形態における契約書作成の概要を示す図である。 本実施の形態に係るモニタノードツール２００−０７と合意グラフとの関係を示す図である。 本実施の形態に係るモデル監視とルールとの関係を示す図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の実装構成例を示す図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の実装例における表示例を示す図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１における機能構成例を示す図である。 本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１における処理手順例を示す流れ図である。

以下、本発明を実施するための実施の形態について詳細に説明する。

＜ＤＥＯＳプロセス＞
図１は、本発明の実施の形態において想定するＤＥＯＳプロセスの概要を示す図である。オープンシステムディペンダビリティ、すなわち、機能、構造、システム境界が時間とともに変化し続けるシステムに対するディペンダビリティを実現するためには、反復的プロセスとしてのアプローチが必須である。この反復的プロセスは、目的（Objectives）や環境の変化に対してシステムを継続的に変更していくためのサイクル（変化対応サイクル１００−０１）と、障害に対して迅速に対応するためのサイクル（障害対応サイクル１００−０２）とを備えている必要がある。両サイクルにおいて、合意記述データベース１００−０８が参照または更新される。

変化対応サイクル１００−０１は、上流プロセスにおける対象システムのオープンシステムディペンダビリティを担保するために必要とされるプロセスからなるサイクルである。この変化対応サイクル１００−０１は、合意形成プロセス１００−０３と、開発プロセス１００−０４と、説明責任遂行プロセス１００−０５の３プロセスを定義している。

障害対応サイクル１００−０２は、対象システムの運用時に必要とされるプロセスからなるサイクルである。この障害対応サイクル１００−０２は、障害対応プロセス１００−０６と、説明責任遂行プロセス１００−０５の２プロセスを定義している。普段は、両サイクルとも対象システムは通常運用状態１００−０７にある。

対象システムのディペンダビリティに関する利害関係者を、ＤＥＯＳプロセスにおいては「ステークホルダ」と呼ぶ。ステークホルダとしては、１）サービス・製品の利用者（顧客、社会的インフラの場合は社会全体）、２）サービス・製品の提供者（事業主）、３）システム提供者（設計開発者、保守運用者、ハードウェア供給者）、４）サービス・製品認可者（規制監督官庁）等を想定するが、これに限定されるものではない。

ステークホルダは、時間の経過や環境の変化によって各々の目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化を、ここでは「目的変化／環境変化」と呼ぶこととする。これらの変化に対し、ステークホルダは熟慮し、相互に合意した上で、適切な時期にシステムの変更を要求する。ＤＥＯＳプロセスはこのような要求に対するサイクルとして、上述の変化対応サイクル１００−０１を備える。

対象システムは、不完全さと不確実さに起因する障害を完全に回避することがきわめて困難である。障害の予兆を検出した場合には障害を未然に回避するが、不幸にも障害が発生してしまった場合には、迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。ＤＥＯＳプロセスではそのような状況に対応するために上述の障害対応サイクル１００−０２を備える。

合意形成プロセス１００−０３は、要求抽出／リスク分析フェーズ１００−０９と、ステークホルダ合意フェーズ１００−１０とから構成される。合意形成プロセス１００−０３は、目的変化／環境変化イベント１００−１９によって、または、障害対応プロセス１００−０６の結果次第で起動される。

要求抽出／リスク分析フェーズ１００−０９では、ユーザニーズ、ステークホルダの目標、多様なシステム環境、規制などから対象システムに係る要求が抽出される。また、それと同時に、サービス継続シナリオが開発される。要求抽出／リスク分析フェーズ１００−０９の結果は、一連のディペンダビリティ要求である。

ステークホルダ合意フェーズ１００−１０は、複数のステークホルダによる対象システムにおいて、何を、何故、如何に変更するか、ということに関する議論から始まる。この議論のプロセス、および、その結果としての合意は、後述のＤ−Ｃａｓｅとして論理的に記述される。ステークホルダ合意フェーズ１００−１０は、サービス継続シナリオからの実行可能手続を生成する。この実行可能手続は、Ｄ−Ｓｃｒｉｐｔに記述され、障害対応に利用される。

開発プロセス１００−０４は、設計フェーズ１００−１１と、実装フェーズ１００−１２と、検証フェーズ１００−１３と、テストフェーズ１００−１４とから構成される。

設計フェーズ１００−１１では、前段の合意形成プロセス１００−０３の結果として合意された要求を、例えば、如何に対象システムに実装し、運用していくかが議論され、必要な仕様書にまとめられる。

実装フェーズ１００−１２では、設計フェーズ１００−１１における仕様書から必要なプログラムコードを記述し、または、必要な技術を実現するプログラムコードを調達し、必要な運用のためのシステムの構築などを行う。

検証フェーズ１００−１３では、実装フェーズ１００−１２の結果が合意形成プロセス１００−０３の結果と矛盾してないかが検査される。プログラムの論理的整合性、プログラミング言語矛盾などが検査される。

テストフェーズ１００−１４では、性能検証のためのベンチマークや耐障害テストなどにより、合意形成プロセス１００−０３におけるステークホルダ合意の通りに対象システムが動作するかが確認される。

障害対応プロセス１００−０６は、通常運用状態１００−０７から起動され、未然回避フェーズ１００−１５と、迅速対応フェーズ１００−１６と、原因究明フェーズ１００−１７とから構成される。

未然回避フェーズ１００−１５は、予兆検知／障害発生イベント１００−１８における特に予兆検知によって起動される。障害の予兆が検知されたことにより、その障害を回避するための必要な対策が実行される。上述の実行可能手続（Ｄ−Ｓｃｒｉｐｔ）の実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ１００−１７を経て合意形成プロセス１００−０３が起動されてステークホルダによる対策が実行される場合もある。

一方、迅速対応フェーズ１００−１６は、予兆検知／障害発生イベント１００−１８における特に障害発生によって起動され、その障害から対象システムを通常運用状態１００−０７に回復させる対策が実行される。未然回避フェーズ１００−１５と同様に、実行可能手続（Ｄ−Ｓｃｒｉｐｔ）の実行によってその対策が実行される場合もあり、また、必要な原因究明フェーズ１００−１７を経て合意形成プロセス１００−０３が起動されてステークホルダによる対策が実行される場合もある。

通常運用状態１００−０７は、対象システムが通常の運用状態にあることを示している。この通常運用状態１００−０７は、対象システムがステークホルダ間で合意されたサービスレベル変動許容範囲（In-Operation Range）から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクル１００−０１は、通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクル１００−０２も、通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、サービスレベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。または、一部の機能を縮退してサービスを継続している場合もある。しかしながら、サービスの提供が完全に停止されてしまう場合もある。

通常運用状態１００−０７において実行されるプロセスには、日常的な動作記録の点検、プロセスの定期的な見直しや改善、要員の訓練、しつけおよび教育など、継続的なディペンダビリティ向上活動が含まれる。システムの稼働状況を記録し、日々点検することにより、保守担当者や運用担当者が何かの兆候をそこから見出すことができる可能性がある。また、システムのメモリ資源を常にクリーンな状態にすることも、非常に有効な日常保守または改善活動である。または、積極的に予行を行うことも有効である。障害は、ある時間が経過してある状態に達した時に発生する。そうであれば、時間を先に経過させると障害の発生を事前に知ることができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかはその時の状況による。

説明責任遂行プロセス１００−０５では、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者および社会に対し、障害状況、迅速対応および今後の見通しなど説明する。また、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか（変化するのか）を説明する。日常のサービス遂行状況や、設計開発／保守運用プロセスに関する説明が必要なときもこれに対応する。これらは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。

＜ディペンダビリティ維持リポジトリシステム＞
図２は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の構成例の概略を示す機能ブロック図である。このディペンダビリティ維持リポジトリシステム２００−０１は、ＤＥＯＳプロセスにおける合意記述データベース１００−０８に対応するものである。なお、ディペンダビリティ維持リポジトリシステム２００−０１は、請求の範囲に記載のデータベースシステムの一例である。

ディペンダビリティ維持リポジトリシステム２００−０１は、対象システム２１０−０１とネットワーク２２０−０１とを介して結ばれている。対象システム２１０−０１は、別個の２台以上のコンピュータから構成されるシステムであってもよい。２台以上のコンピュータから構成される場合には、各コンピュータはネットワーク２２０−０１によって接続され得る。本実施の形態におけるネットワーク２２０−０１は、専用回線であってもよく、インターネットを含む公衆回線であってもよく、公衆回線上にＶＰＮ技術を用いて仮想的な専用回線を構築したものであってもよく、また、１台のコンピュータ内部のＯＳの提供する通信回線であってもよい。以下では、特に断らない限りネットワークを上述のように定義する。

ディペンダビリティ維持リポジトリシステム２００−０１は、上位層、中間層、および、下位層の３層構造によって構成される。

上位層は、基本ツール層２００−０２であり、ディペンダビリティ維持リポジトリシステム２００−０１と各ＤＥＯＳプロセスとのやり取りを支援するコンピュータプログラムが存在する。本実施の形態では、合意形成支援ツール２００−０５と、契約書作成ツール２００−０６と、モニタノードツール２００−０７の３つのツールを基本ツールとして例示するが、これらに限定されるものではない。

合意形成支援ツール２００−０５は、ＤＥＯＳプロセスにおける合意形成プロセスの遂行を円滑にする。ＤＥＯＳプロセスにおける合意形成プロセスでは、トゥールミン（Stephen E. Toulmin）の提案する議論モデル（例えば、ISBN: 978-0-5215-3483-3参照）を採用する。ステークホルダ間における合意に至る過程で生成されるドキュメントをこの議論モデルによって表現し、ディペンダビリティ維持リポジトリシステム２００−０１に記録する。

契約書作成ツール２００−０６は、ディペンダビリティ維持リポジトリシステム２００−０１に記録されている情報から対象システム２１０−０１に関する必要な契約書を作成することを支援する。

モニタノードツール２００−０７は、対象システムの監視点に係る必要な情報を記載したＤ−Ｃａｓｅモニタノード（例えば、非特許文献３参照）と関連し、対象システム２１０−０１をモニタリングするために必要な機能を提供する。

中間層はモデル層２００−０３であり、上位層の基本ツール層２００−０２で必要とされるモデルを定義する。この実施の形態では、基本データモデル２００−１３と、合意形成モデル２００−０９と、トゥールミンモデル２００−１０と、会議モデル２００−１２と、Ｄ−Ｃａｓｅモデル２００−０８と、組織モデル２００−１１を例示しているが、これらに限定されるものではなく、自由に拡張または縮退可能である。

基本データモデル２００−１３は、上位層の基本ツール層２００−０２において共通に利用されるモデルを定義している。合意形成モデル２００−０９は、合意形成支援ツール２００−０５において必要なモデルを定義している。トゥールミンモデル２００−１０は、トゥールミンの議論モデルを表現するモデルを定義している。会議モデル２００−１２は、ステークホルダの合意形成が会議の形態による場合に必要なモデルを定義している。Ｄ−Ｃａｓｅモデル２００−０８は、Ｄ−Ｃａｓｅ記述（例えば、非特許文献３参照）を記録するために必要なモデルを定義している。組織モデル２００−１１は、ステークホルダの権限と組織とを対応付けるのに必要なモデルを定義している。

下位層はデータベース層２００−０４であり、上層のモデル層２００−０３で定義されているモデルのインスタンス（モデル型のデータとも言える）を記録するデータベースである。本実施の形態では、グラフＤＢ２００−１４と、ドキュメントＤＢ２００−１６と、Ｋｅｙ／Ｖａｌｕｅ Ｓｔｏｒｅ２００−１５の３種を定義しているが、これに限定されるものではない。

グラフＤＢ２００−１４は、主に後述の合意モデルを記録するために利用される。ドキュメントＤＢ２００−１６は、ディペンダビリティ維持リポジトリシステム２００−０１が記録する必要のある文書を格納するために利用される。Ｋｅｙ／Ｖａｌｕｅ Ｓｔｏｒｅ２００−１５は、グラフＤＢ２００−１４およびドキュメントＤＢ２００−１６のインデクスを記録するために利用される。

＜ハードウェア構成＞
図３は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１および対象システム２１０−０１のハードウェア構成例を示す図である。最も基本的な構成としては、ディペンダビリティ維持リポジトリシステム２００−０１および対象システム２１０−０１は、命令バスおよびデータバスによって接続された演算装置３００−０１と、制御装置３００−０２と、メモリ装置３００−０３と、入出力装置３００−０４とを備えた電子計算機である。

入出力装置３００−０４から入力されたビットデータの情報に基づいて、演算装置３００−０１において、算術演算、論理演算、比較演算、シフト演算などが実行される。実行されたデータは、必要に応じて、メモリ装置３００−０３に記憶され、入出力装置３００−０４から出力される。これら一連の処理は、メモリ装置３００−０３に記憶されたソフトウェアプログラムに従って、制御装置３００−０２によって制御される。本実施の形態におけるディペンダビリティ維持リポジトリシステム２００−０１および対象システム２１０−０１は、上述のコンピュータとしての基本機能を備えたハードウェアであり、オペレーティングシステムやデバイスドライバ、ミドルウェア、アプリケーションソフトウェアといったプログラム群によって制御される。

＜モデルと合意グラフ＞
図４は、本実施の形態におけるモデルを説明するための図である。モデルとは、一義的に言葉の意味が定義され、一義的に操作の効果が定義され、かつ、一義的にデータの論理的定義と物理的定義とが関係付けられる定義領域のことである。特に断らない限り、本実施の形態ではモデルをこのように定義する。

上述のモデル層２００−０３では、６モデルが提示されていた。これらモデル群を基底に生成されたデータを、モデルインスタンス４００−０１と呼称している。モデルインスタンス４００−０１には、モデルデータに係るインスタンスとしては、Ｄ−Ｃａｓｅとその付帯情報、仕様書、設計書、運用計画書、ログ、等の各種文書群がある。議論に係るインスタンスとしては、会議録文書、主張と反論に関する文書とその履歴等の文書群がある。スクリプトに係るインスタンスとしては、検証、アクション、推論等の手続に関する文書群がある。これら文書群には全ての変更履歴が残されている。さらに、ステークホルダ間で合意された対象システムに係るパラメータであるサービスレベル変動許容範囲（In-Operation Range）を調べることで対象システムが通常運用状態１００−０７にあることを検証するためのスクリプトや、通常運用状態１００−０７から外れた場合のアクションを記したスクリプトなどの文書も対象になる。

モデルインスタンス４００−０１は、データベース層２００−０４に記録される。対象とするデータの性質が非構造的であり、関係性が重要であり、時間特性を備え、高速に多種大量のデータ処理が必要であることを考慮し、グラフデータベース２００−１４、ドキュメントデータベース２００−１６、および、Ｋｅｙ／Ｖａｌｕｅ Ｓｔｏｒｅ２００−１５という３種類のリポジトリを扱う。モデル層２００−０３からは、これらのデータベースに、透過的にアクセス可能である。

本実施の形態では、合意グラフ演算４００−０２として、「マトリクス型アクセス制御」と、「グラフ構造化ログ」と、「イベント相関計算」と、「バージョン制御」と、「トレースとトラッキング」と、「解析と認識」と、「仮説、推定または推論」と、「時間／時刻管理」と、「クラスタリング、分類、予測」と、「コンテキスト検索」とがリストされているが、これらに限定されるものではない。これらの一部を備えてもよく、また、他の新たな演算を加えてもよい。

「マトリクス型アクセス制御」は、誰がどのノードにアクセスできるかを制御する。人は組織に属しており、組織異動によりアクセス権も変更が必要である。組織異動前に生成されたノードに対して、組織異動後のアクセス件を付与してしまうと、そのノードが前組織の資産である場合には都合が悪い。本演算は人と組織とノードの関係を適切に維持するものである。

「グラフ構造化ログ」は、ログモデルに基づいてログデータを構造化するものである。この構造化の具体例については後述する。

「イベント相関計算」は、複数の関連あるイベントをまとめるための相関（correlation）演算を行うものである。これにより、イベントの数を減らし、システム性能を向上させるものである。

「バージョン制御」は、ノードが修正されるとき、または、ノード群の構造が修正されるときに、バージョンを付与することによって、そのバージョンのノード群にアクセスすることを可能にするものである。

「トレースとトラッキング」は、あるノードからリンクを辿ることによって、繋がったノード群を抽出し、または、あるノードへの新たなノードの接続を通知するものである。

「解析と認識」は、ノードとノードの繋がり、または、ノード群の構造を解析し、例えば意味データベースや辞書を参照することによって、そのノードまたはノード群の意味を抽出するものである。

「仮説、推定または推論」は、ノード群の構造または意味との対応から、類似のノード群の性質を導き出すものである。

「時間／時刻管理」は、ノードやリンクに対する生成、変更、削除を含むアクセス時刻を管理し、または、相対時刻とのマッピングを行うものである。

「クラスタリング、分類、予測」は、ノード群を階層的クラスタリングやＫ−ｍｅａｎｓ手法等を用いて分類するものである。

「コンテキスト検索」は、グラフ演算においてコンテキストを考慮した検索を行うものである。例えば、「車」に関する記述があった場合、それが自動車であるか、または、人名であるかは、コンテキストに依存するからである。

ここで、Ｄ−Ｃａｓｅに関して略説する。Ｄ−Ｃａｓｅは、アシュアランスケース（assurance case, ISO/IEC 15026-2: 2011）を拡張し、ＧＳＮ（Goal Structuring Notation, http://www-users.cs.york.ac.uk/tpk/dsn2004.pdf）記法を用いて記述する。このＤ−Ｃａｓｅは、上述のＤＥＯＳプロセスにおいては、変化対応サイクル１００−０１および障害対応サイクル１００−０２によって利用される。例えば、モデルインスタンス４００−０４は、Ｄ−Ｃａｓｅモデル２００−０８に関するインスタンス例である。また、モデルインスタンス４００−０６は、合意形成モデル２００−０９に関するインスタンス例である。モデルインスタンス４００−０４および４００−０６には、それぞれ合意ノード４００−０７および４００−０９が関連付けられている。合意ノード４００−０７は、複数のノードが存在するＤ−Ｃａｓｅモデルインスタンス４００−０４に関する合意であり、合意ノード４００−０８は特定のノードのみに関する合意である。このように、合意の対象は、単独のノードであってもよく、また、複数のノード群であってもよい。

図５は、本実施の形態における合意グラフを説明するための図である。図５における"ａ"は、Ｄ−Ｃａｓｅモデルインスタンス４００−０４の再掲であり、その時刻をｔ１とする。図５における"ｂ"は、"ａ"に対応した時刻ｔ１におけるＤ−Ｃａｓｅである。"ｂ"のＤ−Ｃａｓｅを３人のステークホルダが合意した場合、図５における"ｃ"に示す合意ノード４００−０７が関連付けられる。各々のステークホルダは、モデルインスタンス５００−０１、５００−０２および５００−０３で表現され、合意ノード４００−０７と関連付けられる。このようなステークホルダが合意しているモデルインスタンスを表現したグラフを、合意グラフと呼称する。

ここで、Ｄ−Ｃａｓｅ表記に関して略説する。長方形は、議論によって立証したいゴールを示す。角が丸い四角形は、コンテキストであり、その関連先のノードに関するコンテキスト情報（補助情報）を記述する。並行四辺形は、ストラテジであり、議論をサブゴールに分解する際の方針を示す。丸形は、エビデンスまたはモニタリングであり、関連するゴールに関する根拠を示す。菱形は、議論がまだなされてないノードであることを示す。

次に、時刻ｔ２においてＤ−Ｃａｓｅが、"ｂ"から"ｄ"に修正されたものとする。対応するＤ−Ｃａｓｅモデルは、モデルインスタンス５００−０４となる。２人のステークホルダ５００−０１および５００−０２が合意している場合の合意グラフが"ｅ"に例示される。

図６は、本実施の形態の合意グラフ演算におけるグラフ構造化ログを説明するための図である。一連のログデータ６００−０１は、ログモデル６００−０２に基づいて処理されることにより、データベース層２００−０４にはグラフ６００−０３の構造で記録される。ログデータ６００−０１は、一般に全く構造を持たない非構造データ、または、一部構造が定義されているか容易に推測可能であるような半構造データとして記録されている。ログモデル６００−０２では、マシン名には対応するマシンノードを、アプリケーション名には対応するアプリノードを、プロセス名には対応するプロセスノードを、ログデータには対応するデータノードをそれぞれ生成し、対応する情報を記録する。ログモデル６００−０２では、記号「＊」は矢印元のインスタンス１つに対して矢印先のインスタンスが複数存在可能であることを示している。グラフ構造化ログにより、グラフ６００−０３の構造を持ったログデータがデータベース層２００−０４に記録される。

＜合意形成過程＞
次に、本実施の形態に係る合意形成支援ツール２００−０５を軸にして、本実施の形態におけるディペンダビリティ維持リポジトリシステム２００−０１を利用したステークホルダ間での合意形成過程を説明する。合意形成支援ツール２００−０５は、ＤＥＯＳプロセスにおける合意形成プロセス１００−０３で利用されることを想定している。ここではトゥールミンの議論モデルを採用するが、他の手法を用いてもよい。例えば、ＯＭＧ（Object Management Group）の規定するＳＡＣＭ（http://www.omg.org/spec/SACM）を用いてもよく、また、両者を組み合わせてもよい。

図７は、トゥールミンの提案する議論モデルの一例を示す図である。議論に当たって発言者は自らの発言内容が、図示される構造を持つように発言する。議論の結論である主張（Claim）７００−０１と、それを裏付けるデータ（Data）７００−０３、そして、主張に対するデータの根拠（Warrant）７００−０４を考える。根拠にはその根拠の正しさを示すための裏付け（Backing）７００−０５が必要である。また、主張である結論が完全ではない場合もあるため、限定（Qualifier）７００−０２することができる。議論ではこの主張が当てはまらないことを主張する論駁（Rebuttal）７００−０６も考える。実際にはこの構造が複合的に複数の発言者に関連し複数存在し、議論を構成する。このモデルが上述のトゥールミンモデル２００−１０としてそのインスタンスがデータベース層２００−０４に記録される。

図８乃至図１２を用いて本実施の形態に係る各モデルのＵＭＬクラス図について説明する。なお、本実施の形態では、ＵＭＬクラス図を一実施例として示し、これらには限定しない。ここで、ＵＭＬクラス図に関して略説する。２段に分かれた四角はクラスを表し、上段がクラス名で下段が属性名である。四角から四角の実線は参照であり、矢印上の名称は属性名である。実線の先に「０．．ｎ」とあるのは多重度であり、先のインスタンス数が０かｎであることを示している。先端が白抜きの点線矢印は、スーパークラスとサブクラスの関係を示している。

図８は、本実施の形態に係る合意形成モデル２００−０９に関するＵＭＬ記述例を示す図である。モデルインスタンスとして合意形成コンテキスト（ConsensusBuildingContext）８００−０１と、記述（Description）８００−０２とを定義している。このモデルインスタンスがデータベース層２００−０４にノードとして記録される。

図９は、本実施の形態に係るトゥールミンモデル２００−１０に関するＵＭＬ記述例である。モデルインスタンスとして主張（Claim）８１０−０１と、記述（Description）８００−０２とを定義している。このモデルインスタンスがデータベース層２００−０４にノードとして記録される。

図１０は、本実施の形態に係る会議モデル２００−１２に関するＵＭＬ記述例である。モデルインスタンスとして会議（Meeting）８２０−０１と、議題（TopicContent）８２０−０２と、合意形成コンテキスト（ConsensusBuildingContext）８００−０１とを定義している。このモデルインスタンスがデータベース層２００−０４にノードとして記録される。

図１１は、本実施の形態に係る組織モデル２００−１１に関するＵＭＬ記述例である。モデルインスタンスとして人（Person）８３０−０１を定義している。このモデルインスタンスがデータベース層２００−０４にノードとして記録される。

図１２は、本実施の形態に係る基本データモデル２００−１３のＵＭＬ記述例である。モデルインスタンスとしてファイル（File）８４０−０１と、外部参照（ExternalReference）８４０−０２と、内部参照（InernalReference）８４０−０３とを定義し、それらは抽象クラス（AttachmentContent）８４０−０４から導出されている。また、記述（Description）８００−０２が定義されている。このモデルインスタンス群はデータベース層２００−０４にノードとして記録される。

図１３は、本実施の形態における合意形成に係るモデルの全体像を示す図である。まず、合意形成の場として「合意形成コンテキスト」を定義する。複数の「参加者」と複数の「記述」が「発言」として「合意形成コンテキスト」に関連付けられる。一方、ここでは会議の形態で合意を形成する場合を想定する。「会議」モデルが定義され、複数の参加者と「議題」が関連付けられる。複数の「議題」は「議論内容」として「合意形成コンテキスト」と関連付けられる。上述の議論モデルにしたがって、「記述」は「主張」と関連付けられ、「記述」間には「言及」の関係が存在する。「主張」間には「支持」と「反論」の関係が存在する。「記述」も「主張」も「差替」することで置き換えることができる。また、「記述」や「主張」は、「添付」として「内部参照」、「外部参照」または「ファイル」を参照することができる。「記述」間の関係には「同意表明」があり、そのステータスとして「同意」、「不同意」または「棄権」を定義する。合意形成支援ツール２００−０５は、合意形成の過程を、トゥールミンの提案する議論モデルに従って、必要な関連情報とともにデータベース層２００−０４に記録していく。

図１４は、本実施の形態における議論の対象の設定について説明するための図である。モデル層２００−０３のＤ−Ｃａｓｅモデル２００−０８は、Ｄ−Ｃａｓｅ記述様式（例えば、非特許文献３参照）である木構造を頂点およびエッジとした合意グラフとして記録している。合意記述支援ツール２００−０５では、Ｄ−Ｃａｓｅ記述に対してどの部分を議論の対象にするか、自由に設定することができる。

例えば、Ｄ−Ｃａｓｅストラテジノードを対象に議論を展開してもよい。この場合、合意ノードとしてはＤ−Ｃａｓｅストラテジノード、記述ノード、および、主張ノードがリンクする。また、一部のサブゴールを対象に議論を展開してもよく、また、複数のＤ−Ｃａｓｅ間の関係に関して議論を展開してもよい。Ｄ−Ｃａｓｅ＿１（９００−０１）におけるＳｔｒａｔｅｇｙ９００−０４に関する議論は、主張ノード９００−０５と記述ノード９００−０６として記録される。これに対して、Ｄ−Ｃａｓｅ＿２（９００−０２）を反論として主張する場合、主張ノード９００−０７と記述ノード９００−０８に関連付けられたＤ−Ｃａｓｅ＿２（９００−０２）のノード群が、主張ノード９００−０５に反論９００−０３の属性をもってリンクしている状態として記録される。反論９００−０３は、図９における反論リンク８１０−０２である。

また、議論分解パターンを合意形成支援ツール２００−０５に応用することで、対象の複数のＤ−Ｃａｓｅを効率的に扱うことができる。この議論分解パターンは、Ｄ−Ｃａｓｅストラテジによるサブゴールへの分解の際の方針を、システム分解、機能分解、属性分解、完全分解、単調分解、具体分解というパターンに分けて整理するものである（非特許文献３参照）。例えば、システムを構成するサブシステム毎にゴールが成立することを議論していくパターンであるシステム分解パターンは、サブシステム毎のＤ−Ｃａｓｅを扱うため、関係する合意グラフもサブシステム毎に合意を構成することが可能である。

さらに、Ｄ−Ｃａｓｅエビデンスノード９００−０９に対して関係するドキュメント９００−１２を関連付ければ、ゴール＿２（９００−１３）を成立させるエビデンスとなる。なお、ドキュメント９００−１２は、外部参照ノード経由で、例えばドキュメントＤＢ２００−１６に格納されたドキュメントとして図示されている。また、Ｄ−Ｃａｓｅモニタノード９００−１０に関係するスクリプト９００−１１を関連付ければ、ゴール＿１（９００−１４）を成立させるモニタノードとなる。なお、スクリプト９００−１１は、外部参照ノード経由で例えばドキュメントＤＢ２００−１６に格納されたスクリプトとして図示されている。ここでも、それらのドキュメントが用いられた理由および根拠は、議論の過程としてデータベース層２００−０４に記録される。

Ｄ−Ｃａｓｅは、ある時点での対象システムのディペンダビリティに係るステークホルダ間の合意を表しており、合意された時点での議論の結果として静的である。一方、本実施の形態に係るオープンシステムにおいては、合意は環境の変化によって修正が余儀なくされる。すなわち、Ｄ−Ｃａｓｅはシステムの運用状態では静的ではあり得ない。通常運用状態１００−０７からの逸脱が起きれば、Ｄ−Ｃａｓｅは迅速に修正されなければいけない。そして、何が議論されたか、および、その経緯も提示できる必要がある。本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１はそれを可能にする機構を提供している。例えば、データベース層２００−０４に記録されている合意グラフから、該当する会議モデルインスタンスを抽出し、そのリンクを合意グラフ演算４００−０２の「トレースとトラッキング」機構を用いて辿ることで、過去の会議データを参照することができる。

＜契約書作成＞
図１５は、本実施の形態における契約書作成の概要を示す図である。契約書作成ツール２００−０６は、ディペンダビリティ維持リポジトリシステム２００−０１に記録されている情報から対象システム２１０−０１に関する必要な契約書を作成する機構を提供する。例えば、ＳＬＡ（Service Level Agreement）は、サービスの提供者と受領者の間でサービスの内容、サービスレベルに関する目標、提供者と受領者の責任範囲などに関する合意である。ディペンダビリティ維持リポジトリシステム２００−０１はこのＳＬＡのための情報ソースが記録されている。

データベース層２００−０４に記録されている合意グラフの一部を例示したものが合意グラフ１０００−０１であるとする。一方、ＳＬＡはＳＬＡモデル１０００−０６を定義できる。契約書作成ツール２００−０６は、ＳＬＡモデル１０００−０６に従って、合意グラフ１０００−０１の中で合意ノード１０００−０４および１０００−０５から辿れるノードに関連付けられたドキュメント１０００−０２および１０００−０８を抽出し、契約書１０００−０７を生成する。

＜モニタリング＞
モニタノードツール２００−０７は、Ｄ−Ｃａｓｅモニタノード（非特許文献３参照）と関連し、対象システム２１０−０１をモニタリングするために必要な機構を備える。例えば、「対象システム２１０−０１において何を何時モニタリングすることが効果的か」という情報は、類似のシステムに関するモニタリングを設計する際には有用な情報である。また、「モニタリングが仕様書通りに実行されているか」、そして「それはステークホルダ間で合意されたサービスレベルを満たしているか」ということをリアルタイムに提示するために、モニタノードツール２００−０７は必要な機構を備える。この機構には特許文献１の手段を利用してもよく、また、他の手段を利用してもよい。

また、モニタノードツール２００−０７は、モデルインスタンスにおけるスクリプト９００−１１を実行環境上にデプロイし、対象システムが通常運用状態１００−０７にあることをリアルタイムに把握できるようにする。なお、図１４では、スクリプト９００−１１は、外部参照ノード経由で、例えばドキュメントＤＢ２００−１６に格納されたスクリプトとして図示されている。また、実行環境としては、例えば、特許文献１におけるランタイムコンピュータを想定することができる。

さらに、モニタノードツール２００−０７は、その対象を、対象システム２１０−０１をモニタリングするだけではなく、対象システムの利用環境（組織運営）に拡張してもよい。その場合、組織運営の通常の状態がステークホルダ間で合意され、上述のように合意グラフに記録される。そして、その逸脱により、異常事態に陥る前に回避するか、異常事態に陥っても速やかに復旧させることができる。

図１６は、本実施の形態に係るモニタノードツール２００−０７と合意グラフとの関係を示す図である。合意グラフ１１００−０１にはＤ−Ｃａｓｅモデルインスタンス１１００−０２とログモデルインスタンス１１００−０７とが存在している。ここで、ログモデルインスタンス１１００−０７は、ログモデル６００−０２のインスタンスである。

モニタノードツール２００−０７は、Ｄ−Ｃａｓｅモデルインスタンス１１００−０２内のモニタリングノード１１００−０３および１１００−０４にリンクされたＤ−Ｓｃｒｉｐｔ１１００−０５および１１００−０６を抽出する。モニタリングノード１１００−０３の状態は、Ｄ−Ｓｃｒｉｐｔ１１００−０５を対象システム２１０−０１にデプロイし、実行することにより入手される。モニタリングノード１１００−０４の状態は、Ｄ−Ｓｃｒｉｐｔ１１００−０６をログモデルインスタンス１１００−０７に対して適応することにより入手される。モニタノードツール２００−０７は、Ｄ−Ｃａｓｅインスタンス１１００−０２内のモニタリングノード１１００−０３および１１００−０４の状態によって、ゴール１１００−０８の状態を決定し、必要に応じてさらなるアクションを起動する。

図１７は、本実施の形態に係るモデル監視とルールとの関係を示す図である。この図において、本実施の形態に係る基本ツール層２００−０２におけるツール群が扱うモデル群の管理に関して説明する。合意形成支援ツール２００−０５、契約書生成ツール２００−０６およびモニタノードツール２００−０７は、モデルＤＢ１２００−０２を利用してモデルインスタンスとしての合意グラフ１２００−０１にアクセスする。モデルＤＢ１２００−０２には、モデル層２００−０３に存在するモデルが記録されている。モデルＤＢ１２００−０２は、データベース層２００−０４のドキュメントＤＢ２００−１６にその実体は存在する。ただし、モデル間の関係に関してはグラフＤＢ２００−１４にその実体が存在する。

モデル層２００−０３に存在する複数のモデル群におけるモデル間の関係はルールによって記述される。例えば、「１仕様書は複数の設計書と関連を有する」というルールに対して、その仕様書が作成されたものの関連する設計書が存在しない場合には、ルール違反として何らかのアクションが必要となる。また、一例として、「このＤ−Ｃａｓｅモニタノードはこれらのログ検証結果と関連する」というルールに対して、そのＤ−Ｃａｓｅモニタノードに対応するログ検証結果が存在しない場合、ルール違反となり必要なアクションが起動される。なお、このルールはＤ−Ｓｃｒｉｐｔで記述してもよい。

また、このルールには、作成時限に関するルールを記述してもよい。一例として、「この機能はこの時点までに作成する必要がある」というルールがあった場合、その機能がその時点までに作成されてない場合には、ルール違反となり必要なアクションが起動される。さらに、そのルールにはモデルが持つ値をチェックするルールがあってもよい。モデル間の整合性のチェックに利用される。これらルール群はモデルを前提に作成される。

ルール群は、ルールＤＢ１２００−０４に記録される。ルールＤＢ１２００−０４は、データベース層２００−０４のドキュメントＤＢ２００−１６にその実体は存在する。モデル監視１２００−０３は、モデルＤＢ１２００−０２へのモデルの追加、更新、削除などのイベントを監視し、そのイベント群が発生した場合にはモデルとルールの組をモデル／ルール処理１２００−０５に送り、そのルールを実行する。ルール判定結果は、ルール判定結果ＤＢ１２００−０６に記録される。ルール判定結果ＤＢ１２００−０６は、データベース層２００−０４のドキュメントＤＢ２００−１６にその実体が存在する。モデル／ルール処理１２００−０５は、処理過程において必要に応じてルール判定結果ＤＢ１２００−０６から関係する結果を取得してもよい。判定結果監視１２００−０７は、ルール判定結果ＤＢ１２００−０６を監視し、判定結果をツール層２００−０２のツール群に通知する。モデル監視１２００−０３、モデル／ルール処理１２００−０５、判定結果監視１２００−０７は、モニタノードツール２００−０７が管理し、モデル層２００−０３で実行される。

＜システム実装例＞
図１８は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の実装構成例を示す図である。合意形成支援ツール２００−０５は、ＷＥＢアプリケーションとして構成することができる。基本ツール層２００−０２には、合意形成支援ツール２００−０５が存在する（１３００−０１）。モデル層２００−０３には、会議モデル２００−１２（１３００−０２）と、トゥールミンモデル２００−１０（１３００−０３）と、合意形成モデル２００−０９（１３００−０４）と、基本データモデル２００−１３（１３００−０５）と、組織モデル２００−１１（１３００−０６）とが存在する。上位層は、下位層のモデルを利用しながら合意形成支援ツール１３００−０１に必要な機能を提供する。

この実装例では、合意形成モデル１３００−０４には、合意すべき「対象」とステークホルダとの間の関係を定義する「場」と、そこでの「同意ステータス」をモデルとして定義した。なお、合意すべき「対象」としては、ドキュメント、プログラム、スクリプトなどの、ステークホルダ間で合意すべき全ての成果物（outcome）が想定される。

トゥールミンモデル１３００−０３には、上述の図７のモデルに従って主張、論駁、支持の関係、および、必要なアクションをエッジとして定義した。

会議モデル１３００−０２には、議題間の関係、および、参加者を定義した。各議論には議事進行、議論の対象、対象に対する主張、主張を支持する主張、主張に反論する主張、主張に対する発言の連鎖、対象に対する同意表明を含むようにした。この会議モデルは、アプリケーションに関するモデルであり、下位層のモデルに依存している。なお、これらのモデルは別のモデルであってもよく、置き換え可能である。

（汎用基本）データモデル１３００−０５には、記述、発言関係、ファイル、参照、差替などを定義した。組織モデル１３００−０６は、リソースと組織との関係を表現するが、この実装例では人に関するモデルのみを定義した。これらの層に必要なユーティリティ群は、共通フレームワーク１３００−０７により提供され、合意グラフはグラフフレームワーク１３００−０８によりグラフデータベースに記録される。この実装例では、グラフフレームワーク１３００−０８としてオープンソースのＴｉｎｋｅｒＰｏｐ（http://tinkerpop.com）を採用し、グラフデータベース１３００−１０としてはオープンソースのＮｅｏ４ｊ（http://neo4j.org）を採用した。また、アプリケーションサーバ１３００−０９にはＰｌａｙ！フレームワーク（http://www.playframework.org）を採用した。Ｐｌａｙ！フレームワークは、プラグインの仕組み（モジュール）を備えているため、モデル群およびグラフデータベースとの接続部をＰｌａｙ！フレームワークのモジュールとして実装し、合意形成支援ツール１３００−０１は、Ｐｌａｙ！アプリケーションとして実装した。したがって、図１８ではＰｌａｙ！フレームワークまでをモデル層とした。

図１９は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１の実装例における表示例を示す図である。ここでは、ある会議における議論に関する合意グラフをグラフ表示している。この表示例では、ノードにカーソルを合わせた際に記載内容がポップアップする様子が示されている。

＜全体構成＞
図２０は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１における機能構成例を示す図である。この機能構成例では、合意グラフ２０００−０１に対して、合意形成支援ツール２００−０５と、モニタノードツール２００−０７と、契約書生成ツール２００−０６とがアクセスするように構成されている。

合意形成支援ツール２００−０５は、対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う。合意形成支援ツール２００−０５の対象となるのは、議論およびその議論に必要な合意文書（ドキュメント）２０００−０３である。計算機システムのソフトウエア開発プロセスにおいて合意形成支援ツール２００−０５が使用される場合には、合意文書２０００−０３としてプログラムコードが想定される。ただし、合意形成支援ツール２００−０５は計算機システム以外にも適用可能であり、会社の会議、株主総会、学校の生徒会などにも適用することができる。

そして、合意形成支援ツール２００−０５は、合意対象モデル２０００−０２のモデルインスタンスを表現したグラフとして合意グラフ２０００−０１を生成する。この合意グラフ２０００−０１は、合意形成の過程において得られた履歴である。この合意グラフ２０００−０１は、データベース層２００−０４に記憶される。

モニタノードツール２００−０７は、対象システムの実際の運用状態と合意グラフ２０００−０１とから対象システムにおける通常の運用状態からの逸脱を検出する。対象システムの実際の運用状態は、モニタ対象モデル２０００−０４として表されている。モニタノードツール２００−０７が対象とするのは、サーバや組込みシステムなどの実際のシステムである。このモニタ対象モデル２０００−０４において使用されるスクリプトとしてモニタスクリプト２０００−０５が示されている。

契約書生成ツール２００−０６は、合意グラフ２０００−０１に基づいて、合意形成に関する情報データの一つとして契約書モデル２０００−０６を抽出する。この契約書モデル２０００−０６に従って契約書２０００−０７が生成される。ここでは、合意形成に関する情報データの一つとして契約書を生成する例を示したが、他の情報データを生成するようにしてもよい。この契約書生成ツール２００−０６は、例えば、対象システムにおける通常の運用状態からの逸脱がモニタノードツール２００−０７によって検出された際に、これを契機として情報データを生成する。

図２１は、本実施の形態に係るディペンダビリティ維持リポジトリシステム２００−０１における処理手順例を示す流れ図である。

対象システムの通常の運用状態に関する議論を通じて合意形成が行われる（ステップＳ１１）。この合意形成において合意形成支援ツール２００−０５が用いられる。この合意形成の過程において得られた履歴は合意グラフとしてデータベース層２００−０４に記憶される（ステップＳ１２）。

対象システムの実際の運用状態は常に監視される。モニタノードツール２００−０７は、対象システムの実際の運用状態と合意グラフとを参照することにより、対象システムにおける通常の運用状態からの逸脱が生じていないかを監視する。そして、通常の運用状態からの逸脱が検出されると（ステップＳ１３：Ｙｅｓ）、合意グラフから合意形成に関する情報データが抽出される（ステップＳ１４）。合意形成に関する情報データとしては、例えば、上述の契約書が想定される。

このように、本発明の実施の形態によれば、対象システムの通常の運用状態に関する議論を通じた合意形成の過程において得られた履歴を合意グラフとして記憶し、この合意グラフに基づいて対象システムの運用状態を監視するとともに、合意形成に関する情報データを抽出することができる。

なお、上述の実施の形態は本発明を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。ただし、本発明は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。

１００−０１ 変化対応サイクル
１００−０２ 障害対応サイクル
２００−０１ ディペンダビリティ維持リポジトリシステム
２００−０２ 基本ツール層
２００−０３ モデル層
２００−０４ データベース層
２００−０５ 合意形成支援ツール
２００−０６ 契約書生成ツール
２００−０７ モニタノードツール

Claims (5)

1. 対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う合意形成部と、
   前記合意形成の過程において得られた履歴を合意グラフとして記憶する合意グラフ記憶部と、
   前記対象システムの実際の運用状態と前記合意グラフとから前記対象システムにおける前記通常の運用状態からの逸脱を検出する検出部と、
   前記対象システムにおいて前記逸脱が検出された際に前記合意グラフから前記合意形成に関する情報データを抽出する抽出部と
   を具備するデータベースシステム。
2. 前記合意形成部は、前記対象システムを定義する複数のモデルを基底として前記合意グラフを生成し、
   前記複数のモデルの各々は、前記対象システムに関する言葉の意味を一義的に定義し、前記対象システムに関する操作の効果を一義的に定義し、前記対象システムに関するデータの論理的定義と物理的定義とを一義的に関係付ける
   請求項１記載のデータベースシステム。
3. 前記対象システムのライフサイクルを構成する複数の段階における複数のステークホルダの活動を通じて生成される前記対象システムに関する文書を前記合意グラフと関連付けて記憶する文書記憶部
   をさらに具備する請求項１記載のデータベースシステム。
4. 前記合意グラフは、前記対象システムの目的または環境の変化に対して前記対象システムを継続的に変更していくための変化対応サイクル、および、前記対象システムにおける障害に対応するための障害対応サイクルの両サイクルにおいてアクセスされる
   請求項１記載のデータベースシステム。
5. 対象システムの通常の運用状態に関する議論を通じて合意形成を行うための支援を行う合意形成手順と、
   前記合意形成の過程において得られた履歴を合意グラフとして記憶する合意グラフ記憶手順と、
   前記対象システムの実際の運用状態と前記合意グラフとから前記対象システムにおける前記通常の運用状態からの逸脱を検出する検出手順と、
   前記対象システムにおいて前記逸脱が検出された際に前記合意グラフから前記合意形成に関する情報データを抽出する抽出手順と
   を具備するデータベースシステムの制御方法。

Images