クラウドネイティブへの第一歩 移行計画の立て方を学ぶ NCDC Onlineセミナー 2020年10月6日 NCDC株式会社

自己紹介 十川 亮平 取締役/CTO NCDCでは、モバイル、API、IoT、機械学習 などを使った新規サービスの企画立案や、 プロジェクト推進の支援を担当。 Webサービス／モバイルアプリのバックエ ンドプラットフォームである「AppPot」の プロダクトマネージャーとして、マーケ ティング活動やAPIの開発を行っている。

NCDCのご紹介

私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP（Minimum Viable Product）を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善

私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニ アによる技術移管まで、幅広くお客様をサポートします。 5 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング

Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 6 NCDCのサービス体系

本日の内容 l 移行計画のプロセスから、計画の策定まで l クラウドのメリットおさらい l クラウド移行計画の難しさ l 計画策定のプロセス l どこに行くのか？クラウド移行の目的を決める l どこから着手するか？マスタスケジュールの作成 l どういう形で移行するか。移行パスとアーキテクチャの検討 l どうやって移行するか？移行方式の選択 l 非機能要件の検討 l クラウドネイティブとは l まとめ 7

移行計画のプロセスから、計画の策定まで

DX推進の課題の一つとして既存システムが挙げられています 9 経済産業省「デジタルトランスフォーメーション に向けた課題の検討 ～ ITシステムに関する課題を中心に ～」より引用 https://www.meti.go.jp/committee/kenkyukai/digital_transformation/pdf/001_haifu.pdf

クラウドを活用して、自分たちがやりたいことにフォーカス 10 サーバー、ネットワーク ミドルウェア アプリケーション 運用・ 監視 ツール 認証など の共通機 能 サーバー、ネットワーク ミドルウェア アプリケーション 運用・ 監視 ツール 認証など の共通機 能 オンプレ クラウド 既存システムにかけていた時間、人員をクラウドが提供するサービスを使用することで、 より直接的にユーザーに価値を生むアプリケーションに集中できる。 またクラウドの特徴である、俊敏性、使った分だけ課金、拡張できるインフラと 相性の良いアジャイル、DevOpsなどのプラクティスを取り入れやすくなります。

① 対象のシステムの特性に依存します l クラウドの費用の特性は使った分だけ、という考え方 l 24時間・365日定常的に高い使用率の場合は、サーバー費用だけ見る とオンプレの方が安い場合があります l 逆にいうと使用率が変動するような場合では、大きく費用を下げるこ とができる可能性があります。 ただし！次ページ以降に続きます クラウド移行でコストは下がる？ 11 オンプレの場合、 ピークに合わせて リソースを調達 実際の使用率 クラウドの場合、 必要に合わせて リソースを追加、 削減が可能

クラウド移行でコストは下がる？ ② オンプレと同じ考え方では下がらない場合があります l 直近必要なだけのリソースを使用する見積もりにする l オンプレのサーバーでCPUの使用率がピークで10%台ということ、よくありま せんか？オンプレの場合、一度買ったサーバーを拡張するには時間がかかり ますので、予め２年後、３年後の処理量を予測して購入します。一方、処理 量が予測通り増えないこともよくあることです。 l クラウドの場合、リソースの追加はWeb管理画面から設定を 変更するだけになりますので、各種リソースの使用量の見える化と それに応じてリソースを追加できる予算取り、体制を準備しておきます l 必要に合わせてリソースを追加、削減できる仕組みにしておく l CPU、メモリなどのリソースの追加は比較的簡単にできますが、サーバーの 追加、削除までやる場合、事前にそれができるように設計しておく必要があ ります l インフラの設定だけではなく、アプリケーションとしてもそれができるよう に事前の設計が必要です 12

クラウド移行でコストは下がる？ ③ サーバーの費用と、AWSコストの比較だけでなく、 運用コストや開発に与える影響も加味して考慮する l 実際の運用には、サーバーの費用やAWSの費用だけでなく、 運用にかかるさまざまなコストや、人などのリソース、 ハードウェアが故障するなどのトラブルが合った場合の対応などを 考慮する必要があります。 13

クラウド移行計画の課題 l 一方で、クラウド移行の計画がなかなか進まないという プロジェクトもよく聞きます l 何から手を付けてよいのか分からない l いろいろな移行の仕方があるが、どれが良いのか分からない l 機密データのため、クラウド化することをリスクに感じている l なんとなくクラウド化したほうが良いと思っているが、セキュリティ が心配など反対意見が多くて進められない l 今回はこのような課題をクリアしつつ、クラウド化の計画を立て るためのポイントを整理したいと思います 14

クラウド移行計画のプロセス 15 移行計画 移行の 目的 定義 アプリ改 修 実行フェーズ 要求事 項、課題 の洗い出 し 優先度 付けとス コープ定 義 実現難 易度、コ ストの概 算見積 マスタス ケジュー ル作成 非機能 要件の 検討 アーキテクチャの設計 インフラ設 計・構築 アプ リ移 行 テス ト デー タ移 行 運用の準備 要件定 義 要修正 項目洗 い出し 下記の移行計画を推進することを目的としたチームが必要。規模にもよるが専任でなくても良い。

どこに行くのか？クラウド移行の目的を決める l 前述のクラウド移行のメリットの通り、クラウド移行と言っても様々な メリットがあり、何を主目的にするかによってアプローチが異なります。 また、人によって想定しているクラウド化のレベル感も異なります。 l その後の計画をスムーズにすすめるために、クラウド移行を何のために やるのかを関係者、経営層と認識を合わせておく必要があります。 16 クラウド上でIaaS的なサーバーを借りて、その上にこれまで 作っていたアプリをそのまま動かすのを優先しよう クラウド化と一緒にアプリケーションに 新しい要件を追加したい 今度、改修予定のあのシステムだけクラウド化するか検 討すればいいよね すべてのシステムを段階的にクラウド化する 検討をしたい

クラウド化の目的のアプローチのサンプル l 顧客接点となるアプリケーションを迅速に機能追加や、画面レイ アウトの変更をできるようにすべき これにより、採用するアプローチは「対象となるシステムはクラウドに 最適化した構成で再構築。開発プロセス含めて刷新する。変更頻度の低 い社内システムはクラウド化の優先度を下げる。」などが考えられそう です。 l サーバーのメンテナンス契約が切れるタイミングで、順次クラウ ドに移行して自社でのサーバーのメンテナンスはやめる。これに より、システム移行時の初期コストを下げる。 この場合は、「アプリケーションはクラウド上で動かすための最低限の 改修だけ行い、クラウド上に移行することを最短、低コストで行うこと ができる手法を選択する。」ことが考えられそうです。 17

目的を具体的な施策に詳細化する 18 企画側だけではなく、現行システムの担当者、（運用チーム、インフラチーム） などを交え、ワークショップなどの手法を用いて目的を達成するための 施策や対象のシステム群を洗い出します。 要求事項一覧 移行候補 システム一覧

どこから着手するか？ 基本的に前述の目的で定義した「クラウド化の目的」と、クラウド化の難易度 （技術的な難易度、移行にかかるコスト、リスク）で評価した場合に、「クラ ウド化の目的に合致していて、難易度の低いもの」から着手すべきです。 19 効果が高い メリットを得られる 効果が低い 移行のコスト、 リスクが低い 移行のコスト、 リスクが高い ①最初に移行を計画する ②費用対効果を評価し、 移行するかどうか判断する ②システム改修や、保守切れなどの タイミングに合わせて移行 ③基本そのまま。 システム改修や、保守切れなどの タイミングに合わせて移行

l 対象システム、アプリケーションの相対評価 どこから着手するか？ 20 効果が高い メリットを得られる 効果が低い 移行のコスト、 リスクが低い 移行のコスト、 リスクが高い 1 2 3 4 5 6 7 8 9 10 STEP 1 STEP 2 要求事項一 覧 移行候補 システム一 覧

施策を評価するためのスコアリング（必要に応じて） l 対象システムの相対評価はマトリクスに直接プロットし、 関係者で認識が合うのでしたら、それで十分です。 合意形成にもう少し議論が必要な場合は評価項目ごとにスコアリング後、 前ページのマトリクスに配置するというアプローチもあります。 21 評価項目 システ ム1 システ ム2 システ ム3 システ ム4 システ ム5 得られる メリット 情報をリアルタムで見られる 10 1 1 1 1 社外からも情報参照できる 3 2 2 4 4 ・・・・・ 2 1 2 7 6 ・・・・・ 1 1 2 2 4 合計 16 5 7 14 15 移行難易 度 移行コスト -5 -10 -10 -10 -10 技術的な実現性 -5 -8 -8 -6 -8 -2 -5 -4 -2 -7 -5 -3 -5 -5 -5 合計 -17 -26 -27 -23 -30 前段階で定義した目的から導出 メリットが大きい場合、プラス評価 IT部門やベンダーと協力して評価 難易度が高い場合、マイナス評価

l コストと期間を概算見積もりし、各フェーズの対象範囲と 大まかなスケジュールを決めます どこから着手するか？ 22 効果が高い メリットを得られる 効果が低い 移行のコスト、 リスクが低い 移行のコスト、 リスクが高い 1 2 3 4 5 6 7 8 9 10 STEP 1 STEP 2

STEP1 〜2021/9 STEP2 〜2022/6 システム 7 システム1 システム9 システム4 システム8 システム6 マスタスケジュールの作成 23 前述のフェーズ分けとスケジュールを元に マスタスケジュールを作成する

STEP1 〜2021/9 STEP2 〜2022/6 システム 7 システム1 システム9 システム4 システム8 システム6 マスタスケジュールの作成 24 前述のフェーズ分けとスケジュールを元に マスタスケジュールを作成する STEP 0 パイロット プロジェクト もし、クラウド化に技術的な不安がある場合、 クリティカルなシステムに取り組む前に リスクが小さいシステム、または 実際には商用リリースしないシステムをパイロットプロジェ クトとして一通りを経験するのも有効です

どういう形で移行するか 移行パスとアーキテクチャの検討

非機能要件の検討 l 非機能要件とは、 アプリケーションの画面や業務ロジックなどではなく、処理性能や、セキュ リティ、格納できるデータ容量などの機能以外の要求を定義したものです l 例えば、 l システムの稼働時間は？夜間は止めても大丈夫？ l 同時に使う人数は？障害発生をどこまで許容するか障害発生時の復旧までの時間 l ソフトウェア更新時にシステムが止まっても良い？ l データのバックアップの頻度は？ l システムログはどこまで必要 l 障害を追うことができればよい？個人単位のアクセス履歴が必要？ l 保存期間は？3ヶ月、1年、永続？ l 要求が高くなると当然コストも上がるので、費用に対する効果を見る必要が ある 26

非機能要件の検討 27 項目はIPAが定義した非機能要求グレードというものがあります。 項目数はかなり多いですが、クラウドであれば検討が省略可能な項目もあります。 自社の現行の要求が分かっている方と、クラウドの専門家に相談して、評価するのが良いでしょう。 https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

どういう手法で移行するか l どの移行パスを選択するかは、前述の移行の目的と、対象のシステムの 使用している技術（プログラミング言語、使用しているミドルウェア、 フレームワーク等）や、作りに依存します。 l パスは統一する必要はなく、システムごとに適したものを選択します 破棄 維持 （移行しない） アプリはそのまま 配置場所をクラウドにする アプリのコア機能は そのまま。一部のみ クラウド最適化。 クラウド上のサービスや 製品に置き換える クラウド前提で 設計・開発する AWSが定義するクラウド移行パターンから引用。 他クラウドベンダーも移行パターンを公開しており、細かい部分は違いますが、大きい部分では同様です。 28

アプリケーション以外の移行の検討 l アプリケーション以外に下記についてもクラウド上への移行を検 討します 29 運用 バックアップ 連携方式 他システム連携 監視 自社NWとクラウド 間の通信経路 これらをどう既存の運用の体制 に組み込んでいくか ログ出力、管理

クラウドネイティブなアプリケーション設計 l クラウドを利用することで、インフラの調達、管理をクラウドベ ンダーに任せることができるようになりました l さらにクラウドを前提としたアプリケーション設計を 行うことで、「俊敏性（アジリティ）」、 「拡張性（スケーラブル）」を得られます l このような構成をクラウドネイティブと呼びます 30

クラウドネイティブとは l コンテナ、サーバレスなどの技術、 クラウドベンダーが提供しているマネージドサービスを 積極的に利用してサービスの設計、開発を行います l 俊敏性 l 自分たちで作る量を減らし、クラウドベンダーが提供している機能を サービスとして利用する l インフラだけでなく、OS、ミドルウェアをプラットフォームとして提 供し、その上に作る自分たちの付加価値提供に集中する l 拡張性 l 利用者の増加に応じて、オートスケールできる基盤、アプリケーショ ンの設計にする 31

構成例）サーバレスとマネージドサービスをフル活用したアーキテクチャ 32 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 コンテンツ 配信

構成例）サーバレスとマネージドサービスをフル活用したアーキテクチャ 33 Webアプリ コンテンツ アプリ向けAPI Lambda 業務ロジック DynamoDB 添付ファイル Cognito ユーザー認証 利用者 社内システム 社内システム 社内向けAPI Lambda 業務ロジック マスタ データ連携 バッチによる 日次データ取り込み AWS 自社データセンター Cloud Front S3 コンテンツ 配信 AWS Lambda サーバレスな処理実装 Cognito マネージドな 認証サービス DynamoDB スケールアウト可能な データベース アプリケーションは S3とCloudFrontで配信

まとめ 34 移行計画 移行の 目的 定義 アプリ改 修 実行フェーズ 要求事 項、課題 の洗い出 し 優先度 付けとス コープ定 義 実現難 易度、コ ストの概 算見積 マスタス ケジュー ル作成 非機能 要件の 検討 アーキテクチャの設計 インフラ設 計・構築 アプ リ移 行 テス ト デー タ移 行 運用の準備 要件定 義 要修正 項目洗 い出し

NCDC公式ホームページの「コラム」もご活用ください 35 関連する過去セミナーの資料 「DXを実現する組織とロードマップのつくり方」 https://ncdc.co.jp/columns/6798/ 「DXを成功に導くための３つのキーファクターとは」 https://ncdc.co.jp/columns/6496/ 「マネージャー層向けモダンアプリケーション開発戦略セミナー」 https://ncdc.co.jp/columns/6626/

お問い合わせは l [email protected]まで 36

No content