JP2008171362A

JP2008171362A - システム設計支援装置

Info

Publication number: JP2008171362A
Application number: JP2007006351A
Authority: JP
Inventors: Yoshio Ozawa; 良男小澤; Yuichi Terada; 雄一寺田; Akira Tatemoto; 顕建本
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2007-01-15
Filing date: 2007-01-15
Publication date: 2008-07-24
Anticipated expiration: 2027-01-15
Also published as: JP4980732B2

Abstract

【課題】業務情報システムにおける基盤設計の工数を見積もる。
【解決手段】業務情報システムの設計工数を見積もるためのシステム設計支援装置に関する。業務情報システムとは、複数の処理装置の連携により組織業務を管理するためのシステムである。システム設計支援装置は、既に設計が完了している業務情報システムの処理パターンに関するデータから、その業務情報システムにおける複数種類の処理パターンの実装に要した工数とシステム中継ポイントとの相関関係を示す見積計算式を特定する。
そして、新たな設計の対象となる別の業務情報システムについてのシステム中継ポイントを取得し、見積計算式に基づいて処理パターンの実装に要する工数を見積工数として算出する。
【選択図】図４

Description

この発明は、業務情報システムに関連し、特に、業務情報システムの設計を支援するための技術、に関する。

企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。

業務情報システムの規模は、業務内容に応じて多種多様である。業務情報システムの設計に際しては、まず、業務情報システムに求められる処理内容を特定し、ハードウェアやＯＳ、ミドルウェアといった「基盤」を設計し、その上で各種処理を実行するための「アプリケーション」を設計する。
特開平０７−１９１８３９号公報

アプリケーションの規模を事前に見積もるための方法としては、ＦＰ法（Function Point Method）とよばれる手法が確立されている。ＦＰ法は、ソフトウェアの開発費用や工数などを算定する際に使われている。

しかし、基盤設計に要する工数の見積もりは、熟練したシステムエンジニア（System Engineer）の経験や知識といった属人的スキルに依存しているのが現状である。いいかえれば、基盤設計の工数を見積るという作業は、システムエンジニアの「技能」の領域にとどまっている。一般的な業務情報システムの設計請負契約において、業務情報システムの設計費用は、基盤設計に要する工数の見積もりに基づいて算出される。
本発明者は、業務情報システムの設計側と導入側の双方にとって合理的な設計請負契約を締結するためには、基盤設計の工数を合理的かつ正確に見積もるためのアルゴリズムが必要であると認識した。

本発明は、本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、業務情報システムの設計に要する工数を合理的に見積もるための技術、を提供することにある。

本発明のある態様は、業務情報システムの設計工数を見積もるためのシステム設計支援装置に関する。ここでいう業務情報システムとは、複数の処理装置の連携により組織業務を管理するためのシステムであればよい。
この装置は、既に設計が完了している第１の業務情報システムについて、各種業務に関わる処理装置の組み合わせパターンを示す処理パターンを取得し、各処理パターンに関わる処理装置の数を合計した中継ポイントと、第１の業務情報システムにおける複数種類の処理パターンの実装に要した工数との相関関係を示す見積計算式を特定する。
そして、新たな設計の対象となる第２の業務情報システムについての複数種類の処理パターンから第２の業務情報システムの中継ポイントを取得し、第２の業務情報システムの中継ポイントと見積計算式から、第２の業務情報システムにおける複数種類の処理パターンの実装に要する工数を見積工数として算出する。

本発明の別の態様もまた、システム設計支援装置である。
この装置は、処理装置への機能コンポーネントの導入にともなう作業負荷の大きさを示す負荷値を機能コンポーネントごとに対応づけた負荷テーブルを保持する。
この装置は、既に設計が完了している第１の業務情報システムについて、各処理装置に導入される機能コンポーネントを示す機能情報を取得し、各処理装置に導入される機能コンポーネントの負荷値を合計した導入ポイントと、第１の業務情報システムへの各種機能コンポーネントの導入に要した工数との相関関係を示す見積計算式を特定する。
そして、新たな設計の対象となる第２の業務情報システムについての機能情報と負荷テーブルから、第２の業務情報システムの導入ポイントを取得し、導入ポイントと見積計算式から、第２の業務情報システムへ各種機能コンポーネントを導入するのに要する工数を見積工数として算出する。

本発明のさらに別の態様もまた、システム設計支援装置である。
この装置は、既に設計が完了している第１の業務情報システムについて、各種業務に関わる処理装置の組み合わせパターンを示す処理パターンを取得し、各処理パターンに関わる処理装置の数を合計した中継ポイントと、第１の業務情報システムにおける動作確認テストの実行に要した工数との相関関係を示す見積計算式を特定する。
そして、新たな設計の対象となる第２の業務情報システムについての複数種類の処理パターンから第２の業務情報システムの中継ポイントを取得し、第２の業務情報システムの中継ポイントと見積計算式から、第２の業務情報システムにおける動作確認テストの実行に要する工数を見積工数として算出する。

本発明のさらに別の態様もまた、システム設計支援装置である。
この装置は、処理装置への機能コンポーネントの導入にともなう作業負荷の大きさを示す負荷値を機能コンポーネントごとに対応づけた負荷テーブルを保持する。
この装置は、既に設計が完了している第１の業務情報システムについて、各処理装置に導入される機能コンポーネントを示す機能情報を取得し、各処理装置に導入される機能コンポーネントの負荷値を合計した導入ポイントと、第１の業務情報システムにおける動作確認テストに要した工数との相関関係を示す見積計算式を特定する。
そして、新たな設計の対象となる第２の業務情報システムについての機能情報と負荷テーブルから第２の業務情報システムの導入ポイントを取得し、導入ポイントと見積計算式から、第２の業務情報システムにおける動作確認テストに要する工数を見積工数として算出する。

なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、業務情報システムの設計に要する工数を合理的に算出することができる。

図１は、業務情報システム２００のハードウェア構成図である。
業務情報システム２００は、企業や公共施設のような組織の業務管理のために導入されるシステムである。業務情報システム２００は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。ここでは、インターネットで証券取引を行うための証券会社の業務情報システムを例として説明する。

業務情報システム２００は、データベースサーバ群２１０、ビジネスロジックサーバ群２２０およびプレゼンテーションサーバ群２３０という３種類のサーバ群を含む。また、業務情報システム２００は、インターネット（Internet）などの通信回線を介してノード端末群２４０と接続される。

ノード端末群２４０は、ノード端末２４２ａ、２４２ｂ、２４２ｃなど複数のノード端末２４２を含む。顧客は、いずれかのノード端末２４２を介して業務情報システム２００にアクセスする。各ノード端末２４２は、一般的なＰＣ端末である。業務情報システム２００は、ノード端末２４２から何らかのコマンドを受信すると、コマンドに応じて各種処理を実行し、処理結果をノード端末２４２に送信することになる。

データベースサーバ群２１０は、ＤＢ（Data Base）サーバ２１２ａ、２１２ｂ、２１２ｃのように複数のＤＢサーバ２１２を含む。ＤＢサーバ２１２は、業務に必要な各種情報を保持する。たとえば、顧客の住所や電話番号、暗証番号等のユーザ情報、株価の履歴やアナリストコメントといった企業情報は複数のＤＢサーバ２１２に分散して保持される。
ビジネスロジックサーバ群２２０は、ＢＬ（Bussiness Logic）サーバ２２２ａ、２２２ｂ、２２２ｃのように複数のＢＬサーバ２２２を含む。ＢＬサーバ２２２は、業務に応じた各種計算処理を実行する。たとえば、株式の注文処理、債権の利金計算などの処理が該当する。
プレゼンテーションサーバ群２３０は、ＰＬ（Presentation）サーバ２３２ａ、２３２ｂ、２３２ｃのように複数のＰＬサーバ２３２を含む。ＰＬサーバ２３２は、ノード端末群２４０と業務情報システム２００のインタフェースとなるウェブサーバである。
以下、業務情報システム２００に含まれるＤＢサーバ２１２、ＢＬサーバ２２２、ＰＬサーバ２３２をまとめていうときには、単に「サーバ」とよぶ。

株式の注文や株価の更新など、業務情報システム２００で実行される処理は、通常、１以上のサーバが処理を分担することにより実現される。業務情報システムにおいて実行されるさまざまな処理は、複数種類の「処理パターン」に集約される。処理パターンとは、「なんらかの業務処理を実現するためのデータ処理に関わるサーバの組み合わせ」を示す情報である。図２を参照しつつ具体的に説明する。

図２は、各種処理パターンを示す模式図である。
図２（ａ）は、パターン中継ポイント＝１の処理パターンを示す図である。
顧客がノード端末２４２を操作して、業務情報システム２００にアクセスすると、ＰＬサーバ２３２はウェブページのＨＴＭＬ（HyperText Markup Language）データをノード端末２４２に送信する。顧客がノード端末２４２を介して画面レイアウト変更指示をＰＬサーバ２３２に送信すると、ＰＬサーバ２３２はウェブページのレイアウトを変更し、変更後のＨＴＭＬデータをノード端末２４２に返信する。こうして、ノード端末２４２に表示される画面のレイアウトが変更される。
この「画面レイアウト変更処理」に関わったサーバは、１つのＰＬサーバ２３２だけである。画面レイアウト変更処理に以外にも１つのＰＬサーバ２３２だけで実現される処理がある。これらの処理は、「なんらかの業務処理を実現するためのデータ処理に関わるサーバの組み合わせ」という点で同じ処理パターンに分類されることになる。
以下、なんらかの処理パターンにおいて、データ処理に関わるサーバ数のことをその処理パターンの「パターン中継ポイント」とよぶ。図２（ａ）に示す処理パターンの場合、パターン中継ポイントは「１」である。なお、変形例として、サーバの数だけでなく、ある処理パターンについてのデータ処理にかかわるノード端末２４２の数も含めて、サーバ数とノード端末２４２の合計値をパターン中継ポイントとして計数してもよい。この場合、図２（ａ）に示す処理パターンのパターン中継ポイントは「２」となる。

図２（ｂ）に示す処理パターンにおいては、データ処理に関わるサーバは、ＰＬサーバ２３２とＢＬサーバ２２２の２つである。すなわち、図２（ｂ）に示す処理パターンのパターン中継ポイントは「２」である。上記変形例に基づく計数方法の場合、パターン中継ポイントは「３」となる。
図２（ｃ）に示す処理パターンにおいては、データ処理に関わるサーバは、ＰＬサーバ２３２、ＢＬサーバ２２２およびＤＢサーバ２１２の３つである。すなわち、図２（ｃ）に示す処理パターンのパターン中継ポイントは「３」である。
図２（ｄ）に示す処理パターンにおいては、データ処理に関わるサーバは、ＰＬサーバ２３２、ＢＬサーバ２２２と、ＤＢサーバ２１２ｄと２１２ｅである。すなわち、図２（ｄ）に示す処理パターンのパターン中継ポイントは「４」である。
仮に、業務情報システム２００が図２（ａ）〜（ｄ）の４つの処理パターンを含むシステムであるとする。このような業務情報システム２００についてパターン中継ポイントを合計すると、１＋２＋３＋４＝１０より「１０」となる。以下、業務情報システムに含まれる各処理パターンについてのパターン中継ポイントを合計値のことを「システム中継ポイント」とよぶ。第１の処理パターンと第２の処理パターンに同じサーバＡが含まれるとしても、システム中継ポイントの算出時にはサーバＡはダブルカウントされる。第１の処理パターンのためのサーバＡの設定と、第２の処理パターンのためのサーバＡの設定は、通常、それぞれの処理パターンに対応させるための別作業となることが多いためである。

図２（ｄ）に示す処理パターンの一例として、ＰＬサーバ２３２は、投資信託の買付注文を受け付けると、投資信託の識別ＩＤ、買付数量、顧客ＩＤ等をＢＬサーバ２２２に送信する。ＢＬサーバ２２２は、ユーザ情報を保持するＤＢサーバ２１２ｄにアクセスして買付可能残高を確認し、注文情報を保持するＤＢサーバ２１２ｅに注文内容を登録する。国債の買付注文処理についても基本的に同様の仕組みである。したがって、これらは同じ処理パターンに集約される。業務情報システムの基盤設計に際しては、まず、どのような処理パターンが必要かを検討する。その上で、特定された処理パターンを実現するためにネットワークトポロジー等、各種サーバの配置を設計する。このときには、特定のサーバに過度に負荷がかからないようにするために複数のサーバを用意したり、特定のサーバが受け付けることができるジョブの数の設定なども作業対象となる。このような処理パターンをサーバの配置により実装する作業は、「方式設計」とよばれている。本実施例においては、業務情報システムの設計工数を見積もるためにシステム中継ポイントを利用するが詳しい仕組みについては後述する。

また、各サーバのハードウェアやソフトウェアは目的に応じてさまざまである。たとえば、処理負荷の大きいサーバのハードウェアは、そうでないサーバのハードウェアに比べて高スペックとなる。処理内容が複雑なサーバには、そうでないサーバに比べて高機能なＯＳ（Operating System）やミドルウェアが導入されることになる。このようなサーバに導入されるハードウェアやソフトウェアであって、アプリケーションソフトウェアを実行するための基盤となる構成要素のことを「機能コンポーネント」とよぶ。
方式設計後、各サーバにさまざまな機能コンポーネントが導入される。このような機能コンポーネントの導入作業は「環境設計構築」とよばれている。そして、方式設計と環境設計構築が完了した後に、動作確認テストが実行される。このようなテスト作業のことを「基盤テスト」とよぶ。
まとめると、業務情報システム２００の基盤設計とは、
Ａ．方式設計
Ｂ．環境設計構築
Ｃ．基盤テスト
の３つの作業に大別することができる。基盤テストが完了すると、すなわち、基盤設計が完了すると、アプリケーション設計のフェーズに移行する。実装によっては、基盤設計が完了する前に、アプリケーションの設計フェーズを開始してもよい。

図３は、サーバの階層図である。
同図は、あるサーバに導入される機能コンポーネントの階層を示している。まず、最下層がハードウェア層である。その上位がＯＳ層である。ＯＳの上にはアプリケーションソフトウェアが直接位置してもよいし、１以上のミドルウェアがアプリケーションソフトウェアとＯＳを仲介するために位置してもよい。同図に示すサーバの場合、ミドルウェアＡ、Ｂ、Ｃ、Ｄいう４つのミドルウェアが導入されている。たとえば、ミドルウェアＡがＪＡＶＡ（登録商標）ヴァーチャルマシン（以下、単に「ＪＶＭ（Java Virtual Machine）」とよぶ）であれば、その上位に位置するミドルウェアＢはＪＶＭを前提として動作するＪＡＶＡバイトコードのミドルウェアとなる。
同図において、斜線で示されている部分が「基盤」とよばれる部分であり、特に、環境設計構築や基盤テストの対象となる部分である。

機能コンポーネントには、設定が複雑なものもあればそうでないものもある。環境設計構築においては、機能コンポーネントの数や種類、あるいは、組み合わせによって作業工数が変化する。本実施例においては、機能コンポーネントの数や種類に基づいて業務情報システムの設計工数を見積もるが、詳しい仕組みについては後述する。

図４は、基盤設計の流れを示す図である。
既に述べたように基盤設計においては、方式設計を行う方式設計フェーズ２６２、環境設計構築を行う環境設計フェーズ２６４、基盤テストを行う基盤テストフェーズ２６６という３つのフェーズが順次移行する。実際には、方式設計フェーズ２６２に先立って検討フェーズ２６０が存在する。この検討フェーズ２６０においては、業務情報システム２００に必要な処理を特定し、どのような処理パターンが存在するかを特定する。また、業務情報システム２００においてどのサーバにどのような機能コンポーネントを導入すべきかについてもあらかじめ検討する。従来、熟練したシステムエンジニアが、検討フェーズ２６０において、方式設計フェーズ２６２、環境設計フェーズ２６４および基盤テストフェーズ２６６のそれぞれに必要な工数を経験に基づいて見積もっていた。そして、見積り工数に基づいて、業務情報システム２００の設計に対する請求金額が方式設計見積書２７０、環境設計見積書２７２ａ、基盤テスト見積書２７４ｂのかたちで提示されていた。

業務情報システム２００を導入する企業が請求金額を了解すると、方式設計、環境設計構築、基盤テストが実行され、そのあとにアプリケーション設計がなされる。場合によっては、方式設計フェーズ２６２のあとに再び検討フェーズ２６８を設け、環境設計フェーズ２６４と基盤テストフェーズ２６６の工数を再度見積り、環境設計見積書２７２ｂと基盤テスト見積書２７４ｂが再提示されることもある。方式設計が完了しているので、方式設計前の検討時よりも正確な工数を見積もりやすいためである。

しかし、いずれにしても、見積工数がシステムエンジニアの属人的な「技能」に依存していることには変わりがない。そのため、導入側企業が請求金額に納得しにくいという状況となる。また、設計側企業にとっても統一基準に基づいて請求金額を算出できないため、ディスカウント交渉等の追加的な作業が発生しやすい。もちろん、基盤設計が完了した後に実際の工数に基づいて請求金額を算出してもよいが、投資額の大きな業務情報システム２００の工数見積りはほぼ不可避である。ビジネス慣行においては、見積金額がそのまま実際の請求金額になることが多い。
以上の理由から、導入側にとっても設計側にとっても、業務情報システム２００の基盤設計の前に基盤設計に要する工数を合理的かつ正確に見積もるための方法を確立する必要性やメリットは大きい。

本実施例においては、方式設計フェーズ２６２の前の検討フェーズ２６０や、方式設計フェーズ２６２の後の検討フェーズ２６８のいずれにおいても、処理パターンやシステム中継ポイント、業務情報システム２００に導入される機能コンポーネントの数や種類に基づいて、合理的に設計工数を算出する方法について開示する。

まず、本発明者は、処理パターンの実装に要する工数、すなわち方式設計に要する工数はパターン中継ポイントに大きく依存している点に着目した。そこで、本発明者は方式設計の工数とシステム中継ポイント、すなわち、すべての処理パターンを実装するためのパターン中継ポイントの合計値の間になんらかの相関関係があるという第１の仮説を立てた。

本発明者は、過去に方式設計された複数種類の業務情報システムについて、方式設計に実際に要した工数とシステム中継ポイントの関係を検証した。ここでいう工数とは、人数×時間（月）として示される仕事量のことである。本発明者が上記複数種類の業務情報システムについて、システム中継ポイントを説明変数、方式設計に要した工数を目的変数として線形単回帰分析を行ったところ、相関係数０．６５という結果が得られた。すなわち、方式設計の工数（Ｙ）とシステム中継ポイント（Ｘ）との間には、Ｙ＝ＡＸ＋Ｂという関係を見いだすことができる。いいかえれば、設計対象となる業務情報システムのシステム中継ポイントを取得できれば、方式設計に要する工数を合理的かつある程度の確度にて算定できることになる。システム中継ポイントから方式設計の見積工数を算出するアルゴリズムについては図６に関連して更に詳述する。

本発明者は、機能コンポーネント導入に要する負荷は、機能コンポーネントの数や種類に大きく依存している点にも着目した。そこで、本発明者は環境設計構築の工数と機能コンポーネントの数や種類の間になんらかの相関関係があるという第２の仮説を立てた。そのために、まず、機能コンポーネントの導入に要する負荷の大きさを指標化した「負荷値」示す「負荷テーブル」を用意した。

図５は、負荷テーブル２５０のデータ構造図である。
製品名欄２５２は機能コンポーネントの名前を示す。負荷値欄２５４は機能コンポーネントの導入に要する負荷の大きさを負荷値として示す。負荷値が小さいほど導入が容易であり、負荷値が大きいほど導入にともなう負荷が大きいことを示す。

負荷テーブル２５０は、ハードウェア欄２５６とソフトウェア欄２５８に分けられる。ハードウェア欄２５６はハードウェアとしての機能コンポーネントを示し、ソフトウェア欄２５８はＯＳやミドルウェア等のソフトウェアとしての機能コンポーネントを示す。たとえば、「svA」、「svB」、「svK」という３つのサーバの負荷値は「１」である。「svC」、「svL」という２つのサーバの負荷値は「２」であり、「svA」よりも導入に要する負荷が大きい。このような負荷値は、実際の導入経験に基づいてユーザが任意に設定すればよい。

ＯＳについても、導入後の設定作業が複雑なものもあれば簡単なものもある。したがって、ＯＳについてもそれぞれ負荷値を設定している。そのほかにも、データベースソフトウェア、ＪＶＭ、ファイル転送用ソフトウェアなど、さまざまなミドルウェアについても負荷値が設定される。以下、あるサーバに導入される機能コンポーネントの負荷値を合計した値のことをそのサーバの「サーバ導入ポイント」とよぶ。たとえば、図３に示したサーバには、ハードウェア、ＯＳ、ミドルウェアＡ〜Ｄの６つの機能コンポーネントが導入されている。例として、
ハードウェア：svM（負荷値＝３）
ＯＳ：osC（負荷値＝４）
ミドルウェアＡ：jvA（負荷値＝１）
ミドルウェアＢ：dbA（負荷値＝４）
ミドルウェアＣ：dbB（負荷値＝５）
ミドルウェアＤ：ftA（負荷値＝２）
とすると、このサーバのサーバ導入ポイントは、３＋４＋１＋４＋５＋２＝１９より「１９」となる。
また、ある業務情報システム２００に含まれるサーバのサーバ導入ポイントをすべてのサーバについて合計した値のことを、その業務情報システム２００の「システム導入ポイント」とよぶ。

製品名ではなく製品の機能に応じて負荷値を設定してもよい。たとえば、ハードウェアの機能コンポーネントであれば、仮想化やパーティショニングに対応しているかといった所定条件に基づいて負荷値を設定してもよい。ソフトウェアの機能コンポーネントであっても同様であり、製品がサポートする機能に応じて負荷値を設定してもよい。
同図に示す負荷テーブル２５０の場合、負荷値はすべて整数により示されているが、整数に限る意図ではなく小数の単位で設定されてもよい。特に、後述する負荷値の補正処理においては、１．０よりも小さな単位で負荷値を変化させることができる。

本発明者は、先に示したのと同じ複数種類の業務情報システムに関し、環境設計構築に実際に要した工数とシステム導入ポイントの関係を検証した。ここでいう工数も、人数×時間（月）として示される仕事量のことである。本発明者が上記複数種類の業務情報システムについて、システム導入ポイントを説明変数、環境設計構築に要した工数を目的変数として線形単回帰分析を行ったところ、相関係数０．８４という結果が得られた。すなわち、環境設計構築の工数（Ｙ）とシステム導入ポイント（Ｘ）との間には、Ｙ＝ＣＸ＋Ｄという関係を見いだすことができる。いいかえれば、設計対象となる業務情報システムのシステム導入ポイントを取得できれば、環境設計構築に要する工数を合理的かつある程度の確度にて算定できることになる。システム導入ポイントから環境設計構築の見積工数を算出するアルゴリズムについては図６に関連して更に詳述する。

本発明者は、更に、基盤テストに要する作業負荷は、パターン中継ポイントや、機能コンポーネントの数、種類等に大きく依存している点にも着目した。そこで、本発明者は基盤テストの工数とシステム中継ポイントの間にはなんらかの相関関係があるという第３の仮説、基盤テストの工数とシステム導入ポイントの間にはなんらかの相関関係があるという第４の仮説を立てた。

本発明者は、先に示した複数種類の業務情報システムのうち基盤テストまで完了した複数種類の業務情報システムに関し、基盤テストに実際に要した工数とシステム中継ポイントとの関係を検証した。ここでいう工数も、人数×時間（月）として示される仕事量のことである。本発明者が上記複数種類の業務情報システムについて、システム中継ポイントを説明変数、基盤設計に要した工数を目的変数として線形単回帰分析を行ったところ、相関係数０．７９という結果が得られた。すなわち、基盤テストの工数（Ｙ）とシステム中継ポイント（Ｘ）との間には、Ｙ＝ＥＸ＋Ｆという関係を見いだすことができる。いいかえれば、設計対象となる業務情報システムのシステム中継ポイントを取得できれば、基盤テストに要する工数を合理的かつある程度の確度にて算定できることになる。システム中継ポイントから基盤テストの見積工数を算出するアルゴリズムについては図６に関連して更に詳述する。

本発明者は、上記複数種類の業務情報システムに関し、基盤テストに実際に要した工数とシステム導入ポイントとの関係を検証した。ここでいう工数も、人数×時間（月）として示される仕事量のことである。本発明者が上記複数種類の業務情報システムについて、システム導入ポイントを説明変数、基盤テストに要した工数を目的変数として線形単回帰分析を行ったところ、相関係数０．９７２という結果が得られた。すなわち、基盤テストの工数（Ｙ）とシステム導入ポイント（Ｘ）との間には、Ｙ＝ＧＸ＋Ｈという関係を見いだすことができる。いいかえれば、設計対象となる業務情報システムのシステム導入ポイントを取得できれば、基盤テストに要する工数を合理的かつある程度の確度にて算定できることになる。システム導入ポイントから基盤テストの見積工数を算出するアルゴリズムについては図６に関連して更に詳述する。

基盤テストについては、システム中継ポイントからも、システム導入ポイントからもある程度正確に工数を見積もることができることがわかった。いずれか一方に基づいて工数を見積もるとしてもよいし、両方から見積もってもよい。たとえば、システム中継ポイントから見積もった工数とシステム導入ポイントから見積もった工数との平均値を基盤テストの見積工数としてもよい。

図６は、システム設計支援装置１００の機能ブロック図である。
システム設計支援装置１００は、以上の知見に基づいて業務情報システム２００の基盤設計における見積工数を算出するための装置である。図４に示した各フェーズのうち、検討フェーズにおける使用を想定する。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

システム設計支援装置１００は、ユーザインタフェース処理部１１０、データ処理部１２０およびデータ保持部１６０を含む。
ユーザインタフェース処理部１１０は、ユーザインタフェース全般を担当する。
データ処理部１２０は、ユーザインタフェース処理部１１０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１２０は、ユーザインタフェース処理部１１０とデータ保持部１６０の間のインタフェースの役割も果たす。
データ保持部１６０は、各種データを保持するための記憶領域である。

ユーザインタフェース処理部１１０：
ユーザインタフェース処理部１１０は、処理パターン入力部１１２、環境設定入力部１１４および見積工数出力部１１６を含む。
処理パターン入力部１１２は、業務情報システム２００の処理パターンを取得する。ここでいう処理パターンには、その処理パターンにおいてデータ処理に関わるサーバを示すデータも含む。環境設定入力部１１４は、業務情報システム２００の「機能情報」を取得する。機能情報とは、業務情報システム２００に含まれるサーバと、そのサーバに導入される機能コンポーネントを示すデータである。見積工数出力部１１６は、後述する計算式により算出された基盤設計の見積工数を画面表示等の手段により出力する。

以下においては、既に設計が完了している業務情報システムのことを「実績システム」、これから設計を行うために工数を見積もるべき業務情報システムのことを「設計システム」ともよぶことにする。処理パターン入力部１１２は、設計システムの処理パターンだけでなく実績システムの処理パターンも取得する。同様にして、環境設定入力部１１４も設計システムの機能情報だけでなく、実績システムの機能情報も取得する。
なお、方式設計に要する工数を「方式工数」、このうち実績システムの方式設計に要した工数のことを「方式実績工数」、設計システムの方式設計について見積もった工数のことを「方式見積工数」とよぶ。また、環境設計構築に要する工数を「環境工数」、このうち実績システムの環境設計構築に要した工数のことを「環境実績工数」、設計システムの環境設計構築について見積もった工数のことを「環境見積工数」とよぶ。更に、基盤テストに要する工数を「テスト工数」、このうち実績システムの基盤テストに要した工数のことを「テスト実績工数」、設計システムの基盤テストについて見積もった工数のことを「テスト見積工数」とよぶ。

データ保持部１６０：
データ保持部１６０は、方式設計実績保持部１６２、環境設計実績保持部１６４、テスト実績保持部１６６、負荷テーブル保持部１６８、実績パターン保持部１７０および実績機能保持部１７２を含む。
方式設計実績保持部１６２は、実績システムとその方式実績工数を対応づけて保持する。環境設計実績保持部１６４は、実績システムとその環境実績工数を対応づけて保持する。テスト実績保持部１６６は、実績システムとそのテスト実績工数を対応づけて保持する。負荷テーブル保持部１６８は、図５に関連して説明した負荷テーブル２５０を保持する。方式設計実績保持部１６２、環境設計実績保持部１６４、テスト実績保持部１６６に登録される各種実績工数や負荷テーブル保持部１６８の負荷テーブルは、ユーザインタフェース処理部１１０を介してユーザにより手動設定される。

実績パターン保持部１７０は、実績システムとその実績システムに含まれる処理パターンを対応づけて保持する。たとえば、４つの処理パターンを含む実績システムであれば、その実績システムＩＤについて、４つの処理パターンそれぞれに含まれるサーバのサーバＩＤが対応づけられることになる。すなわち、実績パターン保持部１７０を参照することにより、どの実績システムに、どのような処理パターンが含まれ、それらの処理パターンにどのようなサーバがいくつ関わっているかが分かる。処理パターン入力部１１２が取得する実績システムの処理パターンは、実績パターン保持部１７０に記録される。

実績機能保持部１７２は、実績システムとその実績システムについての機能情報を対応づけて保持する。たとえば、８つのサーバを含む実績システムであれば、その実績システムＩＤについて、各サーバごとに導入されている機能コンポーネントのＩＤが対応づけられることになる。すなわち、実績機能保持部１７２を参照することにより、どの実績システムに、どのようなサーバが含まれ、各サーバにどのような機能コンポーネントが導入されているかが分かる。環境設定入力部１１４が取得する実績システムの機能情報は、実績機能保持部１７２に記録される。

データ処理部１２０：
データ処理部１２０は、ポイント計算部１２２、見積式特定部１２８、工数予測部１３６および負荷調整部１４６を含む。
ポイント計算部１２２は、処理パターンや機能情報から中継ポイントや導入ポイントを計算する。ポイント計算部１２２は、中継ポイント計算部１２４と導入ポイント計算部１２６を含む。中継ポイント計算部１２４は、パターン中継ポイントやシステム中継ポイント等の中継ポイントを算出する。導入ポイント計算部１２６は、サーバ導入ポイントやシステム導入ポイント等の導入ポイントを算出する。

見積式特定部１２８は、実績システムにおけるシステム中継ポイントやシステム導入ポイント、方式実績工数、環境実績工数、テスト実績工数の間の関係を示す見積式を特定する。見積式特定部１２８は、方式見積式特定部１３０、環境見積式特定部１３２およびテスト見積式特定部１３４を含む。
方式見積式特定部１３０は、実績システムについてのシステム中継ポイントと方式実績工数から線形単回帰分析によりその間の関係を示す一次関数式を求める。すなわち、方式設計の工数（Ｙ）とシステム中継ポイント（Ｘ）との間には、Ｙ＝ＡＸ＋Ｂという関係を見いだすことができるから、傾きＡと切片Ｂが特定すべき対象となる。Ｙ＝ＡＸ＋Ｂとして示される方式実績工数とシステム中継ポイントの関係式のことを「方式見積式」とよぶ。なお、１つしか実績システムが存在しないときには、そのシステム中継ポイントと方式実績工数と原点を結ぶ直線を方式見積式として代用してもある程度の合理性・確度を担保できる。方式見積式特定部１３０の処理内容については、更に、図７に関連して後述する。

環境見積式特定部１３２は、実績システムについてのシステム導入ポイントと環境実績工数から線形単回帰分析によりその関係を示す一次関数式を求める。すなわち、環境設計構築の工数（Ｙ）とシステム導入ポイント（Ｘ）との間には、Ｙ＝ＣＸ＋Ｄという関係を見いだすことができるから、傾きＣと切片Ｄが特定対象となる。Ｙ＝ＣＸ＋Ｄとして示される環境実績工数とシステム導入ポイントとの関係式のことを「環境見積式」とよぶ。なお、１つしか実績システムが存在しないときには、そのシステム導入ポイントと環境実績工数と原点を結ぶ直線を方式見積式として代用してもある程度の合理性・確度を担保できる。環境見積式特定部１３２の処理内容については、更に、図８に関連して後述する。

テスト見積式特定部１３４は、実績システムについてのシステム中継ポイントとテスト実績工数から線形単回帰分析によりその関係を示す一次関数式を求める。すなわち、基盤テストの工数（Ｙ）とシステム中継ポイント（Ｘ）との間には、Ｙ＝ＥＸ＋Ｆという関係を見いだすことができるから、傾きＥと切片Ｆが特定対象となる。Ｙ＝ＥＸ＋Ｆとして示されるテスト実績工数とシステム中継ポイントとの関係式のことを「第１テスト見積式」とよぶ。なお、１つしか実績システムが存在しないときには、そのシステム中継ポイントとテスト実績工数と原点を結ぶ直線を方式見積式として代用してもよい。

テスト見積式特定部１３４は、また、実績システムについてのシステム導入ポイントとテスト実績工数から線形単回帰分析によりその関係を示す一次関数式を求める。すなわち、基盤テストの工数（Ｙ）とシステム導入ポイント（Ｘ）との間には、Ｙ＝ＧＸ＋Ｈという関係を見いだすことができるから、傾きＧと切片Ｈが特定対象となる。Ｙ＝ＧＸ＋Ｈとして示されるテスト実績工数とシステム導入ポイントとの関係式のことを「第２テスト見積式」とよぶ。なお、１つしか実績システムが存在しないときには、そのシステム導入ポイントとテスト実績工数と原点を結ぶ直線を方式見積式として代用してもよい。
第１テスト見積式と第２テスト見積式をまとめていうときには、単に、「テスト見積式」とよぶ。テスト見積式特定部１３４の処理内容については、更に、図７や図８に関連して後述する。

工数予測部１３６は、各種見積式に基づいて設計システムの見積工数を算出する。工数予測部１３６は、方式工数計算部１３８、環境工数計算部１４０、テスト工数計算部１４２および見積式補正部１４４を含む。
方式工数計算部１３８は、設計システムの処理パターンと方式見積式に基づいて、方式見積工数を算出する。方式工数計算部１３８の処理内容については、更に、図９に関連して後述する。
環境工数計算部１４０は、設計システムの機能情報と環境見積式に基づいて、環境見積工数を算出する。環境工数計算部１４０の処理内容については、更に、図１０に関連して後述する。
テスト工数計算部１４２は、設計システムの処理パターンや機能情報とテスト見積式に基づいて、テスト見積工数を算出する。テスト工数計算部１４２の処理内容については、更に、図９や図１０に関連して後述する。

ところで、基盤設計の業務効率は、作業を実際に行うシステムエンジニアの能力にある程度依存する。特に、業務情報システム２００の基盤設計に際しては外部の協力会社から派遣されるシステムエンジニアの支援を受けることも多いため、どの協力会社が基盤設計に関わるかによって業務効率も変化する。このような状況に対応するために、方式見積式特定部１３０や環境見積式特定部１３２、テスト見積式特定部１３４は、作業者グループごとに各見積式を特定してもよい。たとえば、方式設計の得意な協力会社についての方式見積式Ｙ＝ＡＸ＋Ｂにおいては、他の協力会社の方式見積式に比べてＡやＢは比較的小さな値となる。

見積式補正部１４４は、見積式特定部１２８にて計算された各種見積式の変数を調整する。たとえば、協力会社Ｊと協力会社Ｋの混成チームにより基盤設計を行う場合を想定する。このような場合には、基盤設計に関わる作業者群において、協力会社Ｊのシステムエンジニアの人数と協力会社Ｋのシステムエンジニアの人数比に基づいて見積式を調整してもよい。たとえば、協力会社Ｊの方式見積式をＹ＝Ａ_ＪＸ＋Ｂ_Ｊ、協力会社Ｋの方式見積式をＹ＝Ａ_ＫＸ＋Ｂ_Ｋであるとする。また、基盤設計のうち、方式設計について、協力会社Ｊのシステムエンジニアの人数と協力会社Ｋのシステムエンジニアの人数の比がＰ_Ｊ：Ｐ_Ｋであるとする。このときの方式見積式をＹ＝ＡＸ＋Ｂとすると、見積式補正部１４４は、
Ａ＝（Ｐ_ＪＡ_Ｊ＋Ｐ_ＫＡ_Ｋ）／（Ｐ_Ｊ＋Ｐ_Ｋ）
Ｂ＝（Ｐ_ＪＢ_Ｊ＋Ｐ_ＫＢ_Ｋ）／（Ｐ_Ｊ＋Ｐ_Ｋ）
として、傾きＡ、切片Ｂを計算する。
このような処理方法によれば、作業者の能力を加味したかたちでより合理的な見積式を算出できる。上記例では、方式見積式について説明したが、環境見積式やテスト見積式についても同様である。

負荷調整部１４６は、負荷テーブル２５０における各機能コンポーネントの負荷値を調整する。負荷調整部１４６は、負荷登録部１４８と負荷補正部１５０を含む。
負荷登録部１４８は、負荷テーブル２５０に機能コンポーネントを登録するときに、その負荷値を初期設定する。このような未登録機能コンポーネントの負荷値は所定値、たとえば、「３」に設定され、ユーザは負荷値を任意に変更するとしてもよい。しかし、機能コンポーネントの中には、既に登録されている機能コンポーネントと同じ製品系列に属するものもある。たとえば、あるＯＳ−Ａがすでに負荷テーブル２５０に登録されている状態において、ＯＳ−Ａのバージョンアップ版であるＯＳ−Ａ’を新たに登録するとする。このとき負荷登録部１４８は、ＯＳ−Ａ’の負荷値をＯＳ−Ａの負荷値に基づいて算出する。たとえば、ＯＳ−Ａ’の負荷値をＯＳ−Ａの負荷値に１以上の所定値、たとえば、「１．３」を乗じた値として初期設定登録してもよい。このような登録方法によれば、既に登録されている機能コンポーネントの負荷値を踏まえて、同系列に属する機能コンポーネントの負荷値を初期設定できる。機能の変更や追加がなされているＯＳ−Ａ’の負荷値は、一般的にはＯＳ−Ａの負荷値よりも大きくなると考えられるからである。

更に、ＯＳ−Ａ’を後継するＯＳであるＯＳ−Ａ”が新たに登録されるときでも同様である。このときには、負荷登録部１４８は、ＯＳ−Ａ’の負荷値に所定値、たとえば、「１．３」を乗じた値をＯＳ−Ａ”の負荷値として登録してもよい。また、負荷テーブル２５０にＯＳ−Ａは登録されているがＯＳ−Ａ’は登録されていない状態で、新たにＯＳ−Ａ”が登録されたとする。このときには、負荷登録部１４８はＯＳ−Ａの負荷値に、「１．３×１．３＝１．６９」を乗じた値をＯＳ−Ａ”の負荷値として登録してもよい。ある機能コンポーネントＡが負荷テーブル２５０に登録されている状態で、その機能コンポーネントと同一の製品系列に属する機能コンポーネントＢを新たに負荷テーブル２５０に登録するときには、負荷登録部１４８は機能コンポーネントＡと機能コンポーネントＢのバージョンの差の大きさにしたがった乗数により、機能コンポーネントＡの負荷値から機能コンポーネントＢの負荷値を算出してもよい。
ここでは、ＯＳを例として説明したが、ＯＳのようなソフトウェアに限らず、ハードウェアの機能コンポーネントについても同様である。

負荷補正部１５０は、負荷テーブル２５０に登録されている負荷値を事後的に補正する。負荷テーブル２５０における負荷値は、ユーザによる入力や負荷登録部１４８により設定されるが、このような負荷値は必ずしも実際の作業負荷に適合しているとは限らない。たとえば、新しいミドルウェアを導入するときには、通常、そのミドルウェアについての使用経験不足から、その導入負荷は高くなる傾向がある。しかし、そのミドルウェアについての使用実績や関連情報が蓄積されていくと相対的に導入負荷は軽減されていく傾向にある。負荷補正部１５０は、このような状況に対処するために負荷値を動的に補正する。

たとえば、あるミドルウェアＢが２００５年にリリースされたとする。負荷テーブル保持部１６８においては、ミドルウェアＢの負荷値だけではなくそのリリース年月日を記録してもよい。そして、負荷補正部１５０は、リリース年月日から所定期間、たとえば、１年間が経過したときに、ミドルウェアＢの負荷値を１以下の所定数、たとえば、０．８を乗じることにより、負荷値を自動的に減少させてもよい。

あるいは、あるミドルウェアＣがさまざまな実績システムにおいて計８個搭載されているとする。負荷テーブル保持部１６８においては、ミドルウェアＣの負荷値だけではなくその採用実績、この場合であれば、採用回数が登録されてもよい。そして、負荷補正部１５０は、採用回数が所定回数、たとえば、１０回を超えたときに、ミドルウェアＣの負荷値に１以下の所定数、たとえば、０．７を乗じることにより、負荷値を減少させてもよい。
このような処理方法によれば、採用実績の高い機能コンポーネントの負荷値を自動的に低減できるため、機能コンポーネント自体の難易度だけではなく、業務情報システムを設計する側の経験まで加味した負荷値とすることができる。なお、環境設定入力部１１４が設計システムの機能情報を取得したときに、負荷補正部１５０はその機能情報に含まれている機能コンポーネントの採用回数を適宜更新すればよい。

このほかにも、負荷調整部１４６は、機能コンポーネントの難易度に関する情報を外部装置から取得してもよい。たとえば、機能コンポーネントとその導入作業に実際に要した時間との対応関係が定められたデータが得られれば、負荷調整部１４６はいっそう合理的な負荷値を設定できる。

図７は、実績システムのシステム中継ポイントから見積式を特定する処理過程を示すフローチャートである。
方式見積式の特定を例として説明する。
方式見積式特定部１３０は、まず、検証対象となる実績システムを選択し（Ｓ１０）、システム中継ポイントＮを「０」に初期設定する（Ｓ１２）。方式見積式特定部１３０は、実績パターン保持部１７０を参照して、処理パターンを選択する（Ｓ１４）。中継ポイント計算部１２４は、選択された処理パターンのパターン中継ポイントとして、サーバ数Ｐを計数する（Ｓ１６）。中継ポイント計算部１２４は、システム中継ポイントＮにサーバ数Ｐを加算する（Ｓ１８）。

実績システムに更に別の処理パターンが含まれていれば（Ｓ２０のＹ）、処理はＳ１４に戻り、再び同じ処理を繰り返す。こうして、選択された実績システムについてのシステム中継ポイントが算出される。次に方式見積式特定部１３０は、選択された実績システムの方式実績工数を方式設計実績保持部１６２から取得する（Ｓ２２）。別の実績システムが登録されていれば（Ｓ２４のＮ）、処理は、Ｓ１０に戻り、再び同じ処理を繰り返す。このようにして、１以上の実績システムについてのシステム中継ポイントと方式実績工数のペアが特定される。
方式見積式特定部１３０は、これらのデータから線形単回帰分析により方式見積式の係数Ａ、Ｂを求めることにより、方式見積式を特定する（Ｓ２６）。

第１テスト見積式の特定についても同様である。方式見積式の場合、Ｓ２２において方式実績工数を取得したが、第１テスト見積式の場合、Ｓ２２においてはテスト実績工数が取得される。そして、Ｓ２６においては、テスト見積式特定部１３４は線形単回帰分析により第１テスト見積式の係数Ｅ、Ｆを求めることにより、第１テスト見積式を特定する。

図８は、実績システムのシステム導入ポイントから見積式を特定する処理過程を示すフローチャートである。
環境見積式の特定を例として説明する。
環境見積式特定部１３２は、まず、検証対象となる実績システムを選択し（Ｓ３０）、システム導入ポイントＲを「０」に初期設定する（Ｓ３２）。環境見積式特定部１３２は、実績機能保持部１７２を参照して、実績システムに含まれるサーバを選択する（Ｓ３４）。導入ポイント計算部１２６は、選択されたサーバのサーバ中継ポイントＳを負荷テーブル２５０と機能情報に基づいて計算する（Ｓ３６）。導入ポイント計算部１２６は、システム導入ポイントＲにサーバ導入ポイントＳを加算する（Ｓ３８）。

実績システムに更に別のサーバが含まれていれば（Ｓ４０のＹ）、処理はＳ３４に戻り、再び同じ処理を繰り返す。こうして、選択された実績システムについてのシステム導入ポイントが算出される。次に環境見積式特定部１３２は、選択された実績システムの環境実績工数を環境設計実績保持部１６４から取得する（Ｓ４２）。別の実績システムが登録されていれば（Ｓ４４のＮ）、処理は、Ｓ３０に戻り、再び同じ処理を繰り返す。このようにして、１以上の実績システムについてのシステム導入ポイントと環境実績工数のペアが特定される。
環境見積式特定部１３２は、これらのデータから線形単回帰分析により環境見積式の係数Ｃ、Ｄを求めることにより、環境見積式を特定する（Ｓ４６）。

第２テスト見積式の特定についても同様である。環境見積式の場合、Ｓ４２において環境実績工数を取得したが、第２テスト見積式の場合、Ｓ４２においてはテスト実績工数が取得される。そして、Ｓ４６においては、テスト見積式特定部１３４は線形単回帰分析により第２テスト見積式の係数Ｇ、Ｈを求めることにより、第２テスト見積式を特定する。

図９は、設計システムのシステム中継ポイントから見積工数を特定する処理過程を示すフローチャートである。
方式見積工数の特定を例として説明する。
方式工数計算部１３８は、まず、システム中継ポイントＮを「０」に初期設定する（Ｓ５０）。処理パターン入力部１１２は、設計システムの処理パターンを取得する（Ｓ５２）。中継ポイント計算部１２４は、選択された処理パターンのパターン中継ポイントとして、サーバ数Ｐを計数する（Ｓ５４）。中継ポイント計算部１２４は、システム中継ポイントＮにサーバ数Ｐを加算する（Ｓ５６）。

設計システムに更に別の処理パターンが含まれていれば（Ｓ５８のＹ）、処理はＳ１４に戻り、再び同じ処理を繰り返す。こうして、設計システムについてのシステム中継ポイントＮが算出される。方式工数計算部１３８は、方式見積式に設計システムのシステム中継ポイントを代入することにより、方式見積工数を算出する（Ｓ６０）。

第１テスト見積式によるテスト見積工数の特定についても同様である。方式見積工数の場合、Ｓ６０において方式見積式とシステム中継ポイントにより方式見積工数を算出したが、テスト見積工数の場合、Ｓ６０においてテスト工数計算部１４２は、第１テスト見積式とシステム中継ポイントによりテスト見積工数を算出する。

図１０は、設計システムのシステム導入ポイントから見積工数を特定する処理過程を示すフローチャートである。
環境見積工数の特定を例として説明する。
環境工数計算部１４０は、まず、システム導入ポイントＲを「０」に初期設定する（Ｓ７０）。環境設定入力部１１４は、設計システムの機能情報を取得し、導入ポイント計算部１２６は、まずサーバを選択する（Ｓ７２）。導入ポイント計算部１２６は、選択されたサーバのサーバ導入ポイントＳを負荷テーブル２５０と機能情報に基づいて計算する（Ｓ７４）。導入ポイント計算部１２６は、システム導入ポイントＲにサーバ導入ポイントＳを加算する（Ｓ７６）。

設計システムに更に別のサーバが含まれていれば（Ｓ７８のＹ）、処理はＳ７２に戻り、再び同じ処理を繰り返す。こうして、設計システムのシステム導入ポイントが算出される。環境工数計算部１４０は、環境見積式に設計システムのシステム導入ポイントを代入することにより環境見積工数を算出する（Ｓ８０）。

第２テスト見積式によるテスト見積工数の特定についても同様である。環境見積工数の場合、Ｓ８０において環境見積式とシステム導入ポイントにより環境見積工数を算出したが、テスト見積工数の場合、Ｓ６０においてテスト工数計算部１４２は、第２テスト見積式とシステム導入ポイントによりテスト見積工数を算出する。

以上、システム設計支援装置１００を実施例に基づいて説明した。
システム設計支援装置１００によれば、設計システムの処理パターンが定義された段階で、基盤設計における方式設計や基盤テストの工数を合理的かつ正確に見積もることができる。システム設計支援装置１００は、また、設計システムの機能情報が定義された段階で、基盤設計における環境設計構築や基盤テストの工数も合理的かつ正確に見積もることができる。システム設計支援装置１００は、たった１つの実績システムのデータからでも各種見積式を特定することができるが、実績システムに関するデータが充実するほど、より正確な見積式を特定しやすくなる。

本発明者らの調査によれば、システム中継ポイントと方式工数、システム中継ポイントとテスト工数、システム導入ポイントと環境工数、システム導入ポイントとテスト工数の関係は、いずれも線形単回帰分析により一次関数のかたちで見積式を求めることができることがわかった。しかし、業務情報システムの種類や業務情報システムの設計作業にかかわる作業グループによっては、非線形単回帰分析の方がより正確な見積式となる場合もあるかもしれない。いずれにしても、見積式特定部１２８は回帰分析により上記した各変数の関係を見積式として合理的に定式化できるため、どのようなタイプの回帰分析による見積式を採用するかは相関係数等を判断基準として選択すればよい。

また、基盤設計にかかわる作業者グループに応じて見積式を特定することにより、作業者のスキルまで考慮した工数見積が可能となる。更に、見積式補正部１４４による補正処理により、さまざまな作業グループの組み合わせについても見積式を適合させることができる。これは、基盤設計全体はもちろん、方式設計、環境設計構築、基盤テストのいずれについても応用可能である。

新バージョンの機能コンポーネントが登録されるとき、旧バージョンの機能コンポーネントの負荷値に基づいて、新バージョンの機能コンポーネントの負荷値を計算することにより、合理的な負荷値を自動的に初期設定することができる。特に、ソフトウェア機能コンポーネントの種類は膨大であるため、このような自動設定によればユーザの設定負担が大きく軽減される。

機能コンポーネントについて定められた条件、たとえば、採用実績やリリース日時などに関する条件が成立したとき、負荷補正部１５０は機能コンポーネントの負荷値を自動的に補正することができる。このため、機能コンポーネント自体の難易度だけではなく、機能コンポーネントに対する作業者の慣れまでも加味して、より実際的な負荷値を設定することができる。

以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

請求項に記載の処理装置は、本実施例においてはＤＢサーバ２１２、ＢＬサーバ２２２、ＰＬサーバ２３２等の各種サーバとして表現されている。請求項に記載の第１の業務情報システムおよび第２の業務情報システムは、本実施例においてはそれぞれ「実績システム」および「設計システム」が対応する。請求項に記載の第１処理パターン取得部と第２処理パターン取得部の機能は、本実施例においては主として処理パターン入力部１１２により実現される。請求項に記載の中継ポイントは、本実施例においては「システム中継ポイント」が対応する。請求項に記載の導入ポイントは、本実施例においては「システム導入ポイント」が対応する。また、請求項に記載の第１中継ポイント取得部や第２中継ポイント取得部の機能は、本実施例においては主として中継ポイント計算部１２４により実現されるが、処理パターン入力部１１２が実績システムのシステム中継ポイントを外部装置から取得してもよい。請求項に記載の負荷変更条件は、本実施例においてはリリース日時からの経過時間や採用実績として表現されているが、このほかにもいろいろな条件設定が可能であることは当業者には理解されるところである。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

業務情報システムのハードウェア構成図である。図２（ａ）は、パターン中継ポイント＝１の処理パターンを示す図である。図２（ｂ）は、パターン中継ポイント＝２の処理パターンを示す図である。図２（ｃ）は、パターン中継ポイント＝３の処理パターンを示す図である。図２（ｄ）は、パターン中継ポイント＝４の処理パターンを示す図である。サーバの階層図である。基盤設計の流れを示す図である。負荷テーブルのデータ構造図である。システム設計支援装置の機能ブロック図である。実績システムのシステム中継ポイントから見積式を特定する処理過程を示すフローチャートである。実績システムのシステム導入ポイントから見積式を特定する処理過程を示すフローチャートである。設計システムのシステム中継ポイントから見積工数を特定する処理過程を示すフローチャートである。設計システムのシステム導入ポイントから見積工数を特定する処理過程を示すフローチャートである。

符号の説明

１００システム設計支援装置、１１０ユーザインタフェース処理部、１１２処理パターン入力部、１１４環境設定入力部、１１６見積工数出力部、１２０データ処理部、１２２ポイント計算部、１２４中継ポイント計算部、１２６導入ポイント計算部、１２８見積式特定部、１３０方式見積式特定部、１３２環境見積式特定部、１３４テスト見積式特定部、１３６工数予測部、１３８方式工数計算部、１４０環境工数計算部、１４２テスト工数計算部、１４４見積式補正部、１４６負荷調整部、１４８負荷登録部、１５０負荷補正部、１６０データ保持部、１６２方式設計実績保持部、１６４環境設計実績保持部、１６６テスト実績保持部、１６８負荷テーブル保持部、１７０実績パターン保持部、１７２実績機能保持部、２００業務情報システム、２１２ＤＢサーバ、２２２ＢＬサーバ、２３２ＰＬサーバ、２４２ノード端末、２５０負荷テーブル。

Claims

複数の処理装置の連携により組織業務を管理するための業務情報システムのうち既に設計が完了している第１の業務情報システムについて、各種業務に関わる処理装置の組み合わせパターンを示す処理パターンを取得する第１処理パターン取得部と、
前記第１の業務情報システムにおける複数種類の処理パターンについて各処理パターンに関わる処理装置の数を合計した中継ポイントを取得する第１中継ポイント取得部と、
前記第１の業務情報システムにおける複数種類の処理パターンの実装に要した工数を実績工数として取得する実績工数取得部と、
前記第１の業務情報システムの中継ポイントと実績工数の相関関係を示す見積計算式を特定する見積計算式特定部と、
新たな設計の対象となる第２の業務情報システムについての処理パターンを取得する第２処理パターン取得部と、
前記第２の業務情報システムにおける複数種類の処理パターンから、前記第２の業務情報システムの中継ポイントを取得する第２中継ポイント取得部と、
前記第２の業務情報システムの中継ポイントと前記見積計算式から、前記第２の業務情報システムにおける複数種類の処理パターンの実装に要する工数を見積工数として算出する見積工数計算部と、
を備えることを特徴とするシステム設計支援装置。
前記見積計算式特定部は、既に設計が完了している複数の業務情報システムについての中継ポイントと実績工数の関係から、前記見積計算式を特定することを特徴とする請求項１に記載のシステム設計支援装置。
前記見積計算式特定部は、中継ポイントを説明変数、工数を目的変数として、回帰分析手法により前記見積計算式を特定することを特徴とする請求項２に記載のシステム設計支援装置。
前記見積計算式特定部は、前記見積計算式を線形回帰分析手法により特定することを特徴とする請求項３に記載のシステム設計支援装置。
前記見積計算式特定部は、第１の作業者グループの作業実績に基づく第１の見積計算式と第２の作業者グループの作業実績に基づく第２の見積計算式をそれぞれ算出し、第１の作業者グループに属する作業者と第２の作業者グループに属する作業者を共に含む作業者グループにより前記第２の業務情報システムの処理パターンが実装されるときには、第１の作業者グループに属する作業者数と第２の作業者グループに属する作業者数の構成比率に応じて、第１の見積計算式と第２の見積計算式から第３の見積計算式を特定することを特徴とする請求項１から４のいずれかに記載のシステム設計支援装置。
複数の処理装置の連携により組織業務を管理するための業務情報システムのうち既に設計が完了している第１の業務情報システムについて、各処理装置に導入される機能コンポーネントを示す機能情報を取得する第１機能情報取得部と、
処理装置への機能コンポーネントの導入にともなう作業負荷の大きさを示す負荷値を機能コンポーネントごとに対応づけた負荷テーブルを保持する負荷テーブル保持部と、
前記第１の業務情報システムにおける複数の処理装置について各処理装置に導入される機能コンポーネントの負荷値を合計した導入ポイントを取得する第１導入ポイント取得部と、
前記第１の業務情報システムにおける複数の処理装置への機能コンポーネントの導入に要した工数を実績工数として取得する実績工数取得部と、
前記第１の業務情報システムの導入ポイントと実績工数との相関関係を示す見積計算式を特定する見積計算式特定部と、
新たな設計の対象となる第２の業務情報システムについての機能情報を取得する第２機能情報取得部と、
前記第２の業務情報システムの機能情報と前記負荷テーブルから、前記第２の業務情報システムの導入ポイントを取得する第２導入ポイント取得部と、
前記第２の業務情報システムの導入ポイントと前記見積計算式から、前記第２の業務情報システムにおける複数の処理装置に対して機能コンポーネントを導入するのに要する工数を見積工数として算出する見積工数計算部と、
を備えることを特徴とするシステム設計支援装置。
前記見積計算式特定部は、既に設計が完了している複数の業務情報システムについての導入ポイントと実績工数から、前記見積計算式を特定することを特徴とする請求項６に記載のシステム設計支援装置。
前記見積計算式特定部は、導入ポイントを説明変数、工数を目的変数として、回帰分析手法により前記見積計算式を特定することを特徴とする請求項７に記載のシステム設計支援装置。
前記見積計算式特定部は、前記見積計算式を線形回帰分析手法により特定することを特徴とする請求項８に記載のシステム設計支援装置。
機能コンポーネントについてあらかじめ設定された負荷変更条件が成立したとき、前記負荷テーブルにおける負荷値を更新する負荷補正部、を更に備えることを特徴とする請求項６から９のいずれかに記載のシステム設計支援装置。
負荷テーブルにおいて負荷値を設定されている第１の機能コンポーネントと同系列に属する製品であって、第１の機能コンポーネントとはバージョンが異なる第２の機能コンポーネントの負荷値を、第１の機能コンポーネントの負荷値を変数とする所定演算を実行することにより算出し、新たに前記負荷テーブル登録する負荷登録部、を更に備えることを特徴とする請求項６から１０のいずれかに記載のシステム設計支援装置。
複数の処理装置の連携により組織業務を管理するための業務情報システムのうち既に設計が完了している第１の業務情報システムについて、各種業務に関わる処理装置の組み合わせパターンを示す処理パターンを取得する第１処理パターン取得部と、
前記第１の業務情報システムにおける複数種類の処理パターンについて各処理パターンに関わる処理装置の数を合計した中継ポイントを取得する第１中継ポイント取得部と、
前記第１の業務情報システムにおける動作確認テストの実行に要した工数を実績工数として取得する実績工数取得部と、
前記第１の業務情報システムの中継ポイントと実績工数の相関関係を示す見積計算式を特定する見積計算式特定部と、
新たな設計の対象となる第２の業務情報システムについての処理パターンを取得する第２処理パターン取得部と、
前記第２の業務情報システムにおける複数種類の処理パターンから、前記第２の業務情報システムの中継ポイントを取得する第２中継ポイント取得部と、
前記第２の業務情報システムの中継ポイントと前記見積計算式から、前記第２の業務情報システムにおける動作確認テストの実行に要する工数を見積工数として算出する見積工数計算部と、
を備えることを特徴とするシステム設計支援装置。
複数の処理装置の連携により組織業務を管理するための業務情報システムのうち既に設計が完了している第１の業務情報システムについて、各処理装置に導入される機能コンポーネントを示す機能情報を取得する第１機能情報取得部と、
処理装置への機能コンポーネントの導入にともなう作業負荷の大きさを示す負荷値を機能コンポーネントごとに対応づけた負荷テーブルを保持する負荷テーブル保持部と、
前記第１の業務情報システムにおける複数の処理装置について各処理装置に導入される機能コンポーネントの負荷値を合計した導入ポイントを取得する第１導入ポイント取得部と、
前記第１の業務情報システムにおける動作確認テストに要した工数を実績工数として取得する実績工数取得部と、
前記第１の業務情報システムの導入ポイントと実績工数との相関関係を示す見積計算式を特定する見積計算式特定部と、
新たな設計の対象となる第２の業務情報システムについての機能情報を取得する第２機能情報取得部と、
前記第２の業務情報システムの機能情報と前記負荷テーブルから、前記第２の業務情報システムの導入ポイントを取得する第２導入ポイント取得部と、
前記第２の業務情報システムの導入ポイントと前記見積計算式から、前記第２の業務情報システムにおける動作確認テストに要する工数を見積工数として算出する見積工数計算部と、
を備えることを特徴とするシステム設計支援装置。