Non-IT人材でもわかる！ システムアーキテクチャ「キホンのキ」 2021 / 08 / 26 NCDC株式会社 NCDC Online Seminar

島田 将人 シニアコンサルタント 前職にてシステムエンジニアとしてキャリ アをスタートし、公的機関の大規模な業務 システム開発、及びAIを用いた新規システ ムの開発・保守に従事。 NCDCに入社後もビジネスコンサルティン グやシステム開発マネジメント、データ分 析案件等、多岐にわたる業務に従事。 2

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 事業部門でDX推進のミッションを与えられ、これからシステム開発含 めたDX施策を遂行しようとしている方 l システム開発プロジェクトに参画するにあたり、モダンなシステムの 構成要素やアーキテクチャに関する知識、検討ポイントを知りたい Non-ITの方 8

アーキテクチャの歴史

l アーキテクチャは、歴史を繰り返しながら発展してきている l サーバーとクライアントそれぞれに担当させる情報処理量の比重の 逆転が繰り返されている アーキテクチャの歴史 10 ホストコンピューター サーバー：Fat クライアント：Thin ダム端末 クライアント サーバーシステム サーバー：Thin クライアント：Fat VB,C++ ,Notes Webアプリ サーバー：Fat クライアント：Thin PHP, Java, .Net SPA サーバー：Thin クライアント：Fat React,Vue.js 技術の オープン 化 クライア ント配布 の簡素化 スマート デバイス の登場

アーキテクチャの基礎概念

SPA(Single-Page Application) l ページ遷移を行わないWebアプリケーション l 従来の「サーバーでページを生成して返す」という考え方ではなく、 「サーバーはデータやビジネスロジックを担当し、ブラウザがその処 理を基にページを生成する」のが特徴 l Google mapsやFacebookがSPAの有名な例 12 指やマウスで上下左右したり ズーム・ワイプしたりすると、 ページ遷移せず必要な情報を 表示 https://www.yahoo.co.jp/ https://www.google.co.jp/maps • 1ページあたりの情報量が決まって おり、リンクを辿ることで次ページへ 遷移するアプリケーションの例 • 全てが悪いわけではない(今でも多く 用いられている)が、たとえば地図ア プリがいちいちページ遷移すると操作 性は良くない

l フロントエンド l クライアントの画面表示・及び画面に近い部分 l 開発言語・フレームワークの例 l Web系：HTML, CSS, JavaScript, React, … l モバイル系：React Native, Swift, Kotlin, … l バックエンド l サーバー側・及びサーバーに近い部分 l 開発言語・フレームワークの例：Node.js, Python, Go, … l 担う役割の大きさや役割そのものが時代によって変わっている Webアプリの時代 SPAの時代 フロント エンド バック エンド フロントエンドとバックエンド 13 Web API • フロントエンドと バックエンドは一 体で考えられ、開 発されることが多 かった • 開発言語も共通 Mobile • スマートフォンの登場 による実装技術の高 度化(ネイティブアプリ の出現)で、大きな役割 を持つようになった • 異なる言語で開発する ことが主流になった

マイクロサービス l 機能の塊でシステムを分割する考え方 l 各マイクロサービスは独立性を保ち、他サービスと連携しながら全体の 機能を提供する l ECサイトで商品、買い物かご、決済、顧客管理を別のサービスとして構築 l 業務機能要件が多く開発規模が大きなシステムや、継続的な改修対応が 行われるシステムに適している 14 モノリシックな システム マイクロ サービスA マイクロ サービスB マイクロ サービスC • 様々な機能を１つのシステムで 実現 • 各機能やデータは密に連携して いるため、システム改修時に 影響範囲が大きく、変更に 時間がかかる • 機能ごとでシステムを分割 • システム間の通信にAPIを用いることで、 疎結合を実現 • システム間のつながりが弱いため、 システム改修時の影響範囲が小さい API API API フロントエンド

クラウドの概要と、よく出てくる用語

SaaS/PaaS/IaaS l クラウドによるサービス提供形態の種類 l SaaS(Software as a Service ) l クラウド事業者や各ベンダーが開発したソフトウェアを使用する形式 l PaaS(Platform as a Service) l クラウド事業者がインフラ・OS・ミドルウェアまでを提供し、ユーザーがシステムを開発し、 使用する形式 l IaaS(Infrastructure as a Service) l クラウド事業者がインフラのみを提供し、ユーザー がOS・ミドルウェアのインストール、 アプリケーションの開発をが行う形式 16 アプリケーション ミドルウェア OS設定 OS ハードウェア SaaSの提供範囲 アプリケーション ミドルウェア OS設定 OS ハードウェア PaaSの提供範囲 アプリケーション ミドルウェア OS設定 OS ハードウェア IaaSの提供範囲

SaaS/PaaS/IaaSの事例 •クラウド上で提供されるソフトウェア •Microsoft Office365 •Google workspace •Salesforce SaaS(Software as a Service) •クラウド上で提供されるOS・ミドルウェア・開発環境等のプラットフォーム •AWS/GCP/Azureのマネージドサービス •Kintone •ノーコード・ローコードツール PaaS(Platform as a Service) •クラウド上で提供されるサーバーやネットワーク等のインフラ •データセンター •クラウドサービスだが、単に借りるだけのもの •EC2(AWS)・ComputeEngine(GCP)・Azure Virtual Machine IaaS(Infrastructure as a Service) 17 上 に 行 く ほ ど 簡 単 に 使 い 始 め ら れ る

クラウドサービスの興隆によるシステム開発のあり方の変化 18 l 今までのパターン l システム構築時にはサーバーを購入したりレンタルサーバーを用意したりして、 ネットワーキングからミドルウェアのインストール、アプリケーションのデプロイまで 全て手作業で実施しなければならない l PoCを行うにも準備が大変だし、すぐに始めようとすると検証範囲が大幅に限られてしまう l クラウドサービスの登場により l ユーザーは、インフラやミドルウェアのことを気にする必要が なくなった l 必要なアプリケーションだけ開発すれば、すぐに使い始められる l 既製品(SaaS)を持って来れば、アプリケーションの開発すら不要

クラウドベンダーが提供するサービスの例 l 例えスクラッチ開発になるとしても、多様なサービスから必要なものを 組み合わせるだけで出来上がる(コーディングの量は大幅に減らせる) l セキュリティや監視といった非機能系のサービスも揃っている l ベンダー間(AWS, GCP, Azure)でそれぞれ特徴はあるが、大きな違いはない 19 AWSの主なサービス

[参考]よく耳にする技術要素

サーバレス l クラウドの文脈に特有な概念 l 実際には物理的なサーバー上にアプリケーションを 配置するが、開発者がサーバーやミドルウェアを 意識する必要がない l 使った分だけ費用が発生する l 暗黙的には以下のような処理が行われている ①クライアントからサーバーに対する処理要求が行われる ②ビルド済のアプリケーションをサーバー上に配置する ③要求された処理を実行し、必要に応じて処理結果を クライアントに返す ④サーバーに配置したアプリケーションを破棄する 21 • 従来、アプリケーションは サーバーに常駐している ものだった • クラウドだと、サーバーに 常駐させているだけで (使っていなくても)費用が 発生する サーバレス 従来型

l OSやハードウェアに依存せずアプリケーションを実行するための 実装方式 l アプリケーションと、アプリケーションを動作させるための ミドルウェアや各種ライブラリをコンテナとしてパッケージングして、 OS上にDocker等のコンテナエンジンを立てておけば、 OSやハードウェアといった動作環境に依存することなく アプリケーションを動かすことができる コンテナ 22 コンテナを使用した環境構築 コンテナを使用しない環境構築

スマートフォンにおける開発のポイント

スマートフォンで動作するアプリの全体像 24 スマホで 動作するアプリ モバイルアプリ ネイティブ アプリ iOS Swift Android Kotlin クロスプラット フォームアプリ ネイティブUI型 React Native 独自レンダー型 Flutter WebView型 (ハイブリッド アプリ) Apache Cordova ガワアプリ Webアプリ PWA PWA以外の Webアプリ 種類が多すぎる...。何がどう違うのか分からない。

スマートフォンで動作するアプリの概要 l まずはここだけ押さえましょう！ l スマートデバイスで用いられるアプリの形式は、「Webアプリ」と 「モバイルアプリ」の2種類に大別される l Webアプリは、ブラウザで動作するアプリ l モバイルアプリは、ストアで配布されるアプリ l 開発言語によって更に2種類に分けられる 25 Webアプリ モバイルアプリ ネイティブアプリ クロスプラットフォーム

WEBアプリ・ネイティブアプリ・クロスプラットフォームの特徴 Webアプリ モバイルアプリ ネイティブアプリ クロスプラットフォーム 概要 • ChromeやSafari等の Webブラウザで動作する アプリ • OSネイティブの言語で 開発されたアプリ • OSに依存しない言語で 開発されたアプリ 開発言語/ フレーム ワーク • HTML • JavaScript (Reactやvue.js といったフレームワーク を活用して開発すること が多い) • Swift (iOSのネイティブ言語) • Kotlin (Androidのネイティブ言 語) • ReactNative • Cordova • Flutter メリット • 実装コストが小さい • アプリのリリースやアッ プデートが容易(ストアの 審査を通す必要がない) • カメラやGPS等、 端末の機能を使いやすい • 両OSのアプリを同時に開 発できるため開発コスト が半減する デメリット • Home画面にアプリが置か れない • オフラインでの実行ができ ない • スマホ独自の機能を使用す ることができない (通知やヘルスケアの情報 取得など) • iOS, Androidそれぞれに アプリを開発しないと いけない • OSの最新機能を動かすこと ができない • 凝ったネイティブ機能を使 用する場合は、対応できな い場合がある 26

通知〜スマートフォン特有の検討ポイント〜 l システムからの情報更新を受信し、ユーザーに知らせる仕組み l メール通知とプッシュ通知が、主な通知手段 l プッシュ通知が必要ならモバイルアプリ化が必要 l 各クラウドの通知実装サービス l AWS：Amazon Simple Notification Service l GCP：Firebase Cloud Messaging l Azure：Notification Hubs 27 メール通知 プッシュ通知 メリット • 実装コストが小さい • ユーザーに気づいてもらい やすい デメリット • 他のメールに埋もれて、 気づかれない場合もある • 実装コストが大きい

ビジネスモデルに応じたアーキテクチャ検討のポイント

DXにおけるビジネスモデルパターンと、重要な検討ポイント l DXにおけるビジネスモデルのよくある例と、それぞれで特に検討 したいポイントを解説していきます 29 社外向け 社内向け to B to C ビジネスモデルごとの 検討ポイント 共通の 検討ポイント 1. 利用シーンに応じたデ バイスと実装方式の特 定 1. 可用性 1. 多様なデバイスへの対 応 2. 簡潔な認証の実装 1. 既存製品の積極活用と、 製品仕様に合わせた業 務フローの修正 2. スクラッチ開発のスリ ム化 ① 特定業界・業種向 けプラットフォー ム構築 ② 新規サービスの立 案・リリース ③ 既存業務のプロセ ス改革 ビジネスモデルの分類

l 特定業界・業種向けプラットフォーム構築の場合 1. デバイスと実装方式を見定める l ビジネスモデルに応じて、どのような形での開発が適しているかが変わっ てくる l 在庫管理や受発注系のビジネスをシステム実装する場合 l 基本的にはPCで操作することが想定されるため、Webアプリで開発 l 物流や建設の現場向けのビジネスをシステム実装する場合 l スマートフォンやタブレットでの操作が主となることが想定される l Webアプリでも問題はないが、GPSやバイタルデータといった端末からのデータ取得を求めるのであればモバ イルアプリ化が必須 l アプリの使用頻度が高い場合やプッシュ通知を必要とする場合も、モバイルアプリの方が適切 30 アーキテクチャの検討ポイント Webアプリ モバイルアプリ ネイティブアプリ クロスプラットフォーム

l 新規サービスの立案・リリースの場合 1. 多様なデバイスに対応する l 不特定多数のユーザーが使用するため、使用シーンに応じた対応デバイス (PC/スマホ/タブレット)の選択と、選択したデバイスに対して多様な機種に対 応することが求められる l サービスの使用頻度を高めたければモバイルアプリを開発してストアに公開するのが 最適 l 基本的にはiOS, Android OSへの対応が求められるので、開発効率や保守性を考慮するとクロスプラットフォームを採 用できるのがベスト l IoTサービスの場合、エアコン1つでも色々なメーカーのエアコンに対応させるか、 メーカーや機種を絞り込むか等の検討が必要 31 アーキテクチャの検討ポイント Webアプリ モバイルアプリ ネイティブアプリ クロスプラットフォーム 同じ機能のアプリを、iOS用にSwift で、Android用にKotlinで、 それぞれ開発しなければならない 1つの言語で、iOS, Android双方に 対応したアプリを開発できる

l 新規サービス立案・リリースの場合 2. 認証は簡潔にする l 頻繁にログイン認証を求められ、入力が煩雑だと ユーザーから疎まれる l 基本的には認証情報を保持しておき、有効期限を超 過した時だけパスワード認証や2要素認証を求める形 が考えられる l SSOも使いやすい l Google, Facebook, Twitter等、複数のアカウントでのSSOを 用意しておくと網羅率も向上する 32 アーキテクチャの検討ポイント

l 既存業務のプロセス改革の場合 1. 使えるものは使う l 既存製品を活用すれば、およそのことは実現できる l コミュニケーションツールをゼロから作らなくても、SlackやTeamsを導入すれば 良い l ファイル管理システムをゼロから作らなくても、BOXやGoogle Driveを使えば良 い l 業績管理システムや会計システム・人事システム等、たくさんのSaaSが出回って いる l 既存の業務に捉われず、「製品に合わせて手順を変える」という考え方 も大切 33 アーキテクチャの検討ポイント

l 既存業務のプロセス改革の場合 2. スクラッチ開発は、なるべくスリムに l どうしてもニーズにマッチする製品がなかったり、基幹システムとの接続 を実現したいというニーズがあったりしたら、スクラッチで開発する l 社内での利用なので、Webアプリで開発コストを下げるのが基本線 l もしGPSやバイタルデータの取得を前提として新たな業務の流れを確立し たければ、ネイティブアプリにする l 利用対象者が社内に限定されたアプリの場合、一般的な公開方式ではなく社員へ 限定的に公開する方式も用意されている l iOS：カスタムAPP l Android：managed Google Play 34 アーキテクチャの検討ポイント

l 各ビジネスモデルで共通の検討ポイント l 適切な可用性を担保する l フェーズに応じて高めていく l それぞれのフェーズでどの程度の可用性が必要となるかはプロジェクトに よって異なるため、プロジェクトの目的や性質に照らしてフェーズごとに 最適な可用性レベルを設定する アーキテクチャの検討ポイント 35 PoCフェーズ • 検証を行うときだけ稼働 • それ以上の稼働はコストの無駄 MVPフェーズ • 日中帯・平日等、実用を阻害し ない最低限の稼働 正式展開フェーズ • 業務やサービスに支障を及ぼさ ないレベルの稼働

本日のまとめ

本日のまとめ l 「アーキテクチャ」という言葉で表される領域は広大ですが、今 日は昨今特に触れる機会の多い2つの分野について説明しました l クラウド l スマートデバイス l 最後はDXとしてよく実施される3つのビジネスモデルについて、代 表的な検討ポイントを説明しました l 「皆様自身がアーキテクチャを設計する」というよりも「ベン ダーやシステム部門に要件・要望を伝える」機会の方が多いと思 います l 今日の内容が「要件・要望を的確に伝える」ことの一助となれば 幸いです 37

No content