はじめに

開発案件の1つとしてリプレイス案件がよくあると思います。既存システムを新たに作って置き換えるというのがリプレイス案件です。オンプレでやってるシステムをクラウドに移行したいや、古いシステムを新たに置き換えたいなど色々な理由でリプレイス案件が発生します。
このような案件の際営業チームは、新しい機能や現行システムから比較した際の使いやすさの改善を提案し、クライアントの社長やシステム担当者を説得して契約を締結します。
じゃあ開発陣はその営業さんが提案したシステムを作ればうまくいくの？という点を見ていくと、ほとんどうまくいかないことが多いです。この記事では、その原因と解決策について見ていこうと思います。

システム移行がなぜうまくいかないのか

現場からの反発です。
システムを置き換える際に、現場の社員から強い反発が生じることがよくあります。特に、営業担当者が使用するシステムでは、その傾向がさらに顕著です。

システムのリプレイスは、通常、経営者やシステム担当者が主導します。社長は売り上げ向上や業務効率化、システム維持費の削減を目的にリプレイスを決定します。しかし、現場の社員にとっては、これらの目的が直接的なメリットとして感じられないことが多いのです。

たしかに現行システムに使いづらさがあるかもしれませんが、現場の社員にとって最も重要なのは「日々の業務が滞りなく行えること」です。システムが変更されることで業務フローに混乱が生じたり、使い慣れた操作が変わると、現場のストレスや反発が一層強まります。効率化や維持費削減といった経営的な視点では正しいリプレイスであっても、現場の社員にとっては「どうでもいい」と感じられることが少なくありません。

また、デモを見せる際に、社員が最初からネガティブな観点でシステムを見ることもよくあります。たとえば、「処理速度が遅い」「前はこういうことができたのに、今はできなくなっている」といった不満が挙がることが多いです。こうした不安や不満はデモの段階で現場の反応としてすぐに表れ、実際の変更が行われる前から抵抗感が形成されてしまうのです。

エンジニアが取るべきステップ

実際にどのようにしたらうまく導入までがスムーズになるのか。
リプレイス案件でエンジニアが取るべきアプローチは、システムを段階的にリリースすることです。まずはVer.1で現場の信頼を得てから、Ver.2で新機能を導入し、さらに業務改善を進めるという2段階の手法が効果的です。以下では、Ver.1とVer.2に分けてそれぞれのステップを詳しく説明します。

Ver.1: 現行システムとの一致を目指す

最初のステップであるVer.1では、可能な限り現行システムと同じ構成・機能を持つシステムを作成することが重要です。具体的には以下の点に重点を置きます。

DB構成を現行と同じにする
将来的に新機能を追加したり、データ構造を最適化したいと考えている場合でも、まずは現行のDB構成をそのまま維持することが大切です。データの構造が変わることで業務フローに大きな影響を与える可能性があるため、初期段階では現場の社員が使用しているシステムとできる限り同じものを提供します。
UIやデザインの変更は最小限に
UIやデザインは多少変更しても問題ありませんが、業務フローそのものは現行システムに忠実に再現します。社員が日常業務で使用している操作感をできるだけ維持することで、現場の混乱を避けることができます。
パフォーマンスの維持・向上
リプレイスしたシステムが、現行システムよりも処理速度が遅いと不満が生じやすくなります。Ver.1の段階では、パフォーマンスを重視し、少なくとも現行システムと同等の速度を確保することが求められます。これにより、現場の社員が新システムに対して信頼感を抱く基礎を築くことができます。

Ver.1は、現場での業務に影響を与えないことを第一に考えたリリースです。この段階で新機能を追加するのではなく、現行システムの再現に注力し、パフォーマンス面でも現場の期待に応えることで、現場の信頼を獲得します。

Ver.2: 新機能の追加と業務改善

Ver.1が安定して運用され、現場からのフィードバックも問題が少ないと確認できたら、次に進むのがVer.2です。Ver.2では、エンジニアのスキルを活かし、次のステップに進みます。

新機能の導入
Ver.2では、営業チームが提案していた新機能を段階的に導入していきます。ここで重要なのは、現場のニーズを反映させることです。Ver.1の運用を通じて得られたフィードバックをもとに、現場が本当に必要とする機能を優先的に実装します。これにより、システムの価値を高め、現場からのさらなる支持を得ることができます。
業務フローの改善
Ver.1で現行フローを再現した後、Ver.2では業務フローの改善にも着手します。たとえば、現場で時間がかかっているプロセスを効率化したり、操作を簡略化することで、現場の社員の負担を軽減します。ここでの改善は、現場がすでに新システムに慣れたタイミングで行うため、抵抗が少なくスムーズに進行します。
パフォーマンスの最適化
Ver.2の段階で、システムのパフォーマンスをさらに最適化します。特に、新機能を追加する際にパフォーマンスが低下しないよう、アーキテクチャやデータベースの最適化を進め、将来的な拡張にも対応できるようにしておきます。
フィードバックの継続的な反映
Ver.2以降は、現場のフィードバックを継続的に反映させることが鍵となります。現場で実際に使用される中で見えてくる改善点を素早く取り入れ、必要に応じてVer.2の内容を柔軟に修正していくことで、システムを進化させながら現場の満足度を高めます。

Ver.2では、システムの価値を現場にさらに浸透させ、業務効率の向上や機能性の向上を実現します。この2段階のアプローチにより、初期の反発や不安感を抑えながら、最終的には現場のニーズに合ったシステムを完成させることが可能になります。

結果的に、この段階的なアプローチは一見手間がかかるように見えるものの、長期的には最も効率的で現場からの反発も最小限に抑えられ、確実にシステムを導入・運用できる方法となります。

営業チームとの連携の重要性

リプレイス案件において、エンジニアが営業チームとしっかり連携することは非常に重要です。営業チームは、クライアントに対して新しいシステムの魅力や利便性を伝える役割を担っていますが、彼らが提案する新機能やシステムの改善案を実際に形にするのはエンジニアです。そのため、営業がクライアントから得た現場のニーズやフィードバックをしっかりと共有してもらうことで、エンジニアは現実に即したシステム開発を進めることができます。

特に、営業が初期段階で提案する新機能や利便性の改善案は、現場のユーザーにどのような影響を与えるかをよく理解しながら進める必要があります。そのため、エンジニアは営業との密なコミュニケーションを通じて、開発の優先度や現場に対する影響を踏まえた開発計画を立てることが重要です。これにより、クライアントや現場の期待に応えるだけでなく、システム導入後のスムーズな運用も確保できます。

最後に

遠回りに見えることが、実は効率的になっているというのはよくあるよね