サブスクリプション型 SaaSは場当たり的に改修しがち

　サブスクリプション型で提供されるSaaS製品は、完成品を仕上げてから展開していくビジネスとは違い、販売・提供を進めながら改良改善を続けていく。顧客の要望をすくいとりながらバージョンアップしていくこの方式は、スモールステップで確実に価値を積み上げていくのに適している。

　言い換えれば「大きな投資をして盛大に空振りするのはあまりにもハイリスクだ。だから、小さく生んで、大きく育てる」ということだ。

　この考え自体は理にかなっているが、「開発途中に販売的な事情の影響を強く受ける」というデメリットについて、深く思いを巡らす人は少ないかもしれない。

「いいニュースだぞ！例の商談が進んで、有名企業に採用されることが決まりそうだ。しかし所定のセキュリティ基準を満たさないとダメだと言われてしまった。すぐに開発に取り掛かってほしい」

「申し訳ないが、進めてきたバージョンアップ計画を変更できないか？ヘビーユーザーから、早くこの機能を実装しないと、他社に乗り換えると言われたんだ。最優先でコストを算出し、開発要員をかき集めてほしい」

　期初に社内で描いたロードマップはどこへやら。今日はこちら、明日はあちらとさまざまな案件をさばいては料理し、料理してはさばく。そんなことがSaaSベンダーの内部では起きている。

　その場その場の需要に応じたやみくもな追加開発は、住宅の建て増しみたいなものであり、エンジニアリングの立場からすると非常に気持ち悪い。

　しかしいま目の前で、売れるかどうか、売り上げが立つかどうかを問われているなかで、内部的なビジョンや技術的な制約を理由にそれを断る道理は、セールス側には、一切ない。そのため、サブスクリプション型SaaSは、場当たり的な対応をせざるをえない。

　この矛盾に身を引き裂かれている人々が、なんと多いことか。華々しい流行のかげに、悲哀がある。

「ちょっと」の改修は「ちょっと」ではない

　一昔前は「スパゲッティコード」なんて言葉がよく使われた。その場限りの無計画な開発で部品と部品のつながりが複雑怪奇な構造になってしまい、どこをどういじったら改修できるのか、読み解くのも困難、修正するのはもっと困難なプログラムのソースコードのことだ。

　こんな状態のプログラムに関していえば、「この画面のこの部分を、ちょっとこう直してほしい」という「ちょっと」の要望の難易度が格段に上がる。システムの裏側がきれいに整理整頓され、影響範囲が簡単に割り出せるならば本当に「ちょっと」の修正だ。しかしスパゲッティコード状態のプログラムの場合、エンジニアは、「本当にそこをいじっても大丈夫か」を調べるためだけに、長大ドキュメントを読み通し、コードを熟読し、修正とテストを繰り返すことを強いられる。こうなると、「スパゲッティプロダクト」とでも呼びたくなる。

　「最初から保守しやすいように作ればいい」と思うかもしれない。だが、スモールスタートで徐々に積み上げていくサブスクリプション型SaaSの難しさがここにある。始めたときには見えていなかった要件や制約が、あとから山ほど発生してしまうため、なかなか理想通りにはいかないのだ。

　製品・サービスづくりとは本質として気の長い、長期的な仕事だ。一方でビジネスとは、今月をどう生き抜くか、この四半期でいかに成果を出すかという極めて短期的な戦いが多い。

　プロダクトの長期的視野と、ビジネスの短期的視野の統合に失敗してしまうと、「どうしてこうなった」としか言いようのない状況になる。

【次ページ】サブスクリプション型SaaSのKPIはそもそもスパゲッティ的