自社パッケージ販売からサブスクリプション型サービス展開する際に考えるべきこと（随時更新）

概要

　昨今、愛車（KINTO）、焼き肉食べ放題（牛角）、動画配信（Amazon Prime）、音楽配信（Spotify）と様々なサブスクリプション（以降サブスク）形態のサービスが登場しています。その波に乗ろうと自社開発のパッケージ製品をサブスクのクラウドサービス(2018.6～)として展開しました。その際に得られた知見を残し、これから始める方の参考になれば幸いです。
　なお、クラウドサービスに限定した内容になります。また、思い出したら随時追加します。
　※自社クラウドサービスはQiita「自社クラウドサービスをAnsibleで作った話 recap」で紹介しています。

まず、よく言われているサブスクリプションのメリットをざっくりまとめたものになります。
詳しい内容は割愛します。

サービス提供側のメリット

• 収入の安定化
• サービス改善の容易化（特にIT系はフィードバックループを回しやすい）
• 新規顧客のハードルを引き下げる

サービス利用者のメリット

• 低価格で利用し始められる
• 容易に解約できる
• 所有するコストを減らすことができる

前提条件

• 自社サービスを展開したことがない
• システム運用をしたことがない
• 自社パッケージを開発している

用語

単語の意味の齟齬を減らすために以下のような定義とさせて頂きます。

• サービス化･･･サブスク型のクラウドサービス
• サービス･･･製品と同等の意味
• パッケージ･･･B2B向けの業務パッケージ

考えるべきこと

1．売り方に対する考えが異なる(最重要！)

サブスクの基本的な考えになりますが、従来のパッケージ販売は売ったらすぐに大きな売り上げが立つので、売ることを重要視してきました。一方サブスクは継続してサービス利用してもらうことを重要視しているので、サービスを購入させることがゴールではない。なので継続してもらうための施策を考え、実行しなければならない。
以下のすべてのことはこの目的を達成するためと言っても過言ではないぐらい重要です。

もし、経営陣がこの売り方を理解できないのであればすぐにやめたほうがいいです。

2. 体制

密に各チームが連携していく

今まで以上に営業、開発、運用、サポートの各チーム間の連携が求められます。
昔ながらの開発はパッケージを作って、あとは営業に頑張って売ってもらうスタイルだったのが、前述の目的を達成するために各々の役割を理解し目的を達成するための戦略をたて、協力し合って実行していかなければならない。

一番わかりやすい例として、利用分析から得られた気づきを各チームに連携し、サービスの品質向上、新機能の実装、機能改善、サポートの品質向上などにつなげる。場合によっては、非技術部門の方に分析基盤を利用してもらえるように環境を整えたり、レクチャーすることもある。

新たな役割を担うチームが必要

システム保守、SRE、アナリティクス、Webマーケティングなどと専門知識を要した組織が必要になる。
サービス開始当初はそういった要員やスキルを確保できないことも多いが、予めこれらを念頭に構築（分析用のログ）や整備（業務フロー）しておくことで、後から始められるように準備しておくことをお勧めします。

3．製品

リリースサイクル

※パッケージ版のリリースサイクルが年、数か月単位、提供方式がCD/DVDなどのメディアを前提しています。
　DL形式で配布しているとしても、顧客がアップグレードするまでにタイムラグがあるため、スムーズな価値提供ができない。

パッケージとサブスクの両形態で製品を提供していくと、どちらに合わせてリリースするのか？が問題になります。
パッケージに合わせた場合、クラウドサービスならではの高速なフィードバックループを活かせない。（仕組みや体制が必要）
サブスクに合わせた場合、小さなバグフィックスや機能改善の都度にパッケージ版をリリースするとコストが大きくなる。

最終的には決めの問題になりますが、製品戦略でサブスクを主軸にしていくのであればサブスク版を優先リリースし、機能優位性や顧客満足の向上を図るのも有りかと思います。

販促サイクル

前述のリリースサイクルの変更に伴い、販促方法も変わっていきます。
サブスクを主軸にした場合は、リリースごとにパンフレットを更新していくとなるとコスト高になるので、Web（Web広告、HP、SNS）を主とした販促方法になっていきます。

見えていなかったことが見える

従来だと基本的に営業が顧客との接点だったことから、顧客の利用状況や要望を営業経由で情報を入手することが多かった。
ただ、すべての顧客からそうした情報を得られるわけでもなく、得られた情報も必ずしも正確とは言えないことから、情報の質としては問題がありました。
サービス化したことにより顧客の利用方法や頻度、障害などをシステマチックに知れるようになることで、提供した価値検証（追加した機能が本当に必要だったのか？UXに問題ないのか？などの検証）や問題の早期発見ができるようになる。

クレカ決済

※残念ながら弊社は実現できていないが、クレカ決済対応は重要だと考えています。

なぜ重要かというと、従来の見積書、注文書の決済フローだと人手による業務が発生します。契約数に応じてそれらの間接費も大きくなっていきます。せっかく開発や運用で自動化してコストダウンを図ったにもかかわらず、決済業務で利益を食いつぶされるのはもったいないですよね。もし、多くの顧客が月払いだとしたら毎月大量の決済業務に追われて目も当てられない状況です。
クレカ決済ではない場合は年払いを基本にすることも対策の一つですが、顧客数が増えるのにつれてそれも有効な対策とは言えないと思います。

クレカ決済のみならず、人手を要する業務をいかに圧縮できるかが重要なので、サービス提供以外でコストがかかるようでしたら見直しを検討することをお勧めします。

4．システム開発

高速なフィードバックループを実現するための仕組み作りがメインになります。

分析できる仕組みを考慮する

自分たちが提供している価値が正しく顧客に届けられているのかを検証するために、予め分析できる仕組み作りを考慮してインフラの設計やアプリの設計していかなければならない。
ログ設計する際は目的をもった意味のあるログを出力する、依存性の低いシステム構成（例：ログの保存先のエラーによって、アプリがダウンしない）にすることが求められます。リソース（人員、時間）不足の場合は、ログの出力と保存だけはしましょう。

※利用規約に利用頻度などデータはサービス向上させるために利用している旨を顧客とと同意すること。

自動化

コストの最小化、利益の最大化を図るためにも人の介入を最小限にする必要があります。初期から完全に自動化するのは難しいと思いますので、繰り返し作業や安全性を求める作業を重点的に取り組むことをお勧めします。最終的にCloud Nativeをめざして、CI/CD、運用も含めて自動化する。
ただし、自動化したことで大事故も容易に発生するので、サーキットブレーカー（異常値の検出）を設けることをお勧めします。サービスの重要点（特にインフラ）を定め、重点的に対策することが望ましいと思います。

※ツール、プラットフォーム、サービスの選択肢としてCloud Native Landscape
※Cloud Nativeを実現するための道のりはCloud Native TrailMap(PNG)、日本語訳

コンテナ化

安定して、高速なリリースサイクルを実現するためにはコンテナ化は欠かせない要素だと思います。
ただ、パッケージ版にコンテナを持ち込めない場合は、パッケージ版とサブスク版間での差異を最小限にするための構成（主にCI/CD）を考慮しなければならない。

開発手法

高速化なリリースサイクルを目指すためには必然的にアジャイル型の開発手法を採用することになると思います。

コスト

従来のモノリシックなパッケージコードをクラウドサービスに適した構成にしたり、CI/CDの整備、サービスのインフラ構築などと開発に関わるコストが発生します。また、新しいスキルの学習コストも発生します。
リソース不足の場合は、インフラ部をマネージドサービスに任せるのも選択肢のひとつとしてありかと思います。

5．運用

コスト

随時コストダウンの施策を実行していくことはもちろんですが、リリース後に機能追加や強化で企画当初よりもコストが増えることがあります。
例えば、自前の監視基盤をマネージドサービス（DataDog、CloudWatch、Mackerel）に切り替えると固定費は増えるが、管理コスト、安定性などの金額に表しづらいコストも含めて考慮して判断する必要があります。

自動復旧

人の介入が必要なく、コスト削減や安定性を考慮して、システムの自動復旧できる仕組みを考慮する必要があります。
例えば、IaaSのインスタンスが突然死した時に、それを検出し自動再起動する仕組みを設ける。

6. 業務

サービス化で新たな収入源を確保するのはいいことですが、それに伴う業務コストをないがしろにすると、穴が開いたバケツ状態になるので、業務の最適化も併せて進めていくことをおすすめします。

SFA、CRMの導入の検討

前述のクレジット決済にも述べましたように、サービス化することで収入源が増え、新たな業務も発生します。それらを従来の手作業でしかかっていくと結局業務コストで利益を食いつぶす状態になります。なので、SFAやCRMなどを導入して、商談が受注ステータスになった段階で自動でアカウントが発行され、サービスが利用できるレベルまで整備できていると無駄な業務コストやリードタイム（サービスが利用できます）が減る。また入り口に営業を通さない場合は、申込フォームからトライアル利用申込して自動でアカウントが作成され利用できるような仕組み作りもありかと思います。