タスク管理システムおよびセキュリティ管理支援システム
【課題】企業等の階層構造を有する組織体において、上位部署もしくはその担当者からトップダウンで展開されるタスクの指示や実施状況の管理等を可能とするタスク管理システムを提供する。
【解決手段】タスク管理サーバ１００とクライアント端末４００とからなるタスク管理システム１であって、タスク管理サーバ１００は、タスクを新たに作成し、タスクの指示を受けた各担当者の単位で作業の進捗率およびステータスの管理を行うタスク進捗を作成して、タスクおよびタスク進捗の情報をデータベースに登録し、更新するタスク操作部１１１と、データベースに登録されたタスク進捗のうち、ユーザに関連するタスク進捗を取得して出力するタスク情報取得部１１２と、タスクの実施状況を算出して出力する実施状況管理部１２０と、タスク管理システム１を利用するユーザおよび部署とその階層構造の情報をデータベースに保持して管理する管理部１３０とを有する。
【解決手段】タスク管理サーバ１００とクライアント端末４００とからなるタスク管理システム１であって、タスク管理サーバ１００は、タスクを新たに作成し、タスクの指示を受けた各担当者の単位で作業の進捗率およびステータスの管理を行うタスク進捗を作成して、タスクおよびタスク進捗の情報をデータベースに登録し、更新するタスク操作部１１１と、データベースに登録されたタスク進捗のうち、ユーザに関連するタスク進捗を取得して出力するタスク情報取得部１１２と、タスクの実施状況を算出して出力する実施状況管理部１２０と、タスク管理システム１を利用するユーザおよび部署とその階層構造の情報をデータベースに保持して管理する管理部１３０とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、タスク管理の技術に関し、特に、企業等の組織体においてトップダウンで作業が指示されるタスクを管理するタスク管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
企業等における業務の流れをコンピュータシステムにより制御・管理するワークフロー管理においては、作業単位をタスクとして各部門・部署や担当者に割り当て、その進捗状況などを管理するということが行われる。このようなワークフロー管理によって管理される業務は、一般的に、ワークフローやタスクの生成が、実業務の発生元である下位部門・下位部署や実担当者によって行われ、上位部門・上位部署や上長などに対して申請され承認されるというように、組織の階層構造における下位から上位に向けての一連の業務の流れ、すなわち上り方向のベクトルを有する業務である。
【０００３】
ワークフロー管理においては、一般的に、予め定義されたワークフローの各タスクに対して静的もしくはワークフローの実行状況に応じて動的に担当者が割り当てられる。このとき、例えば、特開平８−９５８７７号公報（特許文献１）に記載されているように、あるタスクを複数の担当者に同報的に割り当てることも可能であるし、特開２００７−１７９２５１号公報（特許文献２）に記載されているように、タスクを割り当てられた担当者が、他の担当者にタスクを委任することも可能である。一般的にはこれら各タスクの進捗状況を管理することによりワークフロー全体の進捗状況を判断する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平８−９５８７７号公報
【特許文献２】特開２００７−１７９２５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一方で、企業等の階層構造の組織においては、例えば、マネジメント層から直近の下位部署に対して一斉同報的に作業の実施を指示し、当該下位部署がさらに直近の下位部署に同様の指示を展開して階層構造の末端の担当者にまで作業指示が届く、というようにトップダウンで上位から下位に組織の階層構造に応じてタスクが１対多で増幅されて指示される、すなわち下り方向のベクトルを有する業務も多い。
【０００６】
このような業務における各タスクの進捗管理は、上記のようなワークフロー管理の仕組みで対応することが難しい場合が多く、現状ではまだ電話や電子メール等で個別に確認して手作業により集計しているケースも多い。また、組織の階層構造が深くなるほど、進捗を確認する対象の下位部署や担当者の数が１対多で累積的に増幅されるため、タスクの進捗や実績を管理するのはより煩雑となる。
【０００７】
そこで本発明の目的は、企業等の階層構造を有する組織体において、上位部署もしくはその担当者からトップダウンで展開されるタスクの指示や実施状況の管理等を可能とするタスク管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【０００９】
本発明の代表的な実施の形態によるタスク管理システムは、階層構造を有する複数の部署からなる組織体における、前記部署の階層構造の上位の担当者から配下の下位の担当者に対しての作業実施の指示であるタスクの情報を保持し、前記タスクの実施状況の管理を行うタスク管理サーバと、前記タスク管理サーバにネットワーク経由で接続するクライアント端末とからなるタスク管理システムであって、以下の特徴を有するものである。
【００１０】
すなわち、前記タスク管理システムにおいて、前記タスク管理サーバは、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して指示する前記タスクを新たに作成し、前記タスクの指示を受けた各担当者の単位で前記タスクに係る作業の進捗率およびステータスの管理を行うタスク進捗を作成して、前記タスクおよび前記タスク進捗の情報を前記データベースに登録し、また、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記データベースに登録された前記タスクおよび前記タスク進捗の内容を修正して更新するタスク操作部と、前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力するタスク情報取得部と、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出して出力する実施状況管理部と、当該タスク管理システムを利用する前記ユーザおよび前記部署とその階層構造の情報を前記データベースに保持して管理する管理部とを有することを特徴とするものである。
【発明の効果】
【００１１】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１２】
本発明の代表的な実施の形態によれば、企業等の階層構造を有する組織体において、部署の階層構造における配下の担当者に対して作業を指示するタスクを作成し、当該タスクの指示を受けた担当者単位で当該タスクに係る作業の進捗率およびステータス等の管理を行うタスク進捗を作成して、これらの情報をデータベースに保持して管理することで、組織の階層構造に基づいてタスクの指示を容易に行い、また、タスクの実施率の算出やタスクの情報の参照範囲の制限などを含む実施状況の管理を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態１であるタスク管理システムの構成例の概要を示す図である。
【図２】本発明の一実施の形態のタスク管理システムが適用される企業等における一般的な組織の階層構造の一部について例を示す図である。
【図３】本発明の一実施の形態のタスク管理システムにおいて管理されるタスクの概念を説明する図である。
【図４】本発明の一実施の形態のタスク管理システムにおけるタスク（タスク進捗）の状態遷移図の例である。
【図５】本発明の実施の形態１におけるユーザ・部署ＤＢのテーブルの構成例を示した図である。
【図６】（ａ）、（ｂ）は、本発明の実施の形態１におけるタスクＤＢのテーブルの構成例および具体的なデータの例を示した図である。
【図７】（ａ）、（ｂ）は、本発明の実施の形態１におけるタスク進捗ＤＢのテーブルの構成例および具体的なデータの例を示した図である。
【図８】本発明の実施の形態１におけるユーザに関連するタスクの情報を表示するトップ画面の例を示した図である。
【図９】本発明の実施の形態１におけるタスクを新規作成する画面の例を示した図である。
【図１０】本発明の実施の形態１におけるタスク進捗の進捗状況（ステータス）を更新する画面の例を示した図である。
【図１１】本発明の実施の形態１におけるタスク進捗の実施状況を横比較した結果を表示する画面の例を示した図である。
【図１２】本発明の実施の形態１におけるタスク進捗の実施状況を下比較した結果を表示する画面の例を示した図である。
【図１３】本発明の実施の形態１におけるタスク進捗の実施率を算出する処理の流れの例を示すフローチャートである。
【図１４】本発明の実施の形態１におけるタスク進捗の実施状況を横比較する際の処理の流れの例を示すフローチャートである。
【図１５】本発明の実施の形態１におけるタスク進捗の実施状況を下比較する際の処理の流れの例を示すフローチャートである。
【図１６】本発明の実施の形態２であるセキュリティ管理支援システムの構成例の概要を示す図である。
【図１７】本発明の実施の形態２であるセキュリティ管理支援システムを利用したセキュリティ管理業務の流れの概要を示した図である。
【図１８】本発明の実施の形態２における資産ＤＢのテーブルの構成例を示した図である。
【図１９】本発明の実施の形態２における管理策ＤＢのテーブルの構成例を示した図である。
【図２０】本発明の実施の形態２における計画策定ＤＢのテーブルの構成例を示した図である。
【図２１】本発明の実施の形態２における診断ＤＢのテーブルの構成例を示した図である。
【図２２】本発明の実施の形態２における現状のセキュリティレベルの診断結果を表示するセキュリティ診断画面の例を示した図である。
【図２３】本発明の実施の形態２における現状のセキュリティレベルの診断結果を部署毎に比較して表示する部署比較画面の例を示した図である。
【図２４】本発明の実施の形態２における現状のセキュリティレベルの診断結果を管理策カテゴリ毎に比較して表示するレーダーチャート画面の例を示した図である。
【図２５】本発明の実施の形態２における目標セキュリティレベルの値とこれまでのセキュリティレベルの値とを比較して表示する経年予実比較画面の例を示した図である。
【図２６】本発明の実施の形態２における現状のセキュリティレベルの診断結果を管理策毎に詳細に表示する診断明細照会画面の例を示した図である。
【図２７】本発明の実施の形態２における現状のセキュリティレベルの診断結果を資産毎に詳細に表示する診断明細照会（詳細）画面の例を示した図である。
【図２８】本発明の実施の形態２における自部署のセキュリティレベルの目標を設定する自部署目標設定画面の例を示した図である。
【図２９】本発明の実施の形態２における下位部署のセキュリティレベルの目標を設定する下位部署目標設定画面の例を示した図である。
【図３０】本発明の実施の形態２における計画策定画面の例を示した図である。
【図３１】本発明の実施の形態２における自部署のセキュリティ対策の診断結果を入力する診断明細入力画面の例を示した図である。
【図３２】本発明の実施の形態２における自部署のセキュリティ対策の診断結果を資産毎に入力する診断明細入力（詳細）画面の例を示した図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１５】
＜概要＞
以下では、まず、本発明の一実施の形態であるタスク管理システムにおけるタスクおよびタスクの階層構造について概要を説明する。図２は、タスク管理システムが適用される企業等の一般的な組織の階層構造の一部について例を示す図である。例えば、最高情報セキュリティ責任者（ＣＩＳＯ）をトップに営業本部、情報システム本部、業務本部が配下に組織されている。各本部には責任者として本部長が存在する。
【００１６】
また、営業本部の配下には、例えば営業一部、二部が組織され、それぞれに責任者として部長が存在する。さらに、営業一部、二部にはそれぞれ一般従業員として２人の従業員が在籍する。同様に、情報システム本部の配下には、例えば情報システム部、基盤システム部が組織され、それぞれに責任者として部長が存在する。さらに、情報システム部には一般従業員として２人の従業員が在籍する。
【００１７】
ここで、上位組織がＣＩＳＯで共通である営業本部、情報システム本部、業務本部は同一階層の組織である。同様に、営業一部、二部はそれぞれ上位組織が営業本部で共通あり同一階層の組織である。また、情報システム部、基盤システム部は上位組織が情報システム本部であり同一階層の組織である。なお、図２の例では、業務本部および基盤システム部には配下の下位部署および在籍する従業員が存在しない。
【００１８】
図３は、タスク管理システムにおいて管理されるタスクの概念を説明する図である。ここでのタスクとは、組織の階層構造における上位の担当者から配下の下位の担当者に対しての作業実施の指示であり、このような上位部署からトップダウンで展開されるタスクの例として、図３では、企業でのセキュリティ管理における管理策として企業全体での実施が必要である「ＰＣ資産管理台帳の更新」という作業を、図２の組織階層におけるＣＩＳＯがタスクとして指示した場合を例としている。
【００１９】
ＣＩＳＯは、当該タスクの起点となり、まず、配下の組織の担当者である営業本部本部長、情報システム本部本部長、業務本部本部長に「ＰＣ資産管理台帳の更新」というタスク（Ｔ１）を指示している。すなわち、タスク（Ｔ１）では、指示者はＣＩＳＯであり３人の各本部長は指示受け者である。このように、複数の担当者に同報的にタスクを指示することができる。なお、タスクの起点である担当者（ＣＩＳＯ）が指示したタスク（Ｔ１）は元タスクとして識別される。
【００２０】
各タスクのステータスは、タスクの指示受け者の単位で管理される。タスク（Ｔ１）の指示受け者である営業本部本部長は、当該タスクをさらに配下の組織の担当者である営業一部部長、二部部長に再指示（以下では「再アサイン」と記載する場合がある）して展開している。従って、タスク（Ｔ１）について営業本部本部長が指示受け者となっている部分についてはステータスは「指示済」となっている。このように、タスクにおけるタスクの指示受け者毎のステータスの管理単位をこれ以降「タスク進捗」と呼ぶものとする。
【００２１】
営業本部本部長と同様に、情報システム本部本部長も配下の組織の担当者である情報システム部部長、基盤システム部部長にタスクを再アサインしており、情報システム本部本部長が指示受け者となっているタスク進捗のステータスは「指示済」となっている。一方、業務本部本部長は配下の組織および担当者が存在しないため、タスク（Ｔ１）は自身で実施する必要がある。業務本部本部長はタスク（Ｔ１）を再アサインしておらず、自身でも未だ作業着手していないため、タスク進捗のステータスは「未指示」となっている。なお、タスク進捗のステータスについては後述する。
【００２２】
営業本部本部長から営業一部部長、二部部長に再アサインされたタスク（Ｔ２）は、タスク（Ｔ１）を親タスクとした子タスクとして識別される。また、タスク（Ｔ２）について、指示者は営業本部本部長であり２人の各部長は指示受け者である。タスク（Ｔ２）の指示受け者である営業一部部長は、当該タスクをさらに配下の担当者である営業一部＃１、＃２に再アサインしている。また、図３の例ではさらに、営業一部部長自身もＰＣ資産を有しており「ＰＣ資産管理台帳の更新」の作業を実施する必要があることから、自分自身にもタスクを指示している。従って、営業一部部長が再アサインしたタスク（Ｔ４）の指示受け者には、営業一部＃１、＃２に加えて営業一部部長自身も含まれる。
【００２３】
また、タスク（Ｔ２）の指示受け者である営業二部部長は、当該タスクを配下の担当者（営業二部＃１、＃２）に未だ再アサインしておらず、自身でも作業着手していないため、タスク進捗のステータスは「未指示」となっている。この場合、営業二部部長は、原則として当該タスクを配下の担当者に再アサインすることも自身で実施することも可能である。自身で実施した場合にはもはや当該タスクを再アサインすることはできなくなる。このように、タスクの階層構造は組織の階層構造に基づいて構成されるが、同一の構成になるとは限らない。
【００２４】
タスク（Ｔ４）では、営業一部＃１はタスク（Ｔ４）を再アサインしておらず、自身でも未だ作業着手していないため、タスク進捗のステータスは「未指示」となっている。また、営業一部＃２は「ＰＣ資産管理台帳の更新」の作業を全て完了しているため、タスク進捗のステータスは「完了」となっている。また、営業一部部長は「ＰＣ資産管理台帳の更新」の作業を着手しているが未完了であるため、タスク進捗のステータスは「未完了」となっている。
【００２５】
その他のタスク（Ｔ３、Ｔ５）やタスク進捗についても上記と同様であるため説明は省略する。なお、図中において各タスク（タスク進捗）の指示者・指示受け者の名称に付されている括弧内の文字（「Ａ」〜「Ｌ」）は、それぞれの担当者のユーザＩＤを表しているものとする。
【００２６】
図４は、タスク（タスク進捗）の状態遷移図の例である。タスクが指示者から指示受け者に対して指示（もしくは再アサイン）されたとき、指示受け者におけるタスク進捗のステータスの初期状態は未指示（Ｓ１）である。この状態では、指示受け者は当該タスクについて再アサインしておらず、自身での実施も未着手である。
【００２７】
ステータスが未指示（Ｓ１）の状態では、指示受け者は、上述したように、原則として当該タスクを配下の担当者に再アサインすることも、自身で作業を実施することも可能である。当該タスクを再アサインした場合は、当該指示受け者におけるタスク進捗のステータスは指示済（Ｓ３）に遷移する。指示済（Ｓ３）に遷移したタスク進捗は、当該タスク進捗に係る作業を指示受け者が実施することはもはやできないため、これ以上ステータスが遷移することはない。
【００２８】
なお、タスクは原則として配下の担当者に再アサインすることができるが、指示者から「再アサイン不可」の指定が付されて指示されたタスクの場合は、再アサインすることはできない。すなわち、自身が作業を実施しなければならない。配下の担当者が存在しない末端の指示受け者の場合も実質的には再アサイン不可である。これらのタスク進捗については、指示済（Ｓ３）のステータスに遷移することはできない。
【００２９】
一方、ステータスが未指示（Ｓ１）の状態から指示受け者がタスク進捗のステータスに「未完了」を指定した場合は、タスク進捗のステータスは未完了（Ｓ２）に遷移する。なお、タスク進捗のステータスに「未完了」を指定する代わりに、当該タスク進捗に係る作業が一部実行された旨の進捗率（例えば「５０％」など）を指定することで未完了（Ｓ２）に遷移させてもよい。また、新たに指示されたタスクが再アサイン不可の場合は、必然的に指示受け者自身が実施することになるため、ステータスは自動的に未指示（Ｓ１）から未完了（Ｓ２）に遷移する。このときの進捗率は０％である。
【００３０】
ステータスが未完了（Ｓ２）の状態で、タスク進捗のステータスに「未完了」を指定した場合（もしくは作業の進捗率を更新した場合）は、タスク進捗のステータスは未完了（Ｓ２）で不変である。なお、タスク進捗のステータスに「未指示」を指定する（もしくは作業の進捗率に０％を指定する）と、ステータスを未指示（Ｓ１）に戻すことも可能である。
【００３１】
また、ステータスが未完了（Ｓ２）の状態で、作業実施が不能である等の事情により、当該タスクを配下の担当者に再アサインすることも可能である。この場合、ステータスは指示済（Ｓ３）に遷移する。また、ステータスが未完了（Ｓ２）の状態で、タスク進捗のステータスに「完了」を指定した場合（もしくは作業の進捗率に１００％を指定した場合）は、タスク進捗のステータスは完了（Ｓ４）に遷移して終了する。すなわち、ステータスが完了（Ｓ４）になったタスク進捗のステータスはこれ以上変更されることはないため、当該タスク進捗の指示受け者が確かに作業を行ったということの証跡の情報とすることができる。
【００３２】
このように、本実施の形態のタスク管理システムでは、上位部署からトップダウンで展開するタスクを組織階層の構造に基づいて再アサインにより展開可能とし、展開した階層毎に親タスク、子タスクとして管理する。各階層のタスクでは、指示受け者単位でタスク進捗としてステータスを管理する。
【００３３】
＜実施の形態１＞
［システム構成］
以下では、本発明の実施の形態１であるタスク管理システムについて説明する。図１は、本発明の実施の形態１であるタスク管理システムの構成例の概要を示す図である。タスク管理システム１は、例えば、タスク管理サーバ１００およびデータベースと、タスク管理サーバ１００にインターネットや社内ＬＡＮ等のネットワークを介して接続されたクライアント端末４００から構成される。
【００３４】
タスク管理サーバ１００は、コンピュータシステムからなるサーバ機器によって構成され、例えば、タスク実施管理部１１０、実施状況管理部１２０、管理部１３０などを有する。これら各部はソフトウェアプログラムとして実装され、例えば、タスク管理サーバ１００上の図示しないＷｅｂサーバプログラムと連携してクライアント端末４００からの処理要求を受けて所定の処理を行い、クライアント端末４００に対して処理結果の画面を提示する等の処理を行う。
【００３５】
タスク実施管理部１１０は、例えば、タスク操作部１１１、タスク情報取得部１１２を有する。タスク操作部１１１は、クライアント端末４００を介したユーザからの要求によるタスクの新規作成（指示）、再アサインといった処理を行い、当該タスクの情報をその階層構造の情報とともにデータベースに登録する。また、対象のタスクの指示を受けた指示受け者の単位でタスクの進捗率やステータスを管理するタスク進捗をデータベースに登録する。また、タスクおよびタスク進捗の内容の修正、進捗状況の更新などの操作を行い、データベースを更新する。
【００３６】
タスク情報取得部１１２は、クライアント端末４００を介したユーザからの要求により、対象のユーザに関連するタスク進捗の情報（当該ユーザが指示もしくは再アサインしたタスクおよび当該ユーザが指示されたタスクにおける当該ユーザに係るタスク進捗）をデータベースから取得して出力する。
【００３７】
実施状況管理部１２０は、クライアント端末４００を介したユーザからの要求により、タスクの階層構造に基づいて、当該ユーザが指示されたタスクについての実施状況（実施率や未実施者など）を算出して出力する。また、管理部１３０は、タスク管理システム１を利用するユーザおよび部署とその階層構造の情報、その他のシステム的な情報などをデータベースに保持して管理する機能を実現する。また、ユーザの情報を利用してユーザのログイン時の認証なども行う。なお、上記各部の構成はあくまで一例であり、さらに上記以外の各部を有していてもよいし、また、上記各部の一部または全部がまとめられていたり、さらに細かく分けられたりしていてもよい。
【００３８】
タスク管理サーバ１００は、さらに例えば、ユーザ・部署ＤＢ２１０、タスクＤＢ２６０、タスク進捗ＤＢ２７０の各データベースを有する。ユーザ・部署ＤＢ２１０は、タスク管理システム１を利用する企業等の組織におけるユーザおよび部署とその階層構造などの情報を保持する。タスクＤＢ２６０は、タスク管理システム１によって管理されているタスクおよびその階層構造の情報を保持する。
【００３９】
タスク進捗ＤＢ２７０は、タスクＤＢ２６０に保持・管理されている各タスクについて指示受け者（タスク進捗）単位でのステータス等の情報を保持する。なお、これら各データベースは、タスク管理サーバ１００が直接保持する構成でもよいし、別のデータベースサーバ等に保持してネットワーク経由でアクセスする構成としてもよい。これら各データベースの詳細については後述する。
【００４０】
クライアント端末４００は、ユーザ（各部署の担当者など）に対してタスク管理サーバ１００の各機能を利用するためのユーザインタフェースを提供する機器であり、ＰＣや携帯端末などにより構成される。例えば図示しないＷｅｂブラウザを有し、タスク管理サーバ１００上の図示しないＷｅｂサーバプログラムとネットワーク経由により連携して、上記機能を実行するための指示を行ったり、実行結果の画面をユーザに提示したりする。
【００４１】
［データベース構成］
図５は、ユーザ・部署ＤＢ２１０のテーブルの構成例を示した図である。ユーザ・部署ＤＢ２１０は、タスク管理システム１を利用する企業等のユーザや部署およびその階層構造等を保持するデータベースであり、例えば、会社テーブル２１１、部署テーブル２１２、所属部署テーブル２１３、担当ロールテーブル２１４、ロールテーブル２１５、ユーザテーブル２１６のテーブルから構成される。なお、図中のテーブル間の矢印は、例えば、Ａ→Ｂである場合に、Ａ：Ｂ＝１：ｎの関係（A has many Bs）にあることを示している。
【００４２】
会社テーブル２１１は、例えば、会社ＩＤ、会社名などの会社の属性に関する項目を有する。部署テーブル２１２は、例えば、部署ＩＤ、会社ＩＤ、上位部署ＩＤ、部署名、場所などの各部署の属性に関する項目を有する。上位部署ＩＤの項目を有することにより、各部署の階層構造を保持・把握することができる。ロールテーブル２１５は、例えば、ロールＩＤ、会社ＩＤ、ロール名などの項目を有する。ロール名は、例えば、「ＣＩＳＯ」、「各部署セキュリティ管理者」、「一般社員」など、ユーザに割り当てられるロール（役割）の種別である。ユーザのロールに応じて利用可能な機能を制限してもよい。
【００４３】
ユーザテーブル２１６は、例えば、ユーザＩＤ、会社ＩＤ、パスワード、ユーザ名、メールアドレスなどの各ユーザの属性に関する項目を有する。ユーザがタスク管理システム１にログインする際の認証に使用されるデータや、認証結果などの情報も保持する。所属部署テーブル２１３は、例えば、ユーザＩＤ、部署ＩＤなどの項目を有し、ユーザが所属する部署の情報を保持する。部署が階層構造となっていることから、ユーザが所属する部署も複数の階層（例えば「○○部××課」など、直接所属する部署とその上位部署）にわたる場合がある。
【００４４】
また、担当ロールテーブル２１４は、例えば、ユーザＩＤ、ロールＩＤなどの項目を有し、ユーザが担当するロールの情報を保持する。一人のユーザが複数のロールを担当しているという場合もある。これらのユーザ・部署ＤＢ２１０の各テーブルの情報は、例えば、システム管理者や人事担当者等によって、管理部１３０により予め登録され、また更新などの管理が行われる。
【００４５】
図６（ａ）、（ｂ）は、タスクＤＢ２６０のテーブルの構成例および具体的なデータの例を示した図である。タスクＤＢ２６０は、タスク管理システム１によって管理されているタスクおよびその階層構造の情報を保持するデータベースであり、例えば、タスクテーブル２６１、カテゴリテーブル２６２のテーブルから構成される。
【００４６】
タスクテーブル２６１は、例えば、タスクＩＤ、タスクタイトル、期日、作成日、カテゴリＩＤ、親タスクＩＤ、元タスクＩＤ、指示者ユーザＩＤなどのタスクの属性に関する項目を有する。ここでのタスクとは、図３に示したタスクの階層構造における各階層のタスク（例えばＴ１〜Ｔ５）を指し、このタスク毎にタスク操作部１１１によってユニークなタスクＩＤが割り振られる。親タスクＩＤや元タスクＩＤの項目を有することにより、上述したタスクの階層構造を保持・把握することができる。なお、図６（ｂ）は、図３に示したタスクの階層構造を例とした場合のタスクテーブル２６１の具体的なデータの例を示している。
【００４７】
カテゴリテーブル２６２は、例えば、カテゴリＩＤ、カテゴリ名などの、タスクのカテゴリの種類を表すための項目を有する。カテゴリ名は、例えば、「セキュリティ対策」や「月次報告」などである。
【００４８】
図７（ａ）、（ｂ）は、タスク進捗ＤＢ２７０のテーブルの構成例および具体的なデータの例を示した図である。タスク進捗ＤＢ２７０は、タスクＤＢ２６０に保持・管理されている各タスクについての指示受け者（タスク進捗）単位でのステータス等の情報を保持するデータベースであり、例えば、タスク進捗ＩＤ、タスクＩＤ、指示受け者ユーザＩＤ、進捗率、ステータスＩＤ、完了フラグ、完了日、再アサインフラグ、コピーフラグなどのタスク進捗の属性に関する項目を有する。
【００４９】
タスク進捗毎にタスク操作部１１１によってユニークなタスク進捗ＩＤが割り振られ、タスクＩＤ、指示受け者ユーザＩＤの項目を有することで、属するタスクおよび指示受け者を把握することができる。このタスク進捗毎に、進捗率や図４に示したステータスの状況を保持・管理する。
【００５０】
完了フラグの項目は、タスク進捗の完了・未完了を容易に判断可能とするため、ステータスＩＤが完了（Ｓ４）を示すものを「完了」とし、それ以外のステータスのものを「未完了」とする。また、再アサインフラグの項目は、「再アサイン不可」の指定が当該タスク進捗の指示者からされているか否かを示すフラグであり、コピーフラグの項目は、再アサインする際にタスクの内容をコピーすることが指示者から許可されているか否かを示すフラグである。
【００５１】
ステータステーブル２７２は、例えば、ステータスＩＤ、ステータス名などの、タスク進捗のステータスの種類を表すための項目を有する。ステータス名は、図４に示した各ステータスの名称をそれぞれ保持する。なお、図７（ｂ）は、図３に示したタスクの階層構造を例とした場合のタスク進捗テーブル２７１の具体的なデータの例を示している。ステータスＩＤの項目には、便宜上、ステータスＩＤの値ではなくステータステーブル２７２のステータス名の値で変換したものを示している。
【００５２】
［タスク実施管理］
以下では、ユーザがクライアント端末４００を介してタスク管理サーバ１００にアクセスし、タスクの新規作成（指示）、再アサインや、内容の修正、進捗状況の更新などのタスクについての操作を行う際の処理内容について説明する。
【００５３】
ユーザがクライアント端末４００からタスク管理サーバ１００にログインすると、タスク実施管理部１１０のタスク情報取得部１１２は、タスクＤＢ２６０およびタスクＤＢ２７０を参照して、例えば、図８に示すような、当該ユーザに関連するタスクの情報を表示するトップ画面を生成してクライアント端末４００上に表示する。
【００５４】
図８では図２、図３における営業本部本部長がログインした際の画面例を示している。この画面では、「未処理タスク一覧」として、当該ユーザが指示受け者となっているタスクのタスク進捗であり、かつステータスが未指示（Ｓ１）もしくは未完了（Ｓ３）のものの一覧が表示されている。未処理タスク一覧に表示されたタスク（タスク進捗）は、当該ユーザによる実施もしくは再アサインの処理を要するものである。また、これに付随して、「指示受け一覧」ボタンを押下すると、図示しないが、当該ユーザが指示受け者となっている、完了（Ｓ４）や指示済（Ｓ２）も含んだ全てのタスク進捗の一覧を表示することが可能である。
【００５５】
同様に、「処理待ちタスク一覧」として、当該ユーザが指示者となっているタスクに含まれるタスク進捗であり、かつステータスが未指示（Ｓ１）もしくは未完了（Ｓ３）のものの一覧が表示されている。処理待ちタスク一覧に表示されたタスク（タスク進捗）は、当該ユーザが指示を行い、指示受け者（配下の担当者）による実施もしくは再アサインの処理を要するものである。また、これに付随して、「指示一覧」ボタンを押下すると、図示しないが、当該ユーザが指示者となっているタスクに含まれるタスク進捗であり、完了（Ｓ４）や指示済（Ｓ２）も含んだ全てのタスク進捗の一覧を表示することが可能である。
【００５６】
このように、ログインしたユーザによって参照することができるタスク（タスク進捗）の範囲を制限しているが、ユーザの権限（部署やロール等）によって参照することができる範囲（部署、ユーザや、組織階層など）が拡大可能なように制御することも可能である。
【００５７】
図８の画面において、「新規作成」ボタンを押下することによって、当該ユーザが起点となって新たにタスクを作成して指示することができる。図９は、タスクを新規作成する画面の例を示した図である。
【００５８】
図９の画面において、ユーザはタスク名やカテゴリ、内容、担当者（指示受け者）などの情報を設定してタスクを新たに作成することができる。担当者を指定する際には、プルダウンメニューやリスト等によりユーザ・部署ＤＢ２１０に保持されている組織の階層構造の情報を提供することができ、容易に組織の階層構造に沿ったタスクの指示を行うことができる。このとき例えば、自身が属する部署および配下の部署に属する担当者のみがプルダウンメニューに表示されるように制御することでタスクの指示範囲を制限することができる。
【００５９】
さらに、タスクの作成時に、当該タスクの担当者（指示受け者）がさらに配下の担当者にタスクを再アサインすることを許可するか否か、および許可する場合に、指示受け者がタスクを再アサインする際に当該画面で指定したタスクの内容をコピーして再アサインすることを許可するか否かを指定することができる。タスク操作部１１１は、これらの設定内容に従ってタスクＤＢ２６０およびタスク進捗ＤＢ２７０に新たにタスクおよびタスク進捗を作成する。
【００６０】
また、図８の画面において、「未処理タスク一覧」に表示されたタスク進捗の「進捗更新」ボタンを押下することによって、当該タスク進捗のステータスを更新することができる。図１０は、タスク進捗の進捗状況（ステータス）を更新する画面の例を示した図である。図１０の画面において、ユーザは、当該タスク進捗に係る実作業の進捗状況に応じて進捗率やステータスを入力することができる。タスク操作部１１１は、入力内容に従ってタスク進捗ＤＢ２７０の内容を更新する。
【００６１】
さらに、当該タスク進捗が指示者によって再アサイン不可の指定がされていない場合は、「再アサイン」ボタンが押下可能となっており、これを押下することによってユーザは当該タスクの実施を配下の担当者に再アサインすることができる。このとき、図９に示したタスクの新規作成時の画面と同様な画面が表示され、タスクの内容や再アサインする担当者を設定することができる。
【００６２】
なお、当該タスク進捗に指示者によってタスク内容のコピー不可の指定がされていなかった場合は、タスクの再アサインを行う画面において、期日や内容などの情報が再アサインするタスクにそのまま引き継がれて設定される。タスク操作部１１１は、設定内容に従ってタスクＤＢ２６０およびタスク進捗ＤＢ２７０に新たに再アサインしたタスクおよびタスク進捗を作成する。
【００６３】
図１０の画面においてタスクの進捗率を１００％としてステータスを完了（Ｓ４）とした場合は、当該タスク進捗は図８の「未処理タスク一覧」から消える。また、タスクを再アサインしてタスク進捗のステータスを指示済（Ｓ２）とした場合は、当該タスク進捗は図８の「未処理タスク一覧」から消え、「処理待ちタスク一覧」に新たに表示される。
【００６４】
また、図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「修正」ボタンを押下することによって、再アサインした当該タスク進捗の内容を修正することができる。このとき、図９に示したタスクの新規作成時の画面と同様な画面が表示され、内容や期日などの情報を修正することができる。また、組織の人事異動等に伴って担当者が変更になる場合は指示受け者である担当者を変更することも可能である。タスク操作部１１１は、修正内容に従ってタスク進捗ＤＢ２７０の内容を更新する。
【００６５】
また、図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「削除」ボタンを押下することによって、再アサインした当該タスク進捗を削除（指示を取り消し）することもできる。タスク操作部１１１は、指定されたタスク進捗をタスク進捗ＤＢ２７０から削除する。
【００６６】
この際、削除したタスク進捗と同じタスクＩＤを有するタスク進捗が他に存在しない場合、すなわち、当該タスク進捗が属する子タスクに含まれるタスク進捗が全て削除された場合は、タスク操作部１１１は、タスクＤＢ２６０およびタスク進捗ＤＢ２７０を参照して当該子タスクを指示した親タスクのタスク進捗を特定し、そのステータスを指示済（Ｓ２）から未指示（Ｓ３）に更新することによって再アサインがされなかったものとする。
【００６７】
［タスク実施状況管理］
以下では、ユーザがクライアント端末４００を介してタスク管理サーバ１００にアクセスし、タスクの階層構造に基づいた実施状況（実施率や未実施者など）の情報を参照する際の処理内容について説明する。
【００６８】
上述の図８の画面において、「未処理タスク一覧」に表示されたタスク進捗の「実施状況」ボタンを押下することによって、ユーザは当該タスク進捗の実施状況を、同じ指示者から対象のタスクの指示・再アサインを受けた他の担当者に係るタスク進捗との間で比較（横比較）することができる。図１１は、タスク進捗の実施状況を横比較した結果を表示する画面の例を示した図である。
【００６９】
図１１の画面では、営業本部本部長がＣＩＳＯから指示されたタスクについて、ＣＩＳＯから当該タスクについて同様に指示を受けた情報システム本部本部長、業務本部本部長との間でタスク進捗の実施率を比較（横比較）して表示している。これにより、自身に指示されたタスク（タスク進捗）の実施状況を、階層的に横の部署の他の担当者に係るタスク進捗の実施状況と比較して進捗状況を判断することができる。
【００７０】
ここでの実施率（％および件数）は、実施状況管理部１２０が、対象のタスク進捗に対して、タスクの階層構造における自身を含む下位に属する全てのタスク進捗について、例えば、
実施率＝（完了（Ｓ４）の件数）／
（未指示（Ｓ１）or未完了（Ｓ２）or（完了Ｓ４）の件数） …式（１）
の式によって算出する。実施状況管理部１２０における実施率の算出処理の詳細については後述する。
【００７１】
また、上述の図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「実施状況」ボタンを押下することによって、ユーザは当該タスク進捗の実施状況を、自身が再アサインにより指示した配下の担当者に係るタスク進捗の間で比較（下比較）することができる。図１２は、タスク進捗の実施状況を下比較した結果を表示する画面の例を示した図である。図１２の画面では、営業本部本部長が指示したタスクについて、指示受け者である営業一部部長および営業二部部長の間で式（１）によって算出したタスク進捗の実施率を比較（下比較）して表示している。
【００７２】
図１２に示す下比較の場合は、図１１に示す横比較の場合と異なり、自身の配下の部署に係る実施状況の確認であるため、例えば、図１２における「未完了／未実施者」の項目のような未完了者や未実施者の具体的な情報など、さらに詳細な情報を参照可能とするよう参照権限を強化してもよい。また、担当者がさらに再アサインによって配下の担当者にタスクを指示している場合は、それらのタスク進捗についても式（１）によって実施率を算出してタスクの階層毎に表示するようにしてもよい。
【００７３】
［タスク実施状況管理（処理フロー）］
図１３は、タスク進捗毎の実施率を算出する処理の流れの例を示すフローチャートである。あるタスク進捗の実施率は、上述したように、例えば、対象のタスク進捗について、タスクの階層において自身を含む下位に属する全てのタスク進捗を対象に式（１）の計算を行って求めることができる。このタスク進捗実施率算出処理は、上述したタスク実施状況の横比較、下比較のいずれにおいても利用される。
【００７４】
図１３において、実施状況管理部１２０は、事前に実施率の分子および分母となる値を初期化しておく。その後、実施率の算出対象となるタスク進捗（タスク進捗ＩＤ）を入力パラメータとしてタスク進捗実施率算出処理を開始すると、まず、対象のタスク進捗のステータスが指示済（Ｓ２）であるか否かを確認する（Ｓ１０１）。
【００７５】
ステップＳ１０１でステータスが指示済（Ｓ２）でない場合は、対象のタスク進捗は再アサインされておらず、現時点でタスクの階層構造における末端であることを示す。従って、実施率の分母に１を加算する（Ｓ１０２）。次に、対象のタスク進捗のステータスが完了（Ｓ４）であるか否かを確認する（Ｓ１０３）。ステータスが完了（Ｓ４）でない場合（すなわち未指示（Ｓ１）もしくは未完了（Ｓ３）である場合）は、対象のタスク進捗の指示受け者を未完了者のリストに追加し（Ｓ１０４）、ステータスが完了（Ｓ４）である場合は、実施率の分子に１を加算して（Ｓ１０５）、処理を終了する。
【００７６】
一方、ステップＳ１０１でステータスが指示済（Ｓ２）である場合は、対象のタスク進捗は再アサインされているため、対象のタスク進捗から再アサインされたタスクの実施率を算出する。そのため、まず、タスク進捗ＤＢ２７０を参照して、対象のタスク進捗が属するタスク（のタスクＩＤ）を判別する（Ｓ１０６）。
【００７７】
次に、タスクＤＢ２６０を参照して、判別したタスクが親タスクとなっており、かつ、対象のタスク進捗の指示受け者が指示者となっている子タスク（のタスクＩＤ）を判別する（Ｓ１０７）。具体的には、タスクテーブル２６１において、親タスクＩＤと指示者ユーザＩＤの値が、ステップＳ１０６で取得した、タスク進捗テーブル２７１における対象のタスク進捗のタスクＩＤおよび指示受け者ユーザＩＤの値とそれぞれ一致する、という条件を満たすタスクを取得してこれを判別対象の子タスクとし、そのタスクＩＤを取得する。
【００７８】
さらに、タスク進捗ＤＢ２７０を参照して、判別した子タスクに属するタスク進捗（のタスク進捗ＩＤ）を判別する（Ｓ１０８）。なお、ステップＳ１０６〜Ｓ１０８の一連の処理は、便宜上時系列で処理を記載しているが、タスクＤＢ２６０、タスク進捗ＤＢ２７０を対象としたデータベースアクセスにおいて一括で処理することも可能である。
【００７９】
最後に、ステップＳ１０８で判別したタスク進捗毎に、当該タスク進捗実施率算出処理を再帰的に呼び出して、タスク進捗毎の実施率を算出し（Ｓ１０９）、処理を終了する。上記の処理により、あるタスク進捗が指定された場合に、当該タスク進捗について、自身を含む下位に属する全てのタスク進捗を対象とした実施率の分子・分母の値を算出することができる。
【００８０】
図１４は、図１１に示したタスク進捗の実施状況を横比較する際の処理の流れの例を示すフローチャートである。処理を開始すると、実施状況管理部１２０は、まず、タスク進捗ＤＢ２７０を参照して、対象のタスク進捗と同じタスクに属する（同じタスクＩＤを有する）タスク進捗（のタスク進捗ＩＤ）を判別する（Ｓ２０１）。この中には、対象のタスク進捗自身も含まれる。次に、判別したタスク進捗毎に、図１３に示したタスク進捗実施率算出処理を呼び出して、タスク進捗毎の実施率を算出し（Ｓ２０２）、これを例えば図１１に示すような形式で出力して（Ｓ２０３）、処理を終了する。
【００８１】
図１５は、図１２に示したタスク進捗の実施状況を下比較する際の処理の流れの例を示すフローチャートである。処理を開始すると、実施状況管理部１２０は、対象のタスク進捗について、図１３に示したタスク進捗実施率算出処理を呼び出して、対象のタスク進捗の実施率を算出する（Ｓ３０１）。その後、対象のタスク進捗および再アサインした下位の各タスク進捗について、ステップＳ３０２で算出した実施率と未完了者の情報を、例えば図１２に示すような形式で出力して（Ｓ３０２）、処理を終了する。
【００８２】
なお、図１２および図１５に示す下比較の処理では、上述したように、図１１および図１４に示す横比較の場合と異なり、自身の配下の部署に係る実施状況の確認であるため、ステップＳ３０１の処理で記録された未完了者の情報も出力し、当該担当者に対して直接の問い合わせ等も可能となるようにしているが、横比較の場合は、対象のユーザと階層的に横の部署の担当者（指示受け者）における実施状況のサマリーを表示するのみに制限している。
【００８３】
以上に説明したように、本発明の実施の形態１であるタスク管理システムによれば、企業等の階層構造を有する組織体において、部署の階層構造における配下の担当者に対して作業を指示するタスクを作成し、さらに、当該タスクの指示を受けた担当者（指示受け者）単位で当該タスクに係る作業の進捗率およびステータス等の管理を行うタスク進捗を作成して、これらの情報をデータベースに保持して管理することができる。また、指示されたタスクを再アサインすることによりさらに下位部署に指示を展開することができ、これらのタスクをタスクの階層構造として管理することができる。
【００８４】
これにより、組織の階層構造に基づいてタスクの指示・展開を容易に行い、また、組織（タスク）の階層構造に応じた形で実施率の算出や参照範囲の制限などを含む実施状況の管理を行うことが可能となる。さらに、タスク進捗の単位でステータスを遷移させて管理するため、各担当者における作業実施の証跡を容易に取得することが可能となり、監査等の際の対応を容易にすることができる。また、タスクの階層構造の情報を組織の階層構造の情報と分離して保持することで、人事異動や組織改編などの際にもタスクの担当者等を柔軟に変更して対応することができる。
【００８５】
＜実施の形態２＞
以下では、本発明の実施の形態２であるセキュリティ管理支援システムについて説明する。
【００８６】
近年、ＩＴ技術の急速な発展に伴いその重要性が高まる一方、障害や情報漏洩等が発生した場合の影響度も大きくなっており、企業において適切な情報セキュリティ対策を講じることは重要な課題となっている。しかし、企業における情報セキュリティ対策への取組みは、その効果が認識しづらく、また、ゴールが見えずどのような対策をどこまで実施すれば十分であるかが判断しづらいことから、セキュリティ対策に対して過剰投資となる場合も生じ、いわゆる「対策疲れ」の状況も生じている。
【００８７】
これらの課題に対して、これまで、セキュリティ対策の状況（セキュリティレベル）やリスクを定量化することによって可視化するといった解決策が提案されてきた。これらの解決策は大きく分類して管理的（人的）アプローチと技術的アプローチに分けることができる。
【００８８】
管理的アプローチとしては、例えば、企業の情報セキュリティのマネジメント体系に関する認証基準であるＩＳＭＳ（Information Security Management System：情報セキュリティマネジメントシステム）（ＩＳＯ（International Organization for Standardization：国際標準化機構）／ＩＥＣ（International Electrotechnical Commission：国際電気標準会議）２７００１）を始めとするセキュリティ基準についての各種認証の取得や、種々のリスク分析の手法を用いた企業のリスク評価の実施などがある。また、技術的アプローチとしては、例えば、ＳＩＭ（Security Information Management：セキュリティ統合管理ツール）やログ分析ツール等のツール類を用いたセキュリティ管理の実施などがある。
【００８９】
また、これらに該当するものとして、例えば、特開２００３−１５０７４８号公報には、セキュリティポリシーと、情報システムに関する情報とを所定のアプリケーションプログラミングインターフェースに基づきリスク評価用のデータ形式に変換し、変換後のセキュリティポリシー及び情報システムに関する情報に基づきリスク評価を実行し、リスク評価の結果に基づき適宜管理策が選択され、選択された管理策によってセキュリティポリシー等に変更を加えて管理策データとする技術が開示されている。このとき、管理策データを用いてセキュリティのシミュレーションを実行することで、リスク評価の結果をセキュリティポリシーの構築に反映することができる。
【００９０】
このように、セキュリティレベルやリスクを定量化する手法やツールはいくつか存在するが、これらはいずれも企業の経営的視点でセキュリティ管理が行えるようなレベルには至っていない。例えば、リスク分析ツールやＳＩＭなどは、部分的な機能しか提供しておらず、また、セキュリティレベルの把握はあくまで現状を定量化して把握するに止まり、現状のセキュリティレベルに基づく将来の目標設定や、目標を達成するために実施すべき施策の決定を支援するといったことまでは十分にできていない。また、セキュリティレベルを企業における複数の拠点や部署（階層）毎に把握・管理するということもできていない。
【００９１】
特に、大規模組織では、ＰＣやサーバなどの管理対象の資産が多く、また、拠点や部署、グループ企業などの管理対象の組織も多岐にわたるため、セキュリティ管理業務は煩雑となり運営は非常に困難である。また、部署毎の対策レベルの現状把握が難しく、部署毎での対策レベルの差も大きいため、全体最適を実現することも困難である。例えば、ＩＳＭＳ認証を大規模組織で取得するのは非常に困難であり、実際は部署／拠点単位で取得するケースがほとんどである。
【００９２】
また、セキュリティレベルを定量化する従来の手法やツールでは、利用に際して高度な専門的知識が必要であるため、企業等の組織体においては、セキュリティレベルの定量化による評価はセキュリティ管理部門など一定のスキルを持った特定の部署が全部署の評価を一括して肩代わりして行っているのが実情である。その結果、現場の各部署（ユーザ部門）にとってはセキュリティ管理が他人事となってしまい、セキュリティ意識をユーザ部門に広く浸透させるのが困難になっている。
【００９３】
これらの課題を実効的に解決するには、セキュリティ管理「業務」をシステム化することが必要である。ここでの「業務」には、例えば、情報資産の洗い出しや分類、現状のセキュリティ対策状況の把握、リスク分析、セキュリティ対策（リスク対応）の目標設定と対策状況の管理など種々のものがある。これらの中には、例えば、情報資産の洗い出しや重要度設定による分類など、ユーザ部門で実施すべき、またはユーザ部門の協力が必要な作業は多く、また、実際のセキュリティ対策自体についてもユーザ部門で実施すべき対策は多い。
【００９４】
従って、特に、大規模組織においては、ユーザ部門が主体的にセキュリティ対策やセキュリティリスクについて現状を把握し、目標設定・管理を行ってセキュリティ管理業務の運営に関与できるようにすることは、企業において効率的・効果的なセキュリティ管理を実現するうえで非常に重要である。
【００９５】
そこで本実施の形態のセキュリティ管理支援システムは、企業等の組織において、セキュリティ管理の対象となる情報資産に関する情報を各部署によって管理することを可能とし、また、当該情報資産についてのセキュリティ対策状況やリスクを部署毎に定量化して、各部署における現状把握と目標設定・管理を行うことを目的とするものである。
【００９６】
すなわち、本実施の形態のセキュリティ管理支援システムは、企業等の組織体におけるセキュリティ管理「業務」をシステム化するものであり、この機能としては、例えば、部署毎に保護すべき情報資産についての情報をデータベース化して管理し、セキュリティ管理部門等ではなく現場（ユーザ部門）の担当者が情報を入力・更新することで分散管理する資産管理機能や、現状のセキュリティレベルやリスクレベルを定量化して部署別、対策ジャンル別など種々の切り口で把握する現状分析機能を有するものである。
【００９７】
また、現状のセキュリティレベルやリスクレベルに基づく将来の目標レベルの決定や、目標レベルを達成するために実施すべき施策の決定を支援する目標管理機能などを有し、さらに、従業員に対するセキュリティ対策についての具体的な施策である管理策の実施等の各種指示や、上長による承認等の一連の業務をワークフローやタスクとして管理する業務処理機能を有する。
【００９８】
ここで、企業等の組織体におけるセキュリティ管理業務は、その特性上、セキュリティ対策についての管理策の実施を全社もしくは一部の部署における組織階層全体に徹底させ、その実施状況をトラッキングすることによってセキュリティレベルやセキュリティリスクを分析・管理するというものが主である。
【００９９】
従って、本実施の形態のセキュリティ管理支援システムは、このような上位部署からトップダウンで指示・展開される管理策の実施をタスクとして管理するため、上述の業務処理機能の部分に実施の形態１で示したタスク管理システムの機能を適用している。これにより、タスクを階層構造で管理し、組織の階層構造に基づいたタスク（管理策）の指示・展開や、組織の階層構造に応じた形での実施率の算出等の実施状況の管理を行うことが可能となり、セキュリティレベルやリスクレベルの定量化に資することができる。
【０１００】
［システム構成］
図１６は、本発明の実施の形態２であるセキュリティ管理支援システムの構成例の概要を示す図である。セキュリティ管理支援システム５は、例えば、セキュリティ管理支援サーバ５００と、セキュリティ管理支援サーバ５００にネットワーク経由で接続されたおよびクライアント端末４００から構成される。また、後述するセキュリティ管理ツールサーバ３００とネットワーク経由で連携してもよい。
【０１０１】
セキュリティ管理支援サーバ５００は、コンピュータシステムからなるサーバ機器によって構成され、例えば、現状分析部５１０、目標管理部５２０、業務処理部５３０、資産管理部５４０、管理部５５０などを有する。これら各部はソフトウェアプログラムとして実装され、例えば、セキュリティ管理支援サーバ５００上の図示しないＷｅｂサーバプログラムと連携して、クライアント端末４００からの処理要求を受けて所定の処理を行い、クライアント端末４００に対して処理結果の画面を提示したり、また、日次等のバッチ処理により所定の処理を行ったりする。
【０１０２】
現状分析部５１０は、部署毎に保持する資産に対する管理策（セキュリティ対策についての具体的な施策）の実施状況についての診断結果を後述するデータベースに登録し、また、データベースに登録された診断結果に基づいて、各部署における現状のセキュリティレベルもしくはリスクレベルを管理対象のセキュリティ基準に基づいて採点し、部署別、対策ジャンル（管理策カテゴリ）別など種々の切り口（集計方法）で集計した結果をクライアント端末４００に表示する現状分析機能を実現する。
【０１０３】
現状分析部５１０は、例えば、セキュリティレベル診断部５１１、リスク分析部５１２、詳細分析部５１３の各部から構成される。セキュリティレベル診断部５１１は、いわゆるベースラインアプローチによりセキュリティ対策状況（セキュリティレベル）を定量化する機能を有する。リスク分析部５１２は、いわゆるリスクベースアプローチによりセキュリティリスク（リスクレベル）を定量化する機能を有する。詳細分析部５１３は、部署別、管理策カテゴリ別、セキュリティ基準別などの種々の切り口からセキュリティレベルやリスクレベルを集計することで現状を分析し、分析結果をユーザに提示する機能を有する。
【０１０４】
目標管理部５２０は、部署毎の現状のセキュリティレベルやリスクレベルに基づく将来の目標レベルの決定や、目標レベルを達成するために実施すべき施策の決定を支援し、その結果ユーザによって当該部署に対して指定された、セキュリティレベルもしくはリスクレベルの目標レベルとその達成時期および実施すべき施策を後述するデータベースに登録または更新する目標管理機能を実現する。
【０１０５】
目標管理部５２０は、例えば、目標設定部５２１、計画策定部５２２、予実管理部５２３の各部から構成される。目標設定部５２１は、ユーザがセキュリティレベルもしくはリスクレベルの目標値を指定し、その達成期限と合わせて目標レベルとして設定・登録するための機能を有する。計画策定部５２２は、目標設定部５２１によって設定された目標レベルを達成するために必要な管理策をユーザが指定するための機能を有する。予実管理部５２３は、目標設定部５２１によって設定された目標レベルとその達成度をユーザが確認するための機能を提供する。
【０１０６】
業務処理部５３０は、従業員に対する管理策の実施等の各種指示や、上長による承認等の一連の業務をワークフローやタスクとして管理する業務処理機能を実現する。また、セキュリティ管理支援システム５にて蓄積・管理されている情報に基づいて、例えば内部監査等で必要となる項目を抽出したり、内部監査の結果を管理したりといった機能を有していてもよい。
【０１０７】
本実施の形態のセキュリティ管理支援システム５では、管理策の実施といった上位部署からトップダウンで指示・展開される業務をタスクとして管理するため、業務処理部５３０に実施の形態１のタスク管理システム１におけるタスク実施管理部１１０および実施状況管理部１２０の機能を適用している。ここで、管理策は、上述したように部署毎に保持する資産に対する具体的な施策（作業）であり、これを実施の形態１で説明したタスクとして管理するためには、例えば、対象の資産の管理者（ＰＣの場合は各所有者、サーバ機器の場合はサーバ管理者など）に対して管理策の実施というタスクの指示を行うことになる。
【０１０８】
資産管理部５４０は、保護すべき情報資産（機密情報およびこれを保持するファイルサーバ、ＰＣなどの機器等）についての情報をデータベース化して管理し、セキュリティ管理部門等ではなく現場（ユーザ部門）の担当者が情報を入力・更新することで分散管理する資産管理機能を実現する。
【０１０９】
また、管理部５５０は、セキュリティ管理支援システム５を利用するユーザや部署、その他のシステム的な情報などを管理する機能を実現する。さらに、ユーザのログイン時の認証なども行う。すなわち、実施の形態１のタスク管理システムにおける管理部１３０の機能を包含している。なお、上記各部の構成はあくまで一例であり、さらに上記以外の各部を有していてもよいし、また、上記各部の一部または全部がまとめられていたり、さらに細かく分けられたりしていてもよい。
【０１１０】
セキュリティ管理支援サーバ５００は、さらに、ユーザ・部署ＤＢ２１０、資産ＤＢ２２０、管理策ＤＢ２３０、計画策定ＤＢ２４０、診断ＤＢ２５０の各データベースに加えて、実施の形態１のタスク管理システム１におけるタスクＤＢ２６０、タスク進捗ＤＢ２７０の各データベースを有する。
【０１１１】
ユーザ・部署ＤＢ２１０は、管理部５５０によって登録された、セキュリティ管理支援システム５を利用する企業等のユーザや部署およびその階層等の情報を保持する。このデータベースは、実施の形態１のタスク管理システム１におけるユーザ・部署ＤＢ２１０と同等のものである。資産ＤＢ２２０は、資産管理部５４０によって登録された、情報資産に関する情報（重要度や管理者などを含む）を保持する。
【０１１２】
管理策ＤＢ２３０は、管理部５５０によって予め登録された、セキュリティ対策における管理策および対応するセキュリティ基準の情報等を保持する。計画策定ＤＢ２４０は、目標管理部５２０によって登録された、部署毎の目標レベルとこれを達成するための管理策の情報等を保持する。診断ＤＢ２５０は、現状分析部５１０等によって登録された、資産毎の管理策の実施状況についての診断結果、およびこれに基づいて現状分析部５１０によって作成された種々の切り口の現状分析用のサマリーを保持する。
【０１１３】
なお、これら各データベースは、セキュリティ管理支援サーバ５００が直接保持する構成でもよいし、別のデータベースサーバ等に保持してネットワーク経由でアクセスする構成としてもよい。これら各データベースの詳細については後述する。
【０１１４】
セキュリティ管理ツールサーバ３００は、一般的なセキュリティ管理製品やツール等、もしくは既存の社内システム等（以下では総称して「セキュリティ管理ツール」という場合がある）のサーバであり、管理対象の情報資産（特にＰＣ）毎のセキュリティ関連の設定情報（すなわち管理策の実施状況）などを保持するサーバである。これらのセキュリティ管理ツールは、一般的に、資産管理対象のＰＣに導入されたプログラムによってセキュリティ関連の設定情報等を自動判別して取得し、ネットワーク経由でセキュリティ管理ツールサーバ３００に送信することで、セキュリティ管理ツールサーバ３００上で一元管理するものである。
【０１１５】
セキュリティ管理支援サーバ５００の現状分析部５１０は、セキュリティ管理ツールサーバ３００と連携して、セキュリティ管理ツールサーバ３００によって収集され一元管理されている資産管理対象のＰＣの設定情報等を抽出し、フォーマット変換等によって診断ＤＢ２５０に取り込むことが可能である。これにより、情報資産の登録に係る作業を大きく軽減することができる。なお、セキュリティ管理ツールサーバ３００は、連携するセキュリティ管理ツールに応じて複数種類有していてもよいし、全ての情報資産を手動で登録する場合は有していなくてもよい。また、図１６に示すような独立したサーバ機器ではなく、例えば、セキュリティ管理支援サーバ５００上にその機能を有していてもよい。
【０１１６】
クライアント端末４００は、ユーザ（セキュリティ管理部門の担当者や各部署の担当者など）に対してセキュリティ管理支援サーバ５００の各機能を利用するためのユーザインタフェースを提供する機器であり、ＰＣや携帯端末などにより構成される。例えば図示しないＷｅｂブラウザを有し、セキュリティ管理支援サーバ５００上の図示しないＷｅｂサーバプログラムとネットワーク経由により連携して、上記機能を実行するための指示を行ったり、実行結果の画面をユーザに提示したりする。
【０１１７】
［処理の流れ］
図１７は、セキュリティ管理支援システム５を利用したセキュリティ管理業務の流れの概要を示した図である。まず、セキュリティ管理支援サーバ５００の現状分析部５１０の機能を利用して、自部署および下位部署についてのセキュリティ対策状況およびセキュリティリスクの現状レベルを分析する（Ｓ４０１）。
【０１１８】
次に、目標管理部５２０の機能を利用して、各部署の担当者は、自部署および下位部署（下位部署が存在する場合）の目標レベルを設定する（Ｓ４０２）。このとき、一般的には例えば、所定の期限までに所定のセキュリティ基準（例えばＩＳＭＳ認証基準やいわゆる日本版ＳＯＸ法（金融商品取引法）対応など）を達成することを目標として、目標レベルを数値設定する。自部署の目標レベルを設定する際に、上位部署によって目標レベルが設定されている場合には、それを下回らない（目標を達成できる）ような目標設定とする。さらに、設定された目標レベルに対して、これを達成できるように実施すべき管理策と実施期限を設定する。
【０１１９】
次に、各部署において設定された管理策を具体的に実施する（Ｓ４０３）。その後、各部署が自部署における管理策の実施状況の自己点検を行う、あるいは独立したセキュリティ監査部門が各部署における管理策の実施状況の内部監査を行い、現状分析部５１０の機能を利用してセキュリティ管理支援システム５に診断結果を登録・更新する（Ｓ４０４）。ステップＳ４０３の実施とステップＳ４０４の自己点検／内部監査を随時繰り返し、ステップＳ４０１の現状分析に戻る。このようないわゆるＰＤＣＡ（Plan-Do-Check-Act）サイクルを、例えば四半期毎に繰り返すことによってセキュリティ管理業務を運営する。なお、上記各ステップでの処理例については後述する。
【０１２０】
［データベース構成］
図１８は、資産ＤＢ２２０のテーブルの構成例を示した図である。資産ＤＢ２２０は、セキュリティ管理の対象である情報資産に関する情報等を保持するデータベースであり、例えば、資産種別テーブル２２１、資産テーブル２２２、資産種別格納情報テーブル２２３、情報テーブル２２４、システム格納情報２２５のテーブルから構成される。
【０１２１】
資産種別テーブル２２１は、例えば、資産種別ＩＤ、資産種別名、資産区分などの資産の種別に関する項目を有する。資産種別は、例えば、「デスクトップＰＣ」、「ノートＰＣ」、「携帯端末」、「記録媒体」、「机／キャビネット」、「業務系システム」、「ＯＡ系システム」、「ネットワーク」、「組織」などの管理対象資産の小分類区分である。また、資産区分は、例えば、「ＰＣ」、「携帯端末」、「記録媒体」、「机／キャビネット」、「システム」、「ネットワーク」、「組織」などの管理対象資産の大分類区分である。
【０１２２】
資産テーブル２２２は、例えば、資産ＩＤ、管理部署ＩＤ、資産種別ＩＤ、資産名、管理者ＩＤ、利用者ＩＤ、保管場所、金額、製品名、シリアル番号、セキュリティ管理ツールキー番号などの各資産（実物資産）の属性に関する項目を有する。セキュリティ管理ツールキー番号の項目は、対象の資産がセキュリティ管理ツールサーバ３００によって設定情報等を自動収集することができる資産である場合に、その情報を特定するためのキー情報を保持する項目である。
【０１２３】
情報テーブル２２４は、例えば、情報ＩＤ、管理部署ＩＤ、情報名、情報区分、管理者ＩＤ、資産価値区分（機密性、完全性、可用性）、資産価値金額（機密性、完全性、可用性）、個人情報属性、現利用者などの企業で保持している各情報の属性に関する項目を有する。情報区分は、例えば、「自社個人情報」、「顧客個人情報」、「自社重要情報（戦略情報、財務情報等）」、「自社非重要情報（その他の文書、記録等）」などの情報の分類区分である。
【０１２４】
また、資産価値区分は、情報資産についての一般的なリスクの評価観点である機密性（Ｃ：Confidentiality）、完全性（Ｉ：Integrity）、可用性（Ａ：Availability）の観点から、例えば１〜３などの数値により資産価値（当該情報の重要度）を評価したものである。また、資産価値金額は、上記の資産価値を機密性、完全性、可用性の観点から金額で評価したものである。本実施の形態では、情報のリスクの高さを資産価値区分で評価することもできるし、資産価値金額で評価することもできる。これらの資産価値の情報は、例えば、各部署セキュリティ管理者などが入力する。
【０１２５】
資産種別格納情報テーブル２２３は、例えば、情報ＩＤ、資産種別ＩＤなどの項目を有し、各情報が属する（格納されている）資産種別の情報を保持する。一つの情報が複数の資産種別に属する場合もある。また、システム格納情報テーブル２２５は、例えば、情報ＩＤ、資産ＩＤなどの項目を有し、各情報がシステムに属する（格納されている）場合に、そのシステム（資産）との対応を保持する。
【０１２６】
すなわち、各情報資産のリスクを評価するために、本実施の形態のセキュリティ管理支援システム５では、基本的に情報と資産（現物）とを直接紐付けるのではなく、情報と資産種別とを紐付け、資産種別単位で紐付けられた情報の資産価値（重要度）に基づいてリスクを評価する。資産（現物）単位で紐付けられた情報の資産価値に基づいてリスクを評価するほうが精緻なリスク評価が可能であるが、大規模組織で資産（現物）単位で管理を行うことは多大な労力を要する。一方、資産種別単位で紐付けられた情報の資産価値に基づいてリスクを評価した場合、簡便にリスク評価をすることが可能であり、かつ実用上支障のない精度の結果を得ることができる。
【０１２７】
なお、資産区分が「システム」の資産については、資産の数が一般のＰＣ等と比べて少なく、また保持している情報がシステムの種類に応じて特性があり、データ量も多いことから、例外的に資産（現物のシステム）と情報との紐付けを行い、資産単位でリスクの評価を行う。また、資産区分（資産種別）が「ネットワーク」や「組織」の資産については、情報を保持していないものとして、情報との紐付けは行わない。すなわち、情報の資産価値に基づいたリスクの評価は行わない。また、資産区分（資産種別）が「机／キャビネット」に該当する資産であっても、オフィスやデータセンター、倉庫などについては、情報との紐付けは行わないが、重要度の高い情報が必ず含まれているものとして取り扱う。
【０１２８】
これらの資産ＤＢ２２０の各テーブルの情報は、例えば、各部署セキュリティ管理者等によって、資産管理部５４０により登録され、また更新などの管理が行われる。
【０１２９】
図１９は、管理策ＤＢ２３０のテーブルの構成例を示した図である。管理策ＤＢ２３０は、管理策および管理策が含まれるセキュリティ基準の情報等を保持するデータベースであり、例えば、セキュリティ基準テーブル２３１、管理策セキュリティ基準テーブル２３２、管理策テーブル２３３、リスク内容テーブル２３４、管理策リスク内容テーブル２３５、管理策実行部署テーブル２３６、管理策実行パターンテーブル２３７のテーブルから構成される。
【０１３０】
セキュリティ基準テーブル２３１は、例えば、セキュリティ基準ＩＤ、セキュリティ基準名などの項目を有し、セキュリティレベルを定量化（採点）する際のベースとし、管理目標とすることができるセキュリティ基準の情報を保持する。セキュリティ基準は、例えば、ＩＳＭＳ認証（ＩＳＯ／ＩＥＣ２７００１）、ＦＩＳＣ（The Center for Financial Industry Information Systems）安全対策基準、日本版ＳＯＸ法、自社のセキュリティポリシーなどである。
【０１３１】
管理策テーブル２３３は、例えば、管理策ＩＤ、管理策名、管理策内容、管理策カテゴリ、判定手段、質問文、対応有無（機密性、完全性、可用性）などの項目を有し、セキュリティ管理における個別の対策の内容を保持する。管理策カテゴリは、管理策の内容を分類するものであり、例えば、「セキュア設定」、「アクセス管理」、「電子商取引管理」、「パスワード管理」、「外部委託先管理」、「監視」などに各管理策を分類する。
【０１３２】
判定手段は、当該管理策が実施されているか否かの判定をユーザが行い手動で結果を入力するもの（「手動」）であるか、手動入力であっても外部・内部監査によって判定するもの（「手動（監査）」）であるか、セキュリティ管理ツールによる自動判定であるか（「自動」）を示す情報である。これにより、当該管理策の実施状況についての診断の実施（判定）もしくは診断結果の登録のいずれかがユーザ以外によって行われるものとそうでないもの、すなわち、判定結果が第三者判定によるもの（「手動（監査）」もしくは「自動」）であるか、自己判定によるもの（「手動」）であるかを識別することができる。
【０１３３】
また、質問文は、当該管理策の具体的な内容に相当し、当該管理策が実施できているか否かを判定するためのユーザに対する質問文（例えば「パスワードは××文字以上であるか？」など）の形式で保持される。また、対応有無の項目は、当該管理策が機密性、完全性、可用性のそれぞれの観点に対応するものであるか否かを示すフラグである。
【０１３４】
リスク内容テーブル２３４は、例えば、リスク内容ＩＤ、リスク内容、優先度などの項目を有し、想定されるリスクの内容毎にその優先度を保持する。管理策セキュリティ基準テーブル２３２は、例えば、管理策ＩＤ、セキュリティ基準ＩＤ、基準重み付け、文書名、条項番号などの項目を有し、セキュリティ基準の内容に含まれる管理策の情報を保持する。一つの管理策が複数のセキュリティ基準で共通に含まれる場合もある。基準重み付けの項目は、当該管理策について含まれるセキュリティ基準が異なることによる重み付け値である。また、文書名、条項番号の項目は、当該管理策がセキュリティ基準のどの部分に該当するものかを特定する情報である。
【０１３５】
また、管理策リスク内容テーブル２３５は、例えば、管理策ＩＤ、リスク内容ＩＤなどの項目を有し、管理策に該当するリスク内容の情報を保持する。また、管理策実行部署テーブル２３６は、例えば、管理策ＩＤ、実行部署ＩＤなどの項目を有し、当該管理策を実行する部署の情報を保持する。また、管理策実行パターンテーブル２３７は、例えば、管理策ＩＤ、資産種別ＩＤ、資産種別重み付け、管理策実行単価などの項目を有し、当該管理策がどの資産種別に適用されるか、およびその場合のインパクトの情報を保持する。資産種別重み付けの項目は、当該管理策が適用される資産種別が異なることによる重み付け値である。また、管理策実行単価の項目は、当該管理策を対象の資産種別に対して実施した場合の概算のコストであり、後述する計画策定の際のシミュレーションに用いる。
【０１３６】
これらの管理策ＤＢ２３０の各テーブルの情報は、例えば、システム管理者等によって、管理部５５０により予め登録され、また更新などの管理が行われる。
【０１３７】
図２０は、計画策定ＤＢ２４０のテーブルの構成例を示した図である。計画策定ＤＢ２４０は、部署毎の目標レベルとこれを達成するための管理策の情報等を保持するデータベースであり、例えば、目標設定テーブル２４１、リスク目標設定テーブル２４２、計画策定明細テーブル２４３、システム計画策定明細テーブル２４４のテーブルから構成される。
【０１３８】
目標設定テーブル２４１は、例えば、部署ＩＤ、作成基準年月、目標達成年月、自部署設定目標セキュリティレベル、上位部署設定目標セキュリティレベルなどの項目を有し、自部署および上位部署から設定された目標セキュリティレベル（ベースラインアプローチ）と達成期限の情報を保持する。同様に、リスク目標設定テーブル２４２は、例えば、部署ＩＤ、作成基準年月、目標達成年月、自部署設定目標リスクレベル、上位部署設定目標リスクレベルなどの項目を有し、自部署および上位部署から設定された目標リスクレベル（リスクベースアプローチ）と達成期限の情報を保持する。
【０１３９】
計画策定明細テーブル２４３は、例えば、部署ＩＤ、資産種別ＩＤ、管理策ＩＤ、作成基準年月、目標達成年月、計画設定区分などの項目を有し、部署毎の資産種別単位（資産区分がシステムのものは含まない）での実施すべき管理策の内容と達成期限の情報を保持する。また、システム計画策定明細テーブル２４４は、例えば、部署ＩＤ、資産ＩＤ、管理策ＩＤ、作成基準年月、目標達成年月、計画設定区分などの項目を有し、部署毎の資産単位（資産区分がシステムのもののみ）での実施すべき管理策の内容と達成期限の情報を保持する。
【０１４０】
すなわち、本実施の形態のセキュリティ管理支援システム５では、実施すべき管理策の設定単位は基本的に資産（現物）ではなく資産種別である。資産（現物）単位で実施すべき管理策を設定し管理するほうが精緻なセキュリティレベルの評価が可能であるが、大規模組織で資産単位で管理を行うことは多大な労力を要するからである。なお、資産区分が「システム」のものについては、上述したとおり、資産種別単位ではなく資産（システム）単位で実施すべき管理策の設定を行う。計画策定明細テーブル２４３およびシステム計画策定明細テーブル２４４における計画設定区分の項目は、当該管理策が実施対象として選択されているか否かを示すフラグである。
【０１４１】
これらの計画策定ＤＢ２４０の各テーブルの情報は、後述する目標管理部５２０の予実管理部５２３による経年予実比較や計画策定部５２２によるシミュレーションの際などに用いるため、更新された場合には以前のレコードを履歴レコードとして保持する。また、これらの各テーブルの情報は、例えば、各部署の担当者等によって、目標管理部５２０により登録され、また更新などの管理が行われる。
【０１４２】
図２１は、診断ＤＢ２５０のテーブルの構成例を示した図である。診断ＤＢ２５０は、資産毎のセキュリティ対策状況やセキュリティリスク、およびこれに基づいて作成された種々の切り口の現状分析用のサマリーを保持するデータベースであり、例えば、診断明細テーブル２５１から構成される。
【０１４３】
診断明細テーブル２５１は、例えば、資産ＩＤ、管理策ＩＤ、部署ＩＤ、判定結果、判定手段、判定結果更新日時などの項目を有し、部署毎の各資産単位での管理策の実施状況の判定結果の情報を入力・保持する。判定結果の項目は、例えば、○（実施済み）、×（未実施）、Ｎ／Ａ（非該当）などで表される。診断明細テーブル２５１の情報は、判定手段の項目が「手動」もしくは「手動（監査）」の資産については、例えば、各部署の担当者等によって、現状分析部５１０により登録・更新される。また、判定手段の項目が「自動」の資産については、セキュリティ管理ツールサーバ３００から取得した情報によって自動的に判定結果が登録・更新される。
【０１４４】
本実施の形態のセキュリティ管理支援システム５では、管理策の実施状況の判定結果は資産（現物）単位で入力し管理するが、大規模組織で資産単位で入力・管理を行うことは多大な労力を要するため、上述したようにセキュリティ管理ツールサーバ３００から情報を取得して自動登録したり、後述するように、資産種別単位で一括して入力できるようにしたりして作業負荷を軽減している。なお、この診断明細テーブル２５１の情報は、後述する目標管理部５２０の予実管理部５２３による経年予実比較の際などに用いるため、更新された場合には以前のレコードを履歴レコードとして保持する。
【０１４５】
詳細は後述するが、ベースラインアプローチでのセキュリティレベルの採点は、例えば、管理策の総数に対する実施数の割合に重み付けをして行う。また、リスクベースアプローチでのリスクレベルの採点は、例えば、ベースラインアプローチでのセキュリティレベルの採点結果に対してさらに資産価値に基づくリスク係数を考慮して行う。なお、以上に示した各ＤＢの構成は一例であり、他のＤＢやテーブル、項目を有していてもよい。
【０１４６】
［現状分析］
以下、図１７におけるセキュリティ対策およびセキュリティリスクの現状レベルの分析（Ｓ４０１）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介してセキュリティレベルの現状分析を行うよう要求すると、セキュリティ管理支援サーバ５００の現状分析部５１０は、各ＤＢの内容を参照して、例えば図２２に示すような、現状のセキュリティレベルの診断結果を表示するセキュリティ診断画面を生成してクライアント端末４００上に表示する。
【０１４７】
図２２の例では、指定された部署について、指定された管理策カテゴリに属する各管理策についての実施状況に基づいて、指定されたセキュリティ基準毎にセキュリティレベルおよびリスクレベルを採点し、その結果を表示している。
【０１４８】
セキュリティレベルについては、現状分析部５１０のセキュリティレベル診断部５１１により、ベースラインアプローチによって採点を行う。各部署が保持する資産（資産テーブル２２２）の資産種別について、対象のセキュリティ基準によって割り当てられている各管理策（管理策実行パターンテーブル２３７）についての実施状況の判定結果（診断明細テーブル２５１）に基づいて、資産単位でのセキュリティレベルは、
セキュリティレベル＝
Σ（重み付け値×判定結果○（実施済み）の管理策）×１００
÷Σ（重み付け値×判定結果Ｎ／Ａではない管理策） …式（２）
の式によって算出する。
【０１４９】
ここで、重み付け値は、例えば、管理策セキュリティ基準テーブル２３２の基準重み付け値と、管理策実行パターンテーブル２３７の資産種別重み付け値とを乗算したものであり、判定結果は診断明細テーブル２５１の判定結果である。また、ここで判定結果○（実施済み）とは、対象の管理策の実施指示に係るタスクが対象の部署（におけるタスクの指示者）において実施の形態１の図１２、図１５で示した下比較での実施率が１００％となっていることを表す。
【０１５０】
また、Σは対象の資産について割り当てられている全ての管理策について合計することを示す。すなわち、対象の資産について割り当てられている管理策の総数と、そのうちの実施済み（判定結果○）の管理策の数との割合を重み付けして算出したものである。なお、ここでのセキュリティレベルは数値が高いほど良いことを示す。
【０１５１】
図２２の例は、セキュリティレベルを部署単位で採点（集計）したものであり、式（２）による計算を、対象の部署が保持する全ての資産に割り当てられている管理策に対して行ったものである。対象の部署が階層の末端（現場）の部署ではない場合は、当該部署の直近の下位部署のセキュリティレベルを平均したものを用いてもよい。
【０１５２】
また、リスクレベルについては、現状分析部５１０のリスク分析部５１２により、リスクベースアプローチによって採点を行う。例えば、各部署が保持する資産の資産種別に保持される情報（情報テーブル２２４）から求められるリスク係数、および式（２）で算出したセキュリティレベルに基づいて、
リスクレベル＝リスク係数×（１００−セキュリティレベル） …式（３）
の式によって算出する。
【０１５３】
ここで、リスク係数は当該部署が保持する資産に保持される情報の資産価値に基づいて算出される情報のリスクの高さを示す係数であり、例えば、当該部署が保持する資産に保持される情報の情報テーブル２２４における資産価値区分（機密性、完全性、可用性）のそれぞれの最大値を用いる。これにより、機密性、完全性、可用性の区分毎にリスクレベルを算出する。なお、ここでのリスクレベルは数値が低いほど良いことを示す。
【０１５４】
本実施の形態のセキュリティ管理支援システム５では、リスク係数を情報テーブル２２４の資産価値区分に基づいて算出しているが、上述したように情報テーブル２２４の資産価値金額（機密性、完全性、可用性）の値を用いてもよいし、他のリスク評価のための指標を用いてもよい。また、本実施の形態のセキュリティ管理支援システム５では、セキュリティレベル、およびリスクレベルを上記の式（２）、式（３）を用いて比較的簡易な方法で採点しているが、他の採点方法であってもよいし、セキュリティ基準毎に異なる採点方法であってもよい。
【０１５５】
採点されたセキュリティレベルについては、図２２に示すように、例えば、得点とともに最大幅を１００％としたゲージによって表示する。また、リスクレベルについては機密性、完全性、可用性の区分毎に得点を表示する。さらに、第三者判定割合として、対象の管理策のうち第三者判定によるものの割合をゲージとともに表示する。第三者判定割合については、上述したように、例えば診断明細テーブル２５１の判定結果の項目が「手動（監査）」もしくは「自動」のものを第三者判定によるものとして、その数の管理策の総数に対する割合として求める。この第三者判定割合が高いものは診断結果の信頼性が高いものと判断することができる。
【０１５６】
図２２のセキュリティ診断画面によってセキュリティ基準毎のセキュリティレベルの診断結果を参照したユーザは、さらに、例えば画面右のプルダウンメニューおよび「分析」ボタンでの操作により、対象のセキュリティ基準について種々の切り口（集計方法）での詳細分析を行うことができる。詳細分析の要求を受けたセキュリティ管理支援サーバ５００は、現状分析部５１０の詳細分析部５１３により診断明細テーブル２５１を参照して詳細分析を行い、その結果をクライアント端末４００に表示する。
【０１５７】
例えば、図２３は、現状のセキュリティレベルの診断結果を部署毎に比較して表示する部署比較画面の例を示した図である。図２３の例では、指定された部署について、その直近の下位部署毎に、指定された管理策カテゴリでのセキュリティレベルを集計し、その結果をグラフとして表示している。これにより、部署間でのセキュリティレベルの差異を把握することができる。この比較は、上位部署が各下位部署のセキュリティ対策の実施状況を把握するのに用いるとともに、下位部署が同一系列の他部署との間で実施状況を比較するのにも用いることができる。
【０１５８】
また、図２４は、現状のセキュリティレベルの診断結果を管理策カテゴリ毎に比較して表示するレーダーチャート画面の例を示した図である。図２４の例では、指定された部署について、管理策カテゴリ毎にセキュリティレベルを集計し、レーダーチャートの形式で表示している。これにより、管理策カテゴリ間でのセキュリティ対策の実施状況の差異（強み・弱み）を把握することができる。
【０１５９】
また、図２５は、当該部署における管理策の実施状況についての計画と実績を対比（予実管理）する情報として、後述する目標設定の処理により設定された目標セキュリティレベル（将来および過去の設定履歴）の値とこれまでのセキュリティレベル（過去の診断履歴）の値とを比較して表示する経年予実比較画面の例を示した図である。図２５の例では、指定された部署について、設定されたセキュリティレベルの期単位での目標値および実績値を集計し、目標値と実績値とを過去３期、当期、将来３期にわたってグラフ表示している。これにより、設定した目標のセキュリティレベルに対する達成状況を把握することができる。なお、ここでの処理は目標管理部５２０の予実管理部５２３によって行われる。
【０１６０】
また、図２６は、現状のセキュリティレベルの診断結果を管理策毎に詳細に表示する診断明細照会画面の例を示した図である。図２６の例では、指定された部署について、指定された資産種別および管理策カテゴリに該当する管理策毎の診断結果（判定結果）を実施率に基づいて集計し、表示している。ここでは、例として、「本部」を対象として、「デスクトップＰＣ」についての「管理策１、２、３、…」の実施を配下の各課（「営業１課
、２課、…」の担当者にタスクとして指示し、その実施状況に基づいて集計された現状のセキュリティレベルの診断結果を表示している。
【０１６１】
下段の診断結果の表における実施率は、「本部」を対象として、対象の各管理策について実施の形態１の図１２、図１５で示した下比較によって算出した実施率であり、これが１００％となっている場合には判定結果が○となる。
【０１６２】
なお、下段の診断結果の表において、判定手段が「自動」の管理策については、上述したように、セキュリティ管理ツールサーバ３００から判定結果を自動取得している。また、判定結果が「詳細設定」となっている管理策については、対象の資産毎に判定結果が異なる（「全て○」や「全て×」ではない）ことを示している。これについては、画面右の「詳細」ボタンを押下することにより、資産（機器）単位での診断結果の照会画面に遷移する。
【０１６３】
図２７は、現状のセキュリティレベルの診断結果を資産毎に詳細に表示する診断明細照会（詳細）画面の例を示した図である。図２７の例では、指定された部署、資産種別、管理策について、対応する資産（機器）毎に診断結果（判定結果）を診断明細テーブル２５１を参照して表示している。以上の図２６、図２７により、個別の管理策毎、資産毎に詳細にセキュリティ対策の実施状況を把握することができる。
【０１６４】
［目標設定］
以下、図１７における自部署および下位部署の目標レベルの設定（ステップＳ４０２）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介してセキュリティレベルの目標設定を行うよう要求すると、セキュリティ管理支援サーバ５００の目標設定部５２１は、例えば図２８に示すような、自部署のセキュリティレベルの目標を設定する自部署目標設定画面を生成してクライアント端末４００上に表示する。
【０１６５】
図２８の例では、指定された部署について、目標設定の対象のセキュリティ基準についてのこれまでのセキュリティレベルの目標設定値と実績の経年予実比較のグラフが表示されている。このグラフは上述した図２５のものと同様であり、目標管理部５２０の予実管理部５２３により生成する。ユーザは、この経年予実比較のグラフを参照しながら、次期以降の自部署の目標のセキュリティレベルを設定することができる。
【０１６６】
自部署の目標値の設定に際しては、後述する下位部署目標設定画面により上位部署から設定された目標値についても目標設定テーブル２４１の上位部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の上位部署設定目標リスクレベルを参照して合わせて表示される。自部署の目標値として設定する値は、上位部署から設定された目標値より小さい値とすることはできないなどの制限を設けてもよい。
【０１６７】
設定した目標値は、目標設定部５２１により、目標設定テーブル２４１の自部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の自部署設定目標リスクレベルに登録される。このとき、自部署が保持する資産およびその資産種別と管理策実行パターンテーブル２３７の内容とに基づいて、計画策定明細テーブル２４３、およびシステム計画策定明細テーブル２４４のエントリ、すなわち自部署が保持する資産種別（資産区分が「システム」の場合は資産）に割り当てられた管理策のエントリを作成する。
【０１６８】
さらに、図２８の自部署目標設定画面等から、図２９に示すような下位部署のセキュリティレベルの目標を設定する下位部署目標設定画面に遷移することができる。図２９の例では、指定された部署の直近の下位部署について、目標設定の対象のセキュリティ基準についての現状のセキュリティレベルのグラフが表示されている。このグラフは上述した図２３のものと同様であり、現状分析部５１０の詳細分析部５１３により生成する。ユーザは、この各下位部署の現状のセキュリティレベルのグラフを参照しながら、次期以降の各下位部署の目標のセキュリティレベルを設定することができる。
【０１６９】
下位部署の目標値の設定に際しては、前述の自部署目標設定画面により設定した自部署の目標値についても目標設定テーブル２４１の自部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の自部署設定目標リスクレベルを参照して合わせて表示される。設定した目標値は、対象の下位部署についての目標設定テーブル２４１の上位部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の上位部署設定目標リスクレベルに登録される。このように、部署毎の目標設定を、部署の階層構造を考慮した形で行うことができる。
【０１７０】
さらに、各部署の担当者は、図２８の自部署目標設定画面によって設定した自部署の目標値を達成するために実施すべき管理策およびその実施時期を、目標管理部５２０の計画策定部５２２により、図３０に示すような計画策定画面によって決定することができる。図３０の例では、指定された部署について、当該部署が保持する各資産種別について目標設定の対象であるセキュリティ基準によって割り当てられている管理策を、計画策定明細テーブル２４３およびシステム計画策定明細２４４から取得して計画明細として表示している。
【０１７１】
ここで、図中の表における優先度は、各計画明細の静的な優先度を示し、例えば、当該計画明細に対応する管理策についての管理策セキュリティ基準テーブル２３２の基準重み付けの値と、管理策実行パターンテーブル２３７の資産種別重み付けの値とを乗算したものとする。また、対象の管理策に係るタスクについて実施の形態１の図１２、図１５で示した下比較により算出した実施率が表示されている。すなわち、当該実施率は、当該計画明細に対応する管理策についての、対象の部署以下の組織における全資産の数と実施済みの資産の数との割合と等価である。
【０１７２】
また、管理策実行パターンテーブル２３７から取得した、各計画明細の管理策を実施する場合の概算単価、および未実施分の数量についても表示している。なお、図３０の例では、上述した優先度の値に（１−実施率）の値を乗算した値の降順で各計画明細を並べ替えて表示している。これにより、優先度が高くかつ現時点で実施率の低い計画明細が表の上位に表示されるようにすることができる。
【０１７３】
このように表示された各計画明細に対して、ユーザは、当該部署での実施の要否とその完了目標時期を、例えばチェックボックスやプルダウンメニューを利用して選択する。ここで選択した内容は、計画策定明細テーブル２４３もしくはシステム計画策定明細テーブル２４４の計画設定区分および目標達成年月の項目に反映される。上述したように、本実施の形態のセキュリティ管理支援システム５では、実施すべき管理策の設定単位は基本的に資産ではなく資産種別である。資産単位で実施すべき管理策を設定し管理するほうが精緻なセキュリティレベルの評価が可能であるが、大規模組織で資産単位で管理を行うことは多大な労力を要するからである。
【０１７４】
なお、各計画明細についての実施の要否の設定は、対象の情報資産が各階層の部署に存在するため、基本的にはタスクを指示（再アサイン）された各階層の部署で個別に行う必要がある場合もあるが、例えば「セキュリティポリシーの策定」など、各部署で個別に行うのではなく、企業全体もしくは各事業部等の単位（上位部署）で実施すれば他の部署（下位部署）は実施の必要がないという管理策もある。このような管理策については、例えば、個別に管理策カテゴリを割り当てるなどして識別可能とし、上位部署で実施されるもしくは既にされている場合には下位部署では自動的に実施されるもしくは実施されたものとして処理してもよい。
【０１７５】
本実施の形態のセキュリティ管理支援システム５では、さらに、計画策定に際してどの計画明細を実施すれば効果的に目標のセキュリティレベルを達成できるのかを判断するために、シミュレーションの機能を有する。実施する計画明細と完了目標時期を設定して保存ボタンを押下すると、各時期に各計画明細が実施されたとした場合の達成セキュリティレベル（シミュレーション結果）と、実施に要する概算費用（実施費用総額）を算出し、各時期の当該部署の目標セキュリティレベルと合わせて下段の表に表示する。ここで、実施費用総額は、例えば、各計画明細について、各時期において実施されている場合にはその単価に数量を乗算した値を、実施されていない場合には零を、各計画明細について合算して算出する。
【０１７６】
このように、当該部署で保持する資産種別に応じて対象となる計画明細の一覧が提示され、さらに、シミュレーション結果を参照しながら実施する計画明細を設定することができるため、各部署の担当者が容易に目標達成のための計画を策定することができる。
【０１７７】
［自己点検／内部監査］
以下、図１７における管理策の実施状況の自己点検／内部監査（Ｓ４０４）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介して現在のセキュリティ対策状況についての自己点検を行うよう要求すると、セキュリティ管理支援サーバ５００の現状分析部５１０は、例えば図３１に示すような、自部署のセキュリティ対策の診断結果を入力する診断明細入力画面を生成してクライアント端末４００上に表示する。
【０１７８】
図３１の例では、上述の図１２で示した診断明細照会画面と同様の画面から、指定された資産種別について管理策毎に実施率を参照して診断結果（判定結果）をプルダウンメニューで入力することができる。入力された結果は、診断明細テーブル２５１に反映される。なお、図３０の例と同様に、対象の管理策に係るタスクについて実施の形態１の図１２、図１５で示した下比較により算出した実施率が表示されている。
【０１７９】
このように、資産単位ではなく、資産種別単位で管理策毎の診断結果を入力することで、ユーザの作業負荷を軽減することができる。一方、対象の管理策について全ての資産（機器）で判定結果が同じではなく混在する場合には、資産単位での診断結果を入力するため、画面右の「詳細」ボタンを押下することにより、資産単位での診断結果の入力画面に遷移することもできる。
【０１８０】
図３２は、自部署のセキュリティ対策の診断結果を資産毎に入力する診断明細入力（詳細）画面の例を示した図である。図３２の例では、上述の図２７で示した診断明細照会（詳細）画面と同様の画面から、各資産（機器）について診断結果（判定結果）を個別にプルダウンメニューで入力することができる。入力された結果は、同様に診断明細テーブル２５１に反映される。なお、セキュリティ管理ツールサーバ３００から判定結果を取得することが可能な資産（機器）については、自動で判定結果が診断明細テーブル２５１に反映されるため手動での入力は不要である。
【０１８１】
なお、セキュリティ監査部門が各部署における管理策の実施状況の内部監査を行う場合には、図３１や図３２の診断明細入力画面において、部署プルダウンメニューから監査対象の部署を選択したうえで、同様に診断結果（判定結果）を入力する。
【０１８２】
以上、図２２〜図３２を用いて本実施の形態のセキュリティ管理支援システム５での処理内容の概要について説明したが、図２２〜図３２で示した各種画面については、その種類や画面構成、入出力の項目や方法などのユーザインタフェースはあくまで一例であり、当然ながら他のユーザインタフェースであってもよい。
【０１８３】
以上に説明したように、本実施の形態のセキュリティ管理支援システム５によれば、各部署が保持する保護すべき情報資産に関する情報をデータベース上に体系的に保持・管理し、セキュリティ管理ツールとの連携や、資産種別単位でのセキュリティ対策状況の判定結果の入力および目標設定・管理を可能とすることにより、ユーザ部門が情報資産の管理を容易に行うことが可能となる。
【０１８４】
さらに、セキュリティレベルやリスクレベルを種々の切り口で簡易に定量化して提示することによって、部署の階層構造の中で各部署がセキュリティ対策状況の現状把握と目標設定・予実管理を容易に行うことが可能となる。このため、セキュリティ管理に要する負荷を企業内で分散して効率的・効果的なセキュリティ管理を行うことが可能となる。また、各階層の部署毎に、セキュリティ対策状況の現状や実施の成果を定量的に把握することができるため、ユーザ部門のセキュリティ対策に対する関心を高めるとともに、部署間の競争心理を高めてセキュリティ対策を推進する効果を得ることができる。
【０１８５】
また、管理策を実施する作業をタスクとし、実施の形態１に示したタスク管理システムの機能を適用することで、タスクを階層構造で管理し、タスクの作成、配下の部署・担当者への展開や、タスクの階層構造に基づいた形での実施率の算出等を容易に行うことが可能となる。
【０１８６】
これにより、例えば、タスク（管理策）カテゴリと、これに対応する管理策ＩＤとを定義しておき、図１７に示したＰＤＣＡサイクルの１診断周期におけるタスク（管理策）の実施率を、図３０等に示すように診断結果の実施率に自動反映させるなどにより、タスク管理の機能を、セキュリティレベルおよびリスクレベルの定量化などを行うセキュリティ管理の機能に連携させることが可能となる。
【０１８７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１８８】
本発明は、企業等の組織体においてトップダウンで作業が指示されるタスクを管理するタスク管理システムに利用可能である。
【符号の説明】
【０１８９】
１…タスク管理システム、５…セキュリティ管理支援システム、
１００…タスク管理サーバ、１１０…タスク実施管理部、１１１…タスク操作部、１１２…タスク情報取得部、１２０…実施状況管理部、１３０…管理部、
２１０…ユーザ・部署ＤＢ、２１１…会社テーブル、２１２…部署テーブル、２１３…所属部署テーブル、２１４…担当ロールテーブル、２１５…ロールテーブル、２１６…ユーザテーブル、
２２０…資産ＤＢ、２２１…資産種別テーブル、２２２…資産テーブル、２２３…資産種別格納情報テーブル、２２４…情報テーブル、２２５…システム格納情報テーブル、
２３０…管理策ＤＢ、２３１…セキュリティ基準テーブル、２３２…管理策セキュリティ基準テーブル、２３３…管理策テーブル、２３４…リスク内容テーブル、２３５…管理策リスク内容テーブル、２３６…管理策実行部署テーブル、２３７…管理策実行パターンテーブル、
２４０…計画策定ＤＢ、２４１…目標設定テーブル、２４２…リスク目標設定テーブル、２４３…計画策定明細テーブル、２４４…システム計画策定明細テーブル、
２５０…診断ＤＢ、２５１…診断明細テーブル、
２６０…タスクＤＢ、２６１…タスクテーブル、２６２…カテゴリテーブル、
２７０…タスク進捗ＤＢ、２７１…タスク進捗テーブル、２７２…ステータステーブル、
３００…セキュリティ管理ツールサーバ、
４００…クライアント端末、
５００…セキュリティ管理支援サーバ、５１０…現状分析部、５１１…セキュリティレベル診断部、５１２…リスク分析部、５１３…詳細分析部、５２０…目標管理部、５２１…目標設定部、５２２…計画策定部、５２３…予実管理部、５３０…業務処理部、５４０…資産管理部、５５０…管理部。
【技術分野】
【０００１】
本発明は、タスク管理の技術に関し、特に、企業等の組織体においてトップダウンで作業が指示されるタスクを管理するタスク管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
企業等における業務の流れをコンピュータシステムにより制御・管理するワークフロー管理においては、作業単位をタスクとして各部門・部署や担当者に割り当て、その進捗状況などを管理するということが行われる。このようなワークフロー管理によって管理される業務は、一般的に、ワークフローやタスクの生成が、実業務の発生元である下位部門・下位部署や実担当者によって行われ、上位部門・上位部署や上長などに対して申請され承認されるというように、組織の階層構造における下位から上位に向けての一連の業務の流れ、すなわち上り方向のベクトルを有する業務である。
【０００３】
ワークフロー管理においては、一般的に、予め定義されたワークフローの各タスクに対して静的もしくはワークフローの実行状況に応じて動的に担当者が割り当てられる。このとき、例えば、特開平８−９５８７７号公報（特許文献１）に記載されているように、あるタスクを複数の担当者に同報的に割り当てることも可能であるし、特開２００７−１７９２５１号公報（特許文献２）に記載されているように、タスクを割り当てられた担当者が、他の担当者にタスクを委任することも可能である。一般的にはこれら各タスクの進捗状況を管理することによりワークフロー全体の進捗状況を判断する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平８−９５８７７号公報
【特許文献２】特開２００７−１７９２５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一方で、企業等の階層構造の組織においては、例えば、マネジメント層から直近の下位部署に対して一斉同報的に作業の実施を指示し、当該下位部署がさらに直近の下位部署に同様の指示を展開して階層構造の末端の担当者にまで作業指示が届く、というようにトップダウンで上位から下位に組織の階層構造に応じてタスクが１対多で増幅されて指示される、すなわち下り方向のベクトルを有する業務も多い。
【０００６】
このような業務における各タスクの進捗管理は、上記のようなワークフロー管理の仕組みで対応することが難しい場合が多く、現状ではまだ電話や電子メール等で個別に確認して手作業により集計しているケースも多い。また、組織の階層構造が深くなるほど、進捗を確認する対象の下位部署や担当者の数が１対多で累積的に増幅されるため、タスクの進捗や実績を管理するのはより煩雑となる。
【０００７】
そこで本発明の目的は、企業等の階層構造を有する組織体において、上位部署もしくはその担当者からトップダウンで展開されるタスクの指示や実施状況の管理等を可能とするタスク管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【０００９】
本発明の代表的な実施の形態によるタスク管理システムは、階層構造を有する複数の部署からなる組織体における、前記部署の階層構造の上位の担当者から配下の下位の担当者に対しての作業実施の指示であるタスクの情報を保持し、前記タスクの実施状況の管理を行うタスク管理サーバと、前記タスク管理サーバにネットワーク経由で接続するクライアント端末とからなるタスク管理システムであって、以下の特徴を有するものである。
【００１０】
すなわち、前記タスク管理システムにおいて、前記タスク管理サーバは、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して指示する前記タスクを新たに作成し、前記タスクの指示を受けた各担当者の単位で前記タスクに係る作業の進捗率およびステータスの管理を行うタスク進捗を作成して、前記タスクおよび前記タスク進捗の情報を前記データベースに登録し、また、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記データベースに登録された前記タスクおよび前記タスク進捗の内容を修正して更新するタスク操作部と、前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力するタスク情報取得部と、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出して出力する実施状況管理部と、当該タスク管理システムを利用する前記ユーザおよび前記部署とその階層構造の情報を前記データベースに保持して管理する管理部とを有することを特徴とするものである。
【発明の効果】
【００１１】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１２】
本発明の代表的な実施の形態によれば、企業等の階層構造を有する組織体において、部署の階層構造における配下の担当者に対して作業を指示するタスクを作成し、当該タスクの指示を受けた担当者単位で当該タスクに係る作業の進捗率およびステータス等の管理を行うタスク進捗を作成して、これらの情報をデータベースに保持して管理することで、組織の階層構造に基づいてタスクの指示を容易に行い、また、タスクの実施率の算出やタスクの情報の参照範囲の制限などを含む実施状況の管理を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態１であるタスク管理システムの構成例の概要を示す図である。
【図２】本発明の一実施の形態のタスク管理システムが適用される企業等における一般的な組織の階層構造の一部について例を示す図である。
【図３】本発明の一実施の形態のタスク管理システムにおいて管理されるタスクの概念を説明する図である。
【図４】本発明の一実施の形態のタスク管理システムにおけるタスク（タスク進捗）の状態遷移図の例である。
【図５】本発明の実施の形態１におけるユーザ・部署ＤＢのテーブルの構成例を示した図である。
【図６】（ａ）、（ｂ）は、本発明の実施の形態１におけるタスクＤＢのテーブルの構成例および具体的なデータの例を示した図である。
【図７】（ａ）、（ｂ）は、本発明の実施の形態１におけるタスク進捗ＤＢのテーブルの構成例および具体的なデータの例を示した図である。
【図８】本発明の実施の形態１におけるユーザに関連するタスクの情報を表示するトップ画面の例を示した図である。
【図９】本発明の実施の形態１におけるタスクを新規作成する画面の例を示した図である。
【図１０】本発明の実施の形態１におけるタスク進捗の進捗状況（ステータス）を更新する画面の例を示した図である。
【図１１】本発明の実施の形態１におけるタスク進捗の実施状況を横比較した結果を表示する画面の例を示した図である。
【図１２】本発明の実施の形態１におけるタスク進捗の実施状況を下比較した結果を表示する画面の例を示した図である。
【図１３】本発明の実施の形態１におけるタスク進捗の実施率を算出する処理の流れの例を示すフローチャートである。
【図１４】本発明の実施の形態１におけるタスク進捗の実施状況を横比較する際の処理の流れの例を示すフローチャートである。
【図１５】本発明の実施の形態１におけるタスク進捗の実施状況を下比較する際の処理の流れの例を示すフローチャートである。
【図１６】本発明の実施の形態２であるセキュリティ管理支援システムの構成例の概要を示す図である。
【図１７】本発明の実施の形態２であるセキュリティ管理支援システムを利用したセキュリティ管理業務の流れの概要を示した図である。
【図１８】本発明の実施の形態２における資産ＤＢのテーブルの構成例を示した図である。
【図１９】本発明の実施の形態２における管理策ＤＢのテーブルの構成例を示した図である。
【図２０】本発明の実施の形態２における計画策定ＤＢのテーブルの構成例を示した図である。
【図２１】本発明の実施の形態２における診断ＤＢのテーブルの構成例を示した図である。
【図２２】本発明の実施の形態２における現状のセキュリティレベルの診断結果を表示するセキュリティ診断画面の例を示した図である。
【図２３】本発明の実施の形態２における現状のセキュリティレベルの診断結果を部署毎に比較して表示する部署比較画面の例を示した図である。
【図２４】本発明の実施の形態２における現状のセキュリティレベルの診断結果を管理策カテゴリ毎に比較して表示するレーダーチャート画面の例を示した図である。
【図２５】本発明の実施の形態２における目標セキュリティレベルの値とこれまでのセキュリティレベルの値とを比較して表示する経年予実比較画面の例を示した図である。
【図２６】本発明の実施の形態２における現状のセキュリティレベルの診断結果を管理策毎に詳細に表示する診断明細照会画面の例を示した図である。
【図２７】本発明の実施の形態２における現状のセキュリティレベルの診断結果を資産毎に詳細に表示する診断明細照会（詳細）画面の例を示した図である。
【図２８】本発明の実施の形態２における自部署のセキュリティレベルの目標を設定する自部署目標設定画面の例を示した図である。
【図２９】本発明の実施の形態２における下位部署のセキュリティレベルの目標を設定する下位部署目標設定画面の例を示した図である。
【図３０】本発明の実施の形態２における計画策定画面の例を示した図である。
【図３１】本発明の実施の形態２における自部署のセキュリティ対策の診断結果を入力する診断明細入力画面の例を示した図である。
【図３２】本発明の実施の形態２における自部署のセキュリティ対策の診断結果を資産毎に入力する診断明細入力（詳細）画面の例を示した図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１５】
＜概要＞
以下では、まず、本発明の一実施の形態であるタスク管理システムにおけるタスクおよびタスクの階層構造について概要を説明する。図２は、タスク管理システムが適用される企業等の一般的な組織の階層構造の一部について例を示す図である。例えば、最高情報セキュリティ責任者（ＣＩＳＯ）をトップに営業本部、情報システム本部、業務本部が配下に組織されている。各本部には責任者として本部長が存在する。
【００１６】
また、営業本部の配下には、例えば営業一部、二部が組織され、それぞれに責任者として部長が存在する。さらに、営業一部、二部にはそれぞれ一般従業員として２人の従業員が在籍する。同様に、情報システム本部の配下には、例えば情報システム部、基盤システム部が組織され、それぞれに責任者として部長が存在する。さらに、情報システム部には一般従業員として２人の従業員が在籍する。
【００１７】
ここで、上位組織がＣＩＳＯで共通である営業本部、情報システム本部、業務本部は同一階層の組織である。同様に、営業一部、二部はそれぞれ上位組織が営業本部で共通あり同一階層の組織である。また、情報システム部、基盤システム部は上位組織が情報システム本部であり同一階層の組織である。なお、図２の例では、業務本部および基盤システム部には配下の下位部署および在籍する従業員が存在しない。
【００１８】
図３は、タスク管理システムにおいて管理されるタスクの概念を説明する図である。ここでのタスクとは、組織の階層構造における上位の担当者から配下の下位の担当者に対しての作業実施の指示であり、このような上位部署からトップダウンで展開されるタスクの例として、図３では、企業でのセキュリティ管理における管理策として企業全体での実施が必要である「ＰＣ資産管理台帳の更新」という作業を、図２の組織階層におけるＣＩＳＯがタスクとして指示した場合を例としている。
【００１９】
ＣＩＳＯは、当該タスクの起点となり、まず、配下の組織の担当者である営業本部本部長、情報システム本部本部長、業務本部本部長に「ＰＣ資産管理台帳の更新」というタスク（Ｔ１）を指示している。すなわち、タスク（Ｔ１）では、指示者はＣＩＳＯであり３人の各本部長は指示受け者である。このように、複数の担当者に同報的にタスクを指示することができる。なお、タスクの起点である担当者（ＣＩＳＯ）が指示したタスク（Ｔ１）は元タスクとして識別される。
【００２０】
各タスクのステータスは、タスクの指示受け者の単位で管理される。タスク（Ｔ１）の指示受け者である営業本部本部長は、当該タスクをさらに配下の組織の担当者である営業一部部長、二部部長に再指示（以下では「再アサイン」と記載する場合がある）して展開している。従って、タスク（Ｔ１）について営業本部本部長が指示受け者となっている部分についてはステータスは「指示済」となっている。このように、タスクにおけるタスクの指示受け者毎のステータスの管理単位をこれ以降「タスク進捗」と呼ぶものとする。
【００２１】
営業本部本部長と同様に、情報システム本部本部長も配下の組織の担当者である情報システム部部長、基盤システム部部長にタスクを再アサインしており、情報システム本部本部長が指示受け者となっているタスク進捗のステータスは「指示済」となっている。一方、業務本部本部長は配下の組織および担当者が存在しないため、タスク（Ｔ１）は自身で実施する必要がある。業務本部本部長はタスク（Ｔ１）を再アサインしておらず、自身でも未だ作業着手していないため、タスク進捗のステータスは「未指示」となっている。なお、タスク進捗のステータスについては後述する。
【００２２】
営業本部本部長から営業一部部長、二部部長に再アサインされたタスク（Ｔ２）は、タスク（Ｔ１）を親タスクとした子タスクとして識別される。また、タスク（Ｔ２）について、指示者は営業本部本部長であり２人の各部長は指示受け者である。タスク（Ｔ２）の指示受け者である営業一部部長は、当該タスクをさらに配下の担当者である営業一部＃１、＃２に再アサインしている。また、図３の例ではさらに、営業一部部長自身もＰＣ資産を有しており「ＰＣ資産管理台帳の更新」の作業を実施する必要があることから、自分自身にもタスクを指示している。従って、営業一部部長が再アサインしたタスク（Ｔ４）の指示受け者には、営業一部＃１、＃２に加えて営業一部部長自身も含まれる。
【００２３】
また、タスク（Ｔ２）の指示受け者である営業二部部長は、当該タスクを配下の担当者（営業二部＃１、＃２）に未だ再アサインしておらず、自身でも作業着手していないため、タスク進捗のステータスは「未指示」となっている。この場合、営業二部部長は、原則として当該タスクを配下の担当者に再アサインすることも自身で実施することも可能である。自身で実施した場合にはもはや当該タスクを再アサインすることはできなくなる。このように、タスクの階層構造は組織の階層構造に基づいて構成されるが、同一の構成になるとは限らない。
【００２４】
タスク（Ｔ４）では、営業一部＃１はタスク（Ｔ４）を再アサインしておらず、自身でも未だ作業着手していないため、タスク進捗のステータスは「未指示」となっている。また、営業一部＃２は「ＰＣ資産管理台帳の更新」の作業を全て完了しているため、タスク進捗のステータスは「完了」となっている。また、営業一部部長は「ＰＣ資産管理台帳の更新」の作業を着手しているが未完了であるため、タスク進捗のステータスは「未完了」となっている。
【００２５】
その他のタスク（Ｔ３、Ｔ５）やタスク進捗についても上記と同様であるため説明は省略する。なお、図中において各タスク（タスク進捗）の指示者・指示受け者の名称に付されている括弧内の文字（「Ａ」〜「Ｌ」）は、それぞれの担当者のユーザＩＤを表しているものとする。
【００２６】
図４は、タスク（タスク進捗）の状態遷移図の例である。タスクが指示者から指示受け者に対して指示（もしくは再アサイン）されたとき、指示受け者におけるタスク進捗のステータスの初期状態は未指示（Ｓ１）である。この状態では、指示受け者は当該タスクについて再アサインしておらず、自身での実施も未着手である。
【００２７】
ステータスが未指示（Ｓ１）の状態では、指示受け者は、上述したように、原則として当該タスクを配下の担当者に再アサインすることも、自身で作業を実施することも可能である。当該タスクを再アサインした場合は、当該指示受け者におけるタスク進捗のステータスは指示済（Ｓ３）に遷移する。指示済（Ｓ３）に遷移したタスク進捗は、当該タスク進捗に係る作業を指示受け者が実施することはもはやできないため、これ以上ステータスが遷移することはない。
【００２８】
なお、タスクは原則として配下の担当者に再アサインすることができるが、指示者から「再アサイン不可」の指定が付されて指示されたタスクの場合は、再アサインすることはできない。すなわち、自身が作業を実施しなければならない。配下の担当者が存在しない末端の指示受け者の場合も実質的には再アサイン不可である。これらのタスク進捗については、指示済（Ｓ３）のステータスに遷移することはできない。
【００２９】
一方、ステータスが未指示（Ｓ１）の状態から指示受け者がタスク進捗のステータスに「未完了」を指定した場合は、タスク進捗のステータスは未完了（Ｓ２）に遷移する。なお、タスク進捗のステータスに「未完了」を指定する代わりに、当該タスク進捗に係る作業が一部実行された旨の進捗率（例えば「５０％」など）を指定することで未完了（Ｓ２）に遷移させてもよい。また、新たに指示されたタスクが再アサイン不可の場合は、必然的に指示受け者自身が実施することになるため、ステータスは自動的に未指示（Ｓ１）から未完了（Ｓ２）に遷移する。このときの進捗率は０％である。
【００３０】
ステータスが未完了（Ｓ２）の状態で、タスク進捗のステータスに「未完了」を指定した場合（もしくは作業の進捗率を更新した場合）は、タスク進捗のステータスは未完了（Ｓ２）で不変である。なお、タスク進捗のステータスに「未指示」を指定する（もしくは作業の進捗率に０％を指定する）と、ステータスを未指示（Ｓ１）に戻すことも可能である。
【００３１】
また、ステータスが未完了（Ｓ２）の状態で、作業実施が不能である等の事情により、当該タスクを配下の担当者に再アサインすることも可能である。この場合、ステータスは指示済（Ｓ３）に遷移する。また、ステータスが未完了（Ｓ２）の状態で、タスク進捗のステータスに「完了」を指定した場合（もしくは作業の進捗率に１００％を指定した場合）は、タスク進捗のステータスは完了（Ｓ４）に遷移して終了する。すなわち、ステータスが完了（Ｓ４）になったタスク進捗のステータスはこれ以上変更されることはないため、当該タスク進捗の指示受け者が確かに作業を行ったということの証跡の情報とすることができる。
【００３２】
このように、本実施の形態のタスク管理システムでは、上位部署からトップダウンで展開するタスクを組織階層の構造に基づいて再アサインにより展開可能とし、展開した階層毎に親タスク、子タスクとして管理する。各階層のタスクでは、指示受け者単位でタスク進捗としてステータスを管理する。
【００３３】
＜実施の形態１＞
［システム構成］
以下では、本発明の実施の形態１であるタスク管理システムについて説明する。図１は、本発明の実施の形態１であるタスク管理システムの構成例の概要を示す図である。タスク管理システム１は、例えば、タスク管理サーバ１００およびデータベースと、タスク管理サーバ１００にインターネットや社内ＬＡＮ等のネットワークを介して接続されたクライアント端末４００から構成される。
【００３４】
タスク管理サーバ１００は、コンピュータシステムからなるサーバ機器によって構成され、例えば、タスク実施管理部１１０、実施状況管理部１２０、管理部１３０などを有する。これら各部はソフトウェアプログラムとして実装され、例えば、タスク管理サーバ１００上の図示しないＷｅｂサーバプログラムと連携してクライアント端末４００からの処理要求を受けて所定の処理を行い、クライアント端末４００に対して処理結果の画面を提示する等の処理を行う。
【００３５】
タスク実施管理部１１０は、例えば、タスク操作部１１１、タスク情報取得部１１２を有する。タスク操作部１１１は、クライアント端末４００を介したユーザからの要求によるタスクの新規作成（指示）、再アサインといった処理を行い、当該タスクの情報をその階層構造の情報とともにデータベースに登録する。また、対象のタスクの指示を受けた指示受け者の単位でタスクの進捗率やステータスを管理するタスク進捗をデータベースに登録する。また、タスクおよびタスク進捗の内容の修正、進捗状況の更新などの操作を行い、データベースを更新する。
【００３６】
タスク情報取得部１１２は、クライアント端末４００を介したユーザからの要求により、対象のユーザに関連するタスク進捗の情報（当該ユーザが指示もしくは再アサインしたタスクおよび当該ユーザが指示されたタスクにおける当該ユーザに係るタスク進捗）をデータベースから取得して出力する。
【００３７】
実施状況管理部１２０は、クライアント端末４００を介したユーザからの要求により、タスクの階層構造に基づいて、当該ユーザが指示されたタスクについての実施状況（実施率や未実施者など）を算出して出力する。また、管理部１３０は、タスク管理システム１を利用するユーザおよび部署とその階層構造の情報、その他のシステム的な情報などをデータベースに保持して管理する機能を実現する。また、ユーザの情報を利用してユーザのログイン時の認証なども行う。なお、上記各部の構成はあくまで一例であり、さらに上記以外の各部を有していてもよいし、また、上記各部の一部または全部がまとめられていたり、さらに細かく分けられたりしていてもよい。
【００３８】
タスク管理サーバ１００は、さらに例えば、ユーザ・部署ＤＢ２１０、タスクＤＢ２６０、タスク進捗ＤＢ２７０の各データベースを有する。ユーザ・部署ＤＢ２１０は、タスク管理システム１を利用する企業等の組織におけるユーザおよび部署とその階層構造などの情報を保持する。タスクＤＢ２６０は、タスク管理システム１によって管理されているタスクおよびその階層構造の情報を保持する。
【００３９】
タスク進捗ＤＢ２７０は、タスクＤＢ２６０に保持・管理されている各タスクについて指示受け者（タスク進捗）単位でのステータス等の情報を保持する。なお、これら各データベースは、タスク管理サーバ１００が直接保持する構成でもよいし、別のデータベースサーバ等に保持してネットワーク経由でアクセスする構成としてもよい。これら各データベースの詳細については後述する。
【００４０】
クライアント端末４００は、ユーザ（各部署の担当者など）に対してタスク管理サーバ１００の各機能を利用するためのユーザインタフェースを提供する機器であり、ＰＣや携帯端末などにより構成される。例えば図示しないＷｅｂブラウザを有し、タスク管理サーバ１００上の図示しないＷｅｂサーバプログラムとネットワーク経由により連携して、上記機能を実行するための指示を行ったり、実行結果の画面をユーザに提示したりする。
【００４１】
［データベース構成］
図５は、ユーザ・部署ＤＢ２１０のテーブルの構成例を示した図である。ユーザ・部署ＤＢ２１０は、タスク管理システム１を利用する企業等のユーザや部署およびその階層構造等を保持するデータベースであり、例えば、会社テーブル２１１、部署テーブル２１２、所属部署テーブル２１３、担当ロールテーブル２１４、ロールテーブル２１５、ユーザテーブル２１６のテーブルから構成される。なお、図中のテーブル間の矢印は、例えば、Ａ→Ｂである場合に、Ａ：Ｂ＝１：ｎの関係（A has many Bs）にあることを示している。
【００４２】
会社テーブル２１１は、例えば、会社ＩＤ、会社名などの会社の属性に関する項目を有する。部署テーブル２１２は、例えば、部署ＩＤ、会社ＩＤ、上位部署ＩＤ、部署名、場所などの各部署の属性に関する項目を有する。上位部署ＩＤの項目を有することにより、各部署の階層構造を保持・把握することができる。ロールテーブル２１５は、例えば、ロールＩＤ、会社ＩＤ、ロール名などの項目を有する。ロール名は、例えば、「ＣＩＳＯ」、「各部署セキュリティ管理者」、「一般社員」など、ユーザに割り当てられるロール（役割）の種別である。ユーザのロールに応じて利用可能な機能を制限してもよい。
【００４３】
ユーザテーブル２１６は、例えば、ユーザＩＤ、会社ＩＤ、パスワード、ユーザ名、メールアドレスなどの各ユーザの属性に関する項目を有する。ユーザがタスク管理システム１にログインする際の認証に使用されるデータや、認証結果などの情報も保持する。所属部署テーブル２１３は、例えば、ユーザＩＤ、部署ＩＤなどの項目を有し、ユーザが所属する部署の情報を保持する。部署が階層構造となっていることから、ユーザが所属する部署も複数の階層（例えば「○○部××課」など、直接所属する部署とその上位部署）にわたる場合がある。
【００４４】
また、担当ロールテーブル２１４は、例えば、ユーザＩＤ、ロールＩＤなどの項目を有し、ユーザが担当するロールの情報を保持する。一人のユーザが複数のロールを担当しているという場合もある。これらのユーザ・部署ＤＢ２１０の各テーブルの情報は、例えば、システム管理者や人事担当者等によって、管理部１３０により予め登録され、また更新などの管理が行われる。
【００４５】
図６（ａ）、（ｂ）は、タスクＤＢ２６０のテーブルの構成例および具体的なデータの例を示した図である。タスクＤＢ２６０は、タスク管理システム１によって管理されているタスクおよびその階層構造の情報を保持するデータベースであり、例えば、タスクテーブル２６１、カテゴリテーブル２６２のテーブルから構成される。
【００４６】
タスクテーブル２６１は、例えば、タスクＩＤ、タスクタイトル、期日、作成日、カテゴリＩＤ、親タスクＩＤ、元タスクＩＤ、指示者ユーザＩＤなどのタスクの属性に関する項目を有する。ここでのタスクとは、図３に示したタスクの階層構造における各階層のタスク（例えばＴ１〜Ｔ５）を指し、このタスク毎にタスク操作部１１１によってユニークなタスクＩＤが割り振られる。親タスクＩＤや元タスクＩＤの項目を有することにより、上述したタスクの階層構造を保持・把握することができる。なお、図６（ｂ）は、図３に示したタスクの階層構造を例とした場合のタスクテーブル２６１の具体的なデータの例を示している。
【００４７】
カテゴリテーブル２６２は、例えば、カテゴリＩＤ、カテゴリ名などの、タスクのカテゴリの種類を表すための項目を有する。カテゴリ名は、例えば、「セキュリティ対策」や「月次報告」などである。
【００４８】
図７（ａ）、（ｂ）は、タスク進捗ＤＢ２７０のテーブルの構成例および具体的なデータの例を示した図である。タスク進捗ＤＢ２７０は、タスクＤＢ２６０に保持・管理されている各タスクについての指示受け者（タスク進捗）単位でのステータス等の情報を保持するデータベースであり、例えば、タスク進捗ＩＤ、タスクＩＤ、指示受け者ユーザＩＤ、進捗率、ステータスＩＤ、完了フラグ、完了日、再アサインフラグ、コピーフラグなどのタスク進捗の属性に関する項目を有する。
【００４９】
タスク進捗毎にタスク操作部１１１によってユニークなタスク進捗ＩＤが割り振られ、タスクＩＤ、指示受け者ユーザＩＤの項目を有することで、属するタスクおよび指示受け者を把握することができる。このタスク進捗毎に、進捗率や図４に示したステータスの状況を保持・管理する。
【００５０】
完了フラグの項目は、タスク進捗の完了・未完了を容易に判断可能とするため、ステータスＩＤが完了（Ｓ４）を示すものを「完了」とし、それ以外のステータスのものを「未完了」とする。また、再アサインフラグの項目は、「再アサイン不可」の指定が当該タスク進捗の指示者からされているか否かを示すフラグであり、コピーフラグの項目は、再アサインする際にタスクの内容をコピーすることが指示者から許可されているか否かを示すフラグである。
【００５１】
ステータステーブル２７２は、例えば、ステータスＩＤ、ステータス名などの、タスク進捗のステータスの種類を表すための項目を有する。ステータス名は、図４に示した各ステータスの名称をそれぞれ保持する。なお、図７（ｂ）は、図３に示したタスクの階層構造を例とした場合のタスク進捗テーブル２７１の具体的なデータの例を示している。ステータスＩＤの項目には、便宜上、ステータスＩＤの値ではなくステータステーブル２７２のステータス名の値で変換したものを示している。
【００５２】
［タスク実施管理］
以下では、ユーザがクライアント端末４００を介してタスク管理サーバ１００にアクセスし、タスクの新規作成（指示）、再アサインや、内容の修正、進捗状況の更新などのタスクについての操作を行う際の処理内容について説明する。
【００５３】
ユーザがクライアント端末４００からタスク管理サーバ１００にログインすると、タスク実施管理部１１０のタスク情報取得部１１２は、タスクＤＢ２６０およびタスクＤＢ２７０を参照して、例えば、図８に示すような、当該ユーザに関連するタスクの情報を表示するトップ画面を生成してクライアント端末４００上に表示する。
【００５４】
図８では図２、図３における営業本部本部長がログインした際の画面例を示している。この画面では、「未処理タスク一覧」として、当該ユーザが指示受け者となっているタスクのタスク進捗であり、かつステータスが未指示（Ｓ１）もしくは未完了（Ｓ３）のものの一覧が表示されている。未処理タスク一覧に表示されたタスク（タスク進捗）は、当該ユーザによる実施もしくは再アサインの処理を要するものである。また、これに付随して、「指示受け一覧」ボタンを押下すると、図示しないが、当該ユーザが指示受け者となっている、完了（Ｓ４）や指示済（Ｓ２）も含んだ全てのタスク進捗の一覧を表示することが可能である。
【００５５】
同様に、「処理待ちタスク一覧」として、当該ユーザが指示者となっているタスクに含まれるタスク進捗であり、かつステータスが未指示（Ｓ１）もしくは未完了（Ｓ３）のものの一覧が表示されている。処理待ちタスク一覧に表示されたタスク（タスク進捗）は、当該ユーザが指示を行い、指示受け者（配下の担当者）による実施もしくは再アサインの処理を要するものである。また、これに付随して、「指示一覧」ボタンを押下すると、図示しないが、当該ユーザが指示者となっているタスクに含まれるタスク進捗であり、完了（Ｓ４）や指示済（Ｓ２）も含んだ全てのタスク進捗の一覧を表示することが可能である。
【００５６】
このように、ログインしたユーザによって参照することができるタスク（タスク進捗）の範囲を制限しているが、ユーザの権限（部署やロール等）によって参照することができる範囲（部署、ユーザや、組織階層など）が拡大可能なように制御することも可能である。
【００５７】
図８の画面において、「新規作成」ボタンを押下することによって、当該ユーザが起点となって新たにタスクを作成して指示することができる。図９は、タスクを新規作成する画面の例を示した図である。
【００５８】
図９の画面において、ユーザはタスク名やカテゴリ、内容、担当者（指示受け者）などの情報を設定してタスクを新たに作成することができる。担当者を指定する際には、プルダウンメニューやリスト等によりユーザ・部署ＤＢ２１０に保持されている組織の階層構造の情報を提供することができ、容易に組織の階層構造に沿ったタスクの指示を行うことができる。このとき例えば、自身が属する部署および配下の部署に属する担当者のみがプルダウンメニューに表示されるように制御することでタスクの指示範囲を制限することができる。
【００５９】
さらに、タスクの作成時に、当該タスクの担当者（指示受け者）がさらに配下の担当者にタスクを再アサインすることを許可するか否か、および許可する場合に、指示受け者がタスクを再アサインする際に当該画面で指定したタスクの内容をコピーして再アサインすることを許可するか否かを指定することができる。タスク操作部１１１は、これらの設定内容に従ってタスクＤＢ２６０およびタスク進捗ＤＢ２７０に新たにタスクおよびタスク進捗を作成する。
【００６０】
また、図８の画面において、「未処理タスク一覧」に表示されたタスク進捗の「進捗更新」ボタンを押下することによって、当該タスク進捗のステータスを更新することができる。図１０は、タスク進捗の進捗状況（ステータス）を更新する画面の例を示した図である。図１０の画面において、ユーザは、当該タスク進捗に係る実作業の進捗状況に応じて進捗率やステータスを入力することができる。タスク操作部１１１は、入力内容に従ってタスク進捗ＤＢ２７０の内容を更新する。
【００６１】
さらに、当該タスク進捗が指示者によって再アサイン不可の指定がされていない場合は、「再アサイン」ボタンが押下可能となっており、これを押下することによってユーザは当該タスクの実施を配下の担当者に再アサインすることができる。このとき、図９に示したタスクの新規作成時の画面と同様な画面が表示され、タスクの内容や再アサインする担当者を設定することができる。
【００６２】
なお、当該タスク進捗に指示者によってタスク内容のコピー不可の指定がされていなかった場合は、タスクの再アサインを行う画面において、期日や内容などの情報が再アサインするタスクにそのまま引き継がれて設定される。タスク操作部１１１は、設定内容に従ってタスクＤＢ２６０およびタスク進捗ＤＢ２７０に新たに再アサインしたタスクおよびタスク進捗を作成する。
【００６３】
図１０の画面においてタスクの進捗率を１００％としてステータスを完了（Ｓ４）とした場合は、当該タスク進捗は図８の「未処理タスク一覧」から消える。また、タスクを再アサインしてタスク進捗のステータスを指示済（Ｓ２）とした場合は、当該タスク進捗は図８の「未処理タスク一覧」から消え、「処理待ちタスク一覧」に新たに表示される。
【００６４】
また、図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「修正」ボタンを押下することによって、再アサインした当該タスク進捗の内容を修正することができる。このとき、図９に示したタスクの新規作成時の画面と同様な画面が表示され、内容や期日などの情報を修正することができる。また、組織の人事異動等に伴って担当者が変更になる場合は指示受け者である担当者を変更することも可能である。タスク操作部１１１は、修正内容に従ってタスク進捗ＤＢ２７０の内容を更新する。
【００６５】
また、図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「削除」ボタンを押下することによって、再アサインした当該タスク進捗を削除（指示を取り消し）することもできる。タスク操作部１１１は、指定されたタスク進捗をタスク進捗ＤＢ２７０から削除する。
【００６６】
この際、削除したタスク進捗と同じタスクＩＤを有するタスク進捗が他に存在しない場合、すなわち、当該タスク進捗が属する子タスクに含まれるタスク進捗が全て削除された場合は、タスク操作部１１１は、タスクＤＢ２６０およびタスク進捗ＤＢ２７０を参照して当該子タスクを指示した親タスクのタスク進捗を特定し、そのステータスを指示済（Ｓ２）から未指示（Ｓ３）に更新することによって再アサインがされなかったものとする。
【００６７】
［タスク実施状況管理］
以下では、ユーザがクライアント端末４００を介してタスク管理サーバ１００にアクセスし、タスクの階層構造に基づいた実施状況（実施率や未実施者など）の情報を参照する際の処理内容について説明する。
【００６８】
上述の図８の画面において、「未処理タスク一覧」に表示されたタスク進捗の「実施状況」ボタンを押下することによって、ユーザは当該タスク進捗の実施状況を、同じ指示者から対象のタスクの指示・再アサインを受けた他の担当者に係るタスク進捗との間で比較（横比較）することができる。図１１は、タスク進捗の実施状況を横比較した結果を表示する画面の例を示した図である。
【００６９】
図１１の画面では、営業本部本部長がＣＩＳＯから指示されたタスクについて、ＣＩＳＯから当該タスクについて同様に指示を受けた情報システム本部本部長、業務本部本部長との間でタスク進捗の実施率を比較（横比較）して表示している。これにより、自身に指示されたタスク（タスク進捗）の実施状況を、階層的に横の部署の他の担当者に係るタスク進捗の実施状況と比較して進捗状況を判断することができる。
【００７０】
ここでの実施率（％および件数）は、実施状況管理部１２０が、対象のタスク進捗に対して、タスクの階層構造における自身を含む下位に属する全てのタスク進捗について、例えば、
実施率＝（完了（Ｓ４）の件数）／
（未指示（Ｓ１）or未完了（Ｓ２）or（完了Ｓ４）の件数） …式（１）
の式によって算出する。実施状況管理部１２０における実施率の算出処理の詳細については後述する。
【００７１】
また、上述の図８の画面において、「処理待ちタスク一覧」に表示されたタスク進捗の「実施状況」ボタンを押下することによって、ユーザは当該タスク進捗の実施状況を、自身が再アサインにより指示した配下の担当者に係るタスク進捗の間で比較（下比較）することができる。図１２は、タスク進捗の実施状況を下比較した結果を表示する画面の例を示した図である。図１２の画面では、営業本部本部長が指示したタスクについて、指示受け者である営業一部部長および営業二部部長の間で式（１）によって算出したタスク進捗の実施率を比較（下比較）して表示している。
【００７２】
図１２に示す下比較の場合は、図１１に示す横比較の場合と異なり、自身の配下の部署に係る実施状況の確認であるため、例えば、図１２における「未完了／未実施者」の項目のような未完了者や未実施者の具体的な情報など、さらに詳細な情報を参照可能とするよう参照権限を強化してもよい。また、担当者がさらに再アサインによって配下の担当者にタスクを指示している場合は、それらのタスク進捗についても式（１）によって実施率を算出してタスクの階層毎に表示するようにしてもよい。
【００７３】
［タスク実施状況管理（処理フロー）］
図１３は、タスク進捗毎の実施率を算出する処理の流れの例を示すフローチャートである。あるタスク進捗の実施率は、上述したように、例えば、対象のタスク進捗について、タスクの階層において自身を含む下位に属する全てのタスク進捗を対象に式（１）の計算を行って求めることができる。このタスク進捗実施率算出処理は、上述したタスク実施状況の横比較、下比較のいずれにおいても利用される。
【００７４】
図１３において、実施状況管理部１２０は、事前に実施率の分子および分母となる値を初期化しておく。その後、実施率の算出対象となるタスク進捗（タスク進捗ＩＤ）を入力パラメータとしてタスク進捗実施率算出処理を開始すると、まず、対象のタスク進捗のステータスが指示済（Ｓ２）であるか否かを確認する（Ｓ１０１）。
【００７５】
ステップＳ１０１でステータスが指示済（Ｓ２）でない場合は、対象のタスク進捗は再アサインされておらず、現時点でタスクの階層構造における末端であることを示す。従って、実施率の分母に１を加算する（Ｓ１０２）。次に、対象のタスク進捗のステータスが完了（Ｓ４）であるか否かを確認する（Ｓ１０３）。ステータスが完了（Ｓ４）でない場合（すなわち未指示（Ｓ１）もしくは未完了（Ｓ３）である場合）は、対象のタスク進捗の指示受け者を未完了者のリストに追加し（Ｓ１０４）、ステータスが完了（Ｓ４）である場合は、実施率の分子に１を加算して（Ｓ１０５）、処理を終了する。
【００７６】
一方、ステップＳ１０１でステータスが指示済（Ｓ２）である場合は、対象のタスク進捗は再アサインされているため、対象のタスク進捗から再アサインされたタスクの実施率を算出する。そのため、まず、タスク進捗ＤＢ２７０を参照して、対象のタスク進捗が属するタスク（のタスクＩＤ）を判別する（Ｓ１０６）。
【００７７】
次に、タスクＤＢ２６０を参照して、判別したタスクが親タスクとなっており、かつ、対象のタスク進捗の指示受け者が指示者となっている子タスク（のタスクＩＤ）を判別する（Ｓ１０７）。具体的には、タスクテーブル２６１において、親タスクＩＤと指示者ユーザＩＤの値が、ステップＳ１０６で取得した、タスク進捗テーブル２７１における対象のタスク進捗のタスクＩＤおよび指示受け者ユーザＩＤの値とそれぞれ一致する、という条件を満たすタスクを取得してこれを判別対象の子タスクとし、そのタスクＩＤを取得する。
【００７８】
さらに、タスク進捗ＤＢ２７０を参照して、判別した子タスクに属するタスク進捗（のタスク進捗ＩＤ）を判別する（Ｓ１０８）。なお、ステップＳ１０６〜Ｓ１０８の一連の処理は、便宜上時系列で処理を記載しているが、タスクＤＢ２６０、タスク進捗ＤＢ２７０を対象としたデータベースアクセスにおいて一括で処理することも可能である。
【００７９】
最後に、ステップＳ１０８で判別したタスク進捗毎に、当該タスク進捗実施率算出処理を再帰的に呼び出して、タスク進捗毎の実施率を算出し（Ｓ１０９）、処理を終了する。上記の処理により、あるタスク進捗が指定された場合に、当該タスク進捗について、自身を含む下位に属する全てのタスク進捗を対象とした実施率の分子・分母の値を算出することができる。
【００８０】
図１４は、図１１に示したタスク進捗の実施状況を横比較する際の処理の流れの例を示すフローチャートである。処理を開始すると、実施状況管理部１２０は、まず、タスク進捗ＤＢ２７０を参照して、対象のタスク進捗と同じタスクに属する（同じタスクＩＤを有する）タスク進捗（のタスク進捗ＩＤ）を判別する（Ｓ２０１）。この中には、対象のタスク進捗自身も含まれる。次に、判別したタスク進捗毎に、図１３に示したタスク進捗実施率算出処理を呼び出して、タスク進捗毎の実施率を算出し（Ｓ２０２）、これを例えば図１１に示すような形式で出力して（Ｓ２０３）、処理を終了する。
【００８１】
図１５は、図１２に示したタスク進捗の実施状況を下比較する際の処理の流れの例を示すフローチャートである。処理を開始すると、実施状況管理部１２０は、対象のタスク進捗について、図１３に示したタスク進捗実施率算出処理を呼び出して、対象のタスク進捗の実施率を算出する（Ｓ３０１）。その後、対象のタスク進捗および再アサインした下位の各タスク進捗について、ステップＳ３０２で算出した実施率と未完了者の情報を、例えば図１２に示すような形式で出力して（Ｓ３０２）、処理を終了する。
【００８２】
なお、図１２および図１５に示す下比較の処理では、上述したように、図１１および図１４に示す横比較の場合と異なり、自身の配下の部署に係る実施状況の確認であるため、ステップＳ３０１の処理で記録された未完了者の情報も出力し、当該担当者に対して直接の問い合わせ等も可能となるようにしているが、横比較の場合は、対象のユーザと階層的に横の部署の担当者（指示受け者）における実施状況のサマリーを表示するのみに制限している。
【００８３】
以上に説明したように、本発明の実施の形態１であるタスク管理システムによれば、企業等の階層構造を有する組織体において、部署の階層構造における配下の担当者に対して作業を指示するタスクを作成し、さらに、当該タスクの指示を受けた担当者（指示受け者）単位で当該タスクに係る作業の進捗率およびステータス等の管理を行うタスク進捗を作成して、これらの情報をデータベースに保持して管理することができる。また、指示されたタスクを再アサインすることによりさらに下位部署に指示を展開することができ、これらのタスクをタスクの階層構造として管理することができる。
【００８４】
これにより、組織の階層構造に基づいてタスクの指示・展開を容易に行い、また、組織（タスク）の階層構造に応じた形で実施率の算出や参照範囲の制限などを含む実施状況の管理を行うことが可能となる。さらに、タスク進捗の単位でステータスを遷移させて管理するため、各担当者における作業実施の証跡を容易に取得することが可能となり、監査等の際の対応を容易にすることができる。また、タスクの階層構造の情報を組織の階層構造の情報と分離して保持することで、人事異動や組織改編などの際にもタスクの担当者等を柔軟に変更して対応することができる。
【００８５】
＜実施の形態２＞
以下では、本発明の実施の形態２であるセキュリティ管理支援システムについて説明する。
【００８６】
近年、ＩＴ技術の急速な発展に伴いその重要性が高まる一方、障害や情報漏洩等が発生した場合の影響度も大きくなっており、企業において適切な情報セキュリティ対策を講じることは重要な課題となっている。しかし、企業における情報セキュリティ対策への取組みは、その効果が認識しづらく、また、ゴールが見えずどのような対策をどこまで実施すれば十分であるかが判断しづらいことから、セキュリティ対策に対して過剰投資となる場合も生じ、いわゆる「対策疲れ」の状況も生じている。
【００８７】
これらの課題に対して、これまで、セキュリティ対策の状況（セキュリティレベル）やリスクを定量化することによって可視化するといった解決策が提案されてきた。これらの解決策は大きく分類して管理的（人的）アプローチと技術的アプローチに分けることができる。
【００８８】
管理的アプローチとしては、例えば、企業の情報セキュリティのマネジメント体系に関する認証基準であるＩＳＭＳ（Information Security Management System：情報セキュリティマネジメントシステム）（ＩＳＯ（International Organization for Standardization：国際標準化機構）／ＩＥＣ（International Electrotechnical Commission：国際電気標準会議）２７００１）を始めとするセキュリティ基準についての各種認証の取得や、種々のリスク分析の手法を用いた企業のリスク評価の実施などがある。また、技術的アプローチとしては、例えば、ＳＩＭ（Security Information Management：セキュリティ統合管理ツール）やログ分析ツール等のツール類を用いたセキュリティ管理の実施などがある。
【００８９】
また、これらに該当するものとして、例えば、特開２００３−１５０７４８号公報には、セキュリティポリシーと、情報システムに関する情報とを所定のアプリケーションプログラミングインターフェースに基づきリスク評価用のデータ形式に変換し、変換後のセキュリティポリシー及び情報システムに関する情報に基づきリスク評価を実行し、リスク評価の結果に基づき適宜管理策が選択され、選択された管理策によってセキュリティポリシー等に変更を加えて管理策データとする技術が開示されている。このとき、管理策データを用いてセキュリティのシミュレーションを実行することで、リスク評価の結果をセキュリティポリシーの構築に反映することができる。
【００９０】
このように、セキュリティレベルやリスクを定量化する手法やツールはいくつか存在するが、これらはいずれも企業の経営的視点でセキュリティ管理が行えるようなレベルには至っていない。例えば、リスク分析ツールやＳＩＭなどは、部分的な機能しか提供しておらず、また、セキュリティレベルの把握はあくまで現状を定量化して把握するに止まり、現状のセキュリティレベルに基づく将来の目標設定や、目標を達成するために実施すべき施策の決定を支援するといったことまでは十分にできていない。また、セキュリティレベルを企業における複数の拠点や部署（階層）毎に把握・管理するということもできていない。
【００９１】
特に、大規模組織では、ＰＣやサーバなどの管理対象の資産が多く、また、拠点や部署、グループ企業などの管理対象の組織も多岐にわたるため、セキュリティ管理業務は煩雑となり運営は非常に困難である。また、部署毎の対策レベルの現状把握が難しく、部署毎での対策レベルの差も大きいため、全体最適を実現することも困難である。例えば、ＩＳＭＳ認証を大規模組織で取得するのは非常に困難であり、実際は部署／拠点単位で取得するケースがほとんどである。
【００９２】
また、セキュリティレベルを定量化する従来の手法やツールでは、利用に際して高度な専門的知識が必要であるため、企業等の組織体においては、セキュリティレベルの定量化による評価はセキュリティ管理部門など一定のスキルを持った特定の部署が全部署の評価を一括して肩代わりして行っているのが実情である。その結果、現場の各部署（ユーザ部門）にとってはセキュリティ管理が他人事となってしまい、セキュリティ意識をユーザ部門に広く浸透させるのが困難になっている。
【００９３】
これらの課題を実効的に解決するには、セキュリティ管理「業務」をシステム化することが必要である。ここでの「業務」には、例えば、情報資産の洗い出しや分類、現状のセキュリティ対策状況の把握、リスク分析、セキュリティ対策（リスク対応）の目標設定と対策状況の管理など種々のものがある。これらの中には、例えば、情報資産の洗い出しや重要度設定による分類など、ユーザ部門で実施すべき、またはユーザ部門の協力が必要な作業は多く、また、実際のセキュリティ対策自体についてもユーザ部門で実施すべき対策は多い。
【００９４】
従って、特に、大規模組織においては、ユーザ部門が主体的にセキュリティ対策やセキュリティリスクについて現状を把握し、目標設定・管理を行ってセキュリティ管理業務の運営に関与できるようにすることは、企業において効率的・効果的なセキュリティ管理を実現するうえで非常に重要である。
【００９５】
そこで本実施の形態のセキュリティ管理支援システムは、企業等の組織において、セキュリティ管理の対象となる情報資産に関する情報を各部署によって管理することを可能とし、また、当該情報資産についてのセキュリティ対策状況やリスクを部署毎に定量化して、各部署における現状把握と目標設定・管理を行うことを目的とするものである。
【００９６】
すなわち、本実施の形態のセキュリティ管理支援システムは、企業等の組織体におけるセキュリティ管理「業務」をシステム化するものであり、この機能としては、例えば、部署毎に保護すべき情報資産についての情報をデータベース化して管理し、セキュリティ管理部門等ではなく現場（ユーザ部門）の担当者が情報を入力・更新することで分散管理する資産管理機能や、現状のセキュリティレベルやリスクレベルを定量化して部署別、対策ジャンル別など種々の切り口で把握する現状分析機能を有するものである。
【００９７】
また、現状のセキュリティレベルやリスクレベルに基づく将来の目標レベルの決定や、目標レベルを達成するために実施すべき施策の決定を支援する目標管理機能などを有し、さらに、従業員に対するセキュリティ対策についての具体的な施策である管理策の実施等の各種指示や、上長による承認等の一連の業務をワークフローやタスクとして管理する業務処理機能を有する。
【００９８】
ここで、企業等の組織体におけるセキュリティ管理業務は、その特性上、セキュリティ対策についての管理策の実施を全社もしくは一部の部署における組織階層全体に徹底させ、その実施状況をトラッキングすることによってセキュリティレベルやセキュリティリスクを分析・管理するというものが主である。
【００９９】
従って、本実施の形態のセキュリティ管理支援システムは、このような上位部署からトップダウンで指示・展開される管理策の実施をタスクとして管理するため、上述の業務処理機能の部分に実施の形態１で示したタスク管理システムの機能を適用している。これにより、タスクを階層構造で管理し、組織の階層構造に基づいたタスク（管理策）の指示・展開や、組織の階層構造に応じた形での実施率の算出等の実施状況の管理を行うことが可能となり、セキュリティレベルやリスクレベルの定量化に資することができる。
【０１００】
［システム構成］
図１６は、本発明の実施の形態２であるセキュリティ管理支援システムの構成例の概要を示す図である。セキュリティ管理支援システム５は、例えば、セキュリティ管理支援サーバ５００と、セキュリティ管理支援サーバ５００にネットワーク経由で接続されたおよびクライアント端末４００から構成される。また、後述するセキュリティ管理ツールサーバ３００とネットワーク経由で連携してもよい。
【０１０１】
セキュリティ管理支援サーバ５００は、コンピュータシステムからなるサーバ機器によって構成され、例えば、現状分析部５１０、目標管理部５２０、業務処理部５３０、資産管理部５４０、管理部５５０などを有する。これら各部はソフトウェアプログラムとして実装され、例えば、セキュリティ管理支援サーバ５００上の図示しないＷｅｂサーバプログラムと連携して、クライアント端末４００からの処理要求を受けて所定の処理を行い、クライアント端末４００に対して処理結果の画面を提示したり、また、日次等のバッチ処理により所定の処理を行ったりする。
【０１０２】
現状分析部５１０は、部署毎に保持する資産に対する管理策（セキュリティ対策についての具体的な施策）の実施状況についての診断結果を後述するデータベースに登録し、また、データベースに登録された診断結果に基づいて、各部署における現状のセキュリティレベルもしくはリスクレベルを管理対象のセキュリティ基準に基づいて採点し、部署別、対策ジャンル（管理策カテゴリ）別など種々の切り口（集計方法）で集計した結果をクライアント端末４００に表示する現状分析機能を実現する。
【０１０３】
現状分析部５１０は、例えば、セキュリティレベル診断部５１１、リスク分析部５１２、詳細分析部５１３の各部から構成される。セキュリティレベル診断部５１１は、いわゆるベースラインアプローチによりセキュリティ対策状況（セキュリティレベル）を定量化する機能を有する。リスク分析部５１２は、いわゆるリスクベースアプローチによりセキュリティリスク（リスクレベル）を定量化する機能を有する。詳細分析部５１３は、部署別、管理策カテゴリ別、セキュリティ基準別などの種々の切り口からセキュリティレベルやリスクレベルを集計することで現状を分析し、分析結果をユーザに提示する機能を有する。
【０１０４】
目標管理部５２０は、部署毎の現状のセキュリティレベルやリスクレベルに基づく将来の目標レベルの決定や、目標レベルを達成するために実施すべき施策の決定を支援し、その結果ユーザによって当該部署に対して指定された、セキュリティレベルもしくはリスクレベルの目標レベルとその達成時期および実施すべき施策を後述するデータベースに登録または更新する目標管理機能を実現する。
【０１０５】
目標管理部５２０は、例えば、目標設定部５２１、計画策定部５２２、予実管理部５２３の各部から構成される。目標設定部５２１は、ユーザがセキュリティレベルもしくはリスクレベルの目標値を指定し、その達成期限と合わせて目標レベルとして設定・登録するための機能を有する。計画策定部５２２は、目標設定部５２１によって設定された目標レベルを達成するために必要な管理策をユーザが指定するための機能を有する。予実管理部５２３は、目標設定部５２１によって設定された目標レベルとその達成度をユーザが確認するための機能を提供する。
【０１０６】
業務処理部５３０は、従業員に対する管理策の実施等の各種指示や、上長による承認等の一連の業務をワークフローやタスクとして管理する業務処理機能を実現する。また、セキュリティ管理支援システム５にて蓄積・管理されている情報に基づいて、例えば内部監査等で必要となる項目を抽出したり、内部監査の結果を管理したりといった機能を有していてもよい。
【０１０７】
本実施の形態のセキュリティ管理支援システム５では、管理策の実施といった上位部署からトップダウンで指示・展開される業務をタスクとして管理するため、業務処理部５３０に実施の形態１のタスク管理システム１におけるタスク実施管理部１１０および実施状況管理部１２０の機能を適用している。ここで、管理策は、上述したように部署毎に保持する資産に対する具体的な施策（作業）であり、これを実施の形態１で説明したタスクとして管理するためには、例えば、対象の資産の管理者（ＰＣの場合は各所有者、サーバ機器の場合はサーバ管理者など）に対して管理策の実施というタスクの指示を行うことになる。
【０１０８】
資産管理部５４０は、保護すべき情報資産（機密情報およびこれを保持するファイルサーバ、ＰＣなどの機器等）についての情報をデータベース化して管理し、セキュリティ管理部門等ではなく現場（ユーザ部門）の担当者が情報を入力・更新することで分散管理する資産管理機能を実現する。
【０１０９】
また、管理部５５０は、セキュリティ管理支援システム５を利用するユーザや部署、その他のシステム的な情報などを管理する機能を実現する。さらに、ユーザのログイン時の認証なども行う。すなわち、実施の形態１のタスク管理システムにおける管理部１３０の機能を包含している。なお、上記各部の構成はあくまで一例であり、さらに上記以外の各部を有していてもよいし、また、上記各部の一部または全部がまとめられていたり、さらに細かく分けられたりしていてもよい。
【０１１０】
セキュリティ管理支援サーバ５００は、さらに、ユーザ・部署ＤＢ２１０、資産ＤＢ２２０、管理策ＤＢ２３０、計画策定ＤＢ２４０、診断ＤＢ２５０の各データベースに加えて、実施の形態１のタスク管理システム１におけるタスクＤＢ２６０、タスク進捗ＤＢ２７０の各データベースを有する。
【０１１１】
ユーザ・部署ＤＢ２１０は、管理部５５０によって登録された、セキュリティ管理支援システム５を利用する企業等のユーザや部署およびその階層等の情報を保持する。このデータベースは、実施の形態１のタスク管理システム１におけるユーザ・部署ＤＢ２１０と同等のものである。資産ＤＢ２２０は、資産管理部５４０によって登録された、情報資産に関する情報（重要度や管理者などを含む）を保持する。
【０１１２】
管理策ＤＢ２３０は、管理部５５０によって予め登録された、セキュリティ対策における管理策および対応するセキュリティ基準の情報等を保持する。計画策定ＤＢ２４０は、目標管理部５２０によって登録された、部署毎の目標レベルとこれを達成するための管理策の情報等を保持する。診断ＤＢ２５０は、現状分析部５１０等によって登録された、資産毎の管理策の実施状況についての診断結果、およびこれに基づいて現状分析部５１０によって作成された種々の切り口の現状分析用のサマリーを保持する。
【０１１３】
なお、これら各データベースは、セキュリティ管理支援サーバ５００が直接保持する構成でもよいし、別のデータベースサーバ等に保持してネットワーク経由でアクセスする構成としてもよい。これら各データベースの詳細については後述する。
【０１１４】
セキュリティ管理ツールサーバ３００は、一般的なセキュリティ管理製品やツール等、もしくは既存の社内システム等（以下では総称して「セキュリティ管理ツール」という場合がある）のサーバであり、管理対象の情報資産（特にＰＣ）毎のセキュリティ関連の設定情報（すなわち管理策の実施状況）などを保持するサーバである。これらのセキュリティ管理ツールは、一般的に、資産管理対象のＰＣに導入されたプログラムによってセキュリティ関連の設定情報等を自動判別して取得し、ネットワーク経由でセキュリティ管理ツールサーバ３００に送信することで、セキュリティ管理ツールサーバ３００上で一元管理するものである。
【０１１５】
セキュリティ管理支援サーバ５００の現状分析部５１０は、セキュリティ管理ツールサーバ３００と連携して、セキュリティ管理ツールサーバ３００によって収集され一元管理されている資産管理対象のＰＣの設定情報等を抽出し、フォーマット変換等によって診断ＤＢ２５０に取り込むことが可能である。これにより、情報資産の登録に係る作業を大きく軽減することができる。なお、セキュリティ管理ツールサーバ３００は、連携するセキュリティ管理ツールに応じて複数種類有していてもよいし、全ての情報資産を手動で登録する場合は有していなくてもよい。また、図１６に示すような独立したサーバ機器ではなく、例えば、セキュリティ管理支援サーバ５００上にその機能を有していてもよい。
【０１１６】
クライアント端末４００は、ユーザ（セキュリティ管理部門の担当者や各部署の担当者など）に対してセキュリティ管理支援サーバ５００の各機能を利用するためのユーザインタフェースを提供する機器であり、ＰＣや携帯端末などにより構成される。例えば図示しないＷｅｂブラウザを有し、セキュリティ管理支援サーバ５００上の図示しないＷｅｂサーバプログラムとネットワーク経由により連携して、上記機能を実行するための指示を行ったり、実行結果の画面をユーザに提示したりする。
【０１１７】
［処理の流れ］
図１７は、セキュリティ管理支援システム５を利用したセキュリティ管理業務の流れの概要を示した図である。まず、セキュリティ管理支援サーバ５００の現状分析部５１０の機能を利用して、自部署および下位部署についてのセキュリティ対策状況およびセキュリティリスクの現状レベルを分析する（Ｓ４０１）。
【０１１８】
次に、目標管理部５２０の機能を利用して、各部署の担当者は、自部署および下位部署（下位部署が存在する場合）の目標レベルを設定する（Ｓ４０２）。このとき、一般的には例えば、所定の期限までに所定のセキュリティ基準（例えばＩＳＭＳ認証基準やいわゆる日本版ＳＯＸ法（金融商品取引法）対応など）を達成することを目標として、目標レベルを数値設定する。自部署の目標レベルを設定する際に、上位部署によって目標レベルが設定されている場合には、それを下回らない（目標を達成できる）ような目標設定とする。さらに、設定された目標レベルに対して、これを達成できるように実施すべき管理策と実施期限を設定する。
【０１１９】
次に、各部署において設定された管理策を具体的に実施する（Ｓ４０３）。その後、各部署が自部署における管理策の実施状況の自己点検を行う、あるいは独立したセキュリティ監査部門が各部署における管理策の実施状況の内部監査を行い、現状分析部５１０の機能を利用してセキュリティ管理支援システム５に診断結果を登録・更新する（Ｓ４０４）。ステップＳ４０３の実施とステップＳ４０４の自己点検／内部監査を随時繰り返し、ステップＳ４０１の現状分析に戻る。このようないわゆるＰＤＣＡ（Plan-Do-Check-Act）サイクルを、例えば四半期毎に繰り返すことによってセキュリティ管理業務を運営する。なお、上記各ステップでの処理例については後述する。
【０１２０】
［データベース構成］
図１８は、資産ＤＢ２２０のテーブルの構成例を示した図である。資産ＤＢ２２０は、セキュリティ管理の対象である情報資産に関する情報等を保持するデータベースであり、例えば、資産種別テーブル２２１、資産テーブル２２２、資産種別格納情報テーブル２２３、情報テーブル２２４、システム格納情報２２５のテーブルから構成される。
【０１２１】
資産種別テーブル２２１は、例えば、資産種別ＩＤ、資産種別名、資産区分などの資産の種別に関する項目を有する。資産種別は、例えば、「デスクトップＰＣ」、「ノートＰＣ」、「携帯端末」、「記録媒体」、「机／キャビネット」、「業務系システム」、「ＯＡ系システム」、「ネットワーク」、「組織」などの管理対象資産の小分類区分である。また、資産区分は、例えば、「ＰＣ」、「携帯端末」、「記録媒体」、「机／キャビネット」、「システム」、「ネットワーク」、「組織」などの管理対象資産の大分類区分である。
【０１２２】
資産テーブル２２２は、例えば、資産ＩＤ、管理部署ＩＤ、資産種別ＩＤ、資産名、管理者ＩＤ、利用者ＩＤ、保管場所、金額、製品名、シリアル番号、セキュリティ管理ツールキー番号などの各資産（実物資産）の属性に関する項目を有する。セキュリティ管理ツールキー番号の項目は、対象の資産がセキュリティ管理ツールサーバ３００によって設定情報等を自動収集することができる資産である場合に、その情報を特定するためのキー情報を保持する項目である。
【０１２３】
情報テーブル２２４は、例えば、情報ＩＤ、管理部署ＩＤ、情報名、情報区分、管理者ＩＤ、資産価値区分（機密性、完全性、可用性）、資産価値金額（機密性、完全性、可用性）、個人情報属性、現利用者などの企業で保持している各情報の属性に関する項目を有する。情報区分は、例えば、「自社個人情報」、「顧客個人情報」、「自社重要情報（戦略情報、財務情報等）」、「自社非重要情報（その他の文書、記録等）」などの情報の分類区分である。
【０１２４】
また、資産価値区分は、情報資産についての一般的なリスクの評価観点である機密性（Ｃ：Confidentiality）、完全性（Ｉ：Integrity）、可用性（Ａ：Availability）の観点から、例えば１〜３などの数値により資産価値（当該情報の重要度）を評価したものである。また、資産価値金額は、上記の資産価値を機密性、完全性、可用性の観点から金額で評価したものである。本実施の形態では、情報のリスクの高さを資産価値区分で評価することもできるし、資産価値金額で評価することもできる。これらの資産価値の情報は、例えば、各部署セキュリティ管理者などが入力する。
【０１２５】
資産種別格納情報テーブル２２３は、例えば、情報ＩＤ、資産種別ＩＤなどの項目を有し、各情報が属する（格納されている）資産種別の情報を保持する。一つの情報が複数の資産種別に属する場合もある。また、システム格納情報テーブル２２５は、例えば、情報ＩＤ、資産ＩＤなどの項目を有し、各情報がシステムに属する（格納されている）場合に、そのシステム（資産）との対応を保持する。
【０１２６】
すなわち、各情報資産のリスクを評価するために、本実施の形態のセキュリティ管理支援システム５では、基本的に情報と資産（現物）とを直接紐付けるのではなく、情報と資産種別とを紐付け、資産種別単位で紐付けられた情報の資産価値（重要度）に基づいてリスクを評価する。資産（現物）単位で紐付けられた情報の資産価値に基づいてリスクを評価するほうが精緻なリスク評価が可能であるが、大規模組織で資産（現物）単位で管理を行うことは多大な労力を要する。一方、資産種別単位で紐付けられた情報の資産価値に基づいてリスクを評価した場合、簡便にリスク評価をすることが可能であり、かつ実用上支障のない精度の結果を得ることができる。
【０１２７】
なお、資産区分が「システム」の資産については、資産の数が一般のＰＣ等と比べて少なく、また保持している情報がシステムの種類に応じて特性があり、データ量も多いことから、例外的に資産（現物のシステム）と情報との紐付けを行い、資産単位でリスクの評価を行う。また、資産区分（資産種別）が「ネットワーク」や「組織」の資産については、情報を保持していないものとして、情報との紐付けは行わない。すなわち、情報の資産価値に基づいたリスクの評価は行わない。また、資産区分（資産種別）が「机／キャビネット」に該当する資産であっても、オフィスやデータセンター、倉庫などについては、情報との紐付けは行わないが、重要度の高い情報が必ず含まれているものとして取り扱う。
【０１２８】
これらの資産ＤＢ２２０の各テーブルの情報は、例えば、各部署セキュリティ管理者等によって、資産管理部５４０により登録され、また更新などの管理が行われる。
【０１２９】
図１９は、管理策ＤＢ２３０のテーブルの構成例を示した図である。管理策ＤＢ２３０は、管理策および管理策が含まれるセキュリティ基準の情報等を保持するデータベースであり、例えば、セキュリティ基準テーブル２３１、管理策セキュリティ基準テーブル２３２、管理策テーブル２３３、リスク内容テーブル２３４、管理策リスク内容テーブル２３５、管理策実行部署テーブル２３６、管理策実行パターンテーブル２３７のテーブルから構成される。
【０１３０】
セキュリティ基準テーブル２３１は、例えば、セキュリティ基準ＩＤ、セキュリティ基準名などの項目を有し、セキュリティレベルを定量化（採点）する際のベースとし、管理目標とすることができるセキュリティ基準の情報を保持する。セキュリティ基準は、例えば、ＩＳＭＳ認証（ＩＳＯ／ＩＥＣ２７００１）、ＦＩＳＣ（The Center for Financial Industry Information Systems）安全対策基準、日本版ＳＯＸ法、自社のセキュリティポリシーなどである。
【０１３１】
管理策テーブル２３３は、例えば、管理策ＩＤ、管理策名、管理策内容、管理策カテゴリ、判定手段、質問文、対応有無（機密性、完全性、可用性）などの項目を有し、セキュリティ管理における個別の対策の内容を保持する。管理策カテゴリは、管理策の内容を分類するものであり、例えば、「セキュア設定」、「アクセス管理」、「電子商取引管理」、「パスワード管理」、「外部委託先管理」、「監視」などに各管理策を分類する。
【０１３２】
判定手段は、当該管理策が実施されているか否かの判定をユーザが行い手動で結果を入力するもの（「手動」）であるか、手動入力であっても外部・内部監査によって判定するもの（「手動（監査）」）であるか、セキュリティ管理ツールによる自動判定であるか（「自動」）を示す情報である。これにより、当該管理策の実施状況についての診断の実施（判定）もしくは診断結果の登録のいずれかがユーザ以外によって行われるものとそうでないもの、すなわち、判定結果が第三者判定によるもの（「手動（監査）」もしくは「自動」）であるか、自己判定によるもの（「手動」）であるかを識別することができる。
【０１３３】
また、質問文は、当該管理策の具体的な内容に相当し、当該管理策が実施できているか否かを判定するためのユーザに対する質問文（例えば「パスワードは××文字以上であるか？」など）の形式で保持される。また、対応有無の項目は、当該管理策が機密性、完全性、可用性のそれぞれの観点に対応するものであるか否かを示すフラグである。
【０１３４】
リスク内容テーブル２３４は、例えば、リスク内容ＩＤ、リスク内容、優先度などの項目を有し、想定されるリスクの内容毎にその優先度を保持する。管理策セキュリティ基準テーブル２３２は、例えば、管理策ＩＤ、セキュリティ基準ＩＤ、基準重み付け、文書名、条項番号などの項目を有し、セキュリティ基準の内容に含まれる管理策の情報を保持する。一つの管理策が複数のセキュリティ基準で共通に含まれる場合もある。基準重み付けの項目は、当該管理策について含まれるセキュリティ基準が異なることによる重み付け値である。また、文書名、条項番号の項目は、当該管理策がセキュリティ基準のどの部分に該当するものかを特定する情報である。
【０１３５】
また、管理策リスク内容テーブル２３５は、例えば、管理策ＩＤ、リスク内容ＩＤなどの項目を有し、管理策に該当するリスク内容の情報を保持する。また、管理策実行部署テーブル２３６は、例えば、管理策ＩＤ、実行部署ＩＤなどの項目を有し、当該管理策を実行する部署の情報を保持する。また、管理策実行パターンテーブル２３７は、例えば、管理策ＩＤ、資産種別ＩＤ、資産種別重み付け、管理策実行単価などの項目を有し、当該管理策がどの資産種別に適用されるか、およびその場合のインパクトの情報を保持する。資産種別重み付けの項目は、当該管理策が適用される資産種別が異なることによる重み付け値である。また、管理策実行単価の項目は、当該管理策を対象の資産種別に対して実施した場合の概算のコストであり、後述する計画策定の際のシミュレーションに用いる。
【０１３６】
これらの管理策ＤＢ２３０の各テーブルの情報は、例えば、システム管理者等によって、管理部５５０により予め登録され、また更新などの管理が行われる。
【０１３７】
図２０は、計画策定ＤＢ２４０のテーブルの構成例を示した図である。計画策定ＤＢ２４０は、部署毎の目標レベルとこれを達成するための管理策の情報等を保持するデータベースであり、例えば、目標設定テーブル２４１、リスク目標設定テーブル２４２、計画策定明細テーブル２４３、システム計画策定明細テーブル２４４のテーブルから構成される。
【０１３８】
目標設定テーブル２４１は、例えば、部署ＩＤ、作成基準年月、目標達成年月、自部署設定目標セキュリティレベル、上位部署設定目標セキュリティレベルなどの項目を有し、自部署および上位部署から設定された目標セキュリティレベル（ベースラインアプローチ）と達成期限の情報を保持する。同様に、リスク目標設定テーブル２４２は、例えば、部署ＩＤ、作成基準年月、目標達成年月、自部署設定目標リスクレベル、上位部署設定目標リスクレベルなどの項目を有し、自部署および上位部署から設定された目標リスクレベル（リスクベースアプローチ）と達成期限の情報を保持する。
【０１３９】
計画策定明細テーブル２４３は、例えば、部署ＩＤ、資産種別ＩＤ、管理策ＩＤ、作成基準年月、目標達成年月、計画設定区分などの項目を有し、部署毎の資産種別単位（資産区分がシステムのものは含まない）での実施すべき管理策の内容と達成期限の情報を保持する。また、システム計画策定明細テーブル２４４は、例えば、部署ＩＤ、資産ＩＤ、管理策ＩＤ、作成基準年月、目標達成年月、計画設定区分などの項目を有し、部署毎の資産単位（資産区分がシステムのもののみ）での実施すべき管理策の内容と達成期限の情報を保持する。
【０１４０】
すなわち、本実施の形態のセキュリティ管理支援システム５では、実施すべき管理策の設定単位は基本的に資産（現物）ではなく資産種別である。資産（現物）単位で実施すべき管理策を設定し管理するほうが精緻なセキュリティレベルの評価が可能であるが、大規模組織で資産単位で管理を行うことは多大な労力を要するからである。なお、資産区分が「システム」のものについては、上述したとおり、資産種別単位ではなく資産（システム）単位で実施すべき管理策の設定を行う。計画策定明細テーブル２４３およびシステム計画策定明細テーブル２４４における計画設定区分の項目は、当該管理策が実施対象として選択されているか否かを示すフラグである。
【０１４１】
これらの計画策定ＤＢ２４０の各テーブルの情報は、後述する目標管理部５２０の予実管理部５２３による経年予実比較や計画策定部５２２によるシミュレーションの際などに用いるため、更新された場合には以前のレコードを履歴レコードとして保持する。また、これらの各テーブルの情報は、例えば、各部署の担当者等によって、目標管理部５２０により登録され、また更新などの管理が行われる。
【０１４２】
図２１は、診断ＤＢ２５０のテーブルの構成例を示した図である。診断ＤＢ２５０は、資産毎のセキュリティ対策状況やセキュリティリスク、およびこれに基づいて作成された種々の切り口の現状分析用のサマリーを保持するデータベースであり、例えば、診断明細テーブル２５１から構成される。
【０１４３】
診断明細テーブル２５１は、例えば、資産ＩＤ、管理策ＩＤ、部署ＩＤ、判定結果、判定手段、判定結果更新日時などの項目を有し、部署毎の各資産単位での管理策の実施状況の判定結果の情報を入力・保持する。判定結果の項目は、例えば、○（実施済み）、×（未実施）、Ｎ／Ａ（非該当）などで表される。診断明細テーブル２５１の情報は、判定手段の項目が「手動」もしくは「手動（監査）」の資産については、例えば、各部署の担当者等によって、現状分析部５１０により登録・更新される。また、判定手段の項目が「自動」の資産については、セキュリティ管理ツールサーバ３００から取得した情報によって自動的に判定結果が登録・更新される。
【０１４４】
本実施の形態のセキュリティ管理支援システム５では、管理策の実施状況の判定結果は資産（現物）単位で入力し管理するが、大規模組織で資産単位で入力・管理を行うことは多大な労力を要するため、上述したようにセキュリティ管理ツールサーバ３００から情報を取得して自動登録したり、後述するように、資産種別単位で一括して入力できるようにしたりして作業負荷を軽減している。なお、この診断明細テーブル２５１の情報は、後述する目標管理部５２０の予実管理部５２３による経年予実比較の際などに用いるため、更新された場合には以前のレコードを履歴レコードとして保持する。
【０１４５】
詳細は後述するが、ベースラインアプローチでのセキュリティレベルの採点は、例えば、管理策の総数に対する実施数の割合に重み付けをして行う。また、リスクベースアプローチでのリスクレベルの採点は、例えば、ベースラインアプローチでのセキュリティレベルの採点結果に対してさらに資産価値に基づくリスク係数を考慮して行う。なお、以上に示した各ＤＢの構成は一例であり、他のＤＢやテーブル、項目を有していてもよい。
【０１４６】
［現状分析］
以下、図１７におけるセキュリティ対策およびセキュリティリスクの現状レベルの分析（Ｓ４０１）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介してセキュリティレベルの現状分析を行うよう要求すると、セキュリティ管理支援サーバ５００の現状分析部５１０は、各ＤＢの内容を参照して、例えば図２２に示すような、現状のセキュリティレベルの診断結果を表示するセキュリティ診断画面を生成してクライアント端末４００上に表示する。
【０１４７】
図２２の例では、指定された部署について、指定された管理策カテゴリに属する各管理策についての実施状況に基づいて、指定されたセキュリティ基準毎にセキュリティレベルおよびリスクレベルを採点し、その結果を表示している。
【０１４８】
セキュリティレベルについては、現状分析部５１０のセキュリティレベル診断部５１１により、ベースラインアプローチによって採点を行う。各部署が保持する資産（資産テーブル２２２）の資産種別について、対象のセキュリティ基準によって割り当てられている各管理策（管理策実行パターンテーブル２３７）についての実施状況の判定結果（診断明細テーブル２５１）に基づいて、資産単位でのセキュリティレベルは、
セキュリティレベル＝
Σ（重み付け値×判定結果○（実施済み）の管理策）×１００
÷Σ（重み付け値×判定結果Ｎ／Ａではない管理策） …式（２）
の式によって算出する。
【０１４９】
ここで、重み付け値は、例えば、管理策セキュリティ基準テーブル２３２の基準重み付け値と、管理策実行パターンテーブル２３７の資産種別重み付け値とを乗算したものであり、判定結果は診断明細テーブル２５１の判定結果である。また、ここで判定結果○（実施済み）とは、対象の管理策の実施指示に係るタスクが対象の部署（におけるタスクの指示者）において実施の形態１の図１２、図１５で示した下比較での実施率が１００％となっていることを表す。
【０１５０】
また、Σは対象の資産について割り当てられている全ての管理策について合計することを示す。すなわち、対象の資産について割り当てられている管理策の総数と、そのうちの実施済み（判定結果○）の管理策の数との割合を重み付けして算出したものである。なお、ここでのセキュリティレベルは数値が高いほど良いことを示す。
【０１５１】
図２２の例は、セキュリティレベルを部署単位で採点（集計）したものであり、式（２）による計算を、対象の部署が保持する全ての資産に割り当てられている管理策に対して行ったものである。対象の部署が階層の末端（現場）の部署ではない場合は、当該部署の直近の下位部署のセキュリティレベルを平均したものを用いてもよい。
【０１５２】
また、リスクレベルについては、現状分析部５１０のリスク分析部５１２により、リスクベースアプローチによって採点を行う。例えば、各部署が保持する資産の資産種別に保持される情報（情報テーブル２２４）から求められるリスク係数、および式（２）で算出したセキュリティレベルに基づいて、
リスクレベル＝リスク係数×（１００−セキュリティレベル） …式（３）
の式によって算出する。
【０１５３】
ここで、リスク係数は当該部署が保持する資産に保持される情報の資産価値に基づいて算出される情報のリスクの高さを示す係数であり、例えば、当該部署が保持する資産に保持される情報の情報テーブル２２４における資産価値区分（機密性、完全性、可用性）のそれぞれの最大値を用いる。これにより、機密性、完全性、可用性の区分毎にリスクレベルを算出する。なお、ここでのリスクレベルは数値が低いほど良いことを示す。
【０１５４】
本実施の形態のセキュリティ管理支援システム５では、リスク係数を情報テーブル２２４の資産価値区分に基づいて算出しているが、上述したように情報テーブル２２４の資産価値金額（機密性、完全性、可用性）の値を用いてもよいし、他のリスク評価のための指標を用いてもよい。また、本実施の形態のセキュリティ管理支援システム５では、セキュリティレベル、およびリスクレベルを上記の式（２）、式（３）を用いて比較的簡易な方法で採点しているが、他の採点方法であってもよいし、セキュリティ基準毎に異なる採点方法であってもよい。
【０１５５】
採点されたセキュリティレベルについては、図２２に示すように、例えば、得点とともに最大幅を１００％としたゲージによって表示する。また、リスクレベルについては機密性、完全性、可用性の区分毎に得点を表示する。さらに、第三者判定割合として、対象の管理策のうち第三者判定によるものの割合をゲージとともに表示する。第三者判定割合については、上述したように、例えば診断明細テーブル２５１の判定結果の項目が「手動（監査）」もしくは「自動」のものを第三者判定によるものとして、その数の管理策の総数に対する割合として求める。この第三者判定割合が高いものは診断結果の信頼性が高いものと判断することができる。
【０１５６】
図２２のセキュリティ診断画面によってセキュリティ基準毎のセキュリティレベルの診断結果を参照したユーザは、さらに、例えば画面右のプルダウンメニューおよび「分析」ボタンでの操作により、対象のセキュリティ基準について種々の切り口（集計方法）での詳細分析を行うことができる。詳細分析の要求を受けたセキュリティ管理支援サーバ５００は、現状分析部５１０の詳細分析部５１３により診断明細テーブル２５１を参照して詳細分析を行い、その結果をクライアント端末４００に表示する。
【０１５７】
例えば、図２３は、現状のセキュリティレベルの診断結果を部署毎に比較して表示する部署比較画面の例を示した図である。図２３の例では、指定された部署について、その直近の下位部署毎に、指定された管理策カテゴリでのセキュリティレベルを集計し、その結果をグラフとして表示している。これにより、部署間でのセキュリティレベルの差異を把握することができる。この比較は、上位部署が各下位部署のセキュリティ対策の実施状況を把握するのに用いるとともに、下位部署が同一系列の他部署との間で実施状況を比較するのにも用いることができる。
【０１５８】
また、図２４は、現状のセキュリティレベルの診断結果を管理策カテゴリ毎に比較して表示するレーダーチャート画面の例を示した図である。図２４の例では、指定された部署について、管理策カテゴリ毎にセキュリティレベルを集計し、レーダーチャートの形式で表示している。これにより、管理策カテゴリ間でのセキュリティ対策の実施状況の差異（強み・弱み）を把握することができる。
【０１５９】
また、図２５は、当該部署における管理策の実施状況についての計画と実績を対比（予実管理）する情報として、後述する目標設定の処理により設定された目標セキュリティレベル（将来および過去の設定履歴）の値とこれまでのセキュリティレベル（過去の診断履歴）の値とを比較して表示する経年予実比較画面の例を示した図である。図２５の例では、指定された部署について、設定されたセキュリティレベルの期単位での目標値および実績値を集計し、目標値と実績値とを過去３期、当期、将来３期にわたってグラフ表示している。これにより、設定した目標のセキュリティレベルに対する達成状況を把握することができる。なお、ここでの処理は目標管理部５２０の予実管理部５２３によって行われる。
【０１６０】
また、図２６は、現状のセキュリティレベルの診断結果を管理策毎に詳細に表示する診断明細照会画面の例を示した図である。図２６の例では、指定された部署について、指定された資産種別および管理策カテゴリに該当する管理策毎の診断結果（判定結果）を実施率に基づいて集計し、表示している。ここでは、例として、「本部」を対象として、「デスクトップＰＣ」についての「管理策１、２、３、…」の実施を配下の各課（「営業１課
、２課、…」の担当者にタスクとして指示し、その実施状況に基づいて集計された現状のセキュリティレベルの診断結果を表示している。
【０１６１】
下段の診断結果の表における実施率は、「本部」を対象として、対象の各管理策について実施の形態１の図１２、図１５で示した下比較によって算出した実施率であり、これが１００％となっている場合には判定結果が○となる。
【０１６２】
なお、下段の診断結果の表において、判定手段が「自動」の管理策については、上述したように、セキュリティ管理ツールサーバ３００から判定結果を自動取得している。また、判定結果が「詳細設定」となっている管理策については、対象の資産毎に判定結果が異なる（「全て○」や「全て×」ではない）ことを示している。これについては、画面右の「詳細」ボタンを押下することにより、資産（機器）単位での診断結果の照会画面に遷移する。
【０１６３】
図２７は、現状のセキュリティレベルの診断結果を資産毎に詳細に表示する診断明細照会（詳細）画面の例を示した図である。図２７の例では、指定された部署、資産種別、管理策について、対応する資産（機器）毎に診断結果（判定結果）を診断明細テーブル２５１を参照して表示している。以上の図２６、図２７により、個別の管理策毎、資産毎に詳細にセキュリティ対策の実施状況を把握することができる。
【０１６４】
［目標設定］
以下、図１７における自部署および下位部署の目標レベルの設定（ステップＳ４０２）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介してセキュリティレベルの目標設定を行うよう要求すると、セキュリティ管理支援サーバ５００の目標設定部５２１は、例えば図２８に示すような、自部署のセキュリティレベルの目標を設定する自部署目標設定画面を生成してクライアント端末４００上に表示する。
【０１６５】
図２８の例では、指定された部署について、目標設定の対象のセキュリティ基準についてのこれまでのセキュリティレベルの目標設定値と実績の経年予実比較のグラフが表示されている。このグラフは上述した図２５のものと同様であり、目標管理部５２０の予実管理部５２３により生成する。ユーザは、この経年予実比較のグラフを参照しながら、次期以降の自部署の目標のセキュリティレベルを設定することができる。
【０１６６】
自部署の目標値の設定に際しては、後述する下位部署目標設定画面により上位部署から設定された目標値についても目標設定テーブル２４１の上位部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の上位部署設定目標リスクレベルを参照して合わせて表示される。自部署の目標値として設定する値は、上位部署から設定された目標値より小さい値とすることはできないなどの制限を設けてもよい。
【０１６７】
設定した目標値は、目標設定部５２１により、目標設定テーブル２４１の自部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の自部署設定目標リスクレベルに登録される。このとき、自部署が保持する資産およびその資産種別と管理策実行パターンテーブル２３７の内容とに基づいて、計画策定明細テーブル２４３、およびシステム計画策定明細テーブル２４４のエントリ、すなわち自部署が保持する資産種別（資産区分が「システム」の場合は資産）に割り当てられた管理策のエントリを作成する。
【０１６８】
さらに、図２８の自部署目標設定画面等から、図２９に示すような下位部署のセキュリティレベルの目標を設定する下位部署目標設定画面に遷移することができる。図２９の例では、指定された部署の直近の下位部署について、目標設定の対象のセキュリティ基準についての現状のセキュリティレベルのグラフが表示されている。このグラフは上述した図２３のものと同様であり、現状分析部５１０の詳細分析部５１３により生成する。ユーザは、この各下位部署の現状のセキュリティレベルのグラフを参照しながら、次期以降の各下位部署の目標のセキュリティレベルを設定することができる。
【０１６９】
下位部署の目標値の設定に際しては、前述の自部署目標設定画面により設定した自部署の目標値についても目標設定テーブル２４１の自部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の自部署設定目標リスクレベルを参照して合わせて表示される。設定した目標値は、対象の下位部署についての目標設定テーブル２４１の上位部署設定目標セキュリティレベルもしくはリスク目標設定テーブル２４２の上位部署設定目標リスクレベルに登録される。このように、部署毎の目標設定を、部署の階層構造を考慮した形で行うことができる。
【０１７０】
さらに、各部署の担当者は、図２８の自部署目標設定画面によって設定した自部署の目標値を達成するために実施すべき管理策およびその実施時期を、目標管理部５２０の計画策定部５２２により、図３０に示すような計画策定画面によって決定することができる。図３０の例では、指定された部署について、当該部署が保持する各資産種別について目標設定の対象であるセキュリティ基準によって割り当てられている管理策を、計画策定明細テーブル２４３およびシステム計画策定明細２４４から取得して計画明細として表示している。
【０１７１】
ここで、図中の表における優先度は、各計画明細の静的な優先度を示し、例えば、当該計画明細に対応する管理策についての管理策セキュリティ基準テーブル２３２の基準重み付けの値と、管理策実行パターンテーブル２３７の資産種別重み付けの値とを乗算したものとする。また、対象の管理策に係るタスクについて実施の形態１の図１２、図１５で示した下比較により算出した実施率が表示されている。すなわち、当該実施率は、当該計画明細に対応する管理策についての、対象の部署以下の組織における全資産の数と実施済みの資産の数との割合と等価である。
【０１７２】
また、管理策実行パターンテーブル２３７から取得した、各計画明細の管理策を実施する場合の概算単価、および未実施分の数量についても表示している。なお、図３０の例では、上述した優先度の値に（１−実施率）の値を乗算した値の降順で各計画明細を並べ替えて表示している。これにより、優先度が高くかつ現時点で実施率の低い計画明細が表の上位に表示されるようにすることができる。
【０１７３】
このように表示された各計画明細に対して、ユーザは、当該部署での実施の要否とその完了目標時期を、例えばチェックボックスやプルダウンメニューを利用して選択する。ここで選択した内容は、計画策定明細テーブル２４３もしくはシステム計画策定明細テーブル２４４の計画設定区分および目標達成年月の項目に反映される。上述したように、本実施の形態のセキュリティ管理支援システム５では、実施すべき管理策の設定単位は基本的に資産ではなく資産種別である。資産単位で実施すべき管理策を設定し管理するほうが精緻なセキュリティレベルの評価が可能であるが、大規模組織で資産単位で管理を行うことは多大な労力を要するからである。
【０１７４】
なお、各計画明細についての実施の要否の設定は、対象の情報資産が各階層の部署に存在するため、基本的にはタスクを指示（再アサイン）された各階層の部署で個別に行う必要がある場合もあるが、例えば「セキュリティポリシーの策定」など、各部署で個別に行うのではなく、企業全体もしくは各事業部等の単位（上位部署）で実施すれば他の部署（下位部署）は実施の必要がないという管理策もある。このような管理策については、例えば、個別に管理策カテゴリを割り当てるなどして識別可能とし、上位部署で実施されるもしくは既にされている場合には下位部署では自動的に実施されるもしくは実施されたものとして処理してもよい。
【０１７５】
本実施の形態のセキュリティ管理支援システム５では、さらに、計画策定に際してどの計画明細を実施すれば効果的に目標のセキュリティレベルを達成できるのかを判断するために、シミュレーションの機能を有する。実施する計画明細と完了目標時期を設定して保存ボタンを押下すると、各時期に各計画明細が実施されたとした場合の達成セキュリティレベル（シミュレーション結果）と、実施に要する概算費用（実施費用総額）を算出し、各時期の当該部署の目標セキュリティレベルと合わせて下段の表に表示する。ここで、実施費用総額は、例えば、各計画明細について、各時期において実施されている場合にはその単価に数量を乗算した値を、実施されていない場合には零を、各計画明細について合算して算出する。
【０１７６】
このように、当該部署で保持する資産種別に応じて対象となる計画明細の一覧が提示され、さらに、シミュレーション結果を参照しながら実施する計画明細を設定することができるため、各部署の担当者が容易に目標達成のための計画を策定することができる。
【０１７７】
［自己点検／内部監査］
以下、図１７における管理策の実施状況の自己点検／内部監査（Ｓ４０４）での処理内容について説明する。ユーザがクライアント端末４００から図示しないメイン画面等を介して現在のセキュリティ対策状況についての自己点検を行うよう要求すると、セキュリティ管理支援サーバ５００の現状分析部５１０は、例えば図３１に示すような、自部署のセキュリティ対策の診断結果を入力する診断明細入力画面を生成してクライアント端末４００上に表示する。
【０１７８】
図３１の例では、上述の図１２で示した診断明細照会画面と同様の画面から、指定された資産種別について管理策毎に実施率を参照して診断結果（判定結果）をプルダウンメニューで入力することができる。入力された結果は、診断明細テーブル２５１に反映される。なお、図３０の例と同様に、対象の管理策に係るタスクについて実施の形態１の図１２、図１５で示した下比較により算出した実施率が表示されている。
【０１７９】
このように、資産単位ではなく、資産種別単位で管理策毎の診断結果を入力することで、ユーザの作業負荷を軽減することができる。一方、対象の管理策について全ての資産（機器）で判定結果が同じではなく混在する場合には、資産単位での診断結果を入力するため、画面右の「詳細」ボタンを押下することにより、資産単位での診断結果の入力画面に遷移することもできる。
【０１８０】
図３２は、自部署のセキュリティ対策の診断結果を資産毎に入力する診断明細入力（詳細）画面の例を示した図である。図３２の例では、上述の図２７で示した診断明細照会（詳細）画面と同様の画面から、各資産（機器）について診断結果（判定結果）を個別にプルダウンメニューで入力することができる。入力された結果は、同様に診断明細テーブル２５１に反映される。なお、セキュリティ管理ツールサーバ３００から判定結果を取得することが可能な資産（機器）については、自動で判定結果が診断明細テーブル２５１に反映されるため手動での入力は不要である。
【０１８１】
なお、セキュリティ監査部門が各部署における管理策の実施状況の内部監査を行う場合には、図３１や図３２の診断明細入力画面において、部署プルダウンメニューから監査対象の部署を選択したうえで、同様に診断結果（判定結果）を入力する。
【０１８２】
以上、図２２〜図３２を用いて本実施の形態のセキュリティ管理支援システム５での処理内容の概要について説明したが、図２２〜図３２で示した各種画面については、その種類や画面構成、入出力の項目や方法などのユーザインタフェースはあくまで一例であり、当然ながら他のユーザインタフェースであってもよい。
【０１８３】
以上に説明したように、本実施の形態のセキュリティ管理支援システム５によれば、各部署が保持する保護すべき情報資産に関する情報をデータベース上に体系的に保持・管理し、セキュリティ管理ツールとの連携や、資産種別単位でのセキュリティ対策状況の判定結果の入力および目標設定・管理を可能とすることにより、ユーザ部門が情報資産の管理を容易に行うことが可能となる。
【０１８４】
さらに、セキュリティレベルやリスクレベルを種々の切り口で簡易に定量化して提示することによって、部署の階層構造の中で各部署がセキュリティ対策状況の現状把握と目標設定・予実管理を容易に行うことが可能となる。このため、セキュリティ管理に要する負荷を企業内で分散して効率的・効果的なセキュリティ管理を行うことが可能となる。また、各階層の部署毎に、セキュリティ対策状況の現状や実施の成果を定量的に把握することができるため、ユーザ部門のセキュリティ対策に対する関心を高めるとともに、部署間の競争心理を高めてセキュリティ対策を推進する効果を得ることができる。
【０１８５】
また、管理策を実施する作業をタスクとし、実施の形態１に示したタスク管理システムの機能を適用することで、タスクを階層構造で管理し、タスクの作成、配下の部署・担当者への展開や、タスクの階層構造に基づいた形での実施率の算出等を容易に行うことが可能となる。
【０１８６】
これにより、例えば、タスク（管理策）カテゴリと、これに対応する管理策ＩＤとを定義しておき、図１７に示したＰＤＣＡサイクルの１診断周期におけるタスク（管理策）の実施率を、図３０等に示すように診断結果の実施率に自動反映させるなどにより、タスク管理の機能を、セキュリティレベルおよびリスクレベルの定量化などを行うセキュリティ管理の機能に連携させることが可能となる。
【０１８７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１８８】
本発明は、企業等の組織体においてトップダウンで作業が指示されるタスクを管理するタスク管理システムに利用可能である。
【符号の説明】
【０１８９】
１…タスク管理システム、５…セキュリティ管理支援システム、
１００…タスク管理サーバ、１１０…タスク実施管理部、１１１…タスク操作部、１１２…タスク情報取得部、１２０…実施状況管理部、１３０…管理部、
２１０…ユーザ・部署ＤＢ、２１１…会社テーブル、２１２…部署テーブル、２１３…所属部署テーブル、２１４…担当ロールテーブル、２１５…ロールテーブル、２１６…ユーザテーブル、
２２０…資産ＤＢ、２２１…資産種別テーブル、２２２…資産テーブル、２２３…資産種別格納情報テーブル、２２４…情報テーブル、２２５…システム格納情報テーブル、
２３０…管理策ＤＢ、２３１…セキュリティ基準テーブル、２３２…管理策セキュリティ基準テーブル、２３３…管理策テーブル、２３４…リスク内容テーブル、２３５…管理策リスク内容テーブル、２３６…管理策実行部署テーブル、２３７…管理策実行パターンテーブル、
２４０…計画策定ＤＢ、２４１…目標設定テーブル、２４２…リスク目標設定テーブル、２４３…計画策定明細テーブル、２４４…システム計画策定明細テーブル、
２５０…診断ＤＢ、２５１…診断明細テーブル、
２６０…タスクＤＢ、２６１…タスクテーブル、２６２…カテゴリテーブル、
２７０…タスク進捗ＤＢ、２７１…タスク進捗テーブル、２７２…ステータステーブル、
３００…セキュリティ管理ツールサーバ、
４００…クライアント端末、
５００…セキュリティ管理支援サーバ、５１０…現状分析部、５１１…セキュリティレベル診断部、５１２…リスク分析部、５１３…詳細分析部、５２０…目標管理部、５２１…目標設定部、５２２…計画策定部、５２３…予実管理部、５３０…業務処理部、５４０…資産管理部、５５０…管理部。
【特許請求の範囲】
【請求項１】
階層構造を有する複数の部署からなる組織体における、前記部署の階層構造の上位の担当者から配下の下位の担当者に対しての作業実施の指示であるタスクの情報を保持し、前記タスクの実施状況の管理を行うタスク管理サーバと、前記タスク管理サーバにネットワーク経由で接続するクライアント端末とからなるタスク管理システムであって、
前記タスク管理サーバは、
前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して指示する前記タスクを新たに作成し、前記タスクの指示を受けた各担当者の単位で前記タスクに係る作業の進捗率およびステータスの管理を行うタスク進捗を作成して、前記タスクおよび前記タスク進捗の情報をデータベースに登録し、また、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記データベースに登録された前記タスクおよび前記タスク進捗の内容を修正して更新するタスク操作部と、
前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力するタスク情報取得部と、
前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出して出力する実施状況管理部と、
当該タスク管理システムを利用する前記ユーザおよび前記部署とその階層構造の情報を前記データベースに保持して管理する管理部とを有することを特徴とするタスク管理システム。
【請求項２】
請求項１に記載のタスク管理システムにおいて、
前記タスク操作部は、前記タスクを指示された前記ユーザからの要求により、指示された前記タスクの実行を、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して再指示する子タスクを作成して、作成した前記子タスクおよび前記子タスクに係る前記タスク進捗の情報をそれらの階層構造の情報とともに前記データベースに登録することを特徴とするタスク管理システム。
【請求項３】
請求項１または２に記載のタスク管理システムにおいて、
前記タスク操作部は、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記タスクもしくは前記子タスクが新たに作成され、前記タスク進捗が前記データベースに新たに登録された際の前記タスク進捗の前記ステータスを未指示とし、
前記タスク進捗に係る作業が一部実行された旨の進捗率が指定された際に、前記タスク進捗の前記ステータスを未完了に更新し、
前記タスク進捗に係る前記タスクの実行が、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して再指示された際に、前記タスク進捗の前記ステータスを指示済に更新し、
前記タスク進捗に係る作業が完了した旨が指定された際に、前記タスク進捗の前記ステータスを完了に更新することを特徴とするタスク管理システム。
【請求項４】
請求項１〜３のいずれか１項に記載のタスク管理システムにおいて、
前記実施状況管理部は、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出する際に、前記ユーザに係る前記タスク進捗について、前記タスクの階層構造における自身を含む下位に属する全ての前記タスク進捗を対象として実施率を算出して出力することを特徴とするタスク管理システム。
【請求項５】
請求項１〜３のいずれか１項に記載のタスク管理システムにおいて、
前記実施状況管理部は、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出する際に、前記タスクの指示を受けた各担当者に係る前記タスク進捗毎に、前記タスクの階層構造における自身を含む下位に属する全ての前記タスク進捗を対象とした実施率をそれぞれ算出して出力することを特徴とするタスク管理システム。
【請求項６】
請求項１〜５のいずれか１項に記載のタスク管理システムにおいて、
前記タスク情報取得部は、前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力する際に、前記ユーザが指示された前記タスクおよび前記ユーザが指示もしくは再指示した前記タスクにおける前記ユーザに係る前記タスク進捗の情報を取得して出力することを特徴とするタスク管理システム。
【請求項７】
１または複数の部署からなる組織体が保持する保護すべき情報資産についてのセキュリティレベルもしくはリスクレベルを評価して管理するセキュリティ管理支援サーバと、前記セキュリティ管理支援サーバにネットワーク経由で接続するクライアント端末とからなるセキュリティ管理支援システムであって、
前記セキュリティ管理支援サーバは、
前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署毎に、前記部署が保持する資産についての情報を資産データベースに登録または更新する資産管理部と、
前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記部署毎に、前記部署が保持する前記資産に対する管理策の実施状況についての診断結果を診断データベースに登録し、また、前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記診断データベースの内容に基づいて、前記各部署における現状の前記セキュリティレベルもしくは前記リスクレベルを管理対象のセキュリティ基準に基づいて採点し、前記ユーザにより指定された集計方法で集計した結果を前記クライアント端末に表示する現状分析部と、
前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記部署に対して前記ユーザにより指定された、前記セキュリティレベルもしくは前記リスクレベルの目標レベルとその達成時期を計画策定データベースに登録または更新する目標管理部と、
請求項１〜６のいずれか１項に記載のタスク管理システムにおける、前記タスク操作部、前記タスク情報取得部、前記実施状況管理部、および前記管理部とを有することを特徴とするセキュリティ管理支援システム。
【請求項１】
階層構造を有する複数の部署からなる組織体における、前記部署の階層構造の上位の担当者から配下の下位の担当者に対しての作業実施の指示であるタスクの情報を保持し、前記タスクの実施状況の管理を行うタスク管理サーバと、前記タスク管理サーバにネットワーク経由で接続するクライアント端末とからなるタスク管理システムであって、
前記タスク管理サーバは、
前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して指示する前記タスクを新たに作成し、前記タスクの指示を受けた各担当者の単位で前記タスクに係る作業の進捗率およびステータスの管理を行うタスク進捗を作成して、前記タスクおよび前記タスク進捗の情報をデータベースに登録し、また、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記データベースに登録された前記タスクおよび前記タスク進捗の内容を修正して更新するタスク操作部と、
前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力するタスク情報取得部と、
前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出して出力する実施状況管理部と、
当該タスク管理システムを利用する前記ユーザおよび前記部署とその階層構造の情報を前記データベースに保持して管理する管理部とを有することを特徴とするタスク管理システム。
【請求項２】
請求項１に記載のタスク管理システムにおいて、
前記タスク操作部は、前記タスクを指示された前記ユーザからの要求により、指示された前記タスクの実行を、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して再指示する子タスクを作成して、作成した前記子タスクおよび前記子タスクに係る前記タスク進捗の情報をそれらの階層構造の情報とともに前記データベースに登録することを特徴とするタスク管理システム。
【請求項３】
請求項１または２に記載のタスク管理システムにおいて、
前記タスク操作部は、前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記タスクもしくは前記子タスクが新たに作成され、前記タスク進捗が前記データベースに新たに登録された際の前記タスク進捗の前記ステータスを未指示とし、
前記タスク進捗に係る作業が一部実行された旨の進捗率が指定された際に、前記タスク進捗の前記ステータスを未完了に更新し、
前記タスク進捗に係る前記タスクの実行が、前記部署の階層構造における前記ユーザの配下の１または複数の担当者に対して再指示された際に、前記タスク進捗の前記ステータスを指示済に更新し、
前記タスク進捗に係る作業が完了した旨が指定された際に、前記タスク進捗の前記ステータスを完了に更新することを特徴とするタスク管理システム。
【請求項４】
請求項１〜３のいずれか１項に記載のタスク管理システムにおいて、
前記実施状況管理部は、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出する際に、前記ユーザに係る前記タスク進捗について、前記タスクの階層構造における自身を含む下位に属する全ての前記タスク進捗を対象として実施率を算出して出力することを特徴とするタスク管理システム。
【請求項５】
請求項１〜３のいずれか１項に記載のタスク管理システムにおいて、
前記実施状況管理部は、前記クライアント端末を介した前記ユーザからの要求により、前記ユーザに指示された前記タスクについての実施状況を算出する際に、前記タスクの指示を受けた各担当者に係る前記タスク進捗毎に、前記タスクの階層構造における自身を含む下位に属する全ての前記タスク進捗を対象とした実施率をそれぞれ算出して出力することを特徴とするタスク管理システム。
【請求項６】
請求項１〜５のいずれか１項に記載のタスク管理システムにおいて、
前記タスク情報取得部は、前記クライアント端末を介した前記ユーザからの要求により、前記データベースに登録された１つ以上の前記タスク進捗のうち、前記ユーザに関連する前記タスク進捗の情報を取得して出力する際に、前記ユーザが指示された前記タスクおよび前記ユーザが指示もしくは再指示した前記タスクにおける前記ユーザに係る前記タスク進捗の情報を取得して出力することを特徴とするタスク管理システム。
【請求項７】
１または複数の部署からなる組織体が保持する保護すべき情報資産についてのセキュリティレベルもしくはリスクレベルを評価して管理するセキュリティ管理支援サーバと、前記セキュリティ管理支援サーバにネットワーク経由で接続するクライアント端末とからなるセキュリティ管理支援システムであって、
前記セキュリティ管理支援サーバは、
前記クライアント端末を介した前記各部署におけるユーザからの要求により、前記部署毎に、前記部署が保持する資産についての情報を資産データベースに登録または更新する資産管理部と、
前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記部署毎に、前記部署が保持する前記資産に対する管理策の実施状況についての診断結果を診断データベースに登録し、また、前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記診断データベースの内容に基づいて、前記各部署における現状の前記セキュリティレベルもしくは前記リスクレベルを管理対象のセキュリティ基準に基づいて採点し、前記ユーザにより指定された集計方法で集計した結果を前記クライアント端末に表示する現状分析部と、
前記クライアント端末を介した前記各部署における前記ユーザからの要求により、前記部署に対して前記ユーザにより指定された、前記セキュリティレベルもしくは前記リスクレベルの目標レベルとその達成時期を計画策定データベースに登録または更新する目標管理部と、
請求項１〜６のいずれか１項に記載のタスク管理システムにおける、前記タスク操作部、前記タスク情報取得部、前記実施状況管理部、および前記管理部とを有することを特徴とするセキュリティ管理支援システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【公開番号】特開２０１１−８６６９（Ｐ２０１１−８６６９Ａ）
【公開日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願番号】特願２００９−１５３４６６（Ｐ２００９−１５３４６６）
【出願日】平成２１年６月２９日（２００９．６．２９）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願日】平成２１年６月２９日（２００９．６．２９）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]