BLOGAzureブログ

• 目次
• 1.はじめに
• 2.決定的に変化すること
• 3.実行環境の変化がもたらすメリット
• 4.考慮すべき点は？
• 5.DevOpsとは？
• 6.最後に

はじめに

近年、企業のソフトウェア利用における要望は、導入スピード向上・コスト削減・資産の軽量化などの背景から、「パッケージソフトウェアの所有」から「SaaSの利用」へと変化しています。それに伴い、当然ISV（独立系ソフトウェアベンダー）側もパッケージ型からSaaS型へのビジネスモデル転換の流れが加速しています。このような転換を行うことで、それまでとは大きく変化した収益構造や事業体制、エンジニアリング体制などの下で、一般的には主要なパブリッククラウドをアプリケーションサービス提供基盤として活用し、事業を行っていくことになります。

単純にマーケットと需要の変化からだけでなく、サービスプロバイダー側にも大きなメリットがあることがあり、ISV のSaaSビジネスへの参入の流れは加速しているわけですが、当然考慮するべき点もあります。

ということで、今回は主にSaaSビジネスへの参入を計画しているISVの方向けに、主にエンジニアリング面から見たメリットと考慮すべき点を解説します。

決定的に変化すること

ビジネスモデルの面では、買取型のライセンスと保守サポートの販売、というモデルから月額や年額などで一定期間の使用権や従量課金制で販売する、というモデルに変化します。つまり、フロー型からストック型になり、リカーリングやサブスクリプションといったビジネスモデルとなるのです。

では、エンジニアリングの面についてはどうでしょう？そう「アプリケーションの実行環境が変化」します。パッケージソフトを提供していた時には、各顧客が管理する環境に、インストールであったりデプロイして、そのアプリケーションを使用していましたが、サービスプロバイダー側が管理する環境にアプリケーションをデプロイしてサービスとして提供することになります。

実行環境の変化がもたらすメリット

顧客側のプラットフォームを指定することは基本的にできないため（もちろんサポート対象や動作保証環境の制約によりある程度は限定されるものの）、各種ハイパーバイザー上であったりIaaSの仮想マシン、ミドルウェアなどのバージョンなど、さまざまな環境でアプリケーションを動作させることになります。動作保証や保守サポートの観点から、それぞれを考慮しなければならないためテスト工数はかさみますし、動作テストの考慮漏れに起因する不具合が引き起こすインシデントの発生確率はどうしても高くなってしまします。
また、インシデントの発生時にも本番運用環境が顧客側にあるため、解決のために必要な十分な情報を得ることが難しかったり、想定していなかったアプリケーション（プログラム）との競合などの問題もでてきます。

しかし、こういったことに悩まされることがなくなります。ISVの管理・制御下に本番運用環境を置くことになるので、バリエーションが少なくなる（プラットフォームが基本的に一元化される）のは当然のことながら、各種ログの取得なども容易に行うことができトラブル発生時でも容易かつ迅速に対処が可能になります。また、開発・テスト・本番（運用）環境の差異を小さくすることも可能なため、想定していなかったインシデントの発生頻度やテスト工数を大幅に小さくすることができます。

さらには、アプリケーションやその実行環境のプラットフォームや技術選択についての決定権がサービスプロバイダー側にあるため、例えばコンテナ化したアプリケーションにしてしまえば、開発者間（PCのOS）と開発-本番環境間のどちらの環境差異も吸収することができ、リリースまでの工程をスムーズかつスピーディーにすることもできます。

こういったことから、インシデントの発生頻度を抑え、またトラブル発生時の解決能力も向上することから、より開発に専念することができユーザビリティの高いサービス提供を目指すことができます。

では考慮すべき点は？

ズバリ、「メリットの反面」です。具体的には、「インシデント発生時の影響度の拡大」と「システム運用管理業務の必要性」です。

インシデント発生時の影響度の拡大

サービスプロバイダーが運用するプラットフォームにてユーザー環境が集約しているので、例えば障害が発生した際にはサービス停止などの影響を多くの（場合によってはすべての）ユーザーに及ぼしてしまうことになります。
以前よりトラブル解決はしやすくなっているのでしっかり対処すれば大きな問題にはならないかもしれませんが、重大な障害をあまりに頻繁に起こしたり一向に改善が進まないようだと、長期かつ継続的に関係性を築いていくことが前提のこのビジネスでは致命的となってしまいます。

システム運用管理業務の必要性

ISVの管理・制御下の環境にアプリケーションをデプロイしサービスを提供することになるので、それまではそれほど意識する必要がなかった運用・保守・監視を行う必要がでてきます。ASP（Application Service Provider）サービスも手掛けている、もしくはSI事業も営まれていて運用も手掛けられているといったISVもありますが、基本的には知見やノウハウなどがあまりない場合も少なくないと思うので、最初のうちはアウトソーシングすることも視野に入れ業務体制を長期的に構築していくことをしっかり考えなければなりません。なぜならば、これらには一定のスキルや知見、ノウハウが必要な専門性が求められる業務のためです。

加えて、障害時の影響度が拡大していることから、当然そもそも障害が起こりにくくもしくは起きた場合でもサービス提供に影響ができにくい可用性の高い設計を行うことはもちろん、セキュリティを担保したりバックアップやリカバリーといった非機能要件の部分も大変重要になってきます。

ソフトウェア販売ビジネスであった故にあまり重要視する必要が薄かったこういった部分を強化していくためには、以前の記事でも紹介したSRE（チーム）の設置と育成に取り組むことが重要です。また以前はDevの部分だけを基本的に考えておけばよかったのでCI (継続的インテグレーション)は取り入れられていたと思いますが、デリバリーやデプロイも考慮したCI/CD パイプラインの構築・運用、さらにOpsの要素が入ってくる上にストック型のビジネスモデルであることも踏まえるとDevOpsの実現が大変重要になってきます。常にユーザーの満足度を高めていく努力を行い解約率を下げて継続的に利用してもらうためには、ITサービスを迅速に開発してリリースし、市場に受け入れられればシステムを拡張、うまくいかなかった場合はすぐにサービスを変更・改修するといった、システム開発のスピード・品質と柔軟性の両立が強く求められるからです。

DevOpsとは

過去に紹介している関連記事をぜひご参考ください。

---以下引用---

DevOpsとはソフトウェアの開発の概念のひとつです。開発チーム（Development）と運用チーム（Operations）が協力しあって開発を進めていくもので、そのふたつを合わせてDevOpsという言葉で表現しています。
SB C&Sでは、DevOpsを「ビジネスの価値を最大化することを目標とし、迅速かつ高品質なソフトウェア開発を実践する継続的な組織活動」と定義しています。開発にあたり、市場の要求をいち早くキャッチするには、リリース後のシステムを管理する運用チームからのフィードバックが欠かせません。こまめなリリースとこまめなフィードバック。そしてそれを次の開発につなげるという、スピード感あふれるサービスの開発と切っても切り離せない概念がDevOpsです。

• DevOpsの導入を検討したいとき、はじめに知っておきたいこと
• 今さら聞けない4つの開発手法。アジャイル/スクラム/Devops/SREとは

最後に

いかがだったでしょうか？SaaSビジネスへの参入のメリットを活かすためには、実は色々と考慮が必要で、あえて付け加えるならば提供基盤（クラウド）の知見やノウハウを高めて蓄積していくことも当然必要です。

弊社では、こういったSaaS化に向けて技術面では、Azureへの移行計画策定フェーズから環境構築さらには DevOps 導入に至るところまでもご支援させていただくのはもちろん、販売面についてもプロモーションやマーケティングのご支援も承っています。

SaaSビジネスへの参入を計画しているISVにお勤めの皆様、ぜひAzureに関してのご相談なら、Azure相談センターまでお気軽にお問い合わせください。