クラウドネイティブ

「クラウドネイティブ」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、クラウドサービスの利用が前提になってきている現在において、これからのビジネスにおけるIT活用を検討する際に必要な観点である「クラウドネイティブ」について考えてみましょう。

クラウドネイティブとは

クラウドネイティブとは、旧来からのIT利用スタイルに代わり、クラウドサービスが広く提供され利用されるようになった状況を踏まえて、そのような新しい状況を前提にした考え方で作られているITシステムやIT利活用のスタイルのことです。
狭義には、コンテナ技術を用いて開発されたマイクロサービスアーキテクチャのITシステムをクラウドネイティブと呼ぶこともありますが、この記事においては広義の意味において説明を行います。

参考:狭義の「クラウドネイティブ」に関連した記事
コンテナオーケストレーション|用語集

クラウド時代になって起こった技術的変化

クラウドサービスの登場と普及により、ITやビジネスの様々な領域において従来とは違う新たな状況が生じ続けています。そのような破壊的変化を踏まえ、変化後の新しい状況に対応できているかどうかを問うのが「クラウドネイティブ」という言葉の本質ではないかと思います。

つまりクラウドネイティブとは「きちんと時代の変化に対応できていますか」「新時代の新状況が前提(ネイティブ)として考慮されていますか」を問う言葉でもあると思います。

では、そこで問われている「クラウド時代になって起こった破壊的な変化」とはどのようなものでしょうか。変化が起こった結果、どのようなことが我々に求められるようになってきたのでしょうか。解りやすい例として、クラウド黎明期に起こった技術的課題の出現を話題にします。

マルチテナント化

クラウドが登場する以前、コンピュータを利用することとは、自前でハードウェアを用意して利用することでした。業務システムなら、自社でハードを買い、そこで動かすソフトウェアを買ってくるか開発してもらうことでした。ゲームで遊びたいなら、ゲーム機を買って自分の部屋に設置し、買ってきたゲームソフトを入れて遊ぶのが以前の常識でした。

その当時のソフトウェアやITシステムは、基本的にそのような状況で利用されることが暗黙の前提となっていました。

  • ITを利用する:A社保有のハードウェアで、A社保有のソフトウェアを稼動して利用する

ソフトウェアを開発販売する側の目線で考えてみましょう。「会計業務向けのIT」のビジネスをするなら、会計ソフトウェアを開発してパッケージソフトウェアとして売るとか、特定の顧客向けに個別にITシステムを受託開発してハードウェアごと導入するのが、当時のITビジネスの前提でした。

自社で会計ソフトウェアのパッケージビジネスを行っていて業績好調、そこにクラウドが出現し、競合他社がクラウドに参入したので自分たちも参入したいと思ったとします。しかしそこで、自社のソフトウェア資産やソフトウェア開発実績が「クラウド時代に対応できていない」ことが明らかになります。

クラウドサービスですから、インターネット経由でサービスとして提供する必要があります(Webブラウザから利用できるようにするなど)。それ以前と同じUIでは対応できないことが多いはずです。しかも、その点は解決できたとしてもまだまだ問題があります。

クラウドサービスは、ソフトウェアをサービスとして提供して多くの企業に利用してもらうビジネスになります。例えばお客さんが10社できたとして、それらのお客さんに会計ソフトウェアをサービスとして提供しようとすると、こういうことになるはずです。

  • 10社それぞれに専用のハードウェア(実行環境)を用意する
  • それらハードウェア上で個別に会計ソフトウェアを動かしてクラウドサービスとして提供する

強引であろうともクラウドサービスとして提供ができているのも事実ですが、これではコストがかさむのみならず、お客さんが増えると運用の手間が比例して増えるのでビジネスがスケールしません。クラウド時代にきちんと適応出来ているとは言えません(クラウドネイティブではない)。

何がいけないのでしょう。パッケージソフトウェアでは、ハードもソフトも占有して動かすことが当然の前提でしたが、クラウド時代になってその「従来の当然」が「時代遅れ」要素になっているわけです。そこで、クラウドサービスは「マルチテナント」であるかどうかが(その当時)問われるようになります。

  • 一つのハードウェア(群)上で一つのITシステムが動いている(無駄に同じシステムを複数起動するようなことは必要ない)
  • そのシステムを多くの利用者がサービスとして利用している(マルチテナント)

今となってはごく普通なことです。ネットワークゲームの例なら、ゲーム機で動いていたゲームソフトをクラウド側で利用者ごとに個別に動作させている付け焼き刃の対応ではなく、クラウド側で巨大なソフトウェアが動作していてそれをみんなで利用する状況です。

今では「何を当たり前な」と思う話ですが、ゼロ年代には実際にSalesforce社が「マルチテナントであること」を他社クラウドサービスとの違いとしてPRしていたほどでした。

では、パッケージ時代にはお客さんに愛された会計ソフトウェア、どうすればクラウド時代でも生き残れるでしょうか。

  • 起動したらすぐ利用できるだけでログイン機能がないなど、そもそも足りない機能をつける初歩的な対応がまず必要
  • デスクトップアプリをWebブラウザ経由で利用できるUIにする
  • 各社それぞれが別途利用できるようにログイン後に各社環境に振り分ける機能
  • 同一システムを各社が利用しても、各社のデータは互いにセキュアに分離され互いに見えないようにする
  • 閉じたオンプレミスではなく、インターネット上でサービス公開しても問題が起こらないような、強固なセキュリティ上の配慮(脆弱性が残っていることは許されない)

ここまで作れば、とりあえず何とかなりそうに思えます。しかし提供してみると機能はまだ足りておらず、

  • 10社それぞれの利用状況を個別に把握して、自動的に利用料金を計算して請求する仕組みがないと事務処理が破たんする
  • お客さんの監査対応のために、利用ログなどを個別に出力する機能なども必要になった

時代が新しくなると、このように「何をすべきか」すらわからなくなります。やってみて失敗したり苦労したりを経て学習する必要すらあります。あるいはクラウドネイティブとは事前に正解が定められているようなものではなく、そのような試行錯誤の後ろ側にできるものだとも言えます。

このような苦難を乗り越えて、自社の会計ソフトウェアは(クラウド黎明期的には)とりあえずクラウドネイティブになりました。しかし、こんなに大変なら(コストもかかってしまいますしお客さんにも迷惑がかかることもあります)、パッケージソフトウェアのままの商売を続けている方が良かったかもしれません。

AWSの登場

「理解しやすい例」として黎明期での取り組みの例を紹介しましたが、本当に大きな変化があったのは、さらに後です。例えば、AWSが登場して広まることで、「AWS流のシステム開発」が広まったのも大きな変化でした。

当初は「クラウド(AWS)を利用してシステム開発をする」とは、AWSがネット経由で提供する仮想マシン(Amazon EC2)を物理ハードウェアの代わりに借りてITシステムを動かす程度のことで、「それ以外は以前と同じ」ことが多かったのですが、これが「時代遅れ」になってしまうような変革が起こります。

AWSが提供している各種サービスを駆使し、従来のシステム開発とは「基本から異なる発想」でITシステムが作られるようになります。GoogleやMicrosoftなど他社クラウドも機能面で追従したため、いわば「AWSネイティブ」な開発手法が新時代の常識的な取り組みとなり、今やAWSネイティブ的に作られていないITシステムは前時代的とすら言われるようになっています。

  • クラウドネイティブではない:
    クラウド上の仮想マシン(Amazon EC2)は使っているのでクラウドないしはAWSは利用しているが、それ以外は基本的に以前と同じで、可用性や信頼性の確保も従来と同じ方法で実現されている。
  • クラウドネイティブ(AWS的な意味で):
    永続化するデータは仮想マシン上ではなくAmazon S3やAmazon RDSなどのマネージドサービスに配置し、ロードバランサであるELBから自動起動され負荷状況に応じて増減されるEC2上で処理を行う。従来とはシステムアーキテクチャが大きく異なる。

詳しくは説明しませんが、AWS自身が提供している資格「AWS認定クラウドプラクティショナー」では、AWSを用いてシステム開発を行う「新しい考え方」を学ぶことができ、それを理解していることを資格として証明できます。興味があれば、そちらを勉強すると良いでしょう。

コンテナ技術の登場と大流行

変化はそれで終わりではなく、さらに続きます。その後、コンテナ技術が登場して普及し、コンテナ技術をフル活用した、いわば「コンテナネイティブ」な新しいスタイルでのシステム開発が、新しい時代のシステム開発手法として流行し始めます。

AWS自身もこの新しい潮流をすぐに取り込んで進化していますが、コンテナ登場以前のスタイルでのAmazon EC2ベースのシステム開発は、今ではやや時代遅れの感じもするようになりました。

コンテナ|用語集
コンテナオーケストレーション|用語集

つまり、クラウド時代になって大きな変化が一回あったのではなく、変化は繰り返し起こっていますし、きっとこれからもエンジニア世界を震撼させるような新技術の登場はあるでしょう。

「クラウドネイティブとはマイクロサービスのことだ」として話題になっていることがありますが、執筆時点で技術的な話題の最先端にあるのが「コンテナ技術を用いたマイクロサービスアーキテクチャでのITシステム開発」であることが多いだけです。しばらくするとマイクロサービスも「時代遅れの考え方」になっているかもしれません(ただし、現時点においては十分に注目すべき技術であり、長期的に絶対ではないからスルーすべきである、ということでもありません)。

開発技術だけではなく、ビジネスも変わった

ここまで読んできて、クラウドネイティブとは開発部のエンジニアの話題であって、それ以外の部署には関係ないような「技術だけの話」に思えた人もいるかもしれません。

世の中には、ビジネスの話をしているから関係ないんだとか言って、技術を遠ざけたり軽視したりする風潮もありますが、「クラウド登場による破壊的変化」の影響はビジネス側にも及んでいます。「クラウドネイティブ」であるかどうかは、ビジネス側においても問われています。以下、いくつか解りやすい話を紹介します。

ビジネスの前提条件が根本的に変化(初期費用や展開速度)

AWSなどが登場する以前、例えば自社でネットワークゲームを提供しようとすると、高価なプロ用のハードウェアの調達や設置場所のデータセンタの確保から自社で手配が必要でした。サービスインするだけで億単位の予算、年単位の期間が必要になることは普通でした。そうなると軽々に意思決定できませんから、重厚な事業計画を作り、それを承認してもらって資金を確保するための手順も重厚になりがちでした。ITとは言ってもむしろ旧来的ビジネスの色が濃い取り組みが必要になりました。

しかしAWSを利用してシステム開発ができるようになると状況が激変します。小さく始めるなら数百万円の予算で十分、数か月の期間でも同じようなサービスがサービスインできる状況に変わってきます。そうなると、従来的な重厚な意思決定スタイルは無駄に時間がかかり、肝心のシステム開発以外に時間とコストを取られることが問題になってきます。

例えば、自社が昔通りの手続きで会議室の話を通すだけで一年を浪費している間に、競合はサービスを実際に開発して何度も市場に投入してどんどん先に進んでしまうのです。それでは負けてしまいますし、エンジニアも出て行ってしまいます。こうなると重厚な意思決定による機会損失の方がビジネス上も問題になってしまいます。クラウド時代の新常識はこういう形でも出現します。

サーバレスで「固定費がゼロ」の世界

さらには今や「固定費がゼロ」の事業構造まで実現可能になっています。クラウドの最新技術で「サーバレス」という言葉を聞いたことはないでしょうか。エンジニアにとっても便利で手間のかからない最新技術として注目されていますが、ビジネス側にとっても革命的な性質があります。

サーバレス」は使ったときに使った分だけしか費用がかからず、利用しないときには費用が発生しません。つまり、基本的に固定費が発生しないのです。さらには(きちんと配慮して設計してあれば)、突然サービスが大ヒットして万単位の人が押し寄せても、サービスを自動スケールさせることすらできます。

従来、ビジネスは小さく始めてヒットするとチャンスロスしやすく、大きなビジネスを想定して準備してヒットしないと大赤字になるのが常識でした。最新技術の力で「そのリスクが両方とも無い世界」ができあがっているのです。システム開発をする人件費は当然かかりますが、その後、利用者が閑古鳥なら変動費もほとんどなく固定費もほとんど無いのです。

つまり、大スベリしたサービスが100あって塩漬けになっていても、利用されなければサービスの維持費はほとんど無く財務上大きな問題にならないということです。さらには、サービスがテレビで取り上げられて突然利用者が押し寄せてきたような場合、従来ならサービスが落ちてしまって盛大に悔しい想いをしましたが、自動的にスケールアウトするためチャンスロスせずに済みます。

エンジニアにとっても福音となる技術であるのですが、このような性質は「ビジネス側にとってこそ」革命的な変化だと考えられます。今やITはビジネスにとって必須の要素ですが、もしそうならビジネスの根本を革命的に変える技術の存在は、当然考慮すべきではないでしょうか。

このように「クラウドネイティブに変わらないといけないこと」はビジネス側にもあります。

それ以外にも多くある変化

このようなことを踏まえると、精神論的に言われがちな「スモールスタート」なども言葉の意味が違って見えてくると思います。もはやスモールスタートは「気持ちの問題」ではなく、「クラウド時代になって破壊的に変化した技術的前提」を理解し、それを踏まえてビジネス側の常識を変えることが出来ているかを問う言葉になります。

顧客との関係も大きく変わります。クラウドが普及し、スマートフォンが広く活用されるようになった現在、ITを活用すれば顧客と24時間リアルタイムで接点を持ったままにできるようになりました。人の営業やサポートチームが顧客に24時間張り付くことは出来ませんが、今のITならそれができるわけです。本来これも破壊的変化であるはずです。

このように技術そのもの以外の多くの領域でも、クラウド以前とクラウド以降の間で破壊的変化があります。このように「クラウドネイティブであるかどうか」はあらゆることで問われることのはずです。

時代の流れである「内製化」

一方で、コンテナ技術を駆使したマイクロサービスアーキテクチャでのシステム開発、のような話題は、ほとんどの社には縁遠い話に思えるはずです。腕の立つエンジニアを潤沢に採用でき、全世界に向けた大規模なクラウドサービスを提供しているような状況では必然になるような技術は、全ての組織の現実的前提ではないからです。

そうなるとむしろクラウドネイティブとは、後半に書いたようなビジネス的な破壊的変化を踏まえた、ITとの新しいかかわり方の議論がより重要になるはずです。その考え方において、今大きな話題になっているのが「内製化」の取り組みではないかと思います。

ビジネスとITは今や一体不可分であり、変化の速度が必要な時代であるなら、業務の現場が自らITを使いこなしてビジネスを素早く進めることは、まさに望まれることだからです。

内製化からみたクラウド時代

クラウドサービスの普及は、事業の現場が自分たちでITを使いこなす取り組みにも大きな変化をもたらしました。

ITを導入するだけで大きな予算と長い期間がかかった過去とは違い、今ではクラウド上で多種多様に提供されているSaaSがあります。利用したいSaaSにクレジットカードで支払いを行えば、5分後にはもうサービスが利用できたりします。

プログラミングは出来なくても、例えばkintoneなら自分たちで使いこなすことは出来るはずです。このように「自分たちでやろう」と思ったなら、実際にできてしまうことはとても多くなりました。

社内でのクラウド活用が進み、SaaSの機能自体で出来ること以上のことが必要になりはじめても、現場の自分たちで何とかできる手段も整備されつつあります。例えば、プログラミング的なことが必要になったと思える場合でも、今ではノーコードやローコードのツールが多数提供されるようになりつつあります。

つなぐ」技術で内製化の取り組みはさらに進む

SaaSだけではできないことにはいくつかパターンがあります。例えば、もうちょっと機能があれば(例えばデータ加工で少し機能が足りないなど)と思えるようなパターンと、他のサービスや外部データと「連携」させて組み合わせ利用したいと思えるようなパターンです。

クラウド活用が進むほどに各種業務で有用なSaaSの導入が進むので、クラウドサービスを連携するニーズは増してゆきます。例えばSalesforceに入っている顧客データとkintoneに入っている顧客データを連携したいとか、昔から現場で使っているExcelとクラウドサービスを何とか組み合わせたい、などのニーズはありがちなことです。

さらには、他部門のITシステムとの連携、取引先やパートナー企業が利用しているITシステムとの連携など、実現すれば大きな効果のある取り組みにも、外部のシステムやデータと「連携」できれば実現できることが多々あります。「連携したい」ニーズは、IT利活用ニーズの枝葉であると考えられることもありますが、むしろSaaS自身よりも価値実現の本質であることも珍しくありません。

「連携」を手作業でやっていませんか?

連携が必要な状況になると、手作業でのデータの出し入れで対応がなされていることが多いはずです。あるいは、手作業での対応が当然であって、それ以外の手段があるとは思っていない現場も多いと思います。

このような手間で苦しんで、クラウドの活用が停滞してしまうことや、利用するクラウドの種類を不本意に減らすようなこと(kintoneとSalesforceの組み合わせを諦めてkintoneだけにしようとか)もあるかもしれません。

しかし、このような状況には「良い解決手段」が既に存在しています。「連携ニーズをITの力で解決する」「SaaSに足りない機能を外部から補うことや、処理の自動化を実現する」ことを、業務の現場が自らITを活用して解決できる手段です。EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し、設定をすることで多種多様なシステムやデータ、クラウドサービスへの連携処理を実現することができます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的に取り組む」ことを可能にします。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人も居られるかもしれません。

確かに簡単に使えることを謳うツールでは、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」というようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもでき、内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。「GUIだけ」の良さと、本格的能力を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス(iPaaS)のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

関係するキーワード(さらに理解するために)

  • コンテナ
    • コンテナとは、一つのOS実行環境内で、複数の独立したアプリケーションシステムの実行環境を作り出す技術のことです。それまで利用されてきた仮想マシンによるハードウェアレベルの仮想化に対して、OSレベルでの仮想化(OS-level virtualization)を行います。
  • マイクロサービス
    • マイクロサービスは、コンテナ技術により実現し流行するようになった、新しいシステム開発のスタイルです。システムの構成要素を積極的に独立した小さい単位であるマイクロサービスとして作り、システム全体を多数のマイクロサービスで構成する考え方です。
  • コンテナオーケストレーション
    • コンテナ技術を用いたシステム開発や運用において、多数のコンテナを管理し運用し制御する自動化技術のこと。
  • EAI
    • システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
  • ETL
    • 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
  • iPaaS
    • 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

「iPaaS」や「つなぐ」技術に興味がありますか?

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用を成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider」および、データ連携プラットフォーム「HULFT Square」

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください:


「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか:

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか?

  • SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
  • データ利活用に向けて進めたいがシステム連携に課題がある
  • DXの実現に向けてデータ連携基盤の検討をしたい

用語集 コラム一覧

英数字・記号

あ行

か行

さ行

た行

な行

は行

ま行

や行

ら行

わ行

» データ活用コラム一覧

おすすめコンテンツ

Related Content

Return to column list