サービスとしてのプラットフォーム（PaaS）とは、ユーザーがアプリの開発、実行、管理を行う際に使用するプラットフォームをサードパーティプロバイダーが提供するというクラウドコンピューティングモデルです。このモデルでは、ソフトウェアアプリケーションをサポートするインフラの構築や保守を開発者やプログラマーが行う必要がありません。インターネット接続へのアクセスを確保するだけでよいのです。
PaaSは突然登場したわけではありません。サービスとしてのインフラ（IaaS）が普及したことで、自然とクラウドネイティブ開発が発展してきました。当然、クラウドネイティブ開発が広まるとクラウドネイティブアプリケーション（SaaS: サービスとしてのソフトウェア）が大きなトレンドとなりました。
IaaSが提供されるようになる前、IT部門は仮想マシンを使用してサーバーを仮想化することで、サーバーの利用効率を向上させ、1台のコンピュータに複数のOSを共存させていました。しかし、エンタープライズデータの急激な増加は止まらず、既存のデータセンターを補うためにクラウドを利用せざるを得ない状況になってきました。
インフラの管理やセキュリティを自ら行うことに慣れている組織の場合、IaaSを信頼できるようになるまでには時間がかかります。
一方、思い切った取り組みを進めるスタートアップ企業はSaaSオプションの提供を開始しました。サブスクリプションという経済モデルを好まない従来のソフトウェア企業に競争上のプレッシャーを与えるためです。高額なライセンスやソフトウェア年間保守を販売することができる企業は、比較的安価なサブスクリプション料金でライセンス、保守、アップグレードを提供する必要性を感じていませんでした。しかし、SaaSがもてはやされるようになったことで、従来のソフトウェアベンダーも時代に取り残されないよう、SaaSをオプションとして提供せざるを得なくなりました。
SaaSの経済的側面を分析した従来のソフトウェアベンダーはSaaSを導入することで、画一的だった製品をコア製品とモジュールに分割し、顧客の選択肢を増やして新たな収益源を見いだせる可能性があることに気づきました。今も従来のオンプレミスソフトウェアは健在です。しかし、エンタープライズソフトウェアベンダーでさえもSaaSやPaaS（アプリケーションプロバイダーやIBMやOracleなどのクラウドプロバイダーの場合）への移行をユーザーに促すようになっています。
2005年、Fotangoは最初のPaaSであるZimkiというJavaScript Webアプリケーション開発プラットフォームを開発しました。しかし、PaaS業界に火を付けたのはGoogleが2008年にリリースしたApp Engineでした。
IaaSとSaaSに加え、モバイル、アジャイル、DevOps、CI/CDといったトレンドが、PaaSのニーズをさらに高めました。
これまではモバイルアプリがバックエンドでクラウドを利用しているだけでしたが、最近では開発者やシチズンデベロッパーがフロントエンドでのモバイルエクスペリエンスやWebエクスペリエンス構築にPaaSを使用するようになっています。モバイルのテストに関しても、サードパーティのテストラボを利用してクラウドで行われることが多くなっています。テスト対象であるデバイス、OS、ブラウザの多さを考えると、社内でラボを構築・管理するにはコストがかかりすぎるためです。
開発とテストがクラウドで行われるようになり、本番もクラウド化が進んでいます。しかしそれでは終わりません。
DevOpsとCI/CDでは、開発者とIT運用担当者が一体となって作業する必要があります。そのためには、同じ開発環境や本番環境を使用するのが一番です。開発環境ではシミュレータやエミュレータを使用して本番環境を模倣しますが、クラウド環境ではより正確に本番環境を複製することができます。
開発、テスト、IT運用などをすべてクラウドで行うと、アプリケーションデリバリーが加速します。PaaSには、アプリケーションの作成、テスト、デプロイに必要な開発ツールとインフラがそろっています。他社のクラウドを使用することに抵抗がある企業向けに、ファイアウォールで守られたアプライアンスで実行されるプライベートクラウドオプションを提供しているベンダーもあります。
機械学習が目当てでPaaSを導入する企業もあります。機械学習を行うには大量のデータ（つまり、大量のストレージ）や並列コンピューティングリソースが必要になるため、スーパーコンピュータを購入することを思えば低コストですむからです。
aPaaSはPaaSと概念が似ており、混同されがちです。いずれも、インフラ（PaaS）やコーディング（aPaaS）に煩わされずに問題の解決に集中できるようにすることを目的としています。
違うのは、PaaSはユーザーにコーディングスキルがあることを想定しており、aPaaSは想定していないという点です。
つまり、PaaSはプロの開発者向けであるのに対し、aPaaSはコーディングができないシチズンデベロッパー、HTMLやJavaScriptに習熟したWeb開発者、開発時間を短縮したいプロの開発者もターゲットとしているのです。
クラウドオプションの階層
現時点では、aPaaSはPaaSの後継ではないと考えられます。プロの開発者の多くはローコードのことを低レベルの道具のように考えています。コーディングの方法を数年かけて学んだ人にとっては、ビジュアルツールやウィザードでアプリケーション開発の複雑さを解消するローコードツールによって開発者の仕事が完全に奪われることはないという気持ちもあるのでしょう。実のところ、ローコードは開発者の代わりにはなりません。
将来的に、プロの開発者が競争力維持のためにローコードプラットフォームを使用する必要性が高まり、PaaSとaPaaSが統合される可能性はあります。この10年間で見てきたように、開発チームはアジャイルからDevOps、そしてCI/CDへと移行し、より迅速に顧客に価値を提供できるようになってきました。
ソフトウェアデリバリーサイクルが短縮の一途をたどる今、手作業のコーディングはいつか高速化の妨げとみなされるようになるでしょう。その結果、開発者はできるだけローコードツールなどの最新の開発ツールを使用し、ローコードツールがデフォルトで対処できない部分だけ手作業でコーディングするようになるはずです。PaaSプロバイダーは生産性の向上というミッションにたゆまず取り組み続けています。PaaSとaPaaSが統合される日も近いかもしれません。
長期的に見てPaaSやaPaaSが1つのまとまったカテゴリ名になるかどうかは、あまり重要ではありません。ただ当面の話としては、対象ユーザーが異なるという点でこれら2つを区別するのは妥当だといえます。
今日、ほとんどの開発チームが必要に迫られてアジャイルを最大限に取り入れています。単にモノリシックアプリケーションを小さな要素に分割して開発し、完成品がユーザーから支持されることを願うのではなく、MVP（実用最小限の製品）を作成してできるだけ早くフィードバックを集めるというのが現在の考え方です。Amazon、Facebook、Google、Netflixなどのデジタルディスラプターの影響で、最初から完璧を目指す方式からイテレーション方式へと文化が変わってきたのです。
ツールや人材に何百万ドルも投資した製品がまったく支持されなかったらどうなってしまうでしょう。MVPを作成し、失敗から学び（「失敗は早いうちに」）、開発を進めたほうがよいと企業が考えるようになるのも当然だといえます。
PaaSとaPaaSは製品のデリバリーを加速させるため、MVPに最適です。また、分析に役立つアプリ関連データやツールが豊富にあるうえ、すべて1つにまとまっています。アプリが大好評となった場合でも、クラウドで作成されているため無限に拡張することができます。対応はPaaS/aPaaSプロバイダーが行ってくれます。
また、分析に役立つアプリ関連データやツールが豊富にあるうえ、すべて1つにまとまっています。そのため、コンテナやマイクロサービスアーキテクチャなどを使用している場合でも心配は無用です。もちろん、使用しなくても問題ありません。
PaaSとaPaaSはソフトウェア開発の効率と成果を向上させるものです。現在のところ、これら2つは対象ユーザーが異なるため、区別するのが妥当です。しかし、環境が変化するにつれ、どちらか一方に収束されていくでしょう。
PaaSとaPaaSは企業のクラウド移行戦略に最適ななステップです。デジタルトランスフォーメーションによって企業がよりソフトウェアへの依存度を高めソフトウェアを中心に考えるようになるにつれ、PaaSとaPaaSの重要性もさらに高まるものと見込まれます。
