基幹システムの中には、10年以上前に構築されたレガシーシステムも少なくありません。 こうした古いシステムは、メンテナンスに多大なコストがかかるようになります。 （atma がお客様からご相談いただく時に多い理由の一つにコミュニケーションコストがあります。開発ベンダーに改修や不具合の連絡をしても返信がなかったり、コミュニケーションの間隔が長く空いてしまい、お客様が求めるスピード感と合わなくなることがありました。）

例えば、プログラムの改修には古い言語の知識が必要となりますが、その言語を扱えるエンジニアが減少し対応できなくなることもあります。

また、ハードウェアの保守部品の調達が難しくなったり、ソフトウェアのサポートが終了したりするケースも増えています。

ビジネスのグローバル化や新規事業の立ち上げなど、企業の業務は大きく変化しています。しかし、既存の基幹システムでは、こうした変化に対応するための機能が不足しているケースが多々あります。

例えば、海外展開に伴い、多通貨対応や現地税制対応が必要になりますが、既存システムでは実現が難しいといった事態が発生します。

企業のIT環境は、クラウドサービスの普及などにより、多様化が進んでいます。そうした中、基幹システムと他のシステムとの連携を実現し、データを一元管理したいというニーズが高まっています。

例えば、基幹システムの売上データとマーケティングオートメーションツールの顧客データを連携することで、効果的なプロモーション施策の立案が可能になります。

しかし、既存の基幹システムは他システムとの連携を想定した作りになっていないことも多く、APIの整備などが必要になります。

近年、サイバー攻撃の手口が巧妙化しており、企業はセキュリティ対策の強化を迫られています。特に基幹システムは、機密情報を多く扱うため、重要な攻撃対象となっています。

しかし、古いシステムでは、最新のセキュリティ脅威に対応できていないケースが少なくありません。パッチ適用といった対症療法では、根本的な解決は難しい状況です。

要件定義とは、システムに実装すべき機能や性能を具体的に定義することです。この要件定義が曖昧だと、ベンダーは的確なシステム設計ができません。

例えば、「在庫の引当ルールを柔軟に設定できること」といった抽象的な要件では、実際にどのような処理が必要なのかが分かりません。

また、要件定義では、例外処理の定義も重要です。「在庫切れの場合は前工程にフィードバックを掛ける」といった具体的なルールを定義しないと、想定外の動作につながります。

さらに、非機能要件の定義も見落とされがちです。レスポンス時間や同時接続ユーザー数など、システムのパフォーマンスに関わる要件を明確にしておく必要があります。

基幹システムのリプレイスでは、スケジュールを過小に見積もるケースが多々見られます。プロジェクトの開始時点で、その全容を正確に把握することは困難だからです。

例えば、データ移行の工数は、移行元データの品質に大きく左右されます。しかし、プロジェクト開始時点で、データの品質を精査するのは容易ではありません。

また、要件定義の段階で想定していなかった追加要件が発生するケースも少なくありません。こうした追加要件への対応も、スケジュールを圧迫する要因となります。

そして見積もりの誤りによる工数増大に対して、ベンダーの開発リソースが想定通り確保できないケースもあります。特に大規模プロジェクトでは、要員計画通りに体制を組むことが難しいことを想定してプロジェクト管理をする必要があります。

基幹システムのリプレイスでは、複数のベンダーが参画することも珍しくありません（特に大規模プロジェクトでは）。こうしたマルチベンダー体制では、プロジェクトマネジメントが重要となります。

例えば、各ベンダーの役割分担を明確にし、責任の所在を明らかにしておく必要があります。曖昧な責任分界点は、トラブル発生時の対応を遅らせる原因となります。

また、ベンダー間の調整も重要です。要件の食い違いやインターフェースの不整合などの問題を早期に発見し、解決していく必要があります。

さらに、テストや移行といった局面では、綿密な計画と入念な実行が求められます。計画倒れのまま本番移行を強行すると、大きなトラブルを招くリスクがあります。

基幹システムのリプレイスでは、ユーザー企業とベンダーの認識齟齬が問題となるケースが多々あります。受発注者間のコミュニケーション不足が、その主因と言えます。

例えば、要件定義の段階で、ユーザー企業の業務知識が十分にベンダーに伝わっていないケースがあります。（ユーザー企業にとっては当たり前すぎる常識なためベンダーに伝えていない情報が存在するが、ベンダーは当然その情報を把握していないので的確な設計ができていないことが後から発覚するケース）

また、開発段階でも、仕様変更の連絡がベンダーに伝わっていないケースがあります。ユーザー企業内の意思決定が、ベンダーに共有されていないのです。

さらに、トラブル発生時の報告が遅れるケースも見られます。ベンダーがトラブルを把握できていないと、適切なアクションを取ることができません。

基幹システムは、業務クリティカルな位置づけにあるだけに、十分なテストを行う必要があります。しかし、テスト工程が軽視されているケースも少なくありません。（コスト削減のためにテスト工程が削られるケースもしばしばあります）

例えば、テストケースの網羅性が低いケースがあります。主要な業務パターンのみテストし、例外パターンを見落としているのです。

また、テストデータの品質も問題となります。実際のデータを用いた実践的なテストが行われていないと、本番稼働後に想定外の動作を招くリスクがあります。

さらに、テスト期間の短縮を急ぐあまり、十分な検証が行われていないケースもあります。工程遅延を取り戻すために、テストを削減するのは本末転倒です。

データ移行は、基幹システムのリプレイスにおける最重要工程の1つです。しかし、その難易度を見誤り、トラブルに直面するケースが後を絶ちません。

例えば、移行元データの品質が想定以上に低いケースがあります。データクレンジングに想定以上の工数を要し、スケジュールを圧迫します。

また、移行ツールの不具合により、データ変換に失敗するケースもあります。ツール自体の機能不足や、ツールの使い方の誤りが原因として挙げられます。

さらに、移行リハーサル不足も問題となります。本番環境を想定したリハーサルを十分に行わないと、本番移行時のトラブルを招くリスクがあります。

要件定義は、現場の業務知識が不可欠です。システムを実際に利用するエンドユーザーの意見を十分に吸い上げ、要件に反映させる必要があります。

例えば、営業部門の要望を聞き、受注処理の要件を具体化します。「見積書の作成機能が必要」といった大枠の要望だけでなく、「過去の類似見積を参照したい」「値引き率は事前に設定された範囲内でのみ入力可能とする」といった詳細な要件まで落とし込むのです。

また、倉庫部門の意見を基に、在庫管理の要件を固めていきます。「先入先出法で在庫を引き当てる」「ロット管理が必要」など、現場の業務ルールをシステム要件として明文化するのです。

さらに、経理部門の要望を汲み取り、会計処理の要件を定義します。「税区分ごとに仕訳を作成する」「債権の回収予定日を管理する」など、会計基準やルールに基づいた要件定義が求められます。

現場の担当者を集めたワークショップを頻繁に開催すると効果的です。業務フローを可視化しながら、その潜在的な要件を引き出していくのです。

現行システムの課題を洗い出すことも重要です。「この処理は手作業で行っており、自動化したい」「リプレイスを機に、ここからここまでの業務を完全に廃止する」など、現場の生の声を拾い上げ、改善要件を明確化します。

収集した要件は、曖昧さを残さないよう、具体的な表現で文書化していきます。「一覧性が高いこと」といった抽象的な表現は避け、「検索条件を5つまで指定でき、結果を一覧表示できること」といった具体性を心掛けます。

無理のないスケジュールを組むには、要件定義の段階である程度の正確性が求められます。その点で、前述の現場主導の要件定義は、適切なスケジュール策定にも寄与します。

スケジュール策定では、要件の優先度付けも重要なプロセスとなります。リリース時に必須の要件と、追加開発での対応が可能な要件を仕分けるのです。（ここで「あれもやりたいこれもやりたい」を全て同位の優先順位にしてしまうとスケジュールに影響を与えてしまいます）

例えば、「受注処理の自動化」は必須要件、「顧客向けポータルサイトの構築」は追加開発要件と位置付ける。こうした優先度に基づくフェーズ分けにより、リリースを意識した開発計画が立案可能となります。

また、データ移行や、関連システムとの連携テストなど、開発工程以外のタスクも考慮に入れる必要があります。これらの工程は、しばしば見積もりが甘くなりがちです。

データのクレンジングや、移行リハーサルの工数は、事前の調査を基に慎重に見積もる必要があります。関連システムとのインターフェース設計も、各システムの仕様を十分に吟味したうえで、スケジュールに組み込みます。

マルチベンダー体制では、プロジェクトマネージャーの采配が鍵を握ります。各ベンダーの役割と責任を明確に定義し、全体最適な方向でプロジェクトを牽引していく必要があります。

例えば、インフラを担当するベンダーと、アプリケーションを担当するベンダーの間では、環境構築のタイミングや、非機能要件の実現方式などを綿密に擦り合わせる必要があります。

定例会議の場などを活用し、ベンダー間の認識齟齬を解消していくことが重要です。議事録を全ベンダーで共有し、情報の非対称性をなくす工夫も必要です。

品質管理の面では、全体を俯瞰したテスト計画の策定が求められます。単体テスト、結合テスト、総合テストなど、各テストフェーズの位置づけを明確にし、網羅的なテストを計画的に実施していきます。

また、テストで検出された不具合は、原因を分析し、真の責任主体を見極めることが重要です。局所的な対応に終始せず、問題の根本的な解決を図る姿勢が欠かせません。

自社の業務を理解し、長期的な視点でサポートしてくれるパートナー選びが重要です。単なる開発請負の関係ではなく、事業の成長を共に目指せるビジネスパートナーを目指します。

ベンダー選定では、規模や知名度だけでなく、自社のビジネスとの親和性を見極めることが肝要です。業界特有の業務知識やノウハウを持つベンダーであれば、要件定義段階から強力なサポートが期待できます。

また、類似プロジェクトの経験も重視したい評価ポイントです。同業他社の基幹システム構築の実績があれば、自社への展開もスムーズに進められるはずです。

加えて、ベンダーの持つ技術力も見極める必要があります。採用する製品・ツールが、将来の業務変化にも柔軟に対応できるかどうかは重要な観点です。

さらに、アフターサポートの充実度も確認しておくべきでしょう。保守運用体制やサポートの即応性など、リリース後も安心して任せられるベンダーを選ぶことが肝要です。

テストでは、網羅性と再現性を重視する必要があります。業務上の重要度に応じて、テストケースを洗い出し、もれなくテストを行うことが求められます。

例えば、売上計上の処理は、あらゆるパターンを想定してテストを行います。通常の販売だけでなく、返品・値引きなどの例外パターンも漏らさずテストするのです。

また、テストの再現性を担保するために、テストデータの管理も重要です。同じデータを使って、何度でもテストが実行できる環境を整備しておく必要があります。

移行リハーサルは、本番環境と同等の環境で実施することが理想的です。移行ツールの動作確認だけでなく、移行後のシステムの動作確認も含めて、トータルな検証を行うことが重要です。

さらに、移行判定基準を設けることも忘れてはなりません。例えば、「マスタデータの移行率100%」「xxデータの移行差異±1%以内」など、具体的な合否基準を定めておきます。

大規模プロジェクトでは、当初の予算見積もりを超過するケースが多々あります。そうしたリスクを見越して、予算には一定の余裕を持たせておく必要があります。

具体的には、プロジェクト予算の20〜50%程度を予備費として確保しておくことをお勧めします。要件変更による追加開発や、トラブル対応などに備えるのです。

また、ランニングコストの見積もりも重要です。サーバー費用、ハードウェアの保守費用や、ライセンス費用など、継続的に発生するコストを見落とさないよう注意が必要です。

予算管理では、アクティビティベースでのコスト把握が有効です。要件定義、設計、開発、テストなど、各工程に紐づくコストを可視化し、予実の乖離を早期に把握する取り組みが求められます。

さらに、プロジェクトの投資対効果を定期的にレビューすることも重要です。プロジェクトの途中で、当初見込んでいた効果が達成できないことが判明した場合は、大胆な計画変更も視野に入れるべきでしょう。