目次
複数社員レコードの生成 （プロフェショナル・オプション機能が必要です）
社員の人事情報が完全には準備されていない場合（まずは動かしてみたい）
社員の人事情報がほぼ完全は準備されている場合（一度に入社処理をしたい）
自動生成（コマンドボタン）（プロフェショナル・オプション機能が必要です）
この度は、弊社製品をお買い上げ頂き、誠にありがとうございます。
当製品は、一言で説明すると、お客様の「賃金決定システムを容易に構築する」ためのものです。
当製品は、人材を「人財」（人的財産）と考え、「人財管理システム」として、お客様の組織において、従業員の方々の能力や属性、業績などを記録し、組織のトップの組織理念に基づいた人事方針を詳細な要素に分解し体系的に数値化することで、トップの方が全体のバランスを勘案した上で各従業員への人事考課を容易に判定できるようにし、最終的には各従業員の方々の賃金（給与や賞与）を、与件となる人件費総額の範囲を維持しながら、正確に、公平にかつ迅速に決定できるシステムです。
当製品は、組織のトップの方がご自身で操作可能なように、キーボード操作を極力減らし、WindowsのGUI(Graphical User Interface)とマウスを有効に利用できるよう設計しております。
ご使用にあたっては、当解説書を事前によくお読み頂き、正しい操作をすることで、当システムを有効にご活用いただけるようお願い致します。
弊社は、お客様が当製品を導入、操作、運用するにあたりまして、各種のご質問にお答えできるよう支援体制を整えております。また、お客様からのご要望が多いものに関しましては、今後の当製品の標準機能として組入れ、機能強化を図るべく開発方針をとっております。機能強化した製品は、バージョンアップという形で反映させ、保守契約がある限り、お客さまは、弊社のWebsiteから最新版をダウンロードすることができます。
当解説書を理解するためにプログラマ・レベルの知識は特に必要としませんが、ユーザレベルとしては、次に掲げる知識や用語を理解できる必要があります。
l パソコン本体の各部分の名称およびキーボードのキーの名称とキー操作と操作の名称
l Windowsの基本的な要素の名称と操作
お客様での弊社製品の導入に問題が発生した場合は、各種の方法で、お客様の問題解決をお手伝い致します。
弊社製品に関する技術情報、トラブル情報、商品情報、よくある質問（FAQ：Frequently Asked Question）は、下記のWebsiteの「製品」または「サポート」のページからのオンラインで入手することが可能です。また、最新版を入手する場合は、「ダウンロード」のページからダウンロードできます。
http://www.amilink.co.jp
お問い合わせは、主にemailで行っております。上記Website上の「お問合せ」のページから承っております。
なお、「お試しデモ版」のご試用に関する電話でのサポートは致しておりません。あらかじめご了承願います。
以下の場合には、お問合せに対する回答ができないことがあります。あらかじめご了承下さい。
l 本製品で保証している動作環境外でのお問合せ
l 本製品と直接関係ないハードウェア、または他社製品に関するお問合せ
l サポート期間外のサポートおよびお客様への出張を伴うサポート
l WindowsなどのOSやOfficeなど他社のアプリケーション・ソフトに関するお問合せ
弊社や有料サポートを提供しております。詳しくは、上記Websiteの「コンサル」および「サポート」のページを参照下さい。
「らくちん社長-賃金決定」の基本機能の概要を以下に箇条書きで掲げます。
l 賃金は絶対額ではなく、基本的にポイントで記録。１ポイントあたりの金額を設定することで、絶対額を算出する。これにより、昇給（減給）やベースアップ(ベースダウン)時の各種賃金表の設定が容易となる。
l 各種賃金表のユーザ設定可能（正社員年齢学歴給表*、非正社員基本給表、勤続給表*、各種手当額表、スキル免許資格手当額表、職能格給表）（*の表は、手入力で一つ一つ指定することも可能であるが、金額ランクを生成する為の標準関数が用意されているので、それを利用することを推薦する。また、そのユーザ関数を半自動生成する簡易指定機能（ウィザード）も提供されている）。
l 賃金表のグラフ化による視覚での試行錯誤により、社員区分別にバランスのある賃金表の作成が可能。
l 基準内賃金は、本人の能力や成果とは無関係に決まる基本給部分（年齢、学歴および勤続年数から決まる）と、職務などによって決まるメリット給（基本給部分に対して、総合評価係数（社員区分、職位、職能格、職種、株主区分別の考課給係数を全部掛け合わせた値） を掛けた金額）で大体が決まり、それに、各個人個人の人事考課を加味して最終的な額が決定する。全社員分の給与の総合計を先に決め、その額に合わせる形で、各個人の給与水準をバランス良く決定することもできる。
l ボーナス額の、基準内賃金に対する支給比率は、総合賞与係数（社員区分、職位、職能格、職種、株主区分別の賞与係数を全部掛け合わせた係数）でシステムが自動的に決定する部分と、各個人個人のボーナス評価期間の成果を加味した考課部分に分かれる。 これらの合計値が最終的なボーナス額となる。ボーナスは、会社全体のボーナス支給総額を先に決め、その額に合わせるように各個人のボーナス額をバランス良く決定することもできる。
l 給与もボーナスも、その決定に際しては、各人の前年度、前々年度の実績を、絶対金額や比率などで同一の画面上に時系列比較できる上、金額の多寡による社員の並び変えで、他の社員との上下比較も容易にでき、社員間の賃金バランスを容易に取れる。
l 給与決定は、各人の年収の前年度実績および今年度の年収予測を勘案しながら決定できる。
l 社員に特別な事情がある場合や、人事システムの変更などで、賃金額が極端に変る者に対しては、一時的な調整給によりそのギャップを埋めることや、賃金表とは無関係に管理者が決定した結果だけを入力することが可能。
l 氏名（姓＋名＋ミドル名、漢字、ふりがな、フリガナ、日本語およびアルファベットで、それぞれ、業務上名称、通称、ペンネーム、戸籍名、全旧姓、その説明）、採用区分、性別、血液型（Rhプラス・マイナス）、出身、出生、言語３、家族情報、縁故情報、顔写真。
l 社会属性（国籍、パスポート番号、査証条件、国内滞在期限、運転免許番号および次期更新日、健康保険番号、厚生年金番号、雇用保険番号、婚姻情況、住居情況、障害情況）。
l アドレス（住所、電話2、携帯電話2、Fax2、email2, Websiteが日本語およびアルファベットで、それぞれ現住所、実家、郵送先、緊急連絡先、税務管轄先、保養所先、別荘、親戚、別宅、その説明）、全学歴、給与基準学歴、退職金オプション。
l スキル、免許・資格の手当額支給は、社員区分、職能格、職位、職種、職群、部門機能、地区、株主などの組合せにより、支給の可否を登録できる。
l 社員のスキルや免許・資格は、その種類、熟練度、使用頻度、スキル手当額などを管理し一望できる。
l 社員のスキルや免許・資格で、内容が重複するような場合（例：普通自動車免許と特殊第二種免許や、情報処理1級と特種など）で、その支給手当の金額も重複支給になるような場合、その最高額だけが自動的に有効になるような指定ができる。
l 家族記録は、続柄、家族の誕生日、扶養、同居、障害等状況、就業状況、住居など税務申告に必要な家族情報は全て記録できる。
l 賞罰記録は、あたかも経理の減価償却のように、ユーザが指定した償却比率に基づき、年数の経過に従い賞罰評価を逓減させ、社員の評価時期における賞罰の「現在価値」を知ることが可能。
l ある社員が複数の部門組織またはプロジェクトに帰属している場合で、その社員の賃金コストをそれらの部門組織やプロジェクトに賦課する必要がある場合は、賦課の勘定科目やプロジェクトコードの設定および賦課の部門間比率（同時に最大３部門まで）を登録できる。
l 氏名変更、社会属性変更、住所変更、人事異動記録、学歴、スキル、免許、資格などの記録、家族情況の変更、個人の経費賦課分配の記録、給与記録、賞与記録、賞罰記録とその償却記録。
l 人事年度別の全係数の記録 （賃金水準、ボーナス水準、各種評価係数の変更、各種賃金表、各種手当額表、社員区分、職能格、職位、職種、職群、株主区分、部門機能、地区区分での考課係数や賞与係数など）。
l
給与決定時、賞与決定時。
l 社員番号による検索。
l 氏名のふりがなの頭文字で検索。
l 個人またはグループを、社員区分、職位、職能格、職種、部門機能、組織、地区、株主区分などの社員属性で検索。
l 当システムを利用する人物の権限（サインオンＩＤの権限登録）により、一般ユーザ権限、管理者権限、人事統括責任者権限、監査権限の４つの権限が用意されており、それらの権限毎に、アクセスできるデータの範囲をユーザの指定により、各画面ごとに「読み取りのみ」、「更新可能」、「削除可能」、「過去確定データの修正と、アクセス記録の削除可能」の４つのレベルを決めることが出来る。
l 誰が、どのデータにアクセスしたかの全記録が残り、機密保護の検証が可能。かつ、この記録は、人事統括責任者権限者でも削除することはできず、監査権限者のみが削除できる。
l 全ての重要データの削除は論理削除で行う。物理削除は、権限者のみが、後でまとめて行い、不用意に削除してしまう誤りを未然に防ぐ。
l テストデータの利用モードや、現在とは違う人事年度のデータにアクセスした場合は、メニューの色彩が変ったり、注意喚起の点滅などしたりして、ユーザに警告を出し、現在の本番モードとの混乱を避ける。
l 部外者によるデータ検証や参照が必要な時で、データを外部に持ち出す場合は、個人情報の匿名化が命令一つで可能。
l 主要なデータはCSV形式で外部出力が可能。
l OBC（オービックビジネスコンサルタント）社の「給与奉行」と、マスター類がデータ互換。
l 賞与計算に必要な出勤率や、年収管理のための年収総額、退職金に付帯する特別な退職手当類など、賃金決定以外の外部システムで決定されるデータ類は、ファイル形式(CSV形式)での入力または画面からの手入力の、どちらでも選択できる。また、Access2000でのプログラム開発が可能なユーザの場合は、外部システムから直接、該当の人事データ類に更新を行うことも可能。
l ユーザが登録できるメニュー画面が用意されており、そのメニュ-を選択することで、ユーザ独自の適用業務（パソコン業務）に動的な連携が可能。
プロフェショナル・オプションは、主に賃金決定に携わる専門家（社会保険労務士、中小企業診断士、税理士、経営コンサルタントなどの職業の方）のために用意した以下の機能。
l 標準的に99999社の会社の賃金データを、会社番号で検索でき、（会社名を確認したのち）瞬時に切り替えることが可能。
l 共同事務所などで、共通サーバに複数の会社データが混在する場合でも、自分の担当する会社のデータだけが接続でき、第三者のデータは接続できないように設定できる。
l 本番用データ、テスト用データ、人事シミュレーション用データなど、目的により、データを入れ替えられる。
l データの格納場所（ハードディスク装置などの）を自由に変更できる。
l データを部外者に参照するような場合に、データの機密部分をマスクして意味不明に出来る
l 特定のクライアント･パソコンだけを「読み取り専用」に指定することが可能。
l 論理削除されたデータの存在確認と、それらの一括物理削除の指令。
l データのバックアップと回復作業。
l OS：WindowsXP。
l ハードディスク：最低250MB（Access2000インストール済みの場合は50MB）のインストール領域が必要。
l CPU：PentiumⅢ以上で、１GHz以上を推奨。
l メモリー：128MB以上推奨。
l 印刷装置：A4版サイズ以上の印刷装置（カラー推奨）。
l 通信：最低1台のパソコンはｲﾝﾀｰﾈｯﾄに接続されておりemailが利用できる状態にあることが望ましい。
l その他必要ソフト：Microsoft Outlook Express、Microsoft Internet Explore.
一般に人財管理システムはゼロから導入するということはまれで、既に紙ベースで一部を運用しているか、あるいは表計算ソフトのような簡易ソフトに一部の管理資料を記録してあるというのが普通です。
従って、当システムを導入する時は、既に紙ベースなどで最低限必要なデータが存在するという前提で、基本的に次の三つの作業を行います。
① 従業員の属性に関する事実の入力
② 賃金基準を示す各種の数値表（賃金表や職能格給表など）の作成
③ 各従業員に対する格付けや考課などの評価作業
②の賃金基準などの作成は、当システムを導入する目的の一部ですから、準備作業は参考資料程度（もし、現在の賃金表などがあれば参考とする）でよいと思います。また③の人事考課などは、当システムの、「全体のバランスを勘案した上で各従業員の適正な人事考課を容易にする」という当製品の最終目的ですので、この為の準備というのは、各社員に対する相対的な評価比較のようなものがあれば助けになりますが、これも「必須」という訳ではありません。これらの作業は、当システム導入後の全体の係数的な調整が済んでから、再評価という形でやりなおすことも可能です。
当システム導入前に絶対に準備をしておかなくてはいけないのは①の各従業員の属性に関する「事実」の部分です。これを準備しておきませんと、例えば、年齢学歴給や勤続年数給などのように、年齢や学歴、入社歴のような、過去の計数的事実に１００％連動して決定する項目の計算処理を実行できないことになります。当システム導入時に一番初めに行うのは、従業員の事実の登録（社員登録）ですが、この時に、これらの必須の数値が判明していないと登録作業そのものを中止することになり、円滑な導入が困難となります。
（尚、年齢学歴給および勤続年数給を採用しない場合でも、生年月日、入社年月日は必要です）
以下に、導入前準備として用意しておく初期登録必須データおよび必要データをリストします。
l 初期登録必須データは、「このデータが存在しないと、登録作業そのものが続行できない」というもので、絶対に必要なものです。
l 社員名（業務メニュー（「入社処理（社員番号発行）で登録」
l よみがな（業務メニュー（「入社処理（社員番号発行）で登録」
l 社員番号（最大６桁の数値：先行のゼロは無視。新たに振り直すことも可能。「入社処理（社員番号発行）で登録」
l 生年月日（西暦）（業務メニュー「入社処理（社員番号発行）」で登録。「社員基本属性登録」で修正可能）
l 入社年月日（西暦）（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
l 社員区分（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
l
職能格（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
準備ができていない場合は既定値（「未定または不特定」）を利用してください。
l
職種（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
準備ができていない場合は既定値（「未定または不特定」）を利用してください。
l
部門機能（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
準備ができていない場合は既定値（「未定または不特定」）を利用してください。
l
地区コード（業務メニュー「入社処理（社員番号発行）」で登録。「社員異動記録」で修正可能）
準備ができていない場合は既定値（「未定または不特定」）を利用してください。
l 最終（最高）学歴（業務メニュー「入社処理（社員番号発行）」で登録。「社員基本属性登録」で修正可能）
上記の各種登録作業は、「らくちん社長-賃金決定」の「入社処理（社員番号発行）」のメニューで、連続して処理が可能です。
「必要データ」は、初期登録必須データのように、「それがないと、処理が続行できない」というほどのものではありませんが、初期登録が終わった後には、必ず登録作業を必要とするデータです。
尚、標準的なものは、「らくちん社長-賃金決定」で既に登録してありますので、お客様が同様の名称をご使用になる場合は、改めて登録する必要はありません。あるいは、標準的なものを参考に、名称を変更してご使用になることも可能です。
l 社員区分表（正社員、契約社員、役員、顧問など、お客様の組織で分類する一種の雇用区分を分類したもの。「らくちん社長-賃金決定」においては従業員に関するもので一番重要な区分であるので、必須データに近いものとなる）
l 職能格区分表（主任格、係長格,課長格、部長格、取締役など、従業員の職能を格付けして分類したもの。「らくちん社長-賃金決定」では、職能格は、基準内賃金の決定要素（職能格給）となる）
l 職位区分表（課長や部長などの地位。職位は、職能格と近似しているが、職務上の指揮系の地位を示し、「らくちん社長-賃金決定」においては、賃金との連動は直接的にはない。（間接的には賃金との連動を設けることも可能である））
l 職種表（営業、事務処理、建築設計技術、プログラマ、清掃作業、重機運転などの、お客様の組織での職種の分類）
l 部門機能分類（営業、経理、製造、品質管理などの、お客様の組織での各部門の「機能の名称」。組織名と類似するが、別組織でも、同一の機能ならば同一部門機能名となる）
l 地区分類（お客様の組織が、広く別地域に分散する場合で、その地区ごとの「地区手当」（寒冷地手当など）がある場合は、この地区分類が必要。この手当がない場合は、本社の所在地などで、実態とは係りなく一律に決めても構わない）
「必須データ」以外に、組織の中で各従業員に与える属性のうち、前記の各種区分に関する各従業員ごとの区分を明確にする。
セットアップは、ＣＤ-ROMに付属した「らくちん社長-賃金決定V1インストールの手順」に従ってください。
①
使用条件の合意：「らくちん社長-賃金決定」のアイコンをクリックします。
すると、「インストール前に当システムの『ご使用条件とライセンス証書』をお読み下さい。お客様がこの『ご使用条件とライセンス証書』に『合意』された場合にのみインストールが可能となります。」
のメッセージを表示します。
お客様には、この「ご使用条件とライセンス証書」をよくお読み頂いた上で、「合意」（ボタン）をクリックして頂きます。
② 初期化メッセージの確認：「システムのインストールと初期化」の画面で、「これは、当システムの最初の稼動です。当システムのインストールと初期化を開始します。」のメッセージが出ますので、「OK」ボタンをクリックして確認して下さい。
③
システム･インストール登録：「システム･インストール登録」の画面が表示されますので、現在インストール作業を行っているパソコンのCPU-ID（「Master」または「Secondary○○」）とアクセス・モード（「追加･更新可能」または「読み取り専用」）を指定し、契約者の郵便番号、住所、電話番号、Fax、email，契約者（会社）名、担当部門名、責任者名を登録します。
CPU-IDは、最初のクライアントでは必ず「Master」を指定します。つまりスタンド・アロンの場合は必ず「Master」を指定することになります。（クライアント・サーバ型の場合で、2台目以降のクライアントには「Secondary○○」を指定します。）
アクセス・モードに「読み取り専用」を指定すると、このパソコンからのアクセスは、サインオン（当システムを使用する直前にユーザＩＤとパスワードを入力しアクセス権限の確認と認証をする手続き）するユーザの権限に係らず、全て「読み取り専用」となり、更新は出来なくなります。
入力が終わったら「登録」ボタンをクリックします。
なお、「システム･インストール登録」の詳細は、（「第１３章 システム保守」è「インストレーション設定変更」）を参照願います。
④ 登録の確認：契約者登録の確認画面で、「登録が完了しました」と表示されますので、「ＯＫ」ボタンをクリックして下さい。
⑤
バックエンドＤＢの初期化：「ｉｎｉｔｉａｌｉｚｅＤＢＰａｔｈ」という画面で、「バックエンドＤＢが未登録です。 システムの省略時解釈で『ｘ：\○○○○\賃金決定\賃金決定１_n.ａｍｉ』と設定しました。」というメッセージが出ますので内容を確認の上、「ＯＫ」をクリックして下さい。（ここで、ｘは、お客様が指定したハードディスクのドライブ・アドレスです。○○○○の既定値は”Program Files”ですが、お客さまが変更した場合は、その名称になっています。ｎは、当「らくちん社長-賃金決定」の改定レベルの番号で、0から99の番号です。
尚、上記ｘと○○○○に関する記述説明は以降、同様とします。）
また、このバックエンドＤＢの先頭文字（x）から最後の文字までの名称（フル･パス名）は、後ほどの手順で再確認致しますので、メモをとっておいて下さい。
⑥
登録内容の確認準備：ユーザ登録が完了すると「登録内容を確認願います」のメッセージが出ますので「OK」ボタンをクリックして下さい。確認内容は、以下のとおりです。
・ユーザ情報
・バックエンドＤＢファイルの名前と場所
・バージョン情報
⑦
登録内容の確認：「システム基本環境設定」の画面が表示されますので、「バックエンドDB」タブをクリックし、「バックエンドＤＢファイルのパス名」が、お客様が当システムを複写した場所（上記のバックエンドＤＢの初期化で確認したファイルのフル･パス名）であることを確認して下さい。次に「開始画面」タブをクリックし、「当システムの契約社名」と「システム運用責任者名」がお客様の登録内容と同じであることを確認して下さい。
確認できましたら、「終了」ボタンをクリックして下さい。
⑧
サインオン：サインオン画面がでますので、「サインオンID」に「master」、「パスワード」に「password」と入力して下さい。「password」はマスクが掛けられているので「*******」のようにアステリスクで表示されます。
尚、このmasterのパスワードは、初期化を終了した後に変更することが可能です。セキュリティー上の理由から、変更することを強く推奨します。
ただし、お客様が当システムの運用に十分に慣れてから実施してください。そうでないと、「パスワードを忘れてしまった」といような問題が発生しがちです。そうなった場合は、最初からインストールのやり直しになりますので、ご注意願います。
⑨ メインメニューの表示：「賃金決定システムメインメニュー」が表示されます。画面の背景が「灰色」（本番用）であることを確認して下さい（テスト用データの場合は「緑色」になります）。また、その下のサインオン・ユーザという欄に「master」と「SYS_MASTER」の表示されているのを確認して下さい。
⑩ Installation IDの確認：「システム保守」のボタンをクリックして下さい。「SysMaintMenu」（システム保守）の画面が出ますので、「システム基本環境の設定」をクリックします。「システム基本環境の設定」の画面が表示され、その左上の部分に「システム基本環境の設定 （Installation ID： nnn-mmmm-kkkk-jjjjjj）」と表示されています。ここで、n、m、k、jの値はそれぞれお客様独自の数字で構成されるもので、全体として「Installation ID」（インストレーションＩＤ）と呼称します。今後、弊社が、お客様での当システムをバージョンアップしたり、不具合を修正したりする場合に「システム照合」に必要ですので、このInstallation IDはメモし保管しておいて下さい。（当解説書の表紙などに貼り付けておいて下さい）
⑪
初期化の完了：これで初期化は完了です。初期化直後では、現在接続されているバックエンドDBは、「本番用」DBとして自動的に「登録」されています。この「本番用データ」を購入当初において、「テスト的」に利用する場合は、この「本番登録」を解除して下さい（別途、「解除」もしくは「テスト登録」を行う。メニュー画面が「緑色」に変る。（「システム基本環境設定」（画面）è「バックエンドDB」（タブ）で行う））。
初期化後に行う業務関連のコードや賃金表の登録、および各従業員の属性や考課などを行った上、全ての係数や金額が妥当であると確認した段階で本番モード（別途「本番登録」を行う。メニュー画面が「灰色」に変る）に移行して下さい。データ確認が未完了のまま放置しておきますと、本番用なのか仕掛かり中のテスト用なのかが判明せずに運用の誤りの原因になります。メニュー画面が「緑色」の場合は、常にテスト用であるとの認識で運用願います。
初期化完了の後は、このまま次の操作を続行しても問題はありませんが、ここでは、業務終了を確認するために一旦終了します。
⑫
業務終了の確認：現在の画面を終了する。次にシステム保守画面を終了する。メインメニューが表示されますので「業務終了」をクリックします。「業務終了の確認」画面が出て、「「らくちん社長-賃金決定」の業務を終了します。大丈夫ですね？」のメッセージが出ますので、「OK」ボタンをクリックして下さい。
これで、業務が終了します。
⑬ 業務終了後最適化：業務を終了すると、当システムのフロントエンドDBを最適化（運用過程でサイズが増えた分を縮小させる）するために、最適化処理が自動的に始まります。パソコンの能力の差により処理時間は異なりますが、数十秒から数分かかります。最適化が終了すると自動的に終了します。
① 各クライアント側パソコンで次の②から⑦を実行する。
② スタンド・アロン構成の場合の①から⑩までの手順をそのまま実行します。
③
バックエンドＤＢの変更：「システム基本環境の設定」画面で、「バックエンドＤＢ」タブを表示します。左下の編集ボタンの「入力/編集」をクリックし、編集モードにします。「バックエンドＤＢファイルのパス名」の表示部分が更新モード（入力エリアが白くなり窪む）になりますので、ここに、現在クライアント側パソコン上のバックエンドＤＢファイルのフル・パス名になっている指定を、サーバ上に複写したバックエンドＤＢファイルの「賃金決定1_n.ami」のフル・パス名に変更指定をします。
変更前は、スタンド・アロン構成の場合の⑤で確認した『ｘ;\○○○○\賃金決定\賃金決定１_n.ａｍｉ』の値になっているはずですが、ここのｘの部分は、クライアント側パソコンのハードディスクのドライブ･アドレスになっています。このｘの部分を、サーバ側ＣＰＵのハードディスクのドライブ･アドレスに変更します。
もしも、サーバ側ＣＰＵで、ハードディスクのドライブ･アドレスのみならず、「\○○○○」などのフォルダー名の変更も行った場合は、それも含めてフル・パス名の全てを更新して下さい。場所が不明の場合は「参照」ボタンをクリックし、ハードディスクのドライブ・アドレスから順番に探索してサーバ側のバックエンドＤＢファイルを発見することができます。
④ 「システム基本環境の設定」の終了：バックエンドＤＢ名のサーバ側のものへの更新指定が完了したら、「システム基本環境の設定」画面で「終了」ボタンをクリックします。
⑤
クライアント側のバックエンドＤＢの削除： 「システム保守」画面で「ファイルの複写・変更・削除」をクリックします。「ＳｙｓＤＢＧｅｎＡｎｄＲｅｎａｍｅ」（ファイルの複写・変更・削除）画面が出ますので、「対象ディレクトリー」で「バックエンドＤＢ」を指定します。「ＳｙｓＤｉｒＬｉｓｔ」というファイル探索用の画面が出ますので、クライアント側のバックエンドＤＢを格納してあるハードディスク･ドライブ・アドレスから順次、探索をして行き、スタンド・アロン構成の場合の⑤で確認した『ｘ:\○○○○\賃金決定\賃金決定１_n.ａｍｉ』（ここで、ｘはクライアント側のハードディスク・ドライブ・アドレス）を発見し、ここにマウスを当ててダブル･クリックします。「ファイル名」の部分に、『ｘ:\○○○○\賃金決定\賃金決定１_n.ａｍｉ』が転写されたのを確認し、実行をクリックします。
「ＳｙｓＤＢＧｅｎＡｎｄＲｅｎａｍｅ」の画面の「対象ディレクトリー」に『賃金決定１_n.ａｍｉ』が転写されていますので、確認後、「削除」ボタンをクリックします。
⑥
削除の確認：「ファイルを削除します。（一旦削除すると元に戻せません） また、現在使用中のものは削除できません。大丈夫ですね？」のメッセージが出ますので、「ＯＫ」ボタンをクリックします。次に画面全体の色調が変化して点滅し、「このファイルはバックエンドＤＢです。重要なファイルですが、大丈夫ですか？」と再度、警告の確認が出ます。これも「ＯＫ」ボタンをクリックします。
最後に、「ファイルの削除は完了しました。ファイル名=『ｘ:\○○○○\賃金決定\賃金決定１_n.ａｍｉ』」（ここで、ｘはクライアント側のハードディスク・ドライブ・アドレス）と表示されますので、確認後、「ＯＫ」ボタンをクリックし、「システム保守」画面を終了して下さい。
⑦ 業務の終了： スタンド･アロンの⑩（業務終了の確認）以降の手順を実行して、クライアント側の手続きを終了して下さい。
人事関連のシステムの導入で問題となりますのは、その大半が、お客様での「人事理念そのものが明確でない」という場合であります。お客様のコンピュータ・システムに、商品としての「らくちん社長-賃金決定」を単に入れこむだけなら、5分も必要と致しません。「らくちん社長-賃金決定」を格納した配布用のCD-ROMから、お客様のハードディスクに、手順プログラムの指示に従ってボタンを押す操作だけでインストールできるからです。後はマウスで所定のアイコンをクリックすれば「らくちん社長-賃金決定」そのものは「単にプログラムとして」は動きます。
問題の本質は、常にお客様が「従業員の何を評価するのか」という、人事方針が決まっていない場合です。
お客様が、人財管理システムをコンピュータ化する以前から、紙ベースで人財管理システムを運用しており、その手計算作業の軽減のために「らくちん社長-賃金決定」を導入する、という場合は、比較的容易に導入できます。この場合の問題点は少なく、既存の紙ベースで管理してあった全従業員の人事データを「らくちん社長-賃金決定」に入力し直すという、「作業的な準備」が必要となるだけです。これに要する労力は数日の入力作業だけであり、「基本的な判断に苦慮する」ことはあまりありません。システムの切り替えに伴う各種係数などの部分的な修正は当然発生しますが、これらは、言わば建築で言う「現場合わせ」のようなもので、数日の試行錯誤を経た後、適当な値に収斂して行きます。
問題は、お客様が紙ベースでさえも人事管理をしておらず、賃金表も職能格手当表も何もない状態の場合です。この場合は、従業員の賃金は、お客様のトップの方が「鉛筆ナメナメ」で、「エイヤッ」と決めている場合が多く、客観的な資料も何もありません。「トップの方の勘」というのは、それなりに絶妙ですから、結果からみると、それほど間違っていなくても、「システム化」に当たっては、その「勘」の内容を「分析」して「合理的要素」に「分解」しないと、「システム」としては構築できません。
この場合に、お客様のトップの方がご自身の「人事に対する基本的な考え」を整理された形（意味が明確に定義された言葉を用いての人事の理念）で提示することが可能であれば、時間を掛けて整理していけば、最終的には、お客様のトップの「考え」を「要素」に分解できます。ところが、往々にして、「何を評価しているのか」を、お客様ご自身が分からない場合があり、この場合は、お客様のお考えを要素に分解することができません。つまり、システム化に必要な、基準値や数値化が非常に困難になる、ということになります。
具体的な例を挙げますと： 年齢給を議論した場合、「若い奴は頼りない」と主張するお客様（トップの方）がいらっしゃって、「ならば、年齢と伴に上昇する年齢給カーブにしますか？」と確認をいれますと「そうは言っていない・・・」とか「いや年齢ではなく、社歴かな？」と言われるので、「では、社歴に応じて年功給を上昇させます。この場合は年齢や学歴が上の後輩よりも高給になる場合がありますが、よろしいですか？」と確認をいれますと、「いや、それもマズイな・・・」、また「うちは、実力主義だ」と標榜されるので、「では、学歴給は無視しますか」と確認をいれますと、「そういう訳にもいくまい・・・」とか、堂堂巡りの議論になり、結論が出ません。
極端な場合は「年齢も社歴も技術も業績も全てが相当以上の従業員に、は他の従業員よりも十分に高給を与えるのですか？」という究極的な質問を致した場合に「もちろんだ！だが、ほんの少しだけ。50円ぐらいは給与を上げても良い」という具合で、事実上ほとんど「評価差をつけず」「評価管理そのものを」「最初からする気がない」という結論になる場合があります。時間を掛けてよくよくお客様（トップの方）の本音を引き出してみますと「有能な従業員をおだてて、賃金を上げずに、なんとか安く、長時間働かせる方法はないのか？このソフトはそれが出来るのじゃないの？」という事になります。あるいは「一旦決めた昇給ルールに基づいて賃金を決定したら、思いのほか昇給額の多い社員が現われてしまった。が、本人が気が付かないうちは、そのことを隠しておき、昇給を出来る限り据え置きたい。」ということも珍しくありません。このような賃金決定方式を「間違っている」とは必ずしも断定できませんが、当初、経営者が、「うちは、実力主義だ！」「成果主義だ！」と標榜していたならば、これは明らかに矛盾することになります。
こういう場合は、この「らくちん社長-賃金決定」が「従業員を会社の『人財』」と見なして、合理的に評価して管理をする」という商品の目的とは全く異なることを想定しておりますので、「らくちん社長-賃金決定」による人財材管理の運用のための、最初に行う「評価基準そのもの」の初期設定が不可能になり、結局は運用できない、という結論になります。
初期設定は、「理念さえ決まれば、一発で決定できる」という程には簡単ではあませんが、何十回となくシミュレーションした結果、「トップの方の理念」と「感覚的に合う」数字の組合せが現われた時に、「これくらいのバランスが良い感じだな」という具合に数値案が固まっていき、シミュレーションが収斂していきます。上のケースのように「単に従業員を安く使いたい。ただそれだけだ」という場合は、どういう組合せのシミュレーション結果が出ようとも、「人事評価のあるべき姿」の基本的思想を持っていないお客様（トップの方）にとっては、「何がしっくりくるのか」という、その考え自体がないので、永遠に結論が出ません。
この場合は、「人財管理システム導入」に先だって「人事のコンサルティング」を受ける必要があると思われます。
理想的な導入をめざしますと上述のような問題点が露呈されて、かなり敷居が高くなる場合があります。そこで現実的には、「人事の本来のあるべき姿」は一旦棚上げした上で、導入時点では「現状を肯定」した形にし、現状に合わせる（一種の辻褄合わせ）方法が一番「手っ取りばやい」と思われます。
システムが替わりますから、「ピッタリ一致」ということは不可能ですが、8割ほどの従業員の賃金がプラス・マイナス５%未満に入るような係数を探し当てることは可能だと思われます。さらに、導入以前から、一部従業員に関しては評価が過小または過大であると認識している場合は、この導入時のシミュレーションの比較値として、「現状の金額」ではなく「トップの方の勘」でかまいませんので、その「修正した金額」を新たに比較値として記録し、シミュレーションを繰り返します。だいたい10回くらい繰り返すと現状に近い初期値が数例残りますので、後は、その数例をさらに細かく微調整していき、二つか三つのケースまで絞りこみます。それぞれのケースは各種の“重み付け”が多少違うでしょう。例えば、一つのケースは、年齢給のカーブを平坦にした代わりに、年功給を少し上げた、とか、また別のケースは、年齢や年功給はより平坦なカーブにしたが、その代わり職能格給の金額格差を増やして職能の高い従業員は今まで以上賃金が上がるようにした、とか、第三のケースは職能格給にはあまり差をつけずに、スキル手当の格差を大きくしたとか、といった具合です。こうして、３ケースぐらいまで絞りこんだら、後は、お客様（トップの方）が、今後の経営の基本戦略において、「何を重要視するのか」で決まります。「スキルこそが一番重要」だと認識したら、第三のケースを採用すれば良いし、「いや、うちは社内の融和が大事で、似たような仕事の共同作業も多いから、あまり格差を設けない方がいい」との考えなら、第一のケースだ、という具合です。いずれにしろ、最後は、お客様（トップの方）自身に経営理念（人事方針）がないと結論が出ないことになります。
こうして一旦決定した評価基準で、改めて全従業員の賃金を査定しなおします。前提にあるように約２割の従業員は5%以上の査定の違いが出てくるでしょうが、これは一時的な「調整給」により、その年度は従来通りの賃金レベル（手当類も含めた賃金総額で）に合わせます。そして次年度からは、評価基準そのものを微調整して現状に合わせるか、あるいは調整幅を少なくした再度の「調整給」で辻褄を合わせるなどしながら運用を継続します。また、誤差が5%未満の従業員でも、賃下げになる者は不満でしょうから、やはりその年度は「調整給」で先の例と同様の措置をとります。日本の企業では、一般には毎年少しずつ賃金レベルが上がって行きますので5%未満の誤差は2-3年で自然に解消されて行きます。僅かでも賃金レベルの上がった者は基本的には文句はないのですが、「スキル手当は上がったが、基本給は下がった」というように、賃金の内訳が大きく変わりますので、その説明は社長自らが従業員に対して十分に行う必要があります。この場合もやはり「人事の基本方針」を明確にしていないと、それを聞いた従業員が納得しません。
「らくちん社長-賃金決定」の初期導入では、最初から「完全を目指して」導入するのではなく、最初は「最低限の試験的な導入」を行い、徐々に段階を追って、より正確で整合性のとれたシステムへと移行していくことをお奨めします。
「最低限の試験的導入」段階では、「らくちん社長-賃金決定」自体のソフトウエアの操作性に慣れ、その操作を通じて基本的なシステムの構造を理解する、ということを期待します。従って、この段階は言わば“練習段階”ですので、投入データは最低限のものに絞り、データ間の“不整合性”に関してはあまり細かいことを問わないことにします。
全社員のデータは一旦この「最低限の試験的な導入」のレベルで、全部入力を済ませます。
次の「導入の第２段階」では、正確な給与計算に必要な個人情報、および「最低限の試験的導入」で割愛した残りのデータを、全部入力し、相互に整合性のある状態を保証します。全社員に関して、この段階でのデータ投入を完了します。
「導入の第３段階」では、社員の個別情報ではなく、会社全体での賃金水準（年齢学歴給や勤続給、各種手当額などの水準）を決定します。そして、何回かのシミュレーションを行い、全体として、社員全体の８割ぐらいの給与が当システム導入前の給与水準に近くなるような値を模索し、適当な水準を決めます。
そして「導入の最終段階」では、各社員の人事考課を行い、最後の絶妙な格差を設定します。また、お客様によって異なる、社員区分をはじめとする、職能格、職位などの名称の変更を行い、本番に移行するための準備を行います。
この「導入の最終段階」から、再び「導入の第３段階」に戻って、試行し直すことは全く問題ありません。むしろ、この二つの段階を何回か往復することで、最適な値に収斂していくのが普通です。
尚、お客様の現行の人事システムがあまり整備されていないような場合は、この「らくちん社長-賃金決定」の導入を良い機会として、社員区分や職能格、職位などの名称や意味までも、この「らくちん社長-賃金決定」に合わせることをお奨めします。そうすることで、お客様の人事システムを容易に整備およびシステム化することが可能となります。
何事も最初から“一遍にうまくいかせよう”というのは無理があります。また、無理にそれを実行しようとすると、反って時間がかかり遠回りになる場合があります。
ここでは、「らくちん社長-賃金決定」の初期導入に当たっては、「厳密な指定をすることで円滑な導入が難しくなる」ことを避けます。最初は多少、厳密さに欠けてもよいから、まずは、「らくちん社長-賃金決定」そのものを稼動させることに注力します。その次ぎの段階から順次、周辺情報を充実させていき、最後の段階で全ての情報を整合性のある状態にする、という手順で導入することを推奨致します。
従って、この「最低限の試験的導入」の段階でのデータは、あくまで「らくちん社長-賃金決定」が、“ソフトウエアとして技術上単に”稼動する、というだけのもので、入力するデータ項目の一つひとつの値自体は正確でなくてはならないものの、全体のレコード間の整合性は全く期待しない、という認識のレベルとなります。業務上は言わば半分”でたらめ”に近い状態ですので、このデータに基づいた給与計算などは、“動作確認”という技術的検証の意味はあっても、その計算値には業務上何らの意味はない、ということを承知願います。
以降、この手順に沿って解説致します。
尚、実際の画面の操作や登録･指定するデータの説明は、それぞれの該当項目に関する後続の各章で詳細を解説してありますので、そちらを参照願います。
最低限のシステムを導入する場合は、それなりの前提があります。この前提の下に、多少の矛盾があっても気にせずに、前に進んで下さい。
人事システムは、組織によって千差万別です。従って、人事上の要素を表す言葉も違います。本来は、これらの名称や係数、金額などを完全に調整してから各種の登録作業を開始するのが正当であるように思えますが、この手順で実行しますと、いまだ「らくちん社長-賃金決定」という道具に十分に慣れていないにも拘わらず、複雑な指定をすることになり、初歩的な操作ミスなどで手順が逆になるなど、うまく行かずに逆効果になります。
従って、最初は、例えお客様の実際の人事システムとは齟齬があっても、無理にでも「らくちん社長-賃金決定」の既定値に合わせて、一時的にその既定値の中から選択して指定することをお奨めします。
当システムを最初に導入した段階では、数件のサンプル･データを格納してあります。このデータがお客様にとって参考にならずに邪魔である場合は、削除願います。特に邪魔でないならば、本番移行までは残しておいても何ら問題はありません。
また、当解説書の全体、特に目次には事前に目を通して頂き、どの章にどういう解説があるのか、という全体的な雰囲気を感じとっておいて下さい。実際の操作の段階では、詳細な操作要領を知る必要がありますが、その場合に、解説書内の該当部分を探すのが容易になります。
なんの準備もなく、突然、パソコン画面に「らくちん社長-賃金決定」の入力画面を表示しても、結局は、「何を入力してよいか分からない」か、もしくは「入力データが手許にないのでわからない」という状態になります。
社員に関するデータ、特に、社員名や社員番号、生年月日、入社年月日などの基礎データは、事前にノートなどで整理しておいて下さい。その他、段階を追って必要となるデータは、本節、後述の解説を参考にして準備願います。
各種区分コードは、お客様での当システムの整備が進むに連れて、段階を追ってより正確に、より整合性のある状態にもっていかなくてはなりません。が、しかし、当初の導入段階では、最低限必要な部分を最初に登録します。
以下に掲げる区分コードは、社員異動記録を入力する場合に必要です。既定値を利用することが可能な場合は、なるべく既定値を利用して下さい。そうでない場合は、新たに登録をして下さい。
特に「地区コード」に関しては、お客様の地理上の場所により全く異なりますので、普通は新規登録が必要となります。
l 職種コード登録
l 部門機能コード登録
l 地区コード登録
尚、「社員区分コード」に関しては、これは「らくちん社長-賃金決定」においては最も重要な区分コードですが、これを検討するには大変な時間を要します。従って、導入当初の段階では、多少、お客様の現行の人事システムの区分とは違っていても、無理にでも、当システムの既定値を当てはめて下さい。無論、当システムの整備が進んだ最終段階では、この社員区分コードの名称をはじめ、各種の係数やパラメータを追加・変更するのは、大変妥当なことであります。
その為には、お客様の現行の人事システムでの、この“社員区分”に相当する“区分”と、「らくちん社長-賃金決定」での社員区分コードとの対比表などを準備し、その対比表に基づいた、各社員の社員区分を事前に決めておく必要があります。
社員番号を新たに発行し、その他、基本的な社員属性を同時に登録します。
社員番号は、一旦その値を決定して具体的な社員名や社員に関するデータを入力してしまいますと、後から、社員番号だけを変更することは出来ません。社員番号だけは“間違い”のないように正確に決定して下さい。
「入社処理」は、次号以降に述べるところの、本来は目的の異なる別々の記録である「社員基本属性登録」と「社員異動記録」への登録を、操作をより単純かつ簡便にするために、一つの処理にまとめたものです。
従って、この処理において、入力を要求する画面は、本来は、社員基本属性登録画面において入力する項目と、社員異動記録画面において入力する項目を、一つの画面で、一度に入力するようになっています。これにより、複数画面の切り替えに伴う操作の煩雑性や、それによりユーザが思考の連続性を妨げられるような事態を回避し、より単純に、入社手続きができるように配慮しています。
「入社処理（社員番号発行）」は、入社に関する一連の処理を実行します。
「入社処理（社員番号発行）」（コマンドボタン）を押すと、
１． 入社処理-既定値の登録
２． 入社時の初期入力
の順に、画面を表示します。
１と２の画面は、ほぼ同様の内容を表示する画面ですが、１の「入社処理-既定値の登録」画面は、２の「入社時の初期入力」画面での「既定値」（あるいは「省略時解釈」）を事前に登録する画面です。 これは、本来、お客さまが２の画面で、手入力で入力するべき内容の内、全てのレコードあるいは大方のレコードで共通する項目、例えば「異動区分」や「異動年月日」、「入社年月日」のように、どの社員であっても、その値が同じになるような項目を、事前に既定値として登録することで、同じ値を繰り返し入力するのを省略することができるようにする機能です。
尚、「入社処理」は、本来、「社員基本属性」および「社員異動記録」の各記録に別々に登録する内容を、入社処理の操作を簡便にするために、一つの「入社処理情報」として、「一つの受入れデータ」にまとめたものです。従って、各入力項目の意味や説明は、（第７章 社員別各種記録のè「社員基本属性」および「社員異動記録」）の、それぞれ該当する項目にその詳細説明がありますので、そちらを参照願います。
また、各項目の内、背景色が「黄色」の項目は「入力必須」項目です。同「緑色」の項目は、正社員の場合は必須項目であり、また、そうでない場合でも大抵は「入力した方がその後の処理が容易になる」ので、入力することを強く推奨する項目です。
以下の機能を用意しました。
l 既定値の登録
l 社員番号の自動採番基準
l 複数社員レコードの生成 （プロフェショナル・オプション機能が必要です）
l 異動年月日
l 異動区分コード
l 姓名
l 入社年月日
l 生年月日
l 社員区分コード
l 最終学歴
l 卒業遅滞年数
l 満年齢
l 給与基準年齢
l 職能格コード
l 職位コード
l 職種コード
l 給与基準学歴
l 部門機能コード
l 株主区分コード
l 地区ＩＤ
l 組織コード
l 組織名
l 勤務時間形態
l 就業開始
l 就業終了
l 夜間勤務
l 通常勤務
l 月間勤務
l 備考
既定値を登録するか否かを指定します。
既定値を登録すると、次の「入社時の初期入力」（画面）で、各レコードを表示した瞬間に、登録した項目に既定値を自動入力します。
入社処理する社員に社員番号を採番する場合、特に恣意的に特定社員に特定番号を振る理由がない場合は、社員番号の小さい方から、空いている番号を順番に自動採番するのが効率的です。
この場合、自動採番する時の、起点となる最小番号（社員番号採番起点）と、採番する場合の社員番号間の数値に間隔（社員番号採番間隔）を指定します。特に指定がない場合は、１番から、１づつ番号をカウントアップして採番します。
自動採番した番号がたまたま既存の社員番号と重複する場合は、その番号の一つ上の番号を生成します。その番号もまた同様に重複する場合は、重複がなくなるまで同様の手順を繰り返します。
全社的な給与シミュレーションなどで、特定社員の個人情報にとらわれず、一種のテストデータとして複数の類似の社員レコードを一度に生成する場合は、生成社員レコード数を指定すると、その数だけレコードを自動生成します。
例えば、専門家（社会保険労務士、中小企業診断士、税理士、経営コンサルタントのような職業の方）が、特定の会社の賃金政策を策定する時の各種の賃金シミュレーションをする場合などに大いに利用できます。
「生成社員レコード数」で、生成するレコード数を指定します。「生成社員番号採番起点」と「生成社員番号採番間隔」は、前号の「社員番号の自動採番基準」と同様です。
入社処理する社員の「入社処理」に必要な基本的な各種情報を入力します。
ここで入力する情報は、お客さまの準備情況により次のように異なるでしょう。
当該社員に関する「全ての情報」ではなく、入社処理の段階で最低限必要な初期情報だけを入力します。最終的には（あるいは正確には）、ここで指定する項目以外の項目の入力が必要で、完全な社員情報が必要です。それらの情報は、一旦この入社処理した後の、追加、または修正入力として、「社員基本属性登録」、「社員異動記録」、「社員スキル記録」、「社員家族情況記録」および「社員プロジェクト記録」で登録します。
入力の必須項目は「黄色」の入力域です。「緑」の入力域は、契約社員や役員の場合は必ずしも必須ではありませんが、（年齢学歴給の対象となる）正社員の場合は、必須です。
「この画面で処理をした後に、追加、または修正入力として、『社員基本属性登録』、『社員異動記録』の入力することは二度手間である」と判断された場合は、この画面で、一度にこれら（「社員基本属性登録」、「社員異動記録」）の人事情報を入力してしまうことが出来ます。
（ただし、「社員スキル記録」、「社員家族情況記録」および「社員プロジェクト記録」に関しては、この入社処理後に、別途入力する必要があります）
入社処理する社員の姓とふりがなを入力します。
全社的な給与シミュレーションなどで、特定社員の個人情報にとらわれず、一種のテストデータとして複数の類似の社員レコードを一度に生成する場合などで、姓とふりがなを入力しない場合は、システムが自動的に生成した機械的な名称になります。この場合は、姓は「社員区分名の左３桁分」の名称になり、ふりがなは、実際の姓に関係なく「んんん」となります。
入社処理する社員の名とふりがなを入力します。
全社的な給与シミュレーションなどで、特定社員の個人情報にとらわれず、一種のテストデータとして複数の類似の社員レコードを一度に生成する場合などで、名とふりがなを入力しない場合は、システムが自動的に生成した機械的な名称になります。この場合は、名は「社員番号」そのものになり、ふりがなは、実際の名に関係なく「んんん」となります。
社員番号は、数値として取り扱います。従って、先行するゼロは無視します。つまり”007”と入力しても“7”となります。
社員番号の変更はできません。
社員番号の“変更”とは、新社員番号を発行し、その社員番号に対して、社員名などの社員基本属性や社員異動記録など社員別の各種の記録を作成した後に、それらの記録をそのまま保持した状態で、社員番号だけを別の番号にする、ということです。
社員番号は、「らくちん社長-賃金決定」にとっては、システムのキー情報です。銀行の口座番号などと同様に、この番号こそがあらゆるシステム制御の根幹をなすシステム情報です。一旦生成した社員ごとの各種情報は、内部的に多くのレコード群に分散して記録しますが、その相互関連は、この社員番号を相互に保持・参照することで、全体として整合性のあるレコード群として管理状態を保持しています。このような状態で、このキーとなる社員番号を変更するということは、画面上の外観から感じる程には単純ではありません。内部的に相互に連鎖する膨大な関連情報を全部更新することになり、技術的に不可能ではないにしても、大変危険なシステム構造となります。加えて、人財管理システムという業務上特質からも、この社員IDたる社員番号を“変更可能”ならしめることは、業務上もまた危険な要素となります。
従って、一旦発行した社員番号は変更することは出来ないようになっております。
業務上の管理ミスや操作ミスにより、社員番号を間違えて発行してしまった場合は、新たに正しい社員番号を発行しなおして、社員データを全部入力しなおして頂きます。また、間違えた社員番号が別の社員の番号であった場合は、その「別の社員」の社員データを上書きする形で更新入力して下さい。間違えた社員番号に該当する社員がいない場合は、その社員番号は、社員基本属性の画面で、「論理削除」して下さい。
論理削除した後は、速やかに物理削除も併せて実行願います。物理削除をしないと、業務上、つまり人間系では、存在しないことになっているレコードであっても、ソフトウエアの制御システムとしては存在しますので、新規の社員番号を発行する際の論理に影響を与えるからです。
入力処理中に、再度、「入社処理-既定値の登録」の画面に戻る場合に指定します。
「入社処理-既定値の登録」画面上で、「複数社員レコードの自動生成」の「生成社員レコード数」にゼロ以外の数値を指定した場合に、このボタンを押すと、「生成社員レコード数」に指定した数だけの入社処理レコードを自動生成します。
画面上の入社処理の全レコードを削除します。
特定の入社記録を削除する場合は、レコードの左端にある「レコードセレクタ」を押し、キーボード上の「削除キー」（Ｄｅｌｅｔｅ Ｋｅｙ）押します。
「物理削除します。大丈夫ですか？」の確認メッセージを表示しますので、「ＯＫ」すると物理削除します。
入社処理の「実行」を行わずに画面を終了します。
この場合、入力した入社処理レコードは保持されます。
入社処理を実行した場合で、実行後に、画面上の入社処理レコードを削除する場合にこの値をＯｎに設定します。特に理由がない場合は、Ｏｎに設定します。
既定値はＯｎとなっています。
入社処理レコードの内、何ら問題なく処理され、入社処理が完了したレコードは削除されますが、入社処理レコードの入力値に誤りがあり、その後の入社処理で矛盾が生じ、入社処理が完了できなかったレコードは削除されずに残ります。
例えば、ある特定の社員区分コードでは、「社員の所属組織コードを必ず指定しなくてはならない」という規定があるとします。にも拘わらず、入社処理のレコード入力で組織コードを入力しなかったような場合は、このレコードは「入社処理エラー」となり削除されずに残ります。この場合、お客様は、入社処理が失敗した理由を調査し、訂正した後に再度入社処理を行います。こうして、最終的には全ての入社処理レコードが完了し、削除されます。
入社処理を「実行」する場合に押します。
「入社実行」をすると、画面上の入社処理レコードの情報に基づき、入社処理をする社員の各種関連レコードを生成します。
既存の社員に対して、入社処理を再実行した場合は、指定した項目内容に関し、既存のデータは上書きされ書き直されます。
入社処理は、一人の社員の入社記録から、当該社員に関連する全て記録を生成・追加・更新します。従って、その処理には相当の時間を要します。ご了承下さい。
次項の「最低限の社員基本属性」と「最低限の社員異動記録」で説明する項目は、この号で説明した「入社処理（社員番号発行）」を実行した後は、この入社処理自体に同じ項目が既に全て含まれておりますので、改めて実行する必要はありません。
ただし、この「入社処理（社員番号発行）」を実行した後になって、入力のし忘れ、修正、更新などが発生した場合は、以下に示すそれぞれの画面において修正入力を行い更新します。
社員基本属性は、最低限の、「それを入力しないと、画面を終了することが出来ない」という種類のものに限ります。
尚、社員基本属性に関する詳細は（「第７章 社員別各種記録」è「社員基本属性の登録」）を参照願います。
社員の本当の生年月日を入力します。これを間違えると、年齢学歴給は退職年齢が狂いますので、注意願います。
姓名区分は、特別の事情がない限りは「社内普通名」とします。
姓名は、本籍名でも、通称でも問題はなく、社内で使う名称を入力します。
姓名ふりがなは、“ひらがな”で入力します。社員名は“ふりがな”で検索しますので必須項目です。
代表名（チェックポックス=On）とします。
ここで入力した社員名を、「当該社員を一意に表す（代表する）名称として登録する」、という意味になります。
社員異動記録は、最低限の、「それを入力しないと、画面を終了することが出来ない」という種類のものに限ります。
以下の項目は、上述の「各種コードの最低限の事前準備」で、お客様が準備した、各社員ごとに決めた値を入力します。
尚、社員異動記録に関する詳細は（「第７章 社員別各種記録」è「社員異動記録」）を参照願います。
異動年月日は、最初のレコードは「入社」でなくてはなりません。入社には、大きく分けて「入社（新規）」と「入社（移管）」の二種類があり、日付もそれぞれ、「入社年月日」および「移管年月日」となります。
「入社時の初期入力」（画面）で入力する異動年月日の場合は、入力のタイミングと対象によって次のように異なります。
異動年月日は当該社員の「入社年月日」を指定します。
この場合、異動区分は、「入社（新規）」として下さい。
「入社年月日」を別途入力している場合は、異動年月日は、この入社処理をした移管日にしても、特に問題はありません。ただし、この場合、異動区分は「入社（移管）」として下さい。
異動年月日は、「入社（移管）」をする日付とします。日付は、入力する当日の日付にするケースが一般的ですが、別途、お客様の都合で人事管理上の日付としても問題はありません。
この場合、異動区分は、「入社（移管）」として下さい。
異動年月日を、当該社員の「入社年月日」にしても、特に問題はありません。ただし、この場合、異動区分は「入社（新規）」として下さい。
初期導入において、「過去に入社した社員」の異動年月日に「入社年月日」を入力した場合は、当然ながら、当記録を入力する現在日付からは、「相当の過去」の日付になります。
「らくちん社長-賃金決定」では、現在日付から遡ること90日以上前の過去の日付を入力しますと、
「このレコードは最初に記録されてから、90日以上経過しています。同一レコードへの訂正ではなく、別途、新たなレコードを作成することを薦めます。それでも訂正しますか？」
という、“既存レコードへの訂正ではないか”、と疑った注意メッセージを表示します。
ここでは、初期導入という特殊な事情であるので、常に「OK」（つまり“訂正する”という意味）とします。
異動区分は、「入社（新規）」または「入社（移管）」です。この異動区分は、“絶対必須”の異動区分で、これがないと、社員が入社したことになりませんので、社員に関する一切の処理ができません。
尚、この「入社（新規）」または「入社（移管）」の異動区分の記録を入力しないで、画面を終了しようとした場合は、エラー・メッセージが出て、終了することが出来ません。必ず入力して下さい。また、この異動区分の記録を誤って二つ以上入力してしまった場合も同様です。
お客様が、当該社員に対して事前に決めた社員区分を指定します。
これにより、年齢学歴給をはじめ、各種の基本的な賃金要素が全部変ります。「らくちん社長-賃金決定」では最も重要で、最も影響力のある区分コードですので、最大限の注意して決定して下さい。
お客様が、当該社員に対して事前に決めた社員区分を指定します。
これにより、職種考課係数および職種賞与係数が変ります。これらの係数は、社員の基準内賃金の「メリット給」および賞与の「考課分」の算出額に影響を与えます。慎重に決定願います。
お客様が、当該社員に対して事前に決めた社員区分を指定します。
これにより、影響を受ける賃金要素は一般にありません。ただし、就業開始・終了時刻が異なる場合があります。
お客様が、当該社員に対して事前に決めた社員区分を指定します。
これにより、影響を受ける賃金要素は少なく、「寒冷地手当」などの、地区別の手当がある場合だけです。
中小企業の場合、本社や工場、支店などが、全国に分散しているというケースは少ないので、一般にこの地区IDは、社員全員が“同じ”という場合が多くなります。
前記の「最低限の試験的導入」の段階での、言わば半分“でたらめ”に近い状態から、多少はデータに意味のある状態までもっていきます。ここでは、社員に関する“基本的な情報”（考課を除く）で、賃金に影響する部分を、正確にかつ全部登録する、という作業を行います。
社員区分コードの次ぎに、社員の賃金算出に影響があるのが、職能格と各種手当（スキル･免許・資格手当）です。
「導入の第２段階」では、各社員の職能格と、手当を登録して行きます。その為には、「らくちん社長-賃金決定」に既定値として用意してある職能格および手当の種類を事前に確認しておく必要があります。
職能格の場合は、日本の中小企業の平均的なものを既定値として用意してありますが、これらの名称は必ずしもお客様の既存の人事システムと同じとは限りません。しかしながら、この段階では、社員区分コードの決定の場合と同様の考えから、多少の無理があっても、既定値に一番近いものを指定します。
その為には、お客様の現行の人事システムでの、この“職能格”に相当する“格付け区分”と、「らくちん社長-賃金決定」での職能格コードとの対比表などを準備し、その対比表に基づいた、各社員の職能格を“暫定的にでも”事前に決めておく必要があります。
尚、職能格登録に関する詳細は（「第８章 各種区分の登録」è「職能格」）を参照願います。
スキル･免許・資格手当の場合は、業界やお客様によって千差万別です。必要に応じて新規登録をして下さい。
この場合、毎月変るような、例えば「出荷手当」や「月間売上インセンティブ」のようなものの登録は避けて下さい。これらの、“毎月その金額が変る”種類の手当は、「らくちん社長-賃金決定」（人財管理システム）で管理する対象ではなく、あくまで、「給与支払いシステム」で管理する対象になります。
「らくちん社長-賃金決定」の主な機能は、「合理的で迅速な賃金決定」であるので、その計算目的は、基準内賃金と賞与にあります。ここでの「各種の手当」は決して「基準内賃金」ではありませんが、職能格と同様に、各社員の“能力の一部”として、毎月定例的に定額を支払う種類のものを対象にする、という基本的考えからきたものです。
尚、「スキル･免許・資格手当」登録に関する詳細は（「第８章 各種区分の登録」è「スキル･免許・資格手当コード」）を参照願います。
以下の異動記録を、“別レコード”として追加します。
尚、社員異動記録に関する詳細は（「第７章 社員別各種記録」è「社員異動記録」）を参照願います。
異動年月日は、以下の異動項目（主に職能格）に変更があった場合の日付を入力します。
尚、株主区分の場合は、一般に入社の段階から株主であり、「後から株主になる」ということが例外的であることから、異動年月日は入社年月日と同一なので、「入社（新規）」レコードに上書きする、ことで済みます。つまり、別途のレコードを追加する必要は特にありません。
お客様が、当該社員に対して事前に決めた職能格を指定します。
これにより、職能格手当と職能格考課係数が変ります。これらは、社員の基準内賃金の「職能格給」および「メリット給」、および賞与の「考課分」の算出額に影響を与えます。慎重に決定願います。
お客様が、当該社員に対して事前に決めた株主区分を指定します。
これにより、株主区分考課係数と役員賞与係数が変ります。これらは、社員の基準内賃金の「メリット給」」の計算額に影響を与えます。慎重に決定願います
お客様が、当該社員に対して事前に決めたスキル・免許・資格を登録します。
これにより、各種手当額が変ります。ただし、これらは、社員の基準内賃金には一切影響は与えません。
尚、「社員スキルの登録」に関する詳細は（「第７章 社員別各種記録」è「社員スキルの登録」）を参照願います。
当該社員の家族情況を記録します。
これにより、（お客様でその規定があれば）家族手当額が変ります。が、これらは、社員の基準内賃金には一切影響は与えません。
尚、「家族情況記録」に関する詳細は（「第７章 社員別各種記録」è「家族情況記録」）を参照願います。
前記の「導入の第２段階」では、全社員各個人の情報整備を完了しましたが、この「導入の第３段階」では、お客様の組織の賃金体系や賃金水準を整備していきます。前記の個人情報とこの賃金水準情報の組合せにより、各社員の複雑な賃金を合理的に迅速に決定できるようになります。
尚、この「導入の第３段階」と次ぎの「導入の最終段階」では、「どこまでやれば十分か」ということの答えはありません。この二つの段階では、お客様の経営理念（人事方針）に照らし合わせて、また、現行の賃金水準に照らし合わせて、お客様（のトップの方）が「納得がいくか否か」で決まることですから、その納得の行く線になるまでは、何回もシミュレーションを繰り返すことになります。
従って、ここでは、賃金水準に影響力のある項目に絞って説明しますが、現実には、より細かい、絶妙な指定が必要になる場合が一般的です。この場合は、当解説書の各章を熟読の上、各種の係数を幾種類にも変えながら試行錯誤をしていただきますようお願い致します。
「賃金水準の設定」は、基本的な登録画面数だけでも５つあり、その指定項目は多岐を極めます。
基本的には、当システムの既定値を利用するのが適当と思われますが、お客様のシステムとの違いが大きい場合は、変更する必要があります。
尚、「賃金水準の設定」に関する詳細は、（「第６章 賃金水準の設定」è「賞与・給与の基本記録」以降の前節）を参照願います。
ここで、最も影響力のある項目は、「給与ポイント金額」です。これを変更すると、ほとんど全ての賃金表の金額が変更になります。
ここで、最も影響力のある手当は「職能格手当」です。この手当が社員の基準内賃金に占める割合は、社員の地位が上がるほど大きくなります。既定値では、係長以上の場合、この金額の調整次第で大きな格差がでるようになっておりますので、大変有効な調整要素となります。
正社員年齢学歴給では、第一に「大卒総合職」の賃金から調整します。この賃金水準で、大卒社員および課長以上の社員（多くは総合職であるので）の給与水準が、現行の水準と概ね整合性が取れるような設定になるまで調整を先に行います。
年齢学歴給で一番問題になるのは、「飽和年齢」の設定です。「どの年齢以上は、年齢に拘わらず年齢学歴給を一律にするか」、という年齢です。多くの中小企業では、40歳以上の社員の処遇に苦慮しています。この年齢以上の社員の処遇に直接影響する数値ですので、その調整には細心の注意が必要です。
大卒総合職の調整が済んだところで、高卒業務職、高卒一般職へと、順次調整を移していきます。
これは、「役員および契約社員」（非正社員）の年齢学歴給に相当する部分です。
契約社員の場合は、多くの場合は時給そのものですから、決定は容易です。
問題は役員の場合です。役員の報酬月額には、本来、当システムのような「基本金額」というような内訳はありません。従って、この基本金額部分だけを取り上げてその多寡を論じても意味がありません。最終的には、この金額に加えて職能格給およびメリット給を合わせた合計金額で論じるべきものです。従って、ここでは、正社員総合職の年齢学歴給参考にし、その飽和金額の倍ほどの金額を、最高賃金（一般には社長の賃金）の「基本金額」の初期値として暫定的（試験的）に与えます。そして、この試験的な初期値でもって、全社員の給与計算を行い、社長から契約社員の全社員の賃金をその多寡の順に並べて全体のバランスを勘案し、何度も調整しなおすることで、最適のバランスを決定します。
勤続給関数は、年功序列賃金体制と密接に結びついた賃金要素です。現在の日本では、この賃金体系の是非に関して色々の議論はあるものの、現実には、無視し難く存在しております。
ここで、問題になるのは、その金額の多寡の、「正社員年齢学歴給」（非正社員の場合は基本金額）に対する割合（「勤続給係数」）の他、その上昇カーブの形（モデル関数）が問題になります。上昇カーブの問題とは、ある一定期間を過ぎると飽和（一律になる）させるべきなのか、あるいは例え10円でもよいから、定年までは少しでも上昇させるのか、ということです。
これらは当然、お客様の経営理念（人事方針）で決定すべきことがらですが、いずれの方針であろうとも対応可能なように、各種の関数を用意しております。
既定値では、正社員の場合は、「勤続年数の“二乗根に比例”」する関数になっており、契約社員の場合は、「最初の数年は一定額で増加し、その後は一律になる」ようになっております。
社員区分はそもそも組織全体の賃金水準を設定するものではなく、社員区分の違いによる処遇の差を設定するものです。社員の個々人に関する情報は前段階までで完了しましたが、社員区分間の処遇の差というのは、お客様の経営理念（人事方針）により、その意味も額も異なりますので、その設定作業の位置付けは、「組織全体の賃金水準の設定」と「社員個々人の設定」との中間的な意味あいを持ちます。
この“中間的な意味あいを持つ”設定は、社員区分のみならず、その他の区分にもありますが、この“社員区分の設定”が、“その他の区分”の場合に比較して、影響の度合いが一番強いことから、この社員区分での設定を先に述べます。
尚、「社員区分コード」に関する詳細は、（「第４章 各種区分の登録」è「社員区分コード」）を参照願います。
社員区分の係数のうち、給与額に影響があるのは、社員区分考課給係数と社員区分賞与係数です。
これらの係数は、その値そのものは重要な意味はありません。基本的には、正社員総合職のものを基準の1とします。重要なことは、この総合職の1と比較して、その他の社員区分のものがどの程度大きいか小さいか、という比率の問題です。
前記では、社員区分での各種係数の設定を述べましたが、その他の区分にも同様の設定があります。以下にリストしますが、その意味と扱いは、社員区分の場合と全く同様です。“社員区分”を“その他の区分”の名称に読み替えて解釈して下さい。
l 職能格考課給係数と職能格賞与係数
l 職位考課給係数と職位賞与係数
l 職種考課給係数と職種賞与係数
l 株主区分考課給係数と株主区分役員賞与係数
「導入の最終段階」は、本番移行を念頭においた段階です。
本番移行ですから、お客様の現行の人事システムに合わせる場合は、社員区分や職能格、職位などの名称変更などを、機能的には何ら変らないことであっても、運用上の混乱を避けるために行った方が安全です。あるいは全く逆に考えて、お客様の現行の人事システムがあまり整備されていないような場合は、この機会に、その呼称なども含めて、「らくちん社長-賃金決定」の手法および名称に合わせるということも考えられます。
この段階までは、社員個々人の人事考課はまだ行っていません。また、その他のメモ情報など、賃金に直接影響のないデータの投入もまだ行っていません。人財管理システムは、「賃金だけを決めれば“それで使命は終わりだ”」という訳ではありません。本番移行では、これらの情報も全て網羅して、お客様の人財を管理していく必要があります。
「導入の第３段階」までは、給与計算のシミュレーションを行う際は、“時間上の制約から”各社員の人事考課は“3”（平均）として行うケースが多いと思います。社員全体の賃金バランスを俯瞰する場合はその方が全体を把握出来るので良い場合があります。しかし、本番移行の段階では、各社員の人事考課をキッチリと決めておかないと、次ぎの“昇給や昇進”の“タイミングや理由”が曖昧になります。
人事考課の値は、0から7の間の数値（実数）で行います。現実には、1960年代の日本の中学校と場合と同様、1から5の間が普通となります。お客様のトップの方の大多数が、この評価システム（1から5の５段階評価）に慣れておられることから採用した数値範囲です。“0”は「メリット給部分をゼロ査定する」という意味で、事実上“降格”に値するギリギリの考課です。“6”や“7”は、それぞれ次期昇進や2段階昇格などの抜擢に値する極上の評価です。
尚、「人事考課」など「給与決定」の詳細は（「第８章 人事プロセス」è「給与決定」）を参照願います。
賃金システムが変更になると、どうしても、従来の賃金と、システム変更後の賃金に埋め難い差が出る社員が現われます。結果として昇給になる社員の場合は、問題は少ないのですが、大きく減額になる場合は、前記の“考課の範囲”では補えない場合が出てきます。そもそも「“考課”で“調整”」するということは、本来の“考課”の意味を無視することに繋がり、決して推薦できる管理手法とは言えません。
この場合は、“考課”で“調整”することは行わず、“調整給”で“調整”するべきであります。
調整給は、調整給の額自体を指定することも可能であり、また、最終的な基準内賃金額を先に決めてから、調整給が自動的に逆算されるような入力方式も可能です。
各個々人の給与の“過渡的調整”はこの“調整給”で行って頂きます。
「メモ情報」とは、その情報が“あってもなくても”、最終的には社員の評価や給与計算には直接影響しない、という情報です。典型は住所記録です。
しかしながら、人財管理システムというのは、社員を“人財”として扱い、管理することですから、その人物に関する属性情報は網羅的に限りなく正確に把握することが大事です。住所記録なども、社員評価には無関係のようですが、仮に、居住地区によって市民税の税率が違ったり、あるいは寒冷地手当などの社内手当が違ったり、というように“収入の違い”には繋がる可能性があります。
社員基本属性には「血液型」という「何に利用するのか」が一見不明な管理項目がありますが、これなども、事故の場合の輸血を想定した記録です。特に「Rhマイナス型」情報などは、適合血液を発見すること自体が困難であることから、特記してあります。
「その他メモ情報」は各種の記録に分散しております。お客様の必要度に応じてその情報の厚さを増して行くことが大事です。以下にそれらの記録の種類名をリストし主な「メモ情報」項目を載せます。
l 採用区分
l 性別
l 血液型
l 出生地
l 出身地
l 使用言語
l 縁故情報
l 姓名説明
l 社員の顔写真
l 社会属性各種
l 連絡先各種
l 備考
l スキル・免許・資格手当などと直接関係ないスキルなどの登録
l スキルレベル
l スキル使用頻度
l 異動自由
l プロジェクト説明
当システムでは、賞罰記録は給与計算には一切関連がありません。賞罰記録そのものが一種の「メモ情報」になっております。
区分コードの名称変更の対象になるのは、主に、社員区分、職能格、職位です。
先にも触れたように、お客様の人事システムが未整備の場合は、これらの変更をせずにそのまま利用することができます。
変更の例をあげますと、
例１：社員区分の場合、「一般職」è「事務職」、「契約社員」è「パートタイマー」
例２：職能格の場合、「課長」è「管理一級」、「部長」è「主管者2級」、「理事格」è「経営職３級」
例３：職能格の場合、「1stライン」è「課長」、「2ndライン」è「部長」
区分コードの名称変更の際、注意することがあります。
変更は、名称、区分説明など、文字情報だけに限定する必要があります（各種の係数の変更は既に「導入の第３段階」で終わっています）。
絶対に行ってはならないのは、“コード値の変更”です。例えば、既定値の「正社員（総合職）」のコード値は”３6”ですが、今この値を仮に”35”に変更した場合が「コード値の変更」になります。そもそも区分コードの値は、既に、社員異動記録および給与記録、賞与記録に転写され分散してしまっております。ここで、仮にこれらのコード値を上記のように変更してみても、肝心の人事異動記録や社員給与記録には反映できません。コード値の変更をこれらの分散した情報に反映するためには、これらの記録（人事異動記録や社員給与記録）を全部、（場合によっては削除してから）最初から作成しなおす必要があります。
新コード値を「追加」する場合は、そのこと自体に問題はありませんが、この段階で行うべきではありません。新コード値の追加は「導入の第２段階」の前で行うべきことです。新コード値の追加は、社員異動記録を入力する前に整備しておきませんと、折角の社員異動記録および社員給与記録などを全部作成し直さなくてはならなくなる、からです。