ソフトウェアシステムの継続性と陳腐化 ～コト売り事業におけるソフトウェアのあり方～
久山
コト売り事業に必要な要素
サービスを陳腐化させない
コト売り事業をするために一番大事なことは、もちろん提供するサービスに価値があることですが、それに加えて、そのサービスが陳腐化しないということも大事です。サービスが陳腐化してしまうと、一度ついた顧客も簡単に離れてしまいます。サブスクリプション事業においては「Churn率」（解約率）をいかに小さくするかが事業の成否を決めますので、陳腐化は絶対に避けなければなりません。
しかし、コト売りサービスも放っておくとすぐに陳腐化してしまいます。サービスに必要とされる機能は、その時々の顧客の状況や社会制度などによってすぐに変化します。また、サービスを支えるソフトウェアも、新しい技術が登場するサイクルは非常に短く、これに追随しないとあっという間に陳腐化します。
陳腐化を防ぐためには、頻繁に機能の追加や、インタフェースの改善などのための改造を行なっていく必要があります。一度作ったシステムをそのまま長く使い続けるというわけにはいきません。システムを絶えず変えていくことが必要であり、このためのコストがかかります。ソフトウェアを継続的に変えていくことを前提で考えるとこのコストは半ば固定的なコストになってしまいます。いかに低コストでシステムを更新していけるかも、事業の成否を決める重要な課題です。
継続的にサービスを提供する
一方、変えていくだけでなく、継続性も求められます。コト売り事業は一度契約顧客から定期収益を得るビジネスモデルですので、継続的にサービスが提供できなければ成り立ちません。特にサービスを行うために蓄積した「データ」の継続性は重要です。データはサービスの価値の根源となるものです。コト売り事業で蓄積したデータが使えなくなることは、老舗の鰻屋さんが秘伝のタレをドブに捨てるのと同じことです。システムを変えた時にそれまで蓄積してきたデータが使えなくなると言うような事態は絶対に避けなければなりません。
また、サービスを安定して供給できることも重要です。システムを改造する度に、不具合によるシステムが停止していては話になりません。運用中の障害の多発は、ユーザ離れの大きな原因になります。
ソフトウェアシステムのあり方
ソフトウェアシステムの観点で言うと、データを継続的に利用でき、かつソフトウェアを低コストで安全に更新できるものが必要だと言うことになります。なかなか難しい要求ですが、ソフトウェアを設計する上では、以下を考えるべきです。
データモデルは変更しない
システム改変時の、データモデルの変更は非常に危険です。データモデルの変更はシステム全体に影響を及ぼしますので、思わぬところで問題が発生することがよくあります。運用を開始した後の変更は、しばしばシステム障害を引き起こします。これまで全く問題なく動いていた機能が、データモデル変更により突然動かなくなったりします。また、機能追加や変更時にデータモデルも併せて変更する場合は、しない場合と比較してソフトウェアの変更コストは大幅に増加します。さらに問題なのは、データモデルを変更すると、結果的に、それまで積み重ねてきたデータが使えなくなる可能性が高くなることです。
少なくともデータモデルの変更は、運用開始後に頻繁に行うものではなく、極力避けるべきです。最初に設計したデータモデルは安易に変更すべきではありません。言い方を変えると、最初のデータ設計は非常に重要であり、しっかりと時間をかけて行うべきであると言うことになります。最初にデータモデル設計を失敗すると、全てが悪い方向に行ってしまうのです。
機能追加を想定したフレームワークを用意する
一般的に、長年にわたって無計画に機能追加や改造を行うと、元の設計意図とは違う考え方で実装が行われ、ソフトウェアの構造はどんどん複雑になり、改造が影響する範囲が広がっていきます。このため、改造を繰り返す度に、改造コストは大きくなり、システム障害を引き起こしやすくなっていきます。建物に置き換えると、下のような感じです。
ソフトウェアの機能追加や改造では、大なり小なりこのような劣化が起きますが、劣化の度合いを小さくすることはできます。このために、どのような機能追加や改造があり得るかを想定し、機能を追加や改造による影響が小さくなるようなアーキテクチャにしておくことが必要です。また、追加する機能の実現方法を「パターン化」しておき、そのためのフレームワークを用意しておくことにより、機能追加時のコストを低減することができます。
リソースを使わない設計をする
昔と比べ、これらのH/Wの性能は上がり価格も下がっており、オンプレミスのシステムでは、コンピュータリソースの制約が問題になるケースは少なくなっています。
しかし、システムがオンプレミスからクラウドになってくると、また話は違ってきます。クラウドの使用料金を決める要素は、「CPUスペック（種類と数）」「メモリサイズ」「ディスクサイズ」「通信量」、またSaaSの場合は、ソフトウェアAPIの呼び出し回数などです。クラウドの使用料金の増加は固定費の増加として事業の収益性に影響しますので、リソースの使用量は極力下げておきたいところです。コンピュータのメモリやディスクやCPUをいかに使わずに機能を実現できるかを考える必要があります。
新規事業とソフトウェアのあり方
新規事業の立ち上げの際に、事業が軌道に乗るまでにたどるプロセスをスタートアップ・フィットジャーニーとして表すことがあります。この中のSPFのフェーズまでとPMFあたりから後のフェースでソフトウェアのあり方は変わってくるのではないかと思っています。
PMFまでは、提供するソリューションが課題を解決するものになるのかを検証するフェーズであり、顧客に価値を提供できる最小限のプロダクト(MVP : Minimum Viable Product）を作り、短いサイクルでこれを変えながら検証を行なっていきます。
しかし、ここで作られるソフトウェアが、そのまま継続的な事業に使えるかは疑問です。どのようなプロダクトにすべきかの検証の時点で、上で述べたような「データモデルを変更しない」「どのような機能追加があるかを予測する」のは現実的ではないと思います。また、検証フェーズでもリソースを使わないソフトウェアをにするに越したことはありませんが、それよりも早く機能を実現することに注力するべきでしょう。
事業を成功させるためにはPMFフェーズあたりで、検証用のソフトウェアを事業継続用のソフトウェアに作り替える必要があるのではないかと思います。検証用のソフトウェアをそのまま事業に使い続けるのは、あまりにも危険です。
