[日立物流] 周回遅れからのクラウド挑戦 ‐ しがらみからの脱却 · 2017-12-19 · 2.しがらみ多の中でのクラウド推進 3.物流事業へのクラウド活用

周回遅れからのクラウド挑戦-しがらみからの脱却-

2017年5月31日株式会社日立物流

田代肇

日立物流ソフトウェア株式会社吉田佑一郎

AWS Summit Tokyo 2017

1© 2017 Hitachi Transport System, Ltd.

発表者紹介

名前 : 田代肇 (タシロハジメ) 38才 Hajime Tashiro

所属 : 日立物流 IT戦略本部デジタルビジネス推進部部長補佐職歴 : 物流システムのSEからチェコ、シンガポールに赴任、現職趣味 : メダカ飼育

名前 : 吉田佑一郎 (ヨシダユウイチロウ) 48才 y_yossii

所属 : 日立物流ソフトウェア（株）ネットワークソリューション部部長職歴 : 入社以来ずっとアプリケーション開発に従事。上海に赴任後

現所属となり、慣れないインフラに悪戦苦闘中趣味 : 自作PCいじり（VR始めました）


本日の流れ

①はじめに

②日立物流とクラウド

③情報子会社とクラウド

④クラウド取組の

過程

⑤現在のクラウド利用状況

⑥利用拡大への

取組み

Ⅰ. はじめに


リアル周回遅れ1 ①はじめに②日立物流と

クラウド③AWSから学んだ事

④クラウド取組の過程


⑥利用拡大への取組み


リアル周回遅れ2

参照 : AWS Summit 2014資料抜粋

①はじめに②日立物流と






本日お伝えしたい事

1.リアル周回遅れから登壇までの軌跡

2.しがらみ多の中でのクラウド推進

3.物流事業へのクラウド活用

事業、情報子会社の何が変わったか当社経験がヒントになればと思います







日立物流紹介

１. 章タイトル入力エリア

商号

創業

本社所在地

資本金

連結売上高

主要株主

人員

ネットワーク

1950年2月

東京都江東区東陽7-2-18

168億円

6,654億円（2016年度）国内 65% 海外 35%

(株）日立製作所 30％ SGホールディングス（株） 29％

連結 24,744人（2016年3月末）

グループ総人員 48,524人（2016年3月末）

国内 24社 363拠点海外 94社 413拠点

合計 118社 776拠点（2016年3月末）

3PL（物流一括請負)のリーディングカンパニーとして幅広いお客様にサービスを提供しております







日立物流ソフトウェア紹介

日立物流ソフトウェア株式会社

1973年8月20日

東京都江東区東陽7-2-14 東陽MKビル 6F

2億1千万円

125億3千万円（2016年度実績）

株式会社日立物流：75％株式会社日立製作所：25％

590名（2017年4月1日現在）

1.情報システムの開発およびコンサルティング業務

2.パッケージソフトウェアの開発および販売業務

3.コンピュータおよび関連機器の販売業務

商号

創業

本社所在地

資本金

連結売上高

株主

人員

事業内容

最適なロジスティクスITソリューションを提供します







日立物流事業紹介

重量・機工

入庫・検品↓

保管・加工↓

仕分け・出荷

物流センター運営

海外サプライヤー

国内サプライヤー

ミルクラン

海外取引先

国内納品先

部品メーカー

お客様

入庫・検品↓

保管・加工↓

仕分け・出荷

物流センター運営

組立工場

お客様

販売会社

お客様

物流情報システム消費者

3PL (システム物流) / 重量・機工 / 環境事業 / 物流エンジニアリングフォワーディングフォワーディング

調達生産販売

フォワーディング３ＰＬ環境事業

物流エンジニアリング

Global Supply-Chain Solutions Provider調達～生産～販売物流までシームレスな対応が可能です







イギリス

（2016年3月末時点）

メキシコフィリピン

韓国

インド

中国Shanghai （東アジア本社）

ドイツ

オランダWaardenburg（欧州本社）

アラブ首長国連邦

※dots on above map are not put in all areas due to the map size

スロヴァキア

イタリア

スペイン

フランス

ポーランド

トルコ

オーストラリア

Indonesia

シンガポールSingapore （アジア本社）

チェコ

マレーシア

ベトナム

日本Tokyo（日本本社）

極会社数拠点数倉庫面積

日本 24 社 363 拠点 496 万㎡

アジア 30 社 144 拠点 75 万㎡

欧州 13 社 73 拠点 48 万㎡

米州 11 社 45 拠点 22 万㎡

東アジア 40 社 151 拠点 68 万㎡

計 118 社 776 拠点 709 万㎡

アメリカ

タイ

ロシア

ミャンマー

当社拠点

Torrance（米州本社）







最近TOPICS

1. ＳＧホールディングス及び佐川急便の戦略的資本業務提携(2016年)

2. スマートロジスティクス推進(省人化・自動化)

3. ニューイヤー駅伝2017年10位

(2015年 19位2016年 9位)






Ⅱ. 日立物流と

クラウド


2010-2014年の事業環境

1. 日本マーケットの構造変化(人口減少、EC台頭など)

2. 荷主のグローバル化(地域生産・地域消費推進)

3. 世界で戦い・勝てる物流企業(当社戦略)

グローバルを意識した舵取りが鮮明

IT組織もグローバルへの対応・強化が必須








グローバルを支えるシステム

北米WMSWMS

Global Warehouse Management System(在庫管理システム)WMSWMS

日本のオンプレからサービス提供、DRサイトも国内すでに10ヵ国でサービスを提供中、更に展開を予定

だけどこのまま推進していいのか？







リスク再評価

14年4月に提供場所の見直しを決定3極(アメリカ、アジア、中国)でGWMSを稼働を目指す

リスク GWMS影響荷主影響

自然災害の発生(日本) サービス停止大 (出荷停止)

ネットワーク遅延レスポンス遅延中(出荷遅延)

時差・カレンダーメンテ時間調整ほぼなし

このまま日本(オンプレ)からの提供を続けると、海外10か国の出荷が同時停止するかも？







プロジェクト目標

1. アメリカ、アジア、中国(3極)からサービス提供

2. グローバルDRも同時構築

3. 1.5年以内で3極立上

4. BtoBレベルの品質(事業停止なし)

5. コスト(既存オンプレより安く)







候補と検討結果条件現状オンプレクラウド（AWS) グループシェアード

3極サービス日本のみ △ ◎ △

グローバルDR 日本 ○ ◎ △

納期オンプレ × ○ △

BtoB品質 ○ ○ ○ ○

コスト基準値 × ○ ◎

評価オンプレで安定稼働中

予算が無尽蔵にあればオンプレがベストだけど

ニーズをすべて満たせるのはAWSのみ

極レベルでは十分利用可

AWS東京でスモールスタートを実施

凡例：◎（優） ○（良） △（可） ×（不可） ①はじめに②日立物流と






AWS簡単か

AWSサミット2014で情報収集、どの企業も簡単に構築してサービスインしてるそんなに難しくないのか？

しがらみだらけでした

実際のやり取りをご覧ください







周回遅れその1(環境構築編)

組織のしがらみで2か月遅延

日立物流日立物流ソフトウェア日立Gr

AWSやるって決めたやった事ないから無理

その辺は忖度しろよAWSなんて責任持てない

もういいよ、流行りのクラウドSIerにお願いするからそれはないよ、日立GrのSIer

使ってよ！

日立Gr入るし、リスクも少なそうだからやってもいいよ

じゃあ日立Grと一緒にやろうよ







周回遅れその2（アプリ編)

マインドのしがらみで2か月遅延

本当に動くか責任もてないアプリの対応もよろしく

大丈夫だ、一緒にやろう、リスクはお互いで共有オンプレと動作が違う

オンプレではこうだった

技術支援はばっちりですよ動作確認OK、AWSの機能をもっと使いませんか？

やってみると面白いこの際クラウドネイティブにしてしまおう！

日立物流日立物流ソフトウェア日立Gr







そもそも2014年なんで「0」なのか？

クラウドって本当に大丈夫なのか？

クラウドを利用したら子会社のビジネスどうするんだ？

どうせ一時的なトレンドだ

日立物流

横並び体質のしがらみで…

2014年からスタートになってしまった

止まったら誰が責任をとるんだ？

SAPなんてミッションクリティカル乗せられないだろ？

他社が使ってからにしよう







しがらみから丸3年(事業系)


2015年1月稼働東京

2015年10月稼働バージニア

WMSWMS

WMSWMS

2016年1月稼働北京

WMSWMS

2015年12月稼働シンガポール

WMSWMS

2017年7月予定シドニー

検討中フランクフルト

当初条件完了状況

3極サービス完了

グローバルDR 完了(北京以外)

1.5年以内納期 3カ月遅延

BtoB品質業務停止なし

コスト予算通り







しがらみから丸3年(社内系)

事業系でしがらみも雪解け気味

SAPや社内系もクラウド化検討

SAP本番機はAWS、検証・開発環境はB社クラウド

マルチクラウド運用の大変さは吉田資料で共有







AWS構成図 ①はじめに②日立物流と





日立物流国内NW

日立物流海外NW

中国NW

Tokyo

事業系(GWMS等)

管理系(SAP等)

事業系

Beijing

AmazonEC2

AmazonS3

AmazonRDS

Amazon Redshift

AmazonEC2

AmazonS3

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonRDS

Singapore

事業系(GWMS等)

管理系(SAP等)

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonEC2

AmazonS3

AmazonRDS

Virginia DR Tokyo DR

Tokyo DR

Virginia

事業系(GWMS等)

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonRDS

Singapore DR

GWMSのポイント・ALB/EC2/RDS/SNS等 AWSサービスのみで稼働・RDSはMulti-AZ構成・DRはAMI/RDSのリージョン間コピー機能を利用

WMSWMS WMSWMS WMSWMS WMSWMS

Ⅲ. AWSから学んだ事


周回遅れは抜け出せたか

サミット出てるって事は

周回遅れからは抜け出した

周りも活用が更に進んでいる

襷(たすき)をつなげ続ける







変化した事

1. 周回遅れの理解2. しがらみからの脱却3. マインド変化

(新しい事は楽しい)

AWSが今までのやり方を考え直すきっかけに







学んだ事

1. 意思決定から一緒に進める

2. 餅は餅屋、パートナーと一緒に進める（日立Gr様サポートありがとうございました)

3. 最初から高すぎる目標は設定しない







今後の方針

1. マルチクラウドを一緒に進める

2. 持つITから使うITへ

3. 襷をつなぐ






Ⅳ. クラウド取組の過程


２００

クラウド取組の過程 ①はじめに②日立物流と






クラウド取組の過程 ①はじめに②日立物流と





・２０１４年８月にAWSを利用開始後、現在で

のEC2インスタンスが稼働中（今後オーストラリア・ドイツ稼働予定）

これまでの取組の過程、利用拡大に向けた取組み、今後の課題についてご説明します

（高度な技術的な話は他社様にお任せし、ここではあまり触れません）


2014年当時抱えていた課題

そもそもそれまでの日立物流のITは？

ホスト→C/S(分散)→C/S(集中・仮想化)と変遷してきたが、全て自社DCでのオンプレ＆自社運用の完全自前主義！

それを支えるインフラ技術者は？

保守効率を上げるために作業の属人化＆現状技術に特化それでも既存インフラの保守で手一杯どうしても今のシステムを止めない維持保守最優先で新規技術導入提案は後回しに・・・

目一杯言い訳チックですが共感していただける方も多いのでは・・・







当時抱えていた課題

S気質な親会社：AWSやるよ？出来ないなら他社使うよ？

技術者のマインド・・・ネガティブからのスタート

世間でのクラウド利用拡大の潮流は本流？すたれない？

障害が多いって聞くけど本当に大丈夫？障害対応するのうちらよ？

またベンダ固有の技術が増えてしまって大変じゃない？

オンプレサーバも残るし、結局運用は今までより大変になるでは？

ただでさえ今の運用で忙しいのに時間取れる？

日々の運用業の忙しさも相まって、新しいもの好きの技術者でさえあまり積極的になれず…







当時抱えていた課題

どうやら親会社、本気みたい・・・

いつやるの？（古いけど）

マインドの変化

いずれやるなら最初から絡まないと後々の保守大変・・・

・・・

クラウドが今後本流になっていくとすると、下手すれば今後の他の仕事も減って

いく？

丸投げじゃなくてと言ってくれてるから、いいチャンスではあるよね







壁の突破

① ：技術者のマインドチェンジ

② ：技術修得

③ 変化への追随







壁の突破①技術者のマインドチェンジ

①：技術者のマインドチェンジ一歩一歩不安を解消することでネガティブマインドをポジティブマインドへ

AWS固有のわからない単語が沢山・・・

自分たちの知っている技術・単語への置き換え

⇒そうやって見ると

障害発生への不安

障害が起きる前提での冗長化構成を組む

⇒従来までの

『ハード関係障害自体は自分たちの責任ではない』との割り切り実機が目の前にないと何かと不便なのでは・・・ほぼ全ての操作がマネジメントコンソールからできる

⇒どこにいても操作できるので








正直、しぶしぶ始めたAWSだけれども・・・

実際やってみると・・・？あれ？

言葉は違えど

あれ、な・・・・・

ハード故障の心配しなくていいのは楽ちんかも？！？

やっぱり

マルチクラウド？B社クラウドも？AWSもなんとかなったし？








今や・・・

え？オンプレ？なんで？AWSで出来ないの？

うちがサポートするよ？

AWSで出来るよね？？







壁の突破


② ：技術修得








壁の突破②：技術修得

なにはともあれ技術修得！

有識者からの技術吸収

H系SIer・一般系SIerによる勉強会

各種セミナーへの参加

AWSに強いSIerとの問合せ（サポート）契約

インターネットを駆使して調べる（たくさんの情報有り）







壁の突破②：技術修得

部内展開教育・セミナー内容を基にした部内勉強会開催

業務終了後、夜な夜な勉強会開催（）

テスト環境にて試行（）無料枠を最大限有効活用！し、とにかく触る！

とはいえこんなことも・・・サービスが多すぎてどれに注力すればいいのか難しい頑張ってマニュアル作ったが仕様が変わって無駄になることもせっかくCLIを使って効率化してもバージョンが変わって使えない・・・







技術修得のまとめ

代表的なAWSサービスの名前と機能概要さえ押さえれば、今までのオンプレ・仮想化知識があれば取っ付きは何とかなる！

とにかく試す！さわる！

AWS主催セミナーやインターネットにも情報はたくさん！

とはいえ、深く使いこなすにはそれなりの工夫が必要

壁の突破②：技術修得 ①はじめに②日立物流と






壁の突破


② ：技術修得








壁の突破③：変化への追随

技術革新が、かつ、となる

技術革新に追随していくためには・・・常にアンテナ高くして情報を集める＆勉強スピード感を持つためにも、ユーザと共に検証という流れも必要

と、わかってはいてもまだまだ推進不十分






Ⅴ.現在のクラウド利用状況


区分AWS

リージョン利用拠点システム名（数）

営業系

東京シンガポールバージニア中国

日本シンガポールマレーシアタイインドインドネシアフィリピンベトナムオーストラリア韓国中国香港台湾アメリカメキシコ

グローバルWMS（45）国内WMS（34）

管理系東京シンガポール中国

SAP R/3（45）社外Web（3）社内共通システム（71）

その他東京シンガポールバージニア

経営可視化（3）その他（3）

【AWS利用方針】

【AWS未適用事例】•お客さま了承が得られない場合（DC場所

が非公開なことがポリシにそぐわない場合有り）•お客さまネットワーク下への機器配置が必

要な場合•お客さまとのEDI等の為に専用線・INS回線等の引き込みが必要な場合

•AWSでサポートしていないOSを利用する場合

ＡＷＳ適用システム数：システム、ヶ国・地域

現在のAWS利用状況 ①はじめに②日立物流と





WMSWMS


現在のAWS利用状況

AWS利用状況

0

100

200

2014下 2015上 2015下 2016上 2016下

EC2インスタンス数推移

新規構築前期まで累計200







現在のAWS利用状況 ①はじめに②日立物流と





日立物流国内NW

日立物流海外NW

中国NW

Tokyo

事業系(GWMS等)

管理系(SAP等)

事業系

Beijing

AmazonEC2

AmazonS3

AmazonRDS

Amazon Redshift

AmazonEC2

AmazonS3

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonRDS

Singapore

事業系(GWMS等)

管理系(SAP等)

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonEC2

AmazonS3

AmazonRDS

Virginia DR Tokyo DR

Tokyo DR

Virginia

事業系(GWMS等)

AmazonEC2

AmazonS3

AmazonRDS

AmazonEC2

AmazonS3

AmazonRDS

Singapore DR

WMSWMS WMSWMS WMSWMS WMSWMS

Point・DirectConnetで社内NW とAWS環境をフラット接続・リージョン間でDR環境構築（AWS内でDR完結）


マルチクラウド戦略の経過

当初のクラウドの棲み分け計画

・事業系： AWSにGWMSを移行し、小規模荷主で運用開始

・基幹系： B社クラウドに基幹システム（SAP R/3）の検証機・開発機を移行し、運用開始

そして・・・・

事業系：AWS 基幹系：B社クラウド






WMSWMS


マルチクラウド戦略

・事業系：AWS問題なく稼働。検討期間中AWS起因による障害発生ゼロ。

・基幹系：B社クラウドマイナーな事象含め、複数の障害が発生。

上記結果を受け方針転換し、することに

⇒2016/12に

但し、B社クラウドも高可用性を求めないシステムで継続利用し、マルチクラウド戦略は継続中。

（クラウドの更なる発展の為にも、B社にもっと頑張って頂きたい！）







マルチクラウド戦略

R/3移行時の失敗談（お恥ずかしいですが）

SAP R/3をAWSで稼働するにあたり、インスタンスタイプ選択ミスによる性能不足障害を惹起

インスタンスタイプとIOPS指定値を変更し対応したものの、ディスクのウォームアップに想定外の時間がかかりヒヤヒヤ。なんとか間に合い最初の決算を乗り切ることが出来た

【教訓】・インスタンスタイプの検討は慎重に（いつでも変えられる、と安心しない）・ディスクのウォームアップ時間も事前検証しておけばより安心・インスタンスタイプ毎にIOPSの上限等が細かく指定されているので、よく把握しておく






Ⅵ.利用拡大への取組み


利用拡大に向けて取り組んだこと

使おうと思ったときにすぐに使える環境を整備（）

社内LANから普通につながるネットワーク社内LAN環境と同様に使える共通機能(DNSサーバ, Proxyサーバ等)の整備

標準的なAP-DB構成、リージョン間DR含む

必要なAWSサービス、監視・運用費用、共通基盤利用料をパックにした

Zabbixによる







利用者の評判

AWSを利用しての利用者の声（AWSのいい点は皆さんご存知だと思いますので、あえて悪い点をピックアップ）

思っていたよりメンテナンスが多い（再起動時間の調整が大変）

ホスト障害時でもユーザに障害通知が無い為、ユーザ側が障害検知するまで障害

に気づかない

発展のスピードが速い為に、半年前の制限事項が制限事項では無くなっている事

も。その為に、常にアンテナを張っていないとお客様への提案で困る事となりそう







課題と今後の取組み

増加するインスタンス管理手法の確立

現在のExcelによる管理ではそろそろ限界！請求管理と併せて、管理ツールの導入（もしくは内作）を検討

いいソリューションお持ちの会社様いらっしゃいましたら是非売り込みにお越しください！

未利用サービスの活用

日々進化を続けるAWSの中で、未利用の機能がまだまだたくさん存在有効・有益な機能の適用検討を継続実施

AWS営業・SE様ご協力お願いします！







組織改革の検討

オンプレではネットワークチーム、サーバチームと別けていたが、クラウドだと技術の境目が曖昧＆相互干渉

個々の知識範囲の拡大や、都度チームをまたいだ作業推進をしているが、根本的な対策にはなっていない

技術変化が激しく、日々の運用を行いながらの追随は困難

オンプレからクラウドを「」ではなく、「」と捉えた対応が必要

・クラウド専門チーム、独立した技術研究チーム設置の検討





⑥利用拡大への取組み課題と今後の取組み


最後に

様々な方々の助けがあってここまで進めてこれましたが、そんな中でも、（本当にどんな質問でも！）に対応してくれたＡＷＳに感謝いたします。

仕事柄いろいろなITベンダのサポートサービスを利用していますが

(今後ともよろしくお願いします)







Documents

[日立物流] 周回遅れからのクラウド挑戦 ‐ しがらみからの脱却 · 2017-12-19 · 2.しがらみ多の中でのクラウド推進 3.物流事業へのクラウド活用