2022年8月26日にオンラインセミナー『Non-IT人材でもわかる！システムアーキテクチャ「キホンのキ」』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。
なお、この記事は、主に次のような立場のNon-ITの方向けの内容です。
- 事業部門所属でDX推進などのためシステムの企画・開発に関与する可能性がある
- アーキテクチャやモダンなシステムとは何か？ それらに関する基本的なキーワードについて知りたい
目次
アーキテクチャの歴史
ITの「アーキテクチャ」とは、「システムの骨組み」や「システムの構成要素」といった意味を表します。
アーキテクチャは、技術の進歩とともに発展を続けています。
発展の歴史を簡単に振り返ると、ホストコンピューターの時代から始まり、クライアントサーバーシステムと呼ばれるものが流行した後、ブラウザを使用するWEBアプリへとトレンドが移り、今はSPA（Single-Page Application）と呼ばれる方式が流行しています。
このようなアーキテクチャの変化に伴って、サーバーとクライアント（PCやスマホなどの端末）それぞれがどんな処理を担うのか、各機器の役割も変化が繰り返されています。
こうした歴史のすべてを理解する必要はありませんが、アーキテクチャは変化し続けていて、今の正解が数年後も正解であるとは限らないということは覚えておいてください。
続いて、2022年現在のモダンなアーキテクチャを知るための概念・キーワードをいくつか取り上げて説明していきます。
SPA（Single-Page Application）とは？
SPA（Single-Page Application）とは、その名の通りページ遷移を行わず単一ページで機能するWEBアプリケーションを指します。
従来WEBアプリケーションは「クライアント（PCやスマホなどの端末）のリクエストを受けて、サーバーでページを生成して返す」という動きが主流でした。
これはクライアント側から見ると、何かの処理のリクエストを出すと、サーバーからそのレスポンスとして次のページが送られてきて、そのページを読み込むことで処理結果が表示されるという動きです。ユーザーが何かするたびに新しいページのデータを読み込む必要があるので、時間がかかりがちです。
一方で、SPAは「サーバーはデータやビジネスロジックを担当し、クライアント側のブラウザがその処理を基にページを生成する」という動きになっています。もう少し簡単に説明すると、クライアントはいちいちページ遷移をせずサーバーからのレスポンスを表示できるという特徴を持ちます。
クライアント側から見ると、何かの処理のリクエストを出すと、サーバーから必要なデータだけのレスポンスがくるので、新しいページに移動しなくても処理結果が表示されるという動きです。毎回ページ丸ごとを読み込む必要がないため表示が早く、従来のやり方では難しかったいろいろな機能を実現できます。
SPAの具体的な例としては、Google MapsやFacebookが挙げられます。例えばGoogle Mapsで地図上をあちこちへ移動しても、その都度ページ遷移はせずに必要な部分の情報だけ更新されて表示される作りになっています。
ページ遷移が発生する従来型のアプリケーションより、新しい技術であるSPAの方が優れた面はもちろんありますが、無条件にSPAを採用するのが正解というものではありません。たとえばSPAの方が実装コストは高くなるなどのデメリットもあるので、SPAにすべきかどうかは目的に応じて選択することが大切です。
フロントエンド・バックエンドとは？
フロントエンド・バックエンドという言葉自体は新しいものではありませんが、考え方は時代によって変化しています。
フロントエンドは、クライアント（PCやスマホといった端末）側の画面表示および画面に近い部分のことを指します。
フロントエンドの開発言語・フレームワークの例
- Web系：HTML, CSS, JavaScript, React
- モバイル系：React Native, Swift, Kotlin
バックエンドは、サーバー側およびサーバーに近い部分を指します。
バックエンドの開発言語・フレームワークの例
- Node.js, Python, Go
Non-ITの方が開発言語やフレームワークを覚える必要はありませんが、最近は上記の通りフロントエンドとバックエンドで「使用する言語が異なる」やり方が主流で、それぞれを担当するエンジニアは得意領域が異なることは知っておくと役に立つかもしれません。
たとえば関与しているプロジェクトでエンジニア不足が問題になった際、不足しているのはフロントエンド・バックエンドのどちらかがわかると状況を理解しやすくなります。
歴史を振り返ると、以前はフロントエンドとバックエンドは一体で考えられていて、開発言語も共通でしたが、スマートフォンの登場による技術の高度化（ネイティブアプリの出現など）により、フロントエンドとバックエンドを分けるようになったという背景があります。
マイクロサービスとは？
マイクロサービスとはシステム全体の構成を指す言葉で、機能の塊ごとにシステムを分割する構成のことを指します。分割された各サービスは独立性を保ちつつ、APIを介して緩やかに結びつける、という設計思想です(サービス間の緩やかな結びつきのことを「疎結合」と言います)。複数の規模の小さなサービスを組み合わせてひとつの大きなシステムを構成するので「マイクロサービス」と呼びます。その対義として、「すべての機能がまとまったひとつの大きな塊」としてソフトウェアを設計する考え方(モノリシック)が挙げられます。
疎結合な構成のため、一部のサービスだけを止めてシステム改修するなどの柔軟な対応がし易いことがマイクロサービスのひとつのメリットです。従って、規模が大きな複数の機能を組み合わせているようなシステムや継続的な改修が行われるシステムにはマイクロサービスが適しているといえます。
反対に、小規模なシステムやほとんど改修の必要がないシステムはモノリシックな構成が適しています。
マイクロサービスについてはこちらの記事で詳しく解説しているので併せてご覧ください。
マイクロサービスとは？ そのメリットを簡単に解説（初心者・非エンジニア向け）
クラウドとは？
ひとくちにクラウドといってもさまざまな意味を持ちますが、一般的にクラウドサービスと言われるものはサービスの提供形態により、大きく以下の３つに分類されます。
SaaS（Software as a Service）
クラウド事業者や各ベンダーが開発したソフトウェアを使用する形式
（例. Microsoft Office365、Google workspace、Salesforce）
PaaS（Platform as a Service）
クラウド業者がインフラ・OS・ミドルウェアまでを提供し、ユーザーがシステムを開発し、提供する形式
（例. AWS/GCP/Azureのマネージドサービス、Kintone、ノーコード・ローコードツール）
IaaS（Infrastructure as a Service）
クラウド事業者がインフラのみを提供し、ユーザーがOS・ミドルウェアのインストール、アプリケーションの開発を行う形式
（例. データセンター、Amazon EC2（AWS）・Compute Engine（GCP）・Virtual Machines（Azure））
ユーザーがシステムを利用できるまでの時間を短くするという観点では、インフラのみ提供しているIaaSよりもOS・ミドルウェアも提供されるPaaSの方が優れています。もっとも簡単なのはソフトウェアを提供されるSaaSで、申し込んですぐに使い始めることもできます。
こうしたクラウドサービスの登場によってシステム開発のあり方は大きく変化しました。
従来、アプリケーションをリリースするためにはサーバーの購入（もしくはレンタルサーバーの契約）からはじまり、配線を含めたネットワークの設定・OSやミドルウェアのインストール及び設定など、多くの手順を踏む必要がありました。
しかし、IaaSの登場で、自分で購入・管理しなくてもサーバーを使えるようになり、PaaSを利用すればインフラやミドルウェアの準備を自分たちで行わずに済むように進化したため、必要なアプリケーションだけを開発すればすぐに使い始めることが可能になりました。
さらには、目的に合った既製品（SaaS）があればアプリケーションの開発すら不要になるなど、今日では従来に比べて圧倒的なスピードでシステムを利用開始できるようになったのです。
AWSのクラウド製品一覧を見ると、ストレージやデータベースといった以前からある基本的なサービスに加えて、分析、IoT、機械学習、さらには人工衛星に関するものまで、200以上のサービスが提供されています。GCPについてもAzureについても、AWSと同様に多岐にわたるサービスが提供されています。
クラウドを使用すれば、ゼロから自前でプログラムを開発する必要性を大きく低減し、システムの開発やリリースを格段に向上できるようになってきています。
サーバーレス・コンテナとは？
サーバーレスやコンテナはかなり技術面に寄った話ですが、クラウド利用の拡大に伴い近年よく目にする技術要素なので簡単に紹介します。
まず「サーバーレス」について。
従来、アプリケーションはサーバーに「常駐」しているものでした。一方でサーバーレスは、必要な時だけアプリケーションをサーバーの上に乗せて動かし、使い終わったらサーバー上からアプリケーションを消すというような処理を行います。
サーバーに常駐させている場合、通常は「アプリケーションを利用していなくても」クラウドの費用が発生しますが、サーバーレスの構成だと「アプリケーションを利用した分だけ」しか費用がかからないため、コストがスリムになるというメリットがあります。
一方で、アプリケーション「常駐」の構成と比較すると、利用するたびに「サーバー上に持ってくる」必要があるサーバーレスは初回起動が遅くなるというデメリットもあります。
2つ目は「コンテナ」です。
コンテナとは、OSやハードウェアに依存せずにアプリケーションを実行するための仕組みです。アプリケーションを動かすには対象環境となるOSやハードウェアに適合したミドルウェアやライブラリというものが必要であるため、従来は違う環境にアプリケーションをただ移設しても動作しないのが当然でした。
しかし、コンテナという技術を用いると、アプリケーションを動作させるためのミドルウェアなどをパッケージ化して、輸送船のコンテナのように違う船（環境）に簡単に乗せ替えできるようになります。
サーバーレスやコンテナについては技術的に深く理解する必要はありませんが、意味がわかる程度の知識は持っているとベンダーとの会話の際に役に立つかもしれません。
サーバーレスやコンテナについてはこちらの記事で詳しく解説しているので併せてご覧ください。
コンテナとサーバーレスの特長、使い分け（初心者・非エンジニア向け）
モバイル向けアプリ開発
近年はシステム開発を検討する際にモバイル向けアプリが非常に重要な検討のポイントになっています。ひとくちにモバイル向けアプリ開発といっても実は多くの方法があり、それぞれ特徴が異なるのです。
多数の方法の中から最適なものを選択するためには多くの知識が必要になります。すべて把握する必要はありませんが、どのようなパターンがあり何が違うのか大まかに知っておくと役に立つかもしれません。
モバイル向けアプリ開発については詳しく解説した別の連載記事があるので、興味のある方は下記の各記事をご覧ください。
- モバイルアプリとWebアプリの比較
- ネイティブアプリとクロスプラットフォームアプリの違い
- クロスプラットフォームアプリ開発技術の比較（やや技術者向け）
- Webアプリの擬似モバイルアプリ化（PWA）について
３つの具体例とそれぞれの検討ポイント
最後に応用編として、ビジネスモデルに応じたアーキテクチャ検討の具体例を紹介します。
DX推進などのためNon-ITの方がシステムの企画・開発に関わる例
- 特定業界向けのプラットフォーム構築
- 新規サービスの立案とそれに必要なアプリの企画
- 既存業務プロセスの改革
例1.特定業界向けのプラットフォーム構築
BtoBのビジネスの場合はその業界特有の商習慣や管理項目などがあるため、その制約を満たす特定業界向けのプラットフォームサービスがDXプロジェクトとして企画されることはよくあります。例えば「〇〇業界向けの在庫管理システム」「〇〇業界の現場スタッフ向けシステム」など。
在庫管理や受発注管理のようなオフィスでよく使われるシステムの場合、ほとんどのユーザーはオフィスにいてPCで操作することが予想されるため、Webアプリが適していると考えられます。
一方で、物流や建設の現場で使うシステムの場合、スマートフォンやタブレットでの操作が必要になると予想されるので、現場で用いる端末のOSなども考慮して、モバイルアプリを検討すると良いと思います。
使用する場所や端末の種類の他に、機能面でも優先的に考慮すべきものあります。例えばGPS情報のような端末側の持つデータの取得を求められたり、プッシュ通知の実装が必要とされたりするシステムであれば、基本的にモバイルアプリでの開発が必須です。逆に、このような端末依存機能の実装優先度が低かったり、そもそもこのような機能を実装する必要がなかったりする場合は、Webアプリを選択する方が適切と考えられます。
このように、ビジネスモデルを考えることと、その要件を満たすためのシステムの構成要素を決めることは密接に関係しています。
例2.新規サービスの立案とそれに必要なアプリの企画
コンシューマー向けの新規サービス用にアプリ開発をする場合、不特定多数のユーザーが使用することが想定されるため、多くの端末の種類（PC/スマホ/タブレット）を考慮し、さらにさまざまなメーカーが出している各機種にも対応することが求められます。
このような場合は、クロスプラットフォームと呼ばれる、ひとつのソースコードからiOS、Androidの両OS用のアプリを作成できる技術から検討すべきだといえます。
機能面での重要な検討ポイントを一つ挙げると、コンシューマー向けのアプリではよく「認証」が課題になります。せっかくアプリを作ってもログインが複雑だとユーザーは離れてしまうため、できるだけ簡単かつ安心な認証方法を選ぶことが求められます。
例1で挙げた特定業界向けのプラットフォーム構築とはビジネスモデルがまったく異なるので、システムの企画時に重きを置くポイントも違えば、システムの構成要素も違うことがわかります。
例3.既存業務プロセスの改革
前述の2つは新しいシステムを一からつくる前提の例でしたが、最後に社内の既存業務プロセスの改革（業務システムの改善など）の例を紹介します。
業務システムの改善を含む業務プロセス改革に取り組むような場合は、すぐに導入できるSaaSなどを用いてなるべく早く検証を始めるのがおすすめです。
例えば、ファイル管理システムが必要な場合、一からそのシステムを作る必要はなく、BOXやGoogle Driveを利用することで目的を果たせるか確認するということです。求めている機能を100%満たすものではなくても、まず使ってみて仮説検証するのが一番スピーディーな改善方法です。
独自の管理ルールや業務フローがあるため一般的なSaaSの利用は難しいと考えられるケースもあるかと思いますが、その場合も、既存の業務プロセスを維持することに捉われずに「製品に合わせて手順を変える」というアプローチを検討してみることも効果的です。実際に、このような発想に基づいて既存業務の改善を行う事例も増えてきています。
どうしてもほしい機能を満たす製品が市販されていなかったり、SaaSを利用するとしてもあるデータだけは既存の基幹システムを参照する必要があったり…と、一部の重要な機能が不足してしまう場合は、SaaS適用が可能な範囲はSaaSを適用し、不足する機能だけを独自で開発する方法も考えることができます。
可用性を考えることも重要
3つの例を挙げて具体的な検討ポイントをいくつか紹介しましたが、これらはほんの一例で、その他にも多くの検討すべき要素があります。
例えば、Non-ITの方がシステムの企画・開発に関わる際、「可用性」をどう考えるかはよく意見を求められる領域かもしれません。可用性とはシステムが継続して稼働できる能力のことを指し、「障害やメンテナンスなどによるシステム停止がどの程度許容されるか」によって定義されます。
コンシューマー向けのサービスを検討しているなら最初から高い可用性が求められますが、自社内だけで使う実験的なサービスであれば可用性は重視する必要がないかもしれません。システム停止のリスクをどう考えるかによって、高可用性システムを目指すのか、可用性を犠牲にしてもコストを抑える方がいいのかなどの判断が変わるはずです。
どの程度の可用性が必要となるかはプロジェクトの目的や性質、どのようなフェーズにあるかによって異なるので、それらを考慮して適切な可用性レベルを設定するのが大切なポイントとなります。
システム開発のご相談はNCDCへ
ある程度技術的な専門用語なども含めて解説しましたが、Non-ITの方が独力でアーキテクチャを考える機会や必要性は必ずしも多くはなく、あくまでも自社のシステム部門やベンダーに要件・要望を伝える立場での関与が主体になることと思います。
ただ、その際にNon-ITの方がシステム開発の基礎知識を持っているどうかで、IT関係者とのコミュニケーションの取りやすさや認識のすり合わせやすさが大きく変わります。
この記事が、システムの企画・開発に関与するNon-ITの皆様の一助となれば幸いです。
NCDCでは、新規システム構築の要件定義から開発まで一元的なご支援が可能です。
IT部門が関与せずビジネス部門のみで企画している新規デジタルサービスの支援実績も数多くありますので、どうすればビジネス部門のアイデアをうまくシステム化できるかお悩みの方はぜひお問い合わせください。
