元エンジニア的労務の品質管理の捉え方

こんにちは。ゲーミング社労士のT-GOです。

台風、近づいてきていますね。少しずつ勢力は弱まっているようですが、いかんせん速度が遅く、長時間雨風の影響を受けそうです。まだどれくらいの影響を受けるかわからないですが、くれぐれも気をつけたいところです。

ラジオに出演してきました

現職でも労務管理の一環として利用しているSmartHR。
SmartHRには利用者によるオンラインコミュニティが形成されていて、先日コミュニティ企画の一つである「ラジオ」に出演してきました。

内容はコミュニティ参加者しか聴くことができないので、公にすることはできないのですが、もし「あ、実は私参加してますわ。」っていう人は、よろしければお聞きください。

ちなみにテーマは「キャリア」について。
元エンジニアである私が、なぜ人事労務のキャリアを選ぶようになったのか、これからのキャリアは？みたいなことをお話しています。

システム的に品質管理してみる

ラジオの中で「元エンジニアとしての経験が労務に生かされたことはあるか？」という質問を頂きました。

私自身、労務とエンジニアリングは結構似ているところがあると以前から言っていて、業務においても参考になる部分はとても多いと思っています。

私自身特に参考になったのが「品質管理」

実は今日、メンバーと一緒にある成果物のチェックをしていたんですが、そこで成果物のエラーを検出して修正を行うという事案が発生しました。

ちょっとこの事案を通じ「こういう品質管理の考え方もあるよ」ということを書き記しておこうかと思い、筆を取ってみました。

労務の品質管理に悩む方は、よろしければ参考にしてみてください。

エラーを「正常系」と「異常系」に分類する

ここで「あぁ、なるほどね。」と勘づいた方はさすがです。労務適性アリアリなので、ぜひ労務をやりましょう（笑）

「正常系テスト」と「異常系テスト」とは何か？

システム開発のテスト手法の一つに「正常系テスト」と「異常系テスト」というものがあります。

正常系テストは、有効な入力データに対してシステムを検証するテストプロセスです。
正常系テストの主な目的は、ソフトウェア・アプリケーションが想定したとおりに動作するかどうかをチェックすることです。

---

異常系テストは、一般にエラーパステストや障害テストと呼ばれ、アプリケーションの安定性を確保するために行われます。
異常系テストの主な目的は、様々な不正確な検証データセットの影響に対するソフトウェア・アプリケーションの安定性を確認することです。

https://blog.shiftasia.com/difference-between-normal-and-abnormal-test/

めちゃくちゃ端的に読み替えると、
　正常系テストは「想定通りに動くかどうか」
　異常系テストは「想定外の動きをしていないか」
ということでしょうか。

労務の業務は、結構この考え方に基づいてテストして、役に立つ場面があります。

例えば「新入社員の給与の支払い手続」を考えてみましょう。

給与の支払い手続をするためには、まず新入社員そのものの情報をシステムに入力（外注している場合は外注先に連絡）します。

そして実際に給与計算を実施します。

正常系としてどのようにチェックする？

給与計算結果は何らかの形で確認するわけですが、ここで入力した内容に基づいて正しく計算されているかを確認します。

この方の月額給与は30万円です。
支払金額として「30万円」が出力されていますか？保険料や所得税は正しく計算されていますか？

これら「そらそうなるよね。想定通りだよね。」ということを確認するのが、正常系としてチェックする項目です。

異常系としてどのようにチェックする？

異常系は、少しシステム的な品質管理とは違うのですが、こんな風に考えてみましょう。

実はこの新入社員には、扶養する配偶者がいたんですね。
なんと給与システムへの入力が忘れていた（外注先への連絡が漏れていた）ことがわかりました。

そうすると、扶養者の登録有無によって給与計算結果が変わってしまいます。

はい、ここではこういった情報の未入力を異常系として捉えます。

正常系／異常系に分けることで、チェックの捉え方を変える

先ほどの例を考えたときに、どちらが「ヤバい」エラーだと思いましたか？

もちろん「異常系」ですよね。

こういったエラーは全て検出するにこしたことは無いのですが、どれもこれも同じ粒度でエラーの検出や対応を行うことはあまり良くないものと考えています。

というのも、品質管理は突き詰めると非常に膨大で、どれもこれも同じように対応すると費用対効果が著しく悪くなります。

そこで「これは最後のチェックの段階で検出できれば良いエラー（ここでいう正常系）」、「これは最初の段階で防いでおかないといけないエラー（ここでいう異常系）」という風にエラーを分類することで、品質管理の取り組み方、手法、意識を変えることに繋げることができます。

これの良いところって「セルフチェック能力」が鍛えられることだと思っています。「これだけは絶対に避けないといけないエラー」みたいなものを、個人の段階で防ぐことができ、全体的にプロジェクトの品質管理の精度が向上します。

異常系のエラーって「いや、それもうちょっと早く気づかへんの？」的なものが多いので、全体としての工数削減にもつながることが多いです。

もちろん、業務ごとに品質基準は異なりますが、こういった考え方自体をチーム内で共有できると、「あいつまたミスしやがって・・・」的な不毛な争いも防ぐことにもつながるので、ぜひお勧めしたいところです。

---

ちょっとしたノウハウ的な記事なので、初めて有料設定をしてみたり。

でも記事は「全文公開」しています！

「参考になったよ！」という方、もしよろしければおひねりくださいm(_ _)m