この記事、身につまされる。
システム開発の頓挫を巡る、文化シヤッターと日本IBMとの間の裁判で、東京地方裁判所は日本IBM側に19億8000万円の支払いを命じた。米セールスフォースのPaaSを用いた販売管理システムの構築を目指し、2015年に始めた開発プロジェクトだったが、2017年にストップしていた。東京地裁は開発失敗の原因をどう認定したのか。裁判記録をもとに読み解く。
そもそもの話として、RFPを作成したベンダーと、受注したベンダーが同じ時点で両社がかなり深い関係だったんだろうなと推察する。
システム入れ替えのタイミングで既存ベンダーがRFPを作成する。その時、できるだけ他社には受注させないような表現をするのは目に浮かぶ。
既存ベンダーはシステム開発にあたって、これまでの資産を流用する提案を書けるが、他社にはその情報がない。したがって既存ベンダーの提案が一番安くなり、リプレースも既存ベンダーが取っていく。まさにベンダーロックインの現象である。
それまでの信頼関係もあるので、よくある風景だが、この件については最後は損害賠償の係争にまでたどり着いている。
深い関係とは言え、受けてはいけない案件だってあるということをこの件は教えてくれる。ではどの段階で、断るべきだったのか。
この案件の流れは以下のように推察する
①ユーザーがシステムリプレースをすると決断
②ユーザーが、既存ベンダーにRFP作成を委託
③既存ベンダーがRFP作成を受注し、RFPを作成
④ユーザーがRFPに基づきコンペを実施
⑤コンペにおいて既存ベンダーが受注
⑥要件定義において、ユーザーが既存ベンダーに、大量の独自仕様を要求
⑦既存ベンダーが要件を飲み、下流工程へ強引に進める
⑧既存ベンダーがテストを行ったところ、品質が悪く本番運用できる状態ではないことを確認
⑨既存ベンダーがユーザーに、再度開発しなおすことを提案
⑩ユーザーにとって提案が受け入れがたく、ユーザーは既存ベンダーに開発失敗の損害賠償を提起
⑪既存ベンダーはそれまでにかかった開発費用を求めて、ユーザーに提訴
どこで失敗したのか。
本件はまだ裁判中の案件で、私が軽々に表現するのはまずいと思うが、業界の人間として他山の石としたい。時間を巻き戻せるならどこがポイントとなるのか。
直接の原因は、SalesForceが年3回バージョンアップするのに、大量のカスタム開発を実装してしまったため、本番運用できない実装になってしまったことにあるようだ。
つまり、システム開発をする前の要件定義時に、実装した後、運用が難しいことを判断できていれば、ここまでの損害にはならなかっただろう。つまり、⑥がポイントか。
要件がある程度明確化されたところで、「その仕様を、SalesForceで実装することはできません」と言えなかったのは、この時点で実装を知っている人が既存ベンダーにいなかったのか。実装は次のフェーズで考えることであり、要件定義は要求業務を整理することと割り切ってしまったのか。
ただ、実装のことを考えない要件定義などあり得るのか。こういう技術を使って、こういうインフラ基盤を使い、こうします。運用はこういうイメージです。次のフェーズに行く前に、実装担当やその後の運用担当まで巻き込んでレビューすべきではなかったか。
上記は、この記事を読んだら誰でも考えるとは思うが、そうならなかった背景があると推察する。RFP時までは、既存ベンダーの営業担当と、ユーザーの経営層の間で「これからはSalesForceでモダナイズしていかないと」みたいなフワッとした話が盛り込まれていたのではないか。そして、要件定義時は経営層ではなく現場担当が出て来て、いや、SalesForceでもなんでもいいが、これまでのユーザーインターフェースは維持してもらわないと困る、という意向が強硬に働いたのではないか。プロジェクトマネージャーは板挟みになり、SalesForceで大量のカスタム開発をする禁断の実装を選んでしまったのではないか・・と邪推してしまう。
１つ記事の中であれ、と思ったのが、
RFPでは標準部品を80％、セールスフォースのPaaS用プログラミング言語である「Apex」や「Visualforce」を使ったカスタム開発を20％とする予定だった。システム稼働は2016年7月、総開発費用は約12億3400万円を見込んでいた。
とあり、RFP時点でカスタム開発の割合が明記されていることだ。
であれば、要件定義時にこのまま実装を進めれば95%がカスタム開発になることを予想できなかったのか。
ところが開発は見通しを大きく外れ頓挫する。東京地方裁判所の認定によれば、文化シヤッターが旧システムと同様の画面の見た目にこだわり、日本IBMも積極的に標準部品の活用へ誘導することなく2次要件定義フェーズや設計・開発フェーズを進めたため、カスタム開発の割合は95％に膨れ上がった。
とある。誰か止められなかったのか。
おそらく実装したタイミングでは、カスタム開発はすんなり動いたんだろうな、と思う。その後システムテストを行うまでに、SalesForceのバージョンアップが走り、大量のカスタム開発が動かなくなった、みたいな問題がテスト時に発覚したんだろうな、とこれも邪推。
この件、まだ係争中なので、記事に書かれた内容がそのまま最終認定されるとは限らない。記事の中に書かれていることに感想を述べたまでである。ただ、学べることが多い話だ。クラウドサービスにおいては頻繁にアップデートがかかる。これに合わせることができる開発物を作成しないと、アップデートのたびに全部テストをし直し、動かない場所を特定し修正する仕事が必須となる。開発時に実装できればいい、ではない。クラウドサービスの利用にあたっては、かなりクラウドベンダー側に主導権を取られるので、この点は要件定義の段階でかなり意識し臨む必要があることは間違いない。
アップデートが必ずあることを意識し、作りこみすればするほど維持不能に近づくことを関係者全員が意識しなければいけなかった。そうすれば、もっと早い段階で止まることができたのではないか。
クラウドサービスを使うリスクを、具体的に感じさせられた記事であった。
