最近、リプレイス案件のお話をいただく機会が増えています。
システムが古くなって新しいものに置き換える必要があり、システムも新環境で動くように刷新したい。
業務は変えないので機能も同じでいい。
現行をリプレイスして欲しい、
といった感じのご依頼内容です。

この手の依頼ですが、単純リプレイスを前提で考えると少々やっかいになる場合があります。
まぁ、やっかいというか手離れが悪くなるというか…
『現状のままで』を意識しすぎるとハマると思います。

実際に顧客に話を聞いてみると、リプレイスという言葉を使いつつも、
潜在的に業務効率を上げたい要求があることが多いです。
改善できることろは新たに改善したいのです。

リプレイスと言ってるのは、全く同じものを作るという意味でなく、
変えなくていいところまでは変えて欲しくないけど、改善できるところは新しくしたい。
作り直すよりは、費用がかからないのでリプレイス？
といった潜在意識もあり、こういった表現なんだと思います。
まぁ、考えてみれば当たり前です。

リプレイス案件では、言葉の罠にかかってしまうプロジェクトをよく見かけます。
（私のまわりのプロジェクトだけかも知れませんが）
顧客の方もリプレイスという言葉を使っているためか、
完全リプレイスのものをリリースしてもクレームにはなりません。
しかし、後付けで改善要求が結構出てきます。
しかも無償で微修正の範囲でなんとかしようと。
結局いつまでもリリースできず手離れが悪くなってしまいます。

不思議なもので、リプレイスと聞いた瞬間に要件定義しなくて良いとなってしまうみたいです。
いきなり既存のシステムを見たり、ソースがあればソースを確認したり、
初っ端から詳細設計フェーズに力を入れだすのもよく見かけます。
でも、アプリの動作とコードから見ているだけだと、その機能の本来の目的とズレる場合も出てきます。

なので、
初回のお客様との打ち合わせの際に、本当に単純なリプレイスなのかそうでないのか？
の視点でヒヤリングすることをおすすめします。
言い方はわるいですけど、疑ってかかるのが無難と思います。
そして、要件定義は行う前提で取り組む方が良いと思います。