【レポート】ネスレ日本における、AS400 EDIシステムのクラウド移行 #AWSSummit #AWSSummitOsaka

2019.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大阪オフィスのちゃだいんです。

当エントリでは2019年06月27日に行われた『ネスレ日本における、AS400 EDIシステムのクラウド移行』に関する内容をレポートしたいと思います。

AWS Summit Osaka 2019 | 2019 年 6 月 27 (木) グランフロント大阪で開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

ネスレ日本株式会社
財務管理本部
インフォメーションテクノロジー部
細見 貢氏
山口 晃子氏

ネスレ日本が、20年来AS400でまかなってきたビジネスの重要システムであるEDIを、いかに標準化し、同時に、オープン化できたのか。

レポート内容

イントロダクション

  • ネスレでは20年以上に渡りAS400を運用
  • 2018年から1年かけてAWS上でゼロから再構築
    • アプリケーションのオープン化

会社紹介

  • スイスに本社を置く、1913年に日本人法人を創業
  • ネスカフェ、キットカットを展開する食品企業
  • 自社サービス紹介
    • ネスカフェアンバサダー
    • ウェルネスアンバサダー
    • キットカットショコラトリー
  • 単なる商品提供だけでなくサービス開発も展開中

プロジェクト概要

  • 総勢50名で本プロジェクトを推進
  • プロジェクで何が変わったのか?
    • IBMメインフレームから、ウェブベースのシステムに刷新
  • プロジェクト体制
    • 東京にプロジェクトルームを設置し、神戸本社・シドニー(セキュリティチーム)・バンガロール(オフショア開発)の4拠点でリモートでコミュニケーション
  • チーム構成
    • システム開発をJBCC株式会社、運用設計・監視はエクイニクス
    • JBCC開発
      • 長年のAS400の開発・導入実績が豊富
    • エクイニクス
      • サイトロックマネジメントなどサービスが充実
  • 当社でのシステム開発・運用方針
    • ビジネスでのIT活用
      • ビジネスニーズに合わせたサービスの活用
    • 耐障害性
      • 阪神大震災の教訓から、ローカルで保管するシステムを2拠点でバックアップ体制を引く
      • 本番・災害用の2拠点体制が基本
    • 安定稼働
      • ビジネスにインパクトを与えない
      • クリティカルインシデントを発生させない
      • BCP機能が必須
    • オブジェクティブの課題
      • アプリ開発
        • 複雑化・ブラックボックス
      • インフラ開発
        • 保守サポート切れ
        • 災害対策
      • 運用保守
        • 後継者不足など

アプリケーション開発

  • 課題
    • 業務アプリケーションの複雑化
    • 20年以上の運用保守が属人化
    • 度重なる追加開発で機能が複雑化
  • 解決方法
    • オープン化
      • 開発ツール(GeneXus)、パッケージ製品(ACMS)を活用しオープン化
    • オープン化のポイント
      • 開発ツールGeneXus
        • プログラムやデータベースを自動生成し、開発の省力化・高速化を実現
      • EDIパッケージ活用
        • DAL社のACMS APEXを採用
        • EDI通信設定を1つの製品で管理、バッチ生成をノンコーディングで省力化が実現
    • 結果
      • 開発効率化
        • コーディング量削減
      • 品質担保
      • メンテナンス性の向上

インフラ開発

  • 課題
    • AS400の保守サポート切れ間近(これによりプロジェクトの明確なデッドラインが引かれた)
    • 自然災害対策
      • 業務に直結するため基幹システムであるため、高い障害性が必要
  • 解決
    • クラウド化
  • クラウド採用までの検討(オンプレかクラウド化)
    • 1.短期間でのインフラ開発
      • 保守切れ間近のため:1年半から1年に短縮
    • 2.耐障害性
      • 社内方針にのっとり国内2拠点で可能
    • 3.スピーディなインシデント対応
  • クラウドベンダーの検討(AWSを選んだ理由)
    • 多くの導入実績
    • 耐障害性の実現
    • 先進的テクノロジー
  • インフラ構成・利用サービス
  • 開発時の考慮点
    • 本番・災害対策サイト構築

運用設計・保守

  • 課題
    • ITサービス品質低下
      • サービスが形骸化、昨今の社内基準を満たしていなかった
    • 運用担当者の後継者不足
      • このご時世、汎用機の運用保守は若手が誰もやりたがらない
  • 解決
    • 運用・監視設計
      • セキュリティ要件を満たすう運用のデザイン
    • 外部監視サービスを活用しアウトソース化
  • サイトロックマネジメントサービスを利用
    • 運用設計から24/365監視を一気通貫で行える点がメリット
  • 運用設計
    • ヒアリング>運用設計>運用・導入の3ステップで行った
    • ヒアリング
      • ネスレの運用ガイドラインをヒアリングし、システム要件化
    • 運用設計
      • サイトロックの基本基準を当てはめ、システム運用方針を策定
    • 運用・導入
    • 特に注力したのはヒアリングの部分
      • 内部ネゴシエーションにかなりの時間を要したため、丁寧にヒアリングを行った
  • 監視設計
    • 分析>監視設計>実装・テストの3ステップ
    • 分析
      • 開発チームとセッションしシステムの特徴を把握
    • 監視設計
      • サイトロックの基本メニューと開発チームの要望を掛け合わせ、独自の項目を洗い出し
      • 1500項目を設定
    • 実装・テスト
      • アラート検知設定(メール配信)
    • 注力したのは実装・テスト
      • 実際やってみて、ちゃんとアラートが飛ぶか何度も検証した
  • 監視環境
    • AWS上にすでにエクイニクスの環境にあったので導入がスムーズだった
  • 運用保守体制
    • ネスレ・JBCC・エクイニクスの3社協業で運用保守を行う
    • 主な役割分担
      • 24/365監視
        • エクイニクス
      • 問い合わせ・インシデント対応
        • JBCC
      • 上記意外
        • ネスレ

プロジェクト全体のまとめ

  • 効果
    • 外部リソース活用により、運用保守主体からITソリューションを創出するチームへ
    • IT部門のリソースを新たなITの導入担当として生まれ変わった
  • 課題と今後の対応
    • EDI通信のインターネット化
      • 業界全体の動きとして、EDI通信を電話回線からインターネットへ切り替え
    • AS400に対する運用ルール(どこまで内部、どこから外部などの線引きetc)を見直す
    • クラウド化通用推進
      • SaaSをはじめ、クラウド化の要望が出てきている
      • ルール・セキュリティ標準全般を整備しクラウド化を推進できるようにする
  • 今後のクラウド活用案
    • 基幹系システムのAWS移行は、IT部門でのクラウド活用の第1歩
    • 営業サポート
    • チャットボット
    • 工場での異常検知

感想

世の中に溢れる一般的なクラウドジャーニーとしてのスモールスタートとは一線を画す、本丸の基幹システムを一気に移行させるという離れ業を成し遂げたネスレは、今後一気にクラウド導入を加速させると確信しました。

誰かのお役に立てれば幸いです。それではまた。