生活協同組合事業A連合会(以下，A連合会という)は，近隣地域で同じ事業を営むB，C，Dの三つの生活協同組合(以下，生協という)が加盟した事業連合体である。事業としては，商品カタログに基づく注文を受けて，翌週に商品を届ける宅配系と，店舗で商品を販売する店舗系がある。
　宅配系事業では，三つの生協の業務の標準化が完了しており，その業務を支える宅配システムも統一している。一方，店舗系事業では，運営コストの低減がこの数年進んでいなかった。各生協での店舗運営の特徴を尊重して，店舗業務の標準化を行わず，店舗業務を支える店舗システムもオフィスコンピュータ(以下，オフコンという)を使った旧来のものをそのまま使用し続けていて，統一されていなかった。また，オフコンは，数年後にはハードウェアの保守サポートが停止され，後継機の予定もないという問題を抱えていた。
　A連合会のシステムは，図1のように，宅配システムと店舗システム，及び両システムと機能連携して商品情報を管理する商品システムで構成されている。〔重要課題と対策〕
　システム担当のX理事は，A連合会の現状から，業務運営上の重要課題を次の2点に整理した。
　(重要課題1)店舗運営コストの低減
　(重要課題2)オフコンのハードウェア保守サポート停止への対策
　X理事と，店舗系事業を担当するY理事による検討の結果，次の対策案が決まった。店舗運営コストの低減は，店舗業務の標準化及び店舗システムの統一で実現する。店舗業務の標準化については，組合員の評価が高いC生協の業務プロセスに統一する。店舗システムの統ーについては，業務要件の追加・変更をしないで，C生協のものを採用し，B生協，D生協の店舗システムは廃棄する。オフコンの保守サポート停止への対策として，サーバ上で稼働するシステムに切り替える。
　A連合会では，重要課題について，これらの対策を採択することを総会で決定した。
　決定後に，Y理事は，各生協のシステム利用部門から店舗業務に精通した要員をシステム再構築のプロジェクトに参画させるので，要員のスキルに適した作業を担当させてほしいとX理事に要請した。

〔開発方針〕
　X理事は，開発予算を抑えたシステム再構築のプロジェクト計画を立案するようにA連合会の情報システム部のW部長に指示し，Y理事からの要請も伝えた。総会で決定された本番開始の目標時期は，1年半後である。
　宅配システムは，ソフトウェアパッケージを活用して各生協の宅配システムを統一し，一つのサーバに集約済みであるので，今回のシステム再構築の対象外である。商品システムも，一つのサーバに集約されており，利用部門からの強化要望もないので，店舗システムとのaだけを改修する。aの手順と形式は，店舗システムと商品システムとのデータのやり取りに基づいて決めることにした。

〔開発計画(案)〕
　Z社は，A連合会の情報システム子会社であり，3生協の店舗システムを含めて，A連合会の全システムの開発・運用・保守を行っている。W部長は，情報システム部で立案したシステム要件を提示し，システム再構築に関する開発計画(案)の立案をZ社に依頼した。あわせて，プログラムのソースコード(以下，ソースコードという)とソフトウェア詳細設計書(以下，設計書という)の構成管理の実施状況についても，確認を依頼した。構成管理については，開発フェーズから実施しているが，保守フェーズになってからソースコードの修正が先行し，設計書への更新作業が遅れるケースがあり，この改善に取り組んでいるとZ社からW部長に報告があった。
　W部長は，オフコンからサーバ上で稼働するシステムへの切替えに当たって，①新規開発ではなく現行機能を単純に移行する方式のシステム移行(以下，単純移行という)をZ社に要請した。その際に，W部長は，単純移行以外に，開発期間，開発予算，開発体制を勘案して，もう一つの移行手段を考えた。それは，②ソースコードの見直しを検討する必要がなく，技術的にも移行手段の主流になっているが，今回はオフコンのOSの特殊性から断念した。
　W部長は，単純移行の対象となるデータファイル，ソースコード，及び設計書について一覧表を作成するようZ社に依頼した。あわせて，単純移行作業で利用することを想定して，③設計書の内容に関する追加調査も依頼した。この追加調査の結果次第で，移行作業の工数に影響が出てくると付け加えた。
　W部長の依頼に対し，Z社は，図2の開発計画(案)を作成した。〔店舗システムの単純移行〕
　W部長が依頼した追加調査の結果に問題がなかったので，Z社は，オフコンのソースコードの単純移行作業を請負契約とする前提で図3のように進めることにした。1．全ソースコード・全データファイルの分析作業
　単純移行の対象となる全ソースコード・全データファイルの内容を分析する。サーバ関連技術に精通しているSEが分析作業を行い，分析結果は，単純移行方式の検討と決定に使われる。事前の調査で，オフコンのプログラム本数は，バッチ系プログラムがオンライン系プログラムの2倍あり，大量データの処理プログラムが，十数本あることが分かっている。また，大量データの処理プログラムには，それぞれ固有の処理特性と運用時間帯の制約がある。
2． ソースコードの単純移行
　単純移行作業では，オフコンのソースコードを，移行ツールを使って変換し，変換できない部分は，設計書を参考に手作業で修正する。　移行ツールの選定に当たっては，④サンプルのソースコードを移行ツールによって変換した結果を比較し，評価する。サンプルのソースコードは，SEによる分析結果に基づいて選出する。評価のポイントは，移行ツールで変換後に手修正する作業工数が少ないこと，手修正の作業が容易であること，及びバッチ系プログラムの処理性能の3点を重視し，処理性能は実測して評価する。
3．データファイルの移行
　データファイルの移行は，システム面からの検討とともに，3生協のデータ項目の桁数，コード化したデータの扱いなど，移行対象データの業務仕様も考慮して行う。
　データファイルの移行体制は，作業の効率性・専門性を高める観点から，Z社のSEだけによる専任体制とすることがZ社から提案された。当該SEはオフコンからサーバへの移行に関する知識をもつ単純移行の経験者であった。この案に関して，W部長は⑤移行対象データに関する作業内容を考慮して，体制の強化が必要であると考えた。
4．単体テスト～ソフトウェア結合テスト
　最後にW部長は，結合テストでの作業効率の向上，及び品質を保証するテストケースやテスト条件のbの確保をZ社に要請した。Z社は，テスト計画の立案，テストの実施，テスト結果の評価と分析に，オフコンでの店舗システム開発時の結合テストに関する資料やデータを活用することにした。作成するテストケースやテスト条件のbについては，システム利用部門の要員とレビューして，漏れが無いことを確認する。
　W部長は，Z社への要請事項の検討結果を確認後，X理事からプロジェクト計画の承認を得て，システム再構築のプロジェクトを正式に発足させた。