では、PaaSはどういった軸で選べばよいのか。ウフルの古城篤氏（データサイエンス研究所 所長 主席研究員）は「まずは用途で考える」ことを勧める（図5）。帳票的な業務アプリケーションを作るならノンプログラミングPaaSを、消費者向けや業務向けでもUIやロジックを凝りたい場合はランタイムPaaSを使うとよい。汎用的に使えるのがランタイムPaaS、適用領域は限られるものの工数削減効果が大きいのがノンプログラミングPaaSといえる。
次に、PaaSの特徴と構築したいアプリケーションの要件が合致するかを考える。JSOLの角尾剛氏（流通・サービスビジネス事業部 開発第二グループ グループマネジャー）は「単純な○×表で考えるのは推奨できない。PaaS事業者が切磋琢磨して、×だった項目が翌月に○になるくらい変化が激しい。各PaaSの明確な特徴といえる『◎』が付く項目を見極めて、サービスを選ぶとよい」と助言する。
各サービスの特徴は後述するが、ユーザー数の多いゲームのバックエンドに使えるほど自動スケールに強い「Google App Engine」、オンプレミスのWebLogic Serverと全く同じ環境を作れる「Oracle Java Cloud Service」といったように、各PaaSとも明確な個性を打ち出している。
最後に開発チームが持つリソースとの相性を考える。プログラミング言語の習熟度、あるいは既存と同じ開発ツールが使えるかどうかといったものだ。「ただし、開発リソースに引きずられて、特徴面がアプリケーションと合致しないサービスを選ばないように注意したい」（JSOLの角尾氏）。
PaaSが向かないシステムもある。典型的には「特定のミドルウエアに依存するシステムや、ネットワークの要件が厳しいシステムはPaaSに向かない」（シグマコンサルティング 代表取締役の橋本圭一氏）。特定のミドルウエアとしては、大規模なWebサイト向けのCMS（Content Management System）などが該当する。ネットワーク要件としては、DBサーバーは閉域網の特定セグメントに存在しないといけない、といったポリシーと相性が悪い。ほとんどのPaaSは、細かいネットワーク設定ができないからだ。
カスタマイズ性で選択
用途からノンプログラミングPaaSに絞り込めた場合、Force.comとkintoneを比較することになる。両者の最大の違いはカスタマイズ性だ（図6）。
Force.comの方がカスタマイズ性が高い半面、アプリケーション開発にシステムに関する専門知識が求められる。kintoneはその逆で、カスタマイズ性は低いが開発に必要な知識が少なく済む。
例えばForce.comでは、新しいオブジェクト（RDBのテーブルに当たる）を作成するには、データ型やER図といったデータベースの知識が必要だ。ロジックの開発でも、データベース操作やAPIに関する知識が必要になる。ロジックやUIを柔軟にカスタマイズできるが、大幅にカスタマイズするにはプログラミングする必要がある。
富士ソフトの小林 諒氏（金融事業本部 salesforce部 企画グループ 課長）は「アプリケーションの構築段階は我々が支援し、メンテナンスは利用部門だけで実施するケースが多い」という。ロジックやUI部品の開発は、利用部門には荷が重い。そこで、そうした作業はシステム部門やSIベンダーが実施することが前提になる。
一方、kintoneはアプリケーション開発に必要な専門知識が少ない。入力フォームの部品を並べてデータの入力画面を作ると、それ自体がテーブルの設計になる。これを使って、Excelや紙で実現していた業務をWeb化していくイメージだ。サイボウズの伊佐氏は「システム部門があまり関与せず、利用部門でカスタマイズしながら使っているユーザー企業が多い」と話す。
kintoneは開発が簡単な半面、カスタマイズ性はForce.comに及ばない。UIはJavaScriptでカスタマイズできるが、ロジックをカスタマイズする機能はない。複雑なロジックが必要な場合は、kintoneが用意するAPIを使って外部サーバーに実装する。
料金にも差がある。1ユーザー当たりの月額料金（税別）は、Force.comでは下位ライセンスの「Enterprise App」が3000円、上位ライセンスの「App Bundle」が1万円だ。一方、kintoneは下位の「ライトコース」が780円、上位の「スタンダードコース」が1500円である。Force.comは大企業向け、一方kintoneは中小企業や部門導入向けといえる。