Excel→Access→Pythonと紆余曲折、Excelへと回帰した業務改善の道

人事労務において勤怠計算や給与計算をしていると、csvファイルをインポート・エクスポートすることが良くあります。API連携でボタンポチーもだいぶ導入されてきましたが、まだまだcsvが主流なのではないかと思います。

csvファイルを別のシステムでインポートしようとすると事前にファイルの整形作業が必要な時があります。列名を変更したり不要な列を削除したり、集計して新規の列を追加したり。（行は基本変わらないので列操作ばかりですが）

Excel作業の限界

エクスポートしたcsvファイルのデータをAシートに貼り、その内容をBシートにリンク・計算してBシートのデータをインポート用のcsvとして保存する、なんてことをすると、行やセルの扱いで困ることがあります。

AシートよりBシートの方が多かった（0で出力される）
BシートよりAシートの方が多かった（必要な人が出力されない）
Bシートの数式が1行ずれていた
前回の手修正を元に戻し忘れていた

最初は余計なデータを削除すればよいですが、2つ目以降は最初からやり直しです。すでにリンクや関数を埋め込んだシートであってもちょっとした操作で大きな影響が出てきます。毎回Aシートへコピーをするたびに人数に合わせてBシートへ関数やリンクを人数分追加削除する必要が出てきます。また、Aシートの方を削除しちゃうとBシートのリンクも影響を受けます。ここで間違えたらと思うと…

特にExcelは行や列ではなく「セル」単位なので、行がずれてようが列がずれてようが合っているか間違っているかを判断するのは人になります。

ここが難しい。

それならAccessクエリ

次に考えたのがAccessのクエリを使う方法。Accessを知ってたらとても楽な方法です。csvをインポートしてクエリをエクスポートすれば完成です。作業はこれだけです。なんならボタンひとつでエクスポートまでしちゃうもんね。

しかし大きな欠点がありました。会社で導入しているOfficeにはAccessのライセンスがないのと利用経験者がほぼいないこと。

ライセンスの購入費用はそこまで高くはないものの、利用経験者がいないということは、導入までに使い方をレクチャーする必要があるということ、その後のメンテナンスが各自でできないということがやはりネックでした。

また「一つのテーブル内で同じフィールド名が使えない」というのもネックでした。エクスポートされるcsvファイルには同じ列名の項目があったりするのです。そうするとAccessへ取り込む前に名前問題の解決が必要で、その手間やメンテナンスは自分がやらないといけないんだろうなと考えるとなかなか手離れしなさそうなので不向きであるという結論になりました。

バッチ処理ならPython（Google Colaboratry）

そこで、エンジニアの家族に相談。「そんなのバッチ処理で一発やろ？」そうですよね、本職に聞いたらそうなるのは大体想像ついてました。非エンジニアの葛藤が一言で終わってしまいました。

たしかに、ツールを新しく覚えて悪戦苦闘するよりはスクリプト（プログラム）書くのが結果的に早くて確実だと思うんです。ツールの設定に惑わされることがないのでやりやすい。（Accessだと文字列型なのか通貨型なのか決めておかないといけなかったりで投入したものをそのまま出すには技が必要）

てことで、Let'sプログラミングですが、Accessを超える（めんどくさい）実行環境の構築が大前提となります（そしてそこで挫折する人多数）。しかし、会社でGoogle Workspaceを導入しているため、Google Apps ScriptかGoogle Colaboratryが環境構築不要で利用することができます。そこでGoogle Colaboratryを利用してスクリプトを書くことにしました。

すごいですね、巷でこれからはPythonだって言ってるだけあって入りやすいし、ライブラリも豊富だしとっつきやすいです。データ分析で使われるだけあってcsvいじるのも瞬殺です。

てことで、これもcsvを取り込んだら整形したファイルを出力してくれるプログラムを作りました。

これも誰がメンテするのか？とかまたレクチャーしないといけないのか？という問題が出てきます。Accessよりは修正箇所がはっきりしているので実はわかりやすく「この時はここをこういう形に変更してください」という指示で何とかなりそうなんですが、大事なことに気が付きました。

csvの項目は頻繁に変わるものではないですが、最近だと交通費の精算方法が変わったり、手当を追加したり廃止したりなどの変更が発生していて、

・変更前提の仕組みであること
・かつ、だれでもそれに対応できる

というのが何よりも優先されるのではないかという気がしてきました。

変な話、私が長期不在で誰かが変更して作業しないといけない状況になってしまった場合、結局のところバッチは利用せずExcelで作業して…ということになります。

もしかしたら「ボタンポチーで時間短縮だぜ！」ってのも部分最適でしかない単なる自己満足なのかもしれない、全体最適はやはりExcelなのではないかと思い始めるようになりました。

で、結局確実なExcelに戻る

で、Excelの作業を見直してみました。ミスしそうなポイントは数あれど、実際にミスしたことは非常に少ないというか、ほぼなくて。作業手順や過程が誰でもわかるので不在があっても対応可能です。

逆にAccessやPythonは過程がブラックボックス化され、途中で変更が必要な場合に初見だと中身を追いかけるのに時間がかかってしまい、かえってミスを誘発しかねない状態になりそうと判断しました。

見直して元に戻るという決断も業務改善

マクロやRPAのように自動化されることで30分かかる作業が一瞬で終わることは喜ばしいことです。

今回においては、「誰でも実行できてかつ誰でも修正できる」という点が業務遂行の条件として一番大きく、その点においてはExcelが最適解であると判断しました。

特にバックオフィスと呼ばれる管理部門は、作業時間＝コスト削減が常に叫ばれています。人事労務領域におけるオペレーションは特に「期日まで、期日通りに正確に行う」ことが常に求められています。

とはいえ、その中身は毎月細かい変動があり、ルーティンと言えどもルーティンではないのが実情です。（アウトプットが同じなので単純作業と思ってしまう人が非常に多いのが悩ましいところです。）それらをひとつずつ正確に行うためにはオペレーションを担当する全員のスキルレベルを均等に底上げしていく育成と、初めての人でも同じオペレーションができる仕組み作りが必要です。

世の中には便利なツールが色々ありますが、へーしゃにおいては利用するツールをExcelへ集約させて、スキルの均一化と向上を図ることが最善であろうという選択をしました。

将来誰かが「Excelなんてミスったら終わりですよー」と過去の自分が言ったことと同じことを言ってきたとしても、「これこれこういう理由やら経緯があって今はExcelでやっているのさ」と言えれば、そこから新しい議論が始まり今回よりも一歩二歩進んだ業務改善が行われるのではないかと期待しています。