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

専用Accessで作っていた従業員の経費精算ツールについて、業務効率化のためのシステム導入－楽々精算（前編）では、専用Accessツールの業務フローやその課題と、リプレースの検討を行い結果として楽々精算というツールの導入を選択したことまでを書きました。この記事では、実際にどのように楽々精算をカスタマイズして従業員に導入していったのかをご紹介していきたいと思います。

＜目次＞

＜前編＞

３．楽々精算のカスタマイズ

３．１．新業務フローの作成

３．２．ベース情報の設定

３．３．帳票（＝画面）カスタマイズ

４．社内導入

４．１．経理への導入

４．２．従業員への導入

５．成果

５．１．実際の成果と想定との差異

５．２．感想

３．楽々精算のカスタマイズ

３．１．新業務フローの作成

新システムを導入する場合最初に決定しなければいけないのは、「既存業務フローをどのようにシステムに合わせて変更するか」という点です。楽々精算の場合は、申請→承認→経理連携までがWEB上で完結する機能（＝ワークフロー機能）が標準で準備されているため、これまでの紙に依存した業務フローを変更して、WEB完結することも可能でした。紙を廃止して、WEB上のワークフローに移行するかが業務フローの検討ポイントでした。

まず結論からいうと、実装した業務フローは既存の業務フローとほとんど同じもので入力対象のAccessツールを単純に楽々精算に置き換えただけのものにして、紙でやり取りをするフローは残しておくことにしました。

＜楽々精算導入後の業務フロー＞

当初の考えでは、紙で印刷するフローを改めてWEB上で承認をしていくワークフローの導入を検討したのですが、以下の２つの理由から見送ることにしました。

第一点目として、紙で出力をして承認フローを回しても、WEB上で承認フローを回していくにしても、そこまで申請者や承認者の工数に変化はない事。そのため金銭的なメリットがそこまで得られないことがわかりました。もちろん紙の出力枚数の削減などにはなりますが、この会社は派遣社員や外部パートナーをいれても100名規模でしたので、その効果はたかが知れています。むしろ、紙での出力の場合には承認者が任意のタイミングで管掌従業員の申請を確認し承認印を押せばよいのですが、楽々精算の機能を利用したWEBの場合は、申請が行われる都度に承認者にメールで依頼が飛ぶフローとなっていましたので、承認者の承認タイミングが頻度が高くなってしまい仕事を中断させることで、本件以外の工数を圧迫する恐れがありました。

第二点目として、申請者・承認者ともども変化を大きすぎないようにしたかったこと。少なくとも

・申請の画面I／Fは専用Accessツールから楽々精算へ変更となり、項目変更も若干発生

・出力帳票は専用Accessツールから楽々精算へ変更

と従業員にとっては、画面も帳票も変わる大きな改定になります。それに加えて業務フローも変わるとなると従業員の混乱が大きくなるのではないかと考えました。

第一点目でも述べたように工数削減という金銭的なメリットが見込めない事と、第二点目で述べたように変化を大きくし過ぎたくない思いがありましたので最終的にはWebでの承認フローの導入は諦めて紙のままの承認フローを回すことを決定したのです。ただし、最後のSTEP5の所でこれまでは「CSVと帳票を付け合わせて入金処理をする」という処理フローそのものがおかしかった箇所は、業務主体が経理に限定されるため、「経理システムと帳票を付け合わせて入金処理をする」とするように処理フローを改めました。このため業務フロー的にはほぼ変更が無い形で楽々精算を導入することにしました。

３．２．ベース情報の設定

いざ、楽々精算をカスタマイズする段階になりました。まず第1段階として、楽々精算さんの発行してくれたアカウントにログインし、アドミニストレーターの機能設定を行います。

この時に、まずは従業員情報や組織情報などの人事情報や、人事規定に乗っているようなルールを網羅して策定します。以下、設定をした情報を簡単に表にしました。

内容	設定理由	設定値例
組織（※人事情報と共通） 従業員情報：組織	社員が、所属組織・負担組織を選択する際に利用。 データは管理会計の事業P／Lを作る分類の基準となる。 当該従業員の所属組織とデフォルトでの費用負担組織（所属組織と共通）を設定	システム部開発課 財務経理部 A事業部
従業員情報（※人事情報と共通）：役職	社員が、国内出張・海外出張をした際の日当の計算に利用。 部長以上・課長・チームリーダー・メンバーと、役職ごとに日当と宿泊の際に利用できるホテルの単価が違うため、エラーチェックのために利用	取締役・執行役員 部長 課長 チームリーダー メンバー
従業員情報：通勤経路	交通費精算を行う際に、通勤経路を自動除外するために必要。 通勤路線を従業員ごとに登録	JR京浜東北線：上中里～東京 東京メトロ東西線：東京～木場
人事規定：国内出張日当	国内出張日当額を宿泊日数ごとに自動算出するために必要。 役職ごとの国内出張日当を記載	課長以上：4,000円 （取締役・執行役員、部長、課長が該当） 課長未満：3,000円 （メンバー・TLが該当）
人事規定：国内出張のホテルの上限代金	国内出張のホテルの上限代金。首都圏・関西・その他地域で、管理職（課長以上）・チームリーダー・メンバーで上限額が異なっているが、上席者と同じホテルに宿泊する際には、上席者の基準が適用される。 こちらはエラーチェックではなく、文章としてリンクを記載	東京のホテル上限代金 課長以上：15,000円 チームリーダー：13,500円 メンバー：12,000円
経理慣行：証憑不要の区分	証憑（その行為をしたとする証拠。すなわち領収書のこと）が不要となる取引を指定。 具体的には電車・バスなどの公共交通機関での移動を証憑不要に指定（ただし、新幹線は必要）。	電車・バスでの移動：証憑不要 タクシーでの移動：証憑必要
楽々精算データの勘定奉行への連携	会社の財務会計の仕組みが勘定奉行を使用していたため、楽々精算に入力された情報を勘定奉行へ連携するために、勘定奉行FMTに沿って出力するよう選択	ー

まず基本的な前提として、

・人事情報（組織・従業員データ）

があります。これらの情報が入っていないとそもそも従業員はシステムにログインすらできませんし、肝心の発生している費用に対してどの組織のために利用したのか適切に仕訳することすらできません。そのため、これらの情報は人事部と協議を行い、人事部のタスクとして人事DBの更新タイミングと同様に毎月月初に異動情報（新入社員の入社情報の反映、社員の役職の昇降格や組織異動）を月初に反映してもらうことにしました。

また、

・従業員の通勤経路

の情報も大切になります。楽々精算では通勤経路を入力しておくことで自動的に交通費の経路から除外する機能を持っているからです。この機能が使えないと前編に書いたような従業員の入力負荷の削減は期待できません。こちらのデータも、毎月の通勤交通費の算出のために人事部員が人事DBに経路登録を行っていたので、同様の内容を楽々精算に月次で登録してもらうことになりました。人事部からすると、二重の人事データ更新で仕事が増えた形になりますが、それでもどんなに高く見積もっても0.5人日程度の増加想定でした。ここでの工数増加と、従業員が受け取れる「入力負荷の削減」を比較すると圧倒的に後者の工数の方が多いことを説明し、人事部も喜んで仕事の増加を引き受けてくれました。

次に、人事規定情報を設定していきます。

・国内出張日当

・国内出張で宿泊時の料金の上限

これは人事規定でそれぞれ「国内出張規定」という情報に定められていました。ところが、規程の存在そのものを知らない従業員が多く、経理などが各種申請データを見て「これは国内出張だから日当を申請できますよ」と声がけをして修正をしてもらっているような状態でしたので、なんとかこれを自動化できないかと思いました。

国内出張規定上では明確に「出発地から片道200KM以上離れた目的地へ向かうことは国内出張である」と規定されていました。加えて、楽々精算の場合には交通費と国内出張でデフォルトでメニューが分かれていたので、そもそも国内出張精算の申請をしている時点で、従業員の役職別の日帰り・宿泊日当がつくように自動で計算するように設定することが可能でした。

また国内出張が宿泊を伴う場合、ホテルの上限代金にも制限を設けており、規程上は「実費を支給するが、上限は以下の通りとする。ただし、上席者と同じホテルに宿泊した場合には、上席者の基準を適用される」とありました。ただし、これを実装しようと思うと、システム上同行者も入力させたり、その役職を確認してチェックロジックを緩めたりなどかなり煩雑になるため、実装は諦めました。その代わりに国内出張の入力画面にホテル代金上限規定のリンクを張り、「国内出張時のホテル代金には上限がございます。詳細はこちらをご確認ください。」と説明することで、あくまでも注意喚起レベルにとどめておくことにしました。

そして次に経理上証憑が不要な取引を明確にしました。具体的には

・電車・バスでの移動

の場合にはSuicaなどを利用し領収書が残らないため、これらの移動の場合には証憑となる領収書を不要なよう設定を行いました。

最後に、入力された交通費・経費・国内出張申請は、財務ソフトの勘定奉行に連携する必要があったので、経理が経理申請〆を行ったタイミングでデータ出力を行い、勘定奉行に取り込みをできる機能も装着しました。これも楽々精算のデフォルトの機能で準備されており、勘定奉行以外にも弥生やその他の会計ソフトにも対応していたため、こちらはある機能をそのまま活用して、勘定科目のコードだけがずれないようにしておきました。

このような事前設定を行った後で、いよいよ各帳票画面のカスタマイズに移りました。

３．３．画面（＝帳票）カスタマイズ

前編にも書きましたが、これまでの既存業務を大きく変更にすることになるワークフローのシステム実装（＝WEB上での承認行為）は、

１．既存の帳票の要素を確認する

２．新規帳票と既存帳票での過不足を明らかにする

３．新規帳票に追加・削除するべき項目を明らかにする

の3段階で行うことが普通です。この時意識すべきことは「可能な限り業界の標準ルールに合わせる」つまり、楽々精算の「新規帳票」にFMTを可能な限り統一するということです。当たり前ですが、立替精算などの機能はある程度どの会社でも共通するものですので、楽々精算のデフォルトで使われている機能をそのまま利用するのが、一番間違いがないからです。

楽々精算は、画面と帳票がほぼイコールになるような機能でしたので、帳票出力を見越してデフォルトの項目は可能な限り残すような形にして、足りない項目のみを追加していくことにしました。細かな設定の注意点は割愛しますが、結果として以下のような画面・帳票になりました（※帳票を例にしていますが、が画面もほぼ同じです）。

まずは交通費精算を見てみましょう。

＜交通費精算ー国内出張を除く移動＞

NO1の木場～西新宿への移動を見ると、実際に異動した経路は、

A：木場～日本橋（東西線）

B：日本橋～赤坂見附（銀座線）

C：赤坂見附～西新宿（丸の内線）

と３つの地下鉄を乗り継いでいるのですが、A区間は通勤経路にあたるため除外がされていることがわかります。実際に私に出費が発生したのはBとCの区間ですので、その分の運賃の片道「195円」の往復分「390円」が交通費精算の対象として小計に表示されています。またこれらの移動は公共交通機関を使い移動するので証憑は残りません。そのため、証憑不要というとで証票欄には印はでておりません。一方で、NO2の木場～上中里現地は深夜タクシーを使っての帰宅を指します。この場合は公共交通機関の利用ではないため証憑は必須となり、証票欄に○印がついています。

次に、片道200KMを超える移動先に行く場合に適用される国内出張精算を見てみましょう。

＜国内出張精算ー片道200KMを超える移動の計算＞

国内出張精算の記録で、こちらは信州長野にあるクライアントを訪問した際のものです。交通費精算との違いは、交通費精算は半月ごとに処理をするため期間で区切っていますが、国内出張精算はイベントで区切るため一回のイベント都度入力をすることです。また交通費などとの違いとして、国内出張は日当も出るため何の目的で移動をしたのか目的欄の記載が必須となります。このあたりの項目もで楽々精算のデフォルトの項目をそのまま採用しています。

移動を伴う交通費・国内出張費と違い、この後の２つは必ず証票やその目的等が必要になるものです。まずは一番基準が厳しい飲食を伴う交際費・会議費の帳票は以下のようになりました。

＜飲食費精算ー交際費・会議費＞

これはとある企業とランチMTGを行った時のものです。こちらも国内出張精算と同じく行為の都度入力が必要になります。

この時は私がメンバー全員分のお弁当を手配して立替払いをしておきました。飲食費精算で特徴的なのは実施日時・目的・参加者の所属企業名、氏名（全員分）及び人数の記載が必須となっていることです。これは社長さんならばわかると思いますが、税務調査対策でこれらがそろっていないと経費として否認される恐れがあるからです。社長さんや経理メンバーには常識でも、従業員の場合それが単なる社内ルールなのか会社を超えて決まっているルールなのか判断が難しいのです。このため上記の項目は必須項目として、入力がなされていない場合には申請を受け付けない仕様にしておきました。

そして最後は、飲食費以外の立替精算です。こちらは例えば会社での利用を目的とした文房具等を個人で立て替えた場合などに利用します。

＜その他経費精算＞

こちらは飲食費精算とは違って入力項目は最低限の利用目的ぐらいです。また、交通費などと同じで月2回で精算のような形になるため、イベントごとの申請でもなく期間で申請する形となります。

このような形で、各種設定を行い実際に従業員に導入する準備が整いました。なお実際にツールのアクセス権を付与されてから、ここまで約2週間で設定を行いました。

４．社内導入

次に3週間を使って、社内へ導入していく形となりました。こちらは

１．事前に手順書をConfluence上に作成：1週間

２．経理部・従業員へそれぞれ導入：2週間

というスケジュールにて行いました。経理部へは責任者と経理担当者合わせて1回の打ち合わせ1時間で説明。従業員へは広報メールと勉強会を2拠点（東京・静岡）で開く形をとりました。

４．１．経理への導入

経理にとっての変更点は以下の通りでした。

１．帳票レイアウトが、既存のAccessの時と大幅に変更になること。

２．振込処理を、CSVと紙の帳票を比較して振込処理を行うのを、勘定奉行と紙の帳票を比較して振込処理を行うこと。

まず1点目に関しては、これまでの帳票と新しい帳票の新旧比較をマニュアル上に明記して、見た目のレイアウトは大きく変わっているものの、基本的には既存項目は網羅されており、その上で追加項目がどれであるかを説明しました。

2点目はこれまでの処理がおかしかったので、正常な形にしました。また経理の振込処理の結果を帳票上に明記する欄が無かったので振込処理が終わった後で”経理検印”欄を利用して業務をしてもらうことにしました。

上記2点について、特に問題も無く説明が完了し経理への導入は完了しました。

４．２．従業員への導入

従業員にとっては、使うシステムが変更になるので説明は念入りに行いました。

１．社内Wikiツールとして利用してConfluenceにマニュアルを掲載

２．東京・静岡拠点でそれぞれ勉強会を2回づつ実施（内容は同じもの）

まず1のマニュアルに関しては、以前紹介をしたConfluence上に作成しました。この時の作成するポイントはとにかく間違っても良いので、すばやく作成することです。上記では1週間と書きましたが、実際には以下のような形で進めました。

1日目：目次の構成検討・作成、主な画面ハードコピーの取得とアップロード

2日目：文字の記載

3日目：推敲（文言の付け足し、追加ハードコピーの取得）

4～5日目：予備

このように、最初の2日で大枠の作業を完成させ、後は推敲レベルにしておきます。逆に言うとあまり最初から大層なマニュアルを作成せずに、従業員の勉強会での理解度などによって後から追記などを検討することにしました。

2の勉強会は1時間枠を確保し、前半の30分でConfluenceを投影しながらその説明。後半の30分を質疑応答という形にして同じ内容の勉強会を2回行いました。この際に質問が出たりした箇所は、Confluenceのマニュアルに反映させる形で同時にマニュアルを進化させていきました。

５．成果

５．１．実際の成果と想定との差異

このようにして無事に楽々精算の導入が終わりました。そして、導入後3ヶ月程度たってから当初の想定した効果が実際にはどの程度であったのかを振り返りを行いました。工数の削減目標を掲げていたので、実際に工数がオーバーしていれば本末転倒であるからです。

＜インタビュー対象者＞

申請者：20名／月利用しているので、よく利用している営業1名・営業管理職1名・取締役1名にヒアリング

承認者：複数名。省略

管理者：経理部処理担当1名・以前のAccessツール開発者1名にそれぞれヒアリング

＜導入前・導入後想定と実際の工数＞

工数対象	導入前工数	想定工数	ヒアリング結果
申請者	0.5人月／月×20名	0.12人月～0.25人月／月×20名 （1／4～１／２程度に工数削減）	0.1人月／月×20名 （１／5に工数削減）
承認者	微細／月×5名	微細／月×5名 （変更なし）	微細／月×5名 （変更なし）
管理者（経理処理担当）	0.3人月／月×1名	0.15人月／月×1名 （１／２程度に工数削減）	0.25人月／月×1名 （多少削減だが微細レベル）
管理者（開発担当）	0.3人月／月×1名	0.15人月／月×1名 （１／２程度に工数削減）	0.0人月／月×1名 （工数がゼロになった）

申請者に関しては、予想通り入力時の経路入力が無くなったためかなりの削減となりました。加えて交通費精算でICカードリーダーと連動したSUICAの自動読み取りを実装したため一番工数が多かった交通費精算の入力負荷を削減することが出来ました。0.5人月から0.1人月（差分：0.4人月）に削減できたので時間に直すと約6時間の手間が削減できたことになります。これが20人分ですので、会社としては約120時間分／月の入力にかかる負荷を削減できたことになりました。

また管理者に関しては、経理処理担当の負荷はあまり削減されませんでした。これは国内出張は専用FMTを使うにもかかわらず、わからずに交通費のFMTなどを使うメンバーなどがいて指導するケースがあるからとの事でした。これらは3ヶ月目だったのでまだしょうがないかもしれませんが、いずれはこういった負荷は下がっていくものと予測できます。

管理者（開発担当）に関しては、完全にこれまでかかっていた業務工数をゼロにすることが出来ました。こちらは予想以上の成果となりました。

５．２．感想

全体的な感想としては、非常に簡単かつスピーディーに導入することが出来ました。導入に関しては基本的な経費精算に関する勘定科目の知識（簿記3級レベルで充分）と、DBに関しての知識があれば簡単に導入できるかなと思います。

こういった業務系システムは後回しになりがちですが、やはり世の中一般に共通する業務（人事・経理等）に関してはSaaSシステムを利用することが従業員の工数削減にかなりつながることになると実感しました。導入して非常に良かったと思います。

本日は楽々精算の導入を具体的にどのように行っていったのかを説明しました。ぜひともこの記事を読まれている方も、自社のバックオフィス部門に導入し、不要業務の削減→パフォーマンス向上のサイクルを実現してもらえたら嬉しいです。

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

お問い合わせはこちら