ディペンダブルシステムのための木構造を用いた合意形成データベースの提案と実装
琉球大学 大城信康
26 April 2013
DEOSプロジェクト
- ITシステムが巨大化していくにつれ、障害発生時例が社会に与える影響は大
- DEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ、制度化、更には事業化を目指しているCRESTのプロジェクト
- 変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供するシステム構築法、DEOSプロセスの開発を目標
DEOS(Dependability Engineering for Open Systems)
- 変化対応サイクル：ステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクル
- 障害対応サイクル：障害に対して迅速に対応して障害による被害を最小化するためのサイクル
DEOSプロセスとD-ADD
- D-ADDはDEOSプロセスで扱われるデータ、システムのログ、契約書、ソースコードといったものを保持するデータベース
- D-ADDで扱うデータにはステークホルダ間で合意された契約書も含まれる。そのため、D-ADDに基本ツールとして合意形成支援ツールが必要
- 本研究では、D-ADDで行われる合意形成のモデルを提案しツールのプロトタイプの実装を行う。
- また、実際に例題の入力を行い、D-ADDにおける合意形成のあり方についての分析を行った。
D-ADD(DEOS Agreement Description Database)
- 基本ツール層：D-ADDにおける基本ツール。Webアプリケーションとして合意形成支援を実装
- モデル層：基本ツール層で扱うデータのモデルの定義。議論のモデルを実装
- リポジトリ層：D-ADDで扱うデータベース。GraphDBを使って実装
D-ADD 説明責任と合意形成
- システム障害発生時、D-ADDは説明責任を果たさなければならない
- 説明責任：障害が発生した理由、次から障害を起こさせないことを説明する責任
- 「なぜそのようなシステムになったのか」を説明しなければならない
- そのためにはD-ADDに入るデータはプロジェクトに係わるステークホルダの合意を得たデータにすべきである
- そこでD-ADD自身に合意形成を行う機能が必要となってくる
- 合意形成を行うシステムをWebアプリケーションとして提供する
合意形成機能の提案、実装
- 合意を取るためのモデルを提案する
- 提案するモデル
- 合意形成を主張・関係・ユーザの要素から構成される.
- まず命題となる合意を取りたい主張があり、それに対する別の主張を立てることで議論を深めていく
- 主張同士には関係が張られ、最初に作られた主張を根とし木構造で議論が深められていく
モデルの概要
- 木構造には閉路が含まれないため、循環論法を生じさせないという狙いがある
- ユーザ・主張・関係は以下のように定義される
- ユーザ：合意形成の参加者
- 主張：ユーザが作成した合意をとりたい、議論すべき内容を含むもの
- 関係：ユーザと主張、もしくは互いに異なる主張と主張の繋がりの種類を表す
- ユーザと主張はノード、関係はエッジとして扱われる
合意状態の計算
- 主張を合意させるには、合意要求を出している全員から合意を受ける必要がある
- 子供となる主張がある場合、関係次第では子となる主張の合意状態も親の主張の合意状態に影響を与える
- 各関係の主張が与える合意状態への影響についての説明は以下となる
- 反論：反論となる子の主張が合意された場合親の主張は合意されない。反論の主張は否認しなければならない。
- 質問：質問となる主張は合意しなければならない。
- 提案：提案となる主張はどの状態であろうと親の合意状態に影響を与えない。
合意状態の計算
- 木構造で議論を表した例
- 根となる主張があり、反論となる主張と質問となる主張と繋がっている
- 根の主張の合意を取るため、反論で繋がっている主張は否認の状態であり、質問は合意の状態となっている
Webアプリケーションのユースケース図
Webアプリケーションの実装
- サーバサイドの実装はJavaを使用した
- クライアントサイドはJavaScript,HTML,CSSで実装を行った
- サーバサイドがREST APIを用意し、主にJSONデータを用いてデータのやりとりを行う
モデルの実装に使用したデータベース
- 議論は木構造で表される。木構造は閉路の無いグラフである
- そこで今回モデルの実装にGraphDBのTinkerGraphを使用する
- GraphDBはノードとエッジによりグラフでデータを表現する
- ノード、エッジともにプロパティを持つことができ、プロパティはkey,valueでデータを保持する
- エッジにはLabelが付けられ、また向き(Direction)がある。
- ノードは自身に繋がっているエッジをLabelとDirectionで指定することで次のノードの情報を得る。 この動作を走査(Traverse)という
GraphDBによるモデルの表現
- 主張、ユーザをノードで表し、関係をエッジで表す
- 「作者」や「合意要求」もエッジで表す
各ノードのプロパティ
- ユーザノードは特にプロパティは持たない
- 主張ノードは以下のプロパティを持つ
- status：主張の合意状態を表す。 passed, failed, unknown の状態がある
- title：主張のタイトル
- content：主張の内容
- toulmin：トゥールミンモデルにおける主張以外の5つの要素が入る
- timestamp：作成された時間を示すタイムスタンプ
- passedは合意されている、failedは否認された、unknownはどちらでも無いという合意状態を表す
エッジのプロパティ
- 主張同士を繋ぐエッジはプロパティを持たない
- ユーザへ伸びる合意要求のエッジが以下のプロパティを持つ
- status：ユーザの主張に対する合意状態を表す。agreed, pend, unknownの状態がある
- 基本、各主張は自身に繋がっている合意要求の関係にあるエッジのstatusが全てagreedかfailedとなる ことで合意か否認にされたとみなされる
時系列ごとにみられる議論と合意状態
- 合意形成が行われる様子を時系列でみたい
- そこで、木のコピーを行い過去の合意状態を見ることができるようにする
- 木全体のコピーを行い、prevの関係になるエッジで繋げる
- prevをたどることで以前の合意状態と木を見ることができ、議論の流れを知ることができる
デモ
- デモ http://nitch.cr.ie.u-ryukyu.ac.jp:9000
- ユーザ名：Akifumiでログイン
合意形成支援Webアプリケーションでの表示
- 各主張のつながりが分かりやすい
redmineでの表示
- redmineはチケットによりプロジェクトを管理する
- 親チケットのbldsvをリフレッシュする、と子チケットのセカンダリDNSサーバをたてる、の繋がりがわかりづらい
時系列にみることの有用性
- 議論を行ううちに、一度は合意されたが否認され、また合意されるとった主張がでてくるかもしれない
- そのような場合は最新の合意状態をみるだけでは確認できない
- 時系列にみることができれば、その議論の流れを知ることができる
- これにより説明責任に使う情報を増やすことができる
| 最新 | 1つ前 | 2つ前 |
|
|
|
|
まとめ
- 議論のモデルを考えWebアプリケーションとして合意形成支援ツールの実装を行い D-ADDにおける合意形成支援についての追求を行った
- 木構造のモデルの提案とGraphDBを用いた実装を行った
- 実際に作成したWebアプリケーションに大学のサーバ管理班の作業となるデータを入力し、redmineに入力した場合と比較した
- redmineで入力した場合に比べ、各主張同士の関係がみやすいことを確認した
- 時系列的に流れをみることで、合意までの議論の流れがより分かりやすくなり、合意全体の 理解を支援できる可能性を見ることができた
- 本システムを使うことにより、DEOSプロセスにおける説明責任を明確にするためのツールを提供することができた
今後の課題
- 議論の木構造が巨大になった際の対処も考えなければならない
- 内容が同じ主張の検知を行っていない。検知をしてマージを行うなり、何かしら解決する機能を考える必要がある
- 同時に、マージが行われた主張が及ぼす影響をより分かりやすくみせることも理想である
- さらに、本実装では主張同士の関係に反論・質問・提案だけであったが、更に増やすことが可能である
- 関係を増やす場合は反論・質問・提案のを元に合意状態へと影響を与える主張を作成する
- どのような関係があればより合意形成支援を行うことができるのか考え行くべきである