元エンジニアの経理が書く、経理を苦しめないシステム開発について

どうも、ストアーズ・ドット・ジェーピー株式会社(以下、STORES.jp) 
で経理をしている ベープ大澤 と申します。
（厳密にはヘイ株式会社に所属してコイニー株式会社の経理もしてます、ややこしくてすみません…）

STORES.jp Advent Calendar 2019 15日目として

「元エンジニアの経理が書く、
　経理を苦しめないシステム開発について」

というテーマで書かせて頂きます。

▼ 1．自己紹介

自分の経歴を簡単にまとめますと

◆学生 時代
経理職を目指し、会計学を専攻
→ 就活はじめる
→ 当時のリクルーター
　「男で経理職は未来がないよ」
→ 落ち込む
→ でも会計が好き！
→ 会計システムのエンジニアになろう

◆エンジニア 時代
5年ほどエンジニア人生を謳歌
→慣れてきた
→エンジニアたのしーー！！！
→システム導入にアサイン
→顧客の経理現場を見る
→「男の人もバリバリ経理やってるやん。」
→経理やろ

◆経理 時代
3年ほど経理人生を謳歌
→慣れてきた
→経理たのしーー！！！
→前職の同期が働いてる会社を知る
→なんとなく説明会（Hello Hey）に参加する
→「スモールチームのために働くって素敵やん」
→入社

という感じで、今は STORES.jp で働いています。

遠回りに見えたエンジニアとしての時間も
今となっては
・エンジニア業務の知識、経験を得られた
・システムに強い経理という武器を手に入れた
と、自分のキャリアにとってすごい良い経験を得られたなと感じています。

…

話が変わりまして、
先日、弊社のエンジニアと話しているときに
「経理から色んな数字を求められるけど、
そもそも経理って何してんの？」
と言われ、そういや自分も同じこと感じてたな～と思い

せっかくエンジニアを経て、経理をやってるので
そもそも経理が何をしていて、システム開発がどう関わってくるのか
について書こうと思います。

▼ 2．そもそも経理って何してんの？

まず経理の業務を一言でいうと

「お金の動きを正しく管理する」

に全てまとめられます。

ここでいう管理の中には
　◆お金の支払を正しく行う
　◆お金の受取（収入）を正しく検知する
　◆支払、受取の結果を正しく記録（計上）する
　◆記録した結果を正しく報告する
これら4つの意味が含まれており、
経理業務はこの4つの作業を只々繰り返しているだけなのです。

これだけ聞くと、非常に単純な業務に見えます。
では何が難しいのか？　と言うと、
これらの内容を
「後から見たときに、誰が見ても同じ事象と認識できるようにする」
が難しいポイントになります。

例えば「接待交際費」という勘定科目を考えてみましょう。

・Aさんは、営業接待の飲食代を「接待交際費」として計上
・Bさんは、社内会議の弁当代を「接待交際費」として計上
　（本当は会議費が正しい、とする）

↓ その結果

・Cさんは、社内会議の弁当代を確認しようと「会議費」をチェックしたが、弁当代は記録されていない…
・Dさんは、営業接待の飲食代を確認しようと「接待交際費」をチェックしたが、想定より大きい金額が記録されていた…

このように、支払に対して間違った勘定科目で記録されると正しい金額が確認できなくなります。

そうすると、この記録を基にしている、
「予算計画」「経営判断」「会計監査」「納税」といった大事な判断が間違った内容となり、社外まで影響範囲が拡がる可能性があるため、間違いを発生させないように、勘定科目ごとに一定の計上ルールを決めて適切に記録する必要があります。

これを会社で発生する全ての金銭に対して行う必要があるため、検討材料としてあらゆる数値やデータを各部に依頼するわけです。

▼ 3．具体的な経理処理

経理が何をしているかざっくり説明しましたが、
どういうケースで経理処理が複雑になるか、具体的な事象を挙げていきましょう。
（ちょっと長いので、早く本題に入られたい方は▼4 にワープしてください！）

◆ケース1：旅費交通費の精算

4/1の出張のために3/31に飛行機と宿泊先を自費で立て替えて予約をした。購入日は3/31のため、3/31付で経費精算を申請した。
（※3月決算の会社の場合）

→この場合、実際にお金が動いた日は3/31のため、申請も3/31付で行いたくなると思います。
しかし、経理としては実際に業務が発生した日に費用を発生させるべきという考えのため、4/1に計上する必要があります。
月を跨がない場合や、年度末以外の場合はそこまで問題ではないのですが、
本ケースのような場合（年次決算月を跨ぐ場合）、費用を計上する年度が変わってしまうため、費用の決算報告が誤ってしまうので問題となります。

申請の中に「業務発生日が4/1」という情報があれば正しく計上できますが、ない場合は対象者にヒアリングしたり、あとから発覚したときは仕訳を修正するコストが発生してしまいます。

◆ケース2：自社製品の在庫管理

hey STORE の商品を作成するためにTシャツのボディを1000着、料金先払いで購入して7月に100万円を支払った。
8月は110着納品されたが、納品書には先方が誤って100着と記載されていた。
納品書は経理部に届いたため、経理部は100着と認識して仕訳を計上した。

→この場合、料金を先払いしているため、支払った金額（100万円）から毎月どのくらい製品になったか管理していく必要があります。
具体的な仕訳を挙げると、ボディ購入時点で
前払金　100万円　/　現金　100万円
の仕訳が計上されます。

8月に商品が110着納品されているため、本来は
商品　11万円　/　前払金　11万円
と前払金から商品に振り替えるべきですが、
納品書に100着と記載されているため
商品　10万円　/　前払金　10万円
と計上してしまいました。

その後、Tシャツのボディを棚卸した際に、ボディ残は890着なのに、経理部の帳簿上では900着になっている…この10着なんやねん…と気付くと、どの月で間違えたのか過去の納品書と注文数を照らし合わせて探す必要があります。

もし納品書が届いた時点で、商品管理表と納品書を精査し、ボディ残数と経理の数字を照合する仕組みが整っていれば、先に気付けたでしょう。
実際には商品が複数存在し、金額もそれぞれ異なるため、あとから原因を特定するために大変な労力コストが掛かることになります。

◆ケース3：売上金額の計上

12月に50万円の決済がされた。そのうち、10万円はシステム上でキャンセルされたため、実際の決済額は40万円であった。
しかし、経理部が抽出した売上データにはキャンセルが考慮されてなかったため、50万円の売上で仕訳を計上してしまった。

→上記ケースの場合、10万円キャンセルが発生しているため実際に受け取るお金は40万円になり
現金　40万円　/　売上　50万円
売上　10万円　/
と、計上する必要があります。
しかし、出力したデータが50万円のため、受け取ったお金40万円との差額10万円がわからず、仕訳が計上できません。

このように、データの抽出方法を誤ると原因を特定するためにコストが発生します。
実際には売上の中にも色々と種類があるため、金額算出がより複雑になっていくため、システムから正確な情報を出力できることが重要となります。

▼ 4．経理を苦しめないシステム開発

では、今説明した経理業務を円滑に進めるために
システム開発ではどのような点を注意すればよいか考えてみましょう。

今回は下記の3点に着目してみます。

①データの出力
②設計書を作る
③システム開発に掛かる工数の管理

①データの出力

仕訳を入れるために必要なデータは、何かしらの方法で出力できることが必須だと思います。

と言うのも、経理では月次単位で、売上・費用の仕訳を記録して、1ヶ月の結果をまとめる作業（月次決算）が発生するため、お金に関する情報は毎月必要になります。
それを月次の取締役会などで報告するため、決まった期限までに仕訳を計上しきらないといけないプレッシャーと毎月闘うことになります。
期限があるから急がないといけない、でも間違った仕訳を計上するわけにはいかない…となるため、仕訳の基になる情報をいかに素早く的確に入手できるかが大事になってきます。

もちろん機能として用意しなくてもDBから取得できる手段があれば問題ないですが、
Excelで加工する際に人的ミスが発生するリスクなどを考慮すると、システムから加工した状態で出力されることがベストだとは思います。

また仕訳以外にも、
・経営判断に必要な数値を取りたい
・会計監査でデータを求められる
といった要望も出る可能性があるため、そのたびに手でデータを集計するのはつらい……
と考えると、重要度の高いデータについては抽出条件や出力方法を自由に設定できる機能があればとても幸せになれると思います。

…と、理想を述べましたが実際すべてをシステム化するのは難しいと思うので、要件定義の段階で経理を巻き込み、出力できないと致命的になる情報が何かを確認してお互いの折り合いがつく運用を考えることが現実的かと思います。


②設計書を作る

これは開発方針によって、作る作らないが分かれるかと思います。

もちろん開発を優先することが一番大事ですが、
仕訳に使用する金額が本当に正しいか検証する際に、どのように検証をすればいいか考える材料になるため、資料がないとエンジニアに直接確認するコストや内容が間違っているリスクが想定されます。

また、監査法人から仕様を求められたりする機会も多いため、
最低限、お金に関するデータの登録、遷移、修正の方法とタイミングなどをエンジニア以外もお金の流れを理解できるようしっかりドキュメントを残しておくと、いざというときにスムーズに対応できるでしょう。

③システム開発に掛かる工数の管理

工数の管理は生産的な業務ではないため、軽視されがちですが、
システム開発で一番大きいコストが人件費です。
利益を算出するためには「売上」と「原価」を把握する必要があるため、正しく利益を出すためにはプロジェクトごとに工数の管理が必要となります。

会社の方針によっては、そこまで具体的に原価を計上しない場合もありますが、原価を算出することは経理で使用する以外にも、経営戦略を検討して収益性をアップしたり、より効率的な開発サイクルを回すためにも有効な数値になります。
そのようなメリットを考えると、早い段階からコスト管理を習慣付けることをおすすめします。

▼ 5．まとめ

このように、経理はお金の動きを正しく管理する仕事です。

1円単位まで金額を合わせる必要があるため、細かい情報まで求められることがあり、他部の方にとっては対応が面倒に感じることも多いでしょう。
また、経理業務はシステムに大きく影響されるにも関わらず「何をしているかわからない」ので、開発側も要件定義段階で巻き込む考えが出にくいと思います。

しかし、お金に関する情報は会社の信頼性に大きく影響してくる内容で、非常に重要なものです。
社員全員で協力して信頼される会社を作っていけたら、とても素晴らしいと思います。

本記事を読んで、皆さんが仕事をする中で少しでも経理業務に意識を向けて頂けたら嬉しいです。