JP2021105866A - プログラム開発支援システム及びプログラム開発支援方法 - Google Patents

Abstract

【課題】チケットの属性によって、自動実行処理を自動で変更することで自動実行処理を効率的に実施する。【解決手段】自動実行処理サーバを有するプログラム開発支援システムは、自動実行処理サーバが、ソースコードが登録されたことを示すコミット完了通知を受け付けると、ソースコードの情報とチケットの情報を含むコミット情報を取得し、コミット情報からチケット識別子を抽出し、抽出したチケット識別子に基づいてチケットの属性情報を取得し、自動実行処理を行うソースコードに対応する実行対象情報を所定の順序を自動実行キューへ格納し、前記取得したチケットの属性情報に基づいて前記自動実行キューの実行対象情報の順序を変更し、自動実行処理の対象となるソースコード及びテストケースを取得し、自動実行処理変更部で変更された実行対象情報の順序に基づいてソースコード及びテストケースを用いて自動実行処理を行う。【選択図】図１Ｂ

Description

本発明は、プログラム開発支援システム及びプログラム開発支援方法に関する。

プログラムの開発手法として、アジャイル開発のベストプラクティスの一つである継続的インテグレーションと呼ばれる手法が知られている。継続的インテグレーションを用いたプログラム開発では、ソースコードを管理するバージョン管理システムへ作成したソースコードを登録（コミット）した際に、ソースコードのビルドやテストといった作業を自動で実行する。これにより、早い段階での不具合検出を可能にすることで、開発の効率化や高品質化を実現することができる。このような継続的インテグレーションを実現するツールとしては、例えば、Ｊｅｎｋｉｎｓ（非特許文献１）などが知られている。

また、プログラム開発において、作業をタスクに分割してＢＴＳ（Ｂｕｇ Ｔｒａｃｋｉｎｇ Ｓｙｓｔｅｍ：バグ管理システム）のチケット（帳票）に割り当てて管理を行う開発手法が、チケット駆動開発として知られている。このようなチケットを管理するツールとしては、例えば、Ｒｅｄｍｉｎｅ（非特許文献２）が知られている。非特許文献２の手法は、アジャイル開発との親和性が高いことから、上記の継続的インテグレーションと組み合わせて実践されることが多い。

上述の技術に関連する本技術分野の背景技術として、特許文献１が知られている。特許文献１には、継続的インテグレーションにおけるテストを効率的に実施することができるようにテストケースの選択を行うテストケースの選択方法及び選択システムが記載されており、継続的インテグレーションツールから渡された実施重要度及び実施時間閾値と、リポジトリに格納されたテストケースの重要度及び実行実績時間とから実行すべきテストケースを選択する手段が記載されている。

特開２０１０−１３４６４３号公報

Smart, John Ferguson（著）玉川 竜司（訳）、"Jenkins"、オライリー・ジャパン発行、2012年2月22日 Andriy Lesyuk 著、"Mastering Redmine"、Packt publishing発行、January 25, 2013

上記非特許文献１等に記載された継続的インテグレーションツール及び非特許文献２等に記載されたチケット管理ツールは組み合わせて実践されることがあり、連携するための仕組みが提供されている。

しかし、チケット管理ツールのチケット表示画面から、継続的インテグレーションツールで自動実行された結果の画面に遷移できるといった簡易的な連携のみのため、チケットに記載された内容に応じて自動実行を行いたい場合、事前に手動で設定する必要がある。

例えば、コミットが多くなると、自動実行処理の待ち行列が発生するため、優先順位が高いチケットに関する処理が後回しにならないような設定を、事前に手動で設定する必要がある。また、作業の内容によっては、自動実行の範囲や頻度を変えることで効率化を図ることができるが、あらゆる場合の状況を考慮した、範囲や頻度の設定を複数用意する必要がある。

また、特許文献１では、継続的インテグレーションツールから渡された実施の重要度及び実施時間の閾値と、リポジトリに格納されたテストケースの重要度及び実行実績時間とから実行すべきテストケースを選択する手段が記載されている。

これにより、継続的インテグレーションにおけるテストを効率的に実施することができるようにテストケースの選択を行うことができる。しかし、テストケースの重要度を基に判断しているため、テスト以外のビルドや静的解析（コーディングチェック）、レビューなどについては考慮されていない。

また、特許文献１では、判定している属性がテストケースの重要度のみのため、同じ重要度の場合の優先付けはできない。更に、チケットの属性となる期日や担当者、ステータスなどの属性は考慮されていない。そのため、テスト以外の処理についての優先度付けや、同じ重要度の場合の優先付けについて、チケットの属性情報に応じて、あらゆる場合の状況を考慮した設定を複数用意する必要がある。

そこで、本発明は、チケットの属性によって、自動実行処理の内容を自動的に変更することで自動実行処理を効率的に実施することができるプログラム開発支援システム及びプログラム開発支援方法を提供する。

本発明は、プロセッサとメモリと通信インターフェースを有する自動実行処理サーバを有するプログラム開発支援システムであって、前記自動実行処理サーバは、ソースコードが登録されたことを示すコミット完了通知を受け付けると、前記ソースコードの情報と前記ソースコードに対応するチケットの情報を含むコミット情報を取得するコミット情報取得部と、前記コミット情報から前記コミット完了通知に対応するチケット識別子を抽出する連携部と、前記抽出したチケット識別子に基づいて前記チケットの属性情報を取得する属性情報取得部と、自動実行処理を行う前記ソースコードに対応する実行対象情報を所定の順序で格納する自動実行キューと、前記取得したコミット情報からソースコードを指定する情報を実行対象情報として生成して前記自動実行キューへ投入し、前記取得したチケットの属性情報に基づいて前記自動実行キューの実行対象情報の順序を変更する自動実行処理変更部と、前記自動実行処理の対象となるソースコード及びテストケースを取得する対象成果物取得部と、前記自動実行処理変更部で変更された実行対象情報の順序に基づいて前記対象成果物取得部で取得した前記ソースコード及びテストケースを用いて自動実行処理を行う自動実行処理部と、前記自動実行処理部で実行した結果を通知する通知部と、を有する。

本発明によれば、チケットの属性情報によって、自動実行処理を自動的に変更することが可能となり、継続的インテグレーションにおける自動実行処理を効率的に実施することができる。

上記以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の実施例１を示し、プログラム開発支援システムの構成の一例を示すブロック図である。 本発明の実施例１を示し、自動実行処理サーバの構成の一例を示すブロック図である。 本発明の実施例１を示し、チケットの一例を示す図である。 本発明の実施例１を示し、プログラム開発支援システムで行われる処理の一例を示すフローチャートである。 本発明の実施例１を示し、プログラム開発支援システムで行われる処理の一例を示すフローチャートである。 本発明の実施例１を示し、プログラム開発支援システムで行われる処理の一例を示すフローチャートである。 本発明の実施例１を示し、ユースケースの一例を説明する図である。 本発明の実施例２を示し、ユースケースの一例を説明する図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

本実施例は、本発明のプログラム開発支援システム及びプログラム開発支援方法の１実施例である。以下、本実施例を図１Ａから図６を用いて説明する。

図１Ａは本実施例におけるプログラム開発支援システムの構成を示すブロック図である。図１Ｂは、自動実行処理サーバの構成の一例を示すブロック図である。図２は本実施例におけるチケットの記載内容を示す図である。図３は本実施例における自動実行処理システムにおける処理手順の概要を示すフローチャートである。図４は本実施例におけるキュー順序変更処理の詳細手順を示すフローチャートである。図５は本実施例における自動実行設定の詳細手順を示すフローチャートである。図６は本実施例における一つのチケットに対して複数の担当者がソースコードを修正していくユースケースを説明する図の例である。

図１Ａにおいて、１００はソースコードやソースコードに対応するテストケース（実行環境など）をバージョン単位で管理するバージョン管理サーバであり、１１０はプログラム作成に係る作業や不具合に係る内容をチケット（帳票）として管理するチケット管理サーバであり、１２０は前記バージョン管理サーバ１００にソースコードが登録（コミット）された際に、ソースコードのビルドやテスト等のプログラム作成に係る作業を自動で実行する自動実行処理サーバであり、３００はソースコードの生成を行う開発クライアントである。

本実施例におけるプログラム開発支援システムは、これらのバージョン管理サーバ１００、チケット管理サーバ１１０、自動実行処理サーバ１２０、開発クライアント３００から構成される。

１０１は前記バージョン管理サーバ１００で管理するソースコードやテストケースを格納する成果物データベースである。１０２は前記成果物データベース１０１のソースコードやテストケースを登録し、検索などの管理をする管理部である。本実施例におけるバージョン管理サーバ１００は、これら成果物データベース１０１及び管理部１０２で構成される。

また、１１１は前記チケット管理サーバ１１０で管理するチケットを格納するチケットデータベースである。１１２は前記チケットデータベース１１１のチケットを登録、検索などの管理をする管理部である。本実施例におけるチケット管理サーバ１１０は、これらチケットデータベース１１１及び管理部１１２で構成される。なお、バージョン管理サーバ１００及びチケット管理サーバ１１０は、市販又はＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）の既存ツールを用いてもよい。

また、１２１は前記バージョン管理サーバ１００からコミットされた情報を取得するコミット情報取得部である。１２２はコミット情報取得部１２１で取得したコミット情報から該コミットに対応するチケットのＩＤ（又は番号）を抽出して前記バージョン管理サーバ１００と前記チケット管理サーバ１１０とを連携する連携部である。１２３は抽出したチケットＩＤのチケットについて前記チケット管理サーバ１１０からチケットの属性情報を取得する属性情報取得部である。

１２４は取得したチケットの属性情報に基づいて、自動実行キュー１２７に格納された実行対象情報の順序を変更する自動実行処理変更部である。１２５は自動実行の対象となるソースコード及びテストケースを前記バージョン管理サーバ１００から取得する対象成果物取得部である。

本実施例では、自動実行を行う一つの処理を実行対象情報とし、自動実行キュー１２７には１以上の実行対象情報が格納される。実行対象情報には、自動実行処理を行うソースコードとテストケースを指定する情報が含まれる。自動実行処理変更部１２４は、自動実行キュー１２７に格納された実行対象情報の実行順序を制御する。なお、実行対象情報は、ソースコードとテストケースを指定する情報に限定されるものではなく、ソースコードとテストケースの実体であってもよい。

１２６は自動実行処理変更部１２４で決定された実行対象情報の処理順序に基づいて対象成果物取得部１２５で取得した対象のソースコード及びテストケースを用いて自動実行処理を行う自動実行処理部である。なお、自動実行処理部１２６は、前記従来例と同様に、ソースコードのビルドとテストケースによるテストと、静的解析及びレビューを実施する。１２７は１以上の実行対象情報を所定の順序でキュー内を管理する自動実行キューである。１２８は自動実行処理部で実行した結果をメール等で関係者に通知する通知部である。

本実施例における自動実行処理サーバ１２０は、これらコミット情報取得部１２１、連携部１２２、属性情報取得部１２３、自動実行処理変更部１２４、対象成果物取得部１２５、自動実行処理部１２６、自動実行キュー１２７、通知部１２８で構成される。

３１０は開発担当者が操作する入力デバイス（図示省略）から受け付けた情報からソースコードの生成等を行う開発ツールである。３２０は、生成されたソースコードやソースコードに付随する情報（テストケース等）を格納するソース格納部である。

本実施例における開発クライアント３００は、これら開発ツール３１０とソース格納部３２０から構成される。

図１Ｂは、自動実行処理サーバ１２０の構成の一例を示すブロック図である。自動実行処理サーバ１２０は、プロセッサ１１と、メモリ１２と、通信インターフェース１３と、入出力装置１４と、ストレージ装置１５を含む計算機である。

入出力装置１４は、マウスやキーボードあるいはタッチパネルなどの入力装置と、ディスプレイなどの出力装置を含む。通信インターフェース１３は、ネットワーク８０を介して、バージョン管理サーバ１００やチケット管理サーバ１１０や開発クライアント３００と通信を行う。

メモリ１２には、コミット情報取得部１２１、連携部１２２、属性情報取得部１２３、自動実行処理変更部１２４、対象成果物取得部１２５、自動実行処理部１２６及び通知部１２８がロードされてプロセッサ１１によって実行される。また、メモリ１２には自動実行処理部１２６が管理する自動実行キュー１２７が設定される。

プロセッサ１１は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ１１は、自動実行処理プログラムに従って処理を実行することで自動実行処理部１２６として機能する。他のプログラムについても同様である。更に、プロセッサ１１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

図２は、前記チケット管理サーバ１１０で管理するチケットの画面表示例であり、チケットの属性を示す。

図２において、２０１は「作業」や「不具合」などチケットの種類を示す種類属性である。２０２はチケットのタイトルを示すタイトル属性である。２０３はチケットの「作業詳細」や「不具合詳細」を示す内容説明属性である。

２０４はチケットの担当者を示す担当者属性である。２０５は「新規」や「作業中」「作業完了」といったチケットの状況、状態を示すステータス属性である。２０６は作業や不具合等のチケットで対応する処理の優先度を示す優先度属性である。

２０７は作業や不具合対応の期日を示す期日属性である。２０８はチケットの一段上の階層チケットである親チケットの情報を示す親チケット属性である。２０９は別のチケットのステータス属性が「終了」となっていないと着手できないといった作業順序としての関連や、内容が重複するといった関連するチケットがあることを示すチケット属性である。

２１０は工程管理上、全工程が終了するまでの作業の連なりのうち、並行して作業してもこれ以上作業時間を短くすることができない作業の連なり（クリティカルパス）のチケットかどうかを示すクリティカルパス属性である。２１１はチケットに示す作業内容の状況の報告やチケットの属性の変更履歴を示す変更履歴属性である。

なお、図２では、これらの属性がチケット画面上に明記されているが、チケット画面上に明記されていなくてもよい。例えばクリティカルパス属性２１０は、チケットの属性データとして表示されてもよい。

ここで本実施例の処理概略について図１及び図３のフローチャートを用いて説明する。まずチケット管理サーバ１１０にて発行されたチケットに対し、開発クライアント３００を使用する担当者は発行されたチケットの内容に従って、プログラム作成（ソースコード作成又は修正）を行う。

その後、担当者はバージョン管理サーバ１００を用いて該ソースコードを登録（コミット）する。その際、コミットログなどに対応するチケットのチケット番号（ＩＤ）などを記載し、該ソースコードがどのチケットに対するものかを明記する。バージョン管理サーバ１００は、ソースコードのコミットが完了すると、自動実行処理サーバ１２０にコミットが完了したことを示す通知（コミット完了通知）を送信する。

自動実行処理サーバ１２０は、コミット完了通知を受信したことを契機として、コミット情報取得部１２１にて、該コミットの情報（コミット情報）をバージョン管理サーバ１００から取得する（ステップＳ３０１）。ここで本実施例におけるコミットの情報とは、コミットされたソースコードのファイル名（又は識別子）やコミットログ（チャートの識別子）やテストケースを含むコミット時の情報である。

連携部１２２にて、前記コミット情報取得部１２１で取得したコミット情報に含まれる対応チケット番号（又はチケットＩＤ）などのチケットの情報を取得し、該コミットと対応するチケットをチケット管理サーバ１１０に選定させる（ステップＳ３０２）。

その後、属性情報取得部１２３にて、対応するチケットのチケット属性の情報をチケット管理サーバ１１０から取得する（ステップＳ３０３）。ここで本実施例におけるチケット属性は、図２で示したチケット属性（２０１〜２１０）である。

自動実行処理変更部１２４にて、取得したチケット属性情報に基づいて、自動実行キュー１２７のキュー順序を変更する（ステップＳ３０４）。

自動実行処理変更部１２４は、まず、取得したコミット情報からソースコードとテストケースを指定する情報を実行対象情報として生成して自動実行キュー１２７へ投入する。そして、自動実行処理変更部１２４は、取得したチケット属性情報に基づいて、実行対象情報の順序を変更又は設定する（ステップＳ３０５）。

自動実行処理部１２６にて、上記ステップＳ３０３で取得したチケット属性情報のうち期日属性２０７を用いて、過去の自動実行処理の実績時間から期日内に実行対象情報の自動実行が完了するか否かを判定し（ステップＳ３０６）、期日内に自動実行が完了する場合は、前記ステップＳ３０５で設定した順序に従い自動実行キュー１２７内の実行対象情報の自動処理を実行する（ステップＳ３０７）。

なお、自動実行処理部１２６は、ソースコードとテストケースの組み合わせ（実行対象情報）毎に、実行時間の実績をストレージ装置１５へ格納しておき、当該実行対象情報の自動実行が過去の実行時間の実績から期日属性２０７までに完了可能か否かを判定する。なお、過去の実行時間の実績は、実行時間の最大値や平均値など予め設定した統計情報を用いることができる。

一方、自動実行処理部１２６が期日内に完了しないと判定した実行対象情報については、期日までに完了しない旨のメッセージを含めたアラート情報を設定し（ステップＳ３０８）、自動処理は実行しない。その後、通知部１２８にて、ステップＳ３０７で実行した結果又はステップＳ３０８で設定したアラートをメールやメッセージ等の通知手段を用いて予め設定された宛先（例えば、開発クライアント３００）に通知し（ステップＳ３０９）、一連の処理を終了する。

次に図３で示したフローチャートのうち、キュー順序変更処理（ステップＳ３０４）の詳細手順について、図４のフローチャートを用いて説明する。キュー順序変更処理は、自動実行処理変更部１２４で実行する。この処理は、コミット完了通知に対応するソースコードに対応するチケットの情報について実施される。

自動実行処理変更部１２４は、チケット属性情報取得（ステップＳ３０３）で取得したチケット属性情報のうち優先度属性２０６が「大（又は高）」など高い優先度か否かを判定する（ステップＳ４０１）。自動実行処理変更部１２４は、優先度属性２０６の値が所定の閾値Ｔｈｐ以上であれば優先度が高いと判定してステップＳ４０４へ進む。

一方、優先度属性２０６の優先度が高くない場合、自動実行処理変更部１２４は、当該チケット属性情報の期日属性２０７に対して、期日までの日数が所定の閾値Ｔｈｄ以内か否かを判定する（ステップＳ４０２）。ここで閾値Ｔｈｄは予め決めた設定値とする。

自動実行処理変更部１２４は、ステップＳ４０２にて、期日属性２０７までの日数が閾値Ｔｈｄを超える場合、期日までに余裕があると判断し、ステップＳ４０３に移行する。ステップＳ４０３では、自動実行処理変更部１２４が、クリティカルパス属性２１０に対してフラグが設定されているか否かを判定する。

自動実行処理変更部１２４は、フラグが設定されていない場合は、クリティカルパスのチケットではないと判定し、最終的にキューの順序を変更する必要がないチケットだと判定して一連の処理を終了する。

自動実行処理変更部１２４は、ステップＳ４０１において、優先度属性２０６が閾値Ｔｈｐ以上の高い優先度であった場合、又は、ステップＳ４０２において、期日までの残日数が閾値Ｔｈｄ以内であった場合、すなわち期日までに時間がないと判断した場合、又は、ステップＳ４０３において、クリティカルパスのチケットだと判定した場合、自動実行キュー１２７内の実行対象情報の順序を変更する必要があると判定してステップＳ４０４へ進む。

自動実行処理変更部１２４は、第１ソートキーを「優先度」の高い順に設定し（ステップＳ４０４）、第２ソートキーを「期日」までの残日程が短い順に設定し（ステップＳ４０５）、第３ソートキーを「クリティカルパス」かどうかに設定（ステップＳ４０６）する。そして、自動実行処理変更部１２４は、第１から第３ソートキーにより自動実行キュー１２７内の実行対象情報をソートし、自動実行キュー１２７の実行対象情報の順序を変更し（ステップＳ４０７）、一連の処理を終了する。

すなわち、自動実行処理変更部１２４は、コミット完了通知のソースコードに対応するチケットの属性情報に応じて、実行対象情報の実行順序を変更するか否かを決定して、変更する場合には、チケット属性情報に応じて実行対象情報を所定の順序でソートする。なお、上記実施例では優先度と、期日と、クリティカルパスで実行対象情報の実行順序を変更する例を示したが、これに限定されるものではない。実行対象情報をソートする要素は、チケット属性情報から少なくともひとつを選択しておけばよい。

次に図３で示したフローチャートのうち、自動実行設定（ステップＳ３０５）の詳細手順について、図５のフローチャートを用いて説明する。

自動実行設定は、自動実行処理変更部１２４で実行する。自動実行処理変更部１２４は、チケット属性情報取得（ステップＳ３０３）で取得したチケット属性情報のうち親チケット属性２０８を用いて、親チケットへのコミットであったか否かを判定する（ステップＳ５０１）。

親チケットへのコミットでなかった場合、自動実行処理変更部１２４は、担当者属性２０４からチケットの担当者を抽出する。次に、自動実行処理変更部１２４は、チケット管理サーバ１１０から該担当者属性２０４に対応するチケットを抽出させて、未完了の担当チケット数と、過去の担当不具合チケット数の情報を取得する。また、自動実行処理変更部１２４は、バージョン管理サーバ１００から該担当者のコミット件数の情報を取得し、いずれかの数値が予め定めた閾値Ｔｈｃより大きいか、又は、履歴属性２１１から担当者の変更情報を取得し、担当者の変更日時と現在日時の差分が予め定めた閾値Ｔｈｃより小さいかを判定する（ステップＳ５０２）。

自動実行処理変更部１２４は、上記チケット数又はコミット件数が閾値Ｔｈｃより小さい場合、かつ、担当者が変わったばかりではない場合、ステータス属性２０５の情報からステータスが「作業中」か「作業完」を判定する（ステップＳ５０３）。

ステータスが「作業中」であった場合、自動実行処理変更部１２４は、自動実行処理の内容が効率的に行われる設定にし（ステップＳ５０４）、一連の処理を終了する。ここで自動実行処理が効率的に行われる設定とは、例えば、ビルドやテスト実行の対象ソースコードをコミットしたファイルのみに限定し、レビュー実施は不要とし、また、同件不具合の横展開の修正内容が含まれるかのチェックをしない、開発責任者へ自動実行結果のメール通知をしない、といった設定にすることである。

上記ステップＳ５０１にて親チケットへのコミットと判断した場合、自動実行処理変更部１２４は、子チケットの内容を親チケットへ統合（マージ）する作業プロセス上で重要なコミットだったと判定できるため、自動実行処理の内容が重点的に行われる設定にし（ステップＳ５０５）、一連の処理を終了する。

同様に、ステップＳ５０２にて、チケット数又はコミット件数が閾値Ｔｈｃより大きい場合、又は、担当者が変わったばかりの場合、自動実行処理変更部１２４は、重点的にテスト等が必要であると判定し、自動実行処理が重点的に行われる設定にし（ステップＳ５０５）、一連の処理を終了する。

更に、ステップＳ５０３にて、ステータスが「作業完」であった場合、自動実行処理変更部１２４は、自動実行処理が重点的に行われる設定にし（ステップＳ５０５）、一連の処理を終了する。

ここで自動実行処理が重点的に行われる設定とは、例えば、ビルドやテスト実行対象を対象製品の全ソースコードにし、レビュー実施は必須とし、同件不具合の横展開修正内容が含まれるかもチェックし、開発責任者へ自動実行結果のメール通知を行う、といった設定にすることである。

図４及び図５で示した処理により、自動実行処理変更部１２４は、コミット完了通知に対応するチケットの属性によって、自動実行処理を自動的に変更することで、必要性に応じて自動実行処理を効率的に実施することができる。

なお、上記では自動実行処理変更部１２４が、親チケット属性２０８と、担当者属性２０４と、履歴属性２１１に基づいて自動実行処理の内容を決定する例を示したが、これに限定されるものではない。自動実行処理変更部１２４は、チケット属性情報の少なくともひとつの属性に基づいて自動実行処理の内容を決定してもよい。

次に図６を用いて、本発明の一実施例を示す。本実施例では、一つのチケットに対して複数の担当者がソースコードを修正していく場合の例である。図６はそのユースケースを示す図である。

図６に示すユースケースでは、種類属性２０１が「不具合」であるチケット６０１に対して、不具合の修正を担当者Ａと担当者Ｂの二人が開発クライアント３００で修正する場合を示す。なお担当者Ａは、担当しているチケットで未完了のチケット数は少なく、過去に担当した不具合チケット数も少なく、コミット件数も少ない担当者である。担当者Ｂも担当者Ａと同様に、担当しているチケットで未完了のチケット数は少なく、過去に担当した不具合チケット数も少なく、コミット件数も少ない担当者の場合である。

不具合の発見者によりチケット管理サーバ１１０に不具合のチケット６０１が入力される。不具合の対応者として最初に担当者Ａが割り当てられる。担当者Ａは、チケット６０１の記載内容を元に原因究明を行い、開発クライアント３００で不具合の修正を行う。

その際、チケット６０１のステータス属性は、チケット管理サーバ１１０によって「作業中」（又は「修正中」）に切り替えられる。なお、図６ではチケット６０１の属性として種類属性２０１と担当者属性２０４とステータス属性２０５のみ記載しているが、図２で示したその他の属性も含まれている。

図６で示すユースケースでは、不具合の修正箇所が広範囲にわたる場合であり、担当者Ａの担当する範囲でも複数回に分けて修正を実施する場合である。そのため、修正したソースコードのコミットも複数回（６０２〜６０４）に分かれている。

担当者Ａは、開発クライアント３００を用いて、まず初めの修正を行って修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０２）。自動実行処理サーバ１２０は、該コミット６０２がコミット（コミット完了通知の受信、以下同様）されたことを契機に、図３から図５で示した処理を実施する。以下では、図６に記載のユースケースに係る処理部分のみ説明する。

コミット６０２のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、ステップＳ５０１の判定で、ＮＯとなる。

ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ａの未完了の担当チケット数と、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、ＮＯの判定となる。

次に、自動実行処理サーバ１２０は、ステップＳ５０３の判定でステータス属性２０５が「作業中」のため、ステップＳ５０４に移行し、効率実行の設定となる。この後の処理により、コミット６０２では、自動実行処理が効率的な設定で実行されることになる。

図３におけるステップＳ３０９では、開発責任者へのメール通知は行われない。次に、図６において、担当者Ａは開発クライアント３００で、次の修正を行い修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０３）。該コミット６０３がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施するが、前記コミット６０２と同様の処理になる。

次に、担当者Ａは開発クライアント３００を使用して、担当している部分としては最後の修正を行い修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０４）。

該コミット６０４がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施するが、前記コミット６０２と同様のフローになる。担当者Ａとしては最後の修正が終わったため、開発クライアント３００からチケット６０１の担当者を担当者Ｂに設定する（チケット６０１ａ）。

担当者Ｂは、チケット６０１ａの記載内容を元に原因究明を行い、開発クライアント３００で不具合の修正を行う。図６で示すユースケースでは、不具合の修正箇所が広範囲にわたる場合であり、担当者Ｂの担当する範囲でも複数回に分けて修正を実施する場合である。

そのため、修正したソースコードのコミットも担当者Ａと同様に複数回に分かれている。担当者Ｂは、まず初めの修正を行い開発クライアント３００で修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０５）。

該コミット６０５がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図６に記載のユースケースに係る処理部分のみ説明する。

コミット６０５のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、ステップＳ５０１の判定で、ＮＯとなる。

ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ｂの未完了の担当チケット数、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、自動実行処理サーバ１２０の判定はＮＯとなる。

ステップＳ５０３の判定でステータス属性が「作業中」のため、自動実行処理サーバ１２０はステップＳ５０４に移行し、効率実行の設定となる。この後の処理により、コミット６０２では、自動実行処理が効率的な設定で実行することになる。図３におけるステップＳ３０９では、開発責任者へのメール通知は行われない。

次に、担当者Ｂは次の修正を行い、開発クライアント３００で修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０６）。該コミット６０６がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施するが、前記コミット６０５と同様のフローになる。

次に、担当者Ｂは開発クライアント３００で最後の修正を行う。この際、コミットする前に、担当者Ｂは開発クライアント３００でチケットのステータスを「作業完」に変更する（チケット６０１ｂ）。

担当者Ｂは開発クライアント３００を用いてチケット６０１ｂに対して、修正したソースコードをバージョン管理サーバ１００にコミットする（コミット６０７）。該コミット６０７がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図６に記載のユースケースに係る処理部分のみ説明する。

コミット６０５のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、自動実行処理サーバ１２０は、ステップＳ５０１の判定をＮＯとする。ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ｂの未完了の担当チケット数、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、自動実行処理サーバ１２０の判定はＮＯとなる。

ステップＳ５０３の判定でステータス属性が「作業完」のため、自動実行処理サーバ１２０は、ステップＳ５０５に移行し、重点実行の設定となる。この後の処理により、コミット６０７では、自動実行処理が重点的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール等の通知が行われる。

これにより、作業中であるコミットでは、チケットの属性情報を基に効率的な自動実行が行われ、作業完であるコミットでは、最終的な作業として、重点的な自動実行が行われることとなり、全体として効率的な自動実行処理を行うことができる。

上記により、自動実行処理サーバ１２０では、チケットの属性によって、自動実行処理の内容を自動的に変更することが可能となり、継続的インテグレーションにおける自動実行処理を効率的に実施することができる。

なお、上記実施例１では、バージョン管理サーバ１００と、チケット管理サーバ１１０が独立した構成を示したが、これに限定されるものではなく、バージョン管理サーバ１００とチケット管理サーバ１１０が一つの計算機で構成されてもよい。

実施例２は、前記実施例１で示したプログラム開発支援システム及びプログラム開発支援方法において、１つの機能に対して、複数のサブ機能に分けて、複数の担当者でソースコードを作成していく場合の１実施例である。

なお、実施例１で示したブロック図、チケットの説明や、フローチャートは、図１及び図２から図５で示したものと同じであるので、それぞれの説明は省略する。以下、図７を用いて、本実施例におけるユースケースについて説明する。図７は、実施例２のユースケースの一例を説明する図である。

図７に示すユースケースでは、親チケット７００が１つの機能を表しており、親チケット７００の複数の子チケット７１０、７２０、７３０がそれぞれサブ機能Ａ、サブ機能Ｂ，サブ機能Ｃを作成するためのチケットとなっている。そして、子チケット７１０、子チケット７２０、子チケット７３０のそれぞれについて担当者Ａ、担当者Ｂ、担当者Ｃが割り当てられている場合である。

なお、親チケット７００か子チケット７１０、７２０、７３０であるかは親チケット属性２０８により判定される。また、本実施例では、親チケットのステータスが「作業完」になるまでは、全ての子チケットは「作業中」のままであるとする。

ここで、前記実施例１と同様に、担当者Ａ、担当者Ｂ、担当者Ｃは、担当しているチケットで未完了のチケット数は少なく、過去に担当した不具合チケット数も少なく、コミット件数も少ない担当者である場合である。

親チケット７００及び子チケット７１０、子チケット７２０、子チケット７３０がそれぞれチケット管理サーバ１１０に入力される。その際、子チケット７１０の担当者属性２０４に担当者Ａが設定され、子チケット７２０の担当者属性２０４に担当者Ｂが設定され、子チケット７３０の担当者属性２０４に担当者Ｃが設定される。

担当者Ａは、チケット７１０の記載内容を元にサブ機能Ａのプログラム作成を行う。図７で示すユースケースでは、サブ機能の作成が広範囲にわたる場合であり、担当者Ａの担当する範囲でも複数回に分けてプログラム作成を実施する場合である。

そのため、作成したソースコードのコミットも複数回に分かれている。担当者Ａはまず初めのソースコードの作成を開発クライアント３００で行って作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７１１）。

該コミット７１１がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７１１のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、自動実行処理サーバ１２０は、ステップＳ５０１の判定をＮＯとする。

ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ａの未完了の担当チケット数、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、自動実行処理サーバ１２０の判定はＮＯとなる。

ステップＳ５０３の判定でステータス属性が「作業中」のため、自動実行処理サーバ１２０は、ステップＳ５０４に移行し、効率実行の設定となる。この後の処理により、コミット７１１では、自動実行処理が効率的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知は行われない。

次に、担当者Ａは次の機能作成を行って、開発クライアント３００で作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７１２）。該コミット７１２がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施するが、前記コミット７１１と同様の処理になる。本実施例では、コミット７１２でサブ機能Ａの作成は完了したものとする。

次に、担当者Ａはサブ機能Ａが作成できたため、開発クライアント３００を用いて親チケット７００に対して、作成した全ソースコードをバージョン管理サーバ１００にコミットする（コミット７１３）。

該コミット７１３がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７１３のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットとなるため、自動実行処理サーバ１２０は、ステップＳ５０１の判定をＹＥＳとして、ステップＳ５０５に移行し、重点実行の設定となる。この後の処理により、コミット７１３では、自動実行処理が重点的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知が行われる。

担当者Ｂは、チケット７２０の記載内容を元にサブ機能Ｂのプログラム作成を行う。図７で示すユースケースでは、サブ機能の作成が広範囲にわたる場合であり、担当者Ｂの担当する範囲でも複数回に分けてプログラム作成を実施する場合である。そのため、作成したソースコードのコミットも複数回に分かれている。

担当者Ｂはまず初めのソースコード作成を行い、開発クライアント３００で作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７２１）。該コミット７２１がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７２１のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、自動実行処理サーバ１２０は、ステップＳ５０１の判定をＮＯとする。ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ｂの未完了の担当チケット数、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、自動実行処理サーバ１２０の判定はＮＯとなる。

ステップＳ５０３の判定でステータス属性が「作業中」のため、自動実行処理サーバ１２０は、ステップＳ５０４に移行し、効率実行の設定となる。この後の処理により、コミット７２１では、自動実行処理が効率的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知は行われない。

次に、担当者Ｂは次の機能作成を行い、開発クライアント３００で作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７２２）。該コミット７２２がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施するが、前記コミット７１１と同様の処理になる。本実施例では、コミット７２２でサブ機能Ｂの作成は完了したものとする。

次に、担当者Ｂはサブ機能Ｂが作成できたため、開発クライアント３００を用いて親チケット７００に対して、作成した全ソースコードをバージョン管理サーバ１００にコミットする（コミット７２３）。

該コミット７２３がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７２３のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットとなるため、自動実行処理サーバ１２０はステップＳ５０１の判定をＹＥＳとして、ステップＳ５０５に移行し、重点実行の設定となる。この後の処理により、コミット７２３では、自動実行処理が重点的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知が行われる。

担当者Ｃは、チケット７３０の記載内容を元にサブ機能Ｃのプログラム作成を行う。図７で示すユースケースでは、サブ機能の作成が広範囲にわたる場合であり、担当者Ｃの担当する範囲でも複数回に分けてプログラム作成を実施する場合である。そのため、作成したソースコードのコミットも複数回に分かれている。

担当者Ｃはまず初めのソースコード作成を行い、開発クライアント３００で作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７３１）。該コミット７３１がコミットされたことを契機に、自動実行処理サーバ１２０は、図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７３１のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットではないので、自動実行処理サーバ１２０は、ステップＳ５０１の判定をＮＯとする。

ステップＳ５０２の担当者及び履歴情報の判定ステップでは、本ユースケースでは担当者Ｂの未完了の担当チケット数、過去の担当不具合チケット数及びコミット件数は少なく、閾値Ｔｈｃ以内となるため、自動実行処理サーバ１２０の判定はＮＯとなる。

ステップＳ５０３の判定でステータス属性が「作業中」のため、自動実行処理サーバ１２０はステップＳ５０４に移行し、効率実行の設定となる。この後の処理により、コミット７３１では、自動実行処理が効率的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知は行われない。

次に、担当者Ｃは次の機能作成を行い、開発クライアント３００で作成したソースコードをバージョン管理サーバ１００にコミットする（コミット７３２）。該コミット７３２がコミットされたことを契機に、自動実行処理サーバ１２０は図３から図５で示した処理を実施するが、前記コミット７３１と同様の処理になる。本実施例では、コミット７３２でサブ機能Ｃの作成は完了したものとする。

次に、担当者Ｃはサブ機能Ｃが作成できたため、開発クライアント３００を用いて親チケット７００に対して、作成した全ソースコードをバージョン管理サーバ１００にコミットする（コミット７３３）。該コミット７３３がコミットされたことを契機に、自動実行処理サーバ１２０は図３から図５で示した処理を実施する。以下では図７に記載のユースケースに係る処理部分のみ説明する。

コミット７３３のコミットを契機にした処理では、自動実行設定（ステップＳ３０５）である図５の処理において、親コミットへのコミットとなるため、自動実行処理サーバ１２０はステップＳ５０１の判定をＹＥＳとして、ステップＳ５０５に移行し、重点実行の設定となる。この後の処理により、コミット７２３では、自動実行処理が重点的な設定で実行されることになる。図３におけるステップＳ３０９では、開発責任者へのメール通知が行われる。

これにより、サブ機能作成のコミットでは、チケットの属性情報を基に効率的な自動実行が行われ、サブ機能を統合する親チケットへのコミットでは、最終的な作業として、重点的な自動実行が行われることとなり、全体として効率的な自動実行処理を行うことができる。

なお、図７に記載のユースケースに対して、本実施例のようにチケット属性に基づいてではなく、バージョン管理サーバ１００におけるブランチ機能を用いて、作業中ブランチと作業完ブランチを設けて、ブランチ毎に自動実行処理を変えることも可能である。しかし、担当者の数だけブランチが必要になり、大規模なプログラム開発では担当者も多数になるため、多数のブランチが必要になりブランチの管理が難しくなる。一方、本実施例のようにチケット属性を用いれば、１つのブランチでも実施できるため、ブランチの管理は容易となる。

上記により、自動実行処理サーバ１２０ではチケットの属性によって、自動実行処理の内容を自動的に変更することが可能となり、継続的インテグレーションにおける自動実行処理を効率的に実施することができる。

＜結び＞
以上のように、上記実施例のプログラム開発支援システムは、以下のような構成とすることができる。

（１）プロセッサ（１１）とメモリ（１２）と通信インターフェース（１３）を有する自動実行処理サーバ（１２０）を有するプログラム開発支援システムであって、前記自動実行処理サーバ（１２０）は、ソースコードが登録されたことを示すコミット完了通知を受け付けると、前記ソースコードの情報と前記ソースコードに対応するチケットの情報を含むコミット情報を取得するコミット情報取得部（１２１）と、前記コミット情報から前記コミット完了通知に対応するチケット識別子を抽出する連携部（１２２）と、前記抽出したチケット識別子に基づいて前記チケットの属性情報を取得する属性情報取得部（１２３）と、自動実行処理を行う前記ソースコードに対応する実行対象情報を所定の順序で格納する自動実行キュー（１２７）と、前記取得したコミット情報からソースコードを指定する情報を実行対象情報として生成して前記自動実行キュー（１２７）へ投入し、前記取得したチケットの属性情報に基づいて前記自動実行キュー（１２７）の実行対象情報の順序を変更する自動実行処理変更部（１２４）と、前記自動実行処理の対象となるソースコード及びテストケースを取得する対象成果物取得部（１２５）と、前記自動実行処理変更部（１２４）で変更された実行対象情報の順序に基づいて前記対象成果物取得部（１２５）で取得した前記ソースコード及びテストケースを用いて自動実行処理を行う自動実行処理部（１２６）と、前記自動実行処理部（１２６）で実行した結果を通知する通知部（１２８）と、を有することを特徴とするプログラム開発支援システム。

上記構成により、自動実行処理サーバ１２０は、チケットの属性情報によって、自動実行処理の内容を自動的に変更することが可能となり、継続的インテグレーションにおける自動実行処理を効率的に実施することができる。

（２）上記（１）に記載のプログラム開発支援システムであって、前記ソースコード又は前記ソースコードに対応するテストケースをバージョン単位で管理するバージョン管理サーバ（１００）と、プログラムの開発に係る作業又は不具合に係る内容をチケットとして管理するチケット管理サーバ（１１０）と、前記自動実行処理サーバ（１２０）と、前記バージョン管理サーバ（１００）と、前記チケット管理サーバ（１１０）とを接続するネットワーク（８０）を、更に有し、前記コミット情報取得部（１２１）は、前記バージョン管理サーバ（１００）からコミット完了通知を受け付けて、当該コミット完了通知に対応する前記コミット情報を前記バージョン管理サーバ（１００）から取得し、前記属性情報取得部（１２３）は、前記抽出したチケット識別子に基づく前記チケットの属性情報を前記チケット管理サーバ（１１０）から取得することを特徴とするプログラム開発支援システム。

上記構成により、ソースコードとテストケースのバージョンをバージョン管理サーバ１００で管理し、プログラムの開発に係る作業又は不具合に係る内容をチケットとしてチケット管理サーバ１１０で管理することで、処理分散して自動実行処理サーバ１２０と連携処理を行いことができる。

（３）上記（１）に記載のプログラム開発支援システムであって、前記属性情報取得部（１２３）は、前記チケットの属性情報に含まれる、優先度属性（２０６）、期日属性（２０７）又はクリティカルパス属性（２１０）の少なくとも一つを取得し、前記取得した属性情報に基づいて前記自動実行キュー（１２７）の前記実行対象情報の順序を変更することを特徴とするプログラム開発支援システム。

上記構成により、自動実行処理サーバ１２０は、優先度属性２０６、期日属性２０７又はクリティカルパス属性２１０の少なくとも一つに基づいて自動実行キュー１２７の実行対象情報の順序を変更することができる。

（４）上記（１）に記載のプログラム開発支援システムであって、前記自動実行処理部（１２６）は、前記チケットの属性情報に含まれる、前記親チケット属性（２０６）、担当者属性（２０４）、履歴属性（２１１）又はステータス属性（２０６）の少なくとも一つの属性情報を取得して、前記取得した属性情報に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援システム。

上記構成により、自動実行処理サーバ１２０は、親チケット属性２０８と、担当者属性２０４と、履歴属性２１１に基づいて自動実行処理の内容を決定することが可能となる。

（５）上記（３）に記載のプログラム開発支援システムであって、前記自動実行処理部（１２６）は、前記属性情報取得部（１２３）が取得した担当者属性（２０４）の情報を用いて、当該担当者の、未完了の担当チケット数、過去の担当不具合チケット数又はコミット件数の少なくとも一つの数値を取得して、前記取得した数値に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援システム。

上記構成により、自動実行処理サーバ１２０では、チケットの属性によって、自動実行処理の内容を自動的に変更することが可能となり、継続的インテグレーションにおける自動実行処理を効率的に実施することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

＜補足＞
特許請求の範囲に記載した以外の本発明の観点の代表的なものとして、次のものがあげられる。

＜１１＞
請求項３に記載のプログラム開発支援システムであって、
前記属性情報取得部で取得した履歴属性の情報を用いて、担当者が変更されてからの時間情報を取得し、取得した時間情報を基に、自動実行処理を設定することを特徴とするプログラム開発システム。

＜１２＞
請求項１に記載のプログラム開発支援システムであって、
前記自動実行処理変更部で設定する自動実行処理の内容として、ビルドやテスト実行の対象となるソースコード、レビュー実施の要否、同件不具合の修正確認の要否又は開発責任者への通知の要否の少なくとも一つの設定を行うことを特徴とするプログラム開発システム。

＜１３＞
請求項８に記載のプログラム開発支援方法であって、
前記属性情報取得手順で取得した履歴属性の情報を用いて、担当者が変更されてからの時間情報を取得し、取得した時間情報を基に、自動実行処理を設定することを特徴とするプログラム開発方法。

＜１４＞
請求項６に記載のプログラム開発支援方法であって、
前記自動実行処理変更手順で設定する自動実行処理の内容として、ビルドやテスト実行の対象となるソースコード、レビュー実施の要否、同件不具合の修正確認の要否又は開発責任者への通知の要否の少なくとも一つの設定を行うことを特徴とするプログラム開発方法。

１００ バージョン管理システム
１１０ チケット管理システム
１２０ 自動実行処理システム
１２１ コミット情報取得部
１２２ 連携部
１２３ 属性情報取得部
１２４ 自動実行処理変更部
１２５ 対象成果物取得部
１２６ 自動実行処理部
１２７ 自動実行キュー
１２８ 通知部

Claims (10)

1. プロセッサとメモリと通信インターフェースを有する自動実行処理サーバを有するプログラム開発支援システムであって、
   前記自動実行処理サーバは、
   ソースコードが登録されたことを示すコミット完了通知を受け付けると、前記ソースコードの情報と前記ソースコードに対応するチケットの情報を含むコミット情報を取得するコミット情報取得部と、
   前記コミット情報から前記コミット完了通知に対応するチケット識別子を抽出する連携部と、
   前記抽出したチケット識別子に基づいて前記チケットの属性情報を取得する属性情報取得部と、
   自動実行処理を行う前記ソースコードに対応する実行対象情報を所定の順序で格納する自動実行キューと、
   前記取得したコミット情報からソースコードを指定する情報を実行対象情報として生成して前記自動実行キューへ投入し、前記取得したチケットの属性情報に基づいて前記自動実行キューの実行対象情報の順序を変更する自動実行処理変更部と、
   前記自動実行処理の対象となるソースコード及びテストケースを取得する対象成果物取得部と、
   前記自動実行処理変更部で変更された実行対象情報の順序に基づいて前記対象成果物取得部で取得した前記ソースコード及びテストケースを用いて自動実行処理を行う自動実行処理部と、
   前記自動実行処理部で実行した結果を通知する通知部と、
   を有することを特徴とするプログラム開発支援システム。
2. 請求項１に記載のプログラム開発支援システムであって、
   前記ソースコード又は前記ソースコードに対応するテストケースをバージョン単位で管理するバージョン管理サーバと、
   プログラムの開発に係る作業又は不具合に係る内容をチケットとして管理するチケット管理サーバと、
   前記自動実行処理サーバと、前記バージョン管理サーバと、前記チケット管理サーバとを接続するネットワークを、更に有し、
   前記コミット情報取得部は、
   前記バージョン管理サーバからコミット完了通知を受け付けて、当該コミット完了通知に対応する前記コミット情報を前記バージョン管理サーバから取得し、
   前記属性情報取得部は、
   前記抽出したチケット識別子に基づく前記チケットの属性情報を前記チケット管理サーバから取得することを特徴とするプログラム開発支援システム。
3. 請求項１に記載のプログラム開発支援システムであって、
   前記属性情報取得部は、
   前記チケットの属性情報に含まれる、優先度属性、期日属性又はクリティカルパス属性の少なくとも一つを取得し、前記取得した属性情報に基づいて前記自動実行キューの前記実行対象情報の順序を変更することを特徴とするプログラム開発支援システム。
4. 請求項１に記載のプログラム開発支援システムであって、
   前記自動実行処理部は、
   前記チケットの属性情報に含まれる、親チケット属性、担当者属性、履歴属性又はステータス属性の少なくとも一つの属性情報を取得して、前記取得した属性情報に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援システム。
5. 請求項３に記載のプログラム開発支援システムであって、
   前記自動実行処理部は、
   前記属性情報取得部が取得した担当者属性の情報を用いて、当該担当者属性の、未完了の担当チケット数、過去の担当不具合チケット数又はコミット件数の少なくとも一つの数値を取得して、前記取得した数値に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援システム。
6. プロセッサとメモリと通信インターフェースを有する自動実行処理サーバでプログラムの開発を支援するプログラム開発支援方法であって、
   前記自動実行処理サーバが、ソースコードが登録されたことを示すコミット完了通知を受け付けると、前記ソースコードの情報と前記ソースコードに対応するチケットの情報を含むコミット情報を取得するコミット情報取得手順と、
   前記自動実行処理サーバが、前記コミット情報から前記コミット完了通知に対応するチケット識別子を抽出する連携手順と、
   前記自動実行処理サーバが、前記抽出したチケット識別子に基づいて前記チケットの属性情報を取得する属性情報取得手順と、
   前記自動実行処理サーバが、自動実行処理を行う前記ソースコードに対応する実行対象情報を所定の順序で自動実行キューに格納するキューイング手順と、
   前記自動実行処理サーバが、前記取得したコミット情報からソースコードを指定する情報を実行対象情報として生成して前記自動実行キューへ投入し、前記取得したチケットの属性情報に基づいて前記自動実行キューの実行対象情報の順序を変更する自動実行処理変更手順と、
   前記自動実行処理サーバが、前記自動実行処理の対象となるソースコード及びテストケースを取得する対象成果物取得手順と、
   前記自動実行処理サーバが、前記自動実行処理変更手順で変更された実行対象情報の順序に基づいて前記対象成果物取得手順で取得した前記ソースコード及びテストケースを用いて自動実行処理を行う自動実行処理手順と、
   前記自動実行処理サーバが、前記自動実行処理手順で実行した結果を通知する通知手順と、
   を含むことを特徴とするプログラム開発支援方法。
7. 請求項６に記載のプログラム開発支援方法であって、
   前記コミット情報取得手順は、
   前記ソースコード又は前記ソースコードに対応するテストケースをバージョン単位で管理するバージョン管理サーバからネットワークを介してコミット完了通知を受け付けて、当該コミット完了通知に対応する前記コミット情報を前記バージョン管理サーバから取得し、
   前記属性情報取得手順は、
   プログラムの開発に係る作業又は不具合に係る内容をチケットとして管理するチケット管理サーバから前記ネットワークを介して、前記抽出したチケット識別子に基づく前記チケットの属性情報を取得することを特徴とするプログラム開発支援方法。
8. 請求項６に記載のプログラム開発支援方法であって、
   前記属性情報取得手順は、
   前記チケットの属性情報に含まれる、優先度属性、期日属性又はクリティカルパス属性の少なくとも一つを取得し、前記取得した属性情報に基づいて前記自動実行キューの前記実行対象情報の順序を変更することを特徴とするプログラム開発支援方法。
9. 請求項６に記載のプログラム開発支援方法であって、
   前記自動実行処理手順は、
   前記チケットの属性情報に含まれる、親チケット属性、担当者属性、履歴属性又はステータス属性の少なくとも一つの属性情報を取得して、前記取得した属性情報に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援方法。
10. 請求項８に記載のプログラム開発支援方法であって、
    前記自動実行処理手順は、
    前記属性情報取得手順で取得した担当者属性の情報を用いて、当該担当者属性の、未完了の担当チケット数、過去の担当不具合チケット数又はコミット件数の少なくとも一つの数値を取得して、前記取得した数値に基づいて自動実行処理の内容を設定することを特徴とするプログラム開発支援方法。

Images