経営ダッシュボードに案件別予算を載せる — freee 支出の按分と社内取引

経営ダッシュボードとは、売上・費用・予算の状態を一画面で把握するための仕組みである。会計ソフトの試算表をそのまま眺めても、「どの案件がいくら使い、いくら残っているか」は見えてこない。私は freee 会計の支出データを案件単位に按分し、案件名・勘定科目・月次予算を一覧できる『案件』ダッシュボードを Grafana 上に作った。本記事では、なぜ試算表だけでは足りないのか、実績の整理と予算策定が別の作業であること、取引先別の支出を案件へ按分する考え方、管理部門への社内取引としてチェーンをつなぐ設計までを順に書く。

目次

経営ダッシュボードとは何を可視化するものか

経営ダッシュボードは、経営者が数字を探しに行かなくても見える状態を作るためのものだ。売上、費用、予算、案件別の損益を、同じ画面から同じ粒度で見られるようにする。

重要なのは、会計ソフトの画面をそのまま転写しないことである。freee の試算表は勘定科目ごとの集計には強いが、「この支出がどの案件のものか」という軸を持っていない。だから案件別に見ようとすると、毎回手作業で仕分け直すことになる。

ダッシュボードの価値は、その手作業を一度だけ構造化し、以後は自動で更新されるようにするところにある。帳票を眺める画面ではなく、意思決定の前提を揃える画面として設計する。これが最初に決めた方針だった。

なぜ freee の試算表だけでは案件別に見えないのか

freee は会計帳簿としては十分に強力である。仕訳が正しく入っていれば、勘定科目別の残高も、月次の推移も、そのまま見られる。

しかし、案件という軸は会計の標準的な軸ではない。売上や費用は取引先と勘定科目で記録されるが、「どの案件のために使ったか」は帳簿の必須項目ではないからだ。結果として、案件別の損益は帳簿の外側で組み立てることになる。

ここで起こるのが、毎回の手作業による集計である。手作業は属人化し、更新のたびに同じ判断を繰り返すことになる。だから私は、この集計を一度スクリプトとデータベースに落とし、案件軸を機械的に再現できる形にした。

支出の実績整理と予算策定は別の作業である

ここで最初につまずいた。取引先別に支出を整理し、それをそのまま「案件ごとの数字」として扱おうとしていた。しかし整理したのは実績であって、予算ではなかった。

実績の整理は、過去にいくら使ったかを確定させる作業である。予算策定は、これから何にいくら使う予定かを決める作業である。成果物が違う。前者は確定値の一覧であり、後者は配分の意思決定である。

実績の一覧をダッシュボードに貼っても、予算欄は空のままだ。逆に予算だけを並べても、実績との差が見えなければ意味がない。両方を作って初めて、計画と結果の比較ができる。私はここで一度手を止め、実績の整理と予算の策定を別の工程として分けて進めることにした。

取引先別に支出を並べ、金額の大きい順から着手する

支出の案件化は、取引先別に金額の大きい順から着手した。理由は単純で、効果の大きいところから手を付けるほうが、限られた時間で見える成果が大きくなるからである。

どの取引先に多く払っているかを把握しないと、按分の対象も選べない。上位の取引先から順に、その支出がどの案件のためのものかを確定させていく。下位の少額な取引は、まとめて管理部門の共通費として扱えばよい。

この順序を決めたことで、作業は「全部を一度に正しくする」ではなく「大きな流れから順に確定させる」ものになった。会計の整理は、完璧を最初から狙うと前に進まない。

取引先別の支出を案件へ按分する

そのうえで、各取引先の支出を案件へ割り当てていく。ここで効くのが「按分」の考え方だ。1つの支出が1つの案件にしか属さないなら話は簡単だが、実際にはそうならない。ある取引先への支払いが複数の案件にまたがることは珍しくない。

按分は、金額を分ける作業ではなく、責任の所在を分ける作業である。どの案件がその費用を負担すべきかを決めることが本質だ。

だから按分の根拠は、金額の大きさではなく、実際の利用実態に置く。どのサーバーをどの案件が使っているか、どの作業がどの案件のために発生したか。実態を確認してから、金額を割り振る。順序を逆にすると、辻褄合わせの数字になる。

さくらインターネットの按分を実例で考える

具体的な例を挙げる。さくらインターネットへの支出は一括で発生する。しかし、その中には特定の案件で使うサーバーもあれば、複数の案件で共有しているサーバーもある。

私は、ある案件でさくらの VPS を2台使っている構成を確認し、その2台分を当該案件へ、残りを管理部門や他案件へ割り振る形にした。1つの取引先の支払いが、複数の行に分解されるのである。

この分解があるからこそ、後から「なぜこの案件のサーバー費がこの金額なのか」を説明できる。按分の根拠を残しておくことは、監査にも、来期の予算策定にも効く。

売上側も案件化する — SES は人単位で見る

整理すべきは支出だけではない。売上側も同じく案件化した。ここでは、SES のように人単位で単価が決まる契約を、人ごとの案件として分割した。

たとえば、同じ取引先からの売上でも、担当者ごとに案件を分ける。ある期間はA案件、別の期間はB案件、という具合である。人の入れ替わりがそのまま案件の入れ替わりになるため、案件名で期間を追えるようにしておく。

売上と支出の両方を案件で揃えることで、初めて案件別の損益が見える。片側だけを案件化しても、損益は計算できない。

案件名と勘定科目からフィルターできるようにする

一覧表を作るだけでは、まだ使えない。案件が増え、科目が増えると、表は縦に伸びるだけで見通しが悪くなる。そこで、案件名と勘定科目を軸にフィルターできるようにした。

案件別・科目別の月次予算を、最新の予算版で表示する。案件名と勘定科目にはリンクを付け、そこから内訳へ降りられるようにした。これにより、「ITサポート案件のうちサーバー費用はいくらか」といった一段細かい粒度で確認できる。

粒度を上げる作業は、思った以上に効く。合計だけを見ていると気づかない偏りが、内訳を見た瞬間に露出するからである。ダッシュボードは、見る回数が増えるほど、粒度の粗さが不満になる。

案件予算から管理部門へ社内取引として支出する

ここが設計上、最も考えた部分である。案件の予算から、管理部門へ社内取引のような形で支出する。そうすることで、管理部門が誰から利益を得ているのかを理解できるようにした。

通常の会計では、管理部門の費用は間接費として扱われ、どの案件がそれを負担しているかは見えにくい。しかし、案件ごとに管理部門へ支払う形にすれば、費用の流れが一本の線でつながる。社内で動くお金について、全てチェーンがつながる状態にしたいというのが狙いだった。

この設計にすると、ある案件が実は管理部門のコストに支えられていた、という事実が見える。逆に、ある案件が管理部門へ十分に貢献していないことも見える。数字が意思決定の材料になるのは、この粒度に達してからだと考えている。

予算の版管理 — 最新版を参照する仕組み

予算は一度作って終わりではない。四半期ごとに見直し、修正版が生まれる。ここで問題になるのが、どの版が最新かである。

版が複数ある状態で集計すると、古い数字と新しい数字が混ざり、実態とずれる。そこで、予算データには版の情報を持たせ、参照時は常に最新版を選ぶようにした。修正のたびに過去を上書きするのではなく、版を積み上げる形にしている。

版を残すことには意味がある。なぜその数字に至ったかの履歴が追えるからだ。予算は結果だけでなく、そこに至る判断の記録でもある。

案件軸を持つことの副作用と注意点

案件別予算は強力だが、副作用もある。1つの支出を複数の案件に按分すると、案件ごとの合計は正しくても、全体の合計と一致しなくなるリスクがある。按分率の合計を必ず1にしておくことが前提になる。

また、案件が細かくなりすぎると、管理そのものが負担になる。分析したい粒度と、維持できる粒度は違う。最初から細かく割らず、金額の大きい取引先から順に分解するのが現実的である。

さらに、按分の基準は一度決めたら固定するのが望ましい。期の途中で基準を変えると、前期との比較ができなくなる。基準を変えるときは、その事実も記録に残す。

実装でつまずいた点と対応

技術的なつまずきもあった。まず、ダッシュボードが支出の実績しか表示していなかった点である。整理したのは実績で、予算へ転換できていなかった。予算策定という目的を明確にして、初めて予算欄が埋まった。

次に、データ取得の基盤である。会計データを扱うスクリプトが PostgreSQL へ接続するため、システム側の Python にドライバを導入する必要があった。導入は冪等な Playbook として残し、再実行しても壊れないようにした。

さらに、ダッシュボードの粒度を一段上げる作業もやり直した。当初は案件ごとの合計だけだったが、内訳を表示できるように定義を作り直した。予算の版が複数ある場合は、最新版を参照するようにして、古い数字が混ざらないようにした。

環境によっては、システム側の Python にライブラリを直接入れる判断が必要になることもある。その場合も、手順を Playbook 化しておけば、別の環境へ同じ構成を再現できる。

継続的な運用に向けて — 契約終了とサービス整理

運用の面では、契約を終了した取引先の扱いも整理した。今後費用が発生しない取引先は、按分の対象から外して管理する。これを怠ると、使っていない費用が予算に残り続ける。

使っていないサービスについては、解約の必要性を一覧に残すようにした。営業支援のコンサルティング契約のように、もう支払いが発生しないものは、その事実を記録しておく。記録がないと、来期の予算策定で再び拾い上げてしまう。

ダッシュボードは作って終わりではない。使われなくなった費用を落とし、新しい費用を足し続けることで、はじめて現在の経営を映す。

まとめ — 案件別予算が経営判断に効く理由

案件別予算をダッシュボードに載せると、数字の意味が変わる。合計の損益ではなく、どの案件がどの費用を負担しているかが見えるようになるからである。

実績の整理と予算の策定は別の作業である。取引先別の支出は、案件へ按分して初めて意味を持つ。そして案件から管理部門への社内取引をつなげば、社内のお金の流れが一本のチェーンになる。

経営ダッシュボードは、綺麗なグラフを作るためのものではない。意思決定の根拠を、同じ画面に揃えるための道具である。その粒度に到達して初めて、ダッシュボードは経営の役に立つ。

関連記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

金重総合研究所の主席研究員。
子供の頃から研究者を目指し、ライフワークとして日々様々な研究をしています。
経営・マネジメント・金融・DXあたりが本職です。
私を採用したい人、私と一緒に働きたい人、一緒に知識を肥やしていきたい人はぜひお声がけ下さい。

目次