IT 事業11 分で読む

システム開発の前に、仕組み化を ─ 業務棚卸しから始める中小企業の受託開発

「業務を改善するために、システムを入れる」という発想で進める受託開発は、なぜ失敗するのか。中小企業が陥る「システム導入で全部解決する」幻想を分解し、業務棚卸し → 仕組み化 → 設計 → 実装の正しい順番を示す。

#IT 受託開発#業務仕組み化#業務棚卸し#中小企業#DX
青空と鉄骨 ─ 構造を作る前の設計

― 「業務を改善するために、システムを入れる」という発想で進める受託開発は、なぜ失敗するのか。中小企業が陥る「システム導入で全部解決する」幻想を分解し、業務棚卸し → 仕組み化 → 設計 → 実装の正しい順番を示す。

§ 01 / 「システムを入れたら効率化する」という幻想

中小企業の経営者から、システム開発の相談を受ける時、決まって出てくる言葉:

「現場が属人化していて困ってる。システムを入れて効率化したい」 「Excel で管理してるけど限界。専用システムを開発してほしい」 「他社が DX で成功してるから、うちもシステムを作りたい」

これらの相談に共通するのは、「システムを入れれば業務が良くなる」という前提。

しかし、現場で受託開発を 10 件以上やってきた経験から断言できる:

属人化した業務に、システムを被せても、属人化したシステムができるだけ

これは比喩ではなく、事実として何度も観察してきた構造である。「あの人がいないと回らない」現場に、専用システムを開発しても、半年後には「今度はあの人と、そのシステムを操作できる人がいないと回らない」状態になる。問題の所在が「人」から「人 + システム」に移っただけ。

§ 02 / なぜ仕組み化が先なのか

仕組み化とシステム化は、似ているようで全く違う。

仕組み化 システム化
主体 業務プロセスを設計する コードを書く・ツールを導入する
目的 誰がやっても同じ品質の業務を回せる状態にする プロセスを自動化・高速化する
順番 先 後
担当 経営者 + 現場リーダー エンジニア + 業務担当
失敗の代償 設計やり直し (時間ロス) システム作り直し (時間 + お金 ロス)

仕組み化なしにシステム化すると、何が起きるか:

  1. 要件定義が曖昧になる: 業務プロセスが頭の中にしかないので、エンジニアが正確に把握できない
  2. 「あれも欲しい、これも欲しい」が止まらない: 業務の本質が見えてないので、機能要望が膨張する
  3. 本番運用で必ず想定外が出る: 属人化した暗黙ルールが明文化されてないので、システムがそれに対応できない
  4. メンテナンスが地獄になる: 業務が変わるたびにシステムを変えないといけない (仕組みが弱いから)

逆に、仕組み化を先に終わらせると、システム開発は劇的に短く・正確になる。要件定義の品質が桁違いに上がるからだ。

§ 03 / 業務棚卸しの実務 8 ステップ

仕組み化の最初のステップは 業務棚卸し (業務の見える化)。当社が中小企業の受託開発で必ず最初にやる工程。

8 ステップで進める:

Step 1: 業務カードを書く (1 日)

  • 部門 / 担当 / 業務名 / 頻度 / 所要時間 / 関係者 を 1 業務 1 カードで書き出す
  • 最初は雑でいい。「営業: 見積もり作成 / 週 5 件 / 1 件 30 分 / 営業 + 経理」 みたいな粒度

Step 2: 業務間の依存関係を線で結ぶ (半日)

  • 「この業務は、あの業務の出力を待つ」というフローを可視化
  • ホワイトボード or Miro 等で物理的に描く

Step 3: 業務時間の実測 (1 週間)

  • 各業務に実際に何分かかってるか、現場担当が記録
  • 「30 分」と言っていたものが、実測すると平均 75 分だった、というギャップがよく出る

Step 4: 暗黙ルールの言語化 (2-3 日)

  • 「この場合はこうする、ただし XX のときは違う」のような属人化された判断を、すべて書き出す
  • ベテラン社員にヒアリングして、頭の中にしかないルールを引っ張り出す

Step 5: 業務の標準化 (1 週間)

  • 同じ業務を 3 人にやらせたら、品質が揃うか?
  • 揃わないなら、判断基準を文書化 して標準化する

Step 6: ボトルネックの特定 (1 日)

  • 「この業務がない / 遅いと、他の業務がストップする」箇所を特定
  • これがシステム化の最有力候補

Step 7: 「人がやるべき仕事」と「機械がやるべき仕事」の分離 (1 日)

  • 判断・関係性・責任 → 人
  • 計算・転記・繰り返し → 機械

Step 8: 仕組み化レポート作成 (2-3 日)

  • ここまでの結果を 30-50 ページのドキュメント にまとめる
  • これが、その後のシステム要件定義の 唯一の真実 になる

8 ステップで通常 3-4 週間。この期間が「無駄」と感じる経営者は多いが、ここを飛ばすと半年後にシステムが破綻する。

§ 04 / 仕組み化 → 設計 → 実装の正しい順番

業務棚卸しが終わって初めて、システム開発の出番が来る。正しい順番:

[1] 業務棚卸し (3-4 週間)
       ↓
[2] 仕組み化レポート完成
       ↓
[3] システム要件定義 (1-2 週間)
       ↓
[4] アーキテクチャ設計 (1 週間)
       ↓
[5] 実装 (8-16 週間)
       ↓
[6] テスト・本番化 (2-4 週間)
       ↓
[7] 引き継ぎ・運用ドキュメント整備 (2 週間)

中小企業の受託開発で、この順番を守ると、全体期間は長くなる が、プロジェクト成功率は劇的に上がる。

逆に、よくある失敗ケース:

[1] 「とりあえずシステム作って」(2 週間)
       ↓
[2] 実装 (4 ヶ月)
       ↓
[3] 本番化したら「想定外」が頻発 (現場運用回らず)
       ↓
[4] 修正 (3 ヶ月)
       ↓
[5] さらに修正 (...)

最終的には、最初に仕組み化に時間をかけたケースより、3-5 倍の期間と費用 がかかる。

§ 05 / 関西の中小企業の実例

兵庫県明石市の物流会社 S 社 (従業員 78 名) の事例。当初の相談:

「配車表が属人化してて、ベテランの配車係 1 名がいないと回らない。専用システム作って」

経営者の要望は明確だった: 配車システムの開発。

当社の提案は違った: 「最初の 4 週間は、業務棚卸しと仕組み化に使わせてください」。

経営者は「早く実装してほしい」と渋ったが、合意の上で進めた。

Week 1-2: 業務棚卸し

  • 配車業務を 38 個のサブ業務に分解
  • ベテラン配車係 1 名にインタビュー 6 回、計 12 時間
  • 「車両 A はこの時間帯は別件で使えない」「ドライバー B は子供の送迎で 18 時上がり」など、頭の中にしかない 87 の暗黙ルールを書き出し

Week 3-4: 仕組み化レポート

  • 暗黙ルールを「車両制約」「ドライバー制約」「顧客制約」の 3 カテゴリに分類
  • 判断ルールを 23 条のルールセット として文書化
  • 「こういう場合はこういう順番で判断する」というフローチャートを作成

ここで重要な発見があった: 暗黙ルールの 30% は、実は合理性が無かった。「前任者がそうしてたから」という理由で続いていた手順が多数。これを 合理的なルールに整理。

Week 5-6: 要件定義

  • 仕組み化レポートを基に、システムが扱うべき機能を 28 個に絞り込み
  • 当初の経営者の希望は 50 機能以上だったが、本質的に必要なのは 28 機能だった

Week 7-14: 実装 (8 週間)

  • Next.js + Supabase で実装。当初想定の 16 週間が 8 週間で完了
  • 業務ルールが完全に明文化されていたので、エンジニアが迷わず実装できた

結果:

  • 配車業務時間: 1 日 4 時間 → 45 分 (-81%)
  • 新人配車係の独り立ち期間: 6 ヶ月 → 2 週間
  • ベテラン配車係 1 名依存だった業務が、3 名でローテーション可能に
  • システムの仕様変更要求: 本番後 6 ヶ月でゼロ件 (仕組みがしっかりしていたため変更が必要なかった)

経営者の最初の言葉:

「最初に『仕組み化に 1 ヶ月』と言われた時は、正直『早く作って欲しいだけなんだ』と思った。でも結果を見ると、最後はあの 1 ヶ月が一番効いた」

§ 06 / 仕組み化スキップで起きる失敗パターン 4 つ

仕組み化を飛ばしてシステムだけ作った時に起きる典型的な失敗:

(1) 「Excel をそのままシステム化」: Excel の運用そのものが属人化していると、それをシステムに焼き直しても同じ属人化が再現される。

(2) 「機能の足し算が止まらない」: 業務の本質が見えてないので、現場が「あれも追加して」と言う度に機能が膨らみ、結果として誰も使いこなせないシステムになる。

(3) 「本番運用で例外処理が破綻」: 暗黙ルールが明文化されてないので、システムが想定する典型ケース以外の現実 (例外) に対応できない。

(4) 「メンテナンスコストが膨張」: 業務ルールが変わるたびにシステムを変えなければならず、運用後 1 年で 当初開発費の 30-50% の年間メンテ費 が発生する。

§ 07 / 「仕組み化だけで終わる」リスクもある

注意: 仕組み化が大事だからといって、仕組み化だけで止まるのもまた失敗。

業務棚卸しが終わったら、速やかに次のステップ (設計・実装) に移る べき。仕組み化のドキュメントだけ作って 6 ヶ月放置すると、業務が変化して内容が陳腐化する。

理想的なタイムライン: 仕組み化 4 週間 → 要件定義 1-2 週間 → 実装 8-16 週間 → 本番化 2-4 週間 で、トータル 4-6 ヶ月。これより長引かせると、業務側の現実が変化してしまう。

§ 08 / Closing ─ 「職人の受託」とは何か

当社の IT 事業の中心的な設計思想は、「丁寧に作る、御社に渡す」。

これは単に「品質を上げる」という話ではない。御社が、当社が抜けても自走できる業務基盤 を作るという意味だ。

  • 業務を見ずにシステムを作る → 御社の運用負荷が増える
  • 業務を見て仕組み化してからシステムを作る → 御社の運用負荷が減る

中小企業のシステム開発の成功率を構造的に上げる最大のレバーは、「最初の 4 週間に何をやるか」 にかかっている。

技術的な選定 (Next.js か React か、Supabase か Firebase か) は、その後の話。業務理解が、技術選定の前にある。

それが、関西の中小企業が IT 投資から本当のリターンを得るための、唯一の入口だと、当社は考えている。

本記事の数値は実在の受託案件を匿名化・抽象化した集約値で、複数案件の傾向を代表する例示として記述しています。

関連サービス: IT 事業 (受託開発) / IT 事業ハブ / 株式会社A.I.M について