SaaS開発ほど面白いものはない - エンハンスや障害対策が容易
SaaSの顧客はオンライン上、つまりインターネット上に提供されているソフトウエアの使用権を購入して、そのサービスを受ける。それを実現するため、SaaSの提供者は自分で管理するサーバにソフトウェアをインストールして、サービスを提供することになる。このことは、我々開発者にとっても大きな意味を持つ。
つまり、製品のエンハンスや障害対策は、自分で管理しているサーバに適応するだけで完了することになり、エンハンスや障害対策の費用を格段に低く抑えることができる。結果として、開発のプロセス、技術者のメンタリティ、開発へのアプローチなどは、受託開発やパッケージ開発のものと大きく異なるものになる。
SaaSは、このように「気軽にエンハンスや変更が可能」という特性を持つが、それとは対極の位置にある工業製品として代表的なものが、最近話題のトヨタに代表される「自動車」だと思う。自動車産業ではリコールは日常茶飯事らしいが、リコールのたびに莫大なお金をかけて対応していかなければならない。リコールを避ける工夫や、万が一に発生したときの対応など、ものすごい苦労を強いられていることだろう。リコールが発生しない車を開発しなければならない自動車メーカー開発陣が受けるプレッシャーは、尋常なものではないだろう。全体の開発工数に占めるテストの割り合いも、非常に大きいものだろう。
不具合を検出せずに出荷してしまった工業製品による損害は、次のような式で表せるかと思う。
[出荷数] × [1台あたりの不具合による損害] × [1台の対策に掛かる費用] × [世間の評判へのダメージ]
自動車産業の場合、上の全要素が大きなものであるため、損害は相当大きなものになる。
SaaSをこの式にあてはめて考えると、1台の対策に掛かる費用がほぼゼロ。厳密には出荷数にかかわらず、[出荷数]ｘ [１台の対策に掛かる費用]が同じということだが、どちらにしても損害はかなり小さいものになる。経営的視点でこのことを照らしあわせると、出荷前の品質管理の工数を低く抑えられて、結果的にコストを低く抑えることが可能になる。
開発者の視点で考えてみよう。まず、出荷時の不良率を低く保つ手段として行う「テスト工程」を縮小することが可能になる。テスト工程は、クリエイティブを好む優秀な技術者であればあるほどやりたくないものである。ものづくりの醍醐味は、使える部品を組み合わせ、いろいろな制限事項をかいくぐって役に立つものを作ることで、単調なテストを黙々と続けることではない。
ところが、ソフトウエアにはいままで不可能と思われていたような複雑な業務においても使われるようになってきている。複雑であればあるほど、使い方のパターンも膨大になり、結果としてテストのパターンは爆発的に大きくなる傾向にある。
欧米での開発では、この辺りはうまく考えられている。プログラマとは別のテスターが存在し、優秀でクリエイティブなディベロッパーは単調なテスト工程から解放されているのが普通だ。日本の開発では、どういうわけか「作ったものは自分でテストする」という考え方が主流で、プログラマが自分でテストすることになる。
SaaSの開発では、テスト工程そのものをなくすことはできないが、「障害対策が容易」という特性の結果、テスト工程をかなり少なくできる。結局、プログラマはテストのことを気にせず、大胆な実装も気軽にできるようになる。さらに、TDD（Test Driven Develppment）のプラクティスを行っていれば、Regression testの工数をほとんどゼロにすることも可能だ。
企業の業務に使うソフトで、テスト工程ををそんなに縮小して良いのかと思うかもしれない。ここで書いているのは、99.99％問題ないものを出荷する必要はなく、99.9％問題ないレベルで十分だということで、まったくテスト工程をなくすということではないということを理解してもらいたい。 99.99％OKなシステムと99.9％OKのシステムの違いは、ユーザにとって、1万人のうち10人が不具合で迷惑を受けるか、それとも１人しか受けないかの違いに過ぎない。1万人のうち9人にしか影響の違いはない。一方で、99.99％の品質を達成するためのテスト工数は、99.9％の品質にする場合の10倍はかかるだろう。
不具合に気づかずに出荷すれば、いずれは全ユーザーが不具合によって迷惑を被ることになる。「やはりそれはまずい」と思われるかもしれないが、SaaSの場合それはない。なぜなら、他のソフトウエア開発の基準で考えるものよりは、格段に短期間で対策を入れることができるからだ。
不具合の重要度にもよるが、気づいた時点で即刻入れるものもあるだろうし、その日の夜入れるかもしれない、また定期的に準備するバージョンアップ時などに対策を入れていくことになるかもしれない。対策を入れてしまえば、他のユーザーにとってその不具合の存在はなくなるのだ。もちろん、これがいえるのは、SaaSの特性の1つである「マルチテナント」により、複数の顧客で同時に同じシステムを使っているからだ。他の顧客が先に不具合を見つけてくれた結果、自分自身は結局不具合なしで使い続けることになる可能性がかなり高いのだ。
開発工程内における「テスト工程」を減らすことにより、開発コストを下げることが可能になる。そのことは、価格的にも反映されることになる。お客様にとっても好都合な話だと思う。
もちろん、ここで不具合の種類に注意する必要はある。当たり前のことだが、データ化けや計算結果を間違えるような不具合の発生は100％許されない。その点に関するテスト工程は普通の受託開発と同じレベルで行う必要はある。
ということで、今回書きたかったことをまとめる。
SaaS開発では、プログラマはテスト工程を、普通の受託開発の時よりはかなり縮小することが可能になる。結果、プログラマはテスト工程のことを気にすることなく開発に没頭できる。より大胆な開発が可能になるのである。