【通算124｜要求AI 41】このままでは、給与計算が支給日に間に合わなくなる

2026年8月27日 21:05

122と123で、人事の話を書いた。県庁職員と県立高校で、それぞれ1万人。

書いてみて分かったが、どちらも、大きな問題の出てこない話になっている。

人事側には、切迫した課題が無かったからだ。旧システムでも、やれていた。 旧システムでできていたことが新システムでできればよい——人事側のスタンスは、そこにあった。人事は給与へデータを渡す立場で、日付に追われていたのは、給与のほうだった。

給与は、そうはいかなかった。

(1)｜このままでは、給与計算が支給日に間に合わなくなる

この案件が始まった理由は、はっきりしていた。

旧システムのままでは、毎月25日の給与支給に間に合わなくなる。

念のために書いておくと、実際に遅れたことは一度も無い。 毎月きちんと支給されていた。このまま行けば、いずれ処理が終わらなくなる——そういう見通しの話だった。

なぜ処理が重くなっていくのか。

勤怠に関わる法律が、年々複雑になっていくことだった。

休暇の種類が増える。時間外の扱いが細かくなる。そのたびに、判定しなければならない条件が増える。 制度が積み上がるほど、計算の前にやることが増えていく。

困ってから直すのでは間に合わない。

旧システムはA社のメインフレームで動いていた。それをUNIXのサーバーと、県内500台のパソコンをつないだ形へ移す。当時としては、かなり思い切った判断だったと思う。

(2)｜6万人分の給与処理を、1つのシステムで行う

121で出した図を、もう一度、確認する。

対象は6万人。県庁職員が1万人。県立高校の教職員が1万人。市町村立学校の教職員が4万人。

人事のほうは、制度が違うので分かれる。県庁職員と県立高校では、採用の入口から別の制度になっている。

給与は逆だった。

給与テーブルに基づく計算そのものは、民間の給与計算と基本的に変わらない。 等級と号俸があって、手当があって、控除がある。だから6万人ぶんを、1つのシステムで扱える。

計算そのものは、単純なのだ。問題は、その周りにあった。

まず、制度が多い。 6万人の中に、県庁職員がいて、教職員がいて、身分が市町村にある人もいる。手当も、休暇の扱いも、それぞれの制度に従う。

(3)｜提案依頼書の100万ステップが、始まってから140万になった

規模の話を、先に書いておく。

提案依頼書に書かれていた旧システムの規模は、100万ステップだった。 こちらは、その数字を前提に体制と期間を組んでいる。

プロジェクトが始まってしばらくして、県庁のシステム担当の方から言われた。「調査で40万ステップ漏れていました」

4割増える。体制も期間も、100万を前提に組んでいた。

ただ、あとから考えると、責められる話でもない。旧システムは長い年月をかけて機能が積み上がっていて、全体を理解している人がいなかった。 提案依頼書を書く段階で数え切るのは、無理だったのだと思う。

そして「全体を理解している人がいない」というのは、この案件のあいだ、ずっと続く条件になった。

(4)｜サンプル帳票を見せてくださいと言ったら、2000種類出てきた

要件定義の入口で、いつもやることがある。いま使っている帳票を見せてもらう。

出てきたのが、2000種類だった。

どうしようもないので、部屋を1つ借りて、3日こもった。 ひたすら並べて、眺めて、仕分けていく。

3日かけて分かったのは、大きく2つに分かれるということだった。

直接、人事給与に関わるもの   給与明細、辞令、支給の内訳 など
統計として出すもの           水準や人数の集計、比較の資料 など

そして、後者のほうが圧倒的に多かった。

(5)｜8割は、統計資料だった

その140万ステップの内訳が、こうだった。

直接、人事給与に関わる機能は約30万ステップ。 残りの110万ステップ、つまり8割近くが、統計を作るための機能だった。

最初にこれを知ったときは、正直なところ驚いた。人事給与システムなのに、8割が統計なのか、と。

公務員の給与は税金から出ている。だからその水準が妥当であることを、外部に開示する義務がある。

国家公務員を100としたときに、その自治体の水準がどうなっているかを示す指数がある。ラスパイレス指数と呼ばれるものだ。これで都道府県のあいだの横並びが見える。 、別途、民間の給与水準と比べるための仕組みもある。

どちらも、資料を作って公開する。

つまり、8割の統計資料は、 説明する義務があるから、制度の一部なのだ。

そしてもう1つ、やっかいな縛りがあった。

旧システムで出していた統計資料は、新しいシステムでも必ず同じものを出さなければならない。 過去と比べられなくなるからだ。1つも減らせない。

(6)｜統計処理は、旧システムのCOBOLの流用を検討した

新しいシステムで110万ステップ分を書き直していたら、それだけで3年が終わる。

同じものが出るなら、動いているものを使えばいい。

この検討で、統計にかける時間をかなり減らせると判断した。

どこを作らないかを決めるのも、要件定義の仕事だと思っている。

(7)｜教職員5万人分の給与処理要件を誰も知らない

ここからが、この案件でいちばん苦労したところになる。

6万人のうち、県立高校と市町村立学校の教職員が、合わせて5万人。 全体の8割を超える。

この教職員5万人分の給与を、どう計算しているのか。

パソコン側で何をどこまでやらせるのか。どういう単位で処理を分けるのか。それを決めるには、いまどうやっているかを知る必要がある。

聞く相手が、見つからなかった。

給与を担当されているグループの方に聞く。手続きのことは分かる。 だが、教職員の勤務の実態まで踏み込むと、そこは担当が違う、という話になる。

121で書いたとおり、県庁は縦割りだ。自分の担当の外のことは答えないという役割分担になっている。

県庁の中を、どれだけ探しても見つからなかった。

122と123で、人事については早い段階で詳しい方にたどり着けたと書いた。給与は、そこがまるで違った。

(8)｜いちばん詳しかったのは、教育事務所の方だった

行き着いたのは、県庁の外だった。

教職員に関わる給与の実務に、いちばん詳しかったのは、教育事務所の方だった。

福岡県には、教育事務所という出先の機関が置かれている。当時は県内に6か所あったと記憶している。学校の現場に近いところで、教職員に関わる実務を扱っている。

そこに、いちばん詳しい方がおられた。

教職員がどういう勤務をしていて、休暇や時間外がどう記録され、それがどう給与に反映されるのか。その全体像を知っているのは、県庁ではなく、この方だった。

だから勤怠データの入力画面の仕様は、最終的にこの方と詰めていった。

県庁の中を、いくら探しても、いなかった。

これは、要件定義のやり方として学んだところだった。組織図に載っている範囲だけを見ていると、そこに答えがあると思ってしまう。 実際には、実務を握っている人は、出先にいることがある。

(9)｜いちばん複雑だったのは、勤怠管理だった

そして、詰めていくうちに分かったことがある。

給与計算の中で、いちばん複雑な処理は勤怠管理だった。

誰が、いつ、どれだけ働いたのか。休暇はいつ取ったのか。時間外勤務は何時間あるのか。この記録が確定しないと、給与計算が始められない。

給与支給が遅れる原因は、給与計算そのものではなく、勤怠データが揃うのに時間がかかることだった。

このことが分かったのは、かなり後になってからだった。「25日に間に合わなくなる」という話を聞いた時点では、給与計算の速さの問題だと思っていた。 実際には、勤怠データが揃うのが遅いという問題だったのだ。

だとすると、対策が変わる。

現場で日々、勤怠データを入れてもらえるようにするほうが効果的だ。

そして、ここが見えた時点で、課題は1つになった。

勤怠データが揃うようにする。それさえ解決すれば、残りは「あったらいいな」の話だった。要件定義で挙がっていた項目は他にもいくつもあったが、何を先にやるかは、決まった。

だが、そこで別の壁にぶつかった。県内500か所をネットワークでつなぐと、通信の費用がとんでもないことになる。

機能の話が、ネットワークの話に変わった。

そこは、121で予告した4本目——インフラの回で書く。

要件定義とExcel業務の自動化を、ココナラでお請けしています。
ta_kawano｜ココナラ