業務用SaaS導入プロジェクトを思いっきり失敗した話
どうもお久しぶりです。前回の投稿が「転職して半年」という報告でしたが、今回はちょうど入社して１年経った時点での近況になります。
で、掲題の通りですが、入社以来関わっていたプロジェクトが見事に失敗しました。自分としてはがっかりしている気持ちがある反面、突き進まなくて良かったなという気持ちもある複雑な心境です。
今回はどうしてプロジェクトが失敗したのか振り返っていきたいと思います。
入社当時の状況
入社の経緯や詳しい期待値はこちらの記事に書いてありました。
ここで「アセットマネジメント用のSaaSソフトウェアを導入」と書いてありますが、このシステム(=SaaSプロダクト）がまさに１年かけて失敗したものです。
入社当時の状況を振り返ると、導入するプロダクト選定は終わっており、まさに契約書にサインする直前という段でした。
事業のプラットフォーム責任者として、プロダクト選定に関われなかったのは結構痛いなと思っていたのですが、外部のコンサルを入れており、要求定義含めてそれなりの期間（6ヶ月位）を費やしていたので、そこはしっかりできているものとして考えるしかないと思っていました。
雲行きが怪しい
そんなわけで、着任してすぐにやったのは選定されたプロダクトのレビューです。アセットマネジメントのシステムなんて比較的簡単なので、そんなに問題はないだろうと思っていましたが、そのプロダクトをざっと見たところ、どうにもよくわからないことが多くありました。何点か不安な要素があったのですが、一番大きなものは全体のデータモデルがbi-temporal model（*1)ではないというものです。これはローンを管理する上で致命的なのですが、アセットマネジメントシステムでは、そこまで「過去のデータをどの時点でも再現する」という要求が厳しくないので、最悪なんとかなるかと思っていました。ただ、その要求を取り入れていないということは、データモデルがあまりsavvyではないということを意味しており、バックエンドのエンジニアやプロダクトの思想・設計の質に疑問符が付きました。
また、データモデルに不安を覚えたため、簡易ER図かData Dictionaryを見せられる範囲で開示して欲しいとお願いしたところ、「現在、アップデートされたものがない」と言われたこと（秘密保持の観点から見せられないではなく）もますます不安を高めることになりました。
以上のような所見を上司及びチームに伝えたのですが、それはつまり彼らが６ヶ月もかけて行ったプロダクト選定に疑問符をつけるのと同じで、あまり強く言えず、伝え方に苦労しました。結局、懸念は伝えたものの、外部コンサルの猛烈なプッシュもあり、契約は予定通り行うとの方向でまとまりました。
決定的な矛盾
というわけで契約したわけですが、Implementationも最初からあまり上手くいきませんでした。まず、自分たちのインスタンスができるまで、２か月かかりました。その間は、ほぼやれることがなく…。その時点で全体の計画にかなりの遅れが見られました。遅れの大きな要因として、契約した会社が買収されてより大きなスタートアップの会社の1部門となったことが挙げられます。買収されたことにより、もともとのプロダクトのインフラと買収会社のインフラの統合などが発生し、我々のプロジェクトに影響を与えていました。また後から明らかになった事実としては、この段階でもともといたエンジニアが全員退職したようです。
と、遅々と進むImplementationでしたが、決定的な出来事がありました。それはプロダクト選定の際にできると言われており、最大のセールスポイントだった機能が実際は使えないとわかったことです(*2)。
この「できる/できない」問題は英語だと特にややこしく感じるのですが、我々が想定している使い方は「できなかった」のですが、別のかなり限定的な使い方は「できる」という状況でした。私の所管では、実際、どちら（SaaS側か自社側）が悪いかというと、8割位はSaaS側が悪いかなと。実際、我々はユースケースを説明しているわけで、それに対して、SaaS側ができると回答しているので。
つぎつぎに明らかになる不完全さ
上記の致命的な問題に加えて、どんどん製品上の問題が浮かび上がってきます。それらの一つ一つは上記ほど致命的ではなかったのですが、問題はそれらを解決するリソースが彼らになかったことです。
もとのエンジニアがいなくなっているので、改善要求しても何も起こりません。文字通り、そのまま放置され、SaaSのPMに認知されているかすら怪しいレベルでした（改善要求するためのチャネルも常に変わり、結局Productサイドからレスポンスをもらえなかった）。
結果
社内でミィーティングを重ね、そのSaaSとのImplementationは中止し、お金はいくらか返してもらうことになりました（このプロダクトには月額200万円以上払っており、しかも1年分を一括で払っていました。高！と思ったんですが、どんなもんでしょう？普通？）。
失敗の原因と考察
ずばり、悪いプロダクトを選んでしまったことに尽きるかと思います。
SaaS提供先の買収というのは予期せぬところであり、それによって起こった先方のエンジニアの退職（とそれに伴うサービス低下）については、自分達でコントロールできないことなので、仕方ないと思うのですが、プロダクトの完成度が高ければ、とりあえずは動くわけで、なんとかなったんじゃないかなと思うのです。つまり、もともと完成度の低いプロダクトを選んでしまった上に、買収というイベントによって、プロダクトの改善力/開発力が大幅に落ちてしまい、これ以上、お金を払うことに合理性がなくなったと思います。
個人的に今回の件を振り返って、過去のどこのポイントに戻ったら今回の事態を避けることができたのかと考えたのですが、残念ながら私個人では無理で、この結果は不可避だったのかなと思いました。というのも、上記に記載した通り、懸念を感じていたとはいえ、6カ月かけてきたプロジェクトを否定できるほど、私個人の信用度が無かったし、短期間では築くのは無理だったと思うからです。
また、外部プロダクト活用vs.自社開発という点でもいろいろな知見を得ることができました。私の前職はもっと巨大な組織で、FRBの監督下に置かれていたこともあって、クラウドの活用には消極的だったので、基本的には自社でほぼ全ての基幹システムを開発・保守していました。その時は、社内のテクノロジーリソースの奪い合いになってしまい、自分たちのプロジェクトがいつまでたっても始められないというジレンマがありました。なので、現在の会社の方針である外部プロダクトの積極活用というのを良いことだと思っていたのですが、お金を払っているのに外部がここまで使えない状態だとはたしてどうなのだろうと思ってしまいました。n=1の話なので、他の会社はもっと良いと信じたいですが、どうなんでしょうか？
今後どうするか
とりあえず6カ月位をめどに、自社内でData Warehouseを作り、自分達でデータビジュアライゼーションやレポーティングといった要求に対応していく予定です。もちろんSaaSを活用する前提で考えていた成果物と同等のものをは出せないので、いくつか本当に必要なものだけに注力することになります。
というわけで以上が約1年経過時の記録です。
きちんとした成果が出せるように頑張りたいです。
あとがき
駄目元で返してもらうと意気込んでいたお金ですが、驚きの結果になりました。なんと支払い金額の３分の1は返金、３分の2はクレジットとして返金するということになりました。というのも、一応、契約自体は解約せず、プロダクトが改善されるのを待つ、待っている間は支払いは行わないという落とし所に決着したからです。それにしてもほぼ全額返すって凄くないですか？やっぱりアメリカの常識がよくわからんと思うのでした。
(*1) bi-temporal というのは、おそらくこちらのBanking industryでは業界的に通用する言葉だと思うのですが、基本的にはデータベースにtime_in/time_outとstart_date/end_dateの二つの時系列を入れて、a)いつデータが入力されて、いつ取り消されたか（あるいは現在もまだ有効か）、b)そのデータはいつからいつまでvalidかをトラックするものです。
aは主に、incorrectなデータエントリーかどうか判別するためで、bはデータの変遷を判別するためです。
前職では常識的な概念として取り入れられてましたし、違う銀行から転職してきたエンジニアも既知だったので、業界スタンダードだと思っています。もし違っていたら教えてください。
(*2)お試し期間として、実際に触って検証する機会はなかったんか？と思われそうですが（そして私も思いましたが）、どうもそのような期間はもらえなかったようです。その後、いくつかのSaaS製品の導入に関わりましたが、基本的にお試し期間を設けてくれたところは1社のみでした。これって普通の商慣習かんでしょうか？誰か知ってる人いたら教えてプリーズ！