まいどおおきに、ASAKURAの朝倉です。

本日も早朝5時より、筆を走らせます。

私的な話ですが、今週末に中小企業診断士の試験を控えており、そのアウトプットも兼ねた内容です（暇なときに読んでください）。

「基幹システムを入れ替えたい」というご相談をいただくとき、最初に出てくる言葉はたいていツール名です。ERP、kintone、クラウド会計、BIツール、最近だとデータレイク。

どれも実在する良いものですが、順番として最初に決めるべきものではありません。

先に結論を書きます。

中小企業の基幹システム設計で最初に決めるのは、コード体系とマスタです。

データレイクは大半の中小企業に不要です。

DWH（データウェアハウス）は「必要になってから」で間に合います。

BIツールは入れる順番を間違えると、ほぼ確実に使われなくなります。

そして、設計の成否を最も左右するのは技術力ではなく、社内に「業務とITの翻訳ができる人」が一人いるかどうかです。

説明の途中で、架空のA社にたびたび登場してもらいます。当社のコラムシリーズで一貫して使っている会社です。

A社：三重県のリフォーム会社。年商1.2億円、従業員12名（事務2名、営業3名、職人7名）。

見積はExcel、受注管理はGoogleスプレッドシート、会計は市販の会計ソフト、工程管理はホワイトボード、顧客情報は営業それぞれのスマートフォン。社長が「そろそろちゃんとしたい」と言い出したところ。

多くの中小企業が、だいたいこのあたりにいます。

「基幹システム」とは、どこまでを指すのか

言葉の定義から始めます。ここが曖昧なままだと、以降の判断が全部ぶれます。

基幹系システム（SoR：Systems of Record）は、事業活動の「事実」を記録するシステムです。販売管理、購買・発注、在庫、生産、原価、会計、人事給与。止まると事業が止まります。求められるのは、正確さと整合性です。

情報系システム（分析系、あるいはSoE：Systems of Engagement の一部）は、記録された事実を「解釈」するシステムです。BI、レポーティング、ダッシュボード、需要予測。止まっても今日の業務は回ります。求められるのは、速さと柔軟さです。

この2つは、要求される性質が正反対です。

	基幹系（記録）	情報系（分析）
主な操作	登録・更新（書き込み中心）	集計・比較（読み取り中心）
重視するもの	整合性、正確性、監査性	応答速度、切り口の自由度
データの持ち方	正規化された最新状態	非正規化された時系列の蓄積
止まったときの影響	事業が止まる	判断が鈍る
変更のしやすさ	変えにくくてよい	変えやすくないと困る
代表的な技術	RDB（関係データベース）、トランザクション制御	DWH、データマート、OLAP、BI

中小企業のシステム失敗で最も多いパターンのひとつが、この2つを1つのシステムで解こうとすることです。

「販売管理システムで経営分析もできるようにしてほしい」という要望は自然ですが、これを本気で1本に詰め込むと、基幹系が重くなり、分析の自由度も出ず、両方が中途半端になります。

トランザクションという考え方

基幹系がなぜ「変えにくくてよい」のかを補足します。

基幹系のデータ更新には、ACID特性（原子性・一貫性・独立性・永続性）が求められます。難しく聞こえますが、要するに「途中で止まったら全部なかったことにする」「同時に2人が触っても壊れない」「書いたものは消えない」という性質です。

在庫を1つ引き当てながら受注伝票を立てる処理が、片方だけ成功して片方が失敗すると、帳簿と現物が合わなくなります。この整合性を担保するために、基幹系は堅く作られます。堅いということは、変更にコストがかかるということでもあります。

だから、「毎月変えたくなるもの」を基幹系の中に入れてはいけません。分析の切り口、KPIの定義、レポートのレイアウト。これらは変わる前提のものなので、情報系に置きます。

判断1：構造化データで持つか、半構造化で持つか

データの持ち方には、大きく3つあります。

構造化データは、行と列で表現できるデータです。関係データベースに入れるもの。受注明細、在庫数、仕訳。あらかじめ項目（スキーマ）が決まっていて、そこから外れるものは入りません。

半構造化データは、JSON、XML、CSVのように、ある程度の構造はあるがスキーマが固定されていないデータです。外部サービスとのAPI連携、Webのアクセスログ、問い合わせフォームの回答、アンケート結果。項目が増減しても壊れません。

非構造化データは、画像、PDF、図面、音声、動画、メール本文。中身をそのままでは集計できません。

中小企業の結論：本体は構造化、例外は半構造化で逃がす

基幹系の中核（取引先、商品、受注、在庫、原価、仕訳）は、構造化で持ちます。理由は3つあります。

1. 集計できるから。半構造化のまま持つと、集計のたびに「これはどう数えるのか」を人が判断することになります。判断が入る集計は、人が変わると数字が変わります。
2. 整合性を守れるから。項目が固定されていれば、必須入力や入力規則で誤りを構造的に防げます。
3. 説明責任があるから。税務調査や取引先の監査で「この数字の根拠は」と聞かれたとき、たどれる必要があります。

一方で、全部を構造化しようとすると別の失敗が起きます。「念のため」項目が増え続け、入力画面に50個の空欄が並び、誰も埋めなくなる。中小企業の基幹システムで最もよく見る風景です。

現実的な折衷案は、こうです。

• 集計・検索・条件分岐に使う項目だけを構造化された列にする
• それ以外の「あとで読めればいい情報」は、備考欄や拡張属性として半構造化で1枚受け皿を用意する
• 受け皿に入れたものは集計できない、と最初に合意しておく

この「集計できない」という合意が重要です。あとから「備考欄に書いた内容を集計してほしい」と言われたときに、なぜできないかを説明するコストが消えます。

正規化のさじ加減

関係データベース設計では、正規化（重複をなくす）が基本です。第3正規形まで整えるのが定石とされます。

なぜ重複を嫌うか。取引先の住所が3つのテーブルに書いてあると、引っ越したときに3つとも直さなければならず、どれか1つ直し忘れた瞬間、どれが正しいか分からなくなります。これを更新時異状といいます。

ただし、正規化を徹底すると、1画面を表示するのに10テーブルを結合する、といったことが起きます。実務では、参照が重い箇所だけ意図的に重複を許す（非正規化する）判断もします。

中小企業の規模では、性能を理由に非正規化が必要になることはほとんどありません。データ量が小さいからです。むしろ注意すべきは、「Excelの感覚でテーブルを作ると、1つのシートに全部入った巨大な表になる」ことです。取引先名を伝票に直接文字で書いてしまう設計は、必ず後で破綻します。

実は最重要：コード体系の設計

ここが本丸です。地味ですが、10年効きます。

取引先コード、商品コード、部門コード、工事コード。これらの採番ルールを最初に決めます。決めるべきことは以下です。

決めること	よくある失敗	望ましい考え方
桁数	3桁で始めて足りなくなる	想定件数の10倍で桁を確保する
意味を持たせるか	「1」が三重県、「2」が愛知県、のように分類を埋め込む	分類は属性の列で持ち、コードは意味なしの連番にする
誰が採番するか	誰でも新規登録できる	登録権限を絞り、申請と承認を通す
廃止のルール	使わなくなったら消す	消さずに「無効」フラグを立てる（過去の伝票が壊れる）
重複の扱い	同じ取引先が「株式会社◯◯」「(株)◯◯」「◯◯」で3件	表記ルールを決め、定期的に名寄せする

コードに意味を埋め込む設計（有意コード）は、分類が変わった瞬間に破綻します。三重県の会社が愛知県に移転したらコードを変えるのか、変えたら過去の伝票はどうなるのか。答えは「コードは変えず、都道府県は属性列で持つ」です。

A社の場合、まずやるべきことは新システムの選定ではなく、Excelとスプレッドシートに散らばっている取引先を1つのリストに統合し、重複を潰し、コードを振ることです。これは一円もかけずに、今日から着手できます。そして、この作業を終えていない会社がシステムを導入すると、汚れたデータをそのまま新システムに引っ越すことになります。

判断2：データレイクは中小企業に必要か

結論から書きます。大半の中小企業には不要です。

データレイクとは何だったのか

データレイクは、あらゆる形式のデータを加工せずに、生のまま大量に貯めておく置き場です。使うときになって初めて構造を決める（スキーマオンリード）のが特徴で、あらかじめ構造を決めるDWH（スキーマオンライト）と対比されます。

これが必要になる前提条件は、次の3つが揃ったときです。

1. データが大量にある（テラバイト級、あるいは日々増え続けるログ）
2. 形式が多様（センサー値、画像、テキスト、ログ、業務データが混在）
3. 「後で何に使うか決まっていない」ことを許容できるだけの分析人材と予算がある

3番目が重要です。データレイクは「捨てずに取っておく」ための仕組みであり、価値は後から取り出す人がいて初めて生まれます。取り出す人がいなければ、ただのコストです。

中小企業の実態と照らし合わせる

年商10億円未満の会社が、全社のデータを合計して、どのくらいの量になるか。受注、仕入、在庫、会計、顧客。10年分を足しても、多くの場合は数GBに収まります。表計算ソフトでは扱いにくいが、データベースなら余裕、という規模です。

この規模でデータレイクを構築すると、どうなるか。

データスワンプ（データの沼）になります。誰が入れたか分からないファイルが増え、項目の意味を知る人がいなくなり、「このCSVの3列目は何ですか」に答えられる人が退職し、結局誰も使わない。中身が分からないデータは、無いのと同じか、無いよりも危険です（誤った集計の根拠になるため）。

例外的に検討する価値があるケース

以下に当てはまる場合は、検討の余地があります。

• 製造業でラインにセンサーを入れ、秒単位のデータが継続的に発生する
• ECサイトを運営し、Webのアクセスログを長期に貯めたい
• 検査画像や現場写真を大量に扱い、将来的に画像解析を考えている
• 位置情報や車両の走行データを扱う

ただし、これらの場合でも「データレイク製品を導入する」という発想より、「ログ保管用のオブジェクトストレージ（クラウドのファイル置き場）を1つ用意し、命名規則とフォルダ構成を決める」と考えたほうが、実態にも予算にも合います。呼び方が違うだけで、中小企業規模ではやることはほぼ同じです。

レイクとDWHを統合したデータレイクハウスという概念もありますが、中小企業の意思決定においては、当面は検討対象から外して構いません。

判断3：DWH（データウェアハウス）とデータマート

DWHの定義と、その意味

DWHの古典的な定義は、次の4つの特性で説明されます。

特性	意味	なぜ必要か
サブジェクト指向	業務単位ではなく「売上」「顧客」といったテーマ単位で整理する	部門をまたいで見るため
統合	複数システムのデータを、コードや単位を揃えて統合する	販売管理と会計で取引先名が違うと合算できない
時系列	いつ時点のデータかを保持する	過去との比較ができるようにするため
不揮発	更新せず、追加していく	過去の数字が後から変わらないようにするため

3番目と4番目が、DWHの存在理由の核心です。

基幹系のデータベースは、常に「最新の正しい状態」を保つように作られています。取引先の名前が変わればマスタを上書きし、担当者が変われば上書きし、商品の分類が変わればまた上書きします。これは基幹系として正しい振る舞いです。

ところが分析側から見ると、この上書きが困ります。去年の売上を「去年の組織」で見たいのに、今の組織で集計されてしまう。担当者Aが異動したら、彼が去年上げた売上まで異動先の部署に付いてしまう。

DWHは、この「時点」を保持するために存在します。

基幹系のデータベースを直接分析に使ってはいけない3つの理由

1. 本番データベースに重い集計処理をかけると、業務が遅くなる、最悪止まる
2. 上書き更新されるため、時点の比較ができない
3. データが複数システムに分散している（販売管理、会計ソフト、スプレッドシート、業務アプリ）

データマートとは

データマートは、DWHから特定の部門・目的向けに切り出した、小さな集計済みデータの塊です。営業向け、購買向け、経営会議向け、といった単位で作ります。

役割は2つ。

• 表示を速くする（毎回全件を集計しない）
• 定義を固定する（「売上」の定義をここで1つに決める）

2番目のほうが実は重要です。後述しますが、BIが失敗する最大の原因は定義のばらつきです。

中小企業の現実解：段階を踏む

いきなりクラウドDWHを契約する必要はありません。段階で考えます。

段階0：まだ何もない 基幹系のデータを、夜間バッチでCSVに書き出す。あるいは読み取り専用のコピーを作る。これだけで「本番を止めずに集計する」条件は満たせます。

段階1：集計テーブルを1つ作る 月次の売上・粗利・件数を、得意先別・商品分類別に集計したテーブルを1つ用意し、毎晩更新する。実質的なミニDWHです。中小企業の8割は、ここで必要十分に達します。表計算ソフトの限界を超え、かつ運用が破綻しない、ちょうどよい着地点です。

段階2：本格的なDWHを置く クラウドのDWHサービスを使い、ETL/ELTツールで各システムからデータを集める。複数拠点、複数事業、月次では遅すぎる意思決定がある、といった条件が揃ってから検討します。

ETLとELTの違いにも触れておきます。ETL（抽出・変換・格納）は、DWHに入れる前に変換します。ELT（抽出・格納・変換）は、生のまま入れてからDWHの中で変換します。クラウドDWHは処理能力が高いのでELTが主流ですが、中小企業の規模では、どちらでも結果は変わりません。用語として知っておけば十分です。

スタースキーマと「粒度」

DWHの設計では、ファクトテーブル（数値の事実：売上金額、数量）を中心に、ディメンションテーブル（切り口：日付、顧客、商品、担当者）を放射状に配置します。星の形に見えるのでスタースキーマと呼びます。

ここで最初に決めるのが粒度（グレイン）です。1行が何を表すのか。「受注1件」なのか「受注明細1行」なのか「日次の合計」なのか。

粒度を細かくしすぎるとデータ量が増え、粗くしすぎると後から掘れません。原則は「あとで集計はできるが、分解はできない」なので、迷ったら細かいほうに寄せます。ただし「細かくしておけばいつか使う」は、たいてい使いません。今の意思決定に必要な粒度＋1段階、くらいが現実的です。

BIツール上での操作（ドリルダウン＝より細かい階層に降りる、スライシング＝1つの切り口で切る、ダイシング＝複数の切り口で絞る）は、この構造があって初めて成立します。逆にいうと、構造がないところにBIを載せても、これらの操作はできません。

判断4：BIツールを入れる前に片付けておくこと

BIツールは優秀です。優秀すぎて、土台の問題を隠したまま動いてしまうのが厄介なところです。

導入したBIが半年後に見られなくなる原因は、ほぼ次の3つに集約されます。

原因1：マスタが名寄せされていない

同じ取引先が3レコードあると、売上ランキングが割れます。ランキングが実感と合わないダッシュボードは、一度でも「これ違うよね」と言われた時点で、二度と見られません。

信頼を失うのは一瞬で、取り戻すのに数か月かかります。だからBIの前にマスタ整備なのです。

原因2：指標の定義が部署で違う

「今月の売上」が、営業では受注ベース、製造では出荷ベース、経理では検収ベース、社長の頭の中では入金ベース。全員が正しく、全員の数字が違います。

BIを入れると、この不一致が可視化されます。可視化された結果、数字の話ではなく「どっちが正しいか」の会議が始まります。

対策は、BI導入前に主要指標の定義を文書化し、経営が承認することです。売上、粗利、案件、稼働率、原価。10個も定義すれば足ります。この作業に技術は要りません。要るのは決断です。

原因3：作った人しか更新できない

BIツールで凝ったダッシュボードを作った担当者が異動する。数式が読めない。データソースの接続が切れる。誰も直せない。放置される。

対策は、共通指標のダッシュボードは仕様を文書化し、複雑な計算はBI側ではなくデータマート側（SQL）に寄せることです。BIの画面はできるだけ単純に保ちます。

セルフサービスBIとガバナンスの綱引き

現場の誰もが自由にダッシュボードを作れる状態（セルフサービスBI）は、活用が進む一方で、「同じ名前で数字が違うダッシュボード」が増殖します。

2層に分ける運用が現実的です。

層	誰が作るか	定義	用途
公式ダッシュボード	管理者が作り、経営が承認	固定・変更には承認が要る	経営会議、共通KPI
探索用	誰でも自由に	各自の責任	仮説を試す、個人の管理

探索用で有用だと分かったものを、公式に昇格させる。この流れを作ると、自由と統制が両立します。

導入前チェックリスト

以下に「はい」と答えられないうちは、BIツールの契約を待ったほうが安全です。

• 取引先マスタと商品マスタが1つに統合され、重複が潰れている
• 主要指標の定義が文書化され、経営が承認している
• 分析用にデータを取り出す仕組み（コピー、集計テーブル）がある
• 1枚目のダッシュボードで「何の意思決定をするか」が決まっている
• そのダッシュボードを毎週見る人が決まっている

最後の2つは、技術ではなく運用の話です。そしてここが抜けている導入がいちばん多い。

どのような人材を配置し、どう管理するか

中小企業に情報システム部門は作れない。作るのは「役割」

従業員12名の会社に、情報システム部門を置くのは非現実的です。しかし、必要なのは3人ではなく3つの役割です。1人が2つ兼ねてもよく、外に出せるものもあります。

役割	内容	誰が担うか	外注できるか	欠けるとどうなるか
A：意思決定	投資判断、優先順位、業務変更の承認	経営者	できない	決まらない。要望が全部同じ優先度になる
B：翻訳	業務要件の言語化、マスタ管理、テスト、社内調整	業務に最も詳しい社員	最も外注しにくい	動くが使われないシステムができる
C：構築・運用	設計、実装、インフラ、保守、セキュリティ	外部パートナー	できる	品質と保守性の問題。ただし代替は効く

多くの会社が、Cを外注し、Aは社長がやるところまでは辿り着きます。抜けるのはBです。そしてBが抜けたプロジェクトは、ベンダーが悪くなくても失敗します。

なぜならベンダーは、A社の業務を知りません。「見積を出してから受注までの間に、実は現場が寸法を測り直して単価が変わることがある」といった、その会社固有の例外を知っているのは社内の人だけです。この例外を要件として言語化できる人がいないと、システムは「普通の会社」向けに作られ、現場が使えないものになります。

Bを担うのは、必ずしもITに詳しい人でなくて構いません。むしろ業務に詳しく、社内で話を通せる人のほうが適任です。ITの知識は後から足せますが、業務知識と社内の信頼は後から足せません。

そして、Bを任命したら、経営はその人の時間を確保する必要があります。「通常業務をやりながら、空いた時間で」では進みません。導入期は業務時間の2〜3割を充てる想定を、経営が公式に認めることが条件です。

データオーナーとデータスチュワード

データの品質は、責任者を決めた瞬間に変わります。

データオーナーは、そのデータの正しさに責任を持つ人です。取引先マスタなら営業部門長、商品マスタなら商品担当、原価データなら工事責任者。

データスチュワードは、日々の整備をする人です。登録、修正、重複のチェック。事務担当が担うことが多い役割です。

この2つを決めていない会社では、マスタが誰でも登録できる状態になっています。「新規のお客さんだから登録しておいたよ」が積み重なり、重複が生まれ、数字が合わなくなります。

最低限の管理体制

規模を問わず、これだけは決めておく項目です。

項目	決めること	目的
マスタ登録	誰が登録・承認できるか	データ品質
アクセス権限	誰が何を見られるか、変えられるか	内部統制、職務分掌
変更管理	カスタマイズや設定変更の記録、テスト手順	「いつ誰が何を変えたか」を追える
バックアップ	どの頻度で、どこに、どれだけ保持するか	復旧できる状態の担保
復旧目標	いつの時点まで戻すか（RPO）、何時間で復旧するか（RTO）	事前の合意。障害時に揉めない
委託先との分界	ドメイン、アカウント名義、ソースコード、データの所有権	乗り換え可能性の確保

最後の項目は、発注する側が最も見落としやすく、最も痛い目を見るところです。ドメインがベンダー名義、広告アカウントがベンダー所有、CMSの管理者権限を渡してもらえない。この状態は、契約が続いている間は問題になりませんが、切り替えたくなった瞬間に身動きが取れなくなります。

ITリテラシーと設計に関係はあるのか

あります。それも、かなり直接的に。

原則をひとつ挙げるなら、設計は組織のITリテラシーの上限に規定される、ということです。理論的に美しい設計より、現場が正しく入力できる設計のほうが、価値が高い。運用されない設計は、設計として失敗しています。

リテラシーが高くない前提での設計原則

以下は、リテラシーの底上げを待たずに実行できる設計上の工夫です。

入力させない。自動で取れるものは自動で取る。日付、担当者、部署、単価。マスタから引ける情報を人に打たせない。入力項目が1つ減るごとに、誤りと入力放棄が減ります。

自由記述を減らす。自由記述は、書いた人以外には検索も集計もできません。選択式にできるものは選択式にします。ただし選択肢が20個を超えると探せなくなるので、その場合は階層に分けます。

1画面1目的にする。1つの画面に全部を詰め込まない。「受注を登録する画面」と「原価を入力する画面」を分けたほうが、結果的に早く終わります。

構造的に間違えられなくする。必須入力、入力規則、権限制御。「気をつけましょう」という運用ルールは守られません。守らなくても壊れない構造にします。

二重入力を残さない。システムに入れた後で、別のExcelにも転記している状態を放置すると、必ずどちらかが正になり、システム側が空洞化します。移行時にExcelを「捨てる日」を決めるのが、最も効果のある施策です。

逆方向の誤解を2つ

誤解1：リテラシーが低いから、まだシステムは早い これは待ちすぎです。リテラシーは、良い道具を使うことで上がります。使わずに研修だけで上げるのは効率が悪い。並行して進めるものです。

誤解2：リテラシーを上げてから、高度な設計をすればよい これも危険です。「教育すれば使えるようになる」を前提にした設計は、教育コストを見積もっていないことがほとんどです。人は入れ替わります。新人が入るたびに同じ教育コストがかかる設計は、恒久的な負債です。

エンドユーザーコンピューティング（EUC）の光と影

現場の社員が、ノーコードツールやスプレッドシートで自分の業務を効率化できるのは、間違いなく強みです。IT部門を待たずに改善が回ります。

一方で、放置すると次のことが起きます。

• シャドーIT（会社が把握していないツールに業務データが入っている）
• 野良Excel（作った本人しか触れず、退職とともに凍結される）
• データの分散（マスタが増殖し、どれが正か分からなくなる）

対策は禁止ではなく、範囲の定義です。

現場が作ってよいもの	会社が管理すべきもの
個人・部署内の作業効率化	全社共通のマスタ
一時的な集計、試作	対外的に提出する数字
定型作業の自動化（自部署内で完結）	顧客の個人情報を含むもの
ダッシュボードの探索的な試作	会計・税務の根拠になるデータ

境界線を明文化して配るだけで、事故はかなり減ります。

リテラシーの測り方

資格の有無ではなく、観察できる行動で見ます。

• 表計算で、関数やピボットテーブルを使った集計ができるか
• ファイルの共有と権限（誰が見られるか）を理解しているか
• ファイル名やフォルダの命名を、他人が探せる形にできるか
• 分からないときに、検索して自力で解決を試みるか
• 「なぜこの数字になるか」を説明しようとするか

最後の2つが、実は最も設計に効きます。ツールの知識は教えられますが、この2つの姿勢がある人は、Bの役割（翻訳者）の候補になります。

設計をどう進めるか：順番の設計

最後に、進め方です。順番を間違えると、どれだけ良いツールを選んでも回収できません。

ステップ1：現状業務を可視化する（As-Is）

伝票がどこで生まれ、誰の手を通り、どこで数字になるかを追います。具体的には、

• 使っているExcelとスプレッドシートを全部リストアップする
• 同じ情報を2回以上入力している箇所に印をつける
• 紙で運用している箇所と、その理由を書き出す
• 各作業に月何時間かかっているかを、概算でよいので置く

ここを飛ばして「あるべき姿」から始めると、現場の例外が全部漏れます。地味ですが、最も投資対効果の高い工程です。

ステップ2：目的を数字で定義する

「効率化したい」では設計できません。

• 月40時間かかっている請求業務を10時間にする
• 受注から原価確定までの日数を、平均12日から3日にする
• 得意先別の粗利を、翌月5日までに把握できるようにする

数字で置くと、優先順位が自動的に決まります。そして導入後に「効果があったか」を検証できます。

ステップ3：データモデルとコード体系を設計する

第2章で書いた内容です。どんな情報を、どの単位で、どのコードで持つか。ここが設計の本体です。ツール選定より先に来ます。

理由は単純で、この設計ができていれば、どのツールを選んでも移せるからです。逆に、ツールに合わせてデータを持つと、ツールを変えるときに全部やり直しになります。

ステップ4：スコープを決める（全部やらない）

全部門を一度に置き換えるのは、中小企業では推奨しません。人が足りず、通常業務が止まります。

優先順位のつけ方は、次の2軸で十分です。

	業務負荷が大きい	業務負荷が小さい
改善が容易	最優先。ここから着手する	余力があれば
改善が困難	2番目。準備に時間をかける	やらない

A社なら、まず見積と受注の一元化。工程管理と原価は次の段階。会計との連携はさらに次。

ステップ5：方式を選ぶ（Fit to Standard を原則に）

選択肢は、SaaS・パッケージ・スクラッチ開発・内製（ノーコード含む）です。

かつては、パッケージと自社業務の差分を洗い出して埋めるフィット＆ギャップ分析が主流でした。近年は、むしろ業務のほうを標準機能に合わせるFit to Standardの考え方が優勢です。

判断の基準は、その業務が競争優位の源泉かどうかです。

• 競争優位の源泉である業務（A社なら、現場調査から見積を出すまでの独自のやり方）→ カスタマイズする価値がある
• そうでない業務（請求書の発行、経費精算、勤怠）→ 標準に合わせる

「うちは特殊だから」は、ほとんどの場合、特殊なのではなく、そのやり方に慣れているだけです。ただし本当に特殊な部分は必ずあるので、切り分ける作業自体が重要です。

ステップ6：ベンダーを選ぶ

RFP（提案依頼書）を作ります。立派なものである必要はなく、次が書いてあれば機能します。

• 現状の業務と課題（ステップ1の成果物）
• 実現したいこと（ステップ2の数字）
• 対象範囲（ステップ4）
• 既存システムとの連携要件
• 予算の目安と時期
• 提案してほしい内容の項目（構成、費用の内訳、体制、スケジュール、保守条件）

同じ資料を複数社に渡して初めて、見積が比較可能になります。各社に別々の説明をして集めた見積は、金額の大小に意味がありません。

見積を見るときは、次を確認します。

• 初期費用と月額の内訳（どこまでが初期に含まれるか）
• 保守の範囲（障害対応だけか、軽微な変更を含むか）
• 追加開発の単価
• データの所有権と、契約終了時の返還条件
• カスタマイズした部分のバージョンアップ対応

ステップ7：データ移行

想像の3倍かかると思ってください。

移行対象を決め、クレンジング（重複削除、表記統一、欠損の補完）を行い、テスト移行し、検証します。「過去10年分を全部持っていく」は、たいてい不要です。マスタは全件、トランザクション（伝票）は直近数年、というのが一般的な線引きです。

過去分は、参照用に旧システムを一定期間残すか、CSVで保管しておけば足ります。

ステップ8：定着させる

稼働は終わりではなく開始です。

• マニュアルは、画面の説明ではなく「この業務をやりたいときの手順」で書く
• 旧手順を明示的に廃止する（併存させない）
• 最初の1〜2か月は、質問の受け皿を決めておく
• 使われていない機能があれば、その理由を聞く

ステップ9：情報系（DWH・BI）を足す

ここまで来て初めて、分析基盤の出番です。基幹系でデータが正しく貯まり、マスタが整っていることが前提だからです。

やってはいけない順番

逆から書くと分かりやすいので、避けるべき進め方を挙げます。

• BIツールから始める（見る数字がまだ正しくない）
• データレイクから始める（貯める前に、貯めるべきものが定義されていない）
• ツールを決めてから業務を決める（ツールの都合に業務が引きずられる）
• 補助金の締切に合わせて方式を決める（補助金は手段であって、設計の制約にしてはいけない）
• 全部門同時に切り替える（通常業務が止まる）

補助金については補足します。IT導入補助金などの制度は有用ですが、締切が設計を歪めることがあります。「今期の枠に間に合わせるため、要件定義を1か月で終わらせる」は、数百万円の補助のために数年の負債を抱える取引になりかねません。制度は使うものであって、合わせるものではありません。

よくあるご質問

まとめ

長くなったので、要点だけ再掲します。

1. 基幹系（記録）と情報系（分析）は分けて設計する。1つにまとめようとしないこと。
2. 基幹系の本体は構造化データで持つ。集計しない情報だけ半構造化に逃がす。
3. 設計の本体はコード体系とマスタ。ここは今日から、費用ゼロで着手できる。
4. データレイクは大半の中小企業に不要。データスワンプになるリスクのほうが大きい。
5. DWHは「集計テーブルを1つ作る」から始めれば足りる。本格導入は必要になってからでよい。
6. BIは、マスタ整備と指標定義の後。順番を逆にすると必ず使われなくなる。
7. 必要なのは3つの役割（意思決定・翻訳・構築）。抜けやすいのは翻訳役で、ここは外注できない。
8. ITリテラシーは設計を規定する。入力させない、自由記述を減らす、二重入力を残さない。
9. 進め方は、現状把握 → 目的の数値化 → データ設計 → 範囲決定 → 方式選定 → ベンダー選定 → 移行 → 定着 → 分析基盤の順。
10. 契約前に、解約時に何が自社に返ってくるかを書面で確認する。

システムの相談を受けていて思うのは、うまくいく会社とそうでない会社の差は、予算でも技術力でもないということです。差がつくのは、自社の業務を言葉にできる人が社内にいるかどうか、そして経営がその人の時間を確保するかどうか。この2つです。

これは外から買えないものですが、外から手伝うことはできます。

ご相談について

株式会社ASAKURAでは、三重県を中心に、中小企業のITコンサルティング・DX支援を行っています。システムの導入そのものより前の段階、業務の可視化、データとコード体系の設計、要件定義、ベンダー選定の伴走といった部分からご相談を承っています。

「何から手をつければいいか分からない」という段階でも構いません。むしろ、その段階でご相談いただくほうが、無駄な投資を避けられます（宣伝）。