資金繰りのベストプラクティスを見つけるには？実務に即してわかりやすく解説！②

資金繰りについての第2回目のテーマは「なぜ資金繰りを管理できるソフトウェアやシステムが世の中にほとんど無いか」です。これはかなりたくさんの人が興味あるテーマだと思っています。 

前回の記事は、資金繰り業務の全体像を見渡せるようにすることを目的に書きました。ぜひ復習して下さい。これを踏まえて、システム化する上での課題を私なりにまとめました。 

少し長めの記事になりますが最後までお付き合い下さい。 

資金繰りのベストプラクティスを見つけるには？実務に即してわかりやすく解説！①

 

私は社会人になりたての頃、システム会社の営業マンとして色々な会社の経営者、経理担当、財務担当の方とお話する機会がとても多かったです。皆さん口を揃えて「資金繰りの管理ができる安価で導入可能なパッケージソフトってないの？作ってくれたら買うよ！」とおっしゃっていたのがとても印象的でした。 

単純な私は「どの会社にも適用できる資金繰りのシステムを開発してくれ」みたな無茶な依頼を開発部メンバーにした覚えがあります。その後、私は営業マンからシステムエンジニアに役割転換して長い月日が経ちました。しかしシステムエンジニアとして汎用的に使える資金繰りのシステムを作れていません。いまだにこの問題に終止符を打てていません・・・。 

「なぜそんなにニーズがあるのに、どのシステム開発会社も作ってくれないの？」そんな疑問に答えていきたいと思います。 

システムベンダーには得意分野／苦手分野がある 

表題の通りなのですが、システムベンダーごとに得意分野と苦手分野は必ずあります。給与計算、勤怠管理、人事管理、勤務シフト管理等の企業で働いている従業員の管理に精通しているシステムベンダーが存在する一方で、外国為替のスペシャリストとして輸出入管理システムが得意分野のベンダーも世の中にはいます。 

企業にまつわる全ての業務に精通していると言えるシステムベンダーはなかなか無いのではないでしょうか？実は財務会計システム一つとってみても、システムベンダーによって特色がかなり異なります。 

※中小企業の単体決算が得意なベンダー 

※上場会社が求める機能を提供できるベンダー 

※IFRS（イファース：国際会計基準）対応の財務諸表作成が得意なベンダー 

※連結決算をサービス提供できるベンダー 

私も比較的、財務会計や管理会計の知見を持っているシステムエンジニアと自負できるレベルではありますが、正直連結決算のシステムコンサルなどになると相当怪しいです・・・。また、給与計算や勤怠管理の分野も知見はそれなりにありますが、建設業が相手になると話が違います。出面（「でづら」と読みます）といって工事現場ごとの1日当たりの人員配置の概念が出てきて、単純に給与明細書発行や年末調整ができればよいわけではありません。 

現場ごとのシフトや現場ごとの人件費配賦等が求められることがあります。 

このようにシステムベンダーには必ず苦手分野が存在します。少し遠回りしてまでなぜこんな話をしたかというと「資金繰り」というのは企業内で行うあらゆる業務の組み合わせで成り立つものだからです。 

あなたの会社で導入している業務系のシステムを整理してみて下さい。「お金の管理をする」という共通点があるにも関わらず、おそらく様々なシステムベンダーのサービス利用をしているはずです。残念ながら・・・システム業界というのは「餅は餅屋」の世界なのです。 

結論はこうなります！「資金繰りシステム」が独立していても意味がないのです・・・。「資金繰りシステム」を謳っているサービスのデモンストレーションを見たことはありますが、確かにカッコいい資金繰り表は作成できます。しかしインプットするデータを正確かつ効率的に収集するという一番大切な問題解決にフォーカスしているサービスを見たことがありません。 

資金データの整理について 

この章は難しかったら読み飛ばしても構いません。システムエンジニア目線の資金繰りシステム構築の困難さを表現しています。 

前章の流れの通りなのですが、様々なベンダーのシステムを使っていたらデータ形式が統一されていません。もちろん私達が業務で使用するシステムはほとんどが外部出力機能を搭載していることでしょう。ＣＳＶ（カンマ区切りのテキスト）データ等が出力できるはずです。上手く組み合わせができれば資金繰り管理に役立つかもしれません。 

またデータ収集／データ整理するに当たって提案するシステムエンジニア（ＳＥ）にも知見は相当求められます。特定の業務に精通しているスペシャリスト型ＳＥよりも、広い業務に精通しているゼネラリスト型ＳＥじゃないとそもそも顧客と会話が成り立たないと思います。しかし所属するシステムベンダーによってＳＥの知識にも必ず偏りが出てきます。 

前回の記事でも上げましたが減価償却費計上の場合、簿記の取引としては資金変動がありません。しかし機械設備や工場設備建築などの固定資産購入の場面では資金が変動します。モノを買ってお金を払うから当たり前ですよね。ただしこういった高額な取引の場合、完成前に一部金額を手付金として先払いすることがあります。簿記の勘定科目というと「建設仮勘定（貸借対照表の資産の勘定です）」になります。 

こういった情報を管理するのは一般的に「固定資産管理システム」という分野でしょうが、下記の知識をＳＥが理解していないとデータ整理ができません。 

※固定資産の購入 

　→資金減少（実務上は掛取引になるので減少タイミングはズレる） 

※減価償却費の計上 

　→資金変動無し 

※建設仮勘定の計上 

　→資金減少（実務上は掛取引になるので減少タイミングはズレる） 

※建設仮勘定から本来の固定資産勘定へ振替 

　→差額部分だけ資金減少（実務上は掛取引になるので減少タイミングはズレる） 

資金減少と記載しましたが実際は掛取引になるため、資金減少タイミングは少し未来にズレます。掛け金の支払も半金半手（半分現金もしくは振込で、残り半分を約束手形で支払う）の概念が出てくると超複雑です・・・。ちょっと例をあげました。 

・4月30日に10億円の新工場の受け入れをして掛とした。 

　掛の半分を翌月末振込払いで残りを90日サイトの約束手形で支払った。 

この場合は5月末に5億円の資金減少、その90日後（3ヶ月後）の8月末に残りの5憶円が資金減少します。実際にはこんな単純ではなくて、支払額に応じて全額振込払いということもあります。半金半手の配分やサイトも取引先によって異なります。振込70％、手形30％という配分でも実務上は半金半手と言います。 

固定資産購入の例から資金繰りに必要なデータ抽出判定するポイントをあげてみました。これらは残念ながら「専門知識」ではなく「知ってて当たり前の知識」なのです。全方面の業務分野でこういた常識的な「知ってて当たり前の知識」がたくさん求められます。私が汎用的な資金繰りシステムを作れていない原因がここらへんにあります（笑） 

会社ごとのビジネスモデルが多岐にわたる 

前章では恥ずかしながら、私達SEの業務知識の欠如による問題点をたくさんあげました。しかしそんな私みたいなSEでも、持てる知識を駆使して特定のお客様に喜ばれる資金繰りのシステムを導入した経験は多数あります。なぜそういった知見が横展開できていないかというのが、この章のテーマです。 

結論から言いますが、会社によってビジネスモデルが違いすぎます。見かけ上は同業種でも実際に話を聞いてみると結構、重視するポイントが異なります。誰でも知っている有名企業を例に出すと、JR東海、JR九州と聞けば一般的には鉄道の会社と答える人が多いでしょう。間違ってはいないのでしょうが、JR東海は利用客数の多い東海道新幹線といった花形路線を主軸にしたビジネスで、JR九州は実は不動産事業に強みを持ったビジネス展開が特徴なのです。 

ビジネスが異なれば資金繰りでフォーカスが当たる箇所も当然変わってきます。今記事を書いている2024年4月現在、1ドル（USドル）155円近辺という超円安が社会問題になっています。私達も物価が上がって生活がどんどん苦しくなっています。 

しかし輸入をビジネスの柱としている企業はもっと苦しいと思います。輸入雑貨店のようなビジネスであれば、超円安による仕入コスト高騰は死活問題すぎます。為替レートの変動リスクや変動シミュレーションを考慮した資金繰りが必要になるのは言うまでもありません。為替レート変動のリスクヘッジのために、デリバティブ（先物やオプション）といった概念も考慮した資金シミュレーションができないと使い物にならないかもしれません。 

資金繰りの定義がそもそも曖昧 

開発した資金繰りシステムが横展開できない他の理由としては会社ごとに求めるレベルにギャップがありすぎます。ある会社は「当面3ヶ月資金ショートしないように足りない資金を可視化したい」といった簡単な要望である反面、他の会社は「将来のキャッシュイン、キャッシュアウトの金額を現在価値に置換えて資金管理がしたい」といった高度なレベルを求めるケースがあったりもします。前章であげたデリバティブの例なんかも後者に当たると思います。 

全ての顧客が満足するシステムにしようとすると機能が多すぎてユーザーインターフェースが複雑になってしまいます。結果的に使い勝手の悪いシステムになることは火を見るよりも明らかです。 

終わりに（次回展望等） 

資金繰りのベストプラクティスを紹介するというテーマを掲げているにも関わらず、システムエンジニア目線で資金繰りシステム導入の困難さをひたすら列挙してしまいました。ほとんどがシステムエンジニアの言い訳っぽい記述ばかりになってしまい申し訳ありません・・・。 

次回はそこらへんの課題解決に焦点を当てた記事を書きたいと思います。最初から全体最適化を達成するのは困難ですが、一部業務によっては部分最適しやすいものが存在します。 

自社の経営戦略に基づいて全体最適化を達成することが営利企業としての使命になりますが、マクロ目線を持ちつつ部分最適化の積み重ねがあってこそ達成できることだと思います。