システム導入における要件定義の重要性

要件定義とはシステムで実現したいことを整理するフェーズであり、システム導入においては避けて通ることができないものである。プロジェクトの初期段階に訪れるこのフェーズの重要性や難しさについて、システム導入経験者向けには説明する必要もないと思うが、そうでない人にとっては無知で飛び込むと大けがをする可能性があるものでもある。詳しくはこの後述べるが、建築士と入念な打ち合わせをせずに家の建築を始めてしまうようなものである。

HRTech導入における要件定義の難しさ

それでは、HRTechの導入における要件定義の難しさとは何なのか。人事部においてシステム化対象となる業務は、大まかに以下の2つに分類できる。

A. 給与計算、勤怠管理（定型・ノンコア業務）

定型に近い業務が多く、RPAなどを活用して余力を創出し、コア業務へシフトすることを目的とする類である。これらの多くは制度もしくは法律に基づいた「答え」が決まっているため、その正確性を担保することを絶対条件として、正解に至るプロセスをいかに効率化するかがシステムに求められることである。そしてそのプロセスに対する要件定義に難しさがある。
人事担当者は、要件として「答え」とそれを導く「ロジック」は提示できる。しかし、システム担当者からすると、答えに至るまでのインプットや周辺業務などのプロセスに対する理解がないために単純な「ロジック」だけに目が向いてしまう。

例えば給与計算で例を挙げると、人事担当者が行いたいことが「従業員に勤務時間を申請してもらい、その結果を利用して残業代を自動計算したい」だとする。残業代のロジックを渡されたシステム担当者は、「残業代を計算できればよさそうなので、“残業の開始時間、終了時間、残業単価”をWebで本人に入力させるシステムを作りました」なんて結果が待っているかもしれない。本来は、残業代の計算だけでなく、通常の勤務管理もしたうえで残業時間および残業代の自動計算をしたい訳であり、とても使えたものではないシステムができ上がってしまう。ここで必要だったのは、ロジックの周辺にある業務プロセスの共有と要件の深掘りだったのである。

B. 採用、評価、人員配置、退職予測（非定型・コア業務）

非定型のコア業務で、AI、ビッグデータ、クラウドなどのテクノロジーを活用した業務サポートの実現を目指す類である。
これらの要件定義の難しさは「答えがないこと」に尽きる。コア業務たるゆえんでもある。例えば、経営層から「次世代を担う人材を可視化すべし」とリクエストがあったとする。これに対する答えを持っている人事担当者がどれほどいるだろうか。まずは「次世代を担う」の定義が必要であり、またそれをシステムでどう表現することが経営にとって最適なのかという点も検討しなければならない。これはAの定型・ノンコア業務とは異なり「正しい一つの答え」がない状態であり、仮説から最適解を導き出したうえでシステム要件へと落とすことが必要である。この道のりが非常に難解であることは想像に難くない。またAI、ビッグデータ、クラウドなどのテクノロジー活用例が普及しきっていないことも難易度を上げる要因だ。逆にいえばここで他社に先行して有用なコア業務サポートシステムを完成させられたならば、そのメリットは非常に大きい。

なお、いうまでもないことだが、システムの要件定義をする前に自社が推し進めるべき人事戦略像を明確にしておく必要がある。システムが戦略を作るのではなく戦略ありきのシステムであることを忘れてはいけない。

HRTech導入における要件定義の成功ポイント

これらの特性を考慮しながら要件定義を成功させるポイントを3つにまとめた。

1. 曖昧さをなくしたコミュニケーション

Aの給与計算、勤怠管理（定型・ノンコア業務）の場合は金額の正確性、また法令順守の観点からその正確性の強度が求められる。そのため、「システム担当者がよしなにやってくれるだろう」と考えてコミュニケーションを怠るのは絶対にNGであり、以下のような曖昧さを排除したコミュニケーションを以て要件を提示するべきである。

• 勤怠システムのログインID/パスワードは自社のセキュリティポリシーに則った制御をかける
• 従業員がWebにログインして勤務の開始時間、終了時間、休憩時間を入れる
• 画面の日付はカレンダー、時分はプルダウンでの入力にする
• 所定労働時間は決まっているため、残業時間は自動計算する
• 残業単価は基本給を基に割り出す（給与規定XXを参照）
• 割増率は法定と法定外で異なるため、別途説明の時間を設ける

実際はこの何十倍もの要件になるはずのためここでは省くが、正確性を担保するために必要な情報は全て出し切る必要がある。
また、これら定型・ノンコア業務の効率化を求める場合、業務プロセスをシステム担当者に伝えることも有効である。上記のような個別要件だけでなく全体のつながりを共有することで、実現したいプロセスの全体像と個別要件のつながりが明確になり、より個別要件への理解が進むことになる。さらに、システム担当者ならではの視点でアイデアが出てくることにも期待ができる。
Aのような定型・ノンコア業務システムにおいては、このように「曖昧さ」をなくすコミュニケーションを取ることが非常に重要になってくる。

2. 風呂敷は大きく広げてコンパクトにたたむ

ではBの採用、評価、人員配置、退職予測（非定型・コア業務）についてはどうすればよいのか。これらの高度な内容になるほど答えが曖昧になる非定型・コア業務システムの構築時のポイントは、「できること」を理解することだ。そして理解の後に優先順位を整理する。

人事は現行の業務にとらわれていることが多い。例えば採用や人事評価などは、まだまだ人事担当者の経験や勘で意思決定が行われる現場が多いのではないだろうか。しかしHRTechは進化しているため、以前であればこんなことはできるわけがないということも、システムで実現できる可能性がある。それら思い込みを排除し、HRTechで「できること」を理解し、業務効率化の一つととらえる意識が大切だ。
そして最新のHRTechを活用して「できること」と、従前から「やりたいと思っていたこと」の全てを一旦机上に広げ、優先順位をつけてシステム化のスコープおよびリリースの順番を決める。優先順位付けの重要性について今さら深掘るつもりはないが、少なくともないと業務が立ち行かないものは優先度高、なくても業務は可能だが負荷が高いものは中、あったらよいというレベルのものは優先度低、という程度の分類は付けたいところだ。その業務目線の主観的な優先度とコストなどの客観的な基準で最終評価をするのがよいだろう（図1）。

図1：要件整理のステップ

3. 要件定義における人事担当者の役割を正しく理解する

最後のポイントは、この要件定義工程でのキーマンである“人事担当者”が要件定義フェーズで求められる役割を正しく理解することである。利用者がどのように利用したいかをオーダーするのは必須だが、そのオーダー自体の重要性を認識せず、軽く扱ってしまうケースがある。

例えば、「現在の業務が回ればよいので、現行システムの仕様書を読み解いてシステム担当で作っておいてください」といったオーダーの仕方をする場合だ。仕様書があるため、前述した「曖昧さ」はないかもしれない。ただ、古くからの業務システムはいわゆるスパゲッティプログラム（解読困難なプログラム）になっていることも多い。制度や技術の変更があるたびにシステム全体の最適化を行うわけではなく、応急処置的に絆創膏を貼り続けるためだ。その結果、絡んだスパゲッティはだれにも解くことができなくなる。
また、十数年前に構築したシステムを入れ替えるという話もよくあるが、当時の担当者がいないこともざらであり、その場合はなおさら難しい。しかし、さらに重要なのは解くことが技術的に難しいということではなく、応急処置を続けたシステムは最適化されているとはいえないということだ。そのため、現行システムからクローンの新システムを構築することにメリットはほぼないと考えてよい。
そのほか、システム導入の現場では、現状できていることができればよい、すなわち現行補償という言葉を聞きはするものの、それで構築がうまくいった話は聞いたことがない。「システム（旧）」から「システム（新）」を作成するのではなく、「あるべき業務」から「システム（新）」を作成すべきである。

そもそも何のためのシステム導入なのか、人事担当者として以下の点をしっかり考えて提示したいところだ。

• 自分たちがシステムに何を望むのか
• そのシステムを利用して自分たちの業務をどのようにしていきたいか

これらは人事担当者として望む業務の姿であり、人事担当者が自身の業務改革を成功させるチャンスでもある。ゆえに普段から改善したいと考えている点、大きく変革したい点をオーダーとして十分に出し切ることが求められるという認識が重要である。出し切った後、それらをどのようにシステムに実装するのかを考えるのはシステム担当の仕事だ。この責任分界点をはじめ、要件定義における役割を事前に正しく理解し、プロジェクトに臨むことが3つ目の成功要因である。

ちなみに、システム導入プロジェクトで新人や2～3年目の業務担当者が孤軍奮闘している姿を見ることがある。教育という観点ではあながち間違いではないが、プロジェクトとしては悪手といわざるを得ない。業務要件が伝言ゲームになったり、業務の本質を捉えられずに目的でなく手段の構築に走ったりすることもあるからだ。そのため、要件定義フェーズにはそれぞれの業務プロフェッショナルが参画し、中心となって活動することが必須である。次世代エースの若者たちは、そのサポートをする過程で多くを学べばよいと考える。

おわりに

業務システムの変更はそう頻繁に起こるものではない。また変更する場合でもそのプロジェクトに必ず参画するという訳でもない。そのため、人事担当者としてどのようにプロジェクトに関わればよいかが分からないのは当然である。まして「要件定義が難しい」などと言われてもピンと来るわけがない。この記事に目を通し、システム導入プロジェクトに対する理解と心構えが少しでも読者に伝わり、一つでも多くのプロジェクトが良い方向に進むことを切実に祈っている。