情シス部の先人たちが残した、複雑な手組の開発システム　大阪の卸問屋が挑む、“昭和96年”を脱却するデジタル改革

昭和から変わらない、旧式の管理システムがもたらす悩み

井上恵氏：タイトルはズバリ、「それEAIでできるんちゃいますか？？（知らんけど）」です。箸休め程度の内容になります。キレッキレのエンジニアで、トイレに行きたい方は今のうちにどうぞ。嘘ですよ、ちゃんと聞いといてくださいね～。

まずは会社概要です。創業74年、大阪の長堀橋にある建築金物の卸問屋です。従業員170人、売上は80億円。拠点は大阪・東京・九州の3ヶ所です。事業の特徴として、問屋とファブレスメーカー（製品製造のための自社工場を持たない製造業）のハイブリッド企業を目指しております。

自己紹介です。井上恵と申します。2019年9月に現在の会社に入社しました。ASTERIA Warpとkintoneの利用は2021年6月からで、発展途上の初心者ユーザーです。矢沢永吉を心の師と仰ぎ、各種コミュニティ活動が大好きなオッサンです。「出会いからイノベーションが生まれる」という言葉を座右の銘にして、各種コミュニティに出没しております。

まず、当社の悩みです。卸業で顧客とメーカーをつなぐ役割のため、顧客からの注文データをすばやく正確に処理する必要があります。現在の販売管理システムは、昭和時代からの手組のシステムです。オフコン（オフィスコンピュータ）時代からのものを2006年にWindows化した、クラシックな仕組みです。

顧客の商品コード、自社の商品コード、メーカーの商品コードを変換しないといけません。顧客数の増加により、顧客ごとのWEB EDIの利用が増えてきます。今後もこの流れは変わらないでしょう。そのほか悩みごとは満載ですが、まずはこのあたりで。

人材の定着率が悪く、当時のシステム部の「勇者」はもういない

現状の流れです。顧客ごとにモデム通信、全銀手順（全銀協標準通信プロトコル）、JCA手順（流通業界向けに受発注データをやりとりするために作られたプロトコル）など、WEB EDIで各社単位のデータがやってきます。

それを昭和の基幹系（システム）で、顧客ごとに.NET Frameworkでプログラムを開発します。もしくは、退職した情報システム部の先人たちの得意なExcel VBA群など。要するに、電子取引の会社が増えるごとにプログラムを開発していたのです。

データで注文をもらう企業が増えると、Excelマクロが増えている。「基幹系のシステム、改修してるやん。なんでやー！」。過去の当社の情報システム部は人材の定着が悪く、平均4年で入れ替わります。その時にいた勇者が自分の得意な言語でマクロを作成したり、PHPで開発などなど……たくさんあります。もちろん現在は、その勇者はもういません。

世の中にはEAI（Enterprise Application Integration：企業内にあるシステムを連携させ、システムやデータを統合するソフトウェア）がごまんとあるやんか。なんで勇者たちはこれを選択しないで、手組で開発しているんだ？

当社がASTERIA　Warpにたどり着くまでの過程として、「国産だったら、DataSpiderとASTERIA Warpが有名どころ。『Qiita』の記事の数では、DataSpiderのほうがやや多い感じがするな」「どちらの製品もデータベース機能はないので、そこはkintoneを利用」「社内サーバーを持たずにサブスクのサービスが良いよね」「DELLさんが担いでいる『Boomi』も先端サービスなので将来性ありかも」といったものがありました。

また、AAのエバンジェリストさんから「『RPA（AA：Automation Anywhere）』でやれるのかも？」という意見をもらいました。ひとまず、評価版およびオンラインセミナーを受けて、どれが最適なのか、アタリをつけようかと考えました。当社の現在の基幹系システムはオンプレのOracleの10gです。

足を引っ張るのは、サポート終了したシステムとの接続

こちらは比較用の抜粋になるのですが、やはりネックはOracle10gとの接続です。2010年10月でサポートが終了の製品なので、これとの接続コネクターがある製品は皆無でした。しかし、どのEAI製品も内部にデータを保持できません。ここはやはり、価格の一番安いASTERIA Warp Core+でやってみようと考えました。

ASTERIA　Warpが月額で6万円、kintoneが7,500円（※プランによる）。個人的にはAutomation Anywhereでやるのもおもしろいとは思いましたが、今回はASTERIA Warpをやってみることにしました。

当社の基幹系を開発した、既存のメインベンダーさんに相談をしたら、「kintoneの1日当たりの制限値は1アプリにつき1万件の制限があるから、そんな使い方はできへんよ」「すべて新しいサービスの組み合わせなので実績はわからん」など、いろいろ言われました。

既存ベンダーさんから見ると、電子取引会社が増えるたびにプログラム開発したほうが儲かるからなのかな？　とも思いました。いずれにせよ、2023年のOracle NetSuiteが稼働しても残るものと考えました。幸い、Oracle NetSuiteはASTERIA　Warpとのコネクターもあるし、連携事例も多くあります。これが残る基盤です。

あらためて、各モジュールの役割を振り返ります。基幹系DB（データベース）とダイレクトにAPI接続できたらもっと楽なのですが、当社の基幹系DBはOracle10gです。この子がどこまで行っても足を引っ張ります。

ASTERIA Warpで得意先のWEB EDIからダウンロードされたCSVファイルを、kintoneにある商品コード変換表に従ってデータを加工します。その後、エラーがなくなった段階で、基幹系の受注データのレイアウトに変更します。

kintoneでは、自社商品コードと相手先商品コードの変換表の管理、ASTERIA　Warpでエラーが出たものをエラーファイルとして蓄積する機能、データで来る会社の受注データの一括保管の場所として考えました。こちらは実際のASTERIA Warpとkintoneの画面なのですが、非常にシンプルです。お化粧などはほとんどしていません。

「昭和96年のデジタル」からの脱却を目指して

実装するにあたり、製品選定の段階でもすったもんだし、実装段階でも当然すったもんだがありました。親子関係のデータ処理では、ある子明細でのエラーが出たら、同じ親明細も一括でエラーにします。これはRecordSQL、RecordFilterで実装しました。

「今回の仕組みをベースに、本当に横展開はできるのか？」というところですが、フロー変数などのパラメータを使ってフローを複製後にパラメータ変更をすることで、別の取引先用への転用を容易に作ることができました。

「フローが増えるにつれ、処理エラー時のリカバリーが大変」というところについては、コンポーネントで例外処理が発生時に、終了コンポーネントにつながるようフローを分岐させることで、フローを見れば例外処理を行っていることが一目でわかるように工夫しました。また、エラーログをkintoneに連携することで、容易にログを確認できるようになりました。

「kintoneを含めて、初物の組み合わせなのでうまく軌道に乗るのか心配」というところについては、今回は神戸デジタルさんにkintoneを含めて環境構築し、2社目以降は並走サポートで徐々に加速したいと思っています。

今後の予定です。現在はビギナー枠なので、Oracle NetSuiteの稼働までに脱ビギナーを目指したいと思っています。そのためにはASTERIA　Warpのコミュニティに参加して、達人さんたちの技を会得したいと思っています。

最近ASTERIA　Warpは、ローコード・ノーコードとアピールをしていますが、正直そんな製品がとは思ってもみませんでした。要は、言いようやな。あらためて、こちらの機能としての再認識をしたいと思っています。

VUCA時代にはアジャイルアプローチが必須です。それを実現する手段として、せっかく6万円を払っているので、使わないともったいないと思っています。これが私の「昭和96年のデジタル改革」のお話でした。みなさん、ご清聴ありがとうございました。