業務効率化のためのシステム導入－楽々精算（前編）

赤字企業から黒字企業への方法は、費用面からアプローチをすると、

・無駄・不要な費用を削る

・無駄・不要な業務を廃止する

・業務を効率化する

の3種類しかありません。その中で一番わかりづらく・成果も確認しづらい一番最後の「業務を効率化する」について説明したいと思います。業務の効率化を実現するためには、大部分のケースにおいて「システムを導入し、既存の業務のやり方を変える」という方法で実現します。

社長さんの中には「システムの導入ってお金がかかるんじゃないの？社内業務に無駄なお金を使いたくないんだけど」と、社内導入には否定的な方もいらっしゃると思います。ただ、これは、業務の効率化という観点で、かなり勿体ないです。便利な社内システムを導入しないことにより、無駄に人手がかかる状態を温存して非効率な業務体制を放置することにつながるからです。

どういった状態が「非効率」というのは、実際に日常業務がどのように行われているかを見ていかないと判断ができないですが、簡単な目安として

・従業員間コミュニケーション　：　メール・電話のみで、SlackやChatworkなどを導入していない

・ドキュメント作成　　　　　　：　MicrosoftOffice（エクセル・ワード・パワポ・アクセス）以外のツールは導入していない

・経費処理　　　　　　　　　　：　エクセルやアクセスなどを駆使して行っており、クラウドソフトなどは利用していない

などを基準にするとよいでしょう。これに1つでも当てはまるものがあれば、業務効率化の面で「非効率」が存在すると思ってもらって良いです。逆に考えると社長さんの会社が上記に当てはまる場合には、業務効率化の可能性がたくさんある会社と言えます。システムの導入などで業務を効率化すれば、今まで5人で回していた業務が楽に4人で回せるようにもなってきますので、表面的なシステム導入にかかる金額以上の価値は絶対にあるのです。

今回はそんな中でも、地味で後回しになりやすくエクセルなどで管理しがちな従業員精算について、導入して効果のあった「楽々精算」を事例として、導入の際にどのような方法で導入するのか、どのような点に注意して導入すべきなのかを紹介したいと思います。

※なお、ここで取り上げるシステムなどは、実際に私が導入して効果があったシステムだけを紹介しています。この記事自体はシステム会社からお金をもらって宣伝しているアフィリエイト記事では無いですので、フラットな視点で見ていることはお約束したいと思います。

＜目次＞

１．これまでの従業員精算について

１．１．従業員精算の種類

１．２．既存の従業員精算方法

１．３．従業員精算の課題

２．リプレースツール選定

２．１．自社でカスタマイズして導入が出来ること

２．２．申請者の入力工数を削減でき、承認者・管理者の工数も増えない事

２．３．月額15万円以内におさまること

２．４．実際は楽々精算一択

１．これまでの従業員精算について

１．１．従業員精算の種類

従業員精算は、従業員が会社の代わりに自分でお金を立て替えて相手企業に支払い、後日従業員に対して会社が立て替えてもらった分の費用を支払う行為を指します。この種類は大きく以下の４種類に分類されていました。これからその4種類について説明したいと思います。おそらくどの企業でもほとんど大差はないと思いますが、一部その企業特有の事情などがありますので、その際は社長さん自身の会社のルールに読み替えて読み進めてください。

＜従業員精算の種類＞

NO	精算の種類	勘定科目	主要項目
1	交通費精算	旅費交通費（～200キロ）	利用日、経路（From～To）、金額、来訪先、来訪目的
2	国内出張費精算	旅費交通費（200キロ～）	利用日、経路（From～To）、金額、来訪先、来訪目的、日当、ホテル費用
3	経費精算（交際費・会議費）	交際費、会議費	利用日、金額、実施目的、支払先名、参加者（社外・社内）、
4	経費精算（その他）	消耗品費、新聞図書費、その他	利用日、金額、実施目的、支払先名

NO1．交通費精算：営業や新規事業企画、マーケティング活動などで相手先企業を訪問する場合、電車・バス・タクシーなどを利用して訪問することになります。そのように日常的に発生する会社要件の移動の精算が交通費精算です。考慮点としては、移動の経路の中で、自宅～会社間の通勤経路は除外し、経路外の費用のみを会社が負担するという事です。これは通勤経路は別途通勤費として費用を支払っているため、SUICAに定期券などをいれている場合は、その区間の費用は実際には移動をしても発生しないからです。項目は、利用日・移動経路（From～TO）・移動手段・金額・訪問先・来訪目的などを入力する必要がありました。

NO2．国内出張費精算：利用用途などは交通費精算と同じですが、新幹線や飛行機などを利用して会社が定めた長い距離を片道移動する場合には出張扱いになり、交通費精算とは区別して日帰り・宿泊を問わず、国内出張精算として取り扱います。この会社の場合には、約200キロが基準になっており、東京～名古屋を超える距離の場合にはNO1の交通費とは別に日帰りでも日当などを支給する決まりになっていました。加え宿泊を伴う出張のケースでは、ホテルの宿泊費用なども同時に精算する必要がありました。項目は、利用日・移動経路（From～TO）・移動手段・金額・訪問先・来訪目的は交通費と同じですが、国内出張固有要素の日当・ホテル費用も入力する必要がありました。

NO3．経費精算（交際費・会議費）：社内・社外問わず関係者と会食などで使用する費用です。交際費と会議費を分ける基準は、飲酒の有無と会食の参加者一人当たりの金額が基準になります。まず、飲酒がある場合には問答無用ですべて交際費になります。飲酒が無い場合は参加者一人当たりの金額が5500円以上の場合はやはり交際費となり、5500円未満の場合には会議費となりました。これは法律により会議費・交際費の上限が決まっているので、どの企業も同じかと思います。項目は、利用日・金額・参加者（全員の名前。一人頭の金額を算出する必要があるため、誰が参加したかを記録しておく必要あり）・利用店名・利用目的などを入力する必要がありました。

NO4．経費精算（その他）：NO1～NO3以外に従業員が立て替えた費用の精算に利用していました。例えばクラウドサービスのシステムなどに申し込む場合、クレジットカード決済しか受け付けていない場合などが多いです。こういった場合、会社名義のクレジットカードを全員に支給させるわけにもいきませんので、従業員個人で立て替えてもらい、後日従業員の申請に基づき精算を行っていました。システムなどは通信費に分類されますが、例えば研修に参加した研修費や、仕事に利用する本を購入した新聞図書費などがこれに該当します。項目は、利用日・金額・支払先名・利用目的が必要になります。

１．２．既存の従業員精算方法

従業員は事前に従業員精算用の振込口座を、通常の給与振込口座とは別に1種類会社側に提出しており、経理部が従業員精算情報を確認し従業員口座に振り込む運用になっていました。従業員精算は15日〆と月末〆の2種類が存在しており、月をまたいでの精算は禁止されていました。15日〆までに提出されたデータは当月20日振込、月末〆までに提出された従業員精算は翌月5日振込の運用となっていました。

ではNO1～NO4の従業員精算を、システム導入前の既存ではどのような手順で行っていたのかをフローを元に見ていきましょう。

＜既存の従業員精算方法＞

STEP1～STEP5までは上記の流れの通りですが、ポイントは従業員精算の元になる帳票の作成は専用ACCESSツールを使って行われていたことです。この専用ACCESSツールに4種類の入力FMTがあり、情報を入力すると種類ごとの帳票が出力される仕組みになっていました。

専用ACCESSツールは開発部のSEが開発・保守を行っており、従業員は誰でもこの専用ACCESSツールのショートカットをローカルにコピーして登録できる仕組みになっていました。また経理部で管理している経理システム（勘定奉行）に連携するために、登録内容をCSV出力する機能もありました。

１．３．従業員精算の課題

この従業員精算の課題点は大きく3点ほどあり、その理由はまさしく専用ACCESSツールを使用していることに起因していました。

一点目は従業員観点で、使用感・使い勝手が悪く登録に時間がかかることです。そもそもツールの成り立ち自体が、開発部のSEが片手間に作成したものですので、UIなどを考慮しておらず非常に使いずらいものでした。例えば、従業員が交通費精算をしようとした場合、一つの移動先をいれるのにジョルダン乗換案内などをみながら一つ一つ路線と費用を確認して登録していく必要がありました。また、都内ですと通常地下鉄（東京メトロ）→JR（山手線）→地下鉄（・・・）など乗り換えが1つの目的地に行くだけでも複数回発生しますが、その場合乗り換え回数に応じた行分を入力する必要がありました。

専用ACCESSツールですので経路検索ツールと連動などの機能は当然ありません。また、１．１でも書きましたが交通費の考慮点として通勤経路は含めてはいけないのでうが、このあたりの自動判別機能なども当然ながらありません。通勤経路が含まれる場合は、その経路はユーザーが自分の目で見ながら取り除いて、実際の移動経路とは異なる形で登録する必要がありました。

このような形で従業員精算をするのにいちいち時間がかかってしまうのです。そして悪いことに、この企業の場合交通費・出張費などは役職が上になればなるほど利用頻度が上がってくるので、被害を被るのは役員が一番その度合いが高いという状態でした。一例として、役員などは月末は従業員精算の登録などで、毎月4～8時間ほどこの登録処理だけに費やしていたという状態でした。

二点目は会社観点で内部統制上非常に問題がある仕組みという事でした。上記のように登録にも時間がかかる仕組みになっていますが、登録が大変なためミスも多発していました。その際は上司や経理責任者が捺印時に指摘をするのですが、従業員は自分が登録したデータをACCESSで探してDBを修正をして再出力をしていました。このデータを従業員が誰でも修正できる状態だったのです。

これは専用ACCESSツールがログイン機能を持っていないから致し方なかったのですが、誤って他人の情報を修正してしまうこともありえますし、下手をすると間違って削除をしてしまう可能性もあります。また、誤って修正した場合にもそれがだれか行ったのかなどの履歴などは残るようなものではありませんでした。実際に誰かが間違って捺印済みのデータを消してしまい、裏で経理部や開発部SEなどが辻褄合わせのために紙に出力されている内容と全く同じ情報を入力するなどのミスも度々発生しているような状態でした。

三点目は開発部観点で、専用ACCESSツールのフォローで月に0.2～0.3人月程度開発をしたメンバーの手が取られるという工数の問題でした。このツールは開発部のSEが片手間に作ったと書きましたが、その分要件定義書や基本設計書などはもちろんありませんので、その開発をしたＳＥしかメンテナスが出来ない状態でした。上記の課題の二点目で書かれたような状況が発生したときの経理部からの問い合わせや、データの確認、たまに発生するバグの対応など地味に工数が取られることが課題でした。

ただ、こういった課題感があったにも関わらず、専用ACCESSツールはリプレースされることも無く放置されていました。これは開発部観点だと、「システムと呼ぶには構造が単純すぎて自分たちのスキルを活かしづらい」という特徴があり、開発部も積極的にリプレースを提案する性質のものでなかったという事が理由として挙げられます。また、経営層にとっても「従業員精算ぐらいエクセルでもできるので、わざわざ金をかけるだけの必要もないだろう」という認識がったことも理由として挙げられます、またこの会社の事例の場合、社長は専用ACCESSツールを用いた入力などは行っておらず、社長秘書が代替入力処理していました。そのため、社長にとっても自分に実害はない状態でしたのでその大変さが伝わらずずっと放置されていました。

２．リプレースツール選定

この浮いていた状態だった従業員精算のリプレースを、私が担当することになりました。きっかけは、半年前に行われたM&Aでの競合先の吸収合併でした。買収先の従業員精算システムはエクセルで行われていたので、いい加減にそれを共通の仕組みに統合する必要があったことと、何より課題点１の経営層向けの入力負荷が非常に高かったため、社長も決断することが出来たのです。

これに際し、リプレースの条件を以下のように決定していきました。

２．１．自社でカスタマイズして導入ができること

まず第一は既存のこの会社のシステムと同じように、導入企画者の私がカスタマイズして導入ができることということです。元々対象とする業務が従業員の業務処理をサポートする業務システムですので、従来のように社内SEの工数を利用したり、ましてや外部のSEを活用するなどしてしまうと高コストになってしまうためです。

この会社の場合開発部の社員は社外の顧客が使うECシステムを全て自社開発していたのですが、開発部の社員はECシステムに注力してもらい、なるだけこのような業務システムの場合には開発部の関与度合いを下げてあげたいというのが思いとしてはありました。そのため、自社でカスタマイズして導入が出来る事を条件にしました。

２．２．申請者の入力工数を削減でき、承認者・管理者の工数は増えない事

次に二点目は従業員精算利用の申請者の入力工数を削減でき、承認者・管理者の工数は増えない事を目標に設定しました。先に課題感の所でも書きましたが、特に申請者の入力負荷は課題になっていましたので、実際に測定したうえで、その負荷を削減できることを目標としてあげました。また、例えば申請者の入力工数を下げても、承認者や管理者にその分の業務負荷が移管しただけでは何も解決にもなりません（とはいえ多少承認者や管理者の工数が増えてもトータルで削減できればそれはそれで成果とは言えますが）ので、申請者・承認者の工数が増えない事も導入の条件にしました。

そのため、何名かのユーザーを対象として工数の測定を行い、それらを可視化しておきました。

＜既存の仕組みでの測定内容＞

関与人物	業務内容	合計工数（月次）
申請者：月平均20名程度	・申請内容の入力と承認者への提出 ・ミス時のデータ再入力	0.5人月
承認者（各管理者・経理部）：月平均5名程度	・申請内容の確認と捺印処理	微細
管理者 経理部処理担当：1名	・突合処理 ・振込処理 ・問い合わせ対応（データ入力等含む）	0.3人月
管理者 開発部メンバー：1名	・CSV出力＆勘定系システム連携処理 ・問い合わせ対応（データ入力等含む）	0.3人月

２．３．月額15万円以内におさまること

最後の条件は利用料金についてです。これは特に基準があったわけでは無いですが、月額利用料15万円以内におさまるという設定しました。ツール調査の前は金額感などは不明だったのですが、この会社で利用している業務システムを参考に算出してCAPを決めました。

この会社の場合

・SaleForce（コールセンター／顧客営業状況管理）・・・約100万円／月

・JIRA／Confluence（PRJ管理／社内WIKI）・・・約15万円／月

という点を参考にしました。少なくとも利用するのは従業員精算が行われる月2回だけですし、JIRA／Confluenceの利用金額は超えないよう割とタイト目な金額設定をすることにしました。

２．４．実際は楽々精算一択

これらのポイントを踏まえつつ、検索エンジンで「経費精算　システム導入」などで検索し、ヒットしたいくつかの会社に問い合わせを行いました。資料などを送ってくれるので読み進めた結果、最初から株式会社ラクスさんが提供している楽々精算というツール一択のような状態になりました。営業のレスポンスが早く、なおかつ初回の打ち合わせで第一～第三の選定ポイントを満たしていることが早々に判明したため、柱として楽々精算を元に検討していくような形となり、他のツールを深堀して検討する必要が無く、結局そのまま選定したのです。

＜条件に対する楽々精算の結果＞

条件	楽々精算検討結果
条件１：自分がカスタマイズ導入可能	筆者の知識で自力で導入可能と判断 （プログラム不要だが、勘定科目・経理システムの知識及びDB理解及びSaaSなどのカスタマイズスキルが前提）
条件２：申請者は工数削減、承認者・管理者は工数増えない	申請者は１／２～１／４に削減 承認者は変更なし 管理者は１／２に削減
条件３：月額15万円以内	月額4万円 （～50名：3万円　SUICA読み込み：1万円）

特に条件3の、楽々精算の使用料が4万円／月と想定できたことが大きかったです。事前に想定していたよりも１／３程度の費用感で実現できることを早々につかめたため、これを覆す他会社のツールというものが無かったのです。もちろん、無料の従業員精算ツールなどもいくつかあったのですが、逆に無料であるため条件２が楽々精算時と比較するとどうしても悪くなってしまいます。

また導入の決定につながったのは、既存の紙での捺印処理もそのまま継続可能という事です。もちろん将来的にはペーパレスでの承認行為なども想定していたのですが、この企業の場合従業員のITリテラシーがそこまで高くないため、一足飛びにペーパレスでの承認行為を実装するのは難しそうだと感じていました。そのためいったんは既存の捺印などの業務フローはそのままで、申請者・承認者などの変化に対するストレスがあまり発生しないことを優先しました。楽々精算は承認WF機能がありますので紙での出力無しでももちろん可能なのですが、紙での出力などにも対応しており、かつ帳票レイアウトなども自由に設定できるため、既存の専用ACCESSツールにかなり近い形のアウトプットを作ることも可能だったことが選定における大きなアドバンテージとなりました。

そして社長の承認も取り楽々精算で既存の専用ACCESSツールをリプレースすることになりました。その様子は後編に記載をしたいと思います。

お見積もりをご希望の場合は、お気軽にお問合せフォームよりご連絡ください

お問い合わせはこちら