クライアント企業について

日用品・医薬品を幅広く手がけるメーカーです。お客様向けのQ&Aサイトを長年運用しており、以下の要素で構成されています。

• よくあるご質問の掲載・検索
• 掲載内容を更新する管理機能
• 定期的に稼働するバッチ処理

現在もサイトは稼働していますが、構築当時の技術のまま年月が経過していたため「現行の標準的な仕組みへ載せ替えたい」というご要望をいただきました。

プロジェクト概要：システムリプレイスが求められた背景と課題

課題1：ユーザー（表側）の視点

• Perl CGIのままでは、サーバー環境の更新やセキュリティ対応が難しくなる
• 対応できる技術者が減少しており、障害発生時の復旧に時間がかかる
• サイトを改善する際に、対応できる人材を確保しにくい

表示上は問題なく稼働していますが、保守できる体制を維持できない状態に近づいていました。

課題2：運営側（裏側）の視点

• 移行によって既存機能が欠落するリスク
• 裏側で稼働している処理の把握漏れ
• 対象範囲と追加費用の境界が不明確なまま進むリスク
• 移行と改善を同時に行うことによる失敗リスク

新規開発ではなく、既存機能を過不足なく別の基盤へ移す作業が中心となる案件です。

提案のポイント

1. 現行仕様を変更しない前提での移行

• 現行の仕様を変更せず、Perl CGIからPHPプログラムへ移行する方針
• 移行と改善を同時に行わず、不具合の原因を切り分けられる状態を維持
• 判定基準を「以前と同じ動きをするか」に限定し、テスト基準を明確化
• 機能改善は次フェーズに切り分け、期間と費用の見通しを確保

基盤の移行と機能改善を分けることで、移行時のリスクとコストの見通しを立てやすくしています。

2. バッチ処理を対象範囲に含める

• QAサイト改修（330万円）とは別に、バッチ処理改修を80万円で独立計上

※バッチ処理＝人が操作しない時間帯にシステムが自動実行する処理（夜間のデータ集計、定時のファイル取り込み、定期的な情報更新など）

• 画面には表示されないが、停止すると業務に影響する領域
• 別紙の見積根拠シートで、管理機能を含む画面とバッチ処理を個別に列挙

移行対象を画面のみで数えると漏れる領域まで対象範囲に含め、見積根拠として明記しました。

3. 対象範囲・成果物の明文化

見積書には、認識のズレが生じやすい論点を記載しています。

• 対象範囲：別紙見積根拠シートに記載した画面・バッチ処理が対象。対象外の機能が判明した場合は別途再見積もり
• 成果物：ソースコードのみを想定（設計書・テスト仕様書等の資料は含まない）

成果物をソースコードのみと明記することで、設計書やテスト仕様書が必要な場合の追加工数と、不要な場合の費用を切り分けられます。

提案規模・想定内容

• 規模：中規模

• 予算：約514万円

使用技術・ツール

• Perl CGI（移行元。Webページを動的に生成する旧来の方式）
• PHP（移行先。現在のWeb開発で標準的に使われる言語）
• バッチ処理（人が操作しない時間帯に自動実行される定期処理）
• 検証用・本番用のサーバー環境構築

プロジェクトで担当した役割

• 現行システムの機能・画面の洗い出し
• バッチ処理を含む移行対象範囲の特定
• 見積根拠シート（画面・処理単位）の作成
• 移行方針の策定（現行仕様を変更しない前提の整理）
• スケジュール・支払い条件・成果物範囲の整理
• 概算見積の作成

対象範囲を画面・処理単位で確認できる状態にすることを優先し、移行時のリスクを事前に整理しました。

おわりに

レガシーシステムのリプレイスは、既存機能を欠落なく移すことが要件になります。

そのため、対象範囲の特定と、移行と改善の切り分けが前提となります。

今回の提案では、現行仕様を変更しない前提でテスト基準を明確にし、画面に加えてバッチ処理を対象範囲に含め、成果物と支払い条件を事前に明文化しました。

blueでは、稼働中のシステムの刷新について、対象範囲の整理から設計段階までご提案します。

古いシステムの移行を検討されている方は、ぜひ一度blueにご相談ください。

関連記事

・【提案事例】出版・情報サービス企業様向け｜楽楽販売を活用した基幹システム刷新提案

・【提案事例】防災・保安用品メーカー様向け｜楽楽販売への移行提案

執筆・編集：blue広報チーム