JP6799246B2 - 管理サーバ、制御方法、プログラム - Google Patents

Description

本発明は、社員の経歴情報を表示する技術に関する。

取引先の企業の担当者の経歴等の情報を収集・蓄積しておき、その情報を様々な企業活動に活用する仕組みが構築されている。

特に営業活動において、交渉相手となる担当者の情報を把握することは非常に重要であり、取引先の担当者のことを知ることによって、有効な営業戦略や攻略計画を立案することができる。

また自社内でも、社員（役員を含む）の経歴等の情報を蓄積、活用することにより、適切な人材配置や、円滑な人事異動を実施することができる。

特許文献１には、各社員の所属部門、職位、資格、職種及び勤務地の異動履歴を異動年月と共にコード化した社歴データに基づいて、同一の部門、職位、資格、職種又は勤務地の滞留年数が長い社員を異動対象者の候補として抽出することにより、人材の再配置シミュレーションを実施する技術が開示されている。

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

しかし、特許文献１による方法は、各社員の現時点での部門や職位に対する滞留年数を算出し、滞留年数の長い社員を抽出するものであり、過去の経歴の変遷をわかりやすく提示するものではない。また、特許文献１による方法は、同一企業内での異動を対象としており、転職や出向等による複数の企業間での異動は考慮されていない。

そこで、本発明は、社員等の組織の人員の経歴情報を表示させる場合に、任意の期間における当該人員の兼務状況をわかりやすく提示することが可能な仕組みを提供することを目的とする。

本発明の管理サーバは、組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバであって、組織の人員の経歴情報を取得する取得手段と、前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御手段とを備え、前記表示制御手段は、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とする。

本発明の制御方法は、組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバの制御方法であって、取得手段が、組織の人員の経歴情報を取得する取得ステップと、表示制御手段が、前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御ステップとを備え、前記表示制御ステップでは、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とする。

本発明のプログラムは、組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバにおいて実行可能なプログラムであって、前記管理サーバを、組織の人員の経歴情報を取得する取得手段と、前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御手段として機能させ、前記表示制御手段は、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とする。

本発明によると、社員等の組織の人員の経歴情報を表示させる場合に、任意の期間における当該人員の兼務状況をわかりやすく提示することができるようになる。

本発明の実施形態である取引先情報管理システムのシステム構成の一例を示すブロック図。 本発明の実施形態である取引先情報管理システムを構成するクライアント端末、サーバに適用可能なハードウェア構成の一例を示すブロック図。 本発明の実施形態である取引先情報管理システムに機能構成の一例を示すブロック図。 本発明の実施形態である取引先情報管理システムで使用する取引先テーブルの一例を示すデータ構成図。 本発明の実施形態である取引先情報管理システムで使用する担当者テーブルの一例を示すデータ構成図。 本発明の実施形態である取引先情報管理システムで使用する経歴テーブルの一例を示すデータ構成図。 本発明の実施形態である取引先情報管理システムで使用する処理用データの一例を示すデータ構成図。 本発明の実施形態である取引先情報管理システムの取引先画面の一例を示す画面イメージ。 本発明の実施形態である取引先情報管理システムの担当者画面の一例を示す画面イメージ。 本発明の実施形態である取引先情報管理システムの経歴画面の一例を示す画面イメージ。 本発明の実施形態である取引先情報管理システムの経歴図画面の一例を示す画面イメージ。 本発明の実施形態である取引先情報管理システムで表示する取引先経歴図の一例を示す表示イメージ。 本発明の実施形態である取引先情報管理システムで表示する個人経歴図の一例を示す表示イメージ。 本発明の実施形態である取引先情報管理システムで表示する取引先経歴図の一例を示す表示イメージ。 本発明の実施形態である取引先情報管理システムの処理フローの一例を示すフローチャート。 本発明の実施形態である取引先情報管理システムの処理フローの一例を示すフローチャート。 本発明の実施形態である取引先情報管理システムの処理フローの一例を示すフローチャート。 本発明の実施形態である取引先情報管理システムの処理フローの一例を示すフローチャート。 本発明の実施形態である取引先情報管理システムの処理フローの一例を示すフローチャート。

図１は、本発明の実施形態の取引先情報管理システムのシステム構成の一例を示すブロック図である

取引先情報管理システム１００は、クライアント１０１、サーバ１０２、ネットワーク１０３より構成される。

クライアント１０１は、ユーザからの要求を受けて、サーバ１０２に対して処理要求を行い、サーバ１０２からの処理結果を表示する。クライアント１０１はＷＥＢブラウザを装備しており、当該ＷＥＢブラウザを介して上記処理を行う。また、ＷＥＢブラウザではなく、専用のクライアントプログラムを介して上記処理を行ってもよい。

サーバ１０２は、クライアント１０１からの処理要求を受けて、各種処理を実行し、画面表示用データを作成して、クライアント１０１の表示装置に表示させる。

ネットワーク１０３は、クライアント１０１とサーバ１０２を連携させる。ネットワーク１０３は、インターネットであってもよいし、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよい。

図２は、図１のクライアント１０１、サーバ１０２に適用可能なハードウェア構成の一例を示すブロック図である。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。なお、図２では、ＣＲＴ２１０と記載しているが、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるＣＦカードメモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したネットワーク１０３）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。

図３は、本発明の実施形態の取引先情報管理システムの機能構成の一例を示すブロック図である。

取引先情報管理システム１００は、クライアント１０１、サーバ１０２を持つ。

クライアント１０１は、入力受付部３１１、画面表示部３１２を持つ。

入力受付部３１１は、画面を介してユーザからの入力を受け付け、サーバ１０２に入力されたデータを送信する機能部である。画面表示部３１２は、サーバ１０２から受信した画面表示データをもとに画面を表示する機能部である。

サーバ１０２は、経歴図表示制御部３２１、取引先情報管理部３２２、担当者情報管理部３２３、経歴情報管理部３２４を持つ。

経歴図表示制御部３２１は、図１５から図１９に示す処理を実行することにより、経歴図を表示するための画面データを作成し、クライアント１０１に表示させるために画面データを送信する。

取引先情報管理部３２２は、図４に示す取引先テーブルをデータベースに格納し、その内容をメンテナンスする機能部である。

担当者情報管理部３２３は、図５に示す担当者テーブルをデータベースに格納し、その内容をメンテナンスする機能部である。

経歴情報管理部３２４は、図６に示す経歴テーブルをデータベースに格納し、その内容をメンテナンスする機能部である。

本実施例の機能構成では、サーバ１０２の処理はＷｅｂアプリケーションの形態で提供され、クライアント１０１が装備するＷｅｂブラウザを使用して当該Ｗｅｂアプリケーションにアクセスする形態となる。なお、サーバ１０２と、クライアント１０１の接続形態はＷｅｂアプリケーション形式ではなく、クライアント１０１が専用プログラムを備えたサーバ・クライアント形式でもよい。

以下、図を参照して、取引先情報管理システムで使用するデータテーブルの一例について説明する。

図４は、取引先テーブル４００の一例を示すデータ構成図である。

取引先テーブル４００は、取引先となる顧客企業の情報を格納し、項目として、取引先ＩＤ４０１、会社名４０２、略称４０３、企業グループ４０４、親会社ＩＤ、業種４０６を持つ。

取引先ＩＤ４０１は、取引先を一意に識別する英数字列であり、会社名が変更されたとしても法人として同じであれば同一のＩＤを使用する。会社名４０２は、取引先の現在の会社名である。略称４０３は、取引先の現在の会社名の略称である。

企業グループ４０４は、取引先が属する企業グループを示し、企業グループの名称か、企業グループを表すコードを設定する。親会社ＩＤ４０５は、取引先の親会社の取引先ＩＤ４０１を設定する。業種４０６は、取引先が属する業種である。

図５は、担当者テーブル５００の一例を示すデータ構成図である。

担当者テーブル５００は、取引先の担当者である役員や従業員の情報を格納し、項目として、担当者ＩＤ５０１、名前５０２、自社との関係５０３、略称５０４を持つ。

担当者ＩＤ５０１は、担当者を一意に識別する英数字列であり、転職や出向で会社を変わった場合も同一のＩＤを使用する。名前５０２は、担当者の名前である。

自社との関係５０３は、取引先情報管理システムを使用するユーザの属する会社に対して、担当者がどのような関係にあるかを示す情報であり、「普通」、「良好」、「険悪」等を設定する。略称５０４は、担当者の名前の略称である。

図６は、経歴テーブル６００の一例を示すデータ構成図である。

経歴テーブル６００は、各担当者の異動、昇進、転職等に伴う経歴の情報を格納し、項目として、経歴ＩＤ６０１、担当者ＩＤ６０２、着任日６０３、離任日６０４、取引先ＩＤ６０５、在任時会社名６０６、在任時会社略称６０７、兼務フラグ６０８、部署６０９、役職６１０、役職階層６１１、順序６１２を持つ。

経歴ＩＤ６０１は、経歴を一意に識別する英数字列である。担当者ＩＤ６０２は、担当者を表し、担当者テーブル５００の担当者ＩＤ５０１に対応する。着任日６０３は、当該経歴に着任した日である。離任日６０４は、当該経歴から離任した日であり、当該経歴が現在も継続中であれば「−」を設定する。

取引先ＩＤ６０５は、当該経歴時に担当者が属していた取引先を表し、取引先テーブル４００の取引先ＩＤ４０１に対応する。在任時会社名６０６は、当該経歴時の取引先の会社名である。在任時会社略称６０７は、当該経歴時の取引先の会社名の略称である。

兼務フラグ６０８は、当該経歴が担当者にとって兼務か否かを表し、兼務の場合は「ＯＮ」、主務の場合は「ＯＦＦ」を設定する。部署６０９は、当該経歴時の部署であり、代表や役員の場合など特定の部署に属さない場合はブランクとなる。

役職６１０は、当該経歴時の役職である。役職階層６１１は、役職のクラス（レベル）を表し、「代表クラス」から「社員クラス」まで分類する。順序６１２については図８にて後述する。

次に、図を参照して、上記テーブルのレコードを管理するための画面の一例を説明する。

図８は、取引先テーブル４００の情報の入力／表示画面である取引先画面８００の一例である。

取引先の会社名８０１、図面内に表示する際に使用する略称８０２、系列会社を識別する情報、その他取引先に固有の情報を登録する。

系列会社を識別する情報の登録方法としては、所属する企業グループ８０３を入力させる方法と親会社８０４として取引先テーブル４００に存在する別の取引先を指定させる方法の二種類が考えられる。採用する方法によって、企業グループ８０３または親会社８０４のどちらか一方を用意すれば良い。

取引先画面８００の下部には取引先に所属する担当者の一覧８０７を表示する。

表示する担当者は経歴テーブル６００から現在有効な経歴（離任日６０４が空欄のもの）で取引先ＩＤ６０５が表示対象の取引先であるレコードを抽出し、担当者ＩＤ６０２に該当する担当者テーブル５００レコードと連結した情報である。

担当者の一覧８０７の列は並び順（順序列８１６）を編集でき、設定した並び順は経歴レコードの順序６１２に番号で格納される。例えば、最上位に会長、次に社長、次に複数存在する取締役の中でも発言力の強い順、等、並び順を取引先の中での各担当者の序列に従って定義しておくことにより、後述の取引先経歴図（例えば図１２）上でも取引先担当者の序列を表現することができる。

図９は担当者テーブル５００情報の入力／表示画面である担当者画面９００の一例であ。

担当者の名前９０１、図面内に表示する際に使用する略称９０２、自社との関係性を示す値９０３など担当者個人に関わる情報を登録する。

自社との関係性を示す値は「良好／普通／険悪／不明」などの値をあらかじめ定義した中から選択する。例えば自社製品の愛用者であるとか、継続的に取引があり信頼関係が構築されている場合は「良好」を設定し、以前トラブルで迷惑をかけた相手で関係が修復されていない場合は「険悪」を設定する。

担当者画面９００の下部には担当者の経歴一覧９０４を表示し、追加編集もできる。

経歴一覧９０４には経歴テーブル６００から担当者ＩＤ６０２が表示対象の担当者であるレコードを抽出し、着任日６０３および兼務フラグ６０８でソートしたレコードを表示する。

担当者画面９００の経歴一覧９０４の会社名列９１３には経歴テーブル６００の取引先ＩＤ６０５に該当する取引先テーブル４００レコードの会社名４０２値を表示するが、在任時会社名列９１３および在任時会社略称列９１４には取引先テーブル４００レコード項目値ではなく、経歴テーブル６００レコードの在任時会社名６０６項目値および在任時会社略称６０７項目値を表示する。

一方、経歴レコード追加／編集時には、会社名列９１３の値は取引先テーブル４００に登録されたレコードから選択させ、在任時会社名列９１３および在任時会社略称列９１４にも選択したレコードの会社名４０２および略称４０３をデフォルト値として設定する。在任時会社名列９１３および在任時会社略称列９１４は編集可能とし、過去の経歴レコードを登録する際に、必要であれば過去の会社名、略称を手入力できる。

これにより、在任時と現在で取引先の社名が変わっている場合にも取引先の現在レコードとの参照関係を維持しながら、在任当時の社名を保持することができる。

例えば、担当者画面９００の「山田太郎」氏の場合、１９９５年に現在のＣＨＤ株式会社に入社した経歴９２６（該当の経歴レコードは経歴テーブル６００の６２６）を持つが、１９９５年当時ＣＨＤ株式会社はＣ販売株式会社という社名であったため、在任時会社名列９１３および在任時会社略称列９１４にはそれぞれ「Ｃ販売株式会社」「Ｃ販売」と入社当時の社名が保持されている。

担当者画面９００の経歴一覧９０４の兼務列９１５には該当する経歴が主務のものであるか、兼務のものであるかを示す値を設定する。例えば、担当者画面９００の山田太郎氏の場合、現在在任中（離任日９１２列が空欄）の経歴がＣ商事株式会社の会長（９２１の行）とＣスタッフ株式会社（Ｃスタッフ）の取締役（９２３の行）の２つ存在するため、Ｃ商事株式会社の会長を主務（兼務列９１５の値ＯＦＦ）、Ｃスタッフ株式会社の取締役を兼務（兼務列９１５の値ＯＮ）と定義して区別できる。

尚、本実施例では主務と兼務の２種類だけを管理対象としてフラグ形式で管理しているが、３つ以上の職務を同時期に兼任するような状態を管理したい場合は、ＯＮ／ＯＦＦのフラグ形式ではなく、「主務／兼務１／兼務２／兼務３／、、、」といった様に複数の種別から選択できるようにすれば良い。

担当者画面９００の経歴一覧９０４では他に部署９１６および役職９１７も設定できる。

また、実際の役職名（名刺記載の肩書名等）とは別に役職階層９１８を設定できる。役職階層９１８とは経歴テーブル６００の役職階層６１１のように、企業内の地位を大まかに序列化したものである。昨今の企業で使われる肩書が多様になっており、また、役職の階層数も企業によって様々である。例えば、取引先の代表者の場合、「社長」「会長」「ＣＥＯ」等がある。また、「部長」「課長」といった一般的な肩書ならば問題ないが、「チーフ」「主任」「リーダー」「マネージャー」「主事」といった肩書となると、他社の人間がそれらの正確な立ち位置を判断するのは困難であるが、大まかに「５．課長クラス」「４．部長クラス」等に分類しておくことで、管理がしやすくなる他、後に説明する取引先経歴図（図１２）の表示範囲を指定する条件としても利用できる。

経歴テーブル６００のレコードは上記のように担当者画面９００中の経歴一覧９０４で一括編集する他に、図１０に示す経歴画面１０００のように単独レコード単位で表示編集もできる。

次に、このように登録したレコードから図１２に示す取引先経歴図および図１３に示す個人経歴図を生成する方法について説明する。

図１１は取引先経歴図の表示機能を組み込む画面の一例である。

表示対象の取引先１１０１、表示に含める経歴の対象期間を示す表示期間Ｔｏ１１０２および表示期間Ｆｒｏｍ１１０３、表示に含める対象の役職階層を示す表示役職階層範囲１１０４を指定して経歴図表示ボタン１１０６を実行することで、経歴図表示領域１１０５に経歴図が表示される。

また、別の方法として、取引先画面８００に取引先経歴図表示ボタン８０８を配置して画面表示中の取引先を対象とした取引先経歴図を別画面で表示する方法なども考えられる。

個人経歴図については、担当者画面９００上に個人経歴図表示ボタン９０５を配置する方式を一例としてあげる。

個人経歴図例１３００は担当者画面９００に表示したＣ商事株式会社の会長「山田太郎」氏の経歴を図式化した例である。

左端に年列１３０１を配置し、次列を主務列１３１１として主務の経歴を年列１３０１に合わせた在任期間の範囲で表示する。右列は兼務列１３１２として兼務の経歴を同様に表示する。各経歴枠の中には在任時会社略称（経歴テーブル６００の６０６）値、および役職（経歴テーブル６００の６１０）を表示する。また、各経歴枠の背景を現在有効な主務の経歴の取引先を基準として「当該取引先」であるか「当該取引先の系列会社」であるか「系列外の会社」であるかを判別できる背景色を設定する。例えば、「山田太郎」氏の場合、現在有効な主務の経歴はＣ商事株式会社の会長であるため、「Ｃ商事株式会社」が基準となる。経歴枠１３２１〜１３２４はＣ商事株式会社での経歴であるため「当該取引先」を示す背景白、であるのに対し、経歴枠１３２５はＣ商事株式会社の親会社であるＣ販売株式会社（現ＣＨＤ株式会社）での経歴であるため、また、兼務の経歴枠１３２６の経歴についてはＣ商事株式会社の子会社であるＣスタッフ株式会社（Ｃスタッフ）の経歴であるため、どちらも「当該取引先の系列会社」を示す背景網掛けとなる。

また、経歴枠１３２６のＣスタッフの取締役着任以前には兼務の経歴が存在しないため、空欄１３２７として表示される。

各経歴枠（例えば１３２５）をクリックすることで、該当する経歴レコードを表示する経歴画面１０００に遷移し、詳細な情報の確認および編集ができる。

表示されている情報自体は担当者画面９００の経歴一覧９０４と同じものではあるが、図式化することで、各経歴の在任期間や出向転職歴、兼務状態などが視覚的に把握しやすくなる。

例えば、個人経歴図例１３００では社長在任経歴を示す経歴枠１３２２により「山田太郎」氏の主務の経歴の中で社長在任期間が長いことがすぐに認識できるが、担当者画面９００の経歴一覧９０４の社長在任経歴９２２から同様の情報を認識するには、全経歴の着任日と離任日から在任期間を計算して経歴間で比較する必要がある。また、Ｃスタッフ取締役の経歴が兼務であり、主務であるＣ商事での取締役、社長、会長の在任期間に重複していることなども、担当者画面９００の経歴一覧９０４のＣスタッフ取締役在任経歴９２３だけでは把握しづらいが、個人経歴図例１３００の経歴枠１３２６のように図式化することで容易に判別できる。

また、個人経歴図例１３００の中で会社名を略称で表示することで、「株式会社」といった文字が図の中にいくつも表示されて文字だらけで見にくい図になることを防ぐことができる。会社名だけでなく、役職名や部署名について略称を設定しても同様の効果が見込まれる。

図１２は、担当者の経歴図を取引先単位でまとめて図式化した取引先経歴図の一例である。

前述のＣ商事株式会社の会長「山田太郎」氏の経歴列１２１１、１２１２に続けて、同じくＣ商事株式会社に現在有効な経歴が設定されている、取締役「佐藤三郎」氏の経歴列１２１３、取締役「田中一郎」氏の経歴列１２１４、１２１５、取締役「渡辺四郎」氏の経歴列１２１６、部長「鈴木次郎」氏の経歴列１２１７、課長「ジェームズ アンダーソン」氏の経歴列１２１８が表示される。

図１２の例では対象取引先Ｃ商事株式会社のすべての役職階層および期間を表示対象としているため、取引先画面８００の担当者一覧８０７記載の担当者がすべて表示されているが、図１１の画面を利用して条件を設定すると、表示される範囲を制限することができる。例えば、図１１の画面の表示役職階層範囲１１０４に示されているように「代表クラス」と「役員クラス」だけを対象とする条件を設定して表示した場合は、部長「鈴木次郎」氏、課長「ジェームズ アンダーソン」氏の各経歴列１２１７、１２１８は条件に該当しないため表示されない。期間についても同様である。この機能により、対象の取引先に多数の担当者および経歴情報が設定されている場合でも、対象を絞り込んで経歴図を表示することができ、表示速度が遅くなることを防ぐ効果がある。

担当者の並び順については、各担当者の対象取引先における現在有効な経歴レコードに設定された順序項目値（経歴テーブル６００の６１２）を適用する。これにより、山田会長→佐藤取締役→田中取締役→渡辺取締役→鈴木部長→ジム課長と、取引先画面８００の担当者一覧８０７の並び順で定義した取引先の中での各担当者の序列を経歴図上でも表現できる。

各経歴列の先頭行の１２０２には各担当者の名前の略称値（担当者テーブル５００の５０４）を表示する。

これにより、「ジェームズ アンダーソン」氏のような長い名前の担当者がいても、経歴図中では「ジム」という略称を表示することにより、特定の担当者の列だけが幅を取ったり、幾段にも折り返しして高さを取ったり、「ジェーム．．」のように中途半端に省略されてわかりにくくなったりすることを防ぐ効果がある。もちろん、字数に問題がなければ「佐藤三郎」や「渡辺四郎」のように略称にそのまま本名を設定することも可能である。

各経歴列の二番目の行の１２０３には担当者毎に設定した自社との関係項目値（担当者テーブル５００の５０３）値を示すマークを表示する。図１２の例では、顔文字を使用して良好、普通、険悪を表現したが、良好＝「晴れ」、険悪＝「雷雨」を表すアイコンで表現しても良い。

取引先経歴図例１２００の各経歴枠の背景色には先に記述した個人経歴図例１３００と同様に、「当該取引先」（白塗）であるか「当該取引先の系列会社」（網掛け）であるか「系列外の会社」（黒塗り）であるかを判別できる色を設定する。ただし、「当該取引先」は各担当者の現在の主務ではなく、経歴図の表示条件に指定した取引先（図１２の例の場合「Ｃ商事株式会社」）とする。

また、「当該取引先」に該当する経歴枠中は社名の表示を省略している。

取引先経歴図においても個人経歴図と同様に各経歴枠をクリックすることで、該当する経歴レコードを表示する経歴画面１０００に遷移し、詳細な情報の確認および編集ができる。また、同様に担当者名行１２０２の各担当者名（例えば「山田（太）」）をクリックすることで、該当する担当者レコードを表示する担当者画面９００に遷移し、画面タイトルの取引先名（例えば「Ｃ商事株式会社」）のクリックにより、取引先画面８００に遷移する。

背景色の違いにより、社外取締役、出向状況、転職履歴などの判別が容易となる。例えば、「田中」氏の主務列（１２１４）のＡ銀行の取締役の経歴枠が「系列外の会社」を示す黒塗りであることから、「田中」氏の本業がＡ銀行の取締役であり、兼務列１２１５に表示されているＣ商事の取締役は社外取締役としての兼任していることがわかる。

一方、図１４に示す「田中」氏の本業であるＡ銀行の取引先経歴図例１４００では表示内容が次のようになる。Ａ銀行を「当該取引先」とした取引先経歴図例１４００では、「田中」氏の主務列１４１３のＡ銀行の取締役の経歴枠が「当該取引先」を示す白塗りとなって社名表示が省略され、兼務列１４１４のＣ商事の取締役の経歴枠が「系列外の会社」を示す黒塗りでの表示となる。
図１２の説明に戻る。

また、「渡辺」氏の経歴列１２１６の中のＣスタッフ 社長の経歴枠は「当該取引先の系列会社」を示す網掛けであることから、転職して出戻ったわけではなく、系列会社に出向していた状態であることがわかる。一方で「鈴木」氏の経歴列１２１７の最下部にあるＭ証券の社員の経歴は「系列外の会社」を示す黒塗りであることから「鈴木」氏はＣ商事株式会社には新卒入社ではなく、Ｍ証券から転職して中途入社した経歴の持ち主であることがわかる。

また、取引先経歴図によって複数の担当者の経歴を一画面で確認できることにより、営業戦略に役立つ取引先固有の情報を把握できる場合もある。

例えば、図１２の表示例の場合、「営業」という文字が頻出している。役員以上だけを見ても、会長の「山田」氏の経歴列１２１１を見ると「国内『営業』本部 本部長」「『営業』部 部長」「Ｃ販売 『営業』部 部長」と営業畑の出身であることがわかり、また、取締役「渡辺」氏の経歴列１２１６にも「『営業』部 部長」「『営業』部『営業』課 課長」とあり、「渡辺」氏もまた営業畑であることから、現在Ｃ商事株式会社では営業の勢力が強いことが推測される。また、現在「営業部 部長」である「鈴木」氏の経歴列１２１７を見ると部長昇進前は「営業部営業課 課長」であり、「渡辺」氏と同じ昇進履歴を辿っていること、また、「営業部 部長」は会長の「山田」氏も経験したポストであることから、将来「鈴木」氏が取締役に昇進する可能性が高いという推測が成り立つ。

その場合、営業戦略として現在は部長クラスであるものの、将来有望な「鈴木」氏とのコネクションを強化しておく等の対策を取ることができる。

尚、本明細書の記載例で年を縦に降順（現在を上に、過去を下に）で配置し、担当者を横に並べているが、いわゆる歴史年表式に年を昇順（過去を上に、現在を下に）に並べても良いし、ガントチャート式に年を横に配置する方式（過去を左に、現在を右に）としても良い。

以下、図を参照して、取引先情報管理システムにて経歴図を生成する処理について説明する。

以下の処理は、サーバ１０２にて実行されるが、データ入力や画面表示はクライアント１０１の入力受付部３１１、画面表示部３１２にて実行される。

図１５、図１６は本発明による取引先経歴図生成処理の一例を示すフローチャートである。図１１の条件画面にて取引先１１０１、表示期間Ｔｏ１１０２、表示期間Ｆｒｏｍ１１０３、表示役職階層範囲１１０４を指定して経歴図表示ボタン１１０６を実行した場合に、図１５、図１６のフローチャートの処理を開始する。ここでは、図１１記載の「Ｃ商事株式会社」の経歴図を生成する場合を例に説明する。

まず、ステップＳ１０１において経歴図に表示される担当者を検出する。具体的には、経歴テーブル６００から取引先ＩＤ６０５が経歴図画面１１００で指定された取引先１１０１であり、役職階層６１１が条件画面で指定された表示役職階層範囲１１０４に含まれ、かつ、離任日６０４が空欄となっている現在有効な経歴のレコードを取得する。これにより、経歴図に表示される取引先に現在在任中であり、指定された役職階層の担当者が検出できる。ここで取得された経歴レコードの担当者が生成対象の経歴図に表示される担当者となる。

本例の場合、経歴テーブル６００から「山田」氏のＣ商事の会長経歴レコード６２１、「鈴木」氏のＣ商事の営業部部長経歴レコード６２７、「田中」氏のＣ商事の取締役経歴レコード６３１、「ジム」氏のＣ商事の営業部第一課課長経歴レコード６３３、「佐藤」氏のＣ商事の取締役経歴レコード６３５、および「渡辺」氏のＣ商事の取締役経歴レコード６３８の６レコードが取得される。

また、この際に、表示対象担当者の序列を反映するために、対象レコードを順序６１２の値でソートする。これにより、本例の場合、「山田」氏→「佐藤」氏→「田中」氏→「渡辺」氏→「鈴木」氏→「ジム」氏の序列となる。

次に、ステップＳ１０２において各担当者の略称と自社との関係値を取得する。具体的には、ステップＳ１０１において取得した経歴レコードの担当者ＩＤ６０２に該当するレコードを担当者テーブル５００から取得する。本例の場合、レコード５２１（「山田」氏）〜５２６（「渡辺」氏）が取得される。

ここで取得したレコードに含まれる各担当者の略称５０４および自社との関係５０３が生成する経歴図のヘッダ部に表示される。

ステップＳ１０３において、表示対象の経歴レコードをすべて取得する。具体的には、経歴テーブル６００から担当者ＩＤ６０２値がステップＳ１０１において取得した経歴レコードの担当者ＩＤ６０２値に該当し、かつ、経歴図画面１１００で指定した表示期間Ｆｒｏｍ１１０３から表示期間Ｔｏ１１０２の間に在任期間（着任日６０３および離任日６０４の期間）が含まれるレコードを取得する。また、ここでもステップＳ１０１において指定した対象担当者の序列順かつ着任日６０３の降順かつ兼務フラグ６０８順（ＯＦＦ→ＯＮ）でソートする。

本例では、レコード６２１〜６４１が取得されて、一時的にＲＡＭ２０３に格納され、ソートの結果、図７の並び順となる。

ステップＳ１０４において、ステップＳ１０３で取得した経歴レコード群７００の中で一番古い着任日６０３値を検出する。本例の場合、レコード７３９の着任日６０３値「１９９０／０４／０１」が検出される。

ステップＳ１０５において経歴図に表示される月数および年数を算出する。具体的にはステップＳ１０４において検出した一番古い着任日項目値（本例では上記「１９９０／０４／０１」）または経歴図画面１１００で指定した表示期間Ｆｒｏｍ１１０３（本例では「１９９０／０１／０１」）のうち新しい日付（本例では「１９９０／０１／０１」＜「１９９０／０４／０１」であるため「１９９０／０４／０１」を採用）と、経歴図画面１１００で指定した表示期間Ｔｏ１１０２（本例では「現在」を２０１６年８月とする）の間の月数および年数を算出する。

ステップＳ１０６においてステップＳ１０５で算出した月数分の行（および、担当者名行１２０２と自社との関係アイコンを表示する行１２０３）を経歴図に作成する。

ステップＳ１０７において、経歴図の左に年列１２０１を作成し、年に相当する月数分の行を連結し、年値を表示する。本例では、１９９０／０４〜２０１６／０８であるため、１９９０年から２０１６年までの年列となる。

ステップＳ１０８においてステップＳ１０３で取得し、ソートした経歴レコード群７００の先頭レコードを現在レコードする。本例では、７２１の「山田」氏のＣ商事会長経歴レコードとなる。

ステップＳ１０９において、ステップＳ１０３（繰り返し処理の場合は、ステップＳ１２４）で取得したレコードに該当する担当者列（図１２の例の場合、「山田」氏の主務列１２１１）を経歴図に追加する。ステップＳ１０２で取得しておいた担当者レコードの該当する担当者の情報（本例では「山田」氏レコード５２１）から、担当者名行１２０２に略称５０４項目値（本例では「山田（太）」）を表示し、該当担当者の担当者画面９００への遷移情報（Ｗｅｂシステムの場合ＵＲＬ等）を設定しておく。自社との関係アイコン行１２０３に自社との関係５０３項目値（本例では「普通」）に相当するアイコン（顔文字）を表示する。

ステップＳ１１０において、経歴図画面１１００で指定した表示期間Ｔｏ１１０２の値を変数「開始年月」に格納する。本例では、現在を２０１６年８月とするため「２０１６／０８」とする。

ステップＳ１１１において、空白期間の有無を判定する。具体的には、ステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの離任日６０４値が現在を示す空欄以外でステップＳ１１０（繰り返し処理の場合はステップＳ１２２）で変数「開始年月」に格納した値より小さい場合、経歴図の最上部または一つ前の経歴枠の下部（着任日）と当該経歴の離任日の間に空白期間があると判断し、ステップＳ１１３に進む。

上記条件に該当せず、空白期間がないと判断された場合はステップＳ１１２に進む。本例ではレコード７２１の離任日が現在を示す空欄であるため空白期間を設定せずそのままステップＳ１１２に進む。

ステップＳ１１１からステップＳ１１２に進んだ場合、変数「開始年月」が示す行からステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの着任日６０３値が示す年月の行（ただし、着任年月が図１１の条件画面で指定した表示期間Ｆｒｏｍ１１０３値より前である場合は表示期間Ｆｒｏｍ１１０３値の年月の行）までを連結し、経歴枠を作成する。

本例では、レコード７２１の着任日６０３の値が「２０１４／０４／０１」であり、表示期間Ｆｒｏｍ１１０３値「１９９０／０１／０１」より後であることから、開始年月「２０１６／０８」から「「２０１４／０４」までの行を連結した経歴枠（図１２の１２１１列先頭の「会長」経歴枠）が作成される。

もしステップＳ１１１からステップＳ１１３に進んだ場合は、変数「開始年月」が示す行からステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの離任日６０４値が示す年月の行（ただし、着任年月が図１１の条件画面で指定した表示期間Ｆｒｏｍ１１０３値より前である場合は表示期間Ｆｒｏｍ１１０３値の年月の行）までを連結し、空白期間枠を作成し、ステップＳ１１４に進む。

ステップＳ１１４では、ステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの離任日６０４値が示す年月の行から着任日６０３値が示す年月の行までを連結し、経歴枠を作成する。

ステップＳ１１５では、現在処理中の経歴が経歴図表示対象の取引先における経歴であるか否かを判定する。具体的には、ステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの取引先ＩＤ６０５値が図１１の条件画面にて指定した取引先１１０１に該当する場合、経歴図表示対象の取引先の経歴であると判断し、ステップＳ１１９に進む。該当しない場合は経歴図表示対象の取引先の経歴ではないと判断し、ステップＳ１１６に進む。

本例では、レコード７２１の取引先ＩＤ６０５値が条件画面にて指定した取引先「Ｃ商事株式会社」を示す「１００００」であるため、経歴図表示対象の経歴と判断される。

ステップＳ１１５からステップＳ１１９に進んだ場合は、ステップＳ１１１またはステップＳ１１４で作成した経歴枠に、ステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの部署６０９値および役職６１０値を表示し、背景を自社色（図１２の例では白塗）に設定し、該当経歴の経歴画面１０００への遷移情報（Ｗｅｂシステムの場合ＵＲＬ等）を設定し、ステップＳ１２２に進む。本例の場合、レコード７２１より部署値空欄、役職値「会長」と表示し、白塗りとなる。

ステップＳ１２２では変数「開始年月」に現在処理中の経歴レコードの着任日６０３から取得した年月値を格納する。本例の場合、レコード７２１の着任日６０３値の年月「２０１４／０４」を格納する。

ステップＳ１２３では、ステップＳ１０３で取得したレコードに次のレコードがあるかどうかを検証し、次レコードがあればステップＳ１２４に進み次レコードを現在の処理対象レコードし、さらにステップＳ１２５に進む。次レコードが存在しない場合は、ステップＳ１３０に進む。

本例では、処理中の７２１レコードの次に７２２レコードが存在するため、レコード７２２を現在レコードとして次ステップＳ１２５に進む。

ステップＳ１２５では、ステップＳ１２４で現在値とした経歴レコードが、処理中の担当者と一致するかどうかを判定する。具体的には、前レコードと現在レコードの担当者ＩＤ６０２が一致した場合、同一担当者と判断し、ステップＳ１２６に進む。一致しない場合は別の担当者の経歴と判断し、ステップＳ１２７に進み、現在の担当者列の残りの行をすべて連結して空白期間枠を作成した上で、ステップＳ１０９に戻り、次の担当者列について同様の処理を続ける。

本例では現在レコード７２２と前レコード７２１共に「山田」氏の主務の経歴であるため、そのまま主務列の処理を続ける。

同様に経歴レコード群７００の順番にレコード処理を繰り返し、レコード７２５のステップＳ１１５まで進める。レコード７２５はＣ販売株式会社（現ＣＨＤ株式会社）の経歴レコードであるため、ステップＳ１１５において経歴図指定取引先ではないと判断され、今度はステップＳ１１６に進む。

ステップＳ１１５からステップＳ１１６に進んだ場合、経歴図表示対象の取引先ではないため、部署と役職に加えて在任した社名も経歴枠に表示する。ステップＳ１１１（空白期間枠を作成した場合はステップＳ１１４）で作成した経歴枠（本例では図１２の列１２１１最下部のＣ販売営業部部長経歴枠）に、ステップＳ１０３（繰り返し処理の場合はステップＳ１２４）で現在値とした経歴レコードの在任時会社略称６０７値（本例ではレコード７２５より「Ｃ販売」）、部署６０９値（本例では「営業部」）および役職６１０値（本例では「部長」）を表示し、経歴画面１０００への遷移情報を設定し、ステップＳ１１７に進む。

ステップＳ１１７では現在処理中の経歴が経歴図表示対象の取引先の系列会社であるか否かを検出する。系列会社判定処理の処理詳細については図１７、図１８にて後述する。

ステップＳ１１８においてステップＳ１１７の処理結果を判定する。現在処理中の経歴が経歴図表示対象の取引先の系列会社であると判定された場合は、ステップＳ１２０に進み、ステップＳ１１６で社名、部署、役職を表示した経歴枠の背景を系列会社色（図１２の例では網掛け）に設定する

本例では現在処理中のレコード７２５は経歴図表示対象のＣ商事株式会社の親会社（および同じＣＨＤグループ企業である「Ｃ販売株式会社」の経歴であるため系列会会社と判断されて、背景が網掛けに設定される。

次ステップＳ１２２では「開始年月」変数にレコード７２５の着任年月「１９９２／０４」を格納し、ステップＳ１２３を経由してステップＳ１２４にて次レコード７２６の処理に移る。

レコード７２６は同じ「山田」氏の経歴レコードではあるが主務であるＣ商事会長の肩書と兼任しているＣスタッフ取締役の経歴であるため、兼務フラグ６０８値が「ＯＮ」になっており、前レコード７２５の「ＯＦＦ」とは異なるため、今度はステップＳ１２８に進む。

ステップＳ１２８では現在処理中の主務列の残行を空白期間枠に設定する。前レコード７２５の着任日６０３の年月値「１９９２／０４」から経歴図の最下行の「１９９０／０４」までを連結し、空白期間枠に設定する。（図１２の列１２１１の下部）

次にステップＳ１２９にて経歴図に兼務列を追加する。現在処理中の「山田」氏の主務列１２１１の右に同じ「山田」氏のヘッダ情報枠に含めて兼務経歴を表示する新しい列１２１２列を追加し、現在列とする。

そして、ステップＳ１１０に戻り、経歴図の最上部から再度処理を開始するために、「開始年月」変数値を経歴図画面１１００で指定した表示期間Ｔｏ１１０２の値（本例では「２０１６／０８」）で上書きし、ステップＳ１２３までの処理を実行して、作成した兼務列１２１２にレコード７２６のＣスタッフ取締役経歴枠を作成する。

ステップＳ１２４にて次レコード７２７を取得すると、今度は担当者ＩＤ６０２値が「山田」氏を示す「１０１００」ではなく、「佐藤」氏を示す「１０５００」となっているため、ステップＳ１２５において別担当者の経歴レコードと判断され、ステップＳ１２７に進む。

ステップＳ１２７では経歴図に新しい担当者列を作成する。本例では現在レコード７２７が「佐藤」氏の経歴であるため、図１２の列１２１３のように佐藤三郎列を作成して現在処理列としてステップＳ１１０に戻り、処理を続ける。

上記のように処理を繰り返し、レコード７３０のステップＳ１１６まで処理を進める。レコード７３０は「田中」氏のＡ銀行取締役の経歴レコードである。Ａ銀行はＣ商事の系列会社ではないため、ステップＳ１１８において系列会社ではないと判定されて今度はステップＳ１２１に進み、背景色を系列外を示す会社色（本例では黒塗）に設定される。（図１２の列１２１４のＡ銀行取締役経歴枠）

そのまま処理を繰り返し、最終レコード７４１（「ジム」課長の企画部企画課課長経歴レコード）のステップＳ１２２まで処理を進める。

ステップＳ１２３において次レコードが存在しないため、繰り返し処理を抜けてステップＳ１３０に進む。

ステップＳ１３０においてレコード７４１の着任日６０３の値「２００８／０４／０１」から「２００８／０４」行以下をすべて連結して空白期間枠に設定し、処理を終了する。

以上の処理にて図１２の取引先経歴図が生成される。

次に、ステップＳ１１７の系列会社判定処理のフローを説明する。

系列会社判定処理の実装方法としては、先に記述したように、取引先テーブル４００に所属する企業グループ４０４を設定する方法と親会社ＩＤ４０５として取引先テーブル４００に存在する別の取引先の取引先ＩＤを指定させる方法の二種類が考えられる。

図１７の処理フローは取引先テーブル４００に所属する企業グループ４０４を設定する方法の場合の処理例である。

図１６の処理フローにてステップＳ１１７に進んだ場合に図１７のフローが開始する。

まず、先頭のステップＳ２０１にて取引先テーブル４００から経歴図表示対象の取引先のレコードを取得する。

次にステップＳ２０２にて処理中の経歴レコードの取引先ＩＤ６０５に該当する取引先のレコードを取引先テーブル４００から取得する。

ステップＳ２０３にてステップＳ２０１で取得した取引先レコードとステップＳ２０２にて取得した取引先レコードの企業グループ４０４値を比較し、一致した場合は系列企業であると判定（Ｓ２０４）し、一致しない場合は系列企業ではない（Ｓ２０５）と判定して処理を終了する。

一方、図１８は親会社ＩＤ４０５として取引先テーブル４００に存在する別の取引先の取引先ＩＤを指定させる方法の場合の処理フローである。

図１６の処理フローにてステップＳ１１７に進んだ場合に図１８（ａ）のフローが開始する。

まず、ステップＳ３０１にて取引先テーブル４００から経歴図表示対象の取引先のレコードを取得する。

次にステップＳ３０２にて系列元取引先を特定する。系列元取引先とは親会社のさらに親会社、といった企業グループの最上位となる取引先を示す。例えば、Ｃスタッフ株式会社がＣ商事株式会社の子会社であり、Ｃ商事株式会社はＣＨＤ株式会社の子会社であり、ＣＨＤ株式会社には親会社が存在しない場合、上記三社はいずれも「ＣＨＤ株式会社」系列企業と判断され、系列元取引先は「ＣＨＤ株式会社」となる。

図１８（ｂ）にステップＳ３０２の系列元取引先取得処理の詳細な処理フローを示す。

取引先テーブル４００のレコード４２２の「Ｃスタッフ株式会社」を例に説明する。

ステップＳ４０１において親フローより引き継いだ「Ｃスタッフ株式会社」レコード４２２の親会社ＩＤ４０５値を取得する。

ステップＳ４０２において、ステップＳ４０１で取得した親会社ＩＤ４０５値が空欄であるかどうかを検証する。本例の場合、Ｃスタッフ株式会社レコード４２２の親会社ＩＤ４０５に「１００００」が設定されているため、空欄ではないと判断され、ステップＳ４０４に進む。

ステップＳ４０４では、親会社ＩＤ４０５で指定された値に該当するレコードを取引先テーブル４００から取得し（本例の場合、Ｃ商事株式会社レコード４２１が取得される）、ステップＳ４０１に戻る。

ステップＳ４０１では、今度はステップＳ４０４で取得したＣ商事株式会社レコード４２１の親会社ＩＤ４０５を取得する。本例の場合、「３００００」が取得されるため、次のステップＳ４０２では空欄ではないと判断され、再度ステップＳ４０４に進む。

ステップＳ４０４では、今度は取引先ＩＤ「３００００」に該当する「ＣＨＤ株式会社」レコード４２３を取得し、ステップＳ４０１に戻る。

ステップＳ４０１で親会社ＩＤ４０５を取得すると、今度は空欄であるため、ステップＳ４０２の次はステップＳ４０３に進む。

ステップＳ４０３において、現在処理中のレコード４２３に該当する「ＣＨＤ株式会社」を系列元取引先値として返し、処理を終了する。

以上で、系列元取引先取得処理の詳細処理の説明を終了し、図８（ｂ）の説明に戻る。

ステップＳ３０２において上記のように経歴図表示対象の取引先の系列元取引先を取得した後、ステップＳ３０３に進む。

ステップＳ３０３では、処理中の経歴レコードの取引先ＩＤ６０５に該当する取引先のレコードを取引先テーブル４００から取得する。

続けてステップＳ３０４において再度、図１８（ｂ）の系列元取引先取得処理フローを実施し、処理中の経歴レコードの取引先の系列元取引先を取得する。

次に、ステップＳ３０５において、ステップＳ３０２とステップＳ３０４で取得した両系列元取引先を比較し、一致した場合はステップＳ３０６に進み系列企業であると判定して処理を終了、一致しない場合はステップＳ３０７に進み系列企業ではないと判定して処理を終了する。

以上、２種類の系列会社判定処理の処理例について説明した。

このようにいずれの方法でも系列会社判定処理が可能である。

所属する企業グループ４０４を設定する方法は、企業グループ名が必ずしも系列元取引先名と一致しない場合や、財閥のように複数の系列元取引先が１社とは限らない場合などに有効である。また、必ずしも取引先の親会社のレコードを作成する必要がない利点もある。

一方、親会社ＩＤ４０５を設定する方法は、企業グループ名を付ける程でもない小規模な取引先間の系列関係も管理できる他、系列取引先同士の階層付ができるため、取引先同士の親子関係が把握しやすいという利点がある。

次に、図１３に一例を示す個人経歴図を生成する処理フローについて説明する。

個人経歴図を生成する場合も、基本的には図１５、図１６の処理フローを実施するが、冒頭の処理だけが異なる。

本例では、図９の担当者画面の個人経歴図表示ボタン９０５を実行することで、図１９の処理フローが開始されるものとする。

個人経歴図の場合、経歴図処理対象の取引先が特定されていないため、図１５の処理フローに入る前に、表示対象の担当者の最新の主務の経歴を特定し、その経歴の在任取引先を図１５の処理フローにおける経歴図処理対象の取引先として指定する必要がある。

まず、ステップＳ５０１において表示対象の担当者の最新の主務経歴を特定する。具体的には、経歴テーブル６００から表示対象の担当者（本例の場合、担当者画面９００の表示対象である「山田」氏）の担当者ＩＤ６０２が処理呼び出し元の担当者画面９００で表示された担当者に該当する値であり、兼務フラグ６０８値が主務を示す値（本実施例では「ＯＦＦ」）であり、かつ、着任日６０３が最も新しい経歴のレコードを取得する。

本例の場合、図９の取引先画面の表示対象が「山田」氏であるため、経歴レコード６２１が取得される。

次に、ステップＳ９０２において、ステップＳ９０１で取得した経歴レコードの取引先ＩＤ６０５値から取引先を特定し、特定した取引先を続く処理フロー図１５、図１６における「経歴図指定取引先」に定める。

本例の「山田」氏の場合、ステップＳ９０１で取得した経歴レコード６２１の取引先ＩＤ６０５値はＣ商事株式会社を示す「１００００」であるため、Ｃ商事株式会社が「経歴図指定取引先」となる。

「経歴図指定取引先」を表示対象担当者の主務の取引先に設定した後は、取引先経歴図の場合と同様に図１５のステップＳ１０２に進み、担当者テーブル５００から１名のみの表示対象担当者の略称５０４項目値および自社との関係５０３項目値を取得し、続く各ステップを実施した後に、結果として図１３に示す個人経歴図例１３００が生成される。

上記のように生成された「山田」氏の個人経歴図例１３００では、現在の主務として会長を務めているＣ商事株式会社が当該取引先」を示す白塗りとなって表示され、「Ｃ販売」や「Ｃスタッフ」在任中の経歴は関連会社を示す網掛けで表示される。

上記の通り、本発明では、個人の経歴図と、取引先に所属する担当者をまとめた取引先経歴図との両方を生成することが可能であり、ユーザが指定した会社や、担当者が現在所属する会社との関連性をわかりやすく提示することができる。

以上、各実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、各処理方法をコンピュータが実行可能（読み取り可能）なプログラムであり、本発明の記憶媒体は、各処理方法をコンピュータが実行可能なプログラムが記憶されている。

なお、本発明におけるプログラムは、各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読取り実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ 取引先情報管理システム
１０１ クライアント
１０２ サーバ
１０３ ネットワーク
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆコントローラ
２０９ キーボード
２１０ ＣＲＴ
２１１ 外部メモリ

Claims (6)

1. 組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバであって、
   組織の人員の経歴情報を取得する取得手段と、
   前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御手段と
   を備え、
   前記表示制御手段は、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とする管理サーバ。
2. 前記表示制御手段は、前記人員ごとの領域を並べて表示することを特徴とする請求項１に記載の管理サーバ。
3. 前記属性は会社情報を含み、
   前記経歴情報が自社に関するものか否かを判定する判定手段を備え、
   前記表示制御手段は、前記判定した結果に従って、前記経歴情報を自社に関するものか否かを識別して表示するべく制御することを特徴とする請求項１または２に記載の管理サーバ。
4. 前記属性は役職情報を含み、
   役職に関する条件を決定する決定手段を備え、
   前記表示制御手段は、前記決定した条件に合う人員の経歴情報を表示するべく制御することを特徴とする請求項１〜３のいずれか１項に記載の管理サーバ。
5. 組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバの制御方法であって、
   取得手段が、組織の人員の経歴情報を取得する取得ステップと、
   表示制御手段が、前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御ステップと
   を備え、
   前記表示制御ステップでは、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とする管理サーバの制御方法。
6. 組織の人員それぞれの期間と属性とを含む経歴情報を管理し、当該経歴情報をクライアントで表示するべく制御する管理サーバにおいて実行可能なプログラムであって、
   前記管理サーバを、
   組織の人員の経歴情報を取得する取得手段と、
   前記取得した人員の経歴情報を当該人員ごとの領域に当該経歴情報の期間に従って表示するべく制御する表示制御手段
   として機能させ、
   前記表示制御手段は、同じ期間に前記人員の複数の経歴情報がある場合に、当該人員の領域において、前記同じ期間を有する複数の経歴情報それぞれの表示領域を並べて表示することを特徴とするプログラム。
   

Images