JP5973091B2 - 開発支援システム - Google Patents

Description

本発明は、プログラム開発の技術に関し、特に、ソーシャルコーディングシステムを利用したプログラム開発を支援する開発支援システムに適用して有効な技術に関するものである。

近年では、プログラム開発において、ソースコードや設計資料、仕様書などの開発成果物をリポジトリに登録してバージョン管理や変更履歴管理等を行ういわゆるリポジトリ管理システムに加え、開発案件における課題（Ｉｓｓｕｅ）管理の機能や、成果物のレビュー、リポジトリへの反映などの開発プロセスの管理機能などを有するいわゆるソーシャルコーディングシステムが利用されつつある。ソーシャルコーディングシステムでは、例えば、リポジトリにおいて開発・修正用のブランチを作成する機能や、開発成果物を含むブランチをリポジトリにマージするためのＰｕｌｌリクエスト機能などを有している。ソーシャルコーディングシステムとしては、例えば、ＧｉｔＨｕｂ（非特許文献１）などがある。

また、これに関連する技術として、例えば、特開２０１３−１９１００３号公報（特許文献１）には、リポジトリ管理システムと、懸案管理システムとを連携させ、懸案登録から自動的にブランチを作成するブランチリポジトリ管理システムが記載されている。

特開２０１３−１９１００３号公報

ＧｉｔＨｕｂホームページ、［平成２６年４月２３日検索］、インターネット＜URL：https://github.com＞

非特許文献１等に記載されたソーシャルコーディングシステムは、例えば、課題管理機能を用いて、開発成果物と課題とを関連付けて管理するとともに、設計者等が不具合や新規機能について議論を行った後、開発者が実際にソースコード等を修正し、その修正差分を公開し、レビュアーによるソースコードレビューを実施し、問題がなければリポジトリにマージ（統合）する、といった流れでプログラム等のソフトウェアの開発を支援するツールである。

しかしながら、例えば、ソースコードの修正差分を管理するために、ソースコードの修正を実施する前にリポジトリ上でブランチを手動で作成する必要がある。また、ソースコードレビューを実施する際に、どの課題（Ｉｓｓｕｅ）で議論された内容に係る修正なのかをレビュアーが把握可能とするために、例えば、ソースコードの修正を登録（コミット）する際のコメント（コミットコメント）に課題（Ｉｓｓｕｅ）を識別する番号等を手動で付与して関連付けする必要がある。また、修正対象のソースコードについて、レビューが完了した後にどのブランチにマージすべきかの情報を予め手動で指定しておくことも必要となる。

このように、課題（Ｉｓｓｕｅ）、ブランチ、コミット等の関連付けを手動で行う必要があることから、ユーザの負担が大きいとともに、例えば、関連付けを失念してしまったり、ミスにより間違って関連付けされてしまったりする場合があるという課題があった。

また、特許文献１に記載されたブランチリポジトリ管理システムは、ソーシャルコーディングシステムを想定したシステムではなく、単に懸案とブランチとの関連付けとしてブランチの生成を自動的に行うものであり、ソーシャルコーディングシステムにおける上記の課題を解決できるものではない。また、特許文献１に記載されたブランチリポジトリ管理システムを、ソーシャルコーディングシステムを用いたプログラム開発に適用した場合、細かい単位で課題（Ｉｓｓｕｅ）を登録することが推奨されることから、多くの課題（Ｉｓｓｕｅ）が登録され、その結果多くのブランチが作成されてしまい、ブランチの選択や表示などのブランチ操作の操作性が大きく低下するという課題があった。

そこで本発明の目的は、ソーシャルコーディングシステムにおいて、課題（Ｉｓｓｕｅ）に対応するブランチの生成数を抑えつつ、課題（Ｉｓｓｕｅ）、ブランチ、コミット等の関連付けを自動的に行う開発支援システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による開発支援システムは、開発成果物およびその変更履歴をリポジトリに保持するリポジトリ管理システムと、前記開発成果物と課題とを関連付けて管理するソーシャルコーディングシステムと、を有する開発支援システムであって、前記ソーシャルコーディングシステムは、前記課題の情報を管理する課題管理部と、前記リポジトリにおいてブランチの生成を行うブランチ処理部と、を有し、前記ブランチ処理部は、指定された前記課題の情報に基づいて、分岐元となる第１のブランチを特定し、前記第１のブランチから分岐させて、前記課題に対応する第２のブランチを生成するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、ソーシャルコーディングシステムにおいて、課題（Ｉｓｓｕｅ）に対応するブランチの生成数を抑えつつ、課題（Ｉｓｓｕｅ）、ブランチ、コミット等の関連付けを自動的に行うことで、ソースコード修正作業、ひいてはソフトウェア開発作業における作業効率を向上させることが可能となる。

本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。 本発明の一実施の形態におけるリポジトリ上のブランチの分岐による構成例について概要を示した図である。 本発明の一実施の形態におけるブランチの種類および命名規則をまとめた表である。 （ａ）、（ｂ）は、本発明の一実施の形態における課題管理情報のデータ構成および具体的なデータの例について概要を示した図である。 本発明の一実施の形態における開発機能情報のデータ構成の例について概要を示した図である。 本発明の一実施の形態における不具合情報のデータ構成の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるラベル情報のデータ構成および具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるブランチの自動生成処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるコミットコメントの自動追加処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるリポジトリ表示画面の例について概要を示した図である。 本発明の一実施の形態におけるブランチの自動指定処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるＰｕｌｌリクエスト画面の例について概要を示した図である。 本発明の一実施の形態におけるＰｕｌｌリクエスト画面の例について概要を示した図である。 ソーシャルコーディングシステムを利用した従来の開発支援システムの構成例について概要を示した図である。 ソーシャルコーディングシステムを利用した従来の開発支援システムにおける開発時の作業フローの例について概要を示した図である。 従来の開発支援システムにおける開発で取り扱われるデータの関連の例を表したクラス図である。 従来の開発支援システムにおける課題、ブランチ、コミット、およびＰｕｌｌリクエストの間の具体的な対応関係について例を示した図である。 従来の開発支援システムにおけるリポジトリ管理システムとソーシャルコーディングシステムにおける処理イメージの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
図１４は、ソーシャルコーディングシステムを利用した従来の開発支援システムの構成例について概要を示した図である。開発支援システム１は、ソーシャルコーディングシステム１００およびリポジトリ管理システム２００の各情報処理システムと、複数のユーザの情報処理端末であるユーザ端末４００とがネットワーク５００を介して接続される構成を有している。さらに課題の管理を個別に行う課題管理システム３００を有していてもよい。

リポジトリ管理システム２００は、例えば、リポジトリデータベース（ＤＢ）２０１に保持されたリポジトリを管理するリポジトリ管理部２１０、リポジトリ上で作成されているブランチを管理するブランチ管理部２２０、およびリポジトリにおいて開発のために作成し分岐させたブランチを分岐元のブランチにマージ（統合）するマージ処理部２３０などを有する。これらの各部は、例えば、ソフトウェアプログラムによって実装される。

一方、ソーシャルコーディングシステム１００は、例えば、開発者等のユーザに対して認証等の処理を行うユーザ認証部１１０、課題ＤＢ１０１に保持された開発案件における課題（Ｉｓｓｕｅ、以下では単に「課題」と記載する場合がある）を管理する課題管理部１２０、およびリポジトリ管理システム２００を介してリポジトリ上でのブランチに対する各種の処理を行うブランチ処理部１３０などを有する。これらの各部も、例えば、ソフトウェアプログラムによって実装される。ソーシャルコーディングシステム１００としては、例えば、上述したＧｉｔＨｕｂやＧｉｔＬａｂなどが知られている。なお、課題管理部１２０は、課題管理システム３００の課題管理部３１０によって代替してもよいし、並列的に課題ＤＢ１０１を管理する構成であってもよい。

各開発者等が使用するユーザ端末４００は、それぞれ、ソーシャルコーディングシステム１００のクライアントアプリケーションであるソーシャルコーディングクライアント４１０を有する。ソーシャルコーディングクライアント４１０は、各開発者が課題に係る開発を行うため、開発用に作成されたブランチを含むリポジトリの一部もしくは全部を、必要に応じてリポジトリＤＢ２０１からローカルリポジトリＤＢ４０１に取り込むことができ、リポジトリに係る処理を行うためのリポジトリ処理部４１１や、開発対象の課題の管理を行う課題処理部４１２などの各部を有する。なお、ソーシャルコーディングクライアント４１０は、全部もしくは一部が専用のクライアントアプリケーションプログラムとして実装されていてもよいし、ソーシャルコーディングシステム１００と連携してＷｅｂブラウザ上で稼働するＷｅｂアプリケーションとして実装されていてもよい。

図１５は、ソーシャルコーディングシステムを利用した従来の開発支援システムにおける開発時の作業フローの例について概要を示した図である。まず、新規の機能開発もしくは不具合（バグ）対策についての検討が設計者や開発リーダー等により行われる（Ｓ１）。このとき、検討結果として作成された課題を新たに課題ＤＢ１０１に登録する。具体的には、当該課題を表象する情報として、例えば、機能開発の場合は変更票、不具合対策の場合は不具合票をシステム上発行する。

次に、登録された課題（発行された変更票もしくは不具合票）に基づいて、対応を開始する（Ｓ２）。具体的には、リポジトリＤＢ２０１上で、当該課題に係る開発を行うための管理用のブランチを作成する。なお、ここまでの処理は、ソーシャルコーディングシステム１００およびリポジトリ管理システム２００上で、設計者や開発リーダー、プロジェクトマネージャー等（以下ではこれらを総称して「リーダー」と記載する場合がある）により行われるのが通常である。

次に、開発の準備として、開発者が上記の管理用ブランチをローカルリポジトリＤＢ４０１に取り込んで、開発者用のブランチを作成する（Ｓ３）。その後、開発者は、作成された開発者ブランチに対応する開発を行う（Ｓ４）。具体的には、ソースコードを作成・修正し、手動でのテストを行い、テストが完了したソースコードを開発者ブランチに対して登録（コミット）する。さらに、開発した部分について、管理用ブランチへの取り込み要求（Ｐｕｌｌリクエスト）を行う（Ｓ５）。具体的には、リポジトリＤＢ２０１からローカルリポジトリＤＢ４０１に対して最新の管理用ブランチを取り込み、これを開発者ブランチに反映させた上で、リポジトリ管理システム２００に対して管理用ブランチへの取り込み要求（Ｐｕｌｌリクエスト）を行う。

Ｐｕｌｌリクエストがされると、リーダーは、ソーシャルコーディングシステム１００上で開発者ブランチにおける開発内容をレビューし、必要に応じて自動テスト等を行い、問題がなければこれを管理用ブランチにマージすることで取り込む（Ｓ６）。その後、さらに課題としてのレビューを行い、必要に応じて自動テスト等を行い、問題がなければこれをメインブランチにマージすることで取り込むとともに本番環境等にリリースする（Ｓ７）。

ここで、例えば、ステップＳ２やＳ３においては、機能開発や不具合対応の案件毎に管理用ブランチを作成し、さらに複数の開発者での分散開発を可能とするよう、開発者毎に開発者ブランチを作成することになるが、従来の開発支援システムにおける開発では、これらのブランチは手動で作成する必要があり、煩雑で作業負荷が高い状況となっている。

また、ステップＳ４でソースコードの開発が行われてテストが完了すると、開発用ブランチに対してコミットが行われるが、各コミットは、ステップＳ１で作成された課題に対応することから、コミット毎に対応する課題との関連付けを行うことが必要となるが、これも現状では手動で行う必要があり、煩雑で作業負荷が高い状況となっている。

さらに、ステップＳ５で、ステップＳ４で行ったコミットに係る開発部分を対応する管理用ブランチにマージするために、Ｐｕｌｌリクエストを作成するが、当該処理はブランチ間でのマージが前提となる。従って、Ｐｕｌｌリクエストの際にマージ元となる開発者ブランチとマージ先となる管理用ブランチを指定する必要があるが、これも現状では手動で行う必要がある。

図１６〜図１８は、上述したような従来の開発支援システムにおける開発での状況をより詳細に説明した図である。図１６は、従来の開発支援システムにおける開発で取り扱われるデータの関連の例を表したクラス図である。図示するように、ソーシャルコーディングシステム１００もしくは課題管理システム３００では、課題が管理される。さらに、ソーシャルコーディングシステム１００では、Ｐｕｌｌリクエストが管理される。また、リポジトリ管理システム２００（ユーザ端末４００上のローカルリポジトリＤＢ４０１を含む）では、ブランチとコミットが管理される。

課題は、上述したように、機能追加項目を管理する変更票と、不具合修正を管理する不具合票とに分けられる。開発作業を開始する際には、リポジトリ管理システム２００のリポジトリ上の管理用ブランチとして、課題に対応する機能開発用ブランチもしくは不具合修正用ブランチを作成する。しかしながら、上述したように、これらのブランチは現状では手動で作成する必要がある。従って、変更票や不具合票と、機能開発用ブランチや不具合修正用ブランチとの間の関連付け（リンク作成）についても手動で行う必要がある（図中では点線で関連を表している）。なお、特許文献１に記載された技術では、変更票（特許文献１における懸案に相当）に対応する機能開発用ブランチについては自動的に作成することができるが、不具合票に対応する不具合修正用ブランチについては言及されていない。

開発作業時には、上述したように、複数の開発者がそれぞれ独立して並行的に分散開発ができるよう、開発者毎に開発者ブランチ（機能開発用開発者ブランチもしくは不具合修正用開発者ブランチ）を作成することになるが、従来の開発支援システムにおける開発では、これらの開発者ブランチも手動で作成する必要がある。なお、特許文献１に記載された技術では、開発者ブランチに相当するブランチの作成については言及されていない。

開発者ブランチの作成後、ソースコードの作成・修正、テスト等の開発が行われ、完了したものを１つのコミットとして登録するが、上述したように、各コミットは課題に対応する。従って、コミット毎に対応する課題（実際は対応する変更票もしくは不具合票）との関連付けを行うことが必要となるが、これも現状では手動で行う必要がある（図中では点線で関連を示している）。なお、図示するように、コミットは１つの課題に対して複数に分割して登録することができる。

そして、コミットに対応する開発用ブランチを、対応する管理用ブランチ（機能開発用ブランチもしくは不具合修正用ブランチ）にマージ（統合）するために、Ｐｕｌｌリクエストが作成される。実際のブランチのマージ処理は、Ｐｕｌｌリクエストに対するレビュー、承認等を経た後に行われる。上述したように、Ｐｕｌｌリクエストでは、マージ元となる開発者ブランチとマージ先となる管理用ブランチを指定する必要があるが、これも現状では手動で行う必要がある。また、Ｐｕｌｌリクエストは、必ずいずれかの課題（実際は対応する変更票もしくは不具合票）に対応しているが、これらを関連付けてシステム上で管理するには、例えば、Ｐｕｌｌリクエストのコメントに対応する課題の識別情報を手動で記載するなどの作業が必要となる（図中では点線でこれらの関連を示している）。

なお、Ｐｕｌｌリクエストには複数のコミットが関連付けられるが、マージ元の開発用ブランチとマージ先の管理用ブランチが指定されると、マージ先の管理用ブランチにはない、マージ元の開発用ブランチ内のコミット、すなわち、マージ先の管理用ブランチからマージ元の開発用ブランチに分岐して登録された全てのコミットとして特定される。通常、リポジトリ管理システム２００においては、ブランチは必ず１つの親ブランチから派生して作成されている、すなわち、どのブランチも必ず親ブランチのある部分から分岐して作成されているので、上記のようにＰｕｌｌリクエストに対応するコミットを特定することができる。

図１７は、上述したような、課題、管理用ブランチ、開発用ブランチ、コミット、およびＰｕｌｌリクエストの間の具体的な対応関係について例を示した図である。すなわち、機能開発案件においては、変更票と機能開発用ブランチとが１対１で関連付けられ、機能開発用ブランチには開発者毎の機能開発用開発者ブランチが１対多で関連付けられる。また、機能開発用開発者ブランチには、複数のコミット（機能開発修正コミット）が１対多で関連付けられる。そして、複数の機能開発修正コミットは、１つのＰｕｌｌリクエスト（機能開発修正Ｐｕｌｌリクエスト）に多対１で関連付けられ、この機能開発修正Ｐｕｌｌリクエストは変更票に１対１で関連付けられる。

機能開発用ブランチと機能開発用開発者ブランチとの対応は、機能開発修正Ｐｕｌｌリクエストと１対１で関連付けられる。すなわち、各開発者の機能開発用開発者ブランチに係る開発部分は、１つの機能開発修正Ｐｕｌｌリクエストによって機能開発用ブランチにマージされることを示している。なお、上記のような対応関係は、不具合対策案件においても同様であるため、再度の説明は省略する。

図１８は、リポジトリ管理システム２００とソーシャルコーディングシステム１００における処理イメージの例について概要を示した図である。リポジトリ管理システム２００のローカルリポジトリＤＢ２０１には、ブランチの階層構造が保持されている状態を示している。このリポジトリの内容の全部もしくは一部について、開発者毎のユーザ端末４００のローカルリポジトリＤＢ４０１ではクローン（コピー）が作成され、これに基づいて開発が行われる。完了した開発内容が登録されたローカルリポジトリＤＢ４０１上のリポジトリは、リポジトリ管理システム２００のリポジトリＤＢ２０１に対してプッシュ（反映）される。

ソーシャルコーディングシステム１００（もしくは課題管理システム３００）上では、課題（図１８の例では“変更票（Ｃ０００１）”や“不具合票（Ｂ００１１）”など）が作成され、これらの課題と、課題に対応してリポジトリＤＢ２０１上に作成されたブランチとの関連付けが行われる。また、ソーシャルコーディングシステム上では、リポジトリＤＢ２０１に対して開発内容を反映させるためのＰｕｌｌリクエスト（図１８の例では“Ｐｕｌｌリクエスト（＃１）”など）が作成され、Ｐｕｌｌリクエストと課題との間の関連付けが行われる。これらの関連付けは、上述したように、現状では手動で行う必要があり、煩雑で作業負荷が高い。

上述したように、特許文献１に記載された技術では、課題（特許文献１における懸案に相当）管理システム上で新しい課題が登録されると自動的に対応するブランチを作成し、作成されたブランチと課題との関連付けを管理することができるため、上記のような作業負荷をある程度低減させることができる。しかしながら、リポジトリ管理システム２００としてはＳｕｂｖｅｒｓｉｏｎ（登録商標）などの公知のバージョン管理ツールを前提としており、ブランチの階層構造における分岐元は特定のブランチ（例えば“ｔｒｕｎｋ”）に限定され、課題別にブランチを分けることができないという制約がある。

また、課題数が多い場合にブランチ数が膨大となり、管理が困難になるとともに、ユーザインタフェース上において多数のブランチからのブランチの選択・切替が困難になったり、グラフ表示の可視性が悪くなるなどの問題を有する。また、ブランチの作成時の状態でブランチを分岐するため、分岐のタイミングによっては他の修正に係る取り込み作業が無駄に発生する場合がある。

そこで、本実施の一実施の形態である開発支援システムは、ブランチ作成が必要なタイミングでブランチを自動的に作成することでブランチの数をできるだけ抑え、可能な限り最新の状態から開発作業に着手できるようにする。また、課題、ブランチ、コミット、Ｐｕｌｌリクエストの間の関連付けを自動的に行うことで、作業負荷を低減させ、ソフトウェア開発作業における作業効率を向上させる。

具体的には、例えば、課題が作成され、もしくは状態が変化したときに、自動的に当該課題に対応したブランチを作成する。その際、作成された課題の情報に基づいて、分岐元となるブランチを自動的に指定する。これにより、課題の作成等のタイミングでブランチを自動的に作成するとともに、課題とブランチとの関連付けも自動的に行う（例えば、ブランチの命名規則などによる）。

また、ブランチの情報（例えば、命名規則に従ったブランチの名称）に基づいて、当該ブランチに対応する変更票もしくは不具合票の識別情報を判断し、その情報をコミットコメントに付与する。これにより、コミットと課題（変更票もしくは不具合票）との関連付けを自動的に行う。

また、ブランチの情報（例えば、命名規則に従ったブランチの名称）に基づいて、マージ先（分岐元）となるブランチを判断し、その情報に基づいて、Ｐｕｌｌリクエストの作成時に必要となるマージ先およびマージ元のブランチ名を自動的に指定・補完する。これにより、Ｐｕｌｌリクエストとブランチおよび課題との関連付けを自動的に行う。

＜システム構成＞
図１は、本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。本実施の形態の開発支援システム１は、図１４に示した従来の開発支援システム１と同様に、ソーシャルコーディングシステム１００およびリポジトリ管理システム２００の各情報処理システムと、複数のユーザの情報処理端末であるユーザ端末４００がネットワーク５００を介して接続される構成を有している。さらに課題の管理を個別に行う管理システム３００を有していてもよい。ソーシャルコーディングシステム１００（もしくは課題管理システム３００）は、課題ＤＢ１０１を有しており、リポジトリ管理システム２００は、リポジトリＤＢ２０１を有している。

ソーシャルコーディングシステム１００およびリポジトリ管理システム２００は、アプリケーションサーバであり、課題ＤＢ１０１およびリポジトリＤＢ２０１は、ＤＢサーバとして構成される。これらのアプリケーションサーバやＤＢサーバは、いずれも、サーバ機器によって構成されていてもよいし、サーバ機器やクラウドコンピューティングサービス上に構成された仮想サーバの１インスタンスによって構成されていてもよい。また、これらの混在により構成されていてもよい。

また、図中では、これらの各サーバはそれぞれ独立した構成となっているが、全部もしくは一部を１つのサーバ機器等に集約してもよい。また、ソーシャルコーディングシステム１００と課題ＤＢ１０１との間や、リポジトリ管理システム２００とリポジトリＤＢ２０１との間の接続は、専用線に限らず、ネットワーク５００を介して接続されていてもよい。ネットワーク５００は、インターネット、イントラネットのいずれであってもよく、また、物理レイヤーも、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、パケット回線など、特に限定されない。

リポジトリ管理システム２００は、例えば、図１４に示した従来の開発支援システム１と同様に、リポジトリＤＢ２０１に保持されたリポジトリを管理するリポジトリ管理部２１０、リポジトリ上で作成されているブランチを管理するブランチ管理部２２０、およびリポジトリにおいて開発のために作成し分岐させたブランチを分岐元のブランチにマージするマージ処理部２３０などを有する。これらの各部は、例えば、ソフトウェアプログラムによって実装される。

本実施の形態では、リポジトリ管理システム２００として、例えば、オープンソースの分散リポジトリ管理ツールであるＧｉｔを想定しているが、Ｍｅｒｃｕｒｉａｌ（ｈｇ）などの他の分散リポジトリ管理ツールを利用することも可能である。なお、例えば、Ｓｕｂｖｅｒｓｉｏｎ（登録商標）等の集中リポジトリ管理ツールであっても、ユーザ端末４００においてローカルリポジトリＤＢ４０１が不要となるなど構成は変わるものの、原理的には本実施の形態の開発支援システム１に適用することは可能である。ただし、実際のソーシャルコーディングでは複数の開発者により頻繁に開発や修正が行われることからリポジトリの排他処理により他の開発作業が止まってしまう場合が多い。従って、分散リポジトリ管理ツールを利用するのが望ましい。

ソーシャルコーディングシステム１００は、例えば、図１４に示した従来の開発支援システム１と同様に、開発者等のユーザに対して認証等の処理を行うユーザ認証部１１０、課題ＤＢ１０１に保持された開発案件における課題を管理する課題管理部１２０、およびリポジトリ管理システム２００を介してリポジトリ上でのブランチに対する各種の処理を行うブランチ処理部１３０を有する。これらの各部は、例えば、ソフトウェアプログラムによって実装される。課題管理部１２０は、課題管理システム３００の課題管理部３１０によって代替してもよいし、並列的に課題ＤＢ１０１を管理する構成であってもよい。

本実施の形態のソーシャルコーディングシステム１００は、さらに、各ユーザ端末４００からのＰｕｌｌリクエストを受け付けてこれに関する処理を行うＰｕｌｌリクエスト処理部１４０を有する。本実施の形態における課題管理部１２０やブランチ処理部１３０、Ｐｕｌｌリクエスト処理部１４０は、上述したような、課題、ブランチ、コミット、Ｐｕｌｌリクエストの間の関連付けを自動的に行うための機能を有している。これらの機能の詳細については後述する。

ユーザ端末４００は、開発者がそれぞれ使用するＰＣ（Personal Computer）等の情報処理端末であるが、スマートフォンやタブレット端末などの携帯型端末であってもよい。ユーザ端末４００は、図１４に示した従来の開発支援システム１と同様に、ソーシャルコーディングシステム１００のクライアントアプリケーションであるソーシャルコーディングクライアント４１０およびローカルリポジトリＤＢ４０１を有する。ソーシャルコーディングクライアント４１０は、リポジトリに係る処理を行うためのリポジトリ処理部４１１や、開発対象の課題の管理を行う課題処理部４１２などの各部を有する。

本実施の形態のソーシャルコーディングクライアント４１０は、さらに、開発されたソースコード等を開発用ブランチに対してコミット（登録）するための処理を行うコミット処理部４１３、およびリポジトリ管理システム２００上の管理用ブランチへの取り込みを要求するＰｕｌｌリクエストの作成に係る処理を行うＰｕｌｌリクエスト作成部４１４などの各部を有する。本実施の形態におけるソーシャルコーディングクライアント４１０の各部は、ソーシャルコーディングシステム１００と連携して、上述したような、課題、ブランチ、コミット、Ｐｕｌｌリクエストの間の関連付けを自動的に行うための機能を有している。

＜前提となるブランチ運用＞
図２は、本実施の形態におけるリポジトリ上のブランチの分岐による構成例について概要を示した図である。また、図３は、図２に示したブランチの種類および命名規則をまとめた表である。図２では、横方向に時系列（左から右へ時刻ｔが経過）、縦方向にブランチの種別を表している。黒丸印はコミット、すなわち確定したソースコードの修正差分を表している。

図２に示すように、本実施の形態では、最新の開発ブランチを“ｔｒｕｎｋ”としている。これは、最新バージョンの全ての機能が追加されているブランチ（「最新開発ブランチ」と呼ぶ）であり、新規の機能開発（エンハンス開発）におけるメインブランチとなる。図２の例において、機能開発（エンハンス開発）では、“ｔｒｕｎｋ”ブランチから上方向に分岐して“ｆｅａｔｕｒｅ／Ｃ００１／ＤＥＶ”というブランチが作成されている。これは、新規の機能“Ｃ００１”をチームで開発するための管理用のブランチ（総称して「機能開発用ブランチ」と呼ぶ）であり、チーム全体の開発成果物を格納するブランチである。図３に示した命名規則によってブランチ名が付されることにより、ブランチ名からブランチの種別と機能名（図２の例では“Ｃ００１”）を把握することができる。

図２の例では、“ｆｅａｔｕｒｅ／Ｃ００１／ＤＥＶ”ブランチから、さらに分岐して“ｆｅａｔｕｒｅ／Ｃ００１／ｕｓｅｒ２”というブランチが作成されている。これは、機能“Ｃ００１”を開発する開発者“ｕｓｅｒ２”専用のブランチ（総称して「機能開発用開発者ブランチ」と呼ぶ）であり、“ｕｓｅｒ２”個人の作業成果物を格納するブランチである。図３に示した命名規則によってブランチ名が付されることにより、ブランチ名からブランチの種別と機能名（図２の例では“Ｃ００１”）および開発者（図２の例では“ｕｓｅｒ２”）を把握することができる。

一方、図２の例では、“ｔｒｕｎｋ”ブランチから下方向に分岐して“ｓｔａｂｌｅ／ｖ０００１”および“ｓｔａｂｌｅ／ｖ０００２”というブランチが作成されている。これらは、例えば、パッケージ製品など、既に出荷してしまい、それに対する不具合対応等のメンテナンスが必要となるものについて、基準となるバージョンを格納するブランチ（総称して「安定ブランチ」と呼ぶ）であり、不具合修正におけるメインブランチとなる。図３に示した命名規則によってブランチ名が付されることにより、ブランチ名からブランチの種別とバージョン（図２の例では、“ｖ０００１”や“ｖ０００２”）を把握することができる。

図２の例では、“ｓｔａｂｌｅ／ｖ０００１”ブランチから、さらに分岐して“ｆｉｘ／Ｂ０１１／ｖ０００１／ＤＥＶ”というブランチが作成されている。これは、不具合“Ｂ０１１”に対してチームで対応するための管理用のブランチ（総称して「不具合修正用ブランチ」と呼ぶ）であり、不具合“Ｂ０１１”に対してチーム全体で作成された修正コードを格納するブランチである。図３に示した命名規則によってブランチ名が付されることにより、ブランチ名からブランチの種別とバージョン（図２の例では“ｖ０００１”）および不具合名（図２の例では“Ｂ０１１”）を把握することができる。

図２の例では、“ｆｉｘ／Ｂ０１１／ｖ０００１／ＤＥＶ”ブランチから、さらに分岐して“ｆｉｘ／Ｂ０１１／ｖ０００１／ｕｓｅｒ１”というブランチが作成されている。これは、不具合“Ｂ０１１”への対応を行う開発者“ｕｓｅｒ１”専用のブランチ（総称して「不具合修正用開発者ブランチ」と呼ぶ）であり、“ｕｓｅｒ１”個人の作業成果物を格納するブランチである。図３に示した命名規則によってブランチ名が付されることにより、ブランチ名からブランチの種別とバージョン（図２の例では“ｖ０００１”）、不具合名（図２の例では“Ｂ０１１”）および開発者（図２の例では“ｕｓｅｒ１”）を把握することができる。

なお、例えば、開発者用のブランチ（「機能開発用開発者ブランチ」や「不具合修正用開発者ブランチ」など）は、機能開発や不具合修正をチームではなく開発者個人で直接行う場合には作成しない運用とすることも可能である。

また、ブランチの命名規則（ネーミングルール）は、図３に示したものに限られないが、上述したように、「最新開発ブランチ」／「機能開発用ブランチ」／「機能開発用開発者ブランチ」、および「安定ブランチ」／「不具合修正用ブランチ」／「不具合修正用開発者ブランチ」のように、ブランチ間に親子関係が成立しており、その関係がブランチ名から把握できるようにネーミングされていることを前提とする。

＜データ構成＞
以下では、ソーシャルコーディングシステム１００もしくは課題管理システム３００が管理する課題ＤＢ１０１のデータ構成について説明する。図４は、課題ＤＢ１０１内のテーブルの１つである課題管理情報１０１ａのデータ構成および具体的なデータの例について概要を示した図である。図４（ａ）ではデータ構成を示しており、図４（ｂ）ではデータの具体的な例を示している。課題管理情報１０１ａは、課題毎にその内容に関する情報を保持するテーブルであり、例えば、課題ＩＤ、タイトル、内容詳細、担当者、マイルストーン、状態、およびラベルＩＤリストなどの各項目を有する。

課題ＩＤの項目は、各課題を一意に識別することができるＩＤやシーケンス番号等の情報を保持する。タイトルの項目は、対象の課題に付されたタイトルや名称の情報を保持する。タイトルのフォーマットを、図４（ｂ）に示すように、例えば“［課題識別子］＿テキスト”として、各課題を一意に識別することができる課題識別子（例えば“Ｃ００１”など）の情報を含めるようにしてもよい。課題識別子として上記の課題ＩＤの項目の値を用いる場合には特にタイトルの項目に課題識別子を含めなくてもよい。

内容詳細の項目は、対象の課題の内容についての詳細情報を保持する。例えば、対応する機能開発や不具合修正の内容を説明する情報などを含むことができる。担当者の項目は、対象の課題の担当者や管理者、責任者などを特定する情報を保持する。マイルストーンの項目は、対象の課題をどのバージョンのリリースで対応するかというマイルストーンの情報を保持する。状態の項目は、対象の課題の状態やステータスの情報を保持する。ラベルＩＤリストの項目は、対象の課題に対して設定された１つ以上のラベルを特定するラベルＩＤのリストの情報を保持する。各ラベルＩＤは、後述するラベル情報のテーブルに定義されている。

なお、課題管理情報１０１ａは、例えば、課題が機能開発である場合、もしくは不具合修正である場合に、それぞれに特化してその内容に関する情報を保持することができるよう、機能開発と不具合修正のそれぞれの課題毎に個別にテーブルを有していてもよい。図５は、課題が機能開発である場合に特化して、開発対象の機能の内容に関する情報を保持する開発機能情報１０１ｂのデータ構成の例について概要を示した図である。また、図６は、課題が不具合修正である場合に特化して、修正対象の不具合の内容に関する情報を保持する不具合情報１０１ｃのデータ構成の例について概要を示した図である。開発機能情報１０１ｂの開発機能ＩＤ、および不具合情報１０１ｃの不具合ＩＤの項目は、それぞれ、課題管理情報１０１ａの課題ＩＤに対応する項目である。また、不具合情報１０１ｃでは、対象の不具合が発生したバージョンの情報を保持する発生バージョンの項目を有している。

図７は、課題ＤＢ１０１内のテーブルの１つであるラベル情報１０１ｄのデータ構成および具体的なデータの例について概要を示した図である。ラベル情報１０１ｄは、課題に設定される各種文字列等の情報をラベル化、コード化したものの定義内容を保持するマスタテーブルであり、例えば、ラベルＩＤ、およびラベル名などの各項目を有する。ラベルＩＤの項目は、各ラベルを一意に識別することができるＩＤやシーケンス番号等の情報を保持する。ラベル名の項目は、ラベルＩＤに対応するラベルの文字列等の情報を保持する。

なお、上述の図４〜図７で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

＜１．ブランチの自動生成＞
本実施の形態では、上述したように、例えば、図１５のステップＳ１において課題（変更票もしくは不具合票）が作成され、もしくは課題の状態が変化したときに、図１５のステップＳ２やＳ３において課題の情報に基づいて自動的に当該課題に対応したブランチを生成することができる。以下では、このブランチの自動生成の処理について説明する。

図１５のステップＳ２における管理用のブランチ（「機能開発用ブランチ」や「不具合修正用ブランチ」）を自動生成する場合、例えば、図１の例に示したユーザ端末４００の課題処理部４１２において、ユーザからの指示・操作により課題（変更票もしくは不具合票）が新規に作成され、もしくは修正されると、これに連携して、ソーシャルコーディングシステム１００の課題管理部１２０が当該課題を課題ＤＢ１０１に登録もしくは修正する。そして、課題ＤＢ１０１への登録・修正をトリガに、ブランチ処理部１３０が呼び出され、ブランチ処理部１３０が当該課題に対応するブランチを生成する。

図８は、ブランチ処理部１３０におけるブランチの自動生成処理の流れの例について概要を示したフローチャートである。まず、課題の情報から、当該課題を一意に特定することができる課題識別子を抽出する（Ｓ０１）。課題識別子の例としては、機能開発における開発項目や、不具合修正における指摘不具合に対応して割り当てられたＩＤがある。例えば、機能開発における開発項目毎に発行された変更票のＩＤ（例えば“Ｃ００１”など）や、不具合修正における指摘不具合毎に発行された不具合票のＩＤ（例えば“Ｂ０１１”など）を用いることができる。本実施の形態では、例えば、変更票の場合はＩＤの先頭文字を“Ｃ”（Ｃｈａｎｇｅ）とし、不具合票の場合はＩＤの先頭文字を“Ｂ”（Ｂｕｇ）とすることで、課題識別子から変更票か不具合票かを判定可能としている。なお、課題を一意に特定することができる文字列であれば他の項目を課題識別子として用いてもよい。

課題識別子の情報は、例えば、ソーシャルコーディングシステム１００のブランチ処理部１３０や課題管理部１２０が課題ＤＢ１０１にアクセスして、対象の課題の課題ＩＤや、タイトルの項目から課題識別子に相当する部分を抽出することができる。本実施の形態では、上述したように、課題ＤＢ１０１の課題管理情報１０１ａにおいて、課題のタイトルのフォーマットを、例えば“［課題識別子］＿テキスト”としており、タイトルの文字列から課題識別子の情報を抽出することが可能である。また、不具合修正に係る課題をバージョン毎に管理する場合は、後述する処理によりバージョン情報を取得して、これを課題識別子の情報に付加するようにしてもよい。

本実施の形態では、ソーシャルコーディングシステム１００が課題ＤＢ１０１を有して課題を管理する構成を前提に説明したが、ソーシャルコーディングシステム１００とは独立した課題管理システム３００により課題を管理する構成の場合には、課題管理システム３００が管理する課題情報を参照して課題識別子を抽出するようにしてもよい。

次に、課題が不具合対応であるか否かを判定し（Ｓ０２）、不具合対応である場合には、不具合が発生したバージョンの情報を取得する（Ｓ０３）。課題が不具合対応ではない機能開発の場合には、ステップＳ０３を行わずにステップＳ０４に進む。ステップＳ０３での処理としては、例えば、ブランチ処理部１３０や課題管理部１２０が課題ＤＢ１０１にアクセスして、課題管理情報１０１ａから、対象の課題についてのラベルＩＤリストの項目の値を取得する。そして、ラベルＩＤリスト内の各ラベルＩＤについて、ラベル情報１０１ｄからラベル名の項目の値を取得することで、課題に対応したラベルをすべて取得する。

このとき、バージョンを表すラベルが含まれるか否かを判定する。例えば、図４（ｂ）に示した課題管理情報１０１ａの例において、対象の課題が課題ＩＤ＝“５”のレコードの課題の場合は、ラベルＩＤリストとして“１，３，５”の文字列が得られる。これをカンマ（“，”）で分割して、ラベルＩＤとして“１”、“３”、“５”の３つを得る。そして、これらのラベルＩＤについて、図７（ｂ）の例に示したラベル情報１０１ｄでは、それぞれ、“ｖ０１００”、“不具合”、“ＷＩＰ”の文字列（ラベル）を得ることができる。その後、得られた各ラベルについて、バージョンを表す文字列であるか否かを、例えば所定の正規表現（例えば、“／ｖ［０−９］｛４｝”など）に合致するか否かにより判定し、合致する場合にはバージョンを表す文字列とする。

なお、本実施の形態では、上述したように、不具合修正の課題の情報からバージョン情報を抽出する際に、課題管理情報１０１ａのラベルＩＤリストの項目と、ラベル情報１０１ｄのラベルＩＤの項目とを対応付けて、ラベル情報１０１ｄのラベル名から取得しているが、これに限られない。例えば、課題情報の管理が、課題管理情報１０１ａではなく、不具合修正に特化した形で図６の不具合情報１０１ｃのようなデータ構成によって管理している場合には、不具合情報１０１ｃにおける発生バージョンの項目の値をそのまま用いるようにしてもよい。

次に、ソーシャルコーディングシステム１００のブランチ処理部１３０等により、課題に対応するブランチがあるか否かを判定する（Ｓ０４）。ステップＳ０４での処理としては、例えば、ステップＳ０１において抽出した課題識別子が、機能開発の課題に係るものである場合は、当該課題識別子に基づいて生成したブランチ名について、リポジトリ管理システム２００のブランチ管理部２２０を介してリポジトリＤＢ２０１を検索し、対象のブランチの有無を判定する。

例えば、図４（ｂ）に示した課題管理情報１０１ａの例において、対象の課題が課題ＩＤ＝“１”のレコードの課題の場合は、ステップＳ０１においてタイトルの項目から課題識別子として“Ｃ００１”が得られるので、図３に示した機能開発用ブランチの命名規則に従って“ｆｅａｔｕｒｅ／Ｃ００１／ＤＥＶ”というブランチ名を生成し、リポジトリＤＢ２０１上でその有無を確認する。

また、ステップＳ０１において抽出した課題識別子が、不具合修正の課題に係るものである場合は、当該課題識別子と、ステップＳ０３で取得した発生バージョンとに基づいて生成したブランチ名について、リポジトリ管理システム２００のブランチ管理部２２０を介してリポジトリＤＢ２０１を検索し、対象のブランチの有無を判定する。

例えば、図４（ｂ）に示した課題管理情報１０１ａの例において、対象の課題が課題ＩＤ＝“５”のレコードの課題の場合は、ステップＳ０１においてタイトルの項目から課題識別子として“Ｂ００３”が得られる。また、ステップＳ０２において、ラベルＩＤ＝“１”に対応するラベル名として、図７（ｂ）に示したラベル情報１０１ｄの例から、発生バージョンとして“ｖ０１００”が得られるので、図３に示した不具合修正用ブランチの命名規則に従って“ｆｉｘ／Ｂ００３／ｖ０１００／ＤＥＶ”というブランチ名を生成し、リポジトリＤＢ２０１上でその有無を確認する。

ステップＳ０４において課題に対応するブランチが既にリポジトリ上にある場合は、何もせずに（ＮＯＰ：No OPeration）（Ｓ０８）、ブランチの自動生成処理を終了する。一方、ステップＳ０４において課題に対応するブランチがまだない場合は、次に、対象の課題のステータスが作業中であるか否か、すなわち、対象の課題の課題情報に作業中であることを表すラベルがあるか否かを判定する（Ｓ０５）。

ラベルの取得は、対象の課題について課題管理情報１０１ａからラベルＩＤリストの項目の値を取得し、リストに含まれる各ラベルＩＤについて、ラベル情報１０１ｄからそれぞれ対応するラベル名を取得する。取得した各ラベルについて、作業中であることを表す“ＷＩＰ（Work In Progress）”を表すラベルがあるか否かを判定する。例えば、図４（ｂ）に示した課題管理情報１０１ａの例において、対象の課題が課題ＩＤ＝“５”のレコードの課題の場合は、上述したように、課題管理情報１０１ａからは、ラベルＩＤとして“１”、“３”、“５”の３つを得ることができ、さらに、図７（ｂ）の例に示したラベル情報１０１ｄから、それぞれ、“ｖ０１００”、“不具合”、“ＷＩＰ”のラベルを得ることができる。この中に、作業中を表す“ＷＩＰ”のラベルが含まれていることから、対象の課題は作業中であると判定する。

ステップＳ０５において課題が作業中ではない場合は、何もせずに（ＮＯＰ）（Ｓ０８）、ブランチの自動生成処理を終了する。一方、ステップＳ０５において課題が作業中である場合は、ステップＳ０４において生成したブランチ名に基づいて、これを生成する際の分岐元となるブランチを特定する（Ｓ０６）。分岐元となるブランチは、例えば、図３に示した各ブランチとその分岐元のブランチについての命名規則の情報に基づいて特定することができる。例えば、ステップＳ０５において生成したブランチ名が“ｆｉｘ／Ｂ００３／ｖ０１００／ＤＥＶ”である場合、図３の表の命名規則から「（バージョンｖ０１００に対する）不具合Ｂ００３修正用ブランチ」であることが分かり、さらにその分岐元のブランチのブランチ名が“ｓｔａｂｌｅ／ｖ０１００”であることを特定することができる。

その後、リポジトリ管理システム２００のブランチ管理部２２０を介して、ステップＳ０６で特定した分岐元のブランチ名に係るブランチから、ステップＳ０４において生成したブランチ名に係るブランチを新規に生成し（Ｓ０７）、ブランチの自動生成処理を終了する。

上記の一連の処理を、課題が作成されたタイミングや、課題のステータスが修正されたタイミングで実行する、もしくは定期的に実行することで、例えば、ステータスが“作業中”に変わったタイミングで自動的にブランチを生成することもできる。

図１５のステップＳ３における開発者のブランチ（「機能開発用開発者ブランチ」や「不具合修正用開発者ブランチ」）を自動生成する場合も、基本的な処理は上述の図８に示した処理内容と同様である。開発者ブランチを生成する場合は、さらに開発者の情報を得るため、追加の処理として例えば、ステップＳ０１の処理の前に、ソーシャルコーディングシステム１００の課題管理部１２０が課題ＤＢ１０１にアクセスし、課題管理情報１０１ａにおける対象の課題に係る担当者の項目の値を取得する処理を行う。この処理で担当者の情報を取得できなかった場合は、何もせずに（ＮＯＰ）（Ｓ０８）、ブランチの自動生成処理を終了する。

また、ステップＳ０４でブランチ名を生成する際に、図３に示したブランチの命名規則において従う規則を、開発者ブランチのものとする。例えば、図４（ｂ）に示した課題管理情報１０１ａの例において、対象の課題が課題ＩＤ＝“５”のレコードの課題の場合は、担当者の項目から“ｓ−ｎａｋａ”が得られる。また、ステップＳ０１においてタイトルの項目から課題識別子として“Ｂ００３”が得られる。また、ステップＳ０２において、ラベルＩＤ＝“１”に対応するラベル名として、図７（ｂ）に示したラベル情報１０１ｄの例から、発生バージョンとして“ｖ０１００”が得られる。これらから図３に示したブランチの命名規則に従ってブランチ名を生成する際に、“ｆｉｘ／Ｂ００３／ｖ０１００／ＤＥＶ”ではなく、“ｆｉｘ／Ｂ００３／ｖ０１００／ｓ−ｎａｋａ”というブランチ名を生成する。

これにより、開発者ブランチについても課題との関連付けを行いつつ自動生成することができる。なお、開発者ブランチについては、課題の作成時に管理用のブランチの新規生成と合わせて生成してもよいし、この時点で担当者が設定されていない場合は、後に担当者が設定された際に、そのイベントをトリガとして開発者ブランチを自動生成するようにしてもよい。

＜２．コミットコメントの自動追加＞
本実施の形態では、上述したように、開発者ブランチの作成後、図１５のステップＳ４において、ソースコードの作成・修正、テスト等の開発が行われ、完了したものを１つのコミットとして登録する際に、コミットと課題（変更票もしくは不具合票）との関連付けに係る情報をコミットコメントに自動的に追加することができる。以下では、このコミットコメントの自動追加の処理について説明する。

開発者がユーザ端末４００上でソーシャルコーディングクライアント４１０を用いて開発を行い、コミットを実行すると、ソーシャルコーディングクライアント４１０のコミット処理部４１３が呼び出され、コミットコメントの追加の処理が行われる。図９は、コミット処理部４１３におけるコミットコメントの自動追加処理の流れの例について概要を示したフローチャートである。まず、コミットの対象のブランチ名から、対応する課題識別子を抽出する（Ｓ１１）。

図３に示した命名規則に従えば、例えば、機能開発における「機能開発用ブランチ」や「機能開発用開発者ブランチ」では、いずれも、ブランチ名が“ｆｅａｔｕｒｅ／ＣＸＸＸ／〜”となるため、ブランチ名を“／”で分割した文字列の先頭から２番目を取得すれば、課題識別子（この場合は“ＣＸＸＸ”）を得ることができる。同様に、不具合修正における「不具合修正用ブランチ」や「不具合修正用開発者ブランチ」でも、いずれも、ブランチ名が“ｆｉｘ／ＢＸＸＸ／〜”となるため、ブランチ名を“／”で分割した文字列の先頭から２番目を取得すれば、課題識別子（この場合は“ＢＸＸＸ”）を得ることができる。

次に、コミット処理部４１３は、ネットワーク５００を介してソーシャルコーディングシステム１００の課題管理部１２０にアクセスし、課題管理部１２０を介して、課題ＤＢ１０１にステップＳ１１で抽出した課題識別子に係る課題の情報が保持されているか否かを判定する（Ｓ１２）。課題識別子に係る課題の情報が課題ＤＢ１０１に保持されている（当該課題が課題管理部１２０による管理対象となっている）か否かは、例えば、課題管理情報１０１ａのタイトルの項目に対象の課題識別子が含まれているものがあるか否かによって判断することができる。タイトルの項目に代えて、もしくはこれに加えて内容詳細の項目に対象の課題識別子が含まれるか否かによって判断するようにしてもよい。

ステップＳ１２において対象の課題が課題ＤＢ１０１に保持されていない場合は、何もせずに（ＮＯＰ）（Ｓ１４）、コミットコメントの自動追加処理を終了する。一方、ステップＳ１２において対象の課題が課題ＤＢ１０１に保持されている場合は、コミット処理部４１３は、ソーシャルコーディングシステム１００の課題管理部１２０を介して対象の課題に係る課題ＩＤの項目とタイトルの項目の値を取得し、これらをコミット時のコメントに追加して（Ｓ１３）、コミットコメントの自動追加処理を終了する。

＜３−１．Ｐｕｌｌリクエスト時のブランチの自動指定＞
本実施の形態では、上述したように、図１５のステップＳ５においてＰｕｌｌリクエストを行う際に、ブランチの情報に基づいてマージ先（分岐元）となるブランチを判断し、マージ先およびマージ元のブランチ名を自動的に指定・補完することで、Ｐｕｌｌリクエストとブランチおよび課題との関連付けを自動的に行うことができる。以下では、このＰｕｌｌリクエスト時のブランチの自動指定の処理について説明する。

図１０は、ユーザ端末４００上でソーシャルコーディングクライアント４１０により表示されるリポジトリ表示画面の例について概要を示した図である。開発者が、ユーザ端末４００上でソーシャルコーディングクライアント４１０を用いて開発を完了し、Ｐｕｌｌリクエストを行う際に、図１０に示したようなリポジトリ表示画面において、“ブランチ名”として開発成果物が含まれるマージ元の開発者ブランチを指定し、“Ｐｕｌｌリクエスト”ボタンを押下する。これにより、ソーシャルコーディングクライアント４１０のＰｕｌｌリクエスト作成部４１４が呼び出される。本実施の形態では、Ｐｕｌｌリクエスト作成部４１４は、ネットワーク５００を介してソーシャルコーディングシステム１００のＰｕｌｌリクエスト処理部１４０を呼び出し、マージ先（分岐元）のブランチの自動指定の処理を行う。

図１１は、Ｐｕｌｌリクエスト処理部１４０におけるブランチの自動指定処理の流れの例について概要を示したフローチャートである。まず、図１０の例に示したリポジトリ表示画面において現在表示されている（指定されている）ブランチ、すなわちマージ元となるブランチのブランチ名の情報を取得する（Ｓ２１）。例えば、ソーシャルコーディングクライアント４１０のＰｕｌｌリクエスト作成部４１４がリポジトリ表示画面から取得して、ソーシャルコーディングシステム１００のＰｕｌｌリクエスト処理部１４０を呼び出す際にパラメータとして追加することで、Ｐｕｌｌリクエスト処理部１４０は当該ブランチの情報を取得することができる。

次に、ステップＳ２１で取得したマージ元のブランチ名からマージ先のブランチを特定する（Ｓ２２）。本実施の形態では、各ブランチが図３に示したような命名規則に従ってネーミングされていることを前提とし、これに基づいてマージ先となるブランチ名を特定する。すなわち、マージ元のブランチ名が図３に示した命名規則におけるどのブランチに該当するかを判定し、対応する分岐元（マージ先）のブランチ名の命名規則に基づいてマージ先のブランチ名を生成する。例えば、マージ元のブランチ名が“ｆｉｘ／Ｂ００２／ｖ０１００／ｈ−ｎａｋａ”であった場合、「不具合Ｂ００２の開発者ｈ−ｎａｋａ用ブランチ」（図３の表の最下段）であるため、分岐元ブランチのブランチ名として、命名規則に基づいて“ｆｉｘ／Ｂ００２／ｖ０１００／ＤＥＶ”を得ることができる。

その後、Ｐｕｌｌリクエスト処理部１４０は、ステップＳ２１で取得したブランチ名をマージ元ブランチ、ステップＳ２２で生成したブランチ名をマージ先ブランチとしてＰｕｌｌリクエスト画面を生成し、ユーザ端末４００のソーシャルコーディングクライアント４１０に送信して画面表示させる（Ｓ２３）。図１２は、ユーザ端末４００上でソーシャルコーディングクライアント４１０により表示されるＰｕｌｌリクエスト画面の例について概要を示した図である。図示するように、マージ元およびマージ先のリポジトリ名、ブランチ名が自動的に設定・選択された状態で画面を表示させることができる。

なお、このＰｕｌｌリクエスト画面において“Ｐｕｌｌリクエスト送信”ボタンを押下すると、ソーシャルコーディングクライアント４１０のＰｕｌｌリクエスト作成部４１４によりＰｕｌｌリクエストが作成され、ソーシャルコーディングシステム１００のＰｕｌｌリクエスト処理部１４０に送信されて、Ｐｕｌｌリクエストに係る処理が実行される。

＜３−２．Ｐｕｌｌリクエストへのコメントの自動追加＞
本実施の形態では、上記のＰｕｌｌリクエストを行う際に、さらに、当該Ｐｕｌｌリクエストに対してコメントを自動的に追加することができる。これにより、Ｐｕｌｌリクエストに対してレビュー等を行うリーダー等が、当該Ｐｕｌｌリクエストがどの課題に対応したものであるのか等の情報を容易に把握することが可能となる。

具体的には、上述の図１１で示したＰｕｌｌリクエスト時のブランチの自動指定の処理において、例えば、ステップＳ２２でソーシャルコーディングシステム１００のＰｕｌｌリクエスト処理部１４０が、マージ元のブランチ名から、図３に示した命名規則に基づいてマージ先のブランチ名を特定した際に、合わせて、マージ元のブランチ名に対応する課題の情報を取得する処理を行う。課題の情報は、例えば、上述の図９に示した処理のステップＳ１１、Ｓ１２と同様に、マージ元のブランチ名から、図３に示した命名規則に基づいて課題識別子を抽出し、当該課題識別子に係る課題情報が課題ＤＢ１０１に保持されているか否かを判定することで取得することができる。

マージ元のブランチに対応する課題の情報が課題ＤＢ１０１から得られた場合は、課題管理情報１０１ａにおける課題ＩＤやタイトルなどの情報をＰｕｌｌリクエストに対するコメントとして自動的に追加した上で、図１１のステップＳ２３でＰｕｌｌリクエスト画面を生成する。図１３は、ユーザ端末４００上でソーシャルコーディングクライアント４１０により表示されるＰｕｌｌリクエスト画面の例について概要を示した図である。図示するように、マージ元のブランチに対応する課題（図１３の例では不具合“Ｂ００２”）に係る課題ＩＤやタイトルの情報が自動的にコメントとして設定された状態で画面を表示させることができる。

以上に説明したように、本発明の一実施の形態である開発支援システム１によれば、必要なタイミングでブランチを自動的に作成することでブランチの数をできるだけ抑え、可能な限り最新の状態から開発作業に着手させることが可能である。また、課題、ブランチ、コミット、Ｐｕｌｌリクエストの間の関連付けを自動的に行うことで、作業負荷を低減させ、ソフトウェア開発作業における作業効率を向上させることができる。

具体的には、課題が作成されたり、ステータスが変わったり、開発者がアサインされたりなどのタイミングで、自動的に当該課題に対応したブランチを命名規則に従って作成する。また、作成された課題の情報に基づいて、分岐元となるブランチを自動的に指定する。これにより、課題の作成等のタイミングでブランチを自動的に作成するとともに、課題とブランチとの関連付けも自動的に行うことができる。

また、コミット対象のブランチ名の情報に基づいて、ブランチの命名規則から、当該ブランチに対応する変更票もしくは不具合票の識別情報を判断し、その情報をコミットコメントに付与する。これにより、コミットと課題（変更票もしくは不具合票）との関連付けも自動的に行うことができる。

また、マージ元のブランチ名の情報に基づいて、ブランチの命名規則から、マージ先（分岐元）となるブランチを判断し、その情報に基づいて、Ｐｕｌｌリクエストの作成時に必要となるマージ先およびマージ元のブランチ名を自動的に指定・補完する。また、マージ元のブランチ名の情報に基づいて、対応する課題の情報を取得し、これをＰｕｌｌリクエストの作成時にコメントとして自動的に追加する。これらにより、Ｐｕｌｌリクエストとブランチおよび課題との関連付けを自動的に行うことができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、ソーシャルコーディングシステムを利用したプログラム開発を支援する開発支援システムに利用可能である。

１…開発支援システム、
１００…ソーシャルコーディングシステム、１０１…課題ＤＢ、１０１ａ…課題管理情報、１０１ｂ…開発機能情報、１０１ｃ…不具合情報、１０１ｄ…ラベル情報、１１０…ユーザ認証部、１２０…課題管理部、１３０…ブランチ処理部、１４０…Ｐｕｌｌリクエスト処理部、
２００…リポジトリ管理システム、２０１…リポジトリＤＢ、２１０…リポジトリ管理部、２２０…ブランチ管理部、２３０…マージ処理部、
３００…課題管理システム、３１０…課題管理部、
４００…ユーザ端末、４０１…ローカルリポジトリＤＢ、４１０…ソーシャルコーディングクライアント、４１１…リポジトリ処理部、４１２…課題処理部、４１３…コミット処理部、４１４…Ｐｕｌｌリクエスト作成部、
５００…ネットワーク。

Claims (6)

1. 開発成果物およびその変更履歴をリポジトリに保持するリポジトリ管理システムと、
   前記開発成果物と課題とを関連付けて管理するソーシャルコーディングシステムと、を有する開発支援システムであって、
   前記ソーシャルコーディングシステムは、
   前記課題の情報を管理する課題管理部と、
   前記リポジトリにおいてブランチの生成を行うブランチ処理部と、を有し、
   前記ブランチ処理部は、指定された前記課題の情報に基づいて、分岐元となる第１のブランチを特定し、前記第１のブランチから分岐させて、前記課題に対応する第２のブランチを生成する、開発支援システム。
2. 請求項１に記載の開発支援システムにおいて、
   前記ソーシャルコーディングシステムの前記ブランチ処理部は、指定された前記課題の状態が所定の状態になっていることを条件に、前記第２のブランチを生成する、開発支援システム。
3. 請求項１に記載の開発支援システムにおいて、
   前記ソーシャルコーディングシステムの前記ブランチ処理部は、指定された前記課題の情報から、ブランチおよび分岐元のブランチの命名規則の情報に基づいて、前記第１のブランチおよび前記第２のブランチの名称を特定する、開発支援システム。
4. 請求項３に記載の開発支援システムにおいて、
   さらに、前記ソーシャルコーディングシステムを介して前記リポジトリに前記開発成果物を登録するソーシャルコーディングクライアントを有し、
   前記ソーシャルコーディングクライアントは、前記リポジトリにおいて前記第２のブランチに前記開発成果物を登録するためのコミット処理を行うコミット処理部を有し、
   前記コミット処理部は、前記第２のブランチの名称から前記命名規則の情報に基づいて、前記第２のブランチに対応する前記課題を特定する情報を取得し、前記ソーシャルコーディングシステムの前記課題管理部において、前記課題が管理対象となっている場合に、前記課題管理部を介して前記課題に係る情報を取得して、取得した情報をコミット処理を行う際のコメントに追加する、開発支援システム。
5. 請求項３に記載の開発支援システムにおいて、
   さらに、前記ソーシャルコーディングシステムを介して前記リポジトリに前記開発成果物を登録するソーシャルコーディングクライアントを有し、
   前記ソーシャルコーディングシステムは、さらに、前記リポジトリにおいて前記開発成果物が登録された前記第２のブランチを前記第１のブランチに反映させるためのＰｕｌｌリクエストを受け付けて、前記Ｐｕｌｌリクエストに係る処理を行うＰｕｌｌリクエスト処理部を有し、
   前記ソーシャルコーディングシステムの前記Ｐｕｌｌリクエスト処理部は、前記ソーシャルコーディングクライアントから指定された前記Ｐｕｌｌリクエストに係る前記第２のブランチの情報を取得し、前記第２のブランチの名称から前記命名規則の情報に基づいて、マージ先となる前記第１のブランチの名称を特定し、マージ元を前記第２のブランチ、マージ先を前記第１のブランチとした前記Ｐｕｌｌリクエストを作成するための画面を前記ソーシャルコーディングクライアントを介して表示させる、開発支援システム。
6. 請求項５に記載の開発支援システムにおいて、
   前記ソーシャルコーディングシステムの前記Ｐｕｌｌリクエスト処理部は、前記ソーシャルコーディングクライアントから指定された前記Ｐｕｌｌリクエストに係る前記第２のブランチの情報を取得し、前記第２のブランチの名称から前記命名規則の情報に基づいて、前記第２のブランチに対応する前記課題を特定する情報を取得し、前記ソーシャルコーディングシステムの前記課題管理部において、前記課題が管理対象となっている場合に、前記課題管理部を介して前記課題に係る情報を取得して、取得した情報を前記Ｐｕｌｌリクエストに対するコメントとして追加した前記Ｐｕｌｌリクエストを作成するための画面を前記ソーシャルコーディングクライアントを介して表示させる、開発支援システム。