人生100年時代わくわくワークアズライフ

自分のアタマで考えて働きたい。生きたい。さらには誰かに少しでも貢献したい。

勤怠管理システムの要件定義で注意すると導入がスムーズになるポイントについて書いてみる

こんにちは。ERPパッケージシステム導入コンサルタント(専門部分は勤怠管理)のafroriansymです。

今回は、私の本業のど真ん中に関する部分について掘り下げた記事です。

本記事の対象は、私と同じく、「勤怠管理システムの導入コンサルタント」や、「人事部門や情報システム部門で、勤怠管理システムをリプレースしたり、新規導入しようと検討している担当者」を想定しています。

 

勤怠管理システムの要件定義を、できる限り認識齟齬なく実施し、設定テストをスムーズに着手するためのアクション概要を記載します。

 

 

要件定義では誰の視点で何をどこまで掘り下げますか

勤怠管理システムの導入(※前提として、パッケージのシステムでアドオン開発無しです)をする際には、現行の運用内容をヒアリングすることからだいたい始まるかと思います。


ある製品を利用して導入する、となれば、ベンダーのシステム販売の営業さんから、システム導入コンサルタントへバトンタッチ。製品を購入してくださったユーザー様の人事部や情報システム室の担当者の方々へヒアリングをします。


勤怠管理システムに関しては、エンドユーザーが多く、ほぼ従業員全員が利用対象者となる関係上、アズイズ(既存の利用方法を担保する)での導入が基本であるかと思われます。というか、40社ほど導入でかかわってきましたが、経験上、ほぼアズイズでの導入が基本としてあります。

その理由として考えられるのは、業務改善や働き方改革の立場から、フレックスタイム制を導入する、就業規則を改定する、子会社と統合する、などの機会を除けば、ユーザー様の担当者としては、できる限り、大多数の従業員がわかりやすく利用できることを目指したい、という気持ちが大きいためかと思われます。(多くの人は大きな変化を好まないため、と言いかえることができると思います)

そうした思いを汲み取って、導入コンサルタント側としては、ヒアリングをしながら信頼を得ていくよう努めることが大切だと考えます。ただし、アズイズを目指そうとしても、システムをリプレースする場合に、どうしてもギャップが出るケースはあります。

パッケージシステムは標準機能のみで運用を実現する方針で導入する関係上、従前のシステム運用などとはユーザービリティが異なる部分が発生し、運用を変化せざるを得ない部分は当然のごとく出ることは少なくないため、新システムの機能で可能なことと、不可能なことは明確にこの段階で認識合わせをしておきます。


これはいわゆるFit&Gapというものですが、Gapが出る部分を、どう運用回避するのか、それとも機能開発案件としてシステム稼働までに実現を目指し管理するのか、システム外での運用をかませる(Excel VBAなどを経由する)のか、など対応を検討しておきます。


こうした課題管理や、要件ヒアリングした内容は、資料エビデンスとして残しておく必要があります。可能であれば、ベンダー側とユーザー側と双方で確認して認識齟齬がないかの確認までを行うことをマストとできると良いと感じます。


システムを扱う人々にとってはあるあるだと思いますが、”思ったように動作しない”、という事態が発生する前に、要件定義の時点で課題を洗い出しておくことで、設定やデータ移行、テスト検証における時間の有効活用が可能になる(要はイレギュラーの発生を防ぎ余裕ができる)ことは大いにあります。


担当者の業務、運用に関する知見をきちんと掘り下げて資料化するプロセスで、きちんとFit&Gapをすれば、その後の進捗コントロールは大抵問題無く進みます。


ちなみに進捗報告の際に、ユーザー様の役職者、プロジェクトマネージャーなどが同席する場合には、報告方法に留意することも大切ですので、要件定義フェーズなどで、関係者の人柄含めリサーチしておくことも必要だと考えます。


すべては安定稼働に向けてぬかりなく、認識齟齬をなくしていく、課題洗い出しと解決方針を固めることが肝要なのです。

 

 

要件定義自体を認識齟齬なく進めるだけではもったいない

ここまでは、いわゆる要件定義がいかに重要かを説くだけになってしまっていますが、実は認識齟齬が無いかの確認のために、資料を残して、ユーザー側とベンダー側の双方でレビューする、ということだけでは非常にもったいない、と感じるポイントがあります。


これは勤怠管理システムに関して特筆すべきことかもしれませんが、数値検証のテストケースを作ることに時間を要することが多いです。テストケースを作る際に、勤務開始時刻と終了時刻をどのように入力すれば、残業時間数がいくら計上されるようになるのか、といった具体例を挙げていくことを行うわけですが、数値検証の結果、正解となるべき値、想定値は、要件が正しく定義されていることが前提となるわけです。


なので、極論をいうと、要件定義フェーズで、数値に関するヒアリング部分では、テストケース例のパターン化を意識しておくと、より後のフェーズ(テストフェーズ)で役立つ資料を仕込んでおくことが可能になる、というメリットが出ます。

そういうわけで、例えば、要件定義書などに、導入システム上では、具体的な勤怠入力例では、残業時間は2時間計上される、また、別の入力方法では、1時間である。さらに、上限が1日3時間であり、退勤時刻はXX時までしかそもそも入力できないよう制御する、など、できる限りテストケースと直接結びつく部分まで落とし込んでおくとベンダー側もユーザー側も非常に楽になります。

 

勤怠管理システムのテスト実施が重要な理由

ところで、勤怠管理システムのテスト、その中でも数値検証がどうして重要かというと、従業員の給与額に直結する部分のためです。

想像してみてください。残業を3時間したはずなのに、1時間も残業が計上されていなければサービス残業どころの話ではなく、自社の従業員からはブラック企業の烙印を押されかねません。人事/総務/労務担当者としては、従業員に遅滞なく正しく給与支払いをできることは厳守する必要があります。

このように、ユーザー担当者様の立場に立つと、要件定義のタイミングで、如何にその後の作業(テストシナリオづくり)が簡単になるか、を見据えて、然るべきタイミングでご案内していくことで深い信頼を獲得することが可能になります。

具体的な”然るべきタイミング”や、要件定義をテストシナリオ作成につなげるための手順や成果物については別途まとめた上で記事にする予定です。

 

 

実践と試行錯誤あるのみ

いろいろと記載しましたが、本当に喜んでもらえるレベルに達するにはまだまだです。
個人的には、ベンダー、ユーザーという立ち位置に縛られず、お互い歩み寄ってシステム導入プロジェクトを成功したいものです。


精進します。

 

 

参考書籍: あなたはまだそんな「仕様書」を書いているんですか?

こちらは、仕様書に限らず、要件定義書や、テストシナリオを作成するときなどにも活かすことができると感じます。他にもノウハウを蓄積して、記事を書いていく予定です。

 

あなたはまだそんな「仕様書」を書いているんですか?

あなたはまだそんな「仕様書」を書いているんですか?

 

 

 

以上。