ジョブ運用環境 改善事例①

毎年、多くのJP1ユーザー様が集まり、リアルな課題やノウハウを共有する「JP1ユーザー会」。2026年のテーマは「運用ノウハウ共有の年」です。

今回は、株式会社ゴールドウインの島野 郁也氏と福田 拓也氏による事例発表の様子をお届けします。「ザ・ノース・フェイス（THE NORTH FACE）」などのブランドを展開する同社で、JP1経験1年未満のお二人が、DWHやEDI運用の現場で、どのような気づきや苦労があったのか。それぞれの言葉でありありと語っていただきました。

JP1を活用した分析用データ加工の仕組みづくり

ゴールドウインが目指すものと私たちのミッション

ゴールドウインは1951年の設立以来、「モノづくり」「コトづくり」「環境づくり」の3つを軸に、スポーツやアパレルを通じて人々の新たな挑戦を支えてきたライフスタイルクリエイティブカンパニーです。製品の開発から販売までをすべて自社で一貫して手がけているのが大きな特徴です。

私と福田は、管理本部システム部でインフラの構築や運用保守をメインに担当しています。実は私たち、ともにJP1に触れてからまだ1年未満というビギナーです。そんな二人が挑んだ、DWHとEDI運用におけるバックエンド処理の運用効率化の舞台裏をお話しします。

データ連携の基盤としてJP1を導入

弊社のDWHとEDI運用では、上位システムや周辺システムからデータを連携する際、各バッチ処理を個別に管理しています。そのため、日次で実行されるジョブ全体を体系的に把握できず、障害発生時にはリカバリポイントの判断や復旧作業そのものに課題がありました

こうした課題を解決するため、データ連携基盤としてJP1を導入することとしました。

本取り組みの目的は、基幹システムや周辺システムからデータを抽出し、DWH向けに加工したうえで、社内へ情報を提供することです。

ユーザーに価値あるデータを届けるための仕組みづくり

実際のシステム構成ですが、まず左上にあるJP1のホスト兼バッチ実行用のファイルサーバーからジョブが走ります。下部にある「データレイク」と呼ばれる基幹システムのデータ格納場所からデータを抽出し、その隣にあるエージェントサーバーを介して、まずはOracleの利用者側データベースにコピーデータをインサートします。

ここからさらに、データを2次加工するジョブがホストから実行されて、データを加工していく流れです。

なぜわざわざ加工が必要なのかというと、基幹システムのデータをそのままユーザーに開示しても、分析用としては非常に扱いづらいという課題があったからです。ここにはゴールドウインが長年培ってきた分析のノウハウが詰まっています。それをJP1上でどう実現するかについては、パートナーであるアシストの力も借りながら、データ加工の処理を実装しています。

また、Oracleなどで特有のエラーが出たときには、JP1側で確実にエラーをハンドリングし、私たち運用チームへメールを通知する仕組みも今まさに作っているところです。

OS標準にはない、JP1の自動リカバリや柔軟なジョブ連携

JP1について何も知らない状態から手探りでジョブを作ってきたなかで、いろいろな気づきがありました。

例えば、社内にはOS標準のタスクスケジューラで動いている処理がいくつかあります。ただ、タスクスケジューラだと、エラーが起きたときの「自動リカバリ」や「エラーの回避」が難しいと感じていました。また、サーバー間の連携を組むのも正直厳しいなと思っていました。

その点、JP1を入れてみて感じたのは、標準機能としてリカバリジョブや自動リトライの機能があるため、非常に使い勝手が良いということです。ファイル、イベント、待ち合わせなど、用途に合わせて柔軟に連携方法を選択できるのは、ものすごくメリットだと感じています。

経験が浅いからこそ感じた「やりたいことの言語化」の難しさ

一方で、経験が浅いからこその課題もありました。まず、JP1のメール送信機能で通知される情報が多すぎるのかな、という点です。

また、何か実現したいことがあっても、それをアシストに問い合わせるための「言語化」がものすごく難しかった、ということも痛感しました。

そこでアシストへの相談としては、例えば生成AIを介することで私たちが実現したい要件を上手く言語化して伝えてくれる、そんな仕組みがあったら非常に良いなと思っています。

今後は、アプリのログや特定のエラーを、もっと簡単にキャッチしたいと考えています。必要な箇所のみをメール通知できるようなマクロ変数なども、これから使ってみたいですね

ほかにも、RPAを使ってSaaSからCSVデータを出力している処理があるので、そういった処理も将来的にはJP1を使ってAPI実行する処理が実装できればと考えています。

EDIデータの送受信バッチファイルをタスクスケジューラからJP1へ移行

アパレルメーカー業務に不可欠なEDIデータ送受信バッチをJP1へ移行

アパレルメーカーである弊社は日々、全国の取引先様と膨大な注文・発注データをやり取りしています。今回は、従来タスクスケジューラで動かしていたその送受信バッチをJP1へ移行した事例をご紹介します。仕組みはシンプルですが、現場の運用を大きく変える第一歩となりました。

※EDIは企業間で注文書や発注データなどを電子的にやり取りする仕組みです。

JP1への移行で実感したメリットと、日々の運用で気づいた4つのポイント

タスクスケジューラからJP1へ移行して最大のメリットだと感じているのは、「わざわざ対象のサーバーへログインしなくても、タスクの実行状況やスケジュールを一つの画面で容易に把握できるようになった」という点です。

その一方、JP1を実際に運用してみると、経験が浅いからこその気づきがありました。

1. エビデンス採取の手間
   JP1の実行登録を行う際、リリース日や対象とするジョブネット毎にエビデンスを取得する必要があり、手間がかかるので簡略化したい。

2. カレンダー設定の共通化
   現在はルートジョブネットなどの単位で個別にカレンダーを設定しているが、これを共通化したい。

3. Webコンソールのダッシュボード確認期間
   現状のWebコンソールの機能だと、翌日までしか実行スケジュールが確認できないので、翌日以降のスケジュールもWebから確認できるようにしてほしい。

4. ダッシュボード設定情報の共有
   Webコンソール上にダッシュボードを作成できるのは良いが、現状はユーザーが個々で設定する仕組みなので、ダッシュボードの設定情報を複数の運用担当者に横展開したい。

JP1の豊富な機能を誰もが活かせる「テンプレート集」への期待

JP1を使い始めて間もないからこその悩みですが、JP1はコマンドや機能が非常に多い分、社内に有識者がいないと使いこなすのが難しいと思っています。

「こういうときはこれをベースにすればいい」という『機能のテンプレート集』のようなものが欲しいというのが、いま一番の要望です。

編集後記：ユーザー会事務局より

ユーザーに価値あるデータを届けるための工夫や、問い合わせる際の言語化の難しさ、エビデンス採取の手間といった試行錯誤は、多くのユーザー様が共感できる内容だったのではないでしょうか。また、今回いただいた数々の率直なご要望は、私たちアシストにとってもサービス向上への大変貴重なヒントとなりました。こうした「生の声」を共有し、互いに高め合える「横のつながり」こそがユーザー会の最大の魅力です。

JP1ユーザー会は長年運用を続けているベテランの方だけでなく、今回のようなJP1を使い始めたばかりの方でも、明日からの運用に活かせるリアルなヒントを持ち帰れるコミュニティです。「他社の新人はどうやってJP1を覚えているんだろう？」「自社の運用も、そろそろ見直してみたいかも」そう感じた方は、ぜひ次回のユーザー会へ足を運んでみてください。あなたと同じ目線で悩む仲間たちが、ここだけの貴重な体験談を用意してお待ちしています！

次回開催