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

解答の導き方

1. 問われているのは、現行システムの入力データを新システムに手入力したとき、総合テストにどのような影響が出るかです。単に入力作業が大変かどうかではなく、テストの進行にどう影響するかまで考えます。
2. 本文には、現行システムの入力データは「1日当たり数千件に及ぶ」とあります。しかも、総合テストでは数日分を「すべて新システムに手入力」する必要があります。この量を手作業で入力すると、入力そのものに時間がかかり、総合テストで予定している確認作業を進めにくくなります。
3. 手入力では、入力内容を誤る可能性もあります。誤りが見つかれば、データの修正や再入力が必要になり、その分だけテストに手戻りが生じます。結果として、総合テストが予定どおりに進まなくなるおそれがあります。
4. 本文では、こうした混乱を避けるため、現行システムの入力データを新システム用の入力データに変換するツールを開発するとしています。したがって、答えでは「総合テストの進行が遅れること」または「入力ミスによる手戻りが発生すること」を述べれば、懸念されている影響を表せます。

誤りやすいポイント

• 「手入力が大変」とだけ答えると、総合テストに何が起きるのかが示されません。テストが予定どおりに進まない、または入力ミスによる手戻りが発生するところまで述べます。
• 「入力ミスが起きる」だけでは、その後に何が生じるかが不足しがちです。修正や再入力による手戻りにつながる点を押さえます。
• ミドルソフトの不具合や、現行システムの障害に関する記述と混同しないようにします。この設問は、総合テスト用データを手入力することによる混乱を問うています。

FAQ

解答の導き方

1. 問われているのは、現行システムの機能追加を凍結しなかった場合に、現行システムから提供される機能との間で起こり得るリスクです。テスト日程やミドルソフトの不具合ではなく、新旧システムの機能や仕様の整合性に注目します。
2. 1次開発では、オンライン処理用の業務APを新たに開発します。一方で、その処理結果は「現行システムのバッチ処理に、現在のインタフェースを変えずに引き継がれる」とあります。つまり、新システム側の業務APは、現行システム側の機能や処理上の前提と整合している必要があります。
3. そこで、現行システムのオンライン処理用の業務APについて、「昨年12月末に機能追加を凍結」し、その後の機能追加は新システム稼働後に行う方針にしています。新システムの開発中に現行システムの機能が追加されると、開発時に前提としていた仕様と、現行システムが実際に提供する機能との間にずれが生じるおそれがあるためです。
4. そのずれが生じると、新システム側で現行機能との仕様の整合性を保てず、現行機能と同等の動作を保証できなくなる可能性があります。したがって、懸念されるのは、現行機能との仕様の相違や、現行機能を保証できなくなることです。

誤りやすいポイント

• 問われているのは、機能追加を凍結する目的ではなく、凍結しない場合に懸念されるリスクです。
• ミドルソフトの不具合やテストの遅延ではなく、現行システムと新システムの機能・仕様の不整合を答えます。
• 「インタフェースを変えない」ことだけに注目せず、現行システムの機能が開発中に変わると、新システムとの整合性が崩れ得る点まで考えます。

FAQ

解答の導き方

誤りやすいポイント

• 「混乱」を単に「スケジュールが遅れる」とだけ捉えないことが大切です。問われているのは、品質の状況によって起きる具体的な作業上の問題です。
• 1次開発と2次開発のオンライン処理用の業務APには、土台となるプログラムとその修正という関係があります。この関係を押さえずに、別々の開発作業として考えると理由を導きにくくなります。
• 障害対応による修正と、仕様変更によるテストのやり直しは、関連しますが別の問題です。どちらも挙げることで、混乱の内容を具体的に説明できます。

FAQ

解答の導き方

1. まず、不具合が起きる条件を特定します。本文には、「出力要求を行っている端末の台数が5台以上になると印刷処理の性能が急激に悪化する」とあります。問題となるのは、端末が5台以上あること自体ではなく、5台以上の端末から同時に出力要求が行われる状況です。
2. 一方、この不具合を除けば、5月からミドルソフトを使っても問題はない見込みです。そのため、結合テストを延期するのではなく、不具合が起きる条件をテストで避ければ、業務APの機能確認を進められます。
3. 具体的には、同時に出力要求を行う端末が5台以上にならないようにテストします。端末の同時使用を制限する方法でも、印刷処理の性能が急激に悪化する条件を避けられます。
4. 不具合に対応したミドルソフトでの機能確認は、別途設定された結合テスト2で行います。したがって、この設問では、5台以上の端末から同時に出力要求を行わないようテスト条件を工夫することがポイントです。

誤りやすいポイント

• 不具合の条件を「端末が5台以上設置されていること」と捉えないようにします。問題となるのは、5台以上の端末から同時に出力要求が行われることです。
• 不具合があるからといって、結合テスト全体を延期すると考えるのは適切ではありません。テストの実施条件を調整して、影響を受けない範囲で業務APの機能確認を進めます。
• 印刷機能をテストしない、という意味ではありません。問題となる同時出力の条件を避けて確認します。

FAQ

解答の導き方

1. 結合テストは5月に始める予定でしたが、ミドルソフトの不具合への対応が完了するのは6月中旬です。そのため、テスト開始時には対応前のミドルソフトを使い、対応完了後には修正版へ入れ替える状況になります。
2. ただし、テストの途中でミドルソフトを入れ替えると、入替えの前後でテスト環境の条件が変わります。入替え後に障害が起きた場合、それが業務APに起因するのか、ミドルソフトの変更や不具合に起因するのかを判別しにくくなります。
3. 本文でも、ミドルソフトを入れ替えると「結合テストで混乱が生じるおそれがある」としています。そこで、結合テストでは入れ替えず、対応済みのミドルソフトを使った機能確認は、別に設定した結合テスト2で行うことにしました。恐れていた混乱は、障害の原因を切り分けにくくなることです。

誤りやすいポイント

• ミドルソフトの不具合そのものを、設問が問う「混乱」と取り違えないようにします。問われているのは、テスト中に入れ替えた場合に起こり得るテスト上の混乱です。
• 「テストが遅れること」だけを答えるのは不十分です。本文では、入替えによって結合テストが混乱するおそれを理由にしています。
• 不具合の発生源が分かりにくくなる点を、業務APとミドルソフトのどちらに原因があるか判別しにくくなる、と具体化すると伝わりやすくなります。

FAQ

解答の導き方

誤りやすいポイント

• ミドルソフトの不具合を修正後に確認できることだけを理由にしないようにします。この設問で問われているのは、結合テスト2を総合テストの環境で行う効果です。
• 結合テスト2で業務APの機能確認を行うことと、総合テスト環境を事前確認することを混同しないようにします。環境を共用することで、環境の不具合や設定内容の問題を総合テスト前に確認できます。
• 「テストを早く始められるから」だけでは、環境を共用する理由が説明できていません。環境の不具合の発見や、設定内容の妥当性確認まで述べることが重要です。

FAQ

解答の導き方

1. まず、1次開発が何を作っているかを確認します。表1では、1次開発は「データ入力、マスタファイルの更新などのオンライン処理用の業務プログラム」を開発し、「入力項目は変えず」に現行システムより操作性を向上させるものです。つまり、現行システムのオンライン処理に関わる機能を、新システム側で作り直しています。
2. 次に、障害が起きた機能を確認します。本文では、現行システムで「昨年12月末の凍結直前に追加した機能」のうち、4月に初めて稼働した機能に「仕様の不備に伴う障害」が多発したとあります。現行システムのオンライン処理用の業務APについては、昨年12月末に機能追加を凍結しているため、障害が起きたのは、1次開発で作り直すオンライン処理と関係する機能だと考えられます。
3. さらに、本文は「障害が多発している機能について1次開発との関連を調べた結果」と述べています。したがって、単に現行システムで障害が発生しただけではなく、その機能の修正が1次開発にも関係すると分かったことが、リスクを懸念した根拠です。
4. 仕様の不備を直すには、対応する新システム側の仕様を見直す必要が生じる可能性があります。その影響が大きければ、1次開発の仕様に大きな影響が及ぶことがリスクになります。また、本文には「修正作業量が想定していたよりも多い」とあるため、障害対応を1次開発に取り込む工数が大きいことも、独立したリスクの表し方になります。
   この設問では、仕様への影響の大きさと、取込み工数の大きさは、どちらか一方を答えればよく、両方を同時に述べる必要はありません。

誤りやすいポイント

• 「現行システムで障害が多発したこと」だけを答えると、障害機能と1次開発の関係が示せません。1次開発が現行システムのオンライン処理に関わる機能を作り直すことと結び付けて考えます。
• 「結合テストの後半に対応すると危険」とだけ答えるのも不十分です。設問が尋ねているのは、その危険の説明ではなく、障害機能と1次開発との関連です。
• 仕様への影響と取込み工数を、必ず一つの解答に両方含めなければならないと思い込まないようにします。どちらも、本文から導ける別々の観点です。

FAQ

解答の導き方

誤りやすいポイント

• 「障害が多発している」ことだけに注目し、結合テストへの具体的な影響を説明しないと、リスクが明確になりません。
• 修正箇所だけを再確認すればよいと考えがちですが、修正の影響を受ける機能も再テストが必要になる場合があります。
• スケジュールの遅れだけでなく、手戻りによる進捗の遅れや、デグレードによる品質の劣化もリスクとして捉えます。

FAQ

解答の導き方

1. まず、B課長が変更した対応方針を確認します。障害対応を結合テストの後半にまとめて行うのではなく、「結合テストの初期の段階で障害対応の取込みを行う」としています。つまり、修正を早い段階で取り込み、その結果を結合テストで確認する方針です。
2. 次に、保守担当の責任者に追加で情報を依頼する理由を見ます。本文には「修正作業量が想定していたよりも多いので、障害対応の取込み結果を効率よく確認したい」とあります。修正仕様だけでは、修正を取り込んだ後に何を使って、どのように確認するかが分かりません。
3. そこで、修正結果の確認に使うデータの仕様、または確認に必要なテストケースを提供してもらえば、確認作業を効率化できます。したがって、求める情報は「修正結果の確認用データの仕様」や「修正結果の確認用のテストケース」に当たります。

誤りやすいポイント

• 障害の原因分析や類似障害の調査結果を答えにしないようにします。本文では、これらの調査はすでに済んでいると説明されています。
• 障害対応の修正仕様だけを答えにしないようにします。これは既に提供を受ける前提で、設問はそれに加えて必要な情報を尋ねています。
• 「効率よく確認する」という目的に注目します。修正後の動作を確認するためのデータやテストケースが必要だと考えます。

FAQ