Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Non-IT人材でもわかる!システムアーキテクチャ「キホンのキ」

NCDC
August 26, 2022

 Non-IT人材でもわかる!システムアーキテクチャ「キホンのキ」

業種を問わずDX推進が叫ばれる今、ビジネスとITはもはや密接不可分な関係です。
そのため、Non-IT人材であっても何らかのかたちでシステムの企画・開発に関わる機会が増えているようです。

一方で、Non-IT人材がシステム開発に関わる場合、「知識不足でIT部門やベンダーとの協議がまとまらない」「知識差による認識のズレが生じたまま設計が進み、結果的に不要なコスト増加やスケジュール遅延につながる」といった問題が起こりがちです。

Non-IT人材が急にプログラムを読み書きできるようになるのは難しいですが、システムアーキテクチャ(システムの構造や、それがどのように機能するかの概念)について基礎知識を学んでおくと、いざという時に大きな支えになるのではないでしょうか。

このセミナーでは、これからシステム開発に関わる可能性がある、あるいは既にシステム開発に携わっているNon-ITの方々を対象に、システムを構成する要素の基本的な概念や検討ポイントを、クラウド活用等のトレンドも混じえてわかりやすく解説します。

NCDC

August 26, 2022
Tweet

More Decks by NCDC

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

  3. NCDCのご紹介

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. はじめに

    View full-size slide

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

    View full-size slide

  9. アーキテクチャの歴史

    View full-size slide

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

    クライア
    ント配布
    の簡素化
    スマート
    デバイス
    の登場

    View full-size slide

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

    View full-size slide

  12. 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ページあたりの情報量が決まって
    おり、リンクを辿ることで次ページへ
    遷移するアプリケーションの例
    • 全てが悪いわけではない(今でも多く
    用いられている)が、たとえば地図ア
    プリがいちいちページ遷移すると操作
    性は良くない

    View full-size slide

  13. 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
    • スマートフォンの登場
    による実装技術の高
    度化(ネイティブアプリ
    の出現)で、大きな役割
    を持つようになった
    • 異なる言語で開発する
    ことが主流になった

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. 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の提供範囲

    View full-size slide

  17. 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









    使






    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. DXにおけるビジネスモデルパターンと、重要な検討ポイント
    l DXにおけるビジネスモデルのよくある例と、それぞれで特に検討
    したいポイントを解説していきます
    29
    社外向け
    社内向け
    to B
    to C
    ビジネスモデルごとの
    検討ポイント
    共通の
    検討ポイント
    1. 利用シーンに応じたデ
    バイスと実装方式の特

    1. 可用性
    1. 多様なデバイスへの対

    2. 簡潔な認証の実装
    1. 既存製品の積極活用と、
    製品仕様に合わせた業
    務フローの修正
    2. スクラッチ開発のスリ
    ム化
    ① 特定業界・業種向
    けプラットフォー
    ム構築
    ② 新規サービスの立
    案・リリース
    ③ 既存業務のプロセ
    ス改革
    ビジネスモデルの分類

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  33. l 既存業務のプロセス改革の場合
    1. 使えるものは使う
    l 既存製品を活用すれば、およそのことは実現できる
    l コミュニケーションツールをゼロから作らなくても、SlackやTeamsを導入すれば
    良い
    l ファイル管理システムをゼロから作らなくても、BOXやGoogle Driveを使えば良

    l 業績管理システムや会計システム・人事システム等、たくさんのSaaSが出回って
    いる
    l 既存の業務に捉われず、「製品に合わせて手順を変える」という考え方
    も大切
    33
    アーキテクチャの検討ポイント

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. 本日のまとめ

    View full-size slide

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

    View full-size slide