大規模展開を成功へ導く3つのポイント～「計画」「ルール …...モダナイゼーションビジネス事業部コンサルティングの推進、コンサルティングサービスの提供

Copyright © 2018 TIS Inc. All rights reserved. 0

2018/06/01

プラットフォームサービス事業部

プラットフォームサービスコンサルティング部

AWS大規模展開を成功へ導く3つのポイント～「計画」「ルール整備」「運用」が肝！～

Copyright © 2018 TIS Inc. All rights reserved.

目次

Chapter1 自己紹介

Chapter2 ① 計画

Chapter3 ② ルール整備

Chapter4 ③ 運用

Chapter5 事例紹介

1


自己紹介 Chapter1

2


自己紹介

3

中澤義之（なかざわよしゆき） TIS株式会社プラットフォームサービス事業部プラットフォームサービスコンサルティング部テクニカルエキスパート [役割] ・クラウド導入コンサルティング・クラウド基盤開発・クラウド運用サービス等


TIS会社概要

TIS株式会社 (TIS Inc.) 昭和46年（1971年）4月28日

100億円

グループ20,206人単体：5,440人（2017年10月31日現在）

社名創業

資本金

従業員

代表者

3,933億98百万円（2017年3月期連結）売上高

代表取締役会長前西規夫代表取締役社長桑野徹

その他 4.0%

製造業

20.3%

流通・サービス業

30.9%

金融業

35.4%

業種別売上高構成比売上高に占める ITアウトソーシングの割合

ITアウトソーシング

32.3%

公共・公益 9.4%

コンサルティング

システムインテグレーション

ITアウトソーシング

IT基盤の構築

最先端技術の研究

4


TISのご紹介

ｱｶｳﾝﾄ密着型で個社戦略に特化した開発･保守･運用

ﾋﾞｼﾞﾈｽの推進、ｿﾘｭｰｼｮﾝの企画・提供

クレジットプラットフォーム事業部

カード第１事業部

IT基盤技術本部カード第２事業部

産業事業本部

食品医療通信ビジネス事業部

流通サービスビジネス事業部

ｴﾈﾙｷﾞｰ・食品・医療・通信・流通･ｻｰﾋﾞｽ分野等

での顧客密着型ﾋﾞｼﾞﾈｽ、及びｿﾘｭｰｼｮﾝ提供型ﾋﾞｼﾞﾈｽ

をｸﾞﾛｰﾊﾞﾙに推進

エネルギービジネス事業部

フィナンシャル事業部

アドバンスドクレジット事業部

公共事業本部

公共事業部

公共分野での開発･保守･運用ﾋﾞｼﾞﾈｽの推進、ｿﾘｭｰｼｮﾝ

の企画･提供、ｱﾗｲｱﾝｽの推進

モダナイゼーションビジネス事業部

コンサルティングの推進、コンサルティングサービスの提供

ビジネスイノベーション事業部

全社に対するインフラ構築・保守・運用サービスの提供

特定顧客向けの開発･保守･運用の推進

インダストリー事業統括本部

サービス事業統括本部

金融事業本部

ペイメントサービス事業部

リテール決済サービスの企画・研究開

発・開発・提供・保守・運用

ﾃﾞｼﾞﾀﾙｲﾝﾃｸﾞﾚｰｼｮﾝ事業部

デジタルマーケティング分野に特化した

ソリューション、サービスの推進・展開

ＡＩサービス事業部

ＡＩ・ロボットを活用したソリューショ

ン・サービスの企画・開発・提供

ｴﾝﾀｰﾌﾟﾗｲｽﾞｿﾘｭｰｼｮﾝ事業部

業界横断型の経営管理業務領域に特化

したｿﾘｭｰｼｮﾝ、ｻｰﾋﾞｽ等の企画・提供

プラットフォームサービス事業部

クラウドサービス、セキュリティサービ

ス、ＤＣ、ネットワークサービスの推進

フィナンシャルサービス事業部

生損保、金融機関向けｿﾘｭｰｼｮﾝ、ｻｰﾋﾞｽの

企画・提供・推進、開発・保守・運用

製造サービス事業部

製造分野での基幹(ERP)、基幹周辺領域

におけるｿﾘｭｰｼｮﾝ、ｻｰﾋﾞｽの企画・提供

5


ミッションステートメント

6


サービスコンセプトクラウドとセキュリティの様々なサービスを中心に、最適なサービスについて弊社のコンサルティング力と 40年以上の経験あるアウトソーシングノウハウを結集したマネージドサービスでお客様のビジネスを支えていきます。

パブリッククラウド

プライベートクラウド

ハイブリットクラウド

クラウド

セキュリティ

サービスコンサルティング

マネージドサービス

データセンターマルチサービス運用

脆弱性診断

セキュリティシステム設計・導入

マネージドセキュリティ

セキュリティコンサルティング

7


サービスコンサルティング

8

最新情報と目利き力で、「ビジネスにとっての最適」目線で、お客様を導きます。

Consulting Policy

目利き力クラウドを深く理解したコンサルタントがお客様に必要なサービスを提案

中長期的な視点今後の変化を見据えつつ現状の Fit & Gap 分析を活用し将来像までご提案

ノウハウの活用豊富な案件ノウハウを元に、お客様にあったシステムを提案

③ プラットフォーム選定お客様のあるべき姿（次期プラットフォーム構想）を見据え、現状分析と次期インフラ基盤の評価指標を作成し、次期プラットフォームの検討を支援。 TISが培った「プラットフォーム選定コンサルティング」のノウハウを余すことなく活用。

① 業界のノウハウを集約した「テンプレート」業界に応じたノウハウを標準化しお客様にご提供

金融業界向けテンプレート

産業向けテンプレート

公共向けテンプレート

ガイドライン

統合運用管理基盤

クラウド

運用メニュー

セキュリティ

音声（

Ale

xa）

ホスト

マイグレーション

AI

その他業務アプリ

② クラウドセキュリティサービス「Security by Design」を実現し、ビジネスの安全をご提案。クラウドを活用するシステムの特性により、セキュリティ対策や運用内容が異なる為、ITSは、多様なITプラットフォーム全体に対し、情報セキュリティを企画・設計段階から確保した導入・運用を行い、お客様のビジネスの安全を確保


TISが提供するクラウド関連サービス

9

常に一歩先ゆくパートナーとして、お客様のクラウド活用を牽引します。


ところで、、、

10

Q. 大事なお金、どこに置いてますか？



11

Q. 大事なお金、どこに置いてますか？

A. 銀行



12

Q. 大事なサーバ、どこに置いてますか？


A. AWS ＋ TIS （事例）

2017/12/14 TISニュースリリース https://www.tis.co.jp/news/2017/tis_news/20171214_1.html

13


本日のテーマ

14

お客様へのご支援を通じて得られた

AWS大規模展開のポイント

をお伝えいたします


① 計画 Chapter2

15


クラウドのメリット

16

アジリティセキュリティコンプライアンス

コスト

最適化

運用負荷

低減

一般的なメリットは、いろいろあるけど特に重要なところはどれ?


アジリティ

17

①必要なITリソースがすぐに調達可能

③初期投資を抑えて開始可能

②PoCの実施が容易

クラウドが提供するメリット


アジリティ

18

最適化された課金体系

コスト

時間

実際の稼働状況

インスタンス変更を行った場合の実態メリット①余剰コスト削減

メリット②不足・機会損失の排除


アジリティ

19

最適化された課金体系というけれど、、、 EC2は、サーバを止めて、インスタンスタイプを変更しないと金額が変わらない

コスト

時間

実際の稼働状況

インスタンス変更を行った場合の実態

このインスタンスタイプの変更、だれがやるの？


アジリティ

20

サーバが増えるとこうなる

コスト

時間

システム毎にスケールすべきポイントが異なる →対応なしにはクラウドのメリットを享受しきれない

※このままいく、という判断も必要


アジリティ

対応方針は２つ

・自動化（予測可能なもの）

ロジックの作成 → コード化/実装

・運用対応（予測できないもの）

判断基準/ポイントの作成 → 定型運用化

21


アジリティ

・自動化（予測可能なもの）

ロジックの作成 → コード化／実装

・運用対応（予測できないもの）

判断基準／ポイントの作成 → 定型運用化

一旦運用を開始してしまうと、あとから対応させるのは非常に労力がかかる

最初から、自動化・運用を想定して構築


23

クラウドのメリット① コスト最適化を享受するため最初に、自動化・運用を想定して構築すべき

クラウドのメリット② 即時構築/PoC クラウドのメリット③ 初期コストの抑制

最適化というメリットが、スモールスタートというメリットを殺す？

ということは、コンソールを「ぽちっ」と押すだけの起動では使えない？

アジリティ


アジリティ

24

・PoC/単システム

→個別対応、個別運用で乗り切ることが可能 -トライアルなので、費用もないのでスペック不足を許容する

-単システムなら、普段の運用の中で業務運用のついでに

・大規模移行

→自動化/運用設計は必須

-個別要件に対応するはずが、対応できず余剰状態に

-全体が見渡せなくなり、結果、野放しの管理に


アジリティ

25 ・・・いるわけない！

マッスル AWS運用技術者




我社にはこんなにたくさんのAWS運用技術者が！

システムに比例して運用管理者をふやせればいいが・・・


アジリティ

26

ちなみに、基盤づくりをせずに拡張するとどうなるか・・・。

野良クラウド/シャドーIT

管理者不在

セキュリティホール

責任の押し付け合い

結果、管理できていなかった情報システム部門の管理監督責任に。。。


最初から、クラウドに適した設計を導入しながら移行

アジリティ

27

クラウド・ネイティブ

リフト＆シフト

初期プロジェクト PoC/単システム

大規模移行

クラウド・ネイティブ化

ハード老朽化更新目的でクラウドへ単純移行

クラウドへ移行した後で、クラウド最適化を目指す

実は、大きな壁がある

単システム移行と、大規模移行の間に・・・


アジリティ

28

クラウド・ネイティブ

リフト＆シフト

基盤作り初期プロジェクト PoC/単システム

大規模移行


ハード老朽化更新目的でクラウドへ単純移行

クラウドへ移行した後で、クラウド最適化を目指す

基盤づくりフェーズが必要（運用を含めた検討）

最初から、クラウドに適した設計を導入しながら移行


基盤づくりって何？

29

オンプレ時代のデータセンタ移設検討項目

– 耐障害性含めたHW構成検討 – 移設対象サーバ選定 – データセンタ選定 – サーバ監視構築 – ネットワーク構築 – 障害対応運用設計 – 保守ベンダによる復旧サービス – アプリのリカバリプラン策定

・・・etc.

クラウド時代も基本的に考えることは一緒

運用からはリリースされますが、どう運用するかを考えなくていい

わけではありません！

データセンタ自社サーバ室

アジリティ


計画

「クラウド」の基盤整備では何をするか？

30

まずは、基盤移行を「計画」する！！

＜計画における３つのポイント＞

①現状把握

②移行したときのメリット・デメリット

③移行の実現可能性


計画するにあたり、、、

31

「とりあえず、全部AWSに持っていきたいんですけど・・・？」

「なにを持っていくんですか？」

「よくわらかないので、全部です！」


①現状把握

見積り・稟議申請に最低限必要な情報

・どれくらいのスペックのサーバで、HW的な過不足はないか？ →実利用量を、時間ごとに把握し、オンデマンドでよいか判断。

・動作しているアプリケーションは何か？ →どのベンダに動作確認すべきかを把握。

・今まで、いくら費用がかかっているのか？（ハードウェア費用、ライセンス費用、回線／NW関連費用、データセンタ費用、電気代、空調費、運用保守費用、システム維持管理の人件費、次回HW更新費用…etc.）

→現状とのコスト比較（お客様しか分からない項目が多い）

32


②移行可能性

そもそも、AWSに移行できるのか？

＜よくある移行検討のトラブル＞

・各種EoSが終了し、切り替えまでサポートが続かない

・アプリケーションがそもそも動作保障をしてくれない

（APのバージョン問題はほぼ発生）

・ライセンスの買い直し／追加が発生

（SPLA/SAなどのライセンス追加など含む）

33


②移行可能性

そもそも、AWSに移行できるのか？

＜よくある移行検討のトラブル＞

・各種EoSが終了し、切り替えまでサポートが続かない

→EOSの調査

・アプリケーションがそもそも動作保障をしてくれない

（APのバージョン問題はほぼ発生）

→アプリケーション動作確認/PoC

・ライセンスの買い直しが発生

（SPLA/SAなどのライセンス追加など含む）

→既存資産の棚卸 34


③移行した場合のメリット・デメリット

本当にメリットがでるのか？

＜思っていたのと違うパターン＞

・既存データセンタを解約できないので、二重課金

・アプリケーション作り直し！

（PKG切り替えなどタイミングが良いならばまだしも、、）

・もっていったら、動作が遅い・・・

35


メリットの出る最適解を探すために

36

対応方針は2つ

・自分でやる

外部流出コストはおさえられるけど、

時間も労力もかかる

・プロ（TISのサービスコンサルタント）の支援を受ける

最適な移行プランを設計支援


ちなみに、プロが計画すると

• いつまでに、何を実現するか

• 将来像＋見直し/中間点

• 見直す内容とポイントを設定

37

基盤作り初期プロジェクト

移行


AWSを熟知したプロフェッショナルが、お客様に確実な移行（リフト）を計画

見直し


絵に描いた餅

すばらしい？計画ができた。

実行するのは、だれ？

38


体制

よくある悩み

• 現行システムの運用と、新ステム検討の二足のわらじ

• 既存構成の影がちらつく

• パワーバランス（費用負担部門、要件確定）

39


体制

推進体制（CCoE)の必要性

40

backbone system

infrastructure

application

business


体制

41

ユーザ部門

CCoE

意思決定ガバナンス全体調整教育/育成

パートナー

全社およびパートナーとのコミュニケーションを集約する

…その他、各種APベンダ

ユーザ部門

ユーザ部門


体制

対象業務

対象システム対象組織

管理部門から戦略部門へ

保守・運用から戦略企画へ

全システムからコアシステムへ

現状の姿

将来の姿

クラウド・ジャーニーを通して、お客様自身も変革

42


② ルール整備 Chapter3

43


ルールを整備する

推進体制ができた。

みんな、ついてきてね！

44



推進体制ができた。

みんな、ついてきてね！

45

掛け声で、ついてくるなら苦労しない、、、



46

組織をうごかすために必要なこと

それこそ、社内ルール


ルール整備

47

社内ルールを整備する際のポイント

各部門が実行可能なルールを作るのはもちろんですが、、、

• コンプライアンスにそった運用ルール

• セキュリティポリシーの見直しを忘れずに


オンプレとは異なる、責任範囲

ファシリティ（耐震、空調、防火設備等）

ネットワークインフラ

コンピュートインフラ (物理サーバ、ストレージ、仮想化レイヤ）

サービスの範囲

OS

セキュリティ

運用ツール

AWS

Proxy、踏み台、NTP

ウイルス対策、セキュリティパッチ管理

監視、ジョブ、ログ管理、バックアップ

アカウント管理、ネットワーク設定、障害対応

データ

ミドルウェア

アプリケーションアカウント管理、データバックアップ/リ

ストア

変更管理、資産管理

サービス利用者

48

AWS cloud


コンプライアンス

49

公共： NISC 金融業界： FISC クレジットカード業界: PCIDSS 医療： CSV 全業界：サイバーセキュリティ経営ガイドライン・・・etc

各々の会社が守るべき、外的要因（コンプライアンスプログラム）は何か？



50

例）PCI DSSへの準拠

①AWSのサービスがPCI DSSに準拠しているもの ⇒AWSサービス及びその機能で対応できる ②AWS上のシステムとしてPCI DSSに準拠が必要なもの ⇒AWS以外の機能で対応するものあるいは運用で対応するもの



51

①AWSが担保してくれる領域

すべてを自身で取得することは非常にコストがかかること

AWSが取得しているレポートの利用は、利用者がコンプライアンスに準拠する場合の助けになる

出典：https://aws.amazon.com/jp/compliance/pci-data-privacy-protection-hipaa-soc-fedramp-faqs/ より抜粋



52

★ガイドラインとは

★ガイドラインが必要な理由

指標・指針

・クラウドの理解・情報セキュリティ対策・運用の標準化／効率化

②AWS利用者が対応すべき領域

明示化することで組織を統制する


ガイドラインの具体例【ガイドラインテンプレート項目例】 1.はじめに目的とともに、本環境に関わる関係者を明確にする 2.基本情報「AWSとは」という基本的内容を記載 ※AWSを利用するための前提知識も合わせて記載 3.基本方針アカウント、権限、セキュリティ、運用に関する基本ルールを記載 ※共通基盤が提供する共通管理サービスについても触れる 4.手続きアカウント発行や利用に必要な手続きを記載 5. AWS環境のシステム構成（ネットワーク構成） AWS上のシステム構成を記載 6.AWS環境への通信経路関係各所とシステムの通信経路を記載 7.サービスの利用方法 AWSのサービス毎に利用方法を記載 8.運用運用方法について記載 9.課金について課金に関する説明内容を記載 10.お問い合わせ一覧

テンプレート利用のメリット

①ゼロから検討する時間を短縮

53

③ノウハウを共有できる

②アウトプットイメージが共有できる

④自社のポリシーに合わせてカスタマイズ可能


セキュリティ対策

54

設定されたコンプライアンスのハードルを越える、

セキュリティ対策の実装と運用

超えるべきハードルを認識したうえで、、、

が必要



①オンプレでも必要になるセキュリティ対策

→今まで通り、対応をお願いします！

②クラウドならではのセキュリティ対策

→サービス内の高権限管理

55


クラウドサービスの怖さ

56

Management Console

利用者

うっかり操作で、

個人情報が

インターネットに公開。。。

SecurityGroup の設定ミス


AWSはセキュリティを守る「機能」を多数提供してくれます。

提供された機能を「使う」のを忘れずに



セキュリティ対策に利用できるサービス

・サービス操作に対する認証／認可 ⇒AWS Identity and Access Management（IAM）・データの暗号化 ⇒AWS Key Management Service（KMS）・サービス操作ログの取得 ⇒AWS CloudTrail ・構成管理／変更管理 ⇒AWS Config／AWS Config Rules




59

AWS IAM の管理

『IAM のベストプラクティス』参照：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html#use-access-levels-to-review-permissions

AWS アカウントのルートユーザーのアクセスキーをロックする個々の IAM ユーザーの作成 IAM ユーザーへのアクセス権限を割り当てるためにグループを使用する AWS 定義のポリシーを使用して可能な限りアクセス権限を割り当てる最小権限を付与するアクセスレベルを使用して、IAM 権限を確認するユーザーの強力なパスワードポリシーを設定特権ユーザーに対して MFA を有効化する Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する認証情報を共有するのではなく、ロールを使って委託する認証情報を定期的にローテーションする不要な認証情報を削除する追加セキュリティに対するポリシー条件を使用する AWS アカウントのアクティビティの監視

いちから考える必要はないけれど、、、



60

・AWSアカウント（ルートユーザ）の管理は? ・IAMユーザは誰が作成するの? ・IAMユーザは誰が利用できるの? ・ポリシーはどうするの?（最小権限??）

『IAM のベストプラクティス』はあるけど組織にあわせた考慮が必要

そのままでは使えません

AWS IAM の管理（誰に操作／管理させましょうか）



机上のセキュリティ対策設計

PoCで確認してみましょう


PoC（Proof Of Concept）

62

検証してみましょう

Management Console

利用者


ルール整備

63

ようやく。。。

実行可能な「ルール」が完成しました！！


③運用 Chapter4

64


運用

65

作ったルール。

そのままにしておくと「どんどん陳腐化」


運用サポート体制

66

サービスオペレーション

お客様 TIS

サービスデスク

・単一窓口

・インシデント管理

IT戦略の立案/ 全体方針策定/ 導入企画

業務アプリ開発/ 保守/運用

インフラ構築/ 保守/運用

IT運用管理

技術管理アプリ管理

1次対応受入手順対応

2次対応インフラSE対応

2次対応アプリSE対応

問題管理 -インシデントに紐づく、1次/2次対応

要求実現 -定期オペレーション、依頼対応、問い合わせ対応など

監視システム

統合運用管理基盤

サービスオーナコンサルティング

サービスストラテジサービスデザイン

サービストランジション継続的サービス改善

システム障害通知/対応

・ITサービス戦略管理

・サービスポートフォリオ管理

運用チーム

企画/CCoE

実績報告/改善活動

導入提案/改善活動サービス拡張対応サービス拡張対応

・デザインコーディネーション -サービス要件定義（SDP） -設計

・改善プロセス

構築/受入対応構築/受入対応

・変更管理

・リリース管理

サービスデザインサービスストラテジサービストラジションサービスオペレーション

継続的サービス改善 ITIL v3におけるサービスライフサイクルの5つの段階

ガイドライン

依頼対応メニュー

月次報告

全体計画立案

手順書/ 連絡先等

TISが考える運用サポート体制


監視運用

67

監視は運用の基本

CloudWatch

監視サーバ

:Zabbix Agent監視

:CloudWatch連携

凡例）

:Web監視（URL監視）

:運用／保守拠点への通知

運用／保守担当者

運用／保守拠点


ログ管理運用

68

ログの収集・保管

OSログ

CloudTrail

ELBアクセスログ

ClpoudFront

Lambda

VPC Flowlogs

API Gateway

RDS

Cloudwatch Logs

S3

サービス毎にログの出力が違う ⇒すべてがCloudwatch Logs に統合されているわけではない

すべてのログをS3に集約・保管（高耐久性／安価）

ログ集約・保管処理

活用（ログ解析／分析処理）


ログ管理運用

69

ログ仕様（いろんな注意例）

CloudWatch Logs エージェントは、フォーマット間違うとログを正しく保管できない

CloudFrontのアクセスログは、最大24時間遅延する

RDSのログは、データベースエンジン毎に仕様が異なる

重要ソースログファイルには、各ログ行の先頭にタイムスタンプがあり、タイムスタンプの後にスペースがある必要があります

CloudFront は通常、その期間のログファイルを、ログに書き込まれたイベントの発生から 1 時間以内に Amazon S3 バケットに配信します。ただし、ある期間のログファイルエントリの一部またはすべてが、最大で 24 時間遅れることもあります。

MariaDB、MySQL、Microsoft SQL Server、Oracle、PostgreSQLで出力されるログファイルの種類も保持期間やローテーションの仕様もバラバラ。同じデータベースエンジンでもRDSとAuroraで微妙に違う。


セキュリティ運用（Managed Security Service）

70

Advanced Security Operation Center

Internet

●マネージドクラウドSIEM クラウド型SaaSのSIEM Trustwave Global Threat DBと連携 ●マネージド WAF

振る舞い型検知で未知の脅威へ対応 ●マネージド UTM ●マネージド Next Generation Firewall (Paloalto,Cisco,FortiGate,Trustwave) ●マネージド IPS (McAfee NSP / Cisco FirePower) ネットワークレイヤーでの攻撃による通信抑止

●マネージドクラウド SWG 振る舞い型検知で”ゼロデイ”対策。マルウェア感染保証も

●マネージドFireEye マルウェアがダウンロードされた端末の挙動などを検知し、情報の流出や実行をブロック（サンドボックス）

●脆弱性スキャンクラウド型脆弱性調査

●マネージドセキュリティテスティングペネトレーション（侵入）テスト

貴社環境

DeepSecurity

クラウド

●マネージド TrendMicro DeepSecurity AWS環境のDeepSecurityをサポート


お客様環境

Deep Security Manager

保守環境

Trustwave SOC

VPNルータ保守端末

Internet

SOCアナリスト

システム運用者

ASOC

Deep Security Agent

Global 脅威DB

LCA

LogCollector

Trend Micro Deep Securityと脅威分析により、継続的にセキュリティを強化

セキュリティ運用（Managed Security Service）


継続的改善

72

AWSは常に進化しており、旧来のやり方では対応しきれない

AWS からの最新のお知らせ

参照：https://aws.amazon.com/jp/about-aws/whats-new/2018/

2018年の発表で、405件

サービスアップデートにより、従来できなかったことができるようになる

サービス仕様の変更により、仕組みを変更する必要が起きる

実装が困難であきらめていたことがサービスアップデートにより、容易に実現できるようになる


継続的改善

73

AWS関連情報収集の方法（一例）

SlackにRSSを連携

何か対応することはあるだろうか?


本日のまとめ

74

計画

運用ルール整備


事例紹介 Chapter5

75


社内事例

76

社内システム

社内開発環境

お客様向けの自社サービス提供基盤

新サービスのPoC環境

社内利用状況

Documents

大規模展開を成功へ導く3つのポイント ～「計画」「ルール …...モダナイゼーションビジネス事業部 コンサルティングの推進、コンサルティングサービスの提供

大規模展開を成功へ導く3つのポイント～「計画」「ルール …...モダナイゼーションビジネス事業部コンサルティングの推進、コンサルティングサービスの提供