ラクラス
ニュースレター
キタハラコラム
マイナンバーの
リアル
ラクラスは、人事とITが重なる領域で事業を営んでいます。私自身も「この領域についてはそれなりに詳しい人物らしい」という評価をいただいているようでして、昨今次のような質問を受けることが多くなりました。
「給与計算をAIで自動化できないんですか？」
私のAIについての理解は次の通りです。
この理解が正しければ、AIで給与計算を自動化するためには、まず「給与計算にかかる様々なインプットとアウトプットの正しい組み合わせ」をAIに入力しなければなりません。するとAIは、自ら学習して、給与計算のロジックを見つけ出していきます。学習が深まるにつれて正しいアウトプットが出る割合は上がっていきます。そしていつの日か100％正解に達します。
「これでAIによる給与計算の自動化は完成だ！」と言いたいところですが、これはまあ冗談です。給与計算のロジックは明確に決まっています。ディープラーニングを用いてわざわざAIにロジックを探し出させる必要はないのです。
ラクラスは、AIとはまったく異なるテクノロジーを用いて、「１ヶ月にわたる給与計算業務の自動化」に成功しました。今回のキタハラコラムは、給与計算の自動化がテーマです（※1）。
※1：「給与計算 自動化」をキーワードにして検索した結果とは、次元が異なるレベルの自動化であることを宣告しておきます。
私のキャリアは、日米両国での人事とITの経験です。しかしながら、給与計算の実務を担当した経験はありません（※2）。ですので、「給与計算の専門性」という言葉を聞いても、それが何を意味するのかわかっていませんでした。
しかし、ラクラスが成長しお客様が増えてきますと、給与計算の専門性とは何かを考えざるを得なくなります。「給与計算の専門家をどれだけ多く雇えるかが当社の成長の上限になる」といった状況は、経営者として許容できません。そこで、「給与計算の専門性とはなにか？」という長年の疑問の解決に、真剣に取り組むことにしました。
給与計算に関する当初の私の認識は次の通りです。
しかし、インプットが多岐にわたろうが、計算処理に法律が絡んでいようが、計算式は決まっています。人によって判断が変わったりするわけでもありません。専門性の有無でアウトプットが変わるはずもなく、「正しいデータさえ入力すれば給与計算は完了するんじゃないの」というのが私の認識でした。
「いったいどこに専門性があるのだろう」と訝りながらさらに議論を進めていくと登場してくるのが、「例外が多いんです」という担当者の発言です。給与計算には、「例外まで含めて処理できること」が求められており、そこに専門性が求められる、と言うのです。
そこで「例外とは何か」を明確にすることにしました。その結果、例外は何種類かに分類できることがわかりました。
対象者を特定するのに、複数のデータベースを検索する必要があるとき、手作業が発生します。複数のデータベースの検索結果をエクセルにコピーして、関数を使って対象者を確定する、といった手作業が行われていました。
類似の作業として、計算処理に必要なデータが複数のデータベースに分散しているため、手作業でこれを探すというケースもありました（※3）。
例えば、「ある顧問への報酬の支払い方法はちょっと特別」といったケースは、手作業で処理されていました。対象者がごく少数のときには、給与システムにパラメータを設定するよりも、手作業の方が効率的という判断でした。
どれだけ多くの経験を積み重ねても、初の出来事というものが存在することは否定できません。
こうした議論を進めていく中で、「給与計算業務のエッセンスは何か？」が見えてきました。
※2：給与計算の経験はありませんが、年末調整の保険料控除証明書の確認作業の経験はあります。2016年までの毎年、社長である私も含めて全員が「年調チェック」に駆り出されていました。こりゃいかんということで「年末調整支援システム：HIIRAGI」の開発に取り組みました。その結果、2017年の年末調整に私は動員されませんでした。社員の残業もずいぶん減りました。
※3：例えば、給与システムで営業日に基づく日割計算をするとき、就業システムに営業日カレンダーを見に行かなければなりませんでした。
議論の中から私たちが発見したのは、「給与計算とは、特定の対象者の、特定の項目に、特定の値を入力する作業の繰り返しである」というエッセンスです。
具体例を挙げて説明しましょう。例えば、役職手当の更新作業です。
まず、人事データベースの中から役職コードが、「前月は空欄」かつ「当月は課長」の社員を検索します。これが「特定の対象者」です。この対象者の役職手当という項目に、役職手当テーブルに定められている50,000円という値を入力します。役職手当という項目が「特定の項目」であり、50,000円という値が「特定の値」です。
家族手当であれ通勤手当であれ、処理の手順は同じです。検索条件が異なり、参照するテーブルが異なり、入力する項目や入力する値が異なります。しかし、「特定の対象者の、特定の項目に、特定の値を入力する作業」であることに違いはありません。給与計算とは、すべての支給・控除項目に対してこの作業を繰り返すことなのです。
まったく性格が異なるように見える「タイムカードの未提出者に督促メールを送る」という作業も同じです。検索されたタイムカードの未提出者が特定の対象者、督促メール送出フラッグという項目が特定の項目、1という値が特定の値です。システムは、未提出者を検索して、督促メール送出フラッグに1を入力し、１と入力された対象者に督促メールを送ります。枝葉は違っても、エッセンスは同じです。
「ある顧問への報酬の支払い方法はちょっと特別」という例外も、このエッセンスで説明できます。対象者を検索する条件が、顧問の社員番号になるだけのことです。社員番号で検索した対象者のある項目にある値を入れるだけのことです。
ここで改めて給与計算のエッセンスをまとめておきましょう。
「給与計算とは、継続して勤務している社員において（※４）、定められた条件で検索された社員の、定められた入力項目に、定められた値を入力する作業の繰り返しである」。
こうして給与計算自動化への道が見えてきました。
※4：入社・退社・休職・復職に関してはやや別の流れが発生しますので、あえて「継続して勤務している社員」という限定を設けました。ラクラスの人事クラウドは、別の流れである入社・退社・休職・復職も自動化します。
仕事にPCが使われるようになって四半世紀が経過しました。
企業においてPCを操作する手順は作業マニュアルに定められています。社員は、作業マニュアルの記述を読み解き、PCに指示を与えます。PCは指示の通りに処理を行い、結果をディスプレイに表示して動作を停止します。再び社員は作業マニュアルを読み解き、次の指示をPCに与えます。
この手順を給与計算に置き換えてみましょう。PCを用いて給与計算を行う手順は作業マニュアルに定められています。給与担当者は、作業マニュアルを読み解き、対象者を検索する条件式をPCに入力します。PCは検索結果をディスプレイに表示して動作を停止します。
再び給与担当者は作業マニュアルを読み解き、表示された社員の特定の支給・控除項目に、規程で定められた値を入力します。給与担当者は、すべての支給・控除項目について、同じ手順を繰り返します。すべての入力項目に値が入力されれば、あとは給与システムが支給額・税・社会保険等を計算するバッチ処理を行います。
私たちはPCを仕事に活用していると思っています。しかし、ここまで説明した通り、仕事を進める主体はあくまでも人間です。PCは人間の指示に従って、その場その場で動いては止まっているだけです。このような仕事の進め方を、「人間が作業動線を管理する方法」と呼ぶことにします。
ラクラスは、人間に代わってシステムに作業動線を管理させることはできないかと考えました。システムが作業動線に従って、人間の指示を待たずに作業を完了できるのであれば、それが給与計算の自動化です。
そして研究を進めた結果、次の２つの機能要件を満たせば、例外処理まで含めた自動化が可能なことがわかりました。
前述した例外処理とこの2条件は密接に関連しています。給与計算に必要なすべてのデータをそのシステムがもっていれば、対象者を検索するための手作業は不要になります。作業動線をそのシステムに設定する方法が容易であれば、システムを設定するよりも手作業の方が早いといった悩みはなくなります。
ラクラスが開発したフレームワーク「SQN」は、就業・給与・福利厚生にかかるあらゆる情報を一つのデータベースに集約し、１ヶ月間にわたる給与計算の作業動線を記憶し自動実行する人事クラウドを実現しました。作業動線の設定にプログラムコーディングは必要ありません。テクノロジーによる生産性の向上こそ、人口減少社会にむけたラクラスの回答です。
前述のように、これまでは人間がPCを操作することで、業務処理を実行していました。PCが働いているように見えますが、全体の作業動線を管理しているのは人間です。
SQNフレームワークで開発されたラクラス人事クラウドサービスは、１ヶ月にわたる給与計算の作業動線を記憶し、自動実行します。人事クラウドは、その作業を開始するスケジュールになると、定められた条件で検索された社員の、定められた入力項目に、定められた値を入力し、その結果を画面に表示します。人間の役割は、人事クラウドが実行した結果を確認することに変わります。
スケジュールとして機能するのは、日時だけではありません。前の複数の作業がすべて完了したら自動的に開始する、あるいは外部から取り込むべきファイルがフォルダに投入されたら自動的に開始する、といったトリガーも準備されています。
自動実行できる作業も、「検索と値入力」だけではありません。あらゆる条件式や計算式を設定できることはもちろん、メールサーバの操作、CSV / Excel / JSONによる入出力、PDFの生成、あるいは他システムとデータ連携する機能ももっています。
ラクラス人事クラウドサービスの「就業・給与・福利厚生」機能を次に紹介しておきます。
| 就業・給与・福利厚生にかかる機能 | |
|---|---|
| 就業管理 | ・あらゆる就業形態に対応する多様な打刻方法 ・多様な休暇や休日への対応 ・あらゆる就業形態に対応する勤怠集計 ・リアルタイムな勤怠集計とマネジメント ・シフトの作成とインポート ・未提出者・未承認者督促 ・入退場データとの比較 ・36協定等、労働時間管理 ・プロジェクト別従事時間登録 |
| 給与・賞与計算 | ・あらゆる給与形態へ対応 ・給与・賞与計算 ・通勤経路管理、通勤費計算 ・各種手当計算 ・社会保険・労働保険料計算 ・各種掛金・会社負担金の計算 ・給与明細・源泉徴収票 ・年末調整計算 ・グロスアップ計算 ・出国時年末調整計算 |
| 退職金計算 | ・退職金ポイント計算 ・確定拠出型年金 ・退職金支給額シミュレーション ・確定給付型年金 ・キャッシュバランス型年金 |
| 社会保険 | ・社会保険、労働保険管理 ・電子申請、e-Gov連携 ・手続き進捗管理 ・社会保険料管理 ・各種給付管理 |
| ポストペイロールレポート | ・財務連携仕訳レポート ・総額人件費変動レポート ・プロジェクト別人件費原価レポート ・給与改定・賞与通知書 ・社会保険料改定通知書 |
| 福利厚生 | ・財形、団体保険 ・持株会、共済会 ・福利厚生ポイント、カフェテリアプラン ・社宅、社有車管理 ・給与控除金管理 ・貸付金管理 |
ラクラス人事クラウドサービスは、１ヶ月にわたる給与計算の作業動線を記憶し、自動実行します。賞与計算、年末調整、残業時間管理、マイナンバーの利用、社会保険手続きといった就業・給与・福利厚生業務だけではなく、人事評価票の配布・回収、昇給賞与の予実管理、労務レポートの出力など、自動化できる業務に制約はありません。
ここでは、人事クラウドが自動化を実現するための2つの条件を満たしていることを説明しておきます。第１に自動化に必要なデータは、そのシステムで検索可能であること、そして第２にそのシステムに作業動線を設定する方法が、容易で柔軟であることです。
第1の条件を満たすために、人事クラウドは従業員の身上情報（家族申請・住居申請等）、従業員の就業情報（打刻・勤怠申請等）、企業の発令情報（報酬・役職・組織等）、行政からの情報（税・社会保険等）、および過去の給与支払情報等といった給与計算に必要な情報を、すべて統合人事データベースに蓄積して検索可能にしています（※7）。
次の図は、従来のシステムおよび人事クラウドにおいて、これらの情報がどのように流れるのかを示しています。
従来の人事情報システムにおいて、身上・就業・発令・行政・給与支払歴といった情報は、「ワークフロー」、「就業管理」、「給与計算」、「人事データベース」という4つの機能の中を流れ、人事データベースと給与計算のデータベースの2つに分散して保管されていました（※8）。そのため、複数のデータベースの検索結果を重ね合わせるための手作業が発生していました。
ラクラス人事クラウドサービスは、すべてのデータを一つの統合人事データベースに集約します。すべてのデータを検索条件として利用できますし、すべてのデータを出力できます。コンピュータが動線を管理するための一つ目の条件はこれで整いました。
※7：給与計算に必要な情報だけではなく、人材管理（タレントマネジメント）に必要な情報もすべて統合人事データベースに統合され検索可能になっています。キタハラコラム「タレマネ日米比較」をご覧ください。
※8：人事データベースにも給与計算のデータベースにも引き継がれず、したがって保管されないデータもあります。例えば、毎日の打刻データは就業管理のデータベースに残ったままですし、ワークフローの承認記録はワークフローのデータベースを見に行かなければなりません。
2つ目の条件は、「作業動線を設定する方法が、容易で柔軟であること」です。
SQNは、プログラムコーディングなしに、作業動線を設定できます。たとえその作業動線が１ヶ月の長きにわたるものであろうと、SQNの設定にプログラムコーディングは必要ありません。
コーディングの代わりになるのが、アクティビティ図（※9）と呼ばれる形式で記述されたフローチャートです。アクティビティ図には、SQNに対する指示（ルールと呼びます（※10））と、その指示を実行する順番（フローと呼びます）が記述されています。SQNは、アクティビティ図に定義されたタイミングで、定義された順番に、定義された指示を実行していきます。
下図は、給与計算の作業動線を表したアクティビティ図の一部です。ラクラスは、基本となるアクティビティ図を用意しています。ラクラスのコンサルタントは、お客様の要求を実現するように、アクティビティ図を修正していきます。
【アクティビティ図のサンプル】
アクティビティ図の利点は、それが人間にとって理解しやすいことです。アクティビティ図に記載されたルールは、一定の範囲までお客様が変更可能です。たとえば、検索条件の追加や変更、あるいは値の変更といったルールは、お客様が変更することができます。
※9：アクティビティ図は、業務プロセスの流れを定義するフローチャートです。ラクラスは、国際標準である統一モデリング言語（Unified Modeling Language：UML）を独自に拡張し、人間が理解しやすい視覚的な表現で業務プロセスを定義できるようにしました。
※10：ルールは、ルールセットとしてアクティビティ図から切り出して管理することができます。ルールセットはアクティビティ図に記載された一つひとつのタスクに付随して実行されるスクリプトです。業務の全体像を表すアクティビティ図の中に存在する細かいロジックをルールセットで表現することで、運用中のロジックの差し替えが容易になりました。
ここで、SQNとRPAとの違いを説明しておきましょう。
RPAができることは、画面の操作です。ソフトウェアに備わっている画面に表示される値を取り出したり、入力フィールドに値を入力したり、操作ボタンをクリックすることができます。エクセルのマクロのように、人間が行なった操作を記憶することもできます。マクロとの違いは、そのソフトの中だけで閉じていないことです。RPAは複数のソフトの画面を操作し、相互のデータを連携することができます。
しかし理解しておかなければなければならないのは、RPAが操作できるのはソフトウェアに備わっている画面だけだということです。RPAは、そのソフトウェアのその画面ができる以上のことはできません。
一方、SQNができることは、データベースを操作することです。あらゆる情報処理は、「データベース」、データベースの操作を定めた「ルール」、そしてルールの順番を定めた「フロー」で定義されます。SQNは、アクティビティ図とルールセットにフローとルールを定義することで、データベースに対するあらゆる操作を行うことができます。ワークフローの画面に表示する項目や承認経路を設定する、打刻データを用いて勤務時間を集計する、支給・控除の各項目を算出する、給与計算する、給与明細を社員に配布する、残業時間推移を部門別に集計する等々、あらゆる操作をアクティビティ図とルールセットで定義できます。
RPAは画面操作を代替します。SQNが代替するのはプログラミングそのものです。
2013年にオックスフォード大学から発表された「雇用の未来：コンピュータ化によって仕事は失われるのか」という報告書は、給与・福利厚生業務を「消える職業」に選んでいます。国立情報学研究所新井紀子教授は、「現在のホワイトカラーの仕事の半分がAIに置き換えられる」と予想しています。
最後に、SQNが実現する未来について、私の考えを述べておきます。
SQNフレームワークにより開発されたラクラス人事クラウドサービスは、給与計算を自動化します。人事クラウドは、アクティビティ図で定義された作業動線を、例外処理も含めて、毎月忠実に繰り返します。「作業マニュアルに書かれた通りにPCを操作して、毎月の給与計算を正確に実行する」という作業者は、人事クラウドに置き換えられるでしょう。
しかし、これをもって人間がコンピュータに置き換えられると考えるのは早計に過ぎます。
なぜなら、人事クラウドに作業動線を設定する作業は、今後とも人間の作業として残るからです。いかに設定にプログラミングが必要なかろうと、理想とする作業動線を構想し、これを人事クラウドを稼働させる要件に落とし込めるのは人間だけだからです。人事クラウドの処理結果の正否を判断し、これを正しく修正するのも人間の役割です。
私は、法律、あるいは企業ごとに異なる制度や規程から出てくる「要求」を、コンピュータが理解できる「要件」に落とし込む作業は、人間が担うべき仕事として今後とも残ると考えています。いやむしろ、「要求を要件に落とし込む仕事」こそを人間が担うべきであり、ここに専門性と呼ぶべき価値があると考えています。
毎月の繰り返し作業に加えて、SQNが置き換えるもう一つの作業は、プログラミングです。プログラミングとは、人間の言語をコンピュータ言語に翻訳する作業です。これまで翻訳には専門知識が必要とされていました。
しかしSQNにプログラミングは必要ありません。SQNは、人間が容易に理解できるアクティビティ図とルールセットで情報処理を開始します。SQNは自動翻訳機であるという見方もできますし、さらに言えば、「SQNにおいて、アクティビティ図は新しいコンピュータ言語だ」という言い方もできます。
繰り返しになりますが、プログラマは不要となっても、「要求を要件に落とし込む仕事」はなくなりません。プログラミングという下流工程はなくなりますが、アーキテクチャ設計を含む上流工程は人間の仕事です。
人間が人間にしかできない仕事に集中できるようにすること。
これがラクラスの考える人口減少社会への対応です。
