抜け漏れが起きがちな「エラー処理の設定」、未然にどう防ぐ？　“うっかりミス”にも即座に対処する、ASTERIA Warp活用術

ASTERIA Warpユーザーが語る、運用課題を解決した事例

森慶輔氏（以下、森）：アステリア株式会社第1営業部で営業をしております、森と申します。本日は、NX情報システム株式会社の林さまにご講演いただきます。よろしくお願いいたします。

林一輝氏（以下、林）：よろしくお願いします。

森：では、まずは林さまから簡単な自己紹介をしていただければと思います。

林：NX情報システムの林と申します。本日はユーザー事例として、「運用課題から考える連携基盤の設計」というお話をさせていただこうと思っております。よろしくお願いいたします。

さっそくですが、最初にタイトルについて少しお話ししたいなと思っています。ちょっとかっこいい感じで名前をつけてしまったんですけれども、基本的には運用のTipsをお話しさせていただきます。

「こんなところを気にすると、開発の効率が上がりますよ」とか、運用課題を解決した事例もありますので、みなさんが今後開発にあたっていく中で、考えてもらうきっかけになっていくといいのかなということで、お話しさせていただこうと思っております。

もしかしたら、ゴリゴリ開発をされている方がお聞きになったら「若干つまらないかな？」というところも出てくるのかなとは思ってはいるんですが、もっともっと良い取り組みをしている方がいらっしゃいましたら、ADN Slackに投稿いただいて、ディスカッションができたらうれしいなと思っております。

森：ありがとうございます。ちなみに、林さんはサーバーを壊されたことはあるんでしょうか？

林：（笑）。サーバーを自分で壊したことはなかったはずですね。ただ、壊されたことはあります。

森：なるほど。2人目です（笑）。

林：なので、やっぱりバックアップは大事なのかなと思います。

森：大事ですね。

システム運用・保守メンバーとして、ASTERIA Warp歴は10年以上

林：さっそくですが、会社の概要からお話しさせていただきたいと思います。私はNX情報システム株式会社に所属しておりまして、所在地は東京の秋葉原の本社と福岡にオフィスがございます。

基本的には日本通運さんの仕事をさせていただいておりまして、アプリケーション・インフラ・ユーザーサポートという3つの観点で、それぞれ設計開発や企画、ユーザーの問い合わせの対応をやらせていただいております。私は、アプリケーションに携わっています。

2022年1月より社名が変わりまして、「NXグループ」というところを押しています。日本通運とグループ会社が「グローバル市場で存在感を持つグループに変わっていきたい」ということで、「NX」がフューチャーされている名前になっています。

NX情報システム株式会社と社名が変更されましたので、これを機にご承知おきいただけると幸いです。

自己紹介なんですが、ASTERIA Warpの経歴について書かせていただいております。ASTERIA Warpで作成されているデータを配信するシステムの運用・保守メンバーとして、2011年からかれこれ10年近くアステリアに関わっております。

2012年には、汎用機にて稼働するEDI業務の移行基盤設計や移行対応をさせていただいておりました。先ほどもお話がありましたように、こちらはCOBOLの言語で書かれたものも非常に多かったので、COBOLというキーワードを聞いて、「あぁ、COBOL……」と思いました（笑）。

森：（笑）。COBOLって難しいですよね。

林：あの画面からすると、ASTERIA Warpがものすごく色とりどりの画面になるので、最初は目が痛かったです。

森：なるほど。視力によくない開発で……。

林：いえいえ。ある意味、楽しいのでよかったかなと思います。

開発にがっつり関わらなくても、工数削減を実現

林：そんな移行の作業などをしまして、「顧客業務」という言い方をさせてもらってるんですが、2013年から2015年にはよりお客さんに則したプログラムの移行設計と開発をやらせていただきました。業務数に関しましては600強ほどありまして、かなりの数をさせていただきました。

森：ちなみに林さまは、冬に行われたDevFes 2022 Winterのデベロッパークイズではユーザー部門最優秀賞を獲得したということで、まずはおめでとうございます。

林：ありがとうございます。

森：ちなみに、その時に景品として星野リゾートのギフト券をお渡しさせていただいたと思うんですが、どちらに行かれたんでしょうか。

林：まだ行ってないんですよね。

森：なるほど。星野リゾートさま、見ていましたらぜひいい所をよろしくお願いします。

林：お願いします。2014年に、FAXの連携基盤の設計と開発をさせていただきました。これは汎用機に付随して、機能としてはFAXで現場に帳票を配信する仕組みがあったんですが、そちらもASTERIA Warpで実装できそうだということで、ASTERIA Warpの中で全部完結するかたちでコンパクトにまとめさせていただきました。

直近、2019年から2022年現在なんですが、SaaSパッケージとの連携がけっこう増えてきていまして、グループ会社を含めて開発フローの展開をさせていただいております。

森：すごく長くASTERIA Warpを使っていただきまして、本当にありがとうございます。

林：ASTERIA Warpだと、開発にがっつり関わらなくても開発の工数自体を短くできます。だからこそ、こうやって関われているのかなと考えています。

森：ありがとうございます。

フロー数は600強……開発で工夫した点は？

林：弊社の環境についてのご説明なんですが、こちらにEDI（電子データ交換）の環境のお話をシンプルに書かせていただいています。お客さまからデータをもらって、インターネットなどでデータを通信しているEDIのシステムが、まず（スライド）中段にございます。

こちらに通信を司っている部分があるので、いただいたデータをEAIシステムに連携して、そちらでマッピングやデータ分析、帳票のイメージ化などをやらせていただいております。

森：フロー数は600ということで、これはかなりの数がありそうですね。

林：そうですね、フローの数はかなり多いです。そのため、開発のやり方を工夫しないとなかなか難しい部分があったので、その部分についてより詳しくご説明させていただけたらなと思います。

ちなみに製品については、ASTERIA WarpのStandardを使っています。これから話していく内容は、Standardだからできるような部分もあるので、そういった部分も含めてお聞きいただけると幸いです。

EDIシステムのフロー開発についてお話しさせていただきたいんですけれども、顧客数がかなり多くて、データの種類も非常に多いです。その分だけプログラムが必要になってきますので、どんどんと1フローが増えていくという環境下にございます。

ただ、必須の機能としては、基本的にはデータを受信して、データを変換して、各システムに送信するところがメインになります。なのでこういった機能に関しては、共通部品とベースフローを作っていって、そのベースフローを元に開発をすることで工数を削減する工夫をしています。

フローの変数や外部変数を活用して、パラメーターなどでファイルをやり取りできる作りにしており、変更点を極力減らすことを意識しております。こういったことに気をつけることで、高速開発も狙えるのかなという部分がありますので、ベースフローの開発が重要なポイントなのかなと思っています。

フローを削減し、障害が起きた時の対応もシンプルに

森：弊社は「ノーコードで高速開発」と謳わせてもらっているんですが、その中でも基本のフローを作っておいて、それをコピーしてなるべく使わせることで、さらに高速に開発させるということですね。

林：そういうことです。

森：なるほど。

林：データ変換に関しましては、共通部品化が難しい部分なのであえてサブフロー化するんですが、ここだけを開発するような仕掛けにしています。何かあった場合には、サブフローだけを見ればデータの作りだとかに問題があるか・ないかを判定できるということで、こんな意図で分離をさせている状態です。

詳しくご説明させていただくんですが、ベースフローはこのような構成になっております。右側の絵なんですが、大きく分けて以下の構成になっております。初期化の処理があって、ファイル受信の処理があって、個別の変換処理があって、ファイルの送信処理があって、終了処理があるというかたちになっています。

変更しなければならないフローは赤枠の部分になっていて、ここの個別の変換処理を、より中に入って作っていくことになっています。

こういったところでフローを少なくしていますので、ファイルに起因した障害が起きた場合には、この部分だけを確認すれば基本的には問題ないですよ、という仕掛けになっています。個別の変換処理のみを動かせるような処理の作り方をしているので、デバッグなどをする際にも活用できるかたちにしております。

森：なるほど。「この部分だけ見ればいいですよ」とか、いろんなコメントも入れてもらっているので、かなり共通化できる部分がいいところですね。

林：そうですね。コメントは別の発表でお話しさせていただいたこともあるんですが、ここはけっこう集中して、「わかりやすく」を心掛けて作っております。

人知れずフローが落ちてしまうことを防ぐために

林：続いて、ベースフロー化していくとメリットがある部分なんですが、その他にもフローのプロパティで以下の設定を事前にすることができるのかを考えております。具体的には、汎用エラー処理やログの設定名です。

汎用エラーの処理は設定の抜け漏れが起こりやすい部分なのかなと思っていまして、事前に設定しておいたものをコピーすることで、エラー処理が行われずに人知れずフローが落ちることを防ぐというところで、このあと設定についてお話しいたします。

中には「エラー処理はまだぜんぜん作ってないよ」という方もいらっしゃるかもしれないんですが、とりあえず設定しておくことによって、あとからSlackでの連携をしたり、作り込みができる部分になります。なので、もしこういったところを設定してない方がいらっしゃいましたら、共通部品を作っていただくのがよろしいのかなと思っています。

こちらをベースフローとして作っていますので、ログ設定も随時変えるためにベースフローを別々に切り分けているので、そういったところでも運用のひと工夫ができるのかなと思っています。

ちょっと個人的な話にはなるんですが、スタートコンポーネントに関しましてもトランザクション化することを推奨しています。基本的に、再処理をする際にロールバックをして、頭から流せるようなフローや作り方を心掛けています。

スタートコンポーネントのトランザクション化って、なかなか見落としがちな設定だと思うんですが、ベースフローでコピーして使うことで便利に使えていると考えております。

森：エラーが起きても、もう一回最初からやり直してデータを取り直すということですね。

林：そうですね。EDIのシステムのフローの開発で考えたTipsや運用課題から、「こういったかたちにするのがいいんじゃないかな」と思ったのは以上になります。

「他のパッケージ連携のフローは参照させたくない」という声も

林：次に、簡単に連携基盤の開発についてのお話をさせていただきます。SaaSのシステムの刷新が増えてきていますので、社内業務システムとの接続が増加しています。

EDIでやっているフローの中で、データ連携の基本的な考え方やリソースと増強の有無には問題がないなとは思ってはいたんです。ただ、運用面を考えると、1つのASTERIA Warpのユーザーで開発・管理するのは限界がありそうでした。

課題としまして、「開発担当者以外にもASTERIA Warpのフローデザイナーを使いたい」「他のパッケージ連携のフローは参照させたくない」「そもそも他の業務で稼働しているフローを見せたくない、見たくない」という場合がございました。

そんな中で、ASTERIA Warpユーザーでの論理的な環境分離をさせていただいたので、こちらを説明させていただきたいなと思っております。

ASTERIA Warpのユーザー作成でできることはいろいろあると思っていまして、ASTERIAホームディレクトリにユーザー専用のディレクトリが作れます。(参考：ホームフォルダー）

フローデザイナーから参照した場合には、この階層以下のファイルのみが参照できます。例えば受信ファイルや送信ファイルも、フローデザイナーからホームディレクトリに配置しておくことで参照できるようになります。この階層に配置することは、運用の中でやっておくと便利かなと思っています。

SVNなども活用して、開発環境やテスト環境もユーザーを細かく切ることで分離できましたので、こういったところでもメリットがあったのかなと思っています。

情報を網羅的に閲覧することが可能に

林：ちょっと残念なポイントというわけではないんですけれども、ヘルプなどには「ドメイン設定やユーザーの権限がもっと細かく設定できる」と書かれてはいるんですが、若干ヘルプがわかりにくいのかなというところと、具体的なイメージが湧かないところがあって。

「こんなふうにやると、運用としてメリットがありますよ」というところにフォーカスを当てたような説明があるとうれしいなぁ、なんて思いました。

森：なるほど。今日、この場にいろんな方がいらっしゃるので、必ず変えてくれると思いますので、ぜひご期待いただければと思います。

林：なんかすみません。ディレクトリのお話なんですが、簡単なものなんですけど、ディレクトリの作成イメージはこんなふうにしています。

ディレクトリの作成イメージは、基本的には大きくファイルのディレクトリがあって、ここにシステムプロジェクト名ごとにデータを作成していくかたちになっています。In、Outのフォルダーがあって、このファイルのディレクトリを見ればデータがすべて揃っています。

それとは別に、業務フローのディレクトリ、共通フローのディレクトリ、共通スクリプトのディレクトリがあったりします。なので、フローデザイナーでログインするとすべての情報が網羅的に見れるようにしております。

その他に、業務フローの中でも連携システム単位でディレクトリを作るという考え方とか、ASTERIA Warpの用途によって検討するとよいのかなという部分がいっぱいあると思っています。

これが1つの正解だとは思っていないんですが、こういったところを考えることで、運用のしやすさにつながっていくのかなと思います。ぜひディレクトリの構成も考えていただくと、便利に使えるんじゃないかなと思っています。

データ検索で“迷子”にならないために大事なポイント

森：そうですね。いろんな人が使う基盤の中で、やはりユーザーさんがどんどん増えてきてしまう。気づいたら「あれ、フロー変わってる？」というのが一番怖いところだとは思いますので、ぜひそういったところもみなさんご検討いただければなと思います。

林：「データもどこにあるかわからない」となってくると、見る場所がわからないので。

森：そうですね、怖いですね。

林：そういったところもないように気をつけていく、標準化していくことが大事なのかなと思います。

まとめです。EDIシステムのフロー開発については、一回「産みの苦しみ」もあると思うんですけれども、開発すべき部分を省力化するためのベースフローの開発が大事なのかなと思います。

これはASTERIA Warpの初学者にも優しいのかなと思っていまして、変換のマッピングのフローは最初に作りやすい部分なのかなと思っています。そこを組み込んでしまえば全体の流れができますので、そこから徐々に全体の理解をしていく。

共通部品やベースフローの作りを見ていくことでステップアップできるので、なかなかステップアップしやすい環境になっているんじゃないかなと思っています。作成した個別処理だけで動作するようにしているので、デバッグとかは単体テストも容易にできます。

漏れたら困るプロパティは事前に設定

林：あと、漏れたら困る部分ですね。漏れやすいプロパティを事前に設定することで、ミスが少なくなるのかなと思っています。プロパティの設定漏れで、何か重大な障害が起きたりすることはなきにしもあらずなのかなと思うので、ここがけっこう重要なところです。

逆に、変更しなきゃいけない部分は明示的に設定しています。コメントなどで赤くするだとか、「ここを変えてください」と書くことで、便利に使えるのかなと思っております。

連携基盤の構築については、ユーザーの設定で環境分離をすることも検討できるものなのかなと思います。別にASTERIA Warpを立てなくても、いろいろと便利な使い方ができるんじゃないかなと思い、書かせていただいてます。

その際に、やっぱりディレクトリの構成や検討が必要なものがあるので、フローデザイナーでどこまでできるようにするかも含めて考えていただいたり、見せたい情報・見せたくない情報をどのディレクトリに配置するかを検討いただくのがいいのかなと思っています。

そういったところを気にして作っていくと、開発環境やテスト環境もASTERIAユーザの活用で設定できるんじゃないかなと思っています。

ただ、リソースが本当に足りているかどうかは別途検討が必要で、足りないのに無理やり使うのはよろしくないので、その時はASTERIA Warpをバンバンと買って増強していくのがいいんじゃないかなと思います。

森：そうですね。

林：私の事例は以上になります。

森：ありがとうございます。本日は、NX情報システム株式会社さまからいろいろな運用課題のお話をしていただきました。今後みなさんが導入される際に、ぜひ有効な情報になればなと思っておりますので、引き続きよろしくお願いいたします。林さま、今日はありがとうございました。

林：ありがとうございました。