――会計ソフト時代に忘れられた「信用を記録する」という視点
中世ヨーロッパ発、複式簿記という信用の技術

会計を「税金のため」だけに考えてよいのか

複式簿記は、中世ヨーロッパ、とりわけイタリアの商業都市で発展してきた記録技術です。

現代では、会計というと「税務申告のための処理」「会計ソフトへの入力」「税理士さんに渡す資料」といった印象が強いかもしれません。

しかし、複式簿記の歴史をたどると、会計は税金のためだけに生まれたものではないことが分かります。

中世の商人たちは、遠く離れた地域と取引し、代理人を使い、複数の商品を扱い、債権と債務を管理しながら商売をしていました。

誰にいくら貸しているのか。
誰にいくら支払う必要があるのか。
どの商品が動いているのか。
どこに財産があるのか。
どの取引が利益につながったのか。
代理人や共同事業者に任せた仕事は、正しく行われているのか。

こうしたことを記憶や口約束だけで管理することはできません。

商売が大きくなればなるほど、取引を記録し、あとから確認し、必要に応じて他者へ説明できる仕組みが必要になります。

そのために発展してきたのが、複式簿記という記録技術でした。

つまり複式簿記は、単なる計算方法ではありません。
商人が自分の商売を把握し、取引相手との約束を記録し、自分の信用を説明するための技術だったのです。

会計ソフト市場は、すでに成熟している

現在の会計ソフト市場には、多くの優れたサービスがあります。

銀行口座との連携。
請求書の発行。
領収書の保存。
税理士との共有。
インボイス制度への対応。
電子帳簿保存法への対応。
決算や申告作業の効率化。

こうした機能は非常に便利です。
会計ソフトを使うこと自体が悪いわけではありません。

むしろ、定型的な処理を効率化する道具として、会計ソフトは大きな価値を持っています。

ただし、会計ソフト市場が成熟しているからこそ、私たちは改めて問い直す必要があります。

会計とは、入力を楽にするためだけのものなのでしょうか。
会計とは、税務処理を済ませるためだけのものなのでしょうか。
会計とは、標準的な画面に会社の出来事を入力するだけで足りるものなのでしょうか。

複式簿記の歴史を振り返ると、会計の本来の役割はもっと広いものだったはずです。

会計とは、会社の出来事を記録し、会社の状態を説明し、信用を積み上げるための仕組みです。

複式簿記は、信用を記録する技術だった

中世ヨーロッパの商人にとって、信用は商売の土台でした。

遠隔地との取引では、相手を直接見て判断できるとは限りません。
すべての取引をその場で現金決済できるわけでもありません。
代理人や共同事業者に仕事を任せることもあります。
商品が動き、お金が動き、債権と債務が発生します。

その中で、何が起きたのかを記録できなければ、商売は広がりません。

記録があるから、あとで確認できます。
記録があるから、相手に説明できます。
記録があるから、間違いや不正に気づけます。
記録があるから、自分の財産と負債を把握できます。
記録があるから、次の取引や投資を判断できます。

この意味で、複式簿記は「信用を記録する技術」だったと言えます。

そして現代の会社においても、この本質は変わっていません。

会計は、経営判断のために使われます。
投資判断のために使われます。
融資判断のために使われます。
税務処理のために使われます。
与信判断のために使われます。
内部統制や不正防止のために使われます。
予算管理や原価計算のために使われます。
資金繰り管理のために使われます。
事業承継やM&A、企業価値評価のために使われます。
補助金、助成金、許認可、入札のためにも使われます。
そして、経営者が説明責任を果たすためにも使われます。

つまり会計とは、会社の信用を支える記録なのです。

---

設計を省略した安さは、将来の高額請求書になる

システム開発の見積もりを取ると、よくこういう話になります。

「A社はこの金額でした」
「B社はもっと安くできますと言っています」
「うちではこの金額でできますよと言われました」

中小企業にとって、初期費用を抑えたいのは当然です。
限られた予算の中で事業を回している以上、安い見積もりに魅力を感じるのは自然なことです。

ただし、ここで一つ注意しなければならないことがあります。

その安さは、
範囲を明確に絞った安さなのか。

それとも、
設計を省略した安さなのか。

この二つは、まったく別物です。

小さな試作品、短期間だけ使うツール、社内の簡単な補助アプリであれば、安く作ること自体は悪くありません。
むしろ、目的を絞って素早く作ることが有効な場面もあります。

しかし、会社の業務、会計、顧客情報、社員情報、権限管理、承認経路に関わるようなシステムを、同じ感覚で選んでしまうと危険です。

安い見積もりに、将来の設計費は含まれているのか

安い見積もりの中に、将来のことまで考えた設計費が含まれている可能性は、決して高くありません。

たとえば、次のようなことまで考えられているでしょうか。

将来、部署が増えたときに対応できるか。
拠点が増えたときに無理なく拡張できるか。
社員の権限が増えたときに安全に管理できるか。
会計処理と業務データをどうつなぐか。
ログをどこまで残すか。
外部の税理士、社労士、データベース専門家、セキュリティ担当者と連携しやすい構造になっているか。
将来、生成AIにコードや構造を読み取らせて改善できる形になっているか。

こうした設計判断は、画面を一つ作るだけなら表に出てきません。
しかし、会社が成長し、業務が増え、関わる人が増えたときに、一気に重要になります。

ソフトウェア工学の分野では、短期的には都合のよい設計・構築方法であっても、後から同じ作業を行う際にアーキテクチャ上の手戻りが必要になり、結果として今対応するより高くつく状態を「アーキテクチャ上の技術的負債」として扱います。

つまり、安く早く作るために省略された設計判断は、消えてなくなるわけではありません。
後から改修費用、調査費用、保守費用、作り直し費用として戻ってくることがあります。

設計を省略したシステムは、最初は安く見える

設計を省略したシステムは、最初は安く見えます。
画面も動きます。
入力もできます。
帳票も出るかもしれません。

しかし、後から変更しようとしたときに問題が表面化します。

「この権限追加は大きな改修が必要です」
「この構造では部署別管理に対応できません」
「会計連携は最初から考えていないので作り直しに近くなります」
「ログが足りないので、過去の処理を追跡できません」
「データ移行が必要になります」
「このまま拡張するとセキュリティ上の問題が出ます」

このとき初めて、安く作った理由が見えてきます。

それは、本当に効率よく作られていたのではなく、
将来必要になる設計判断が先送りされていただけだった
ということです。

IBMも、技術的負債について、ソフトウェア開発中の近道や最適ではない判断に頼った結果として将来発生するコストであり、後からリファクタリング、デバッグ、継続的な保守によって返済が必要になるものだと説明しています。

これは、企業の業務システムにとって非常に重要な考え方です。

最初に安く作れたとしても、その安さが「必要な設計を省略した安さ」であれば、会社が成長した瞬間に高額な改修費として戻ってくる可能性があります。

安い開発会社が悪いわけではない

もちろん、安い開発会社がすべて悪いわけではありません。
また、高い見積もりなら必ず良い設計がされている、というわけでもありません。

大切なのは、金額そのものではなく、
その金額の中に何が含まれていて、何が含まれていないのか
を見抜くことです。

安いシステムが悪いのではありません。
問題なのは、安さの理由が分からないまま発注してしまうことです。

範囲を明確に絞った安さであれば、それは合理的です。
しかし、設計を省略した安さであれば、それは将来の改修費用を先送りしているだけかもしれません。

システム設計とは、今の開発費を無駄に増やすためのものではありません。
会社が成長したときに、改修費用が爆発しないようにするための経営上の保険です。

会社の中核システムほど、最初の設計判断が重要になる

特に、業務会計システムのように会社の中核に関わる仕組みでは、最初の設計判断が将来の自由度を大きく左右します。

どの情報を会社全体で持つのか。
どの情報を部署ごとに持つのか。
どの権限をどのアプリケーションで扱うのか。
会計処理をどの段階で組み込むのか。
外部専門家が確認しやすい構造になっているのか。
将来の分社化、拠点追加、事業拡張に耐えられるのか。

こうしたことは、発注時点で経営者がまったく理解していないと、開発会社任せになります。

そして、開発会社は基本的に、依頼された範囲のものを作ります。
経営者が将来の成長や運用方針を伝えなければ、そこまで踏み込んだ設計にはなりにくいのです。

経済産業省が取りまとめた「レガシーシステムモダン化委員会総括レポート」でも、DXやレガシーシステムの問題と対処の方向性が整理されています。同レポートは、経済産業省、デジタル庁、IPAを事務局とする委員会での議論をもとにまとめられたものです。

このような資料が示しているのは、システムの問題は単なるIT部門だけの問題ではなく、経営課題そのものだということです。

経営者はプログラマーになる必要はない

中小企業の経営者は、プログラマーになる必要はありません。

しかし、システム設計の考え方を知っておく必要はあります。

コードを書けるかどうかよりも、
自社の業務をどう構造化するのか。
どこを内製し、どこを外部専門家に任せるのか。
どの部分を将来変更できるようにしておくのか。
その判断ができることの方が、はるかに重要です。

安い見積もりを選ぶこと自体が悪いのではありません。

しかし、
安さの中身を見抜けないまま選ぶこと
これは、将来の自社に高額な請求書を送っているのと同じです。

これからの中小企業に必要なのは、単に安い業者を探す力ではありません。

安い理由を確認できる力。
設計が省略されていないかを見抜く力。
自社の成長に必要な構造を考える力。
そして、外部の専門家を正しく使いこなす力です。

システムは、会社の頭脳です。
その頭脳を、初期費用だけで選んでよいのか。

一度立ち止まって考える価値があります。

まとめ

安いシステム開発費が悪いのではありません。

本当に怖いのは、
何が省略されて安くなっているのかを知らないまま発注してしまうこと
です。

範囲を絞った安さなのか。
設計を省略した安さなのか。

この違いを見抜けるかどうかで、将来の改修費用は大きく変わります。

会社の業務、会計、顧客情報、社員情報、権限管理に関わるシステムは、単なる便利ツールではありません。
会社の成長を支える土台です。

だからこそ、経営者自身がシステム設計の考え方を知り、外部の専門家を正しく使いこなすことが重要になります。

---

出典・参考資料

経済産業省
「レガシーシステム脱却に向けた『レガシーシステムモダン化委員会総括レポート』を取りまとめました」

経済産業省／IPA
「DXの現在地とレガシーシステム脱却に向けて――レガシーシステムモダン化委員会総括レポート」

CMU Software Engineering Institute
「Architectural Technical Debt Library」

IBM
「What is Technical Debt?」

CISQ
「Technical Debt Standard」