■ ここまでのまとめ

これまで見てきた通り、経理や管理部門が増え続ける原因は、

• 取引数の増加ではなく
• 業務量の増加でもなく

「業務が増え続ける構造」にありました。

そしてその背景には、

• 事業の増加
• 管理要求の増加
• データ未整備
• Excel依存

がありました。

■ では、どうすればいいのか？

ここで重要なのは、「人を減らす」ことではありません。本当にやるべきことは、構造を変えることです。

■ 違い①：事業と業務の関係を設計しているか

増え続ける会社は、事業が増えるたびに業務もそのまま増えます。

一方で、減らせる会社は違います。

• どの単位で管理するか
• どこまで個別対応を許すか

をあらかじめ決めています。

つまり、事業と業務の関係を設計しています。

■ 違い②：データを一度で使えるか

多くの会社では、

• 基幹
• 会計
• 管理資料

とデータが分断されています。

そのため、何度も加工が発生します。

一方で、うまくいっている会社は、データを一度で使える形にしています。

• 入力は一度
• 出力は多用途

この状態を作っています。

■ 違い③：Excelを補助にしているか、主役にしているか

増え続ける会社は、Excelが業務の中心です。

• 加工
• 集計
• 管理

すべて人がやる。

一方で、減らせる会社は違います。

• Excelは補助
• 本体は仕組み

つまり、人ではなく構造で処理します。

■ 違い④：ルールを増やしているか、減らしているか

問題が起きると、多くの会社は

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

方向に進みます。これは短期的には正しい。しかし長期的には、業務を確実に増やします。

一方で、うまくいっている会社は、ルールを減らす努力をします。

• 標準化する
• 例外を減らす
• 判断を減らす

■ 違い⑤：システムを入れているかではない

よくある誤解があります。「システムを入れれば解決する」。これは半分正しく、半分間違いです。

なぜなら、設計がないままシステムを入れても、何も変わらないからです。

• 無理に合わせる
• Excelが残る
• むしろ複雑になる

これはよくある失敗です。

■ 本当に必要なもの

では何が必要か。それは、業務設計です。

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

これを決めること。これがないと、どんなシステムも機能しません。

■ まとめ

経理を減らす会社と、増え続ける会社の違いは、能力でも努力でもありません。構造です。

• 人で回す会社
• 仕組みで回す会社

この違いが、時間とともに大きな差になります。

■ シリーズを終えて

このシリーズでは、「なぜ会社は成長すると非効率になるのか」をテーマに、

• 現象
• 原因
• 構造
• 解決

を順に整理してきました。もし今、

• 人が増え続けている
• 業務が重くなっている
• Excelが増え続けている

という状況であれば、それは個別の問題ではなく、構造の問題かもしれません。

「可視化ができる」
「分析に強い」
「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は原価計算ではなく原価分析向き」というテーマで整理します。

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

• ACCESS再構築
• Excel（PowerQuery）
• クラウド基盤（Kintoneなど）
• ERP統合

その中でも、最も現実的で、実際に多くの企業が検討するのが「今のACCESSを作り直す」という選択です。

これは妥当な判断なのか。それとも将来に禍根を残すのか。今回はその論点を整理します。

ACCESSは本当に“時代遅れ”なのか？

まず前提として整理しておきたいのは、

ACCESS＝時代遅れ、ではないということです。年商数十億円規模の中小製造業であれば、次のような条件下では、ACCESSは十分に実用的です。

• 製品点数が数百〜数千程度
• 月間製番数が数百レベル
• 工数データが月数万行程度
• 同時利用者が5名以内

この規模感であれば、設計が適切なら大きな問題は起きません。実際、安定稼働している企業は数多くあります。問題は「ACCESSだからダメ」なのではなく、
設計が今の実態に合っているかどうかです。

それでも再構築が必要になる理由

では、なぜ再構築が議論に上がるのでしょうか。よくあるきっかけは次のようなものです。

• 処理が遅くなってきた
• 修正できる人がいない
• 64bit対応で不具合が出た
• Excelでの手修正が増えている
• 生産形態が変わっている

特に最後の点。多品種少量化、外注比率の増加、複数拠点化など、生産の実態が変わっているにもかかわらず、原価計算ロジックは20年前の前提のままというケースは少なくありません。ここにズレが生じます。

ACCESS再構築には2種類ある

ACCESS再構築といっても、中身は大きく2つに分かれます。

① 延命型再構築

• 不具合修正
• 速度改善
• 64bit対応
• 帳票修正

いわば「リフォーム」です。短期的には合理的で、コストも抑えられます。ただし、原価計算の設計思想そのものは変わりません。生産実態とのズレがある場合、それは残ります。

② 設計見直し型再構築

もう一つは、

• 間接費配賦の再設計
• 製番単位の再定義
• 標準原価の考え方の整理
• データ構造の抜本的見直し

を行ったうえで、ACCESSで作り直す方法です。これは単なるシステム修正ではありません。原価計算の再設計です。同じACCESSでも、意味はまったく異なります。

ACCESSの現実的な限界ライン

ここで、データ量の目安も整理しておきます。ACCESSの制約はよく語られますが、実務上問題になるのは次のようなケースです。

• 月間製番が数千件規模
• 実績データが月数十万行を超える
• 同時利用者が10名以上
• 拠点間リアルタイム共有が必要
• 海外拠点を含む統合管理

このレベルになると、

• 処理速度低下
• データ破損リスク
• バックアップ運用の複雑化

といった問題が出やすくなります。つまり、問題は売上規模ではなく、データ量と同時利用環境です。年商30億円でもデータがシンプルなら問題は起きません。年商10億円でも製番が極端に多ければ厳しくなります。

最大のリスクは再び属人化すること

再構築で最も多い失敗はこれです。

• ロジックを文書化しない
• 配賦根拠を整理しない
• データ構造を共有しない

結果として、数年後に再びブラックボックス化する。ACCESSの問題というより、
設計統制の問題です。再構築するなら、最低限、

• 原価フロー図の作成
• 配賦ロジックの明文化
• マスタ設計書の整備

はセットで行う必要があります。

どんな会社にACCESS再構築は向いているか

ACCESS再構築が合理的なのは、次のような企業です。

• 単一拠点である
• 生産構造が比較的シンプル
• 将来5年で大きな拡大予定がない
• 上場予定がない
• 原価設計を一度整理したい

この場合、ACCESSは十分に選択肢になります。無理にERPへ飛びつく必要はありません。

延命か、再出発か

結局のところ、判断の分かれ目はここです。

• 今の原価は経営判断に使えているか
• 生産の実態を正しく表しているか
• 5年後も通用する設計か

もしここが曖昧であれば、単なる延命ではなく、設計からの見直しが必要です。ACCESSを使うかどうかよりも、どの思想で原価を設計するかの方がはるかに重要です。

次回は、「Excel × PowerQueryで原価計算を再設計する」というアプローチを取り上げます。大規模投資をせずに、原価ロジックを一度“分解”する方法です。

システム刷新の第一歩は、ツール選定ではなく、構造の可視化かもしれません。

• 生産形態の変化
• ロジックの老朽化
• 属人化

にある、という話でした。では、実際に見直そうとしたとき、どのような選択肢があるのでしょうか。

今回は、原価計算システム刷新の「全体像」を整理します。

選択肢は大きく4つに分かれる

原価計算システムの見直しは、概ね次の4つに分類できます。

1. 既存ACCESSの再構築・延命
2. Excel（PowerQuery等）で再設計
3. Kintoneなどのクラウド業務基盤で構築
4. ERP・基幹システムへ統合

重要なのは、「どれが優れているか」ではなく、自社の規模・複雑性・将来像に合っているかです。

1. ACCESSを再構築するという選択

もっとも現実的で、もっとも選ばれやすいのがこの方法です。

既存ロジックを整理し、不要な部分を削ぎ落とし、改めてACCESSで作り直す。

メリットは明確です。

• 既存資産を活かせる
• コストを抑えられる
• 現場が使い慣れている

一方で、

• 将来の拡張性には限界がある
• 開発者依存リスクが残る
• クラウド連携は弱い

という課題もあります。

「あと5年持たせたい」という場合には合理的な選択ですが、10年スパンの経営基盤としては慎重な検討が必要です。

2. Excel × PowerQueryで再設計する

意外と現実的なのがこの方法です。近年のExcelは、PowerQueryを活用することで、データ整形や集計をかなり高度に行えます。

特に、

• 原価計算のロジックを一度分解し
• 計算プロセスを可視化し
• ブラックボックスを解消する

という目的には非常に向いています。

導入コストも低く、経理部門主導で進められるのが強みです。

ただし、

• データ量が増えると管理が難しくなる
• ガバナンスが弱くなりがち
• 入力系システムには向かない

という限界があります。

「まずは設計を立て直す」段階では有効ですが、最終形とは限りません。

3. Kintoneなどクラウド業務基盤で構築する

Kintoneのようなノーコード／ローコード基盤を使い、原価関連データを一元管理する方法もあります。

この選択肢の本質は、原価計算を単体で考えない という点にあります。

• 工数管理
• 製番管理
• 外注管理
• ワークフロー

これらを業務全体として整理し、その上で原価を算出する。業務改革とセットで進める場合には非常に有効です。

一方で、

• 複雑な配賦ロジックは工夫が必要
• 大量データ処理には設計力が求められる

という技術的課題もあります。

④ ERP・基幹システムへ統合する

最も本格的な選択肢が、ERP導入です。販売管理・生産管理・会計を統合し、原価計算もその中で行う。

メリットは、

• データ一元化
• 内部統制強化
• 拠点展開対応
• 上場準備対応

など、経営基盤としての強さです。

ただし、

• 導入コストが大きい
• 業務をシステムに合わせる必要がある
• 導入失敗リスクも存在する

という現実があります。規模や将来計画を踏まえた判断が必要です。

実は「計算」と「分析」は分けて考える

ここで重要な視点があります。

それは、原価を「計算する仕組み」と「分析する仕組み」は別物 ということです。

たとえば、

• 計算はERPやExcelで行い
• 分析はPowerBIで行う

という分業も十分あり得ます。

一つのツールで完結させようとすると、かえって不自然な設計になることがあります。

選択の軸は何か？

選択を誤らないためには、次の観点を整理する必要があります。

• 製品点数はどれくらいか
• 製番管理はしているか
• 間接費配賦は複雑か
• 拠点は複数あるか
• 将来的に上場を目指すか
• 内製化したいか、外注前提か

ツールから考えるのではなく、自社の将来像から逆算することが重要です。

次回は、最も現実的な選択肢である「ACCESSを再構築する」という選択について、もう少し掘り下げます。

延命なのか、再設計なのか。そこを曖昧にすると、再び同じ問題が繰り返されます。単なるツール比較ではなく、原価設計の本質に踏み込んでいきます。

営業支援システムや受発注管理システムは、本来、業務を効率化し、営業担当者が付加価値の高い活動に集中できるようにするためのものです。ところが実際には、システムの存在がかえって現場の負担となり、効率を阻害している例が少なくありません。これは特定の業界や企業に限らず、多くの現場で共通して見られる現象です。

入力作業の負担と二重入力

営業担当者が最も強く感じるのは、入力作業の煩雑さです。製品仕様や数量、配送先など細かい項目を繰り返し入力させられ、同じ情報を複数の欄に書き込まなければならないケースも少なくありません。さらに、入力の元になる情報がメール、Excel、紙の資料などに分散しており、入力よりも「探して転記する」ことに時間がかかる状況が生まれています。

システムと実務の乖離

システムの設計が実務に合っていないこともよくあります。ほとんど利用されない機能や入力欄が存在する一方で、実際に必要な情報はシステム外でExcelや紙に頼らざるを得ない。このように不要なものが残り、必要なものが欠けているアンバランスさが、システムと現場の乖離を生んでいます。

帳票と金額計算の人力依存

見積や請求、納品資料を作成する場面でも、システムの出力をそのまま使えず、Excelや電卓を使った再計算が常態化している企業は多いものです。帳票に余計な情報が含まれていたり、逆に必要な明細が不足していたりするため、必ず人手による加工が必要になります。結果として、システムが業務を最後まで完結させられず「最後の仕上げは人力」という状態が固定化されています。

検索性の低さと参照の不便さ

過去案件を検索する機能があっても、実際にはうまく活用できないケースも少なくありません。品名や担当者の入力ルールが統一されていないため、検索してもデータが見つからない。全角・半角や入力方法の違いが障害になり、前任者の登録データをうまく引き継げない。このように「検索はあるが、見つからない」という問題は、多くの企業で繰り返されています。

UI・操作性・安定性の問題

システムの使い勝手に対する不満も根強いものがあります。入力欄が狭い、文字数制限が厳しい、画面遷移が多いなど、ユーザーにとって直感的でないUIがストレスを生みます。さらに、入力中にタイムアウトやセッション切れが起こり、作業が中断することもあります。営業担当者が「システムに気を使いながら業務を行う」状態は、本来の目的と逆行しています。

改善の方向性

こうした課題を解決するために必要なのは、大規模なシステム刷新では必ずしもありません。入力や検索の改善、金額計算や帳票出力の自動化、UIや安定性の強化といった部分的な改修だけでも、業務効率は大きく向上します。小さな改修で現場のストレスを取り除けば、営業担当者は本来の顧客対応や提案活動に集中できるようになります。

まとめ

営業システムは「業務効率化の道具」であるはずなのに、現場の声に耳を傾けないと「事務負担の増加要因」へと転じてしまいます。経営者や幹部が注目すべきは、大きな刷新ではなく、現場に即したピンポイントの改善でどこまで成果を上げられるかという視点です。二重入力をなくし、帳票や金額計算を自動化し、検索や操作性を改善する。これらはどの企業にも共通する「小さな投資で大きな効果を得られる領域」です。

基幹システムの入れ替えを検討するとき、多くの企業が直面するのが「古くからある実績型パッケージ」と「クラウド前提で再設計されたSaaS型」の二択です。どちらが優れているかという単純な話ではなく、自社の状況と優先順位によって答えは変わります。本記事では、経営判断に必要な考え方を整理します。

1．「安定」か「将来性」かは最初の分かれ道

長年使われてきたパッケージ型システムは、稼働実績やトラブル対応のノウハウが豊富で、カスタマイズや周辺連携も一定の安心感があります。業務を大きく変えたくない、あるいはトラブルによる業務停止を避けたい企業にとっては、もっともリスクの低い選択肢になります。

一方、刷新されたSaaS型は、サーバーの運用が不要で、アップデートも自動で提供され、将来の技術変化に対応しやすいという強みがあります。ただし、導入事例がまだ少ない場合は、安定稼働やトラブル対応力に不安が残るケースもあります。

2．業務を「システムに合わせるか」「システムを業務に合わせるか」

選択の本質は、業務とシステムのどちらを起点に考えるかによって違ってきます。

すでに確立された業務フローや独自の商習慣があり、現行の運用を維持したい場合は、過去のカスタマイズノウハウが蓄積されている従来型パッケージのほうが適しています。導入企業数が多ければ、似た業種・業態の事例も見つかりやすく、カスタマイズ済みの「部品」を再活用できるため、導入コストを抑えることも可能です。

一方、業務そのものを見直したい、あるいは標準化・BPR（業務改革）と並行して刷新を進めたい場合は、SaaS型のほうが合理的です。標準機能をベースに業務を設計し直す前提であれば、過去の“使い回し”に縛られず、運用コストも削減できます。

3．IT運用体制とサーバー管理の可否

「自社でサーバーを持ち続けるかどうか」は大きな判断軸になります。オンプレ型やクラサバ型は、自社もしくは既存ベンダーがシステム維持に関与し続ける前提です。バックアップやセキュリティ、OSアップデート対応などの体制を維持できるなら選択肢として成立します。

逆に、インフラや保守要員の確保が難しい企業、あるいはセキュリティ対応や障害時対応を外部化したい企業にとっては、SaaS型による「運用レス」のメリットは無視できません。特に、IT人材の採用・育成が困難になっている企業では、サーバーを持ち続けるというだけで経営リスクになり得ます。

4．プロジェクトの失敗許容度

「失敗できないプロジェクトか」「ある程度の試行錯誤が許されるか」も判断材料になります。

トラブルが発生した場合の影響が大きい業種、あるいは現場負荷が高くプロジェクトが止められない企業は、実績型のパッケージのほうが安全です。導入ベンダー側も過去の知見をもとにプロジェクトを管理できるため、工数や見積り精度も高くなります。

逆に、将来を見据えて変革のタイミングを作りたい企業や、既存システムの延命に限界を感じている企業であれば、SaaS型との相性は良くなります。もちろん不確実性は伴いますが、その分、刷新後の運用負担は軽くなります。

5．コストは「導入費用」ではなく「総額」で見る

「クラウドのほうが安い」「オンプレは高い」といったイメージだけで判断するのは危険です。カスタマイズ量・連携要件・運用年数・バージョンアップ費用などを含め、5年〜10年単位での総コスト（TCO）を比べる必要があります。

特にSaaS型は初期費用が低く見えがちですが、標準機能外の実装や運用変更が多い場合、追加コストが膨らむケースも少なくありません。一方、従来型であっても「過去の開発資産を再利用できる」「トラブル時の対応が早い」といった点が、結果的にコスト抑制につながるケースもあります。

6．最終判断は「どちらを選ぶか」ではなく「どの前提を受け入れられるか」

どちらが優れているかではなく、自社がどの前提を採用できるかが決め手になります。

安定性・過去実績・カスタマイズ性を重視するなら従来型パッケージ。
業務標準化・インフラレス・将来拡張を重視するなら刷新SaaS。

言い換えれば、「今の業務を守るのが目的か」「将来に合わせて作り替えるのが目的か」で方向性が決まります。

まとめ：迷うのは正常。ただし“曖昧に選ぶ”のが一番危険

両者には明確な棲み分けがあります。どちらを選ぶかは会社の方針、業務の柔軟性、IT体制、リスク許容度によって変わります。にもかかわらず、「最新版だから」「安心だから」という感覚だけで決めると、導入後のミスマッチやコスト膨張を招きます。

重要なのは、判断基準を明確にし、「なぜこちらを選ぶのか」と説明できる状態にしておくことです。逆にそれができれば、どちらを選んでも後悔は少なくなります。

このテーマは、多くの企業がこれから直面する経営判断そのものであり、単なるITの話ではありません。次回は、実際の判断材料をチェックリスト形式で整理してみたいと思います。

近年、あらゆる業界で「DX（デジタルトランスフォーメーション）」という言葉を耳にする機会が増えました。しかし、現場ではこれを単なるIT導入や業務効率化の延長と捉えてしまい、本来の効果を発揮できないケースも少なくありません。DXとは、ITを活用して事業や企業そのものを変革し、競争優位を確立する取り組みを意味します。

DXは「IT経営」の延長ではない

これまでのIT活用は、社内業務の効率化やコスト削減が中心でした。一方、DXは顧客や社会のニーズに応え、新しい製品・サービス・ビジネスモデルを生み出すことに重点を置きます。

違いの一つは、つながるネットワークの規模です。従来は社内や取引先といった限られた範囲でしたが、DXではIoTや5Gを活用して顧客や市場全体とつながるオープンなネットワークになります。また、扱うデータも大きく変化します。手入力の定型データだけでなく、センサーやアプリ、SNSなど多様なソースから得られる膨大な情報を活用し、AIやビッグデータ分析によって新たな価値を見出します。そして対象とするニーズも、内向きの効率化から外向きの顧客体験・社会価値創造へと広がります。

DXは「新しい事業の土壌」になる

DXの本質は、未開拓市場（ブルー・オーシャン）を切り開くことにあります。技術は生活や行動様式を根本から変え、新たなニーズを生み出します。

たとえば、専用アプリで顧客と常時接続し、利用データから新商品の企画を行う。センサー情報を活用し、故障前にメンテナンスを行う予防保全や、需要に応じたオンデマンドサービスを提供する。あるいは顧客体験を中心に据えた直販（D2C）モデルを構築し、中間コストを削減する。こうした取り組みは、既存の競争環境を飛び越えた成長を可能にします。

DXを成果につなげる3つのプロセス

DXを単なるスローガンで終わらせないためには、以下の3つのプロセスが重要です。

1. 顧客ニーズの把握
   顕在化しているニーズだけでなく、顧客自身が気づいていない潜在ニーズを探り出す。IoTや行動履歴のデータをAIで分析し、新たな仮説を立てる。
2. 新規事業・新サービスの創出
   発想法やブレインストーミングを活用し、他業界の事例や異分野の技術と組み合わせることで独自性を高める。
3. 企業変革
   新しい事業にふさわしい組織や文化、業務プロセスにシフトし、古い体制を刷新する。

経営者が今すぐ着手すべきこと

DXの成否は、経営層の意思と覚悟にかかっています。まずはDXで何を実現するのかというビジョンを明確にし、そのゴールを全社で共有します。次に、既存の契約やデータの棚卸しを行い、活用可能な資産や顧客接点を可視化します。そして、小規模な実証実験を繰り返し、成功事例を組織に浸透させていくことが重要です。

まとめ

DXは単なるIT投資ではなく、企業の存在意義やビジネスのあり方を問い直すプロセスです。ネットワーク、データ、顧客志向の3つを軸に、事業と企業の両輪で変革を進めることが、今後の成長の鍵となります。変化は待ってくれません。いまこそ、自社のDX戦略を具体的に描き、実行に移すべき時です。

かつて、基幹システムは“15年使って当たり前”と考えられていました。しかし、今日ではこの常識が大きく揺らいでいます。中堅企業においても、システム戦略を再定義すべきタイミングが来ているのです。

なぜ10年で終わるのか？背景にある3つの変化

1. 技術進化の加速 クラウド、API、AIといった新技術の進化が速く、10年前の技術では現在の業務要件に対応しきれないことが多くなっています。
2. ベンダービジネスの構造変化 ソフトウェアベンダーの多くが、ライセンス販売からサブスクリプションモデルに移行。旧製品の保守・改修よりも、新サービスへの移行を促進する方向に舵を切っています。
3. 法令・業務環境の変化 電子帳簿保存法の改正やインボイス制度、働き方改革など、制度対応のスピードも問われる時代に。これに柔軟に対応できる設計が求められています。

長期利用＝コストメリットではない時代

過去には「長く使えば元が取れる」という考えが主流でした。しかし、技術的陳腐化や属人化、保守人材の不足といったリスクが顕在化する中、「長く使い続けること」自体がコスト増要因になるケースも増えています。

むしろ、柔軟に再構築できる設計思想、アップデートしやすいシステム構成こそが、将来的な投資対効果を高めるカギとなります。

これからの基幹システム戦略 〜進化を前提に設計する〜

以下の3点が、今後の基幹システム設計における柱になります。

1. 柔軟性を備えたアーキテクチャ
   • クラウド活用やAPI連携、モジュール構成など、特定ベンダーに依存しない仕組みを前提とする
2. データ資産を中心に据える設計
   • データを自社の資産として分離・保管し、アプリケーションとは切り離して管理
3. 進化を前提にした体制と運用
   • 「導入して終わり」ではなく、5年ごとの定期見直しと小規模アップデートを続ける体制を構築

リプレイス＝後ろ向き ではなく、進化のチャンス

突然のベンダー撤退はたしかに痛手です。しかしそれは、現状の業務やシステムの在り方を見直す貴重な機会でもあります。

変化の激しい時代にあっては、永続的に使えるシステムではなく、「いつでも変えられるシステム」を持つことこそが、企業競争力の源泉となります。

これからの基幹システム戦略は、「安定性」と「進化性」を両立する発想への転換が不可欠です。10年後も強くしなやかな経営を支えるために、いま一度、自社のIT基盤の在り方を問い直してみてはいかがでしょうか。

こう考えている企業は多いかもしれません。しかし、その「動いているから大丈夫」という考えが、将来の大きなリスクにつながる可能性があります。

特に、過去の担当者しか分からない 「ブラックボックス化した業務システム」 は、企業の事業継続や競争力に深刻な影響を及ぼします。

では、このブラックボックス化を放置すると、どのような問題が起こるのでしょうか？

ブラックボックス化を放置するとどうなるか？

業務システムが属人化し、ドキュメントも整備されず、リプレイスが後回しになると、企業は次のようなリスクを抱えることになります。

1. 事業継続リスクの増大

• 重要なシステムの運用が停止すると、業務がストップし、顧客対応や取引に支障をきたす。
• 担当者が退職・異動した途端、誰もシステムの仕組みを理解できず、障害発生時の復旧が困難に。

2. コストの増大

• システムの構造が不明確なため、運用・保守の工数が増え、人的コストが増大。
• 古い技術で作られたシステムの維持費が高騰し、新しい業務ツールとの連携が困難に。

3. 業務効率の低下

• 属人化した業務フローに依存し、改善や自動化が進まない。
• レガシーシステムが業務のボトルネックとなり、新しい市場機会への対応が遅れる。

このまま放置すれば、企業の成長スピードが鈍化し、競争力を失う危険性があるのです。

解決策：まずはシステムの可視化から始める

業務システムのブラックボックス化を解消するには、 短期的な対策と長期的な改革の両方 が必要です。

短期的な対策：システムの可視化とナレッジ共有

• システム構成を文書化
  現在のシステム、アプリケーション、データベース、サーバーの一覧を作成。
• 依存関係の可視化
  どのシステムがどの業務に関わっているのかを明確にし、関連性を整理。
• ナレッジ共有の仕組み構築
  システムの運用ルールやトラブルシューティングの情報をドキュメント化し、関係者全員がアクセスできる環境を整備。

長期的な改革：リプレイス計画の策定

ブラックボックス化したシステムは、ほとんどの場合、技術的にもビジネス的にも「賞味期限切れ」 です。したがって、長期的には新しいシステムへの移行が必要になります。

• リプレイスの目的・目標を明確化
  どの業務を効率化し、どの問題を解決するためにシステムを更新するのかを定義。
• グランドデザインの策定
  求める業務要求を整理し、それを実現するための新システムのグランドデザインを策定。またクラウド化、SaaSの活用、API連携の強化などの実装方法も検討。
• 移行計画ラフ案の策定
  現行システムの運用に支障をきたさない形で、段階的にリプレイスを実施。超概算で経営陣の理解も得る

ブラックボックスからの脱却が、企業の未来を切り開く

業務システムのブラックボックス化を解消することは、 単なるシステムの刷新ではなく、企業の競争力を強化する戦略的な取り組み です。

今こそ、 「動いているから大丈夫」から「持続的に成長できるシステムへ」 のシフトが求められています。