■ ここまでの整理

ここまでの内容を振り返ります。

• 業務量は売上ではなく構造で決まる
• 事業数・承認・データなどで業務は増える
• その背景には業務設計の不在がある

ではこれらは、実際にはどのようにつながっているのか？

今回はそれを、1つの構造として整理します。

■ 経理が増える会社の共通点

まず前提として、経理が増え続ける会社には共通点があります。

それは、

• 事業が多い
• 管理会計の要求が多い
• データが分断されている
• Excelに依存している

一つひとつはよくある話です。

しかし問題は、これらが“つながっている”ことです。

■ 構造はこうなっている

全体の流れをシンプルにすると、こうなります。

① 事業が増える

新しい事業が増えると、

• 取引
• 契約
• 請求
• 原価管理

がそれぞれ発生します。ここまでは自然な成長です。

② 管理の要求が増える

事業が増えると、

• 事業別に見たい
• 部門別に見たい
• 収益性を細かく見たい

といった管理会計の要求が増えます。

③ データが分断される

しかし多くの会社では、その要求に対して

最初から設計されたデータ基盤がありません。

そのため、

• システムからデータを抜き
• 加工し
• 別の形で集計する

という対応になります。

④ Excelでつなぐ

結果として、

• スプレッドシート
• Excel
• 個別ファイル

で業務がつながれていきます。

短期的にはこれで回ります。しかし、人が処理する構造になります。

⑤ 業務が複雑化する

この状態が続くと、

• データが複数存在する
• 定義が揃っていない
• 数字が合わない

という問題が発生します。

⑥ チェックと調整が増える

その結果、

• 確認
• 突合
• 修正

といった「調整作業」が増えていきます。

⑦ 人を増やすしかなくなる

ここまで来ると、もう打ち手は限られます。

• 人を増やす
• 分業する

つまり、構造的に人員増加が必要になる

■ 全体をまとめると

この流れを一つにすると、こうなります。

事業増加
↓
管理要求増加
↓
データ未整備
↓
Excel運用
↓
業務複雑化
↓
チェック・調整増加
↓
経理人員増加

■ 重要なポイント

ここで一番重要なのは、この流れはどこにも無理がないことです。

すべて自然な意思決定の結果です。

だからこそ、多くの会社で同じことが起きます。

■ もう一段深い問題

そしてもう一つ、見落とされがちなポイントがあります。

それは、管理会計が制度会計の上に乗っている構造です。

• 基幹システム
  ↓
• 制度会計
  ↓
• 管理会計（Excel）

このように、

データを二度加工する構造になると、

• 手作業
• 確認
• 不整合

が必ず発生します。

■ まとめ

経理が増え続けるのは、単に仕事が増えたからではありません。

人を増やさないと回らない構造になっているからです。

■ 前回のおさらい

前回、業務量が売上以上に増える理由として、

• 事業数の増加
• 少額取引の増加
• 承認フローの増加
• データの分断
• ガバナンス強化

という5つの要因を整理しました。

どれも納得感のある話です。しかしここで、もう一つ重要な問いがあります。

■ なぜ、それは止まらないのか？

これらの要因は、多くの会社で発生します。

でも本当に問題なのは、「それが止まらないこと」です。

なぜ、

• どんどん複雑になり
• どんどん業務が増え
• どんどん人が増えるのか

ここを説明しないと、本質にはたどり着きません。

■ よくある対応

実務では、こういう対応が繰り返されます。

• 事業が増えた → とりあえず個別対応
• 管理項目が増えた → Excelで対応
• データが足りない → 手作業で補完

そして問題が起きると、

• チェックを増やす
• 承認を増やす
• 人を増やす

一つひとつは合理的です。しかし、これを積み重ねるとどうなるか。

■ 気づかないうちに起きていること

結果として起きているのは、「業務設計が存在しない状態」です。

本来、業務は

• どういう単位で管理するのか
• どこまで標準化するのか
• どのデータを正とするのか

といった設計が必要です。

しかし現実は、その都度の対応で積み上がる。

つまり、設計ではなく“対応の集合体”になっているのです。

■ なぜそれが危険なのか

この状態になると、業務は次のように変化します。

• 事業ごとにルールが違う
• 同じデータが複数存在する
• どこが正しいか分からない
• 確認・調整が増える

結果として、「処理」ではなく「調整」が仕事になる

■ そして起きること

この状態では、システムでは解決できません。

なぜなら、システムは「設計」を前提にしているからです。

設計がない状態でシステムを入れると、

• 無理やり合わせる
• 結局Excelが残る
• さらに複雑になる

という悪循環になります。

■ 本当の因果関係

ここまでを整理すると、本当の構造はこうです。

事業増加
↓
個別対応
↓
ルール未整備
↓
Excel運用
↓
業務複雑化
↓
チェック増加
↓
人員増加

つまり、

問題は業務量ではなく、業務の作り方です。

■ 多くの会社が気づいていないこと

重要なのは、この状態は「自然にそうなる」ことです。

誰かが間違えたわけではない。

むしろ、現場は合理的に動いています。だからこそ怖い。

気づいたときには、戻れないレベルで複雑になっています。

■ まとめ

本当の原因は、取引数でも承認フローでもありません。

業務設計がないことです。

そしてそれが、業務を増やし続ける構造を作っています。

■ 前回のおさらい

前回、業務量は「取引数」ではなく、業務の構造で決まるという話をしました。

つまり、売上が同じでも構造によって業務量は何倍にもなる。

では実際に、業務量が売上以上に増えてしまう原因は何か？

今回はここを具体的に見ていきます。

■ 理由①：事業数が増える

まず一番大きいのがこれです。

事業数の増加

多くの会社は、売上ではなく事業の数に比例して仕事が増えます。

例えば、

• 1事業 → 請求1つ、契約1つ
• 100事業 → 請求100、契約100

売上が同じでも、事業が増えれば業務は指数的に増えていきます。

■ 理由②：少額取引が増える

次に多いのが、

取引の粒度が細かくなること

特にデジタル系の事業では、

• 少額決済
• 広告課金
• ポイント処理

などが大量に発生します。

例えば、1億円の売上でも

• 1億円 × 1件
• 100円 × 100万件

では、業務量はまったく違います。

■ 理由③：承認フローが増える

会社が大きくなると、チェックや承認が増えます。

例えば、

• 申請
  → 上長
  → 部門長
  → 経理
  → 役員

1つの取引でも、複数の作業に分解される ようになります。

結果として、

件数は同じでも業務量は何倍にも膨らみます。

■ 理由④：データが一度で使えない

これも非常に多いです。

データが整流化されていない状態

例えば、

• 基幹システム
• 会計システム
• 管理会計用データ

それぞれで

• 加工
• 転記
• 確認

が発生する。つまり、同じデータを何度も触っている 状態です。

これは業務量を爆発させる典型パターンです。

■ 理由⑤：ガバナンスが強化される

会社が成長すると、当然ながら

• 内部統制
• 証憑管理
• 監査対応

が求められます。

これは必要なことですが、同時にチェック業務が増えることを意味します。

つまり、「安全性」と引き換えに業務量が増えていく構造です。

■ ここまでをまとめると

これら5つの要因はすべて、売上とは直接関係がありません。

しかし、確実に業務量を増やします。

整理するとこうなります。

• 事業数が増える
• 取引が細かくなる
• 承認が増える
• データが分断される
• チェックが増える

これらが重なると、業務量は売上を簡単に超えていきます。

■ 重要なポイント

ここで重要なのは、これらはすべて自然に発生するということです。

つまり、何もしないと必ずこうなる。

だから多くの会社で、

• 人が増え続ける
• 業務が重くなる

という現象が起きます。

■ まとめ

業務量が増えるのは、売上が伸びたからではありません。業務が増える“構造”が積み上がるからです。

■ 前回のおさらい

前回、「取引が増えたから人が増えた」という説明は本質ではない、という話をしました。

なぜなら、

• 取引が増えた
• 業務量が増えた
• 人が増えた

これは単なる現象の説明だからです。

本当に重要なのは、

「なぜそうなるのか？」

という原因の部分です。

■ 多くの会社が見ているもの

多くの会社は、こう考えます。

• 取引数が増えている
• 申請件数が増えている
• 処理が追いつかない

だから、人を増やすしかない

これは一見、合理的です。しかしここには、大きな落とし穴があります。

■ 見ているものが“浅い”

この考え方は、「表に見えている数字」しか見ていない

という問題があります。

例えば、

• 取引数
• 申請件数
• 仕訳数

これらはすべて“結果”です。

しかし本来見るべきなのは、その裏にある

「業務の作り方」

です。

■ 構造で見るとはどういうことか

ここで重要なのが、

「構造で考える」という視点です。

構造とは、

• どういうルールで業務が発生し
• どういう流れで処理され
• どこで手間が増えているか

という“仕組み”のことです。

■ 同じ売上でも、業務量は全く変わる

例えば、次の2つの会社を考えてみてください。

A社

• 3つの事業
• ルールは統一
• システムで一括処理

B社

• 100の事業
• 事業ごとにルールが違う
• Excelで個別対応

売上が同じだとしても、どちらの会社の方が忙しいかは明らかです。

当然、B社です。

■ 何が違うのか

この違いは、取引数ではありません。

違いはこれです。

• 事業の数
• ルールの統一度
• データの流れ
• 処理の方法

つまり、業務の構造そのもの

です。

■ 業務量はこうやって決まる

業務量は単純な件数ではなく、次の掛け算で決まります。

業務量 ＝ 件数 × 複雑さ × 手作業率

例えば、

• 件数が同じでも
• 承認が3段階あれば3倍
• データ加工があればさらに増える

このように、構造が変わるだけで業務量は簡単に何倍にもなります。

■ なぜ構造が崩れるのか

ではなぜ、こうした構造になるのか。

多くの場合、原因はシンプルです。

• 事業が増える
• 個別対応で乗り切る
• ルールを統一しない
• Excelでつなぐ

これを繰り返すと、気づかないうちに “複雑で戻れない構造” ができあがります。

■ まとめ

問題は「取引数」ではありません。

本当の問題は、業務が増え続ける“構造”ができていること です。

そしてこの構造は、放っておくと必ず人を増やし続ける方向に働きます。

■ よくある説明

前回、こんな話をしました。

売上が伸びているのに会社は楽にならない。

むしろ、

• 管理部門が増える
• 経理が膨らむ
• 業務がどんどん重くなる

こうした現象が起きます。

そしてこのとき、よく使われる説明がこれです。

• 取引が増えたから
• 申請が増えたから
• 業務量が増えたから

だから「人を増やすしかない」

一見すると、正しい説明に見えます。

■ この説明の“違和感”

ただ、この説明には重要な問題があります。

それは、

「なぜ取引が増えたのか」を説明していないことです。

つまり、

取引が増えた
↓
業務量が増えた
↓
人が増えた

という流れは、

現象の説明であって、原因の説明ではない

ということです。

■ 極端な話をすると

もしこのロジックが正しいなら、

会社は成長するほど
必ず非効率になります。

なぜなら、

売上が増える
↓
取引が増える
↓
人が増える

が止まらないからです。

つまり、

成長＝人が増え続ける構造

になります。

でも、これは本来おかしい。

企業は本来、

• 規模が大きくなるほど効率化し
• 同じ人数でより多くの仕事をこなせる

ようになるはずです。

■ 本当に考えるべき問い

ここで立てるべき問いは、これです。

「なぜ取引は売上以上に増えるのか？」

ここを説明しない限り、

• 業務量の増加も
• 人員増加も

本質的には理解できません。

■ 実務でよく起きていること

実際の現場では、取引が増えているのではなく、

“取引の増え方”が変わっています。

例えば、

• 1つの売上が細かく分割される
• 少額の取引が大量に発生する
• 同じ取引に複数の承認が入る

こうなると、

売上はそれほど増えていなくても
処理すべき件数だけが増えていきます。

つまり、

売上と業務量の関係が崩れている

状態です。

■ さらに見落とされがちな点

もう一つ重要なのは、
業務量は「取引数」だけでは決まらない

ということです。

例えば同じ1件の取引でも、

• 承認が3回ある
• データを2回加工する
• 別システムに転記する

これだけで、

実質的な作業は5倍以上になります。

つまり、

• 件数 × 処理の複雑さ

で業務量は決まります。

しかし多くの説明は、「件数」しか見ていません。

■ まとめ

「取引が増えたから人が増えた」

これは間違いではありません。

ただし、

それだけでは何も説明していないのと同じです。

本当に見るべきなのは、

• なぜ取引が増えるのか
• なぜ処理が複雑になるのか

という“構造”です。

売上が増えれば、利益も増え、人も増える・・・だから本来は、「会社はどんどん回りやすくなる」はずです。

■ でも現実は、なぜか逆になる

実際の現場では、よくこんな声を聞きます。

• 「人は増えているのに楽にならない」
• 「むしろ前より大変になっている」
• 「管理部門ばかり増えている」

特に多いのがこれです。

「売上は伸びているのに、経理や管理部門が膨らみ続ける」

しかもその増え方は、売上以上のペースです。

つまり、

• 売上は1.2倍
• でも経理は1.5倍

のようなことが普通に起きます。これは一見、違和感のある現象です。

■ よくある“説明”

こういう状況になると、よくこんな説明がされます。

• 取引が増えたから
• 申請が増えたから
• 業務量が増えたから

そして結論はこうなります。

「だから人を増やすしかない」

たしかに、現場感としては間違っていません。忙しいから人を増やす。これは自然な判断です。

■ でも、その説明は本当に十分か？

ここで、少し立ち止まって考えてみてください。

もしこの説明が本当に正しいなら、売上が伸びれば伸びるほど会社は、どんどん重くなるはずです。

つまり、

• 成長するほど非効率になる
• 大きい会社ほど運営が大変になる

ということになります。

しかし、これはどこかおかしい。本来、企業は成長するほど

• 標準化が進み
• 効率が上がり
• 生産性が上がる

はずです。それなのに、なぜ現実は逆になるのでしょうか。

■ 本当に知るべき問い

ここで重要なのは、次の問いです。

「なぜ業務量は売上以上に増えるのか？」

多くの説明は

• 業務量が増えた
• だから人が増えた

で終わります。

しかしこれは、原因ではなく“結果の説明”です。

本来考えるべきは、

• なぜ取引は増えるのか
• なぜ申請は増えるのか
• なぜ業務は複雑になるのか

という“構造”の部分です。

■ 実は、問題はもっと深い

実務で多くの会社を見ていると、本当の問題は別のところにあります。

それは

「会社の構造」そのものです。

例えば、

• 事業が増えるたびに業務も増える
• 部門ごとにルールがバラバラ
• データが一度で使えず、何度も加工される
• システムではなくExcelで対応している

こういった状態が積み重なると、気づかないうちに

業務が増え続ける“仕組み”

が出来上がってしまいます。

■ まとめ

売上が伸びても会社が楽にならないのは、単に仕事が増えたからではありません。

仕事が増え続ける「構造」があるからです。

そしてこの構造は、

多くの会社で気づかれないまま放置されています。

• ACCESS再構築
• Excel × PowerQuery
• Kintone
• Power BI
• ERP

を整理してきました。最終回は、最も重要な問いに答えます。結局、どれを選ぶべきか。

まず結論：判断軸は2つある

ツール選定の本質は、

① 原価構造の複雑性
② データ量と利用環境

この2つです。売上規模ではありません。従業員数でもありません。

判断軸①：原価構造の複雑性

次の問いにいくつ「YES」がつくでしょうか。

• 多品種少量生産である
• 製番数が多い
• 部門間配賦が多段階
• 標準原価差異を厳密管理したい
• 拠点が複数ある
• 在庫評価が重要
• 上場や監査対応を視野に入れている

YESが多いほど、原価制度は複雑です。複雑性が高い企業は、簡易的な仕組みでは運用が破綻します。

判断軸②：データ量と利用環境

もう一つの軸が、データ量です。例えば、

• 月間製番数は何件か
• 工数データは月何行か
• 原価明細は年間何行か
• 同時利用者は何人か
• リアルタイム共有が必要か

仮に原価構造がシンプルでも、

• 月数十万行の実績データ
• 利用者が20人以上
• 拠点間同時接続

といった環境では、ExcelやACCESSでは限界が見えます。

逆に、原価構造が多少複雑でも、データ量が限定的で利用者が少数なら、Power BIやACCESSで十分運用可能な場合もあります。

複雑性 × データ量で整理すると

イメージとしては、次のように整理できます。

■ 複雑性：低 × データ量：少

→ ACCESS再構築
→ Power BI単体構築
→ Excel運用

現実的でコスト効率が良い。

■ 複雑性：中 × データ量：中

→ Power BI＋基幹データ連携
→ 設計見直し型ACCESS
→ クラウド基盤＋集計設計

設計力が重要。

■ 複雑性：高 × データ量：多

→ ERP検討が現実的

このゾーンで簡易ツールに固執すると、必ず再構築になります。

ツール選定の本質

重要なのは、「何が流行っているか」ではなく、

• 自社の原価制度の複雑さ
• データのボリューム
• 利用者環境

に対して、過不足のない選択をすることです。過小投資は再構築リスク。過大投資はコスト負担。どちらも経営にとっては損失です。

最後に

原価計算システムの選定は、ITの話ではありません。経営基盤の設計です。

• どこまで精緻に把握するのか
• どの頻度で意思決定に使うのか
• どのレベルまで将来拡張するのか

その答えが決まれば、ツールは自然に絞られます。複雑性とデータ量。この2軸で一度、自社を整理してみてください。

そこからが、本当のスタートです。

「可視化ができる」
「分析に強い」
「DAXで計算できる」

では、Power BIは原価計算システムの代替になり得るのでしょうか。結論から言えば、条件付きで可能です。ただし、向いているケースと向いていないケースがあります。

Power BIは本来、分析ツール

まず前提です。Power BIは、

• データを取り込み
• モデル化し
• 可視化・分析する

ためのツールです。ERPのような基幹システムではありません。しかし、DAXという計算言語を使えば、

• 原価集計
• 製番別損益計算
• 差異分析

も実装できます。つまり、「計算できない」のではなく、「何をどこまで計算するか」が重要なのです。

個別原価計算なら十分現実的

特に向いているのは、個別原価計算（製番別原価）です。

例えば、

• 製番ごとの材料費
• 工数実績
• 外注費
• 共通費の単純配賦

といった構造であれば、Power BIで十分構築可能です。

データを

• 生産管理システム
• 会計システム
• 工数管理データ

から取り込み、モデル化し、製番別に集計する。このレベルであれば、現実的です。

向いていないケース

一方、次のような場合は難易度が上がります。

• 多段階配賦（部門→工程→製品）
• 標準原価差異の厳密管理
• 仕掛品の詳細評価
• 月次締め処理としての確定ロジック

Power BIは「確定処理」よりも「動的集計」に向いています。そのため、財務確定ロジックの中核を担わせる設計は慎重にすべきです。

一つに絞るならどう考えるか

現実には、ACCESSもERPもKintoneもPower BIも並行利用する、というのは中小企業では現実的ではありません。多くの場合、どれか一つに絞って再構築することになります。

その場合、判断軸はこうなります。

■ Power BIを選ぶべき会社

• 生産管理システムは既にある
• 原価データは取得できている
• 個別原価中心
• 経営分析を強化したい
• ITリテラシーが一定ある

この場合、Power BIは「原価計算＋経営分析」を一体で実現できる選択肢になります。

■ その他を選ぶべき会社

• 全社統合をしたい
• 内部統制を強化したい
• 上場を視野に入れている
• 拠点が多い

この場合、Power BI単独では足りません。

設計のポイント

Power BIで原価計算を行う場合、重要なのはデータモデル設計です。

• 製番テーブル
• 実績明細テーブル
• マスタテーブル
• 配賦基準テーブル

を明確に分ける。

リレーションを整理し、

• 計算列を乱立させない
• DAXを過度に複雑化しない

ことが鍵になります。設計を誤ると、「動くが誰も触れないシステム」になります。

最大の強みは経営直結

Power BIで原価計算を構築する最大の利点は、そのまま経営ダッシュボードになることです。

• 製品別採算
• 顧客別利益
• 月次推移
• 赤字製番ランキング

が即座に可視化される。計算と分析が一体化する。これは大きなメリットです。

まとめ

Power BIは、

• 大規模・複雑な原価制度向きではない
• しかし、個別原価中心の企業には十分現実的

という位置づけです。重要なのは、「Power BIは分析ツールだからダメ」と切り捨てることではなく、自社の原価構造に合うかどうかを冷静に判断することです。

次回はシリーズ最終回として、「結局どの選択肢を選ぶべきか」を整理します。

ツールではなく、

• 自社の規模
• 生産形態
• 将来像

から逆算する判断軸を提示します。原価計算は、システム選びではなく、経営設計です。

• ACCESS再構築
• Excel × PowerQuery

という選択肢を整理してきました。今回は、クラウド業務基盤であるKintoneを活用するケースを考えます。

ただし最初に強調しておきます。Kintoneは「原価計算専用システム」ではありません。あくまで、業務アプリを構築するための基盤です。

Kintoneは“計算ツール”ではなく“業務基盤”

Kintoneでできることは、

• データベース構築
• 入力画面設計
• ワークフロー設計
• 権限管理
• クラウド共有

です。

つまり、原価を計算する仕組みというより、原価データを整備する仕組みに向いています。

典型的な活用パターン

実務で多いのは、次のような構成です。

• 既に生産管理システムがある
• そこから実績データを出力する
• Kintoneに取り込む
• 少数ユーザー（経理・管理部門）が原価集計を行う

このように、原価計算専用の管理基盤として限定利用するという使い方です。この場合、全社利用ではないため、比較的導入しやすくなります。

ランニングコストという現実

Kintoneはユーザー課金型です。利用者が増えるほど、月額コストは積み上がります。

例えば、

• 全社展開する
• 現場全員が工数入力する

という設計にすると、ランニングコストは無視できません。一方、

• 原価管理担当者のみ利用
• 入力は既存システムから連携

という構成であれば、コストは抑えられます。つまり、Kintoneは利用範囲の設計が極めて重要なのです。

大量データ処理の制約

もう一つ重要な論点があります。Kintoneはクラウド型データベースですが、

• レコード数上限
• パフォーマンス制約
• 大量データの一括処理の制限

があります。月数十万件〜数百万件規模の実績データをそのまま蓄積・計算する用途には向きません。そのため、

• 生データは別DBで管理
• 集計済データのみKintoneに取り込む

といった設計が必要になります。

どんな企業に向いているか

Kintoneが適しているのは、次のような企業です。

• 原価以前に業務フローが整理されていない
• 製番管理や承認フローを整備したい
• クラウド化を進めたい
• 原価管理は少人数で行う
• 生産管理システムは既に存在する

この場合、Kintoneは 原価の計算エンジン”ではなく、原価の業務管理基盤として機能します。

向いていないケース

逆に、次のような場合は注意が必要です。

• 全社員が常時利用する設計
• 月数十万件以上の実績データを直接扱う
• 多段階配賦や高度な原価差異分析を内部完結させたい
• ERP並みの統合管理を期待する

この場合、過剰投資または機能不足になる可能性があります。

Kintoneの本質的価値

Kintoneの価値は、原価を高度に計算することではなく、原価データの発生源を整えることにあります。

• 製番登録の統一
• 工数入力のルール化
• 外注管理の明確化
• 承認フローの標準化

これらが整えば、原価の精度は自然と上がります。

結局、どう位置づけるべきか

Kintoneは、

• ERPの代替ではない
• Excelの上位互換でもない

あくまで、業務を整理するためのクラウド基盤です。原価計算単体で考えるのではなく、業務フロー全体を見直す企業には強力な選択肢になります。

次回は、「PowerBIは原価計算ではなく原価分析向き」というテーマで整理します。

原価をどう算出するかではなく、どう経営判断に活かすか。シリーズはいよいよ経営活用の領域に入ります。

「ERPを入れるべきか？」
「クラウドに移行すべきか？」

しかし、実務で最も有効な第一歩は、意外にも Excel × PowerQuery であることが少なくありません。

今回は、その現実的な使い方と限界を整理します。

なぜExcelが現実的なのか

中小製造業において、Excelはすでにインフラです。

• 現場も使える
• 経理も使える
• データもExcelで出てくる

新しいツールを導入するよりも、心理的ハードルが圧倒的に低い。さらにPowerQueryを使えば、

• データの自動取得
• データ整形
• マスタとの結合
• 集計処理の自動化

が可能になります。もはや単なる表計算ソフトではありません。

本当の目的は「完成」ではなく「分解」

ここで重要なのは、Excelで原価計算を完成させることが目的ではないという点です。目的は、ブラックボックス化した原価ロジックを一度分解すること です。

例えば、

• 材料費はどこから来ているのか
• 工数データはどう取り込まれているのか
• 間接費はどの基準で配賦されているのか
• どこで手修正が入っているのか

これらを一つ一つ、PowerQueryで見える形にしていく。すると、

• 不要な二重処理
• 根拠不明の按分
• 属人化したExcel補正

が浮き彫りになります。この「見える化」こそが最大の価値です。

ただし、Excelはデータベースではない

ここは重要な注意点です。Excel＋PowerQueryは、リレーショナルデータベースではありません。ACCESSやSQL Serverのように、

• 主キー・外部キー制約
• 参照整合性の強制
• データ入力時の制御

といった機能は持っていません。PowerQueryでテーブルを結合することはできますが、

• マスタが削除されても警告は出ない
• 重複キーがあっても自動的に止まらない
• データ整合性は設計者に依存する

という構造になります。つまり、整合性は守られるのではなく、守る必要があるという点が根本的な違いです。

どこまでなら現実的か

実務上、次の規模感であればExcelは十分有効です。

• 月間製番数が数百レベル
• 実績データが月数万行程度
• 利用者が限定的（数名）
• 主に分析・再設計目的

この範囲であれば、PowerQueryは非常に強力です。しかし、

• 多人数同時利用
• 入力系システムとしての運用
• リアルタイム拠点共有
• 厳密なデータ統制

が必要な場合、Excelは適していません。

Excel活用の正しい位置づけ

Excelは「最終形」ではなく、再設計のための中間地点であることが多いのです。一度Excelでロジックを分解し、

• そのまま小規模運用する
• ACCESSを再設計する
• クラウド基盤に移行する
• ERPへ統合する

といった次の一手を判断する。いきなり大規模投資をするより、失敗確率は大きく下がります。

最大の価値は原価の流れが見えること

原価は、

• どこからデータが来て
• どこで加工され
• どの基準で配賦され
• どう集計されているか

が見えなければ、正しい議論ができません。

Excel × PowerQueryは、この流れを一度“見える形”にするための最適な道具です。

次回は、「Kintoneなどクラウド業務基盤で原価管理を構築する」というアプローチを整理します。原価計算を単体で考えるのではなく、業務全体の流れの中で再設計する方法です。

システム刷新の成否は、ツールではなく、設計思想で決まります。