(57)【要約】【課題】複数のチームが携わるソフトウェア開発プロジェクトにおいて、構成管理ツール等に対する知識やスキルの習得を要さずに、ソフトウェアの構成管理を容易かつ効率的に行うことを可能とする。【解決手段】モジュールをリポジトリＤＢ１４に保持してバージョン管理を行うバージョン管理システム１１と、障害もしくは開発に係る案件毎に工程をワークフローにより管理するプロジェクト管理システム１２と、バージョン管理システム１１とプロジェクト管理システム１２とを連携させる連携部１３とを有し、連携部１３は、プロジェクト管理システム１２がユーザに提供する前記工程を処理する画面を生成した際に、前記工程においてバージョン管理システム１１に対して行うべき処理を実行するスクリプトファイルを生成し、これをダウンロードさせるための指示部を前記画面に埋め込む。【選択図】図１
2016076181.tif 000002
【特許請求の範囲】
【請求項１】
複数の開発チームによりソフトウェア開発を行う際の構成管理を支援するチーム内構成管理システムであって、
ソフトウェアを構成するモジュールをリポジトリに保持してバージョン管理を行うバージョン管理部と、
障害もしくは開発に係る案件毎に工程をワークフローにより管理するプロジェクト管理部と、
前記バージョン管理部と前記プロジェクト管理部とを連携させる連携部と、を有し、
前記連携部は、前記プロジェクト管理部がユーザに提供する前記工程を処理する画面を生成した際に、前記工程において前記バージョン管理部に対して行うべき処理を実行するスクリプトファイルを生成し、当該スクリプトファイルをダウンロードさせるための指示部を前記画面に埋め込む、チーム内構成管理システム。
【請求項２】
請求項１に記載のチーム内構成管理システムにおいて、
前記ソフトウェアを構成する前記モジュールの情報を一覧するデータをライブラリ管理情報保持部に保持し、
前記バージョン管理部は、前記リポジトリの内容が更新された場合に、当該更新の内容を前記ライブラリ管理情報保持部に反映させ、
前記連携部は、前記プロジェクト管理部がユーザに提供する前記工程を処理する前記画面を生成した際に、前記ライブラリ管理情報保持部の内容をエクスポートしたライブラリ管理台帳ファイルをダウンロードさせるための指示部を前記画面に埋め込む、チーム内構成管理システム。
【請求項３】
請求項２に記載のチーム内構成管理システムにおいて、
前記連携部は、前記プロジェクト管理部がユーザに提供する前記工程を処理する前記画面を生成した際に、前記ライブラリ管理台帳ファイルに対して変更が加えられたものをアップロードして、当該変更を前記リポジトリに反映させるスクリプトファイルを生成し、当該スクリプトファイルをダウンロードさせるための指示部を前記画面に埋め込む、チーム内構成管理システム。
【請求項４】
請求項１に記載のチーム内構成管理システムにおいて、
前記連携部は、前記プロジェクト管理部がユーザに提供する前記工程を処理する前記画面を生成した際に、前記工程が前記プロジェクト管理部に対する前記モジュールのチェックアウト申請もしくはコミット申請である場合に、チェックアウト申請書もしくはコミット申請書のファイルを生成し、当該ファイルをダウンロードさせるための指示部を前記画面に埋め込む、チーム内構成管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発における構成管理の技術に関し、特に、大規模な開発プロジェクトなど、複数のチームが開発に携わるプロジェクトに適用するチーム内構成管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
大規模なソフトウェア開発プロジェクトなどでは、複数のチームがソフトウェアの各部を分担し、並行的に開発を行う場合がある。このような場合、いわゆるソフトウェア構成管理として、例えば、ソースコード等のモジュールやドキュメント等の成果物について、バージョンや変更履歴などを適切に管理する必要がある。
【０００３】
ソースコード等のモジュールの管理については、従来は、例えば、ライブラリアンの役割を有するメンバーが、台帳管理や開発のためのモジュールの受け渡し、払い出しなどの作業を人手で行うことで管理していた。しかしながら、例えば、台帳への最新状況の反映が必ずしもリアルタイムでなされずにタイムラグを有するため、開発者が最新の状況を把握するのが困難となったり、払い出しや登録の申請手続にミスが生じやすかったりなど、管理負荷が非常に高いものとなっていた。
【０００４】
これに対し、ソフトウェアの構成管理をシステム的に行うためのツールとして、例えば、ＣＶＳ（Concurrent Versions System）やＳｕｂｖｅｒｓｉｏｎ（登録商標、以下では「ＳＶＮ」と記載する場合がある）などのバージョン管理システムや、Ｒｅｄｍｉｎｅなどのプロジェクト管理システムなどが普及してきている。
【０００５】
また、これらに関連する技術として、例えば、特開２０１３−１９１００３号公報（特許文献１）には、既存の懸案管理システムを参照し、既存のバージョン管理システムに懸案事項ごとにトランクリポジトリを派生元としてブランチリポジトリを作成させるブランチ作成部と、懸案管理システムにブランチリポジトリのソースファイルをデータ端末の作業フォルダに格納させるチェックアウト処理部と、懸案管理システムにソースファイルの変更内容をブランチリポジトリへ反映させるコミット処理部と、懸案管理システムにブランチリポジトリのソースファイルの変更内容を派生元のトランクリポジトリへ反映させるマージ処理部とを有することで、既存のバージョン管理システムが、既存の懸案管理システムで管理している懸案事項毎にバージョン管理を行うことを可能にする技術が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−１９１００３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したようなバージョン管理システムやプロジェクト管理システムなどの構成管理ツールを用いることで、ソフトウェア開発における構成管理をある程度システム化、自動化することができる。しかしながら、これらのツールが個別に全ての要件に対応できるものではなく、守備範囲が異なることから、管理の目的や対象に応じてこれらを組合せて利用することが必要となる。一方で、管理者などを含む各ユーザがこれらの構成管理ツールを利用して構成管理を行うには、これらのツールについての知識やスキルを習得する必要があるが、開発者、特に近年普及してきているいわゆるオフショア開発等における開発者に対してこれらを習得させるにはコストやオーバーヘッドが過大となる場合がある。
【０００８】
また、複数のチームが並行的に開発を行う大規模なソフトウェア開発プロジェクトでは、各チームが開発・修正するモジュールが競合する場合があり、管理対象の各モジュールについてチーム間での整合を維持した上での管理が必要となる。これに加えてさらに、チーム毎に開発工程が異なる（例えば、単体テストと結合テストとシステムテストが並行的に行われる）場合も生じ得ることから、チーム間および工程間での整合を維持した上で、どのモジュールを開発・修正すべきかの制御等を含む管理を行う必要がある。
【０００９】
そこで本発明の目的は、複数のチームが携わるソフトウェア開発プロジェクトにおいて、構成管理ツール等に対する知識やスキルの習得を要さずに、ソフトウェアの構成管理を容易かつ効率的に行うことを可能とするチーム内構成管理システムを提供することにある。
【００１０】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１１】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１２】
本発明の代表的な実施の形態によるチーム内構成管理システムは、複数の開発チームによりソフトウェア開発を行う際の構成管理を支援するシステムであって、ソフトウェアを構成するモジュールをリポジトリに保持してバージョン管理を行うバージョン管理部と、障害もしくは開発に係る案件毎に工程をワークフローにより管理するプロジェクト管理部と、前記バージョン管理部と前記プロジェクト管理部とを連携させる連携部と、を有し、前記連携部は、前記プロジェクト管理部がユーザに提供する前記工程を処理する画面を生成した際に、前記工程において前記バージョン管理部に対して行うべき処理を実行するスクリプトファイルを生成し、当該スクリプトファイルをダウンロードさせるための指示部を前記画面に埋め込むものである。
【発明の効果】
【００１３】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１４】
すなわち、本発明の代表的な実施の形態によれば、複数のチームが携わるソフトウェア開発プロジェクトにおいて、構成管理ツール等に対する知識やスキルの習得を要さずに、ソフトウェアの構成管理を容易かつ効率的に行うことが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態であるチーム内構成管理システムにおける構成管理の例について概要を示した図である。
【図２】本発明の一実施の形態であるチーム内構成管理システムを有するソフトウェア開発環境の構成例について概要を示した図である。
【図３】本発明の一実施の形態におけるスクリプトファイルの生成と実行の処理の流れの例について概要を示した図である。
【図４】本発明の一実施の形態における障害や開発案件の発生時の業務フローの例について概要を示した図である。
【図５】本発明の一実施の形態における障害や開発案件の発生時のシステム内の処理フローの例について概要を示した図である。
【図６】本発明の一実施の形態における障害や開発案件の発生時のシステム内の処理フローの例について概要を示した図である。
【図７】複数のチームが携わるソフトウェア開発プロジェクトにおける従来の構成管理の例について概要を示した図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【００１７】
＜概要＞
図７は、複数のチームが携わるソフトウェア開発プロジェクトにおける従来の構成管理の例について概要を示した図である。図７では、サブシステム等の開発を担当するグループに属する各開発チームが、開発・修正対象のモジュールの払い出し（チェックアウト）を受ける際の手続や処理について示している。まず、開発案件や障害発生等に伴い、モジュールの開発・修正が必要となった際に、対象の開発チームのライブラリアンであるチームライブラリアン６１が、例えば、電子メールや電話などを介して、当該開発チームが属するサブシステムの開発管理者５２に対してモジュールの払い出しを申請する。
【００１８】
申請を受けた開発管理者５２は、開発対象のソフトウェア全体のモジュール等の構成管理を行う統括ライブラリアン４１に対して、正規の手続に従って申請帳票等を起票して申請を行う。申請を受けた統括ライブラリアン４１は、ＣＶＳ等の既存のバージョン管理システム２１上のリポジトリから対象のモジュールを取り出して受け渡す。その後、サブシステムのライブラリアン５１が、当該モジュールをチームライブラリアン６１に対して提供するとともに、モジュールの払い出し状況を管理するためにライブラリ管理台帳１７の内容を手作業により更新する。ライブラリ管理台帳１７は、例えば、表計算ソフトウェアによりリスト形式で作成される。
【００１９】
チームライブラリアン６１が対象のモジュールの提供を受けることで、開発チームはこれに対する開発・修正作業を行うことができる。また、開発チームは、ライブラリ管理台帳１７を参照することで、各開発チームがどのようなモジュールを開発・修正中であるのか等の情報を把握することができる。
【００２０】
このように、サブシステムの開発管理者５２やライブラリアン５１と、各開発チームのチームライブラリアン６１との間でのモジュールの授受は、電子メールやファイルの授受などの個別の手段により手作業で行われており、作業負荷が高くなっている。また、ライブラリ管理台帳１７への更新が人手を介しておりリアルタイムではないことから、最新のモジュール情報を把握することができないために申請手続のミスも生じ易くなっている。
【００２１】
そこで、本発明の一実施の形態であるチーム内構成管理システムでは、サブシステムの開発グループ内において、バージョン管理システムによるモジュールの管理と、プロジェクト管理システムによる障害・開発案件における工程管理、ワークフロー管理とを組み合わせて取り入れ、モジュールの払い出し（チェックアウト）の申請から払い出し、受け入れ（コミット）等の一連の作業のうち、人手にて行われているものを可能な限り自動化することで、ライブラリアンの作業負荷を大きく低減するものである。また、ライブラリ管理台帳１７の生成・更新も自動化するため、各開発チームが常に最新のモジュール情報を把握することができ、申請ミスの低減や情報共有による作業の効率化などを可能とするものである。
【００２２】
図２は、本発明の一実施の形態であるチーム内構成管理システムにおける構成管理の例について概要を示した図である。図７に示した従来の構成管理との相違点として、チームライブラリアン６１は、モジュールの払い出しの申請を電子メール等ではなくＲｅｄｍｉｎｅ等のプロジェクト管理システム１２が提供する画面インタフェースを介して行う。また、払い出されたモジュールについても、ＳＶＮ等のバージョン管理システム１１を利用してリポジトリ上で管理する。
【００２３】
さらに、プロジェクト管理システム１２とバージョン管理システム１１とをユーザに意識させることなく連携させ、さらに、バージョン管理システム１１のリポジトリに対する登録内容に変更があった場合にライブラリ管理台帳１７を自動生成・更新する。これらにより、ライブラリアンの作業負荷の低減と、最新のモジュール情報の把握を可能とする。
【００２４】
なお、本実施の形態では、従来の構成管理との連続性も考慮し、統括ライブラリアン４１が管理する開発対象のソフトウェア全体のモジュールは、ＣＶＳ等の既存のバージョン管理システム２１を使用した構成管理を継続して採用するものとしているが、払い出されたモジュールの開発グループ内での管理も含めて、ソフトウェア全体の構成管理としてＳＶＮ等のバージョン管理ツールを統合的に用いることも可能である。
【００２５】
また、本実施の形態では、後述するように、ライブラリ管理台帳１７にて管理されるモジュール情報をデータベースにて管理するものとするが、ユーザがこれを参照する際のインタフェースとしては、従来との連続性や、一覧性、操作性、情報追加の容易性などを考慮して、表計算ソフトウェアのファイル形式で作成されるライブラリ管理台帳１７を継続して使用するものとし、その内容をデータベースから自動生成・更新することで最新の情報が反映されるようにしている。
【００２６】
＜システム構成＞
図１は、本発明の一実施の形態であるチーム内構成管理システムを有するソフトウェア開発環境の構成例について概要を示した図である。ソフトウェア開発環境は、ＬＡＮ（Local Area Network）等により構成されるセキュアなネットワーク３０に対して、チーム内構成管理システム１０と構成管理システム２０、および各ユーザ（統括ライブラリアン４１やライブラリアン５１、開発管理者５２、各開発チームのチームライブラリアン６１や開発者６２など）が使用する情報処理端末がそれぞれ接続される構成を有している。各ユーザは同じ拠点に所在している必要はなく、例えば、一部もしくは全部の開発チームのチームライブラリアン６１や開発者６２が、海外などの拠点に所在し、ＷＡＮ（Wide Area Network）等を介してチーム内構成管理システム１０にアクセス可能なように構成されていてもよい。
【００２７】
チーム内構成管理システム１０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバ、もしくはＰＣ（Personal Computer）などの情報処理装置等により実装され、ライブラリアン５１や開発管理者５２により、複数の開発チーム（図１の例では、“Ａチーム”、“Ｂチーム”、“Ｃチーム”等）からなる開発グループにおけるソフトウェアの構成管理を行う情報処理システムである。
【００２８】
チーム内構成管理システム１０は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で動作するソフトウェアにより実装されるバージョン管理システム１１やプロジェクト管理システム１２、および連携部１３などの各部を有する。また、データベースにより実装されるリポジトリデータベース（ＤＢ）１４、チケット情報ＤＢ１５、およびライブラリ管理ＤＢ１６などの各データストアを有する。
【００２９】
バージョン管理システム１１は、上述したように、リポジトリＤＢ１４上でモジュールやドキュメント等の成果物についてのバージョンや変更履歴の管理を行うツールであり、本実施の形態ではＳＶＮを用いるものとするが、一般に利用可能な他のバージョン管理ツールやリポジトリ管理ツールなどを適宜用いることが可能である。
【００３０】
プロジェクト管理システム１２は、上述したように、ＲｅｄｍｉｎｅなどのＷｅｂベースのプロジェクト管理ツールであり、ソフトウェア開発プロジェクト毎の「要件管理」や「ＴＯＤＯ」、「障害管理」、「Ｑ＆Ａ管理」、「課題管理」、「依頼」、「変更管理」等のタスクを「チケット」という形でチケット情報ＤＢ１５に記録してワークフローにより管理するなどの機能を、ユーザが使用する情報処理端末上のＷｅｂブラウザを介して利用可能とする機能を有する。本実施の形態ではＲｅｄｍｉｎｅを用いるものとするが、一般に利用可能な他のプロジェクト管理ツールや課題管理ツール、懸案管理ツールなどを適宜用いることが可能である。
【００３１】
なお、本実施の形態では、後述するように、「障害」、「開発（仕様変更や追いつき開発）」、「チェックアウト申請」、「コミット申請」の４種類のチケットを発行することができ、テスト工程で発生したモジュールの障害や、開発をチケットとして起票して管理するものとする。障害や開発が発生した際、チケットを発行すると、プロジェクト管理システム１２のワークフロー機能により、関係者に通知するための電子メールを自動的に送信することができる。これにより、障害や開発の状況を関係者全員でリアルタイムに情報共有することができ、報告や連絡作業を定型化、簡略化することが可能となる。
【００３２】
連携部１３は、バージョン管理システム１１とプロジェクト管理システム１２という異なるツール間での連携をとる機能を有する。具体的には、プロジェクト管理システム１２が提供するＷｅｂインタフェースを介してユーザがチケットに係る各種作業を行う際に、ユーザに意識させることなく、バージョン管理システム１１に対しても対応する処理を実行できるようにする。
【００３３】
本実施の形態では、後述するように、バージョン管理システム１１に対して対応する処理を実行するためのコマンド等が実装されたスクリプトファイルやバッチファイルを自動生成し、これをプロジェクト管理システム１２が提供するＷｅｂインタフェースを介してユーザにダウンロードさせて実行させることで実現する。これにより、一般的にオープンソースのソフトウェアとして提供されるプロジェクト管理システム１２やバージョン管理システム１１のプログラム自体に変更を加えることなく連携させることが可能となり、プロジェクト管理システム１２やバージョン管理システム１１自体のバージョンアップ等による影響を極小化することができる。
【００３４】
上記のスクリプトファイル等は、例えば、バージョン管理システム１１に対する処理（例えば、ブランチの生成やモジュールのチェックアウト、コミット、モジュールのダウンロード等）毎にテンプレートを予め用意しておき、プロジェクト管理システム１２に対するアクセスが行われた際に、処理内容に応じてテンプレートを適宜選択し、対象のチケットのＩＤ等の情報に基づいて必要な情報を取得してパラメータとして設定することで生成する。生成したスクリプトファイルは、例えば、プロジェクト管理システム１２がＷｅｂインタフェースとして生成する画面のＨＴＭＬ（HyperText Markup Language）ファイルに対してダウンロード用の指示部（例えば、ボタンコントロールやハイパーリンク）を埋め込むなどにより、当該指示部を介してユーザにダウンロードさせることができる。
【００３５】
図３は、スクリプトファイルの生成と実行の処理の流れの例について概要を示した図である。ライブラリアン５１や開発管理者５２、チームライブラリアン６１、開発者６２などのユーザが、使用する情報処理端末上のＷｅｂブラウザ等を使用してチーム内構成管理システム１０のプロジェクト管理システム１２に対してチケットに係るワークフロー処理を行うためにアクセス要求を行うと（Ｓ１０１）、プロジェクト管理システム１２は、該当の処理（例えば、チェックアウト申請やコミット申請など）を行うための画面を生成する（Ｓ１０２）。
【００３６】
その際、連携部１３では、該当の処理においてバージョン管理システム１１と連携するための処理を行うためのスクリプトファイルを生成する（Ｓ１０３）。ここでは、上述したように、スクリプトファイルのテンプレートから該当の処理に対応するものを選択し、これにパラメータとして必要な情報を設定することで生成する。その後、連携部１３は、ステップＳ１０２で生成した画面のＨＴＭＬデータに対して、生成したスクリプトファイルをダウンロードできるようにするためのコントロールやリンクを埋め込む（Ｓ１０４）。これら一連の処理を行うため、連携部１３は、例えば、それ自体がプロジェクト管理システム１２が生成する画面のテンプレートのＨＴＭＬデータの中にプログラムやスクリプトとして埋め込まれる形で実装されていてもよい。
【００３７】
その後、プロジェクト管理システム１２は、スクリプトファイルのダウンロード用のリンク等が埋め込まれた画面をユーザに対して応答し（Ｓ１０５）、ユーザのＷｅｂブラウザ上に当該画面が表示される（Ｓ１０６）。
【００３８】
ユーザは、表示された画面に埋め込まれたスクリプトファイルのダウンロード用のリンク等を選択することで、スクリプトファイルのダウンロードを要求し（Ｓ１０７）、当該要求を受けたプロジェクト管理システム１２は、当該スクリプトファイルをユーザの情報処理端末に送信する（Ｓ１０８）。ユーザは、ダウンロードされたスクリプトファイルを単に実行することで（Ｓ１０９）、詳細な操作方法等を知らなくても、プロジェクト管理システム１２および／またはバージョン管理システム１１に対して所定の処理（例えば、チェックアウトやコミット等）を実行させることができる（Ｓ１１０）。
【００３９】
図１に戻り、ライブラリ管理ＤＢ１６は、上述したライブラリ管理台帳１７を生成するためのモジュール情報の元データを保持するデータストアであり、例えば、ＭｙＳＱＬ（登録商標）等のオープンソースのＤＢＭＳを用いて実装される。ライブラリ管理台帳１７は、ライブラリ管理ＤＢ１６から必要な部分をエクスポートする等により生成することができる。各ユーザは、プロジェクト管理システム１２が提供するＷｅｂインタフェースを介してこれをダウンロードすることでローカル環境で参照することができる。
【００４０】
ライブラリ管理台帳１７に対してローカル環境で最新状況を反映させて更新した場合は、これを例えば上述したスクリプトファイルを実行することなどにより、チーム内構成管理システム１０にアップロードした上で連携部１３によりその内容をバージョン管理システム１１のリポジトリＤＢ１４に反映させることができる。リポジトリＤＢ１４に加えられた更新は、例えば、ＳＶＮのフックスクリプトなど、リポジトリＤＢ１４のイベントをフックする機能によりライブラリ管理ＤＢ１６に随時反映させることができる。
【００４１】
上述したように、本実施の形態では、ライブラリ管理台帳１７を生成するためのモジュール情報をライブラリ管理ＤＢ１６で管理する一方で、ユーザがこれを参照する際のインタフェースとして、従来との連続性や、一覧性、操作性、情報追加の容易性などを考慮して、従来同様にライブラリ管理台帳１７のファイルを継続して使用するものとしている。これに対し、例えば、ユーザがモジュール情報を参照する際のインタフェースとして、ライブラリ管理台帳１７に代えて、もしくはこれに加えて、プロジェクト管理システム１２のＷｅｂインタフェースを介してＷｅｂ上でライブラリ管理ＤＢ１６の内容を直接参照できるようにすることも可能である。
【００４２】
構成管理システム２０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバ、もしくはＰＣ等により実装され、統括ライブラリアン４１が管理する開発対象のソフトウェア全体のモジュール等の構成管理を行う情報処理システムである。構成管理システム２０は、例えば、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で動作するソフトウェアにより実装されるバージョン管理システム２１を有する。また、データベースにより実装されるリポジトリＤＢ２２を有する。
【００４３】
上述したように、本実施の形態では、従来の構成管理との連続性も考慮し、統括ライブラリアン４１が管理する開発対象のソフトウェア全体のモジュールについての構成管理を行うバージョン管理システム２１は、従来同様にＣＶＳ等の既存のバージョン管理ツールを継続して使用するものとするが、チーム内構成管理システム１０のバージョン管理システム１１と併せて、全体としてＳＶＮ等のバージョン管理ツールを統合的に用いることも可能である。
【００４４】
＜業務フロー＞
図４は、本実施の形態における障害や開発案件の発生時の業務フローの例について概要を示した図である。障害や開発案件が発生すると、まず、開発管理者５２もしくはライブラリアン５１が、障害チケットもしくは開発チケットを起票する（Ｓ０１）。その後、開発チームのチームライブラリアン６１は、プロジェクト管理システム１２から通知の電子メールを受け取る等により、チケットが起票されたことを把握すると、当該チケットに対応する修正モジュールを特定し（Ｓ０２）、プロジェクト管理システム１２を介してこれらに対するチェックアウト（払い出し）の申請を行う（Ｓ０３）。
【００４５】
チェックアウト申請を受けた開発管理者５２もしくはライブラリアン５１は、申請対象のモジュールを確認して、チェックアウトの可否を審査する（Ｓ０４）。一方で、開発者６２は、チェックアウトしたモジュールの修正やテストを実施し（Ｓ０５）、完了した場合はコミット（登録）の申請を行う（Ｓ０６）。その後、開発管理者５２もしくはライブラリアン５１は、プロジェクト管理システム１２から通知の電子メールを受け取る等により、コミットの申請がされたことを把握すると、コミット申請に対する審査を行い（Ｓ０７）、その後、モジュールをソフトウェア全体のリポジトリに受け入れるための審査を行う（Ｓ０８）。
【００４６】
＜システム内処理フロー＞
図５、図６は、本実施の形態における障害や開発案件の発生時のシステム内の処理フローの例について概要を示した図である。図５では、障害や開発案件が発生すると、まず、開発管理者５２もしくはライブラリアン５１が、チーム内構成管理システム１０のプロジェクト管理システム１２にアクセスして障害チケットもしくは開発チケットを起票する（Ｓ１１、Ｓ１２）。障害チケット／開発チケットを作成することで、プロジェクトメンバー間で障害／開発の状況を共有することが可能となる。なお、障害／開発チケットを作成すると、バージョン管理システム１１のリポジトリＤＢ１４のサブシステム内連結用ブランチ（図中では「サブ内ブランチ」と記載）に対してモジュールをコミットするために開発者６２が審査用のモジュールを登録する場所となる審査ブランチが自動的に生成される。
【００４７】
その後、チームライブラリアン６１は、プロジェクト管理システム１２から通知の電子メールを受け取る等により、チケットが起票されたことを把握すると、当該チケットに対応する修正モジュールを特定する（Ｓ１３）。
【００４８】
具体的には、チームライブラリアン６１が上記の電子メールに含まれるＵＲＬ（Uniform Resource Locator）を選択することにより、プロジェクト管理システム１２における対象のチケットに係るＷｅｂインタフェース画面を表示させる。当該画面には、自動生成されたダウンロード用のスクリプトファイルのリンク等が埋め込まれており、チームライブラリアン６１は、当該リンク等を指定してスクリプトファイルをダウンロードして実行することで、審査ブランチの内容のコピーをエクスポートしてローカル環境にダウンロードすることができる。これにより、チームライブラリアン６１の作業負荷を大きく低減することができる。チームライブラリアン６１もしくは開発者６２は、ダウンロードした最新モジュールから修正対象のモジュールを特定する。
【００４９】
その後、チームライブラリアン６１は、特定したモジュールをチェックアウト（払い出し）するために、プロジェクト管理システム１２にアクセスしてチェックアウト申請チケットを起票して、チェックアウトの申請を行う（Ｓ１４、Ｓ１５）。具体的には、チームライブラリアン６１がプロジェクト管理システム１２における対象の障害／開発チケットに係るＷｅｂインタフェース画面を表示させ、当該画面からチェックアウト申請を指示する。これにより、チェックアウト申請用の画面が表示されてチェックアウト申請チケットが自動生成されるとともに、チェックアウト申請書のファイルの初期版が自動生成され、ダウンロード可能となる。チェックアウト申請書のファイルは、例えば、表計算ソフトウェアのファイル形式で作成されている。
【００５０】
チェックアウト申請チケットを作成することで、プロジェクトメンバー間でチェックアウトの申請状況を共有することが可能となる。また、チェックアウト申請書の初期版の作成などが自動化されるため、チームライブラリアン６１の作業負荷を大きく低減させることができる。
【００５１】
その後、チームライブラリアン６１は、チェックアウト申請書の初期版をダウンロードして、ステップＳ１３で特定したモジュールの情報を入力して保存し、当該チェックアウト申請書を添付した上で、チェックアウト申請用の画面から申請処理を指示する。これにより、当該チェックアウト申請書がアップロードされるとともに、プロジェクト管理システム１２により、関係者に通知するための電子メールが送信される。
【００５２】
その後、開発管理者５２もしくはライブラリアン５１は、プロジェクト管理システム１２から通知の電子メールを受け取る等により、チェックアウト申請がされたことを把握すると、当該申請に対する審査を行い、承認もしくは差し戻しを行う（Ｓ１６）。具体的には、開発管理者５２もしくはライブラリアン５１が上記の電子メールに添付されているチェックアウト申請書のファイルをダウンロードし、内容を確認する。そして、上記の電子メールに含まれるＵＲＬ等を選択することにより、プロジェクト管理システム１２における対象のチェックアウト申請チケットに係るＷｅｂインタフェース画面を表示させ、承認もしくは差し戻しの指示を行う。
【００５３】
チェックアウト申請がされた旨を電子メールで開発管理者５２もしくはライブラリアン５１に通知したり、開発管理者５２もしくはライブラリアン５１による審査結果をチームライブラリアン６１に自動的に通知したりすることで、審査状況の共有と、効率的なワークフロー処理の実現を図ることができる。
【００５４】
ステップＳ１６でチェックアウトを承認した場合は、ソフトウェア全体を管理している構成管理システム２０のバージョン管理システム２１に対して、対象のモジュールをチェックアウトする（Ｓ１７）。当該処理は、例えば、従来通りに、統括ライブラリアン４１に対して申請書を提出することで、これに基づいて統括ライブラリアン４１が行う。
【００５５】
一方で、チームライブラリアン６１は、ステップＳ１４においてチェックアウト申請を行った後、直ちにチーム内構成管理システム１０のバージョン管理システム１１におけるリポジトリＤＢ１４上の審査ブランチから対象のモジュールをチェックアウトして取得することができる（Ｓ１８）。
【００５６】
具体的には、図３に示したように、プロジェクト管理システム１２における対象のチェックアウト申請チケットに係るＷｅｂインタフェース画面から、スクリプトファイルをダウンロードして実行することで、対象のモジュールをローカル環境にダウンロードすることができる。このように、ステップＳ１６でのチェックアウトの審査結果を待たずに直ちにモジュールの取得を可能とすることで、チェックアウトの審査待ち期間を排除し、効率的な作業を実現することができる。なお、モジュールをチェックアウトした後に、ステップＳ１６においてチェックアウト申請が差し戻された場合は、再度ステップＳ１４のチェックアウト申請の処理から実行することが必要となる。
【００５７】
図６に移り、その後、開発チームにおいて対象のモジュールに対する修正やテストを行い（Ｓ１９）、完了すると、チームライブラリアン６１は、対象のモジュールを審査ブランチに対して登録する（Ｓ２０）。具体的には、プロジェクト管理システム１２が提供するＷｅｂインタフェース画面から、図５のステップＳ１４でのチェックアウト申請時に自動生成されているコミット申請チケットを特定し、当該チケットに添付されている自動生成されたスクリプトファイルをダウンロードして実行することで、対象のモジュールを審査ブランチに対して登録することができる。
【００５８】
その後、チームライブラリアン６１は、対象のモジュールをサブシステム内連結用ブランチに対してコミットするために、プロジェクト管理システム１２にアクセスしてコミット申請チケットを起票して、コミットの申請を行う（Ｓ２１、Ｓ２２）。具体的には、チームライブラリアン６１がプロジェクト管理システム１２が提供するＷｅｂインタフェース画面から、図５のステップＳ１４でのチェックアウト申請時に自動生成されているコミット申請チケットを特定し、これに添付されているコミット申請書の初期版のファイルをダウンロードする。コミット申請書のファイルは、例えば、表計算ソフトウェアのファイル形式で作成されている。
【００５９】
チームライブラリアン６１は、ダウンロードしたコミット申請書のファイルに、コミット対象のモジュールの情報を入力して保存する。その後、当該コミット申請書を添付した上で、コミット申請用の画面から申請処理を指示する。これにより、当該コミット申請書がアップロードされるとともに、プロジェクト管理システム１２により、関係者に通知するための電子メールが送信される。
【００６０】
コミット申請チケットを作成することで、プロジェクトメンバー間でコミットの申請状況を共有することが可能となる。また、審査ブランチに登録するスクリプトファイルの生成や、コミット申請書の初期版などが自動化されるため、チームライブラリアン６１の作業負荷を大きく低減させることができる。
【００６１】
その後、開発管理者５２もしくはライブラリアン５１は、プロジェクト管理システム１２から通知の電子メールを受け取る等により、コミット申請がされたことを把握すると、当該申請に対する審査を行い（Ｓ２３）、承認もしくは差し戻しを行う（Ｓ２４）。具体的には、開発管理者５２もしくはライブラリアン５１が上記の電子メールに含まれるＵＲＬ等を選択することにより、プロジェクト管理システム１２における対象のコミット申請チケットに係るＷｅｂインタフェース画面を表示させ、添付されているコミット申請書のファイルをダウンロードして、内容を確認する。
【００６２】
さらに、添付されているテスト証跡ファイルをダウンロードして、テスト証跡の内容を確認できるようにしてもよい。また、修正前後のモジュールの差分を比較できるようにしてもよい。例えば、コミット申請チケットに係るＷｅｂインタフェース画面から、スクリプトファイルをダウンロードして実行することで、チーム内構成管理システム１０のバージョン管理システム１１が修正前後のモジュールをそれぞれエクスポートしてダウンロードするようにすることができる。その後は、修正前後のモジュールをｄｉｆｆ等の一般的な差分比較ツール等を用いて比較検証することができる。
【００６３】
審査の結果、不備がなければ、開発管理者５２もしくはライブラリアン５１がコミット申請チケットに係るＷｅｂインタフェース画面から承認を指示することで、審査ブランチに対するコミットが行われる。なお、ステップＳ２３、Ｓ２４では、図５のステップＳ１４でのチェックアウト申請単位で、モジュールに対する審査・承認が行われる。
【００６４】
コミット申請がされた旨を電子メールで開発管理者５２もしくはライブラリアン５１に通知したり、開発管理者５２もしくはライブラリアン５１による審査結果をチームライブラリアン６１に自動的に通知したりすることで、審査状況の共有と、効率的なワークフロー処理の実現を図ることができる。また、修正前後のモジュールについて差分を比較するためにエクスポートするスクリプトファイルを自動生成することで、開発管理者５２もしくはライブラリアン５１の作業負荷を大きく低減させることができる。
【００６５】
その後、開発管理者５２もしくはライブラリアン５１は、審査ブランチのモジュールをサブシステム内用連結ブランチにコミットしてもよいかどうかを判断する受け入れ審査を行う（Ｓ２５）。ここでは、図５のステップＳ１１での障害チケットもしくは開発チケットの単位で、モジュールに対する審査・承認が行われる。
【００６６】
具体的には、開発管理者５２もしくはライブラリアン５１が、プロジェクト管理システム１２における受け入れ対象の障害／開発チケットに係るＷｅｂインタフェース画面を表示させ、審査の進捗率が１００％になっている、すなわち、全てのチェックアウト申請チケットおよびコミット申請チケットが承認されていることを確認する。その後、障害／開発チケットに添付されているスクリプトファイルをダウンロードして実行することで、審査ブランチの内容をエクスポートしてローカル環境にコピーし、受け入れ可能であるか否かを審査する。エクスポートするためのスクリプトファイルを自動生成することで、開発管理者５２もしくはライブラリアン５１の作業負荷を大きく低減させることができる。
【００６７】
ステップＳ２５の審査で、受け入れ可能であれば、開発管理者５２もしくはライブラリアン５１が、プロジェクト管理システム１２における対象の障害／開発チケットに係るＷｅｂインタフェース画面から承認を指示することで、プロジェクト管理システム１２において対象の障害／開発チケットが承認されるとともに、審査ブランチからサブシステム内連結用ブランチに対して修正後のモジュールが自動的にコミットされる（Ｓ２６）。その後、開発管理者５２が、ソフトウェア全体を管理している構成管理システム２０のバージョン管理システム２１に対して、対象のモジュールをコミットする（Ｓ２７）。当該処理は、例えば、従来通りに、統括ライブラリアン４１に対して申請書を提出することで、これに基づいて統括ライブラリアン４１が行う。
【００６８】
上述したように、チーム内構成管理システム１０のバージョン管理システム１１のリポジトリＤＢ１４に加えられた更新は、例えば、ＳＶＮのフックスクリプトなど、リポジトリＤＢ１４のイベントをフックする機能によりライブラリ管理ＤＢ１６に随時反映させることができる。そして、ライブラリ管理ＤＢ１６の内容をエクスポートすることで、最新のモジュール情報を有するライブラリ管理台帳１７を作成することができる（Ｓ２８）。作成されたライブラリ管理台帳１７は、例えば、連携部１３によってダウンロード用のスクリプトファイルを生成し、これをプロジェクト管理システム１２が提供するＷｅｂインタフェース画面を介してユーザにダウンロードおよび実行させることでローカル環境に提供することができる。
【００６９】
以上に説明したように、本発明の一実施の形態であるチーム内構成管理システム１０によれば、サブシステムの開発グループ内において、バージョン管理システム１１によるモジュールの管理と、プロジェクト管理システム１２による障害・開発案件における工程管理、ワークフロー管理とを組み合わせて取り入れ、これらの間の連携も含めて、モジュールのチェックアウトからコミット等の一連の作業を可能な限り自動化する。これにより、ライブラリアンにバージョン管理システム１１やプロジェクト管理システム１２についてのスキルや知識を要求せずに、作業負荷を大きく低減することができる。
【００７０】
また、ライブラリ管理台帳１７の生成・更新も自動化するため、各開発チームが常に最新のモジュール情報を把握することができ、申請ミスの低減や情報共有による作業の効率化などが可能となる。
【００７１】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【産業上の利用可能性】
【００７２】
本発明は、大規模な開発プロジェクトなど、複数のチームが開発に携わるプロジェクトに適用するチーム内構成管理システムに利用可能である。
【符号の説明】
【００７３】
１０…チーム内構成管理システム、１１…バージョン管理システム、１２…プロジェクト管理システム、１３…連携部、１４…リポジトリＤＢ、１５…チケット情報ＤＢ、１６…ライブラリ管理ＤＢ、１７…ライブラリ管理台帳、
２０…構成管理システム、２１…バージョン管理システム、２２…リポジトリＤＢ、
３０…ネットワーク、
４１…統括ライブラリアン、
５１…ライブラリアン、５２…開発管理者、
６１…チームライブラリアン、６２…開発者
【図１】
2016076181.tif 000003
【図２】
2016076181.tif 000004
【図３】
2016076181.tif 000005
【図４】
2016076181.tif 000006
【図５】
2016076181.tif 000007
【図６】
2016076181.tif 000008
【図７】
2016076181.tif 000009