システムのリプレース案件って失敗しやすいのかなぁと思ったのでちょっとメモ。
もちろん新規開発だって難しいわけで失敗確率もそれなりにあるわけなんですが、リプレース案件の場合はリプレースならではの事情で更に難易度が上がるのではないかなと。
システム開発の鉄則として、まずできるだけ小さく作るってのがあります。いきなり重厚長大なシステムを手がけても、完成までには非常に時間がかかるし難易度も飛躍的に上がります。その完成をユーザは待ってくれません。小さく作りながら実際に使ってもらってフィードバックをもらうことで微調整していくというのは有効な手法です。って、アジャイルに話が偏ってますけどね。でもウォーターフォールだって、フェーズを分けて少しずつ開発していくってやり方もあるんですけどね。
ともかく、まずは小さく作りたいのです。新規開発の場合はシステムはなにもありませんから、どんなに小さくても機能が一つ出来あがれば進歩です。業務システムであればカイゼンってやつです。しかし、リプレース開発の場合、既存のシステムがあるんですよ。隣に既存のシステムがある状態で、機能に不足のある新システムを用意したところで、誰がそれを使うでしょうか。それだけだとカイゼンではなくカイアクです。コンシューマ向けサービスとかなら、まあまだそれもできるんですけどね。一旦ユーザが激減しても、そっから先で盛り返す見込みがあるなら果敢にチャレンジするという選択肢はある。しかし、業務システムはそうはいかない。業務システムは、スタッフは好むと好まざるに関わらず使わなければならないから。にもかかわらず新システムが機能不足で業務が回らないなんてことになったら、現場は阿鼻叫喚となりますよ。
ということで、業務システムのリプレース開発では既存のシステムの機能を全て兼ね備えることが最低ラインになるわけです。当然ながら、そのハードルはかなり高いものになるでしょう。また、リプレースするのですから、既存のシステムの不満点をカバーしたり、野心的な新機能が仕様に盛り込まれたりもするでしょう。となるともう、最初のリリースに至るまでの道のりが遙か彼方になってしまうわけです。この道程の途中で力尽きてしまうリプレースプロジェクトも多いだろうと思います。また、こうしたことが予想されることから、リプレースには取りかからず、既存のシステムの改修でなんとか回している現場も多数あることだと思われます。でも、それは問題を先送りにしているだけで、いつかは爆弾が破裂するわけですが。
これに対して特にこうしたらいいという対策は思いつきません。単純に、新規開発時にうまくいったからリプレース開発もうまくいくと安易に考えて取りかかると痛い目をみるような気がします。少なくとも、リプレース開発にはこのような困難な問題が存在するということを肝に銘じたうえでとりかかるべきかなと思います。
(2016/8/22追記)
最近知ったんですが、こういうのを「セカンドシステム症候群」というのですね。「人月の神話(ISBN:978-4621066089)」で論じられているそうです。やっぱり私なんかが書く文章に目新しいことなんて何一つ無いですな。
ただ、セカンドシステム症候群についてのネット上の記述を見る限りでは、セカンドシステムでは野心的な機能を盛り込んでしまうことに対する指摘が主眼であって、私が主に論じたセカンドシステムではファーストシステムを超えることが最低ラインになってしまうことはあまり論じられてないみたいです。だとすれば私がこんな駄文を書いた意義も少しはあるのかもしれない。無いのかもしれないけど。
過去記事で言えばスクラッチで書き直すのはそんなに悪いことなのかとかもちょっとこれに関係あるかもしれない。はてなダイアリーというファーストシステムに対して、はてなブログというセカンドシステムが開発された。はてなブログの開発チームがどれくらいセカンドシステム症候群を意識していたかは分からないけれど、開発は比較的うまくいっているんではないだろうか。勝手な評価だけど、はてなブログの開発がうまくいった理由の一つは、ファーストシステムを超えることを目標にしなかったことではないかと思う。リリース直後のはてなブログって、はてなダイアリーはもちろん他のブログサービスでも当然に用意されているような機能が全然実装されてなくて評判も凄く悪かったように記憶しています。小さく作って細かくリリースしてを繰り返して、現在では立派なブログサービスに成長しています。はてなダイアリーというサービスを並行して運用していたから機能不足でもリリースできたってのもあるかもしれないし、一時的にユーザが少なくても構わないという覚悟もあったんだろうとは思う。ともあれ、はてなブログはセカンドシステム症候群にははまらずに済んだのかなと思います。