🗓️ 本記事は TRAILBLAZER Advent Calendar 2025 の参加予定記事です。
公開は12月15日を予定しています。

はじめに

今回の執筆は、TRAILBLAZER Advent Calendar 2025 の募集内容を拝見し、
「このテーマなら、自分の過去の経験が誰かの参考になるかもしれない」
――そんな思いで筆を取りました。

10年ほど前の経験ではありますが、
当時の試行錯誤の中で得た知見は、今でも十分に応用できる部分があると感じています。
システム環境や開発手法は今とは異なりますが、
小規模チームでの内製化を進める上での考え方として、
少しでもヒントになれば幸いです。

対応した現場の状況

クリックで展開

中小企業でシステムをどう内製化していくか。
これは、多くの企業が直面する課題だと思います。

私が過去に所属していたのは、ある業界の問屋業を営む中小企業でした。
業務効率化を目的にパッケージソフトを導入していたのですが、
実際に運用を始めてみると、現場の業務フローとマッチしていない部分が多く、
会計や売上管理など一部の機能しか活用できていませんでした。

導入を担当した社員も、思うように成果が出せなかったことで自信を失い、
次第に社内でシステム活用に関する議論が止まってしまっていました。
そうした状況の中で、私はシステム再活用のきっかけづくりを期待されて採用されました。

当時の私は、IT担当者としてある程度プログラムを作成できるスキルを持っていました。
ただし、開発の企画や仕様書作成といった上流工程には自信がなく、
「現場寄りの社内SE」として落ち着いて仕事ができれば、という思いで入社しました。

しかし、入社後に目にしたのは、
パッケージソフトを導入したものの活用しきれていない現場の姿でした。
システムの再生が求められる中、
私は「全部は作らない、でも諦めない」という方針を立て、
パッケージソフトの不足部分を“＋α”の工夫で補う取り組みを始めました。

本記事でお伝えしたいこと

本記事では、私がその会社で約6年間かけて実践してきた、
パッケージ＋αの内製化の記録およびシステム改善をまとめます。

完璧ではなくても、できる範囲で前に進む――
その積み重ねの中に、今の時代にも通じるヒントがあると感じています。

🧩 Step 1：現場を知る

クリックで展開

まずは現場でマスタ登録や仕入・売上入力の手伝いをしながら、
システムの実態を理解するところから始めました。

導入されていたパッケージソフトにはテスト系と本番系の2つの環境があり、
その元データベースには Oracle Database が使用されていました。
私は、パッケージベンダからユーザ名とパスワードを共有してもらい、
パッケージソフトの元データベースであるOracleの構造を直接確認しながら、
システム内部のデータの流れを理解していきました。

現場では、仕入・売上・出荷などの入力処理を担当者に教えてもらいながら、
実際の作業用PCとバーコードリーダを使ってデータ登録を行いました。
その一方で、Oracleのテーブル一覧を眺めながら、
入力データがどのように流れ、どこに蓄積されていくのかを丁寧に追いました。

さらに、パッケージ会社にも問い合わせを行い、
テーブル内容や項目の意味などについても理解を深めていきました。
この「現場とデータベースの両方から把握する」アプローチは、
後の改善活動において非常に大きな基盤になったと感じています。

💬 まとめ： 現場とシステムの両面を理解することが、後の改善の出発点になった。

⚙️ Step 2：データを動かす（Access・PowerShell活用）

クリックで展開

システムの構造を把握できたことで、次に私は「蓄積されたデータをどう活用できるか」という点に注目しました。
導入されていたパッケージソフトには、主に次の2つのデータ出力機能が用意されていました。

ある程度の集計が可能な BI機能
BI機能で表現できないデータを抽出するための CSV出力機能

しかし、入社当時の会社では、これらの機能を十分に活用できていませんでした。
現場では「どのデータをどう使えばいいのか」が判断できず、結果としてパッケージソフトはデータを蓄積するだけの存在になっていたのです。

🗂️ AccessとPowerShellによる補助ツール開発

また、日々の業務で必要とされる機能がパッケージ側に不足していたため、
私は自ら補助ツールの開発に着手しました。
開発には Access VBA と PowerShell を採用し、本番データへ接続してデータを活用できる機能を追加しました。

5日・10日ごとの仕入れ／売上集計表
　- 問屋業務では収支の把握が重要であったため、Accessのクエリで集計し、レポートとして出力しました。
過去売上の確認機能
　- 小売店ごとに異なる掛け率計算が存在し、毎日夕方に責任者が手書きで修正をし、担当者が入力していました。
　　そのため、責任者が前回売上掛け率を確認できるように、過去データから掛け率や売上履歴を照会できる仕組みを整備しました。

🔧 運用と共有の工夫

Access VBA と PowerShell を採用した理由は明確でした。
まず、一人で開発・運用することを前提としていたため、コンパイルが必要な言語は避けました。
その代わり、スクリプト型言語であるこれらを使い、
その場で改修・配布が可能な柔軟な運用を目指しました。

さらに、ツールが属人化しないよう、ファイルサーバに共通の保管場所を設け、
ツールごとにPowerPointで簡易マニュアルを作成して共有しました。

💬 まとめ： “スクリプト＋共有ルール”で、小規模でも持続可能な改善サイクルを作れた。

⚙️ Step 3：売上データの抽出の課題

クリックで展開

所属企業は問屋業であったため、メーカーへの販売実績報告や、小売店ごとの販売戦略を検討するうえで、
売上データの抽出が欠かせませんでした。
しかし、依然としてパッケージソフトからのデータ取得は容易ではなく、
私はその都度、必要なデータを抽出してExcel形式で渡す運用を続けていました。

この作業は地味ながら重要で、後に自動化や効率化に向けた改善の原点となりました。
同時に、依頼対応の増加に伴い、社内でのデータ運用の在り方について、
徐々に見直す必要があると感じるようになりました。

💬 まとめ： データ抽出業務を通じて、「見直しの必要性」に気づく段階に入った。

🌐 Step 4：だれでも利用できる仕組みを目指して

クリックで展開

売上データの抽出とBIツールの活用（社内向け）

多様な業務に対応していた私は、次第に社内での依頼が増え、
日々の作業が多忙になっていきました。
また、営業担当の方々にとっても「私がデータを握っている状態」は好ましくなく、
自分たちで売上情報を閲覧・活用できる環境を整える必要があると感じました。

しかし、当時は私一人で開発を担当しており、
自作ツールを増やしすぎると保守が難しくなります。
そこで、商用利用も可能な無償ツールを活用し、
できるだけ既存リソースを生かす方針を取りました。

当時はBIツールがまだ発展途上で、機能制限付きながら無料で利用できるものがいくつか存在していました。
そのうちの一つを選定し、営業担当者が自分で検索・抽出できる
売上データ閲覧環境を構築しました。

本番系への負荷と“情報系”への切り替え

構築を進めるうちに、自作ツールで本番系に直接接続してデータ抽出を繰り返すと、
パッケージソフトの動作が重くなるという問題が発生しました。
日中に私が参照作業を行っていると、
他の社員から「最近システムが遅い」と相談を受けることもあり、
データ参照が本番環境のパフォーマンスを圧迫していることが明らかになりました。

この問題を放置すれば、業務全体に支障をきたす恐れがありました。
私はこの点を懸念し、ダメ元でパッケージメーカに相談したところ、
テスト環境（テスト系Oracle）を情報系システムとして利用してよいとの承諾を得ることができました。

そこで、毎晩本番系の日次処理が完了した後に、
BIツールで利用するための集計データをテスト系データベースに自動登録・更新する仕組みを構築しました。
これにより、BIツールは本番系ではなく、この「情報系Oracle」を参照して動作するようになりました。

この仕組みによって、営業担当者は各自の担当小売店の売上状況をリアルタイムで確認できるようになり、
さらに上長から伝えられる売上目標との進捗を自ら把握できるようになりました。
結果として、営業担当者が自立的にデータを活用する文化が社内に広がり始めました。

データ提供の自動化（社外向け）

営業担当者向けのデータ環境整備が完了した後、
次に着手したのは社外向けデータ提供の自動化でした。

当社では、営業担当が取引先に対して定期的に売上データを送付しており、
その内容は主に以下の2種類でした。

小売店向け：売上情報（小売店が仕入データとして利用）
メーカー向け：販促・製品分析用の売上情報

これまでは、依頼があるたびに私がデータを抽出し、
手動でExcelやCSVをメール送信していました。
しかし、この運用では担当者の負担が大きく、
送信のタイミングも人によってばらつきが生じていました。

そこで、プログラムで複雑に作り込みすぎず、
誰でも再設定・再利用できる方法を検討した結果、
OSSのETLツールを活用する方法を採用しました。

ETLツールを使い、本番系データを自動的に集計・CSV化し、
毎朝決まった時間にWindowsタスクスケジューラで実行するよう設定しました。
生成されたファイルは所定のフォルダに保存され、
別の自動メール送信ツールがそのファイルを添付して送信する仕組みです。

この仕組みによって、営業担当者は煩雑な送付作業から解放され、
メーカーや小売店には決まった時間に正確なデータを届けられるようになりました。
結果として、当社は取引先からの信頼を高め、
データ提供による付加価値を生み出すことができたと感じています。

💬 まとめ：

社内向けにはBIツールを導入し、「だれでも見られる」環境を構築。

社外向けにはETL＋メール自動送信で、「確実に届く」仕組みを整備。

本番系の負荷を回避しつつ、現場と外部の両方に“自立したデータ活用の流れ”を作れた。

🏁 Step 5：成果と課題（6年間の定着）

クリックで展開

ここまでの取り組みは、入社からおよそ3年間の間に進めてきた内容です。
Access VBAやPowerShellによる個別対応を積み重ねながら、
最終的にはパッケージソフトを中心に据えたデータの一元化と自動化を実現しました。

この期間は、技術的な仕組みづくりと、現場がそれを使いこなすための環境整備に注力した時期でもありました。

社内事務作業の軽減に向けた後半3年

後半の3年間は、より実務に根づいた改善を進めていきました。

当社が属していた問屋業界は、世間よりもデジタル化が遅れており、
仕入伝票を毎日手入力する運用が長年続いていました。
その影響で、経営層が利用する5日・10日ごとの集計処理に遅延や誤差が発生し、
在庫数量の不整合も頻発していました。

さらに、取引先の多くは中小規模のメーカーであり、
売上データをExcelなどで提供してくれる企業はごく一部に限られていました。
そのため、仕入データの正確性を上げるには、
取引先との調整を地道に進めていく必要がありました。

私は、取引先が当社を訪問するタイミングを活かし、
毎年数十社ずつにデータ提供の協力をお願いしました。
数年にわたる取り組みの結果、
退社する頃には**仕入高の約70％にあたる取引先（50社以上）**から、
定期的にデータを受け取れる体制を築くことができました。

データ文化の定着と社内外の信頼構築

この成果は、システム開発だけでなく、
社内外を巻き込んだ業務文化そのものの改善であり、
この6年間の取り組みの中で、最も意義のある成果だったと感じています。

社内では「データを集めて分析する」だけでなく、
「データをもとに行動する」意識が芽生え、
営業や事務処理の現場からも改善提案が出るようになりました。

また、外部の取引先からも「データを出してくれる会社」として信頼を得られ、
単なる業務効率化を超えた協業のきっかけにつながったと考えています。

💬 まとめ： 内製化は“開発”ではなく、“文化の育成”である。小さな改善の積み重ねが信頼を生み、データ文化が根づいていった。

💡 Step 6：今ならこうする（RPA・サブスク活用）

クリックで展開

6年間の取り組みを振り返ると、私が実践していた「パッケージ＋α」の考え方は、
現代の技術環境にも通じる普遍的な考え方だと感じます。

ただし、当時とは利用できるツールやサービスが大きく変わり、
より手軽に、より安全に自動化を進められるようになりました。
ここでは、もし今の環境で同じ課題に取り組むなら、
どのような手法を選ぶかについて整理してみます。

RPAによるノーコード自動化

私が当時利用していたETLツール（データ変換ツール）は、
無償で使えるものが限られており、設定や運用にも一定の知識が必要でした。
現在では、同等の処理をRPAツールでノーコードに実現できる時代になっています。

データ抽出や変換、ファイル出力、メール送信などの一連の流れを
GUI上で設定できるため、非エンジニアでも自動化を進めやすくなりました。
もし今の時代に同じ業務を再構築するなら、
ETLツールではなくRPAによる自動化を進めていたと思います。

RPAは、開発者がいなくても運用担当者が自ら処理を追加・変更できる点で、
“＋α”を現場が自ら作れる仕組みとして非常に有効です。

クラウド型BIツールの活用

当時利用していたBIツールは、無償で利用できる範囲が限られており、
数年後には有償ライセンスへのリプレースが必要となりました。
その際、会社では100〜200万円ほどの導入費用をかけて
オンプレミス型のBIツールを購入していました。

もし今の時代に同じような選択をするなら、
私はクラウドライセンス型のBIサービスを選んでいたと思います。
クラウド型であれば初期投資を抑えながら利用を開始でき、
トライアル期間中に「どの程度の活用ができるか」を試しながら調整することができます。

加えて、クラウドサービスではチーム共有や権限設定も容易であり、
**“みんなが気軽に見て活用できるBI環境”**を低コストで整備できる点が魅力です。

クラウドによるデータ送信・通知の自動化

小売店やメーカーへのデータ送信についても、
当時は偶然、社内で購入済みだったメールアプリのライセンスを活用していました。
現在であれば、クラウドのメッセージングサービスを組み合わせることで、
より柔軟で安全な自動送信機能を構築できたと思います。

たとえば、Azure Logic Apps や Power Automate のようなサービスを利用すれば、
ファイルの生成からメール送信、ログ記録までを一連のフローとして定義でき、
監査や再送の管理も容易です。

このような仕組みを導入していれば、
運用担当者がGUIで確認しながら自動化の設定を管理でき、
より継続的に利用できるシステム基盤を築けていたと感じます。

“＋α”の本質は「現場が使えること」

振り返ってみると、当時の“＋α”の工夫は、
すべて“現場が自分で活用できるようにする”という目的に基づいていました。
今でこそRPAやクラウドサービスが一般化しましたが、
その根底にある考え方――「技術を目的ではなく手段として活かす」――は、
これからも変わらないと思います。

完璧なシステムを作るのではなく、
現場が自走できる仕組みを一歩ずつ整えていく。
それこそが、「全部は作らない、でも諦めない」内製化の本質です。

💬 まとめ： 技術が進化しても、“＋α”の本質は変わらない。重要なのは、現場が使い続けられる仕組みをつくること。

✍️ おわりに

完璧なシステムを作るのではなく、
現場が自走できる仕組みを一歩ずつ整えていく。
それこそが、「全部は作らない、でも諦めない」内製化の本質だと感じています。

こうした考え方に至った背景には、
私が入社した当時、社内で「システムが何をできるのか」を理解している人がほとんどいなかったという現実がありました。
要望はそれぞれの担当者の頭の中にあり、明文化もされていなかったため、
私は一つずつ話を聞き、動かせる範囲から改善していくしかありませんでした。

さらにもう一つ大きな要因として、
会社はすでにパッケージソフトの導入に相応のコストをかけており、
それが十分に活用できていなかったという背景がありました。
新たに費用を投じてシステムを再構築することは現実的ではなく、
「いまある資産を最大限に活かす」以外の選択肢はなかったのです。

また、開発者が自分一人だったこともあり、
すべてを完璧に作り込むのではなく、要望に沿った部分から順に形にしていくという進め方を選びました。
それぞれの機能には簡単なマニュアルと振り返りポイントを設け、
誰が見ても動かせるように意識してきました。

結果として、この積み重ねが社内に「自分たちでも改善できる」という意識を生み、
現場がシステムを“活用する側”から“育てる側”へと変わっていったように思います。

💬 まとめ： 内製化とは、システムを作ることではなく「人と仕組みが成長するプロセス」である。