【ITパスポート練習問題 6.3対応】24.調達計画・実施

【解説】

正解: 2 システムの目的や全体像を明らかにする

この問題は、システム開発の最上流工程である「システム企画」がどのような役割を持つプロセスかを理解しているかを確認するものです。

正解は2の「システムの目的や全体像を明らかにする」です。システム企画では、経営戦略に基づいて、「なぜシステムを作るのか（目的）」「どのような業務を対象とするのか（範囲）」「どの程度の費用と期間をかけるか（全体像）」といった基本構想を策定します。これが後続の設計や開発の土台となります。

選択肢1の「企業の経営戦略に関係なく」という記述は誤りです。システムは経営目標を達成するための手段であり、経営戦略との整合性が不可欠です。選択肢3の「導入したシステムの保守のみを行う」は、システムが完成した後の「運用・保守プロセス」の説明であり、企画段階の活動ではありません。

【解説】

正解: 3 ソフトウェアのコーディング

この問題は、システム開発における「上流工程（企画・要件定義）」と「下流工程（実装・製造）」の区別がついているかを確認するものです。

正解の3「ソフトウェアのコーディング」は、プログラミング言語を使って実際にプログラムを作成する作業であり、開発（製造）工程で行われます。システム企画は、これよりずっと前の段階で「何を作るか」を構想するフェーズなので、コーディングは含まれません。

選択肢1の「要件定義」や選択肢2の「リスク評価」は、どのようなシステムが必要か、どのようなリスクがあるかを検討する活動であり、企画プロセスやその直後の工程で実施される重要な要素です。

【解説】

正解: 2 システム導入に伴うリスクを分析し管理するため

この問題は、プロジェクトの初期段階で行う「リスクマネジメント」の重要性と目的を理解しているかを問うものです。

正解は2の「システム導入に伴うリスクを分析し管理するため」です。新しいシステムを導入する際には、技術的な課題、コストの超過、スケジュールの遅延など様々なリスクが伴います。企画段階でこれらを洗い出し、事前に対策を検討しておくことで、プロジェクトの失敗を防ぎ、計画の実現性を高めることができます。

選択肢1の「プロジェクトの進捗を早めるため」はリスク評価の直接的な目的ではありません（結果的に手戻りが減って早まることはあっても、早めること自体が目的ではありません）。選択肢3の「経営戦略を変えるため」も不適切です。リスク評価は計画を実行するための活動であり、戦略そのものを変更するためのものではありません。

【解説】

正解: 1 調達活動を管理するための枠組みを作ること

この問題は、システム開発に必要な製品やサービスを外部から手配する際の「調達計画」の定義を理解しているかを確認するものです。

正解は1の「調達活動を管理するための枠組みを作ること」です。調達計画プロセスでは、何を外部から調達するか、どのような契約形態（請負、委任など）にするか、いつ頃調達するかといった調達の全体的なルールやスケジュールを決定します。

選択肢2の「システム開発に必要なプログラムを書くこと」は開発工程の活動です。選択肢3の「業務フローを分析すること」は要件定義や業務分析の活動であり、調達計画の主な目的とは異なります。

【解説】

正解: 3 システムの要件定義

この問題は、システム開発の流れにおいて「要件定義」と「調達計画」がどのような関係にあるかを理解しているかを問うものです。

正解は3の「システムの要件定義」です。要件定義は、ユーザーがシステムに求める機能や性能を明確にする活動であり、通常は調達を行うための前提条件となります（何が欲しいかが決まっていないと、調達できないため）。したがって、調達計画プロセスの中で要件定義を行うわけではありません。

選択肢1の「調達スケジュールの作成」や選択肢2の「調達先の選定（に向けた基準作りなど）」は、調達計画プロセスで実施すべき中心的な活動です。

【解説】

正解: 2 効率的な資源調達とコスト削減

この問題は、企業活動における調達計画の経営的な意義（QCDの観点）を理解しているかを確認するものです。

正解は2の「効率的な資源調達とコスト削減」です。調達計画では、適切な時期に適切な価格で必要なリソース（ハードウェア、ソフトウェア、人材など）を確保することを目指します。無駄なコストを省き、プロジェクトの予算内で最大限の効果を得ることが重視されます。

選択肢1の「プログラムの詳細な設計」は内部設計や詳細設計の工程で行う技術的な作業です。選択肢3の「システム保守の体制」は運用設計の範疇であり、調達計画で最も重視されるポイントではありません。

【解説】

正解: 1 製品の環境負荷の低さ

この問題は、企業の社会的責任（CSR）や環境経営の一環として行われる「グリーン調達」の定義を理解しているかを問うものです。

正解は1の「製品の環境負荷の低さ」です。グリーン調達とは、製品や部品、材料などを調達する際に、品質や価格だけでなく、環境への影響を考慮して、環境負荷ができるだけ小さいもの（省エネ、リサイクル可能、有害物質を含まないなど）を優先的に選ぶ取り組みです。

選択肢2の「製品のデザインの美しさ」や、選択肢3の「調達コストの上昇」は、グリーン調達が重視する本質的な基準ではありません。

【解説】

正解: 2 環境保護や持続可能な社会の実現のため

この問題は、なぜ企業がグリーン調達に取り組む必要があるのか、その背景にある「サステナビリティ（持続可能性）」の概念を理解しているかを確認するものです。

正解は2の「環境保護や持続可能な社会の実現のため」です。地球温暖化や資源の枯渇といった環境問題に対応するため、企業にはサプライチェーン全体で環境負荷を減らすことが求められています。グリーン調達はそのための具体的な手段の一つです。

選択肢1の「短期的な利益を追求するため」は誤りです。環境配慮型製品は初期コストが高くなる場合もあり、短期利益よりも長期的な社会貢献や企業価値向上を重視する取り組みです。選択肢3の「市場での競争力を下げるため」も誤りで、むしろ環境対応は競争力の源泉となりつつあります。

【解説】

正解: 1 再生可能資源を使用した製品の調達

この問題は、グリーン調達の具体的な事例を識別できるかを確認するものです。

正解は1の「再生可能資源を使用した製品の調達」です。再生プラスチックを使った事務用品や、森林認証を受けた紙の購入などがこれに該当します。資源の循環利用を促進し、環境への悪影響を減らす活動です。

選択肢2の「石油製品の大量購入」や、選択肢3の「廃棄物の増加を促す取引」は、環境負荷を高める行動であり、グリーン調達の理念とは正反対です。

【解説】

正解: 2 データの権利と取り扱いに関する取り決め

この問題は、AI技術をビジネスに導入する際に重要となる「契約ガイドライン（経済産業省などが策定）」のポイントを理解しているかを問うものです。

正解は2の「データの権利と取り扱いに関する取り決め」です。AI開発では、学習用データの提供や、生成された学習済みモデルの権利帰属が複雑になりがちです。そのため、誰がデータを提供し、そのデータや成果物をどう利用してよいかを契約で明確にしておくことが特に重視されます。

選択肢1の「AI開発のコスト削減」は契約ガイドラインの目的ではありません。選択肢3の「AIによる全ての業務の自動化」は技術的な目標のレベルであり、契約ガイドラインの主題ではありません。

【解説】

正解: 3 データの無制限使用の許可

この問題は、データの適正な利用に関するコンプライアンス意識を確認するものです。

正解は3の「データの無制限使用の許可」です。これは契約ガイドラインの内容として不適切です。個人情報保護や営業秘密管理の観点から、データの利用目的や範囲を明確に限定する必要があります。「無制限」としてしまうと、予期せぬ流出や不正利用のリスクが高まるため、適切な契約とは言えません。

選択肢1の「AIの出力に関する責任分担」や、選択肢2の「データ利用の範囲に関する合意」は、トラブルを避けるためにガイドラインで定めるべき正しい内容です。

【解説】

正解: 2 出力結果に関する責任分担を明確に契約で取り決める

この問題は、AI特有の「不確実性」を踏まえた契約実務の知識を問うものです。

AIは確率的に結果を出力するため、100%の精度を保証することが難しく、出力結果によって損害が生じた場合の責任の所在が問題になりやすい性質があります。

そのため、正解は2の「出力結果に関する責任分担を明確に契約で取り決める」となります。どちらか一方が全ての責任を負うと決めるのではなく、どのような場合に誰が責任を負うかを事前に協議し、合意形成しておくことが重要です。選択肢1や3のように、一方的に責任を押し付ける考え方はトラブルのもとであり、適切ではありません。

【解説】

正解: 1 製品やサービスに関する情報収集

この問題は、システム調達の初期段階で使用される文書「RFI（Request For Information：情報提供依頼書）」の目的を理解しているかを問うものです。

正解は1の「製品やサービスに関する情報収集」です。発注側がまだ要件を固めきれていない段階で、ベンダーに対して「御社はどのような技術や実績を持っていますか？」「一般的にどのような製品がありますか？」といった広範な情報を問い合わせるために使用します。

選択肢2の「契約書の締結」は最終段階の活動です。選択肢3の「製品のテスト運用」は選定中や導入前に行う活動であり、RFIの段階ではありません。

【解説】

正解: 2 市場調査を行う初期段階

この問題は、システム調達プロセスにおけるRFIの実施タイミングを正しく理解しているかを確認するものです。

正解は2の「市場調査を行う初期段階」です。RFIは、具体的な提案を依頼する「RFP（提案依頼書）」を作成するための基礎情報を集める手段として使われます。したがって、まだ詳細が決まっていないプロジェクトの開始直後や調査フェーズで実施するのが最も適切です。

選択肢1の「契約交渉の直後」や選択肢3の「システムの導入後」では、情報収集のタイミングとして遅すぎます。

【解説】

正解: 3 提供される情報の評価

この問題は、RFIを実施した後に発注側が行うべき活動を理解しているかを問うものです。

正解は3の「提供される情報の評価」です。ベンダーから回答があった情報を整理・分析し、「どの技術が使えそうか」「どのベンダーが有力そうか」「実現可能性はどの程度か」を評価します。この結果をもとにして、次のステップであるRFP（提案依頼書）の作成や、調達要件の絞り込みを行います。

選択肢1の「システムの保守作業」や選択肢2の「価格交渉」は、システムが稼働した後や、具体的な提案が出た後の活動です。

【解説】

正解: 2 提案内容の評価基準

この問題は、発注者がベンダーに提示する「RFP（Request For Proposal：提案依頼書）」に記載すべき重要事項を理解しているかを問うものです。

正解は2の「提案内容の評価基準」です。RFPには、システムの要件だけでなく、「どのような観点で提案を評価し、選定するか」という基準を明記することが望ましいとされます。これにより、ベンダーは発注者が重視するポイントに沿った的確な提案を作成でき、公平な選定が可能になります。

選択肢1の「ベンダーの決定通知」は選定後の通知です。選択肢3の「契約後のトラブル対応」は、契約書やSLA（サービスレベル合意書）で定める内容です。

【解説】

正解: 3 具体的な提案を得てベンダーを選定すること

この問題は、RFPを発行する最終的なゴール（目的）を理解しているかを確認するものです。

正解は3の「具体的な提案を得てベンダーを選定すること」です。RFPは、発注者の要件（やりたいこと）を具体的に伝え、それに対する解決策（ソリューション）、費用、スケジュールなどの提案をベンダーに要求する文書です。集まった提案書を比較検討し、最も適した発注先を決めるために使用します。

選択肢1の「ベンダーとの長期契約を結ぶこと」は結果の一つかもしれませんが、RFP自体の目的は提案を集めることです。選択肢2の「提案内容を保留にすること」は目的として不適切です。

【解説】

正解: 2 必要な要件や成果物を明確にする

この問題は、RFP作成時の品質がその後のプロジェクトに与える影響を理解しているかを確認するものです。

正解は2の「必要な要件や成果物を明確にする」です。RFPに記載された要件が曖昧だと、ベンダーごとの解釈がバラバラになり、提案内容の比較ができなくなったり、導入後に「欲しかった機能がない」といったトラブルが発生したりします。何を求めているかを明確に伝えることが重要です。

選択肢1の「曖昧な仕様を記載する」はトラブルの原因となる避けるべき行為です。選択肢3の「提案の締切を設けない」と、スケジュール管理ができなくなるため不適切です。

【解説】

正解: 1 ソリューションの概要と提供体制

この問題は、ベンダーが提出する「提案書」に記載すべき構成要素を理解しているかを問うものです。

正解は1の「ソリューションの概要と提供体制」です。提案書には、発注者の課題をどのように解決するかというシステム案（ソリューション）、開発スケジュール、費用見積もりに加え、プロジェクトマネージャや開発メンバーなどの「実施体制」を記載します。これにより、発注者はそのベンダーに実現能力があるかを判断します。

選択肢2の「発注者の企業理念」は、発注側がRFPに書くものであり、ベンダーが提案するものではありません。選択肢3の「ベンダーの過去の全取引履歴」は情報過多であり、通常は類似案件の実績などを抜粋して記載します。

【解説】

正解: 2 ベンダーが発注者に最適なソリューションを提案するための文書を作成する

この問題は、システム調達における「提案書」の定義と役割を正しく理解しているかを確認するものです。

正解は2の「ベンダーが発注者に最適なソリューションを提案するための文書を作成する」です。RFP（提案依頼書）に対する回答として、ベンダーが自社の技術やノウハウを用いてどのように要件を満たすかを具体的に示した文書が提案書です。これが発注者による選定の主な判断材料となります。

選択肢1の「ベンダーが選定される前に解約するための手順」や、選択肢3の「システム運用の具体的な操作マニュアル」は、提案書の役割ではありません。

【解説】

正解: 1 発注者の要件を正確に反映すること

この問題は、評価される提案書を作成するためのポイントを理解しているかを確認するものです。

正解は1の「発注者の要件を正確に反映すること」です。どんなに技術的に優れた提案であっても、RFPに記載された発注者の目的や要件（機能要件、非機能要件、制約事項など）を満たしていなければ採用されません。要件を正しく理解し、それに対する具体的な解決策を示すことが最も重要です。

選択肢2の「提案をできるだけ曖昧に記述すること」は、信頼を損なうため逆効果です。選択肢3の「他の提案と全く違うことを強調するだけにすること」も、要件を満たしていなければ意味がありません。

【解説】

正解: 1 商品やサービスの価格と支払い条件

この問題は、ビジネス取引における「見積書」の基本的な構成要素を理解しているかを問うものです。

正解は1の「商品やサービスの価格と支払い条件」です。見積書には、システム開発や製品購入にかかる総額だけでなく、内訳（明細）、有効期限、支払いの条件（月末締め翌月末払いなど）が記載されます。これにより、発注者は予算内で収まるかを確認します。

選択肢2の「ベンダーの全従業員の勤務時間表」は個人情報かつ不要な情報であり、見積書には記載しません。選択肢3の「契約締結後の実施報告書の内容」は、プロジェクト終了後に提出される報告書の話であり、見積りの段階では存在しません。

【解説】

正解: 2 調達コストを評価する際に参考にするため

この問題は、システム選定プロセスにおいて見積書がどのように活用されるかを理解しているかを確認するものです。

正解は2の「調達コストを評価する際に参考にするため」です。複数のベンダーから提案と見積書を取得（相見積もり）し、提案内容と金額のバランス（コストパフォーマンス）を比較検討するために使用されます。

選択肢1の「システム開発の初期設計を行うとき」は設計図書などを使う場面です。選択肢3の「完成したシステムの運用を開始するため」はマニュアルや手順書を使う場面であり、見積書の用途とは異なります。

【解説】

正解: 3 契約解除の後の運用方法

この問題は、見積書と契約書や運用マニュアルの役割の違いを区別できるかを問うものです。

正解は3の「契約解除の後の運用方法」です。見積書はあくまで「契約する前に、いくらかかるか」を提示する書類です。契約が解除された後の法的な取り決めや運用ルールといった詳細な条項は、別途締結される「契約書」や「利用規約」などに記載されるべき内容であり、見積書には含まれません。

選択肢1の「価格の明細」や選択肢2の「支払い期限（または見積もりの有効期限）」は、見積書を構成する必須項目です。