平成23年度特別 プロジェクトマネージャ 午後Ⅰ 問3

判断の前提をそろえて考える

計画やリスクを考える際は、判断の前提がそろっているかという一点に注目しましょう。示された情報と自分で補った想定を区別し、どの条件に基づいて考えているのかを意識すると、思い込みを避けやすくなります。

この問題で問われていること

検討の対象が変わっても、根拠となる条件を無意識に置き換えないことが大切です。気になる判断について、その前提が与えられた情報に含まれるのか、自分の経験から付け足したものなのかを確かめてみましょう。

視点

判断を支える条件に目を向けましょう。普段の経験から思い浮かぶ条件も、今回示された条件とは分けて扱うと、前提を整理しやすくなります。

確認ポイント

• 判断の根拠となる条件を意識できているか
• 示された条件と自分で補った想定を区別できているか
• 考える途中で前提を無意識に置き換えていないか

解説

本問は、現行システムと並行する開発の状況を踏まえ、再構築の期限と品質を両立させる問題です。仕様の凍結、開発工程の依存関係、テスト環境の事前確認、障害修正の早期取込みを、それぞれ軽減するリスクと結び付けて理解します。

問題の全体像

金融機関のA社は、来年６月末のハードウェア保守期限に合わせて審査システムを再構築しています。１次開発でオンライン処理を移し、２次開発でバッチ処理などを開発する一方、ミドルソフトは別プロジェクトで開発しています。さらに、来年７月の審査基準改定への対応も必要です。こうした期限と依存関係の下で、ミドルソフトの不具合や現行システムの障害にどう対応するかが問われます。公式の出題趣旨では、関連システムの開発・稼働状況を考慮した計画立案、品質確保、リスク軽減などの実践的な能力を問うとしています。各設問では、対策そのものと、その対策で避けたい問題を対応させて読み取ります。

設問1(1)

着目するのは、総合テストで「１日当たり数千件」の入力データを数日分扱う点です。大量のデータを手入力すると、入力作業に時間が掛かるだけでなく、入力ミスの確認や訂正が必要になり、予定したテストが進みにくくなります。公式解答例では「総合テストが予定どおりに進まない」「入力ミスによる手戻りが発生する」を挙げています。20字以内では、例えば「入力ミスによる手戻りが発生する」と、混乱の内容を具体的に表します。変換ツールの開発は、この入力作業に起因する混乱を避けるための対策です。

設問1(2)

下線①の機能追加の凍結は、新システムが引き継ぐ現行機能の仕様を安定させる措置です。新システムの設計・開発中に現行システムへ機能が追加されると、開発の前提が変わり、新システムの仕様と現行機能との間に相違が生じるおそれがあります。公式解答例では「現行機能との仕様の相違が発生する」「現行機能が保証できない」を挙げています。20字以内では「現行機能との仕様の相違が発生する」とまとめられます。採点講評では、二重開発による作業量の増加に着目した解答が多かったとされていますが、ここで求められているのは、現行システムから提供される機能との不一致というリスクです。

設問1(3)

表１では、２次開発のオンライン処理は、１次開発で作った業務プログラムを修正して進めるとされています。このため、１次開発の結合テストで障害や仕様変更が発生すると、その影響が２次開発にも及びます。２次開発の製造・単体テストを既に進めていれば、修正の取込みやテストのやり直しが必要になります。公式解答例では、１次開発の障害対応による手戻りの多発、又は仕様変更による単体テストのやり直しを挙げています。30字以内では「１次開発の障害に対応するための手戻りが多発する」と表せます。７月まで着手を待つのは、修正元となる１次開発の品質を安定させるためです。

設問2(1)

不具合の発生条件は、出力要求を行っている端末が５台以上になることです。また、本文には、この不具合を除けば５月からミドルソフトを使用しても問題はない見込みとあります。したがって、結合テストでは同時に出力要求を行う端末数を制限することで、不具合の条件を避けながら業務APの機能確認を進められます。公式解答例では「５台以上の端末から同時に出力要求を行わない」などを挙げています。30字以内では、この発生条件と回避方法をそのまま示します。不具合を修正したミドルソフトでの確認は、別途設定する結合テスト２で行います。

設問2(2)

着目するのは、結合テストの途中でミドルソフトを入れ替えるという変更です。業務APを確認している最中に、その動作を支えるミドルソフトも変えると、障害が起きた際に業務APとミドルソフトのどちらに原因があるのかを判断しにくくなります。公式解答例では「障害の原因の切分けが難しくなること」、又はミドルソフトに関する不具合の発生を挙げています。20字以内では「障害の原因の切分けが難しくなること」とまとめられます。結合テストではミドルソフトを固定し、修正版の確認を結合テスト２に分ける方針を、原因の切分けという観点で捉えます。

設問2(3)

総合テストの環境を使って、先に結合テスト２を実施する点が根拠です。実際に業務APを動かすことで、その環境に不具合がないか、設定内容が適切かを総合テスト開始前に確認できます。公式解答例では、総合テスト環境の不具合を事前に摘出できること、又は設定内容の妥当性を事前に確認できることを挙げています。30字以内では「総合テストの環境の不具合が事前に摘出できるから」と表せます。採点講評では、結合テスト自体のメリットを書いた誤答が多かったとされています。答案では、総合テストの環境を先に検証できる効果を明確にします。

設問3(1)

設問が求めるのは、現行システムの障害と１次開発との関連です。１次開発は現行のオンライン機能を引き継ぐため、現行機能の仕様不備に対する修正は、新システムにも取り込む必要があります。本文の「修正作業量が想定していたよりも多い」という記述にも着目します。公式解答例では「１次開発の仕様に大きな影響があること」「１次開発への取込みの工数が大きいこと」を挙げています。20字以内では「１次開発の仕様に大きな影響があること」とまとめられます。障害が多発しているという事実だけでなく、その修正が１次開発に大きく波及する点を答えます。

設問3(2)

大きな修正を結合テストの後半にまとめて取り込むと、それまでの確認結果に影響し、修正後の確認や再テストが必要になります。残り期間が少ない段階で手戻りが生じれば、結合テストの完了が遅れるおそれがあります。また、修正によって、それまで正常だった機能に不具合が生じる可能性もあります。公式解答例では、結合テスト完了の遅延、手戻りによる進捗の遅延、デグレードによる品質の劣化を挙げています。20字以内では「手戻りの発生による進捗の遅延」と表せます。設問3(1)の大きな影響・工数を原因とし、本設問ではその結果としてのリスクを答えます。

設問3(3)

修正仕様は、何を直すかを示す情報ですが、取込み結果を効率よく確認するには、どのようなデータや条件で確認するかという情報も必要です。現行システム側では既に原因分析と類似障害の調査が済んでいるため、その知見を確認作業に利用することが考えられます。公式解答例では「修正結果の確認用データの仕様」「修正結果の確認用のテストケース」を挙げています。20字以内では「修正結果の確認用のテストケース」と答えられます。単に障害の説明を追加で求めるのではなく、修正が正しく取り込まれたかを確認するための具体的な情報に着目します。

学習のポイント

リスクの原因と結果を区別し、変更の波及先、テストの目的、障害対応に必要な確認情報を具体的に説明する力を養います。