(57)【要約】【課題】業務システムの保守作業に際し、プログラムファイルの更新履歴を効率的に管理する。【解決手段】保守支援装置１００は、まず、稼働中の業務システム２００に対する改善要求を受信する。作業者は、開発用端末２０６により、改善要求に対応してプログラムファイルを修正する。修正されたプログラムファイルは修正プログラム保持部１６４に登録される。保守支援装置１００は、修正前後の差分を修正箇所として検出し、改善要求と修正箇所を対応づけて修正箇所保持部１６６に登録する。【選択図】図１
2009169724.tif 000002
【特許請求の範囲】
【請求項１】
業務システムを構成する複数のプログラムの修正およびリリースを担当する開発システムと通信回線を介して接続され、
稼働中の前記業務システムに関する改善要求を外部端末から受信する要求受信部と、
１以上の改善要求それぞれについて、改善要求を一意に識別する要望ＩＤと改善要求の内容を示すテキストデータとを対応づけた改善要求情報を保持する要求保持部と、
前記開発システムに改善要求を送信する要求送信部と、
前記送信された改善要求により修正対象となるプログラムを対象プログラムとして、修正を施された対象プログラムと、その修正の契機となった改善要求の要望ＩＤを前記開発システムから受信する修正受信部と、
前記業務システムを構成するプログラムと同一のプログラムを保持するプログラム保持部と、
受信された修正後の対象プログラムと、保持されている修正前の対象プログラムとの差分を修正箇所として検出する修正箇所検出部と、
前記修正箇所を前記修正の契機となった改善要求の要望ＩＤと対応づけて保持する修正箇所保持部と、
前記改善要求に対する前記修正箇所を参照した管理者から、受信された対象プログラムの修正内容を承認する旨を示す承認入力を検出する承認検出部と、
前記承認入力が検出されたことを条件として、修正後の対象プログラムを承認済みの対象プログラムとして前記プログラム保持部に記録するプログラム更新部と、
前記開発システムにより修正後の対象プログラムをリリースさせるときに前記開発システムから前記対象プログラムを再度受信し、受信された対象プログラムと、保持されている承認済みの対象プログラムの差分を再度検出することにより、前記開発システム側にて前記対象プログラムに未承認の修正が新たに施されていないかを確認する修正確認部と、
前記開発システム側に保持される対象プログラムに未承認の修正がなされていないことを条件として、前記対象プログラムのリリース許可を前記開発システムに通知するリリース許可送信部と、
を備えることを特徴とする保守支援装置。
【請求項２】
前記業務システムは、バージョンによって更新履歴が管理されるシステムであって、
前記改善要求情報に登録されている改善要求のうち、将来バージョンのリリースのために対応しておくべき改善要求の選択を検出するバージョン設定部と、
前記改善要求情報に登録されている改善要求のうち、プログラムの修正により対応済みとなった改善要求について、所定の完了フラグを対応済みに設定する対応状態更新部と、
前記将来バージョンにおいて対応すべき全ての改善要求について完了フラグが対応済みに設定されたとき、前記将来バージョンをリリース可能である旨を管理者に通知するリリース可否通知部と、
を更に備えることを特徴とする請求項１に記載の保守支援装置。
【請求項３】
１以上のバージョンのそれぞれについて、一のバージョンと当該バージョンにより対応済みとなった改善要求の要望ＩＤを対応づけた更新履歴情報を保持する更新履歴保持部と、
前記更新履歴情報を画面表示させる更新履歴表示部と、
を更に備えることを特徴とする請求項２に記載の保守支援装置。
【請求項４】
前記更新履歴情報に示される１以上のバージョンのうち、いずれかのバージョンの選択を検出するバージョン選択部と、
前記改善要求情報と前記更新履歴情報を参照して、前記選択されたバージョンにより対応済みとなった改善要求の内容を示すテキストデータを一覧表示させる要求一覧表示部と、
を更に備えることを特徴とする請求項３に記載の保守支援装置。
【請求項５】
前記選択されたバージョンに対応して一覧表示される１以上の改善要求のうち、いずれかの改善要求の選択を検出する改善要求選択部と、
前記選択された改善要求に対応して修正されたプログラムのプログラムＩＤを一覧表示させるプログラム一覧表示部と、
を更に備えることを特徴とする請求項４に記載の保守支援装置。
【請求項６】
前記選択された改善要求に対応して一覧表示される１以上のプログラムＩＤのうち、いずれかのプログラムＩＤの選択を検出するプログラム選択部と、
前記選択されたプログラムＩＤにより特定されるプログラムについて、前記選択された改善要求に対応する修正箇所をそれ以外の箇所と識別可能な態様にて画面表示させる修正箇所表示部と、
を更に備えることを特徴とする請求項５に記載の保守支援装置。
【請求項７】
稼働中の業務システムの改善要求を受信する要求受信部と、
１以上の改善要求のそれぞれについて、改善要求を一意に識別する要望ＩＤと改善要求の内容を示すテキストデータとを対応づけた改善要求情報を保持する要求保持部と、
前記改善要求情報に登録されているいずれかの改善要求に対応して、前記業務システムを構成する複数のプログラムのうちの１以上のプログラムを対象として修正を施したプログラムおよび要望ＩＤを外部装置から受信する修正受信部と、
前記複数のプログラムのうち前記修正の対象となったプログラムについて、前記修正を施した後のプログラムと前記修正を施す前のプログラムとの差分を修正箇所として検出する修正箇所検出部と、
前記修正箇所をその修正の契機となった改善要求の要望ＩＤと対応づけて保持する修正箇所保持部と、
を備えることを特徴とする保守支援装置。
【請求項８】
稼働中の業務システムに関する改善要求を受信する機能と、
１以上の改善要求それぞれについて、改善要求を一意に識別する要望ＩＤと改善要求の内容を示すテキストデータとを対応づけた改善要求情報を保持する機能と、
前記業務システムを構成する複数のプログラムの修正およびリリースを担当する開発システムに対して、改善要求を送信する機能と、
前記送信された改善要求に対応して修正の対象となるプログラムを対象プログラムとして、修正が施された対象プログラムと、その修正の契機となった改善要求の要望ＩＤを前記開発システムから受信する機能と、
前記業務システムを構成するプログラムと同一のプログラムを保持する機能と、
受信された修正後の対象プログラムと、保持されている修正前の対象プログラムとの差分を修正箇所として検出する機能と、
前記修正箇所を前記修正の契機となった改善要求の要望ＩＤと対応づけて保持する機能と、
前記改善要求に対する前記修正箇所を参照した管理者から、受信された対象プログラムの修正内容を承認する旨を示す承認入力を検出する機能と、
前記承認入力が検出されたことを条件として、修正後の対象プログラムを承認済みの対象プログラムとして保持する機能と、
前記開発システムにより修正後の対象プログラムをリリースさせるときに前記開発システムから前記対象プログラムを再度受信し、受信された対象プログラムと、保持されている承認済みの対象プログラムの差分を再度検出することにより、前記開発システム側にて前記対象プログラムに未承認の修正が新たに施されていないか確認する機能と、
前記開発システム側に保持される対象プログラムに未承認の修正がなされていないことを条件として、前記対象プログラムのリリース許可を前記開発システムに通知する機能と、
をコンピュータに発揮させることを特徴とする保守支援プログラム。
【請求項９】
稼働中の業務システムの改善要求を受信する機能と、
１以上の改善要求のそれぞれについて、改善要求を一意に識別する要望ＩＤと改善要求の内容を示すテキストデータとを対応づけた改善要求情報を保持する機能と、
前記改善要求情報に登録されているいずれかの改善要求に対応して、前記業務システムを構成する複数のプログラムのうちの１以上のプログラムを対象として修正を施したプログラムおよび要望ＩＤを外部装置から受信する機能と、
前記複数のプログラムのうち前記修正の対象となったプログラムについて、前記修正を施した後のプログラムと前記修正を施す前のプログラムとの差分を修正箇所として検出する機能と、
前記修正箇所をその修正の契機となった改善要求の要望ＩＤと対応づけて保持する機能と、
をコンピュータに発揮させることを特徴とする保守支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、業務システムの保守、特に、業務システムを構成するファイルの更新履歴を管理するための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤として導入されている。業務システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力する。業務システムを構成するプログラムファイルの数は、数十万、時には数百万にも及ぶことがある。業務システムは複雑化する組織マネジメントをより効率化するために発展を続けている。
【０００３】
このような業務システムは、長年にわたって稼働を続けるため、稼働後も、動作監視、障害対応、機能の拡張・変更・廃止といったさまざまな保守作業を必要とする。
【特許文献１】特開２００７−２６５０２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
保守作業に際しては、どのようなタイミングでどのプログラムファイルのどのコードを修正したか、また、何のために修正したのかといった更新履歴の管理が重要となる。一般的には、なんらかの改善要求が提案され、作業者がプログラムファイルを修正すると、管理者が修正前のプログラムファイルと修正後のプログラムファイルの差分を抽出する。そして、改善要求とは関係のないコードが紛れ込んでいないことを確認した上で、修正後のプログラムファイルを新バージョンとしてリリースする。また、各リリース時にどのような修正がなされたかを記録しておく。
しかし、業務システムに含まれるプログラムファイルの数が増加するにつれて、プログラムファイルの更新履歴を正確に管理するための作業負荷は膨大なものとなりつつある。
【０００５】
更に、近年では、中国・台湾・インド・ロシア等、海外のプログラマに保守作業を委託することも多い。言語やスキルといったバックグラウンドが異なる多くのプログラマが保守作業に関わるほど、保守作業中にどのようなコードが追加されたかを、いっそう厳密かつ効率的に管理するための仕組みが必要とされてきている。
【０００６】
本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、業務システムの保守作業に際し、プログラムファイルの更新履歴を効率的に管理するための技術、を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のある態様は、保守支援装置に関する。
この装置は、まず、稼働中の業務システムに対する改善要求を受信する。いずれかの改善要求に対応して、いずれかのプログラムに修正が施されると、修正後のプログラムと修正前のプログラムとの差分を修正箇所として検出し、修正箇所をその修正の契機となった改善要求と対応づけて保持する。
【０００８】
なお、以上に示した構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、業務システムの保守作業に際し、プログラムファイルの更新履歴を管理しやすくなる。
【発明を実施するための最良の形態】
【００１０】
図１は、業務システム２００と保守支援装置１００、開発システム２５０の関係を示すハードウェア構成図である。
ここに示す業務システム２００は、企業や公共施設のような組織の業務管理のために導入されるシステムである。業務システム２００は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。ここでは、インターネット証券会社の業務システムを例として説明する。
【００１１】
業務システム２００はイントラネット等を介して従業員端末２０２ａ、２０２ｂ、・・・２０２ｃ（以下、単に「従業員端末２０２」とよぶ）と接続される。従業員端末２０２は、インターネット証券会社の従業員が使用する端末である。各従業員は、従業員端末２０２を介して業務システム２００にアクセスし、日常業務を遂行する。従業員に限らず、管理会社の作業員等も従業員端末２０２を操作してもよいが、説明を簡単にするため、本実施例においては従業員のみが従業員端末２０２を使用するものとして説明する。
【００１２】
業務システム２００はインターネット等を介して開発システム２５０とも接続される。開発システム２５０は、業務システム２００を構成するプログラムの修正や更新（リリース）を担当する。開発システム２５０は、開発用端末２０６ａ、２０６ｂ、・・・２０６ｃ（以下、単に「開発用端末２０６」とよぶ）、リリース版保持部２５２、修正プログラム保持部２５４を含む。開発用端末２０６は、業務システム２００の保守作業を行う作業者、たとえば、外部の保守管理会社のプログラマが使用する端末である。近年では、多くのシステム・インテグレータがいわゆるオフショア開発（offshore development）を推進している。このため、ここでいう作業者は、国内に限らず国外のプログラマも想定される。リリース版保持部２５２は、現行の業務システム２００を構成するプログラムと同じプログラム、すなわち、リリース版のプログラムを保持する。修正プログラム保持部２５４は、リリース版のプログラムに必要な修正を施したプログラムであって、将来的にリリースされる予定のプログラムを保持する。
【００１３】
開発システム２５０は、専用線等を介して保守支援装置１００と接続される。保守支援装置１００は、業務システム２００の保守作業を支援するための装置である。保守支援装置１００は、業務システム２００を構成するプログラムファイルの更新履歴を効率的に管理するために導入される。保守支援装置１００は、専用線等を介して管理者端末２０４とも接続される。管理者端末２０４は、業務システム２００の管理者が使用する端末である。管理者は、管理者端末２０４を介して保守支援装置１００にアクセスし、作業者による保守作業を統括する。本実施例における保守支援装置１００は、管理者端末２０４を介して操作される。
【００１４】
保守支援装置１００は、要求保持部１６２、修正プログラム保持部１６４、修正箇所保持部１６６、更新履歴保持部１６８およびリリース版保持部１６９を含む。本実施例において保守作業に関わるのは、従業員、作業者および管理者である。保守支援装置１００の具体的な機能を説明する前に、まず、本実施例における保守作業の流れを概観する。
【００１５】
Ｒ１：従業員は、従業員端末２０２を介して業務システム２００を日常的に使用する。
【００１６】
Ｒ２：従業員は、業務システム２００の使用に際し、業務システム２００について改善すべき点を管理者に通知する。不具合の指摘であってもよいし、ユーザインタフェースなどの改善提案、トレーリング・ストップ等の機能追加の提案であってもよい。この通知は、従業員端末２０２から管理者端末２０４に対して電子メール等の既知の通信手段により通知されればよい。以下、Ｒ２における改善すべき点の通知のことを「改善要求」とよぶ。改善要求に際しては、従業員名や提案日時、緊急度等の各種付随情報も併せて通知されてもよい。
【００１７】
Ｒ３：管理者は、従業員から受信した改善要求を保守支援装置１００に送信する。管理者端末２０４から送信された改善要求は、保守支援装置１００の要求保持部１６２に登録される。なお、要求保持部１６２に改善要求が登録されるとき、改善要求を一意に識別するためのＩＤとして「要望ＩＤ」が割り当てられる。要求保持部１６２に登録された改善要求は開発用端末２０６にて一覧表示される。具体的な表示態様については、図３の改善要求一覧画面１７０に関連して後述する。
【００１８】
Ｒ４：作業者は、改善要求一覧画面１７０を参照し、プログラムファイルの修正を開始することになる。まず、作業者は、リリース版保持部２５２から、リリース版と同じプログラムファイルを取得する。作業者は、開発用端末２０６において、取得したプログラムファイルに必要な修正を施す。こうして、Ｒ２で発生した改善要求に対する具体的な対応がなされる。１つの改善要求に対し、必要であれば、複数のプログラムファイルが修正されることもある。作業者は、修正後のプログラムファイル（以下、「修正版プログラム」とよび、修正がなされる前のプログラムファイルを「未修正プログラム」とよぶ）を単体でテスト実行し、動作確認をした上で、修正プログラム保持部２５４に登録する。作業者は、どの改善要求に対する修正であるかを明示するために、修正版プログラムと要望ＩＤを対応づけて登録する。この修正版プログラムを正式にリリースするためには、更に、管理者による結合テスト、総合テストといった各種動作テストを受け、管理者による修正内容の承認を受けなければならない。ここでは、あるプログラムＡが修正されたとする。
【００１９】
Ｒ５：修正プログラム保持部２５４に登録された修正版プログラムＡは、要望ＩＤと共に保守支援装置１００に送信される。この修正版プログラムＡは、保守支援装置１００の修正プログラム保持部１６４に要望ＩＤと共に登録される。ここで、保守支援装置１００のリリース版保持部１６９も、開発システム２５０のリリース版保持部２５２と同じく、リリース版と同じプログラムファイルを保持している。保守支援装置１００は、未修正プログラムＡ、すなわち、リリース版保持部１６９に保持されているプログラムＡと、修正プログラム保持部１６４に新たに登録された修正版プログラムＡとの差分を修正箇所として検出する。このときの修正箇所を「ａ」とする。この修正箇所ａは、要望ＩＤと対応づけられて保守支援装置１００の修正箇所保持部１６６に登録される。こうして、要望ＩＤをキーとして、改善要求に対してどのプログラムが修正され、更に、プログラムのどの部分が修正されたかが対応づけられることになる。
【００２０】
Ｒ６：管理者は、プログラムＡの修正箇所ａと提案された改善要求を参照して、必要かつ無駄のない修正がなされているかを画面上にて確認する。管理者は、結合テストや総合テストとよばれる各種動作テストを実行し、修正版プログラムＡについて動作確認する。修正内容の妥当性を確認すると、管理者は管理者端末２０４を介して承認の旨を入力する（以下、このような入力のことを「承認入力」とよぶ）。各改善要求には完了フラグが対応づけられており、承認入力がなされたとき、完了フラグは「対応済み」に設定変更される。この完了フラグにより、未対応の改善要求と対応済みの改善要求が区別される。こうして、開発システム２５０側にて修正された修正版プログラムＡにおいて、修正箇所ａの修正内容が管理者に承認されたことになる。
【００２１】
修正版プログラムＡを正式にリリースする際には、保守支援装置１００は、開発システム２５０側の修正版プログラムＡと、保守支援装置１００側の承認済みの修正版プログラムＡの内容が一致しているか確認する。通常は一致するが、Ｒ５において、開発システム２５０から保守支援装置１００に修正版プログラムＡをアップロードしたあと、作業者が修正プログラム保持部２５４の修正版プログラムＡに更に修正ｂを施しているかもしれない。もし、このような確認を行わずにリリースを許可するとすれば、管理者の関知していない修正ｂが業務システム２００に反映されてしまう。このような不都合を回避するために、リリース前の最終チェックとして、開発システム２５０の修正プログラム保持部２５４にある修正版プログラムＡが、保守支援装置１００の修正プログラム保持部１６４にある修正版プログラムＡと同一内容であることを確認する必要がある。開発システム２５０側の修正版プログラムＡと、保守支援装置１００側の修正版プログラムＡが一致していれば、少なくともコードの実質的な変更がなければ、保守支援装置１００は修正版プログラムＡのリリース許可を開発システム２５０に通知する。
【００２２】
Ｒ７：開発システム２５０は、保守支援装置１００からリリース許可通知を受けたことを条件として、自ら修正プログラム保持部２５４に保持する修正版プログラムＡをリリース版保持部２５２に登録する。リリース版保持部２５２に新たに登録されたプログラムＡは、業務システム２００を構成する正式なプログラムとして反映される。
こうして、業務現場から挙がってきた改善要求が業務システム２００の機能として反映されることになる。
【００２３】
図２は、保守支援装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００２４】
保守支援装置１００は、ユーザインタフェース処理部１１０、データ処理部１５０およびデータ保持部１６０を含む。
ユーザインタフェース処理部１１０は、作業者や管理者等（以下、単に「ユーザ」とよぶ）とのユーザインタフェース処理を担当する。ユーザインタフェース処理部１１０は、管理者端末２０４や開発用端末２０６にウェブページ形式にて各種画面を表示させる。データ処理部１５０は、ユーザインタフェース処理部１１０やデータ保持部１６０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１５０は、ユーザインタフェース処理部１１０とデータ保持部１６０との間のインタフェースの役割も果たす。データ保持部１６０は、各種データを保持するための記憶領域である。
【００２５】
ユーザインタフェース処理部１１０：
ユーザインタフェース処理部１１０は、入力部１１２と通知部１３０を含む。入力部１１２は、管理者端末２０４や開発用端末２０６に対するユーザの各種入力を検出する。通知部１３０は、管理者端末２０４や開発用端末２０６に対して各種情報を表示する。
【００２６】
入力部１１２は、要求受信部１１４、修正受信部１１６、承認検出部１１８、バージョン設定部１２０および選択部１２２を含む。
要求受信部１１４は、Ｒ３に関連して管理者端末２０４から改善要求を受信する。改善要求には、改善要求の内容を示すテキストデータのほかにも、提案元の従業員名や緊急度、重要度、提案日等の付随的な情報が含まれてもよい。改善要求は、要望ＩＤと対応づけられて要求保持部１６２に登録される。修正受信部１１６は、Ｒ５に関連して、要望ＩＤと修正版プログラムを開発システム２５０から受信する。修正版プログラムは、要望ＩＤと対応づけられて修正プログラム保持部１６４に登録される。承認検出部１１８は、管理者の承認入力を検出する。業務システム２００は、バージョンによって更新履歴を管理される。バージョン設定部１２０は、将来バージョンと、そのバージョンをリリースするために対応すべき改善要求との関係を設定するための管理者による入力を検出する。バージョン設定については図４のバージョン設定画面１８０に関連して後述する。
【００２７】
選択部１２２は、業務システム２００のバージョンの更新履歴を確認するためのユーザによる各種入力を検出する。選択部１２２は、バージョン選択部１２４、要求選択部１２６およびプログラム選択部１２８を含む。バージョン選択部１２４については図６のバージョン選択画面１９０におけるバージョンの選択、要求選択部１２６は図７の要求選択画面２１０における改善要求の選択、プログラム選択部１２８は図８のプログラム選択画面２２０におけるプログラムの選択をそれぞれ検出する。詳しくは後述する。
【００２８】
通知部１３０は、リリース可否通知部１３２、履歴表示部１３４および改善要求表示部１４４を含む。
リリース可否通知部１３２は、新バージョンのリリースが可能な状態となったとき、その旨を管理者に通知する。リリース可否は、図４のバージョン設定画面１８０における管理者の設定内容にしたがって判定される。履歴表示部１３４は、図６から図９に関連して説明する各種画面を表示させる。履歴表示部１３４は、更新履歴表示部１３６、要求一覧表示部１３８、プログラム一覧表示部１４０および修正箇所表示部１４２を含む。更新履歴表示部１３６は図６に示すバージョン選択画面１９０、要求一覧表示部１３８は図７に示す要求選択画面２１０、プログラム一覧表示部１４０は図８に示すプログラム選択画面２２０、修正箇所表示部１４２は図９に示す修正コード画面２３０をそれぞれ表示させる。改善要求表示部１４４は、次の図３に示す改善要求一覧画面１７０を表示させる。
【００２９】
データ処理部１５０：
データ処理部１５０は、登録部１５２、対応状態更新部１５４、修正箇所検出部１５６、プログラム更新部１５１、修正確認部１５３およびリリース許可送信部１５８を含む。
登録部１５２は、改善要求や修正版プログラムが受信されたとき、これらを要求保持部１６２や修正プログラム保持部１６４に登録する。また、業務システム２００の新バージョンがリリースされるごとに、更新履歴保持部１６８の更新履歴情報を更新する。対応状態更新部１５４は、承認入力が検出されたとき、該当する改善要求の完了フラグを「対応済」に設定する。修正箇所検出部１５６は、修正版プログラムと未修正プログラムの差分を修正箇所として検出し、要望ＩＤとその修正箇所を対応づけて修正箇所保持部１６６に登録する。プログラム更新部１５１は、承認入力が検出されたとき、承認された修正版プログラムをリリース版保持部１６９に記録する。修正確認部１５３は、Ｒ６に関連し、開発システム２５０側の修正版プログラムと保守支援装置１００側の修正版プログラムの内容が一致しているかを判定する。リリース許可送信部１５８は、管理者による承認がなされ、かつ、開発システム２５０側と保守支援装置１００側にて修正版プログラムの内容が一致していることを条件として、リリース許可通知を開発システム２５０に送信する。
本実施例に示す業務システム２００の場合、複数の改善要求に対して、複数の開発者により同時並行的な対応がなされることがある。この場合、ある改善要求ｒ１への対応として管理者が妥当と判断した修正版プログラムが、その後、別の改善要求ｒ２への対応のために更なる修正を受けてしまうことがある。このような理由から、リリース許可送信部１５８は、管理者による承認だけではなく、リリースのタイミングにて、開発システム２５０側と保守支援装置１００側での修正版プログラムの内容が一致していることを確認している。リリース許可通知には、要望ＩＤやプログラムＩＤ等が含まれる。開発システム２５０は、このリリース許可通知を受けたことを条件として、自らの修正プログラム保持部２５４に保持する修正版プログラムをリリースできる。
【００３０】
データ保持部１６０：
データ保持部１６０は、要求保持部１６２、修正プログラム保持部１６４、修正箇所保持部１６６、更新履歴保持部１６８およびリリース版保持部１６９を含む。要求保持部１６２は要望ＩＤと改善要求の内容を対応づけて保持する。修正プログラム保持部１６４は要望ＩＤと修正版プログラムとを対応づけて保持する。修正箇所保持部１６６は、要望ＩＤと修正版プログラムの「プログラムＩＤ」およびその修正箇所を対応づけて保持する。ここでいうプログラムＩＤとは、プログラムのタイトル名やその所在を示す絶対パスなど、プログラムファイルを一意に識別できるデータであればよい。更新履歴保持部１６８は、業務システム２００の各バージョンの更新履歴情報を保持する。リリース版保持部１６９は、業務システム２００を構成するプログラムと同一のプログラムを保持する。
【００３１】
図３は、改善要求一覧画面１７０の画面図である。
管理者端末２０４に改善要求に通知されると（Ｒ２）、管理者はこれらの改善要求を取捨選択して、保守支援装置１００に送信する。なお、管理者端末２０４から保守支援装置１００に直接改善要求を登録できてもよい。保守支援装置１００の要求受信部１１４は、管理者端末２０４から改善要求を受信する（Ｒ３）。保守支援装置１００の登録部１５２は、受信された改善要求に要望ＩＤを付与して、要求保持部１６２に登録する。保守支援装置１００の改善要求表示部１４４は、こうして要求保持部１６２に蓄積された各種改善要求を改善要求一覧画面１７０として管理者端末２０４や開発用端末２０６等の外部端末に表示させる。
【００３２】
要求ＩＤ欄１７２は要望ＩＤを示す。概要欄１７４は改善要求の内容を示す。いずれかの改善要求を選択して該当する概要欄１７４をクリックすると、改善要求の具体的な内容を示すテキストデータが表示される。このほかにも、提案者名や提案日、提案者のメールアドレス等の各種関連情報が表示されてもよい。緊急度欄１７６は改善要求の緊急度を示す。緊急度は提案者が設定してもよいし、管理者が設定してもよい。対応状況欄１７８は完了フラグの状態を示す。対応済みの改善要求は「済」、未対応の場合は「未」と表示される。改善要求一覧画面１７０に示される情報は、主として、要求保持部１６２に保持される情報である。
作業者は、開発用端末２０６を介して保守支援装置１００にアクセスすることにより、現時点でどのような改善要求が挙がってきているか、また、その対応がどういう状況にあるかを確認できる。
【００３３】
図４は、バージョン設定画面１８０の画面図である。
通常、業務システム２００の稼働中においては従業員から次々と新しい改善要求が挙がってくる。たとえば、１０個の改善要求が提案されているとき、これら１０個の改善要求への対応が完了してから次のバージョンをリリースしてもよいが、１０個の改善要求への対応が完了したときには更に新たな改善要求が提案されているかもしれない。そこで、管理者は、現在提案されている改善要求のうち、次期バージョンまでに対応すべき改善要求をあらかじめ設定しておく。たとえば、上記例の場合、１０個の改善要求のうちの７つの改善要求に対する対応が完了した時点で次のバージョンをリリースすると設定してもよい。
【００３４】
管理者は、保守支援装置１００にアクセスし、バージョン設定画面１８０を管理者端末２０４に表示させる。ここでは、現在の業務システム２００のバージョンが「２．８０」であるとする。管理者はバージョン設定領域１８２において、将来のリリースバージョンを設定する。ここでは、「２．８１」と設定されている。要求ＩＤ指定領域１８４は、バージョン２．８１のリリースのために対応すべき改善要求（以下、「必須要求」とよぶ）の要求ＩＤを指定するための領域である。同図では、要望ＩＤ＝０４、０５、２０の３つの改善要求が必須要求として設定されている。このため、要望ＩＤ＝０４の改善要求（以下、「改善要求（０４）」のように表記する）、改善要求（０５）、改善要求（２０）が解決されれば、バージョン２．８１にバージョンアップ可能となる。対応状況領域１８６は、各必須要求の対応状況を示す。対応状況領域１８６は図３の対応状況欄１７８に対応する。同図の対応状況領域１８６によれば、３つの必須要求のうち必須要求（０４）については既に対応済みであるが、残りの２つの必須要求は未対応である。
【００３５】
ここで、作業者が、必須要求（０５）に対応した修正版プログラムを開発システム２５０から保守支援装置１００にアップロードしたとする。管理者は、図９の修正コード画面２３０などのユーザインタフェースを介して、必須要求（０５）に対する修正が正当であることを確認すると、承認入力を行う。保守支援装置１００の対応状態更新部１５４は、要望ＩＤ＝０５について完了フラグを「対応済み」に設定変更する。完了フラグの設定変更に連動して、改善要求一覧画面１７０の対応状況欄１７８や、バージョン設定画面１８０の対応状況領域１８６も更新される。
【００３６】
リリース可否通知部１３２は、要望ＩＤ＝０４、０５、２０の３つの必須要求全ての完了フラグが「対応済み」となると、バージョン２．８１がリリース可能な状態にある旨を管理者に通知する。このとき、登録部１５２は、バージョン２．８１において対応済みとなった改善要求として、要望ＩＤ＝０４、０５、２０をバージョン２．８１と対応づけて更新履歴保持部１６８に記録する。また、登録部１５２は、バージョン２．８１のリリース時において、未対応のまま持ち越されている改善要求の要求ＩＤもバージョン２．８１と対応づけて更新履歴保持部１６８に記録する。すなわち、更新履歴情報においては、バージョン、当該バージョンにおいて対応済みとなった改善要求の要望ＩＤ、当該バージョンのリリース時において未対応のまま残っている改善要求の要望ＩＤが対応づけられる。
なお、バージョン２．８１は、既に述べたように修正確認部１５３による修正内容の最終チェックを経た上で、リリースされる。
【００３７】
図５は、改善要求に対するソースコードの修正箇所を特定する方法について説明するための模式図である。
ここでは、要望ＩＤと修正箇所の対応づけについて説明する。例として、改善要求（２０）に対応するため、「program4」、「program10」、「program12」の３つのプログラムが修正されたとする。３つの修正版プログラムは、要望ＩＤ＝２０を指定した上で、開発システム２５０から保守支援装置１００に送信される。保守支援装置１００の登録部１５２は、要望ＩＤ＝２０と３つの修正版プログラムを対応づけて修正プログラム保持部１６４に登録する。
【００３８】
修正箇所検出部１５６は、リリース版保持部１６９から、現在のリリース・バージョン２．８０と同じプログラム「program4」、「program10」、「program12」を取得する。修正箇所検出部１５６は、修正版プログラム「program4」とバージョン２．８０の未修正プログラム「program4」の差分を修正箇所１８８ａとして検出する。差分は、既存のアルゴリズム、たとえば、UNIX（登録商標）の「diff」コマンドと同等のアルゴリズムにより検出されればよい。同様にして、修正箇所検出部１５６は「program10」について修正箇所１８８ｂ、「program12」について修正箇所１８８ｄ、１８８ｅを検出する。
【００３９】
登録部１５２は、要望ＩＤ＝２０に対して、「program4」のプログラムＩＤおよび修正箇所１８８ａを対応づけて修正箇所保持部１６６に記録する。ここでいう修正箇所とは、たとえば、プログラムファイル中における修正箇所の範囲を行番号や列番号により示す値である。同様に、登録部１５２は、要望ＩＤ＝２０に対して「program10」および修正箇所１８８ｂ、「program12」および修正箇所１８８ｃ、１８８ｄを対応づけて修正箇所保持部１６６に記録する。
こうして、修正箇所保持部１６６においては、要望ＩＤとプログラムＩＤおよび修正箇所が対応づけられて保持される。
【００４０】
管理者は、図３の改善要求一覧画面１７０、図４のバージョン設定画面１８０および図９の修正コード画面２３０等を参照し、改善要求（２０）に対応づけられる修正コードの正当性を確認すると、承認入力する。必要であれば、修正版プログラム単体をテスト実行してみてもよい。
【００４１】
図６は、バージョン選択画面１９０の画面図である。
必須要求全てへの対応が完了すると、次期バージョンがリリース可能となる。改善要求のアップロード、改善要求に対応した修正版プログラムの保守支援装置１００へのアップロード、管理者による修正内容の確認、修正確認部１５３によるリリース前の最終チェック、新バージョンのリリースという各プロセスは、同時並列的に実行される。このため、あるバージョンがリリースされたときには、そのバージョンによって解決した改善要求もあれば、リリース時においても未解決のまま持ち越しとなっている改善要求もある。バージョン選択画面１９０は、各バージョンについて、当該バージョンにより解決した改善要求と当該バージョンのリリース時において未解決のまま残っている改善要求の比率を示す。
【００４２】
保守支援装置１００の更新履歴表示部１３６は、外部端末にバージョン選択画面１９０を表示させる。更新履歴表示部１３６は、更新履歴保持部１６８を参照し、バージョンごとに、当該バージョンにおいて対応済みとなった改善要求の要望ＩＤ、当該バージョンのリリース時において未対応のまま残っている改善要求の要望ＩＤを検出し、バージョン選択画面１９０を形成する。
【００４３】
同図においては、バージョン２．７４のリリース日は「２００７年１０月１５日」であり、バージョン２．７４により解決された改善要求の数は９６個である。また、バージョン２．７４をリリースしたときには、１１個の改善要求が未解決のまま残っていたことになる。次のバージョン２．７５は２００７年１０月２８日にリリースされている。バージョン２．７５により解決された改善要求数は１４９個となっている。すなわち、バージョン２．７４がリリースされた後にも多くの改善要求が提案され、かつ、バージョン２．７５においてその多くが解決されたことがわかる。
【００４４】
バージョン選択画面１９０によれば、ユーザは業務システム２００の各バージョンにおいて改善要求をどの程度解決したか、また、どの程度残したままリリースされているかを一画面にて確認できる。ここでは、バージョン２．７４から２．７６までの既にリリースされたバージョンについての情報を示しているが、まだリリースされていない将来バージョンについての情報も同様の形式にて表示される。たとえば、まだリリースされていないバージョン２．８１について、解決済みの必須要求数、未解決の必須要求数、解決済みの改善要求数、未解決の改善要求数等の比率をグラフ表示してもよい。
【００４５】
ユーザが、いずれかのバージョンをクリックすると、保守支援装置１００のバージョン選択部１２４は、そのバージョンが選択されたものとして検出する。ここでは、バージョン２．７６が選択されたとする。
【００４６】
図７は、要求選択画面２１０の画面図である。
バージョン選択画面１９０においてバージョン２．７６が選択されると、要求一覧表示部１３８はバージョン２．７６において解決された改善要求の一覧を示す要求選択画面２１０を表示させる。要望ＩＤ欄１９１は要望ＩＤを示す。概要欄１９２は改善要求の概要を示す。緊急度欄１９４は改善要求の緊急度を示す。要望ＩＤ欄１９１、概要欄１９２、緊急度欄１９４は、それぞれ図３の改善要求一覧画面１７０における要求ＩＤ欄１７２、概要欄１７４および緊急度欄１７６に対応する。完了日欄１９６は、改善要求への対応を管理者が承認した年月日を示す。
要求選択画面２１０によれば、ユーザは業務システム２００の各バージョンにおいて、どのような改善要求が解決されたのかを一画面にて確認できる。
【００４７】
ユーザが、いずれかの改善要求をクリックすると、保守支援装置１００の要求選択部１２６は、その改善要求が選択されたものとして検出する。ここでは、改善要求（２６）が選択されたとする。
【００４８】
図８は、プログラム選択画面２２０の画面図である。
要求選択画面２１０において改善要求（２６）が選択されると、プログラム一覧表示部１４０は改善要求（２６）に関連して修正されたプログラムの一覧を示すプログラム選択画面２２０を表示させる。要求詳細領域２４０には、改善要求（２６）に関する詳細な情報が表示される。要求詳細領域２４０においては、たとえば、改善要求の要望ＩＤ＝２６、改善要求の提案者や、提案日、緊急度、改善要求への対応を確認した管理者、確認日、更には、改善要求の具体的な内容を示すテキスト等が示される。
【００４９】
修正リスト欄２４２は、改善要求（２６）に関連して修正されたプログラムのプログラムＩＤを示す。同図の場合、プログラムＩＤとは各プログラムの所在を示す絶対パスである。同図の修正リスト欄２４２によれば、改善要求（２６）に対応するために、「program18」と「program24」の２つのプログラムが修正されたことがわかる。修正プログラム保持部１６４に保持される情報により、改善要求（２６）に関連して修正されたプログラムのプログラムＩＤを特定できる。
プログラム選択画面２２０によれば、ユーザは、各バージョンの各改善要求について、どのプログラムが修正の対象となったのかを一画面にて確認できる。
【００５０】
ユーザが、修正リスト欄２４２からいずれかのプログラムＩＤをクリックすると、保守支援装置１００のプログラム選択部１２８は、そのプログラムが選択されたものとして検出する。ここでは、「program18」が選択されたとする。
【００５１】
図９は、修正コード画面２３０の画面図である。
プログラム選択画面２２０において「program18」が選択されると、修正箇所表示部１４２は「program18」のうち、バージョン２．７６のリリースに際して修正された「program18」のソースコードを示す修正コード画面２３０を表示させる。修正箇所表示部１４２は、修正箇所保持部１６６において、要望ＩＤ＝２０に対応づけられている「program18」の修正箇所１８８を特定する。この修正箇所１８８は、バージョン２．７５における「program18」とバージョン２．７６における「program18」の差分にほかならない。修正箇所表示部１４２は、修正箇所１８８を他の箇所と識別可能となるように異なる表示態様にて表示させる。たとえば、修正箇所１８８の部分だけ文字サイズや文字の色、背景色、フォント等を変更してもよいし、修正箇所１８８の部分だけアンダーライン等の文字飾りをつけてもよい。このように、ユーザが一目で修正箇所１８８を特定できるように、修正箇所１８８を強調表示させることが望ましい。
修正コード画面２３０によれば、ユーザは、各バージョンの各改善要求に対応する各修正版プログラムについて、どの部分が修正されたかを確認できる。
【００５２】
図６から図９においては、リリース済みのバージョンを対象として修正箇所等を確認する態様について説明したが、未リリースのバージョンを対象とする場合も同じである。たとえば、バージョン選択画面１９０にて未リリースのバージョン２．８１を選択すると、要求選択画面２１０にてバージョン２．８１の必須要求およびバージョン２．８１以降に解決された改善要求が一覧表示される。たとえば、ここで必須要求（２０）が選択されると、プログラム選択画面２２０においては必須要求（２０）について修正されたプログラムが一覧表示される。そして、いずれかのプログラムを選択すると、修正コード画面２３０にて修正箇所が強調表示される。管理者は、強調表示された部分が必須要求の内容に対応していることを確認すると、対応確認入力を実行する。
【００５３】
また、バージョン単位ではなく改善要求単位にてリリース内容を制御してもよい。たとえば、バージョン２．７８の必須要求Ａによりトレーリング・ストップ機能、必須要求Ｂによりリレー注文機能が搭載されたとする。ここで、証券会社Ｐに納入する業務システム２００には、トレーリング・ストップ機能とリレー注文機能の両方が必要であるとする。一方、証券会社Ｑに納入する業務システム２００は、トレーリング・ストップ機能のみ必要であるとする。この場合には、証券会社Ａにはバージョン２．７８以降のプログラムをリリースすればよい。一方、証券会社Ｂにはバージョン２．７７をリリースした上で、必須要求Ａに対応した修正内容だけを反映させればよい。このため、顧客に応じて搭載すべき機能を比較的簡易に選択できる。
【００５４】
図１０は、次期バージョンをリリースするまでの処理過程を示すシーケンス図である。
保守支援装置１００の改善要求表示部１４４は、改善要求一覧画面１７０を形成するウェブページの送信により、改善要求を開発システム２５０に送信する（Ｓ１０）。開発システム２５０側にて、作業者はプログラムに必要な修正を施す（Ｓ１２）。修正版プログラムは、修正プログラム保持部２５４に登録され（Ｓ１４）、保守支援装置１００にも送信される（Ｓ１６）。保守支援装置１００は、修正版プログラムをいったん修正プログラム保持部１６４に保持する。
【００５５】
管理者は、修正箇所を確認した上で承認入力する（Ｓ１８）。承認後、プログラム更新部１５１は、修正プログラム保持部１６４の修正版プログラムをリリース版保持部１６９に登録する（Ｓ２０）。Ｓ１０において送信した改善要求について必要な修正が完了すると、この改善要求についての完了フラグを「対応済み」に設定する（Ｓ２１）。
【００５６】
次期バージョンの必須要求の全てについて完了フラグが「対応済み」に設定されると、リリース可否通知部１３２は管理者に次期バージョンのリリースが可能な状態にあることを通知する（Ｓ２２）。このとき、リリース許可送信部１５８は、まず、開発システム２５０側に次期バージョンのリリースを準備するように通知する（Ｓ２４）。開発システム２５０は、現行バージョンのリリース後に修正された修正版プログラムを保守支援装置１００に送信する（Ｓ２６）。修正確認部１５３は、リリース版保持部１６９に保持されている修正版プログラムとＳ２６にて受信した修正版プログラムとの差分がないことを確認する（Ｓ２８）。差分がなければ、リリース許可送信部１５８はリリース許可通知を開発システム２５０に送信する（Ｓ３０）。このとき、登録部１５２は、更新履歴情報を更新する（Ｓ３２）。一方、開発システム２５０側では、修正プログラム保持部２５４の修正版プログラムをリリース版保持部２５２に登録し（Ｓ３４）、次期バージョンとしてリリースする（Ｓ３６）。
【００５７】
以上、保守支援装置１００を実施例に基づいて説明した。
保守支援装置１００によれば、業務システム２００の稼働中に改善要求が提案された場合、改善要求一覧画面１７０によって速やかに改善要求の内容が公開される。そして、作業者が改善要求に対応していくつかのプログラムファイルを修正したとき、改善要求と修正対象となったプログラムファイルだけではなく、その修正箇所までを自動的に対応づけることができる。
【００５８】
通常、修正版のプログラムがアップロードされたとき、修正前後の差分を検出して修正内容を確認する作業が必要である。しかし、１つの改善要求に対応するための修正が複数のプログラムファイルに及ぶ場合、こういった確認作業の負荷が大きくなる。また、プログラマによっては、修正に際して改善要求とは関係のない部分も修正してしまうこともある。このため、修正時においては、改善要求とは関係ない不明朗なコードが紛れ込む可能性が常に存在する。これに対し、本実施例に示す保守支援装置１００は、改善要求と修正箇所を対応づけて保持するため、管理者が修正前後の差分を検出する作業が実質的に不要となる。結果として、管理者の確認負担を軽減できるため、不明朗なコードが紛れ込む可能性を排除しやすくなる。
更に、開発システム２５０側にある修正版プログラムと、保守支援装置１００側にある承認済みの修正版プログラムの間に差分がないことを確認してから、開発システム２５０によるリリースを許可している。このため、リリース前に未承認の修正内容が正式版に紛れ込む可能性を排除している。
【００５９】
また、バージョン設定画面１８０において、バージョンと必須要求を対応づけて設定できるため、どの改善要求への対応が完了したら次期バージョンがリリースされるかという情報を複数のユーザ間で共有できる。更に、バージョン選択画面１９０、要求選択画面２１０、プログラム選択画面２２０、修正コード画面２３０を介して、バージョンの更新履歴、各バージョンにおいて解決された改善要求、各改善要求への対応のために修正されたプログラムファイル、更には、その修正箇所までを一続きに辿ることができる。このため、膨大なプログラムファイルから構成される業務システム２００を長期にわたって運用する場合においても、ソースファイルの更新履歴を効率的に管理することができる。
【００６０】
以上、本発明について実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００６１】
【図１】業務システムと保守支援装置、開発システムの関係を示すハードウェア構成図である。
【図２】保守支援装置の機能ブロック図である。
【図３】改善要求一覧画面の画面図である。
【図４】バージョン設定画面の画面図である。
【図５】改善要求に対するソースコードの修正箇所を特定する方法について説明するための模式図である。
【図６】バージョン選択画面の画面図である。
【図７】要求選択画面の画面図である。
【図８】プログラム選択画面の画面図である。
【図９】修正コード画面の画面図である。
【図１０】次期バージョンをリリースするまでの処理過程を示すシーケンス図である。
【符号の説明】
【００６２】
１００  保守支援装置、  １１０  ユーザインタフェース処理部、  １１２  入力部、  １１４  要求受信部、  １１６  修正受信部、  １１８  承認検出部、  １２０  バージョン設定部、  １２２  選択部、  １２４  バージョン選択部、  １２６  要求選択部、  １２８  プログラム選択部、  １３０  通知部、  １３２  リリース可否通知部、  １３４  履歴表示部、  １３６  更新履歴表示部、  １３８  要求一覧表示部、  １４０  プログラム一覧表示部、  １４２  修正箇所表示部、  １４４  改善要求表示部、  １５０  データ処理部、  １５２  登録部、  １５４  対応状態更新部、  １５６  修正箇所検出部、  １５８  リリース許可送信部、  １６０  データ保持部、  １６２  要求保持部、  １６４  修正プログラム保持部、  １６６  修正箇所保持部、  １６８  更新履歴保持部、  １７０  改善要求一覧画面、  １７２  要求ＩＤ欄、  １７４  概要欄、  １７６  緊急度欄、  １７８  対応状況欄、  １８０  バージョン設定画面、  １８２  バージョン設定領域、  １８４  要求ＩＤ指定領域、  １８６  対応状況領域、  １８８  修正箇所、  １９０  バージョン選択画面、  １９１  要望ＩＤ欄、  １９２  概要欄、  １９４  緊急度欄、  １９６  完了日欄、  ２００  業務システム、  ２０２  従業員端末、  ２０４  管理者端末、  ２０６  開発用端末、  ２１０  要求選択画面、  ２２０  プログラム選択画面、  ２３０  修正コード画面、  ２４０  要求詳細領域、  ２４２  修正リスト欄。  
【図１】
2009169724.tif 000003
【図２】
2009169724.tif 000004
【図３】
2009169724.tif 000005
【図４】
2009169724.tif 000006
【図５】
2009169724.tif 000007
【図６】
2009169724.tif 000008
【図７】
2009169724.tif 000009
【図８】
2009169724.tif 000010
【図９】
2009169724.tif 000011
【図１０】
2009169724.tif 000012