第１２回「人事情報システム導入のプロセス」１１
［ 掲載日 ］2023/10/30
［ 掲載日 ］2023/10/30
（２）パッケージ選定フェーズ
１）ＲＦＰの作成（Request For Proposal）
③ 要求定義
ＲＦＰの要求定義は、製品（パッケージ）を決めるためのものであり、ある程度理想に近いレベルのものを作ることになると思います。始めから、こんな機能はないだろうとか自社の業務プロセスや固有のものは遠慮しておこうなどと考える必要はありません。ただ、自覚があるまたはこれは期待が高すぎる、優先順位は高くないといったものは、明示する必要があります。高すぎるレベルの要求は、ベンダーに尻込みさせてしまうか、想定予算を遥に超えた回答を誘発するものになります。
この要件定義は、一から作ろうとするとかなり大変な作業です。こういった作業を支援するコンサルタントには、一般的な業務一覧やシステムに要求する内容がまとまったテンプレートがあるのでそれを使うことが多いのですが、やはり企業によって事情が異なるので、部門に対するヒアリングが必要になります。
このヒアリングの実施については気をつけたいポイントがあります。
人事部門は元から現状のシステムとの比較で改善したい点を中心に意見を言います。その要求は妥当なのか、作業効率の問題か、説得力がある内容かなどを検討した上でまとめていく必要があります。
そして起こりがちなのが、聞きっぱなしで要求定義を進めてしまうことです。
ヒアリングのまとめを行う時点で、その要求は公式なものとして採用するか今回は見送りにするか等の評価を行うイベントが必要です。これを行わないと、特に事業所の業務担当者やプロジェクトの情報が入らない部門の期待外れの失望が大きくなります。
実際に製品が決まって、導入のために行う要件定義のときに、大きな問題が発生します。
つまり、ここは重要なポイントで、ボタンの掛け違いがあるかどうかが導入プロジェクトの行方を左右するといっても過言ではありません。選択した製品が、袖や裾上げ、胴回りなどの修正は対応できるけど、肩幅や腰回りまでは手を付けられないとか、制約を正しく理解しないと、折角時間を掛けて要求定義を作っても無駄になってしまうからです。
要求定義は下記のような分類ができます。
【機能要求】
システム機能として、人事給与などでは一般に人事管理、給与計算、就業管理、福利厚生、届出申請などに分類されます。更に、それぞれが［個人情報］［発令］［採用］［評価］などのサブシステム的に細分され、その中身に必要な機能が列記されて機能要件になのです。
すでに多くの利用ユーザが存在するパッケージは、それなりに世間の要求する機能は備えています。極端に言えば、自社が例えば同業のどこどこと寸分違わぬオペレーションをしていて、その会社が納入先として登録されていれば、詳細な検討は必要ないのかもしれません。同じことができれば良いというものさしで十分なら、ＲＦＰも必要ないのです。
よく言われることですが、経理部はあまり細かいことは言わないのに、どうして人事部は「ウチは特殊だから」と主張して譲らないのかという疑問があります。経理も財務会計だけなら良いのですが、管理会計となると独自性が出てきます。まして労働法など縛られる法令が限定されていれば、人間を相手にしたものだから、対応するオペレーションは同じものにはならないのだという主張もあります。
しかし給与計算などは、扱う給与項目は別として、オペレーションが特殊になる要素はありません。「標準化」を目指す機能要求は、あまり独自性を出さないようにするべきではないでしょうか。
そうすると残るのは使い易さや自動化などのオペレーション効率だけになってきます。
この標準化を目指す領域と、人材の評価や能力・コンピテンシの管理の仕組みなど、企業人材の競争力に係る部分は別に考えるべきではないじょうか。
この機能要求は、業務別に細かく「〇〇ができること」などを表形式にまとめて、できる、できない、アドオンする、外部で処理するなどの回答を求めていくものです。もともと、競争的なシステムと標準化を目指すシステムとをまとめて企画することは避けるべきことなのですが、標準化領域の機能要求は、「できないこと」を正直に記述してもらった方が良いのです。また競争領域のシステムは、妥協できない部分を含めて、御社が求めていることができないパッケージを使うべきではないと思うです。
【非機能要求】
業務的視点から「あれはできるか」「この機能はあるか」などのチェックを行う機能要求とは異なり、非機能的な要求事項を検討する必要もあります。この部分は、特に業務部門である人事部には荷が重いと思われます。情報システム部門の支援が必要だと思います。
◆ 品質・性能に関する要件
パッケージはある程度、さまざまな企業で使われ実績を積んだ商品です。またパラメータや設定を行うことで、違った動きをすることになります。つまり導入企業ごとに多少異なる機能を持つことになります。そのため、その品質や性能を保証してもらうための要件を記述することになります。たとえばそれを担保するテストをどう行うかやツールなどを使うか等の要求を書くのです。従業員が多い企業については、給与計算の所要時間などが気になる点でしょう。最近はサーバなどの性能が上がったこともあり、以前ほど気にしなくともよさそうですが、レスポンスの問題はコストに響きます。またＢＩツール等を使った検索処理をスムーズに行うことや勤怠管理などの一定期間に処理が集中するシステムについては、ハードウェアの性能問題は殊に重要な問題になります。この点を要件としてまとめる必要があるのです。
◆ 技術に関する要件
スクラッチ開発と異なり、開発モデルや使用言語などの指定はできませんが、少なくとも、どういうテクノロジースタック（環境）で動くものかなどの説明は必要だと思われます。また使っているミドルウェアやデータベース等の指定或いは説明、また運用に使われるツールの指定等を聞きます。更にはソフトウェアの保守や体制についての条件などがあればそれも記述してもらいます。
◆ 運用・操作に関する要件
システムの運用要件とは、人事給与の場合は２４時間３６５日稼働が前提とはなりにくいが、データセンターなどを利用する場合やクラウドを使う場合は、特に注意が必要です。
土日は使えるのか、必要があれば要求に応じてもらえるのか等。災害や事故があった場合の復旧の条件（ＳＬＡ：サービスレベルアグリーメント）も記述することになります。また、バクや操作ミス等による事故発生時の回復条件や稼働時間についての要件などをまとめておくことも必要です。オペレーションに関してですが、業務要員がマニュアルで操作するのが標準である等の、期待と異なる運用を強いられることを避けるため、サブシステム間のデータ連携やバッチによる自動化についての要求は必ず行うことが望ましいと思います。
◆ 移行に関する要件
移行については、現行システムからのデータの移行についての要求は欠かせません。どう移行するのか、プログラムを開発して行うのか、ツールを使うのか、ユーザがどう係わるのか、手順や時期等。給与は特に過去歴についての移行は必ず要求事項に入れるべきです。また、人事管理で難しいのは、発令などの過去歴の移行で、適正に移行できるかはどうかは新システムの運用に影響してきます。発令の整合性や給与との関係性など、システムの特性に絡んでくるのです。正しく移行されないと、退職金の計算ベースなどに面倒臭いトラブルを抱え込むことになります。休職、復職などの発令が面倒を招く例が多いです。更に、現状のシステムへの移行時に積み残した問題、データクレンジングについての責任範囲など、聞くべきことは多いと思います。
◆ 付帯作業やその他の要件
ドキュメント作成や導入時のトレーニング、業務改革の必要性など、大事なことですが、案外疎かにするユーザやザベンダーも多いので、上記の要件以外については注意して検討することが必要です。
またセキュリティ関連の要件も最近は重要性が増しています。更に、パッケージ導入時のサポートデスクや保守期間のヘルプデスクの対応など、検討する項目は少なくありません。