ローコードで「倉庫管理システム」を4カ月で内製リプレース 調味料メーカーのダイショーが語る、非エンジニア中心で成功に導けた理由、実践のポイント：「改善活動が発展」「失敗してもいいのでトライする」 ダイショーの内製化戦略

2025年6月4〜5日に開催された「＠IT 開発変革セミナー 2025 Spring」の基調講演で、調味料メーカーであるダイショーの松井伸明氏が登壇。同社における倉庫管理システムの内製リプレース事例を踏まえ、ローコード開発を成功に導くポイントを解説した。

[加山恵美，＠IT]

　多様な調味料の製造、販売を手掛けるダイショー。1966年12月の設立以来、独自の商品開発力で日本の調味料市場に数多くの商品を提供してきた。特にロングセラーとなる「味・塩こしょう」は1968年の発売以来、家庭や業務で愛用されている。他にも、「博多　もつ鍋スープ　しょうゆ味」「きのこがおいしい！　アヒージョの素」などの液体調味料や粉末調味料など、年間で300品目以上の新商品を開発し、市場に投入している。

　そんな同社は、2005年ごろから非エンジニア職によるアプリケーション開発を進めている。工場の生産部門のメンバーが主体となり、ローコード開発ツールを用いた内製開発で業務改善を推進してきた歴史がある。近年では、非エンジニアが中心となり、倉庫管理システムなどコア業務を支える既存システムのリプレースにも内製で挑んだという。

　業務アプリケーション開発に取り組んできたダイショーの松井伸明氏（営業本部 部長代理）が、内製開発やローコード開発を成功に導いたポイントを紹介した。

業務環境の変化が激しい中で、内製開発を選択

ダイショー 営業本部 部長代理 松井伸明氏

　ダイショーで品質や食品安全の取り組みに関わり、近年ではローコード開発ツールに出会い非エンジニアという立場で内製開発に取り組んでいる松井氏。趣味は山登りとのことだが、山登りとローコード開発には共通する部分があるという。

　「どちらも目的に向かって自分のペースで進めることができます。山登りなら頂上、ローコード開発なら解決したい業務課題です。どちらも、ルート選びが重要であること、仲間との協力、共有があると心強いこと、また達成感と自己成長が感じられます。どちらもハードルが高そうに聞こえるかもしれませんが、本質の部分が共通しているからこそ、非エンジニアの自分なりに今まで進めてこられたと考えています」

　そもそも、なぜ同社は内製開発に注力してきたのか。松井氏は「潤沢な資金を投入すれば、完璧に近いアプリケーションを構築できます。それで業務生産性が速やかに向上するなら、それも正解だと思います。ただ、業務環境は激しく変化しており、柔軟かつ迅速に対応できなくなることを危惧した結果、自分たちの業務範囲では自ら考え、作り、修正できる環境を求めて、2005年ごろから内製化を選択してきました」と話す。

内製開発は生産工場から始まり、他部門へと展開

　ダイショーにおけるアプリケーション開発の内製化はまず、生産工場における情報共有のための掲示板アプリケーションから始まったという。そこから生産部門では、「製造現場の計画指示にまつわる生産管理」を、品質保証部門では、「商品の検査や検証にまつわる品質管理、環境面での労働安全管理、トレーサビリティーといった食品安全管理」といったように、幅広い業務において内製開発の取り組みが広がっていったという。

　同社の開発部門では、商品設計、レシピや製造工程にまつわる仕様管理、原材料の評価や採用の管理、検証記録、技術情報共有のためのアプリケーション、品質や食品安全では、顧客に提出する商品情報管理、あるいは顧客からの苦情や相談の履歴を管理する受付アプリケーションなどを構築、運用しているという。

（松井氏の講演資料より）

　全社的に内製開発が広まった背景として、松井氏は「業務改善活動への意識」を挙げる。「小さな改善を積み上げて全体の効率を高めること、品質を向上させる取り組みは工場における日常的な習慣や文化のようなものです。ローコード開発を採り入れることは、こうしたものに自然とマッチするものだと実感しています」（松井氏）

　松井氏は組織内でローコード開発ツールによるアプリケーションを活用する効果は3つあったとした。

1. 情報共有の効率化：メンバー間のコミュニケーションが強化できた
2. 業務効率の改善：プロセスを合理化することで生産性が向上した
3. チームワークの促進：組織内のメンバーを巻き込むことで、チームワークと参加意識が高まった

　「特に成果がすぐに見えるので、開発者たちはやりがいを実感できる」という。そのため開発者の成長とモチベーションが向上し、副産物としてスキル開発や仕事の満足度向上にも発展した。

　松井氏は「取り組むスタンスはやはり改善活動だと思います。当初はローコード開発といったかっこいいフレーズはありませんでしたが、多くの効果が得られたことで組織内で広がり、発展していきました。ローコード開発ツールを内製開発で活用することは組織内に多くのメリットや効果をもたらしてくれます」と強調する。

老朽化した倉庫管理システムのリプレースを、社内協力のもと内製開発で実現

　生産工場の文化で培われたローコード開発の活用は、関係者の部署異動をきっかけに他部門へと広まることもあった。その一例が倉庫管理システムだ。同社の物流部門には長期で使われて老朽化した倉庫管理システムがあり、早急なリプレースが迫られていた。そうした中で、生産部門から物流部門（と経営企画室を兼務）に異動した人物をきっかけに、内製開発による取り組みがスタートしたという。

　「外部ベンダーに老朽化したシステムをリプレースするための見積もりを依頼した結果、『納期は1年、費用は数千万円』と返ってきました。一方、内製開発で試算すると『3カ月で数百万円』となりました。失敗したら、外部ベンダーにあらためて依頼してもいいので、まずは内製開発でやってみようという機運が高まったのです」

　倉庫管理システムは、ダイショーの商品の入庫管理、ロット管理、出庫管理、在庫の追跡をリアルタイムでトレースできるようなシステムになっている。工場で生産された商品は一度倉庫に保管され、顧客からの注文に応じてスーパーや問屋などへ出荷する。

　他にもピッキングや出荷作業を効率的に指示し、倉庫内の商品の保管や配置を最適化することでスペースを有効活用するためのロケーション管理、物流会社へのデータ送付や帳票、ラベル発行など、倉庫内の業務全般も管理する。そのため、基幹システムとのデータ連携も必須となり、コア業務を支える重要なシステムだ。

　情報システム部、物流部、経営企画室が倉庫管理システムのリプレースに携わり、情報システム部は既存システムの仕様確認、環境構築、基幹システムとの連携を、経営企画室は社内でのコンセンサス取得、スケジュール管理、アプリケーションの設計や開発をとりまとめていった。

　松井氏は「もし倉庫管理システムの内製によるリプレースが成功すれば、全社的なDX（デジタルトランスフォーメーション）や開発生産性向上の取り組みに弾みがつくのではないかという狙いも含まれていました。業務を担当する物流部門のメンバーが積極的に設計、開発に携わったこともリプレースを成功できた理由の一つだと考えます。情報システム部は業務内容を見極めながら改善のリクエストに全力で応えていく一方、業務部門のリクエスト通りにせず汎用（はんよう）性を持たせる代替案を提示するなど、丁寧に課題と向き合い、互いに連携したことが最大の成功の秘訣（ひけつ）だったと感じています」と話す。

　普段なかなか接点がない部門間での横のつながり、あるいは縦のつながりが生まれたことも、松井氏には大きな魅力に映ったという。

　「当時は現場の期待に応えたいと時間も忘れて構築に熱中するあまり、総務人事部から『PCのログ履歴が日付をまたいでいます』と指摘された月もありました」

　プロジェクトの起案からリリースまで4カ月の間にミーティングを10回実施し、現場部門と仕様調整や改善検討会は3回、テスト検証は3回実施した。当初の計画とほぼ近い期間で立ち上げることができた。リプレース後のシステムには大きなトラブルもなく、細かな改善を重ねることで現在もしっかり稼働している。定量的には、新しい倉庫管理システム稼働後は時間外労働を20％削減する成果も得ているという。

倉庫管理システムのイメージ（松井氏の講演資料より）

　後に、松井氏は現場担当者から報告や感謝を受けると「一番うれしく、成果を感じましたし、こうして企業の改善文化にローコード開発が根付いていくのだと実感した瞬間にもなりました」と話す。

ローコード開発を成功に導くため必要な役割

　松井氏は同社の取り組み事例を踏まえた上で、ローコード開発においては役割分担が重要だと振り返る。まずは、従来のシステム開発と同様、プロジェクト全体をマネジメントするプロダクトマネジャーだ。適正な人員を見極め、組織のつながりを整理し、環境を整え、失敗を恐れさせないように後押しして、プロセスや結果を適切に評価できると理想的だ。

　そして次は、アプリケーションの設計／開発者だ。ただローコードツールで構築するだけではなく、ユーザーにしっかりと寄り添い課題を抽出し、的確に、継続的に改善することで、より良いアプリケーションへと成熟させていく観点が求められる。また業務部門のユーザーもただ与えられたツールを利用するのではなく、自らの生産性を俯瞰（ふかん）し、継続的に改善活動に取り組むことで、価値ある取り組みにつながっていくとした。

　そしてこれらの取り組みを、情報システム部門が環境面でフォローすることで、組織内でローコード開発ツールの活用が進み、組織に根付いていくとした。

ローコード開発ツールの選定とリスク

　ダイショーでは、複数のローコード／ノーコード開発ツールを併用している。松井氏は「自社環境や業務に応じて選択すべきです。開発側も運用側も使い勝手が悪ければ必然的に使わなくなりますし、自社の環境や業務にマッチして使いやすければ、必ず残ります」と言う。

　ローコード開発ツールの選定ポイントについて、松井氏はそれぞれの観点から以下のようなポイントを挙げた。

• 使い勝手：「そもそも自社環境に合わなければ使いものにならない」
• 実績：多くの企業で導入実績があれば「まあ安心だよね」と感じられる上、「その感覚は意外と正しい」
• 学習機会：未経験の人が開発しようとすると、どうしても壁にぶつかることがある。その時にセミナーや研修など学べる機会があると、壁を克服できる可能性がある
• サポート体制：壁にぶつかった場合、サポートがあれば壁を乗り越えてアイデアを実現できる。もしなければ挫折して終わってしまうかもしれない

　またローコード開発を推進するにしても要求レベルはさまざまだ。難しいプログラミングが必要になると開発のハードルは上がり、逆に簡単だと開発に制約が出てしまう。そうしたバランス感覚を考えることも重要だとした。そしてローコード開発を推進する上では以下のような注意点を挙げた。

セキュリティリスク

　特に、個人情報や顧客情報の漏えいリスクだ。基幹システムにある情報と連結させるとこうしたリスクが生まれる。機微な情報との連携は「必要最小限に」と松井氏は助言する。

業務停止のリスク

　ローコード開発で構築されたアプリケーションが業務に幅広く活用されるようになればなるほど、業務が停止するリスクは大きくなる。ダイショーでは拠点や部署ごとにアプリケーションサーバや保管場所を区切るなどしてシステムダウンの影響を最小限に、また毎日バックアップして破損しても復旧できるような状態で運用しているという。

データ管理

　データの消失や改ざんのリスクに備えるために、ログを残すこと、バックアップが大切だとした。

法令順守

　電子帳簿保存法など、業務ごとに順守しなければならない法令がある。ダイショーでは監査室と連携し、必要な範囲で監視可能な体制を組んでいるという。

ツール／アプリケーションの乱立リスク

　自由すぎれば、いわゆる「野良アプリケーション」が増加し、管理できない状態に陥るリスクがある。逆にルールを厳密化しすぎると、開発の足かせになりかねない。そうした中でもダイショーでは幅広く使われることを優先し、自由に開発できる環境を整備している。ただ、部署単位を越えて使用するアプリケーションでは、一定のルールに基づいてサーバで管理し、共有化して運用するようにしている。

　「ダイショーでは『まずはやってみよう』というスタンスでローコード開発はスタートしました。これから取り組んでみようと思われる会社さまも『まずはやってみよう』というスタンスで取り組まれてはいかがでしょうか」と松井氏は呼び掛ける。

周囲を巻き込むことが、成功の近道に

　松井氏は、大きく注目されている生成AI（人工知能）の活用も検討しているという。「ローコードで組むアプリケーション自体も、そのうちAIが作るようになるかもしれません。自分たちの武器となるような、業務に即したアプリケーションに育てるためのアイデアや課題は現場に潜んでいるので、それらを抽出して、選択して、改善を試みるのはわれわれに委ねられていると考えています」と期待を寄せる。

　最後に松井氏は「リスクばかり考えず、チャレンジすることが重要です。改善活動というスタンスで推進すれば必ず成果が生まれます。またローコード開発は『作ったら終わり』ではなく、設計、開発、運用、改善のサイクルを何度も継続することで実践の効果を最大化できます。そしてこれらの取り組みを、1人で全て任されたら大変困難です。周囲の人や組織を巻き込みながら取り組んでいくことが成功の近道です。IBM初代社長のトーマス・J・ワトソン・シニア氏は『早く成功したいなら、失敗を2倍の速度で経験することだ。成功は失敗の向こう側にあるのだから』と言いました。ローコード開発ツールを活用した内製化も、常にこのマインドで取り組んでいきます」と述べ、講演を締めくくった。