(57)【要約】【課題】ソフトウェア開発のリスクの予兆の判断に関する負担を軽減すること。【解決手段】リスク判定装置は、ソフトウェアの開発に利用される複数のツールからログを収集する収集部と、前記開発におけるリスクの予兆を示す状況の発生の有無を判定するための指標を、前記収集部が収集したログから取得する取得部と、前記指標を予め設定された条件に当てはめて、前記予兆の有無を判定する判定部と、を有する。【選択図】図２
2019125158.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの開発に利用される複数のツールからログを収集する収集部と、
前記開発におけるリスクの予兆を示す状況の発生の有無を判定するための指標を、前記収集部が収集したログから取得する取得部と、
前記指標を予め設定された条件に当てはめて、前記予兆の有無を判定する判定部と、
を有することを特徴とするリスク判定装置。
【請求項２】
前記判定部によって前記条件が満たされたと判定された場合に、前記予兆の発生を示す通知を出力する通知部、
を有することを特徴とする請求項１記載のリスク判定装置。
【請求項３】
前記取得部は、ソフトウェアの開発で達成すべき目標に関する複数のカテゴリのそれぞれについて、当該カテゴリに関する指標を前記ログから取得して、取得した指標に基づいて当該カテゴリに関するリスクの度合いを判定し、
前記カテゴリごとに、前記度合いを出力する出力部、
を有することを特徴とする請求項１又は２記載のリスク判定装置。
【請求項４】
ソフトウェアの開発に利用される複数のツールからログを収集する収集手順と、
前記開発におけるリスクの予兆を示す状況の発生の有無を判定するための指標を、前記収集手順において収集したログから取得する取得手順と、
前記指標を予め設定された条件に当てはめて、前記予兆の有無を判定する判定手順と、
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リスク判定装置及びプログラムに関する。
【背景技術】
【０００２】
従来、ソフトウェアの各開発プロセスに関してプロジェクト管理又は課題管理等の目的ごとに、当該目的に適した各種のツールが利用されて、プロジェクトの管理等が行われている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】エンゲージメントを可視化するSlackボット「A;」、本日よりオープンβを無償公開、インターネット＜URL：http://jp.techcrunch.com/2017/06/06/laboratik-open-beta/＞
【非特許文献２】Laboratik、チームワークを可視化するSlackボット「A;」のクローズドβ版を提供開始、インターネット＜URL：https://codezine.jp/article/detail/9973＞
【非特許文献３】定量的プロジェクト管理ツール 「EPM Base Ver. 2.0」、インターネット＜URL：https://www.opst.co.jp/epm/＞
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来技術では、プロジェクト管理を行うツールは、開発プロセスや目的毎にそれぞれ独立で用意されているため、開発プロジェクトにおけるリスクの予兆はプロジェクト管理者等のスキルや経験に依存して判断する必要があり、プロジェクト管理者の負担が大きかった。多くのツールを管理し、各ツールごとに定量的に表示された情報画面が散在しており、リスクの有無、複数リスクのある場合の優先度を短時間に把握することが困難であった。
【０００５】
本発明は、上記の点に鑑みてなされたものであって、ソフトウェア開発のリスクの予兆の判断に関する負担を軽減することを目的とする。
【課題を解決するための手段】
【０００６】
そこで上記課題を解決するため、リスク判定装置は、ソフトウェアの開発に利用される複数のツールからログを収集する収集部と、前記開発におけるリスクの予兆を示す状況の発生の有無を判定するための指標を、前記収集部が収集したログから取得する取得部と、前記指標を予め設定された条件に当てはめて、前記予兆の有無を判定する判定部と、を有する。
【発明の効果】
【０００７】
ソフトウェア開発のリスクの予兆の判断に関する負担を軽減し、特に重要なリスク項目を定量的に表現することにより、迅速な意思決定を開発管理者へ促すことができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施の形態におけるリスク判定装置１０のハードウェア構成例を示す図である。
【図２】本発明の実施の形態におけるリスク判定装置１０の機能構成例を示す図である。
【図３】ログ収集処理の処理手順の一例を説明するためのフローチャートである。
【図４】プロジェクトの状況の表示指示に応じてリスク判定装置１０が実行する処理手順の一例を説明するためのフローチャートである。
【図５】Ｄｅｌｉｖｅｒｙに関する測定項目及びメトリクスの関係等の一例を示す図である。
【図６】Ｓｃｏｐｅに関する測定項目及びメトリクスの関係等の一例を示す図である。
【図７】Ｑｕａｌｉｔｙに関する測定項目及びメトリクスの関係等の一例を示す図である。
【図８】Ｃｏｍｍｕｎｉｃａｔｉｏｎに関する測定項目及びメトリクスの関係等の一例を示す図である。
【図９】分析結果出力画面の表示例を示す図である。
【図１０】リスク定義に基づいてリスク判定装置１０が実行する処理手順の一例を説明するためのフローチャートである。
【図１１】リスク定義の一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるリスク判定装置１０のハードウェア構成例を示す図である。図１のリスク判定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。
【００１０】
リスク判定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１１】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってリスク判定装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【００１２】
なお、リスク判定装置１０は、表示装置１０６及び入力装置１０７を有さなくてもよい。この場合、リスク判定装置１０にネットワークを介して接続される端末等が、表示装置１０６及び入力装置１０７とされてもよい。
【００１３】
図２は、本発明の実施の形態におけるリスク判定装置１０の機能構成例を示す図である。図２において、リスク判定装置１０は、開発ツール２０ａに対応したログ収集部１１ａ、開発ツール２０ｂに対応したログ収集部１１ｂ、開発ツール２０ｃに対応したログ収集部１１ｃ等の複数のログ収集部１１と、ログ分析部１２Ｄ、ログ分析部１２Ｓ、ログ分析部１２Ｑ及びログ分析部１２Ｃ等の４つのログ分析部１２と、分析結果出力部１３と、リスク判定部１４と、リスク通知部１５とを有する。これら各部は、リスク判定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。リスク判定装置１０は、また、ログ記憶部１６ａ、ログ記憶部１６ｂ及びログ記憶部１６ｃ等の複数のログ記憶部１６、並びにリスク定義記憶部１７等の記憶部を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又はリスク判定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００１４】
開発ツール２０ａ、開発ツール２０ｂ及び開発ツール２０ｃ等の複数の開発ツール２０は、ソフトウェアの開発に利用される各種のツール（ソフトウェア）である。例えば、開発ツール２０ａは、プロジェクト管理ツールであり、開発ツール２０ｂは、ソースコードのバージョン管理ツールであり、開発ツール２０ｃは、開発者間のコミュニケーションツールであるとする。なお、各開発ツール２０は、リスク判定装置１０外の１以上のコンピュータに分散されて配置されていてもよいし、リスク判定装置１０内に配置されていてもよい。
【００１５】
各ログ収集部１１は、それぞれに対応する開発ツール２０から定期的にログを収集する。ここで、ログとは、ログの収集時、又は前回のログの収集時から今回のログの収集時までの期間において、開発ツール２０が管理しているデータの複製（例えば、スナップショット）である。プロジェクト管理ツール又はバージョン管理ツールのように、或る時点のスナップショットが取得されれば十分な開発ツール２０については、ログの収集時のスナップショットがログとして取得されればよい。コミュニケーションツールのように、或る期間のデータ（コミュニケーションの内容）が取得される必要が有る開発ツール２０については、前回のログの収集時から今回のログの収集時までの期間のデータが取得されればよい。ログの取得方法や、取得対象のデータ等は、開発ツール２０に応じて異なりうる。したがって、開発ツール２０ごとにログ収集部１１が存在する。各ログ収集部１１は、それぞれが対応する開発ツール２０が公開しているＡＰＩ（Application Program Interface）を利用して、ログを収集してもよい。
【００１６】
なお、ログ収集部１１ａによって収集されたログは、ログ記憶部１６ａに記憶（蓄積）される。ログ収集部１１ｂによって収集されたログは、ログ記憶部１６ｂに記憶（蓄積）される。ログ収集部１１ｃによって収集されたログは、ログ記憶部１６ｃに記憶（蓄積）される。
【００１７】
４つのログ分析部１２のそれぞれは、ソフトウェア開発で達成すべき目標である、Ｄｅｌｉｖｅｒｙ（納期）、Ｓｃｏｐｅ（目標）、Ｑｕａｌｉｔｙ（品質）、Ｃｏｍｍｕｎｉｃａｉｔｏｎのいずれかのカテゴリに関するリスクの度合い（以下、「リスクレベル」という。）を測定するための１以上の項目（以下、「測定項目」という。）の値を、いずれかのログ記憶部１６に記憶されているログから取得されるメトリクス（指標）に基づいて計算する。具体的には、ログ分析部１２Ｄは、Ｄｅｌｉｖｅｒｙ（納期）に対応し、ログ分析部１２Ｓは、Ｓｃｏｐｅ（目標）に対応し、ログ分析部１２Ｑは、Ｑｕａｌｉｔｙ（品質）に対応し、ログ分析部１２Ｃは、Ｃｏｍｍｕｎｉｃａｉｔｏｎに対応する。
【００１８】
なお、Ｄｅｌｉｖｅｒｙ（納期）は、開発対象のソフトウェアの納期（開発期間）である。Ｓｃｏｐｅ（目標）は、開発対象のソフトウェアに対する要件である。Ｑｕａｌｉｔｙ（品質）は、開発作業の成果物であるソフトウェアの品質である。Ｃｏｍｍｕｎｉｃａｉｔｏｎは、開発プロジェクトのメンバ間のコミュニケーションである。
【００１９】
Ｄｅｌｉｖｅｒｙ（納期）に関するリスクとは、納期の超過である。Ｓｃｏｐｅ（目標）に関するリスクとは、要件を満たすことができないことである。Ｑｕａｌｉｔｙ（品質）に関するリスクとは、成果物であるソフトウェアの品質が一定基準を満たせないことである。Ｃｏｍｍｕｎｉｃａｉｔｏｎに関するリスクとは、チーム内の雰囲気が悪化したり、メンバ間のコミュニケーションが偏ったりすることである。
【００２０】
なお、本実施の形態では、１つのスプリントにおける各種のリスクの判定等の例について説明する。スプリントとは、開発、まとめ、レビュー、調整が繰り返される開発プロジェクトにおける１回分の繰り返しの開発期間をいう。各スプリントには、要件のリストが設定される。したがって、１つのスプリントでは、当該スプリントに対して設定された要件を満たすソフトウェアが成果物となり、当該成果物について、プロジェクトのメンバによってレビューが行われると共に、要件元の顧客等によってレビューが行われる。
【００２１】
１つのスプリントに対して設定された要件のリスト（集合）をバックログという。また、１つの要件は、当該要件を満たす成果物を開発するために必要とされる１以上のタスク（作業）に分解される。更に、１つのタスクは、当該タスクを遂行するために解決すべき１以上の課題に分解される。以下において、当該課題のことをチケットという。なお、本実施の形態では、チケットごとに予定工数が見積もられることとする。したがって、或るタスクの予定工数は、当該タスクに関するチケットの予定工数の合計によって求めることができ、バックログの予定工数は、当該バックログに属するタスクの予定工数の合計によって求めることができる。
【００２２】
但し、上記はバックログの構成の一例にすぎない。例えば、上記では、工数の計算に関する最小単位がチケットであるが、タスクが最小単位とされてもよい。
【００２３】
分析結果出力部１３は、任意のタイミングでユーザによって入力される、プロジェクトの状況の表示指示に応じ、各ログ分析部１２による分析結果を表示装置１０６に出力（表示）する。
【００２４】
リスク判定部１４は、リスク定義記憶部１７に記憶されている定義情報（以下、「リスク定義」という。）において監視対象として指定されている、リスクの予兆を示す状況又は現象（以下、「監視リスク」という。）の発生を検知する。すなわち、リスク判定部１４によって予兆の発生の有無が判定されるリスクは、ユーザによって任意に設定可能な定義に合致するリスクである。一方、ログ分析部１２によって判定されるリスクは、ログ分析部１２のロジックに組み込まれている静的な判定基準に基づくリスクである。なお、リスク定義記憶部１７には、監視リスクの発生の有無の判定のタイミングも設定可能であり、リスク判定部１４は、当該タイミングにおいて、監視リスクの発生の有無を判定する。
【００２５】
リスク通知部１５は、リスク判定部１４によって監視リスクが発生したと判定された場合に、監視リスクの発生を示す通知を出力する。リスク通知部１５は、所定のメールアドレスに、監視リスクの発生を通知するメールを所定のメールアドレス宛に送信してもよい。
【００２６】
以下、リスク判定装置１０が実行する処理手順について説明する。図３は、ログ収集処理の処理手順の一例を説明するためのフローチャートである。図３の説明において、符号ｘは、ａ、ｂ又はｃである。
【００２７】
ステップＳ１０１において、ログ収集部１１ｘは、予め設定されているログの収集時期の到来を待機する。なお、ログの収集時期は、ログ収集部１１ごとに異なってもよいし、全てのログ収集部１１について共通であってもよい。
【００２８】
ログの収集時期が到来すると、ログ収集部１１ｘは、開発ツール２０ｘからログを取得し（Ｓ１０２）、取得したログをログ記憶部１６ｘに記憶する（Ｓ１０３）。なお、ログには、現在日時が付与されてもよい。
【００２９】
図３の処理は、各ログ収集部１１によって並列的に実行される。したがって、各ログ記憶部１６には、並列的に、各ログ収集部１１に対応する開発ツール２０のログが蓄積される。
【００３０】
続いて、プロジェクトの状況の表示指示がユーザによって入力された場合にリスク判定装置１０が実行する処理手順について説明する。図４は、プロジェクトの状況の表示指示に応じてリスク判定装置１０が実行する処理手順の一例を説明するためのフローチャートである。
【００３１】
ユーザによる表示指示に応じ、各ログ分析部１２は、それぞれが対応するカテゴリ（Ｄｅｌｉｖｅｒｙ、Ｓｃｏｐｅ、Ｑｕａｌｉｔｙ、Ｃｏｍｍｕｎｉｃａｉｔｏｎ）に関する測定項目の計算に必要なメトリクスを、いずれかのログ記憶部１６から取得する（Ｓ２０１）。各メトリクスの取得先は、当該メトリクスを含むログが記憶されているログ記憶部１６である。
【００３２】
具体的には、ログ分析部１２Ｄは、Ｄｅｌｉｖｅｒｙに関する測定項目の計算に必要なメトリクスを、当該メトリクスを抽出可能なログを記憶するログ記憶部１６から取得する。
【００３３】
図５は、Ｄｅｌｉｖｅｒｙに関する測定項目及びメトリクスの関係等の一例を示す図である。図５には、Ｄｅｌｉｖｅｒｙのカテゴリに関する各測定項目について、「種別」、「Ｎｏ．」、「測定項目名」、「数式」、「必要メトリクス」、「取得先」等が示されている。
【００３４】
「種別」は、測定項目を「リスクサマリ項目」又は「サブ項目」に分類する概念である。「リスクサマリ項目」は、Ｄｅｌｉｖｅｒｙの観点におけるプロジェクトの状況を概観又は俯瞰するための測定項目である。「サブ項目」は、当該状況を詳細に観察するための測定項目である。
【００３５】
「Ｎｏ．」は、リスクサマリ項目又はサブ項目における測定項目の順番である。「測定項目名」は、測定項目の名称である。「数式」は、測定項目を取得するための数式又は方法である。「必要メトリクス」は、測定項目を計算するために必要なメトリクスである。「取得先」は、「必要メトリクス」の取得先の開発ツール２０を示す。本実施の形態において、開発ツール２０ａが「ＡＡＡ」に対応し、開発ツール２０ｂが「ＢＢＢ」に対応し、開発ツール２０ｃが「ＣＣＣ」に対応する。したがって、「取得先」が「ＡＡＡ」であるメトリクスは、ログ記憶部１６ａに記憶されているログから取得される。また、「取得先」が「ＢＢＢ」であるメトリクスは、ログ記憶部１６ｂに記憶されているログから取得される。更に、「取得先」が「ＣＣＣ」であるメトリクスは、ログ記憶部１６ｃに記憶されているログから取得される。
【００３６】
具体的には、図５において、Ｄｅｌｉｖｅｒｙのリスクサマリ項目としての測定項目は、「予定ベロシティ」及び「実績ベロシティ」である。
【００３７】
「予定ベロシティ」の「数式」は、
測定時点でのバックログの予定工数の合計値／スプリント日数
である。したがって、「予定ベロシティ」の「必要メトリクス」は、当該数式のパラメータである「測定時点でのバックログの予定工数の合計値」及び「スプリント日数」であり、これらは「ＡＡＡ」に対応するログ記憶部１６ａに記憶されているログを分析することで取得可能である。「測定時点でのバックログの予定工数の合計値」とは、測定時点においてバックログに含まれる全要件のそれぞれを構成する各タスクに属する各チケットの予定工数の合計値を意味する。予定工数の合計対象とされるチケットは、解決済みであるか否かを問わない。「測定時点での」という修飾語が付与されているのは、開発作業の進行に応じてチケット（課題）の増加（割り込み）が発生する可能性が有るからである。また、スプリント日数とは、スプリントの開始から終了までの日数をいう。なお、測定時点とは、ログの収集時期をいい、「必要メトリクス」は、最新の収集時期のログに含まれる値が採用される。
【００３８】
また、「実績ベロシティ」の「数式」は、
完了したチケットの予定工数の合計値／稼働済み日数
である。したがって、「実績ベロシティ」の「必要メトリクス」は、当該数式のパラメータである「完了したチケットの予定工数の合計値」及び「稼働済み日数」であり、これらはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「完了したチケットの予定工数の合計値」とは、測定時点において完了したチケット（課題）の予定工数の合計値である。「稼働済み日数」は、既に稼働した日数である。
【００３９】
一方、Ｄｅｌｉｖｅｒｙのサブ項目としての測定項目は、「未入力のバックログ件数」、「割り込みバックログ率」、「メンバ毎の実績ベロシティ」、「メンバ毎の実績完了」、「更新したコードの量」である。
【００４０】
「未入力のバックログ件数」の「数式」は、
予定工数が未入力のチケット件数
である。すなわち、「未入力のバックログ件数」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「未入力のバックログ件数」の「必要メトリクス」は、「予定工数が未入力のチケット件数」であり、これはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「予定工数が未入力のチケット件数」とは、測定時点において予定工数が開発ツール２０ａに入力されていないチケットの数である。
【００４１】
「割り込みバックログ率」の「数式」は、
スプリント開始後に追加されたチケット件数／測定時点でのチケット件数
である。したがって、「割り込みバックログ率」の「必要メトリクス」は、当該数式のパラメータである「スプリント開始後に追加されたチケット件数」及び「測定時点でのチケット件数」であり、これらはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「スプリント開始後に追加されたチケット件数」は、スプリントの開始前には未入力であったがスプリントの開始後に追加されたチケットの数（すなわち、チケットの増分）である。「測定時点でのチケット件数」は、測定時点における全チケット（解決済みであるか否かを問わない）の数である。
【００４２】
「メンバ毎の実績ベロシティ」の「数式」は、
メンバ毎の完了したバックログの予定工数の合計値／稼働済み日数
である。したがって、「メンバ毎の実績ベロシティ」の「必要メトリクス」は、当該数式のパラメータである「メンバ毎の完了したバックログの予定工数の合計値」及び「稼働済み日数」であり、これらはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「メンバ毎の完了したバックログの予定工数の合計値」とは、バックログのうち、プロジェクトのメンバごとに完了したチケットの予定工数の合計値である。すなわち、「メンバ毎の完了したバックログの予定工数の合計値」とは、バックログのうち、完了したチケットの予定工数の合計値である。「稼働済み日数」については上述した通りである。
【００４３】
「メンバ毎の実績完了」の「数式」は、
メンバ毎の完了したチケットの件数
である。すなわち、「未入力のバックログ件数」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「メンバ毎の実績完了」の「必要メトリクス」は、「メンバ毎の完了したチケットの件数」であり、これはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「メンバ毎の完了したチケットの件数」とは、プロジェクトのメンバごとの完了したチケットの数である。
【００４４】
「更新したコードの量」の「数式」は、
本スプリントで更新したコード量
である。すなわち、「更新したコードの量」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「更新したコードの量」の「必要メトリクス」は、「本スプリントで更新したコード量」であり、これは「ＢＢＢ」に対応するログ記憶部１６ｂに記憶されているログを分析することで取得可能である。「本スプリントで更新したコード量」とは、本スプリントにおいて、測定時点までに更新されたソースコードの行数である。
【００４５】
また、ログ分析部１２Ｓは、Ｓｃｏｐｅに関する測定項目の計算に必要なメトリクスを、当該メトリクスを含むログを記憶するログ記憶部１６から取得する。
【００４６】
図６は、Ｓｃｏｐｅに関する測定項目及びメトリクスの関係等の一例を示す図である。図６の見方は、図５と同様である。図６において、Ｓｃｏｐｅのリスクサマリ項目としての測定項目は「バックログの達成率」である。
【００４７】
「バックログの達成率」の「数式」は、
測定時点での完了済チケット件数／測定時点でのチケット件数
である。したがって、「バックログの達成率」の「必要メトリクス」は、当該数式のパラメータである「測定時点での完了済チケット件数」及び「測定時点でのチケット件数」であり、これらはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「測定時点での完了済チケット件数」は、測定時点において完了したチケットの数である。「測定時点でのチケット件数」については上述した通りである。
【００４８】
一方、Ｓｃｏｐｅのサブ項目としての測定項目は、「バックログの全体量推移」、「件数ベースでの達成件率推移」、「バーンダウンチャート」、「メンバ毎のバックログの完了状況」である。
【００４９】
「バックログの全体量推移」の「数式」は、
測定時点でのバックログの予定工数の合計値の時系列グラフ
である。すなわち、「測定時点でのバックログの予定工数の合計値」について時系列の値が必要とされる。したがって、「バックログの全体量推移」の「必要メトリクス」は、「各測定時点でのバックログの予定工数の合計値」であり、これはログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。
【００５０】
「件数ベースでの達成件率推移」の「数式」は、
（測定時点での完了済チケット件数／測定時点でのチケット件数）の時系列グラフ
である。すなわち、「測定時点での完了済チケット件数」及び「測定時点でのチケット件数」について時系列の値が必要とされる。したがって、「件数ベースでの達成件率推移」の「必要メトリクス」は、「各測定時点での完了済チケット件数」及び「各測定時点でのチケット件数」であり、これらは、ログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。
【００５１】
「バーンダウンチャート」の「数式」は、
測定時点での残チケットの予定工数の合計値の時系列グラフ
である。すなわち、「測定時点での残チケットの予定工数の合計値」について時系列の値が必要とされる。したがって、「バーンダウンチャート」の「必要メトリクス」は、「各測定時点での残チケットの予定工数の合計値」であり、これはログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。なお、「残チケットの予定工数の合計値」とは、完了していないチケットの予定工数の合計値である。
【００５２】
「メンバ毎のバックログの完了状況」の「数式」は、
メンバ毎の完了したチケットの件数
である。すなわち、「メンバ毎のバックログの完了状況」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「メンバ毎の完了したチケットの件数」の「必要メトリクス」は、「メンバ毎の完了したチケットの件数」であり、これはログ記憶部１６ａに記憶されているログを分析することで取得可能である。
【００５３】
また、ログ分析部１２Ｑは、Ｑｕａｌｉｔｙに関する測定項目の計算に必要なメトリクスを、当該メトリクスを含むログを記憶するログ記憶部１６から取得する。
【００５４】
図７は、Ｑｕａｌｉｔｙに関する測定項目及びメトリクスの関係等の一例を示す図である。図７の見方は、図５と同様である。図７において、Ｑｕａｌｉｔｙのリスクサマリ項目としての測定項目は、「スプリントレビューの差し戻し率」である。スプリントレビューとは、スプリントの終了後に、要件元の顧客等によって行われるレビューをいう。差し戻しとは、レビューにおいて、要件が十分に満たされていないと判断されることをいう。
【００５５】
「スプリントレビューの差し戻し率」の「数式」は、
差し戻し件数／スプリントレビューを実施したバックログ件数
である。したがって、「スプリントレビューの差し戻し率」の「必要メトリクス」は、当該数式のパラメータである「差し戻し件数」及び「スプリントレビューを実施したバックログ件数」であり、これらはログ記憶部１６ａに記憶されているログを分析することで取得可能である。「差し戻し件数」は、差し戻された要件の数である。「スプリントレビューを実施したバックログ件数」は、バックログのうち、スプリントレビューの対象とされた要件の数である。
【００５６】
一方、Ｑｕａｌｉｔｙのサブ項目としての測定項目は、「クローズ件数の推移」、「差し戻し件数の推移」、「解決済件数の推移」、「メンバ毎の差し戻しの割合」である。
【００５７】
「クローズ件数の推移」の数式は、
クローズチケット件数の時系列グラフ
である。すなわち、「クローズチケット件数」について時系列の値が必要とされる。したがって、「クローズ件数の推移」の「必要メトリクス」は、「各測定時点のクローズチケット件数」であり、これはログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。なお、クローズチケット件数とは、クローズされたチケットの数をいう。チケットのクローズとは、プロジェクトのメンバ内でのレビューにおいて、解決されたと判断されたチケットをいう。なお、スプリントレビューにおいて、要件元によって解決されたと判断されたチケットは、「解決済み」となる。
【００５８】
「差し戻し件数の推移」の「数式」は、
差し戻し件数の時系列グラフ
である。すなわち、「差し戻し件数」について時系列の値が必要とされる。したがって、「差し戻し件数の推移」の「必要メトリクス」は、「各測定時点の差し戻し件数」であり、これはログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。なお、「差し戻し件数」については上述した通りである。
【００５９】
「解決済件数の推移」の数式は、
解決済チケット件数の時系列グラフ
である。すなわち、「解決済チケット件数」について時系列の値が必要とされる。したがって、「解決済件数の推移」の「必要メトリクス」は、「各測定時点の解決済チケット件数」であり、これはログ記憶部１６ａに記憶されている各収集時期のログの履歴を分析することで取得可能である。なお、解決済チケット件数とは、解決されたチケットの数をいう。
【００６０】
「メンバ毎の差し戻しの割合」の「数式」は、
メンバ毎の差し戻し件数
である。すなわち、「メンバ毎の差し戻しの割合」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「メンバ毎の差し戻しの割合」の「必要メトリクス」は、「メンバ毎の差し戻し件数」であり、これはログ記憶部１６ａに記憶されているログを分析することで取得可能である。
【００６１】
また、ログ分析部１２Ｃは、Ｃｏｍｍｕｎｉｃａｔｉｏｎに関する測定項目の計算に必要なメトリクスを、当該メトリクスを含むログを記憶するログ記憶部１６から取得する。
【００６２】
図８は、Ｃｏｍｍｕｎｉｃａｔｉｏｎに関する測定項目及びメトリクスの関係等の一例を示す図である。図８の見方は、図５と同様である。図８において、Ｃｏｍｍｕｎｉｃａｔｉｏｎのリスクサマリ項目としての測定項目は、「ポジネガ割合」及び「発言者の割合」である。
【００６３】
「ポジネガ割合」とは、ポジティブな発言とネガティブな発言との割合であり、その「数式」は、
ポジネガ割合
である。すなわち、「ポジネガ割合」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。なお、図８において、「ポジネガ割合」の「取得先」は、「ＣＣＣ」である。本実施の形態において、開発ツール２０ｃが「ＣＣＣ」に対応する。したがって、ログ分析部１２Ｃは、ログ記憶部１６ｃに記憶されているログを分析することで「ポジネガ割合」を得ることができる。
【００６４】
「発言者の割合」の「数式」は、
発言者の割合
である。「発言者の割合」も「ポジネガ割合」と同様に、ログ記憶部１６ｃに記憶されているログを分析することで解析を行うことにより得ることができる。
【００６５】
一方、Ｃｏｍｍｕｎｉｃａｔｉｏｎのサブ項目としての測定項目は、「会話のポジネガの推移状況」、「発言の時間帯」、「指示語の多さ」、「メンバ毎の発言数」、「発言の方向性」、「コミットの時間帯」である。
【００６６】
「会話のポジネガの推移状況」の「数式」は、
ポジネガ割合の時系列グラフ
である。すなわち、「ポジネガ割合」について時系列の値が必要とされる。したがって、「ポジネガ割合の時系列グラフ」の「必要メトリクス」は、「各測定時点のポジネガ割合」である。
【００６７】
「発言の時間帯」の「数式」は、
時間帯別の発言数
である。すなわち、「発言の時間帯」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「発言の時間帯」の「必要メトリクス」は、「時間帯別の発言数」であり、これはログ記憶部１６ｃに記憶されているログを分析することで取得可能である。
【００６８】
「指示語の多さ」の「数式」は、
発言の中の指示語の数
である。すなわち、「指示語の多さ」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「指示語の多さ」の「必要メトリクス」は、「発言の中の指示語の数」であり、これはログ記憶部１６ｃに記憶されているログを分析することで取得可能である。
【００６９】
「メンバ毎の発言数」の「数式」は、
メンバ毎の発言数
である。すなわち、「メンバ毎の発言数」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。メンバ毎の発言数は、ログ記憶部１６ｃに記憶されているログを分析することで取得可能である。
【００７０】
「発言の方向性」の「数式」は、
ユーザー別の他者への発言数
である。すなわち、「発言の方向性」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。したがって、「発言の方向性」の「必要メトリクス」は、「ユーザー別の他者への発言数」であり、これはログ記憶部１６ｃに記憶されているログを分析することで取得可能である。
【００７１】
「コミットの時間帯」の「数式」は、
コミットの時間帯
である。すなわち、「コミットの時間帯」は、数式によって求まるものではなく、メトリクスがそのまま測定項目として採用される。コミットの時間帯は、ログ記憶部１６ｂに記憶されているログを分析することで取得可能である。
【００７２】
なお、図５〜図８において説明した測定項目は、一例である。また、本実施の形態では、全ての測定項目が利用されるわけではないが、本実施の形態では利用されない測定項目が以降の処理手順において利用されてもよい。
【００７３】
図４に戻る。ステップＳ２０２に続いて、各ログ分析部１２は、いずれかの測定項目に基づいて、それぞれに対応するカテゴリのリスクレベルを判定する（Ｓ２０３）。
【００７４】
具体的には、Ｄｅｌｉｖｅｒｙについては、以後の稼働で取り返せる状態か否かがリスクレベルの判断のポイントとされる。より詳しくは、割り込みタスクだけでなく、進捗遅れなどに伴う後続の作業量増大の影響が、スプリントの残期間で吸収可能な状況であるかが判定される。
【００７５】
そこで、ログ分析部１２Ｄは、以下のようにＤｅｌｉｖｅｒｙに関するリスクレベルを判定する。
【００７６】
測定時点の「予定ベロシティ」をＰｖ、「実績ベロシティ」をＡｖ、「スプリント日数」をＡｄ、「稼働済み日数」をＵｄとしたとき、ログ分析部１２Ｄは、ベロシティから求められる積み残し出来高Ｒｙを以下のように算出する。
Ｒｙ＝（Ｐｖ−Ａｖ）×Ｕｄ
ログ分析部１２Ｄは、Ｒｙをスプリント完了までの残稼働日数で割ることで、後の稼働で『取り戻し作業に必要な追加ベロシティ値』Ｒｖを算出する。
Ｒｖ＝Ｒｙ／（Ａｄ−Ｕｄ）
続いて、ログ分析部１２Ｄは、Ｒｖを「予定ベロシティ」Ｐｖで割る。これにより、メンバ一人に対する取り戻し負荷指数Ｒｌが求められる。
Ｒｌ＝Ｒｖ／Ｐｖ
Ｒｌ＜＝０であれば、進捗としては前倒し又はオンスケジュールであるため、ログ分析部１２Ｄは、Ｄｅｌｉｖｅｒｙに関するリスクレベルをＡ評価とする。０＜Ｒｌ＜０．５の場合、一人当たりの稼働が１．５倍（残業４Ｈ）未満に収まるため、ログ分析部１２Ｄは、Ｄｅｌｉｖｅｒｙに関するリスクレベルをＢ評価（警戒域）とする。０．５＜＝Ｒｌの場合、一人当たりの稼働が１．５倍（残業４Ｈ）を超過するため、ログ分析部１２Ｄは、Ｄｅｌｉｖｅｒｙに関するリスクレベルをＣ評価（危険域）とする。
【００７７】
また、Ｓｃｏｐｅについては、本来のゴールの達成状況が停滞していないかがリスクレベルの判断のポイントとされる。より詳しくは、本来のバックログの消化ペースを予定上一様であると仮定し、スプリントの進行に伴うバックログの消化状況との差分が計測される。残作業が間に合うか否かは、ベロシティで判断可能であるが、割り込みタスクが優先されてしまうため、本来のバックログに対する潜在課題／リスク等の検出が遅れていないかどうかをＳｃｏｐｅで判定する。
【００７８】
そこで、ログ分析部１２Ｓは、以下のようにＳｃｏｐｅに関するリスクレベルを判定する。
【００７９】
「スプリント日数」をＡｄ、「稼働済み日数」をＵｄ、「バックログの達成率」をＣｒとしたとき、ログ分析部１２Ｓは、以下のように規定される達成指数Ａを算出する。
Ａ＝Ｃｒ−Ｕｄ／Ａｄ
０＜＝Ａの場合、バックログの達成率はスプリントの進捗に対して前倒し又はオンスケジュールであるため、ログ分析部１２Ｓは、Ｓｃｏｐｅに関するリスクレベルをＡ評価とする。また、ログ分析部１２Ｓは、予め設定される「バックログのペンディング許容率Ｐａ」に基づいて、Ｂ評価及びＣ評価を区別する。具体的には、０＞Ａ＞＝−Ｐａの場合、ログ分析部１２Ｓは、Ｓｃｏｐｅに関するリスクレベルをＢ評価（警戒域）とする。−Ｐａ＞Ａの場合、ログ分析部１２Ｓは、Ｓｃｏｐｅに関するリスクレベルをＣ評価（危険域）とする。
【００８０】
また、Ｑｕａｌｉｔｙについては、リスクレベルの判断のポイントとして、２つのポイントが採用され、２つのポイントのそれぞれについてリスクレベルが判定される。
【００８１】
第１のポイントは、スプリント全体としての品質が維持できているか否かであり、スプリント全体としての品質状況が判定される。
【００８２】
第２のポイントは、レビューが定期的に実施され、チケットがクローズされているかである。すなわち、成果の評価を行うレビューが行われていない場合、差し戻し自体も行われないため、差し戻し率だけで品質を判定するのは困難である。そこで、チケットがクローズされている＝レビューが行われているとして、成果に対する評価活動が行われていることが確認される。
【００８３】
第１のポイントについて、ログ分析部１２Ｑは、以下のようにリスクレベルを判定する。
【００８４】
測定時点での「差し戻し率」をＢｒとし、予め設定される「許容差し戻し率」をＰｂとしたとき、０＜＝Ｂｒ＜＝０．５×Ｐｂの場合、ログ分析部１２Ｑは、第１のポイントに関するリスクレベルをＡ評価とする。０．５×Ｐｂ＜Ｂｒ＜＝１．５×Ｐｂの場合、ログ分析部１２Ｑは、第１のポイントに関するリスクレベルをＢ評価（警戒域）とする。１．５×Ｐｂ＜Ｂｒの場合、ログ分析部１２Ｑは、第１のポイントに関するリスクレベルをＣ評価（危険域）とする。
【００８５】
また、第２のポイントについて、ログ分析部１２Ｑは、以下のようにリスクレベルを判定する。
【００８６】
レビューは毎日行われるとは限らないため、ログ分析部１２Ｑは、第１のポイントのリスクレベルを週単位で判定する。なお、開発レビューは最低限１週間に１回以上行われることを前提とする。評価対象週のクローズチケット件数の増分をＣｉ、差し戻し件数の増分をＢｉ、解決済チケット件数の増分をＲｉとする。なお、Ｃｉ、Ｂｉ、Ｒｉは、順番に、「クローズチケット件数の推移」、「差し戻し件数の推移」、「解決済件数の推移」の測定項目に基づいて特定可能である。
【００８７】
ここで、Ｃｉ＋Ｂｉは、レビューを行って、完了／差し戻しを判断したチケットの数を示し、Ｒｉがレビューを依頼したチケットの数であるとみなせる。そこで、ログ分析部１２Ｑは、レビュー実施が行われているかどうかの評価は次のように実施する。すなわち、Ｃｉ＋Ｂｉ＞＝Ｒｉの場合、ログ分析部１２Ｑは、第２のポイントに関するリスクレベルをＡ評価とする。この場合、評価対象週のレビュー依頼の全てを消化、又は前週の積み残し分も消化したと考えられるからである。０．８×Ｒｉ＜Ｃｉ＋Ｂｉ＜＝Ｒｉの場合（すなわち、評価対象週の８割のレビュー依頼は消化された場合）、ログ分析部１２Ｑは、第２のポイントに関するリスクレベルをＢ評価とする。Ｃｉ＋Ｂｉ＜０．８×Ｒｉの場合（すなわち、評価対象週に実施されたレビューがレビュー依頼の８割に満たない場合）、ログ分析部１２Ｑは、第２のポイントに関するリスクレベルをＣ評価とする。
【００８８】
ログ分析部１２Ｑは、第１のポイント及び第２のポイントのそれぞれに関するリスクレベルを判定後、評価の低いリスクレベルをＱｕａｌｉｔｙに関するリスクレベルとして採用する。
【００８９】
また、Ｃｏｍｍｕｎｉｃａｔｉｏｎについても、リスクレベルの判断のポイントとして、２つのポイントが採用され、２つのポイントのそれぞれについてリスクレベルが判定される。
【００９０】
第１のポイントは、プロジェクトチームの雰囲気が悪化していなか、である。より詳しくは、チーム内でやり取りされている内容（コミュニケーションの内容）の感情状態に基づいて、ネガティブな発言ばかりが行われていないかどうかが判定される。したがって、コミュニケーションがネガティブな情報ばかりになっている場合に、雰囲気が悪化していると判定される。
【００９１】
第２のポイントは、プロジェクトチーム内のコミュニケーションの方向に偏りがないか、である。すなわち、チーム内でのコミュニケーションの方向（発言者、受信者）に偏りがある場合、メンバ間において積極性や温度感のギャップが有り、チームとして団結する雰囲気が損なわれている可能性が有る。第２のポイントでは、この可能性が判定される。
【００９２】
第１のポイントについて、ログ分析部１２Ｃは、以下のようにリスクレベルを判定する。
【００９３】
日によって突発的に（何らかのイベント等で）ポジティブな発言又はネガティブな発言が偏る場合を考慮し第１のポイントは週単位で判定される。
【００９４】
まず、ログ分析部１２Ｃは、評価対象週の各稼働日毎のポジティブ発言率Ｐｒ、ネガティブ発言率Ｎｒを取得し、Ｐｒの中央値Ｐｎ及びＮｒの中央値を求める。なお、Ｐｒ及びＮｒは、「ポジネガ割合」に基づいて特定可能である。
【００９５】
続いて、ログ分析部１２Ｃは、ポジティブ傾向指数Ｐｉを以下の式に基づいて計算する。
Ｐｉ＝Ｐｎ／Ｎｎ
１．０＜Ｐｉの場合、ポジティブな雰囲気であると考えられるため、ログ分析部１２Ｃは、第１のポイントに関するリスクレベルをＡ評価とする。０．５＜Ｐｉ＜＝１．０の場合、ややネガティブ傾向が強いと考えられるため、ログ分析部１２Ｃは、第１のポイントに関するリスクレベルをＢ評価とする。Ｐｉ＜０．５の場合、極めてネガティブ傾向が強いと考えられるため、ログ分析部１２Ｃは、第１のポイントに関するリスクレベルをＣ評価とする。
【００９６】
また、第２のポイントについて、ログ分析部１２Ｃは、以下のようにリスクレベルを判定する。
【００９７】
まず、ログ分析部１２Ｃは、「発言の方向性」に基づいて、メンバ毎の発言の発信数Ｓ、受信数Ｒを求める。
【００９８】
続いて、ログ分析部１２Ｃは、発信数Ｓの上位数名のメンバをサンプリングする共に、受信数Ｒの上位数名のメンバをサンプリングする。なお、サンプリング数は、予め設定されればよい。
【００９９】
続いて、ログ分析部１２Ｃは、発信数Ｓについてサンプリングしたメンバの発信数Ｓの総計Ｓｓ、受信数Ｒについてサンプリングしたメンバの受信数Ｒの総計Ｓｒを求める。
【０１００】
全メンバの発信数総計Ａｓ、受信数総計Ａｒ、予め設定される偏り許容量Ｄとしたとき、「Ｓｓ／Ａｓ＜＝Ｄ、かつ、Ｓｒ／Ａｒ＜＝Ｄ」の場合、ログ分析部１２Ｃは、第２のポイントに関するリスクレベルをＡ評価とする。「Ｓｓ／Ａｓ＞Ｄ、又は、Ｓｒ／Ａｒ＞Ｄ」の場合、ログ分析部１２Ｃは、第２のポイントに関するリスクレベルをＢ評価とする。
「Ｓｓ／Ａｓ＞Ｄ、かつ、Ｓｒ／Ａｒ＞Ｄ」の場合、ログ分析部１２Ｃは、第２のポイントに関するリスクレベルをＣ評価とする。
【０１０１】
ログ分析部１２Ｃは、第１のポイント及び第２のポイントのそれぞれに関するリスクレベルを判定後、評価の低いリスクレベルをＣｏｍｍｕｎｉｃａｔｉｏｎに関するリスクレベルとして採用する。
【０１０２】
続いて、分析結果出力部１３は、カテゴリごとに各ログ分析部１２によって判定されたリスクレベル等を含む分析結果出力画面を表示装置１０６に出力（表示）する（Ｓ２０４）。
【０１０３】
図９は、分析結果出力画面の表示例を示す図である。図９に示される分析結果出力画面５１０は、領域５１１〜５１７等を含む。
【０１０４】
領域５１１には、プロジェクト名及びスプリント名等が含まれる。領域５１２には、カテゴリごとのリスクレベルが含まれる。
【０１０５】
領域５１３には、Ｄｅｌｉｖｅｒｙに関する状況を概観させる情報として、ベロシティ予実比が示される。ベロシティ予実比は、Ｄｅｌｉｖｅｒｙのリスクサマリ項目である「予定ベロシティ」及び「実績ベロシティ」に基づいて求まる。すなわち、ベロシティ予実比＝実績ベロシティ／予定ベロシティである。したがって、領域５１３の上側に示されている分数の分母は「予定ベロシティ」であり、分子は「実績ベロシティ」である。領域５１３の下側の円グラフは、当該分数の計算結果を示す。なお、領域５１３に関する計算は、ログ分析部１２Ｄが実行してもよい。
【０１０６】
領域５１４には、Ｓｃｏｐｅに関する状況を概観させる情報として、Ｓｃｏｐｅのリスクサマリ項目である「バックログの達成率」が示される。領域５１４の上側に示されている分数の分母は「測定時点でのチケット件数」であり、分子は「測定時点での完了済チケット件数」である。領域５１４の下側の円グラフは、当該分数の計算結果を示す。なお、領域５１４に関する計算は、ログ分析部１２Ｓが実行してもよい。
【０１０７】
領域５１５には、Ｑｕａｌｉｔｙに関する状況を概観させる情報として、Ｑｕａｌｉｔｙのリスクサマリ項目である「差し戻し率」が示される。領域５１５の上側に示されている分数の分母は「スプリントレビューを実施したバックログ件数」であり、分子は「差し戻し件数」である。領域５１５の下側の円グラフは、当該分数の計算結果を示す。なお、領域５１５に関する計算は、ログ分析部１２Ｑが実行してもよい。
【０１０８】
領域５１６は、Ｃｏｍｍｕｎｉｃａｔｉｏｎに関する状況を概観させる情報として、Ｃｏｍｍｕｎｉｃａｔｉｏｎのリスクサマリ項目である「ポジネガ割合」に基づく円グラフが示される。領域５１７には、「発言の方向性」に基づく円グラフが示される。
【０１０９】
ユーザは、分析結果出力画面５１０を参照することで、プロジェクトの状況を概観する（要約する）ことができる。
【０１１０】
続いて、リスク定義に基づいてリスク判定装置１０が実行する処理手順について説明する。図１０は、リスク定義に基づいてリスク判定装置１０が実行する処理手順の一例を説明するためのフローチャートである。
【０１１１】
ステップＳ３０１において、リスク判定部１４は、リスク定義記憶部１７に記憶されているリスク定義を読み込む。
【０１１２】
図１１は、リスク定義の一例を示す図である。図１１において、リスク定義は、「監視条件」及び「判定時期」等の項目を含む。
【０１１３】
「監視条件」は、監視対象とする、リスクの予兆となる状況又は現象等を規定する条件である。図１１の例では、Ｄｅｌｉｖｅｒｙに関する測定項目である「実績ベロシティ」が前日比８０％以下であり、Ｃｏｍｍｕｎｉｃａｔｉｏｎに関する測定項目である「コミットの時間帯」に１８時以降の時間帯が含まれることが条件とされている。なお、コミットとは、ソースコードが開発ツール２０ｃに対してコミット（アップロード）されることをいう。コミットが１８以降の時間帯に行われるということは、作業の遅れのために残業が発生していることが考えられるため、リスクの条件とされている。
【０１１４】
「判定時期」は、「監視条件」の充足の有無（すなわち、「監視条件」によって規定された状況等の発生の有無）を判定するタイミングである。図１１の例では、毎日１２：００及び１８：００の２回において判定が行われることが設定されている。
【０１１５】
なお、図１１に示された「監視条件」及び「判定時期」は、一例に過ぎない。したがって、これらの項目について他の内容が設定されてもよい。また、リスク定義に対して更に別の項目が設定されてもよい。
【０１１６】
続いて、リスク判定部１４は、リスク定義における「判定時期」の到来を待機する（Ｓ３０２）。「判定時期」が到来すると（Ｓ３０２でＹｅｓ）、リスク判定部１４は、リスク定義の「監視条件」の判定に必要な測定項目を、当該測定項目に対応するログ分析部１２から取得する（Ｓ３０３）。リスク定義が、図１１に示される通りである場合、ログ分析部１２Ｄに対して、前日の同時期の「実績ベロシティ」と、現時点の（又は現時点において最新の）「実績ベロシティ」との取得が要求される。また、ログ分析部１２Ｃに対して、「コミットの時間帯」の取得が要求される。なお、測定項目の取得を要求されたログ分析部１２は、当該要求に応じて測定項目の計算を行ってもよいし、定期的に測定項目を計算しておき、要求された時期に対応する測定項目を応答してもよい。
【０１１７】
続いて、リスク判定部１４は、取得した測定項目を「監視条件」に当てはめて、「監視条件」の充足の有無を判定する（Ｓ３０４）。監視条件が充足される場合（Ｓ３０４でＹｅｓ）、リスク通知部１５は、監視リスクの発生（すなわち、リスク定義において規定されたリスクの予兆の発生）を示す通知を出力する（Ｓ３０５）。例えば、監視リスクが発生したことを内容とする電子メールが、所定のメールアドレス宛に送信されてもよい。
【０１１８】
上述したように、本実施の形態によれば、リスク定義に定義された、リスクの予兆を示す状況の発生の有無が自動的に監視され、当該状況の発生の有無が自動的に判定される。したがって、ソフトウェア開発のリスクの予兆の判断に関する負担を軽減することができる。
【０１１９】
また、監視対象の状況が発生した場合、当該状況の発生が通知される。したがって、管理者等は、リスクの予兆を迅速に知ることができる。
【０１２０】
なお、本実施の形態において、ログ収集部１１は、収集部の一例である。ログ分析部１２は、取得部の一例である。リスク判定部１４は、判定部の一例である。リスク通知部１５は、通知部の一例である。分析結果出力部１３は、出力部の一例である。
【０１２１】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１２２】
１０          リスク判定装置
１１ａ        ログ収集部
１１ｂ        ログ収集部
１１ｃ        ログ収集部
１２Ｄ        ログ分析部
１２Ｓ        ログ分析部
１２Ｑ        ログ分析部
１２Ｃ        ログ分析部
１３          分析結果出力部
１４          リスク判定部
１５          リスク通知部
１６ａ        ログ記憶部
１６ｂ        ログ記憶部
１６ｃ        ログ記憶部
１７          リスク定義記憶部
２０ａ        開発ツール
２０ｂ        開発ツール
２０ｃ        開発ツール
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１０６        表示装置
１０７        入力装置
Ｂ            バス
【図１】
2019125158.tif 000003
【図２】
2019125158.tif 000004
【図３】
2019125158.tif 000005
【図４】
2019125158.tif 000006
【図５】
2019125158.tif 000007
【図６】
2019125158.tif 000008
【図７】
2019125158.tif 000009
【図８】
2019125158.tif 000010
【図９】
2019125158.tif 000011
【図１０】
2019125158.tif 000012
【図１１】
2019125158.tif 000013