第2回 AUG 事例研究WG レポート (2016/6/23開催)
株式会社フォーバルテレコム様を訪問、
「開発効率化の工夫」や「バージョンアップ体験記」を伺いました
第2回 AUG事例研究WG は株式会社フォーバルテレコム様を訪ね、同社 企画本部 システム開発部 担当部長 内海 義朗様、鈴木 智仁様にお話を伺いました。
フォーバルテレコム様は通信サービス、セキュリティコンサルティングを事業の柱とされていますが、自社向けに開発したサービス利用料一括請求システムを「おまか請求」として他社提供するなど、自社で開発したシステムを外販するビジネスも展開。システム開発部門では、将来外部にそのシステム自体を販売することも考慮しながら自社システムを開発されているといいます。
そんなフォーバルテレコム様を訪問し、ASTERIA WARPの「開発効率化のための工夫」及び「バージョンアップ体験記」を伺いました。
ASTERIAバージョンアップ体験記
まず初めに、同社 企画本部 システム開発部 鈴木 智仁様より今手がけているASTERIAバージョンアップについてお話いただきました。
フォーバルテレコム様は2009年にASTERIA WARP 4.4を導入し、翌年2010年に4.5にバージョンアップを行い、3年後の2013年にASTERIA WARP 4.7.1にバージョンアップ、今回が３度目のバージョンアップとのことです。
前回のバージョンアップ担当者の話では、バージョンアップにかなり苦労されたとのことで、フォーバルテレコム様ではしばらくバージョンアップを躊躇していたそうですが、ASTERIA WARP 4.8.1からインストーラーが変更となり、アップデート方法が簡素化されたとの情報を得て、今回4.9.1へのバージョンアップに踏み切られました。
今回のバージョンアップ計画は次の図のとおりです。
なお、現時点（6月第３週）まで、ほぼ計画通りに推移されているとのことでした。ちなみに本番機のASTERIA WARPバージョンアップは３人日で予定していたにも関わらず、実際には１人日で完遂したとのことです。
また最近は、DB更新や複雑な処理はOracle側で実施し、ASTERIA WARPでは外部連携、中間ファイル生成の役割を担うよう切り分けて利用しているため、以前のバージョンアップ時３週間かかった動作検証も今回はスムースに行えたとのことです。
ただし、バージョンアップに伴いJDKがアップデートされてしまったことから、Access接続がうまくいかなくなり、下記ADN記載の対処を行ったことなども説明されました。
参加者より次のような質問が挙がりました。
― テスト機でのバージョンアップ検証の際、書き込み先パスをどうやって変更していますか？
テスト機のパスにはすべて「test」を付記しています。
― バージョンアップに伴いLinuxサーバに変更する予定ですが、気をつけるべきことはありますか？
ASTERIAに限らない話ですが「￥（バックスラッシュ）」が残るとエラーになるため、Windowsでも、常日頃よりできるだけ「/（スラッシュ）」を使い、バックスラッシュは使わないほうがよいでしょう。
その後、パスや￥を一括検索、変換する良い方法がないか話し合われました。Oracleに格納したパス情報をASTERIAフローで使っていたケースもあったとの体験談も話され、社内ルールが徹底していないと検索ではひっかからないものがでてしまうなどの情報共有が行われました。
ASTERIA開発効率化のための工夫
続いてフォーバルテレコム内海様よりASTERIA開発効率化のためのポリシー、工夫について実際の事例を交えながら紹介いただきました。
１） ポリシー１：得意なものは得意なモノに
ASTERIAで複雑なコーディングをすべて記述するのではなくASTERIAの役割を限定化してフローをシンプルにされているとのことです。
２） ポリシー２：プロジェクト作成のルール化
さらに同じ目的の処理を行うプロジェクトは必ず同じルールとして誰が見てもわかりやすいようにされています。例えば次の図のような外部からデータを取得するプロジェクトは必ず「メイン処理」「前処理」「ファイル作成」「後処理」「メール送信」の5個のフローで構成するルールとされているとのことです。
３） 効率化の工夫：関数化による共通処理作成
たとえ３コンポーネントの組み合わせであっても共通処理は関数化することで、属人性を排除し、フローをよりシンプルなものにされているとのことです。
参加者より次のような質問が挙がりました。
― 関数はあらかじめテンプレートをつくるのでしょうか。
すでに出来上がっているフローから共通のものをコピーして関数をつくっています。
— ASTERIAで配信したメールが正しく送信されたかプログラム側で検知するよい方法はないでしょうか？
これについては参加者より「エラー転送先を監視してはどうか。」「メールサービスをAPIで呼び出すことで、結果がわかる」などの回答が寄せられました。
編集後記
第２回目となる今回の事例研究WGでは、1回目より参加者の皆様の肩の力が抜けて、終始なごやかな雰囲気でディスカッションや質問回答が活発に行われ前回以上に有用な会となりました。また、その後の懇親会では第３回開催を日立ハイテクフィールディング様で実施いただけることが決定！第３回（9/13）は懇親会も新たな企画が進行中です。次回の事例研究WGもぜひお楽しみに。
