業務システムにおけるアジャイル その3：SaaSとの相性

中佐藤です。

今回は、いろんなベンダーさんから石を投げられそうな話で、ちょっとビクビクしながら投稿します。
とはいえ、同様の話を最近あちこちで聞くので、心を鬼にして(?)解説します。

業務システムを刷新する際に、スクラッチ開発ではなく、SaaSベースで開発する、という状況もよく聞くようになりました。ベースのSaaSがあり、そこにサードパーティー製のプラグインを入れたり、自分たちでカスタマイズのコンポーネントを作成して追加する、という開発方法です。
そして、このようなSaaSベンダーさんは「うちのサービスはアジャイル開発向きです！」とおっしゃることがあります。動作するシステムをすぐに作って見せられること、対象サービスが想定している変更の範囲であれば、設定ファイル等で簡単に変更ができることが、その根拠でしょう。

これは決して間違ってはいないのですが、鵜呑みにすると危険だな、と思う事例をよく聞くようになりました。気を付けるべき点は以下：

• 「対象サービスが想定している変更の範囲」が思った以上に狭い
• プラグインの入れ替えが技術の問題ではなく時間がかかることがある
• 対象SaaSを使うことそのものを再考せざるを得なくなることがある

ひとつずつ解説していきます。

SaaSとはいえ、パッケージの一種であると思います。パッケージであるからには、その「設計思想」があり、そのSaaSを使うということは、その設計思想に乗っかるということです。SaaS側が利用側の都合に合わせてくれるわけではありません。特にスクラッチ開発やより自由度の高いCMS（Contents Management System）に慣れていると、え、こんなこともできないの、と足元をすくわれます。やりたいことと、SaaSの提供している機能を、よくよく比較・検討しなければなりません。

さらにSaaS特有の課題として、ある日いきなりSaaSの提供機能が変わります。このあたりはオンプレミスにインストールして使用するパッケージ以上にシビアです。今日できていたことが明日できなくなるかもしれず（もちろん事前予告はあるでしょうが）、対象SaaSのバージョンアップにずっと追随する必要があります。

このようなSaaSベンダーさんは、サードパーティーのプラグインを開発・販売している会社と協業し、いわゆる「エコシステム」を形成していることが多いです。
それはそれで結構なことなのですが、問題はそれぞれに契約が必要なこと。SaaSベンダーとは別に、プラグインの会社との契約が必要になります。別のプラグインを使おうとすると、さらに別契約が必要になる。

そしてこの契約というものは、どうしても開発よりは時間がかかります。場合によってはあらためて稟議を通したりするために、数か月かかってしまう。最初にこのプラグインでいける！と開発を進めた結果、やっぱり機能不足だった、他のプラグインでよさそうなものがあると気づいても、すぐに乗り換えられるわけではないのです。結果として、技術面とは全く別の観点で、アジリティを阻害することになります。

同じ会社内の別システムで特定のSaaSを使用しており、まあまあうまくいっていると聞けば、自チームでも有力な候補になるでしょう。ところが残念ながらほんのちょっとした差で、自チームのシステムには合わなかった、ということが十分起こりえます。

実はひとつのシステムでもそうです。アジャイル開発は基本的に、継続して開発し、徐々にひとつのシステムを大きくしていきます。その過程で、今までうまく要望とマッチしていたのにも関わらず、これは無理、という事態になることがありうるのです。

この時に、エンドユーザーに納得してもらえるでしょうか？
はたまた、今まで積み上げてきたSaaSベースのシステムを捨てて、別のプラットフォームに乗り換えることができますか？

まずは、ベンダーさんの売り文句を鵜呑みにせず、上のような可能性があることを理解してください。もし、エンドユーザー側から指定されたSaaSなのであれば、エンドユーザーにも理解してもらう必要があります。お互いにこのようなデメリットを理解していただくためのたたき台として、今回の記事を書きました。

もう少し大きな視点でいうのであれば、開発側には、さまざまなサービスやパッケージ、プラットフォームを、自分たち自身で選定する「目利き」が必要です。
これを次回のお話にしましょう。