プロジェクトマネージャ 2014年 午後1 問03
生産管理システムの再構築に関する次の記述を読んで、設問1～4に答えよ。
A社は、SI企業である。製造業のH社から、生産管理システムの再構築プロジェクト（以下、H社プロジェクトという）を受注することになり、現在、3月からの作業開始に向けて計画を策定している状況である。
H社の生産管理システムは、10年以上前に自社開発したシステムを過去数回にわたり改修してきたもの（以下、現システムという）である。これまで現システムを保守していた担当者が6月末で退職することもあり、自社で維持できなくなることから、外部のSI企業に再構築を委託することになった。再構築に当たっては、現システムの業務機能は変えずに、アーキテクチャを刷新した新しいシステム（以下、新システムという）へ移行したいとのことであった。また、生産実績の状況を照会できる拡張機能も開発したいとのことであった。新システムのイメージを図1に示す。
H社では、年末年始の休業の時期にしかシステムの移行ができないという制約があるので、開発期間は10か月である。H社プロジェクトのプロジェクトマネージャ（PM）には、生産管理システムの経験が豊富なA社のB氏が任命された。B氏は、A社の過去のプロジェクト完了報告書から、類似のシステムのスケジュールを参考にして、図2に示すH社プロジェクトのスケジュール案を作成した。
〔契約管理〕
B氏は、作成したスケジュール案を基に、H社プロジェクトのリスクについて検討を行った。H社の契約窓口からは、“新システムは、現システムの業務機能は変えずに、アーキテクチャを刷新するものであり、仕様が明確である。”との見解に基づき、全工程を請負契約で締結することを求められている。
B氏は、現システムの状況について現システムの保守担当者に確認した。現システムは、これまで10年以上にわたって運用されており、過去数回にわたり改修されてきたが、設計ドキュメントは初期のものが残っているだけで、改修履歴は反映されていないとのことであった。B氏は、H社プロジェクトでは、外部設計において、現システムの実際の仕様を十分に調査し、明確になった仕様に基づいて、外部設計書を新たに作成する必要があると考えた。
B氏は、H社の契約窓口の見解と現システムの状況にはギャップがあり、全工程を請負契約で締結することはリスクが大きいと考え、外部設計を委任契約、内部設計～総合テストを請負契約、移行支援を委任契約で締結する契約案を作成し、H社と協議を行うことにした。
〔プロジェクト計画〕
B氏は、プロジェクト計画書を作成するために、プロジェクトの遂行に必要な作業を洗い出した。外部設計が委任契約であることを前提に、全体の期間については参考として、内部設計～移行完了を外部設計完了後8か月で行う計画案を提示し、H社と打合せを行った。H社からは、移行は年末年始にしかできないので、来年初めからの稼働開始を確約してほしいとの強い要望があった。
B氏は、現時点ではA社ではコントロールできないリスクが存在し、稼働時期を確約することはできないことを説明し、理解を求めた。その上で、来年初めからの稼働開始に向けて、次の条件を提案した。
・外部設計書の確定を4月末とすること
・外部設計終了時に改めて再見積りを行い、内部設計以降の契約を締結すること
・“現システムの業務機能は変えず”という条件ではなく、aを条件として開発を進めること
協議の結果、来年初めからの新システム稼働開始を目標として作業を進めること、できる限り現システムの仕様を取り込むように開発を進めること、できるだけ業務に影響を与えずに新システムへ切り替えるために、移行・運用の方法を別途提案することを条件に、H社の承認を得て、H社プロジェクトは開始された。
〔調達管理〕
B氏は、A社の開発要員だけでは納期に間に合わないと考えたので、営業部門が使う拡張機能である実績照会機能の開発を外部へ委託することにし、H社プロジェクトの開発のチームリーダに、委託先を選定するよう指示した。チームリーダは、A社との付き合いが長く、A社の品質管理基準も理解しているX社に委託したいとのことであった。
B氏は、チームリーダの重視する委託先選定のポイントは適切と認める一方で、複数の委託先の候補から見積りをとることの意義を説明した。また、委託先選定の履歴を明確に文書で残すことの重要性を説明し、委託先選定に先立ち、提案依頼書（RFP）を作成するように指示した。そして、チームリーダに、評価基準として重視したいある条件を加えさせて、X社を含めた3社に対してRFPを出させた。
〔移行・運用方法の検討〕
B氏は、H社から要望された、できるだけ業務に影響を与えずに新システムへ切り替えるための移行・運用の方法を検討することにした。
B氏は、データを移行するプログラムの検証も含めて、総合テストの初期段階から本番データによる現システムとの処理結果の一致の確認を徹底して行うことにした。
しかしながら、B氏は、今回の開発の進め方を考慮すると、①総合テストで本番データによる現システムとの確認を徹底したとしても、新システムが現システムの全ての仕様を網羅しているという保証は得られないと考えた。そこで、運用の方法として、移行後も一連の月次処理を行う1か月の間、現システムと新システムを並行運用して、新システムのリスクに対応する必要があると考えた。さらに、B氏は、次の内容についてH社と合意をしておく必要があると考えた。
・新たに作成した外部設計書と新システムの実装機能の不整合は瑕疵として扱い、瑕疵担保責任の期間内であれば無償で修正を行う。
・現システムの仕様のうち外部設計で洗い出せなかった仕様が発見された場合は追加開発とし、別途見積りを行い、契約を締結して実施する。
B氏は、これらの内容を提案としてまとめ、H社に提示した。
設問1：
問題文を見る〔契約管理〕について、B氏は、H社の契約窓口の見解と現システムの状況にはギャップがあり、全工程を請負契約で締結することはリスクが大きいと考えた。そのギャップとは何か。また、リスクとは何か。それぞれ40字以内で述べよ。
模範解答
ギャップ：仕様が明確という見解と設計ドキュメントに改修履歴が反映されていない状況
リスク：改修で変更された機能が実装されず手戻りが発生して納期に遅れること
解説
解答の導き方
まず、H社の契約窓口が「仕様が明確」と考えている根拠を確認します。H社は、現システムの業務機能を変えず、アーキテクチャを刷新することから、仕様は明確だと見ています。
一方、B氏が保守担当者に確認したところ、現システムは10年以上にわたって運用され、改修も行われていますが、「設計ドキュメントは初期のものが残っているだけで、改修履歴は反映されていない」という状況でした。つまり、H社は仕様が明確だと見ているのに対し、実際には資料から現システムの現在の仕様を正確に把握できるとは限りません。この認識の差が、設問で問われているギャップです。
次に、その状況で全工程を請負契約にした場合のリスクを考えます。設計ドキュメントに記録されていない改修内容を見落とすと、現システムで使われている機能が新システムに実装されない可能性があります。開発後にその差が発見されれば、設計や実装をやり直す手戻りが生じ、納期に影響します。このため、リスクは、改修で変更された機能が実装されず、手戻りによって納期が遅れることだと判断できます。
誤りやすいポイント
- 「業務機能を変えない」という要望と、「現システムの仕様が明確である」という判断を同じものとして扱わないようにします。機能を変えない方針でも、現行の実際の仕様が資料から把握できるとは限りません。
- ギャップを「設計ドキュメントが古いこと」だけで終わらせないようにします。設問が問うているのは、H社側の見解と、資料に改修履歴が反映されていない実態との食い違いです。
- リスクを「仕様が不明確なこと」だけで述べると、具体的な影響が不足します。未実装の機能が後から判明し、手戻りや納期遅延につながるところまで押さえます。
- 「追加費用が発生すること」だけをリスクとして挙げるのも不十分です。模範解答では、機能が実装されないことによる手戻りと納期への影響が焦点です。
FAQ
Q: 業務機能を変えないのであれば、現システムの仕様も明確だと考えてよいのですか。
A: いいえ。維持したい機能の方針と、現在のシステムが実際にどのように動いているかを把握できているかは別です。改修履歴が資料に反映されていなければ、現行の仕様を調査する必要があります。
A: いいえ。維持したい機能の方針と、現在のシステムが実際にどのように動いているかを把握できているかは別です。改修履歴が資料に反映されていなければ、現行の仕様を調査する必要があります。
Q: なぜ機能の見落としが納期遅延につながるのですか。
A: 開発後に現システムとの違いが見つかると、設計や実装を修正し、必要に応じてテストもやり直すことになります。その手戻りがスケジュールを圧迫するためです。
A: 開発後に現システムとの違いが見つかると、設計や実装を修正し、必要に応じてテストもやり直すことになります。その手戻りがスケジュールを圧迫するためです。
Q: 外部設計を委任契約にすることには、どのような意味がありますか。
A: この問題では、現システムの実際の仕様を調査して外部設計書を作る必要があります。まず仕様を明確にしてから内部設計以降の契約を結ぶことで、未確定の仕様を前提に後続工程の契約を確定するリスクを抑えられます。
A: この問題では、現システムの実際の仕様を調査して外部設計書を作る必要があります。まず仕様を明確にしてから内部設計以降の契約を結ぶことで、未確定の仕様を前提に後続工程の契約を確定するリスクを抑えられます。
関連キーワード: 請負契約、委任契約、設計ドキュメント、仕様の不確実性、手戻り
設問2：
問題文を見る〔プロジェクト計画〕について、B氏が外部設計終了時に改めて再見積りを行い、内部設計以降の契約を締結するために提示した条件aはどのような内容か。35字以内で述べよ。
模範解答
a：新たに作成した外部設計書に基づいて新システムの開発を行うこと
解説
解答の導き方
-
まず、なぜ外部設計終了時に再見積りをするのかを確認します。現システムは長期間運用され、改修も重ねていますが、「設計ドキュメントは初期のものが残っているだけで、改修履歴は反映されていない」とあります。そのため、開発開始時点では現システムの実際の仕様を十分に把握できていません。
-
B氏は、外部設計で現システムの実際の仕様を調査し、明確になった仕様に基づいて外部設計書を新たに作成する必要があると考えています。つまり、外部設計を通じて、開発対象となる仕様を明らかにする計画です。
-
一方、H社は「現システムの業務機能は変えずに」再構築することを望んでいます。しかし、実際の仕様が分からないまま、その機能を完全に維持すると約束するのは困難です。そこで、開発の前提を、あらかじめ現システムの全機能を維持するとするのではなく、外部設計で作成・確定した文書に定められた仕様に置きます。
-
外部設計の完了後に、その文書に基づいて内部設計以降の作業を再見積りし、契約する流れです。したがって、条件aは、新たに作成した外部設計書を開発の基準とすることです。
誤りやすいポイント
- 「できる限り現システムの仕様を取り込むこと」を条件aの答えにしないようにします。これは協議後の方針ですが、条件aが示す開発の基準は、新たに作成する外部設計書です。
- 「外部設計書の確定を4月末とすること」は、日程に関する条件です。問われているのは、開発をどの仕様に基づいて進めるかです。
- 「現システムの業務機能を変えないこと」と答えると、H社の当初の要望を繰り返すことになります。本文では、その要望どおりの仕様を事前に確定できないため、外部設計書を基準とする条件に改めています。
FAQ
Q: なぜ外部設計が終わってから再見積りをするのですか？
A: 外部設計で開発対象の仕様を明らかにしてから、その仕様に基づいて内部設計以降の作業量や費用を見積もるためです。
A: 外部設計で開発対象の仕様を明らかにしてから、その仕様に基づいて内部設計以降の作業量や費用を見積もるためです。
Q: この条件は、現システムの機能を引き継がなくてもよいという意味ですか？
A: いいえ。現システムの仕様をできる限り取り込む方針はありますが、開発範囲を明確にする基準を、新たに作成した外部設計書に置くという意味です。
A: いいえ。現システムの仕様をできる限り取り込む方針はありますが、開発範囲を明確にする基準を、新たに作成した外部設計書に置くという意味です。
関連キーワード: 外部設計、仕様確定、再見積り、請負契約、委任契約
設問3：〔調達管理〕について、(1)、(2)に答えよ。
設問3（1）
問題文を見るB氏が説明した、複数の委託先の候補から見積りをとることの意義とは何か。20字以内で述べよ。
模範解答
・委託先の客観的な評価ができる。
・調達コストを適正にできる。
解説
解答の導き方
-
問われているのは、複数の委託先候補から見積りを取ることで、委託先の選定にどのような利点があるかです。
-
本文では、チームリーダが「A社との付き合いが長く、A社の品質管理基準も理解しているX社」に委託したいと考えています。B氏はその選定ポイントを認めつつ、候補を複数にして見積りを取る意義も説明しています。つまり、付き合いの長さだけで決めず、複数の候補を比較することが重要です。
-
見積りを比較すると、各候補の提案や費用を同じ観点から確認できるため、委託先を客観的に評価できます。また、費用の違いを比較することで、調達コストが適正かどうかを判断しやすくなります。
誤りやすいポイント
- 「最も安い委託先を選べること」だけを意義として答えると、委託先を比較・評価する利点を捉えきれていません。
- 見積りを取る目的を「候補を増やすこと」とだけ捉えないようにします。重要なのは、候補を比較して選定の客観性と費用の妥当性を高めることです。
- X社の品質管理基準への理解は、チームリーダが重視する選定ポイントです。設問が尋ねている、複数の見積りを取る意義とは分けて考えます。
FAQ
Q: 見積金額が最も低い候補を選ぶことが、複数の見積りを取る目的ですか？
A: いいえ。金額の比較は調達コストの適正さを判断する助けになりますが、それだけでなく、候補を客観的に評価することにも意義があります。
A: いいえ。金額の比較は調達コストの適正さを判断する助けになりますが、それだけでなく、候補を客観的に評価することにも意義があります。
Q: 付き合いの長い委託先がいる場合も、複数の候補から見積りを取る必要がありますか？
A: 本文では、X社を候補に含めつつ、他の候補からも見積りを取っています。比較することで、選定の客観性と費用の妥当性を確かめられます。
A: 本文では、X社を候補に含めつつ、他の候補からも見積りを取っています。比較することで、選定の客観性と費用の妥当性を確かめられます。
Q: 見積りを取るだけで、委託先選定の記録として十分ですか？
A: 十分とは限りません。本文では、選定履歴を文書で残すことも重視しています。見積りの比較と、その結果や判断の記録は別の観点です。
A: 十分とは限りません。本文では、選定履歴を文書で残すことも重視しています。見積りの比較と、その結果や判断の記録は別の観点です。
関連キーワード: 相見積り、委託先選定、評価基準、調達コスト、RFP
設問3（2）
問題文を見るB氏が加えさせた、評価基準として重視したいある条件とは何か。25字以内で述べよ。
模範解答
・A社と同様の品質管理基準を有していること
・品質に関するA社の検収条件を満たすこと
解説
解答の導き方
この設問では、委託先を評価する際に、B氏が追加させた条件を考えます。
まず、チームリーダがX社を候補にした理由は、「A社との付き合いが長く、A社の品質管理基準も理解している」ことです。B氏は、この選定のポイント自体は適切だと認めています。したがって、追加する条件も、委託先の品質を確保できるかどうかに関係すると考えられます。
一方、B氏はX社だけに委託先を決めるのではなく、複数の候補から見積りを取り、選定の経緯を文書に残そうとしています。そのため、評価基準は、候補となる各社に共通して適用でき、提案内容を比較できる形で示す必要があります。
実績照会機能の開発を委託するに当たっては、委託先がA社のプロジェクトで求められる品質を確保できることが重要です。具体的には、A社と同等の品質管理基準を備えているか、または品質面でA社の検収条件を満たせるかを評価する条件が考えられます。これらは、委託先の品質管理能力を判断するための条件です。
誤りやすいポイント
- X社との付き合いの長さを、追加された評価条件と取り違えないようにします。これは、チームリーダがX社を候補に挙げた理由です。
- 「A社の品質管理基準を理解していること」だけにとどめず、委託先がその基準に沿って品質を確保できるかという観点で考えます。
- 価格や納期を答えると、設問が求める品質に関する条件から外れます。
FAQ
Q: なぜ委託先の品質管理基準を評価する必要があるのですか？
A: 委託した機能もH社プロジェクトの成果物となるため、プロジェクト全体で求める品質を確保できる委託先かどうかを確認する必要があるからです。
A: 委託した機能もH社プロジェクトの成果物となるため、プロジェクト全体で求める品質を確保できる委託先かどうかを確認する必要があるからです。
Q: 「同様の品質管理基準」と「検収条件を満たすこと」は、どのように関係しますか？
A: いずれも、委託先がA社の品質面の要求に対応できることを確認する観点です。前者は委託先の品質管理の仕組み、後者は成果物が受入れの条件を満たすかに着目しています。
A: いずれも、委託先がA社の品質面の要求に対応できることを確認する観点です。前者は委託先の品質管理の仕組み、後者は成果物が受入れの条件を満たすかに着目しています。
Q: RFPに評価条件を含めるのはなぜですか？
A: 候補各社に同じ条件を示し、提案を共通の基準で比較できるようにするためです。
A: 候補各社に同じ条件を示し、提案を共通の基準で比較できるようにするためです。
関連キーワード: RFP、委託先選定、評価基準、品質管理、検収条件
設問4：〔移行・運用方法の検討〕について、(1)、(2)に答えよ。
設問4（1）
問題文を見るB氏が、本文中の下線①のように考えた理由は何か。40字以内で述べよ。
模範解答
本番データが現システムの全テストケースをカバーしているわけではないから
解説
解答の導き方
-
まず、現システムの仕様を完全には把握できていない可能性があります。本文には、設計ドキュメントは初期のものだけで、「改修履歴は反映されていない」とあります。そのため、外部設計で実際の仕様を調査しても、すべての仕様を洗い出せるとは限りません。
-
次に、総合テストでは「本番データによる現システムとの処理結果の一致」を確認します。この確認によって、本番データを使った処理について、新旧システムの結果が一致するかを確かめられます。
-
ただし、本番データに含まれるのは、実際に発生したデータや条件です。現システムで起こり得るすべての入力パターンや条件が、本番データに現れているとは限りません。したがって、本番データで処理結果が一致しても、テストされていない条件に関する仕様まで、新システムが実装しているとは確認できません。
このため、下線①の理由は、本番データが現システムの全テストケースをカバーしているわけではないから、と判断できます。
誤りやすいポイント
- 本番データを使えば、実際の利用状況を確認できるため、すべての仕様を検証できると思い込むことです。本番データで確認できるのは、あくまでそのデータが通る処理です。
- 新旧システムの処理結果が一致したことを、すべての仕様が一致したことと同じだと考えることです。テストしていない条件の仕様までは確認できません。
- データ移行プログラムの検証と、現システムの全仕様の確認を混同することです。移行したデータを正しく処理できても、全ての仕様が網羅されたとは限りません。
FAQ
Q: 本番データを使った総合テストには、どのような意義がありますか？
A: 実際に使われているデータを新旧システムで処理し、処理結果や移行後の動作を比較できることです。ただし、それだけで全ての仕様を確認できるわけではありません。
A: 実際に使われているデータを新旧システムで処理し、処理結果や移行後の動作を比較できることです。ただし、それだけで全ての仕様を確認できるわけではありません。
Q: 本番データでの確認を徹底しても、なぜ並行運用が必要なのですか？
A: テストでは現れなかった仕様の違いが、実際の運用で判明する可能性があるためです。並行運用によって、新システムの処理結果を現システムと比較し、差異があれば把握できます。
A: テストでは現れなかった仕様の違いが、実際の運用で判明する可能性があるためです。並行運用によって、新システムの処理結果を現システムと比較し、差異があれば把握できます。
関連キーワード: 本番データ、テストケース、テスト網羅性、総合テスト、並行運用
設問4（2）
問題文を見るB氏が、H社に提示した提案で、移行後も現システムと新システムの並行運用を行うことで対応するとした、新システムのリスクとは何か。また、その対応策とは何か。それぞれ20字以内で述べよ。
模範解答
リスク：
・実装が漏れている機能が発見される。
・処理結果に不一致が発見される。
対応策：
・現システムの処理結果を使う。
・現システムに切り戻す。
解説
解答の導き方
-
まず、並行運用を行う理由を確認します。本文では、総合テストで本番データを使って現システムとの確認を徹底しても、「新システムが現システムの全ての仕様を網羅しているという保証は得られない」としています。したがって、稼働後に初めて、現システムの機能が新システムに実装されていないことが分かる可能性があります。
-
また、機能が実装されていても、同じデータを処理したときに現システムと新システムで結果が異なる可能性があります。よって、並行運用で備えるリスクは、実装漏れの発見と処理結果の不一致の発見です。
-
次に、対応策を考えます。現システムと新システムを並行して動かすのは、問題が起きたときに現システムを利用できるようにするためです。処理結果が異なる場合は現システムの処理結果を使い、新システムで業務を続けるのが難しい場合は現システムに切り戻します。
誤りやすいポイント
- 「並行運用すること」自体を対応策として書くだけでは不十分です。設問は、並行運用によって対応する具体的なリスクと、そのときの対応策を尋ねています。
- リスクを「新システムに不具合がある」とだけ書くと、具体性が不足します。実装漏れと処理結果の不一致に分けて考えます。
- 処理結果に不一致があった場合の対応と、新システムの運用継続が難しい場合の対応を混同しないようにします。前者では現システムの処理結果を使い、後者では現システムへ切り戻します。
FAQ
Q: 並行運用をすれば、新システムの仕様漏れがなくなるのですか？
A: 仕様漏れをなくす保証にはなりません。稼働後に漏れや不一致が判明した場合に、現システムを使って業務への影響を抑えるための運用です。
A: 仕様漏れをなくす保証にはなりません。稼働後に漏れや不一致が判明した場合に、現システムを使って業務への影響を抑えるための運用です。
Q: 処理結果を使うことと、切り戻すことはどう違いますか？
A: 処理結果を使うのは、現システムと新システムで結果が異なった場合に、現システムの結果を業務に用いる対応です。切り戻しは、新システムから現システムへ運用を戻す対応です。
A: 処理結果を使うのは、現システムと新システムで結果が異なった場合に、現システムの結果を業務に用いる対応です。切り戻しは、新システムから現システムへ運用を戻す対応です。
Q: なぜ総合テストだけでは十分ではないのですか？
A: テストを徹底しても、現システムの全ての仕様を新システムが網羅していると保証できないためです。実際の運用で初めて判明するリスクに備えて、並行運用を行います。
A: テストを徹底しても、現システムの全ての仕様を新システムが網羅していると保証できないためです。実際の運用で初めて判明するリスクに備えて、並行運用を行います。
関連キーワード: 並行運用、切戻し、総合テスト、処理結果照合、レガシーシステム
