プロジェクトマネージャ 2010年 午後1 問03

解答の導き方

1. まず、本番移行で問題になる制約を確認します。対象データは「全体で200万件」であり、本番移行はサービス提供時間帯を避けて「6時間以内」に終える必要があります。したがって、移行に時間がかかり、制約を超えることがリスクです。
2. 次に、各方式で本番移行に残る作業を比べます。案イでは、すべてのデータ移行を本番移行だけで行います。一方、案ロでは、本番移行までに変更されないデータを先に移行しておき、本番移行では残りを扱います。案ハでは、すべてのデータを先に移行し、その後に変更されたデータだけを本番移行で扱います。
3. このように、案ロと案ハでは、本番移行で扱うデータ件数や作業量を減らせます。その結果、本番移行の所要時間を短縮し、6時間以内に完了できないリスクを小さくできます。

誤りやすいポイント

• 案ロや案ハで、データ移行そのものが不要になると考えないようにしましょう。本番移行では、案ロなら先行移行できなかったデータを、案ハなら先行移行後に変更されたデータを扱います。
• 「リスクを軽減する理由」を、移行データの正確性だけに結び付けないようにしましょう。この設問では、6時間以内という時間制約に対し、本番移行でのデータ量や作業量を減らす点が重要です。
• 案イも含めて、どの方式もデータ移行の方式ですが、案イはすべてを本番移行で行うため、本番移行の負荷を減らす効果はありません。

FAQ

解答の導き方

1. この設問では、データ移行の方式を決める際に、本番移行が時間の制約内で実施できるかどうかを評価するための作業を問われています。
2. 本文には、本番移行は「6時間以内に終えなければならない」とあります。したがって、実現性を確かめるには、本番移行にどれくらいの時間がかかるかを把握する必要があります。
3. その時間を見積もる材料として、本文は「本番移行が必要なデータの件数と種類」を挙げています。件数や種類によって、移行プログラムで処理する量や内容が変わるためです。また、データの変換は移行プログラムによって行います。
4. つまり、必要なデータの件数と種類を基に、本番移行にかかる作業時間を見積もり、その時間が6時間以内に収まるかを評価します。

誤りやすいポイント

• データの件数や種類を確認するだけで、時間を見積もる必要はないと考えることです。確認した情報を使って作業時間を見積もることが、実現性の評価につながります。
• 本番移行の対象データを正しく作成できるかという、データの正確性の確認と混同することです。ここで問われているのは、時間の制約内で移行できるかどうかの評価です。
• 移行作業全体の期間や、移行プログラムの開発期間を見積もることだと捉えることです。対象は、本番移行に必要な作業時間です。

FAQ

解答の導き方

1. 本文では、本番移行は利用部門へのサービス提供時間帯を避けて行うため、「6時間以内に終えなければならない」とされています。したがって、データを正しく移行できるかだけでなく、決められた時間内に作業を完了できるかが重要です。
2. 移行リハーサルでは、設計した手順の正しさや、手順で作成したデータの確認に加えて、「本番移行が制約の下で確実に実施できること」を検証します。この制約とは、先に示された本番移行の時間制限です。
3. よって、リハーサルでは本番移行にかかる時間を確認し、6時間以内に完了できることを検証する必要があります。

誤りやすいポイント

• データの件数や内容が正しいことだけを確認すればよいと考えること。リハーサルでは、時間制限を守って作業を完了できるかも重要です。
• 「手順の正しさ」と「制約の下で実施できること」を同じ意味として扱うこと。手順どおりに作業できても、所要時間が制限を超えれば本番移行の条件を満たしません。
• 制約の内容を別の条件と取り違えること。本文で本番移行に課されているのは、6時間以内に終えることです。

FAQ

解答の導き方

1. 問われているのは、総合テストでデータ移行によって作成したデータを使うことが、サービス開始後の安定性につながる理由です。
2. 本文には、総合テストの後半から「データ移行で作成した新システムのデータ」をテストに使うとあります。これは、現行システムのデータを新システム向けに変換したデータを使って、テストできるということです。
3. また、総合テストは「本番稼働向けに構築した環境」で行います。つまり、本番環境に近い環境で、実際のデータの特徴を反映したデータを使って業務処理を確認できます。
4. テスト用に単純化したデータだけでは見つけにくい、データの内容や組合せに関係する問題も、サービス開始前に発見しやすくなります。そのため、安定したサービスの提供につながる理由は、本番環境に近いデータでテストができることです。

誤りやすいポイント

• 「テストデータを充実させる」を、単にデータ件数を増やすことだと捉えないようにします。重要なのは、本番に近いデータの特徴を含めてテストできることです。
• 移行プログラムの正しさだけを確認する話ではありません。設問は、総合テストで移行後のデータを使うことの効果を問うています。
• 「本番データそのものを使う」と断定するのは避けます。本文にあるのは、データ移行で作成した新システムのデータです。

FAQ

解答の導き方

誤りやすいポイント

• 「合同チームにすれば不具合が発生しなくなる」と考えないようにしましょう。問われているのは、不具合の予防ではなく、発生後の原因究明が速くなる理由です。
• 原因をデータ移行だけに決めつけないようにしましょう。移行で作成したデータを業務機能のテストに使うため、両方の作業が原因の候補になります。
• 単に「担当者同士で情報共有できるから」とするだけでは、なぜ迅速化するのかが伝わりにくくなります。原因の切分けや、両面からの並行調査まで説明することが重要です。

FAQ

解答の導き方

1. 案1は「移行プログラムを修正する」方法です。ところが、本文では、対象となる200件に合わせるには「多くの箇所に修正を加える必要がある」とあります。変更範囲が広いため、修正作業だけでなく、修正後に正しく移行できるかを確かめる時間も必要です。
2. 不一致が判明したのは「2月の最終週」です。スケジュールでは、その後に移行リハーサルや移行実施があり、サービス開始は4月1日です。修正と検証が予定どおりに終わらなければ、本番移行に間に合わず、サービス開始が遅延するおそれがあります。
3. また、修正箇所が多いと、200件への対応だけでなく、すでに正しく動いていた移行処理に影響が及ぶ可能性もあります。変更によって既存の動作に不具合が生じることをデグレードといいます。修正後に別の不具合が見つかれば、追加修正や再検証が必要となり、移行を確実に完了できるかの見通しも立ちにくくなります。

誤りやすいポイント

• リスクを「修正作業に時間がかかること」だけに限定しないようにします。修正が移行処理の別の部分に影響する品質上のリスクもあります。
• 200件のデータ値が一致しないことだけに注目しないようにします。設問が問うのは、その対応として移行プログラムを多くの箇所で修正する場合のリスクです。
• サービス開始の遅延と、デグレードによる移行の見通しの悪化は、関連しますが異なる観点です。前者はスケジュール、後者は修正による影響範囲や品質に関するリスクです。

FAQ

解答の導き方

1. まず、設問は案2を採用するかどうかではなく、案2の作業を本番移行時に確実に行えることを、どのように検証したかを尋ねています。
2. 案2では、利用部門が業務機能を使って、対象データの値を一件ずつ変更します。本文では、変更が必要な200件について「移行プログラムで対応していなかった」とあります。そのため、まず実際に業務機能を使い、対象の値を正しく変更できることを確かめる必要があります。
3. 値を変更できるだけでは、新システムの業務処理が正しいとは限りません。本文では、課金インタフェースファイルの仕様は変更されず、現行システムと新システムの処理結果は一致しなければならないとされています。したがって、業務機能で変更したデータを使って処理し、両システムの結果が一致することも確認します。
4. さらに、本番移行には「6時間以内に終えなければならない」という制約があります。対象データの変更作業を実際に行い、その時間を測定して、本番移行の時間内に完了できるかを確かめる必要があります。

誤りやすいポイント

• データの値を正しく変更できることだけを確認し、変更後の業務処理結果を比較しないことです。
• 作業手順が実行できるかだけに注目し、6時間以内に終えられるかという時間の制約を見落とすことです。
• 案2は利用部門が業務機能を使って値を変更する方法なので、移行プログラムの修正だけを検証内容として挙げることです。

FAQ