1. プロジェクトの始動と成果
かねてより当社の懸案事項であった「販売管理システム」を、ついにFileMakerを用いた自社開発によって導入・運用開始いたしました。
事務所のPCおよび現場のiPadを連携させ、受注・発注・納期管理から在庫状況までを一元管理する仕組みを構築しました。これにより、従来の手書き台帳やExcelへの転記作業に費やしていた工数が劇的に削減され、業務効率化の実感を得始めています。
システム構成としては、通常業務を行う「販売管理インターフェース」と、製造現場で使用する「アセンブリ業務専用メニュー」の2画面構成を採用。業務フェーズに合わせてUI（画面操作）を切り替えることで、現場の使いやすさを最優先に設計しました。
2. なぜ「完全自社開発」を選んだのか
今回、パッケージソフトの導入や外部委託ではなく、自社開発に踏み切った最大の理由は、「急激な業務プロセスの変更による現場の混乱」を避けるためです。
完成された大規模なシステムへ一括移行（ビッグバン移行）するには、長期の準備期間と現場への多大な負荷が必要です。業務の一つ一つを棚卸しし、「当社にとって最適なIT化とは何か」を検討した結果、たどり着いた結論は**「小さく作って大きく育てる（アジャイル型開発）」**というアプローチでした。これが当社の企業文化と規模に最も合致していると判断しました。
3. 導入前の課題：アナログ管理と情報の属人化
導入のきっかけは、紙ベースの管理台帳と、担当者ごとに形式が異なる「Excel管理」によって業務が圧迫されていたことでした。
月間200～300件の受注をExcelで管理しつつ、詳細な部品台帳（図面・過去の履歴・加工の注意点など）はすべて「紙」で管理していました。そのため、以下のような非効率なワークフローが常態化していました。
- 情報の断絶： 受注1件ごとに分厚い台帳バインダーを開き、図面や単価を目視確認する必要がある。
- 多重入力の手間： 「受注→1次発注→入荷→2次発注…」といった工程が進むたびに、台帳を取り出し手書きで追記しなければならない。
- 検索コストの増大： 過去の履歴調査や在庫確認のために、物理的に倉庫へ移動したり書類をめくったりする時間が膨大。
経営者や管理者がこうした事務作業に忙殺され、本来注力すべきマネジメント業務を圧迫している——この「時代に即さない現状」を打破する好機となったのが、京都府が実施する「サービス等生産性向上支援事業（補助金）」でした。
4. IT化を阻む「3つの壁」
しかし、「補助金があるから」といって簡単にDX（デジタルトランスフォーメーション）が成功するわけではありません。「そんなに簡単なら、どこも苦労はしていない」というのが本音です。 実際にプロジェクトを進めるにあたり、以下の3つの大きな課題（壁）が立ちはだかりました。
① コストとROI（投資対効果）の壁
外部の専門ベンダーに開発を依頼すれば、高級外車が購入できるほどのイニシャルコスト（初期費用）が想定されます。さらに、ランニングコスト（サーバー費・保守費）や、将来的な改修費用、ソフトウェアのライフサイクル（寿命）による再構築リスクも考慮しなければなりません。 「要件定義（作りたいものの仕様決め）」が難しいシステム開発において、かけた費用に見合う効果が得られるのか、投資判断が非常に難しい点でした。
② 「人」とITリテラシーの壁
これが最大の課題です。「人がITに合わせるのではなく、ITを使いこなせるか」。 長年慣れ親しんだ業務フローを変えることへの心理的抵抗（レジスタンス）や、PC操作に不慣れな社員への教育。 「最初は大変でも、将来必ず楽になる」というビジョンを共有し、組織全体のITリテラシーを底上げできなければ、どんなに優れたシステムも形骸化してしまいます。
③ 導入・データ移行の壁
システム化にあたり、アナログで管理されている膨大な「暗黙知（ベテランの頭の中にあるノウハウ）」や「紙データ」をどうやってデジタル化するか。 開発会社へ正確に意図を伝えきれなければ、使いにくいシステムができあがり、結局Excelや手書きメモが残る「二重管理」になりかねません。また、稼働に必要な商品マスターデータの移行作業（データマイグレーション）を誰がいつやるのか、というリソースの問題もありました。
5. 不退転の覚悟で挑む
数多くの懸念や不安はありましたが、当社はこれらを乗り越え、未来へ進むために「不退転の覚悟」でプロジェクトを始動させました。 まずは第一関門である京都府の補助金申請を行い、無事に審査を通過。いよいよシステム開発への挑戦が始まります。
（次回へ続く）
【編集協力】 このプロジェクト記録の文章表現は、Gemini（Google AI）による構成案の作成および校正支援を受けています。