🦆

【ST試験対策】システム調達

2025/01/18に公開

なぜ作成したのか

  • ITストラテジスト合格のため、書籍の内容をまとめてみる

参考


午前Ⅱ対策

システム調達

  • システム企画、要件定義工程が完了したら、開発工程に進みます。
  • システム開発ベンダーに要件を伝え、提案および見積もりを依頼します。
  • もっともその企業にマッチした提案及び見積もりを提示したベンダーをパートナーとして選定します。
  • 契約にあたっては契約形態についても注意が必要です。

RFI(Request for Information:情報提供依頼書)

  • 概要
    • ベンダーや市場から情報を収集するための文書で、調達の初期段階で使用。
    • 提供可能なサービスや技術、費用感などを把握し、調達計画を具体化する。
  • 主な目的
    • ベンダーの技術力、ソリューションの選択肢、最新トレンドの把握。
  • 利用タイミング
    • 調達の初期段階で市場調査を行う際に使用。
  • 内容
    • 必要とされるシステムの概要。
    • ベンダーに対する質問項目(例:技術力、実績、提供可能なオプション)。
  • 具体例
    • AIを活用した分析ツールの導入を検討する際に、関連ベンダーから情報を収集。

RFQ(Request for Quotation:見積依頼書)

  • 概要
    • ベンダーに具体的な製品やサービスの価格見積を依頼する文書。
    • 価格を中心に調達の選択肢を比較・検討する際に使用。
  • 主な目的
    • 価格競争力のあるベンダーを特定。
    • 契約交渉の基礎情報を収集。
  • 利用タイミング
    • 調達の具体的な仕様や要件が確定した後。
  • 内容
    • 製品やサービスの詳細要件、提供条件、納期。
    • 見積価格の提出フォーマット。
  • 具体例
    • サーバー機器の購入において、ベンダーに価格見積を依頼。

RFP(Request for Proposal:提案依頼書)

  • 概要
    • ベンダーに具体的な提案を求める文書で、システムの仕様や実現方法を含む。
    • ベンダーの創造性や技術力を重視する調達手法。
  • 主な目的
    • ベンダーから具体的な提案を得て、適切な調達先を選定。
    • 複数のソリューションを比較し、最適な選択をする。
  • 利用タイミング
    • 調達する製品やサービスの要件はある程度確定しているが、技術的な詳細は未定。
  • 内容
    • 調達するシステムやサービスの要件。
    • 提案書に含むべき情報(スケジュール、コスト、実現方法)。
  • 具体例
    • CRMシステムの導入に際して、各ベンダーから設計、導入、運用までの提案を依頼。

請負契約

  • 概要
    • ベンダーが成果物を完成させることを目的とする契約形態。
    • 発注者は完成した成果物を受け取り、支払いを行う。
  • 特徴
    • 成果物の完成が契約履行の条件。
    • 作業プロセスではなく、成果物の品質に責任を持つ。
  • メリット
    • 発注者が詳細なプロセス管理を行う必要がない。
  • デメリット
    • 仕様変更が発生した場合、追加コストがかかる可能性がある。
  • 具体例
    • 新しい業務システムの開発プロジェクトを請負契約で委託。

準委任契約

  • 概要
    • 特定の業務をベンダーに委託し、作業内容に基づいて報酬を支払う契約形態。
    • 成果物の完成ではなく、提供された業務や時間に応じて報酬が発生。
  • 特徴
    • ベンダーは発注者の指揮命令下で業務を行う。
    • プロセスや作業内容に責任を持つ。
  • メリット
    • 柔軟な対応が可能で、途中で作業内容を変更しやすい。
  • デメリット
    • 成果物の完成責任がないため、納期や成果の管理が発注者側に求められる。
  • 具体例
    • ソフトウェアの保守運用業務を準委任契約で委託。

派遣契約

  • 概要
    • 発注者が指定した業務を遂行するために、ベンダーから派遣された技術者が業務を行う契約形態。
    • 発注者が作業の指示や監督を行う。
  • 特徴
    • 技術者の指揮命令権は発注者側にある。
    • 業務範囲は派遣法に基づき規定される。
  • メリット
    • 必要なスキルを持つ人材を短期間で確保できる。
  • デメリット
    • 契約期間に制限があり、長期的な活用には不向き。
  • 具体例
    • 特定のスキルを持つプログラマーを派遣契約でプロジェクトに投入。

まとめ

観点 概要 利用目的・タイミング 具体例
RFI ベンダーから情報を収集する文書。 初期段階で市場調査を行う。 AIツール導入の選定に向けた情報収集。
RFQ ベンダーから価格見積を得る文書。 要件が確定し、価格重視で選定する場合。 サーバー購入における価格競争。
RFP ベンダーに提案を求める文書。 技術的な提案や創造的なソリューションが必要な場合。 CRMシステム導入のための提案依頼。
請負契約 成果物の完成を目的とする契約形態。 システム開発プロジェクトの完了を目指す場合。 新規システムの開発をベンダーに請負契約で依頼。
準委任契約 ベンダーに業務を委託し、作業内容に基づいて報酬を支払う契約。 継続的な保守運用やスキルが必要な業務を依頼する場合。 システム運用保守を準委任契約で委託。
派遣契約 ベンダーから派遣された技術者が、発注者の指揮命令下で業務を行う契約。 必要なスキルを持つ人材を一時的に確保する場合。 プログラマーを派遣契約で採用し、特定の業務を遂行。

補足:準委任契約における善管注意義務

準委任契約における善管注意義務は、受託者が契約上の義務を遂行する際に、善良な管理者としての注意義務を負うという法的責任です。この義務は、特に専門知識やスキルを持つプロフェッショナルに課されるものであり、業務遂行において通常求められる注意や配慮を行う必要があります。


1. 善管注意義務の基本的な法的背景

  • 民法第644条(受任者の注意義務)
    • 「受任者は、委任事務を処理するについて、委任の本旨に従い、自己のためにするのと同一の注意をもってその事務を処理しなければならない。」と規定。
  • 準委任契約に適用
    • 特定の成果物を納める請負契約と異なり、準委任契約では「成果物完成」が義務ではないため、業務遂行プロセス自体に注意義務が求められる。

2. 判例:システム開発保守における善管注意義務違反の事例

判例概要

  • 案件
    • あるシステム保守契約において、受託者(ITベンダー)が適切な対応を怠ったため、システム障害が発生し、発注者が損害を被った。
  • 争点
    • 受託者が善管注意義務を果たしたか否か。
  • 判決の要点
    1. システム障害の予防義務
      • 受託者は、発注者が依頼した保守作業だけでなく、システム全体にわたる潜在的リスクを把握し、適切な予防措置を講じるべきであった。
    2. 報告義務違反
      • システム障害の兆候が発生していたにもかかわらず、受託者が発注者に適時報告を行わず、対応が遅れた。
    3. 善管注意義務違反
      • 専門家としての注意義務を怠り、結果として障害が発生したことをもって受託者の責任を認定。

判決の結論

  • 裁判所は、受託者が専門的な注意を払わなかったことを認定し、発注者に対する損害賠償責任を課した。

3. 善管注意義務違反が問われる場面

  1. 問題の未然防止が不十分
    • 障害の可能性が予見できたにもかかわらず、適切な予防策を取らなかった。
  2. 業務遂行の過失
    • 提供されたデータや仕様書に誤りがある場合でも、それを発見し修正する義務がある。
  3. 報告や連絡の不足
    • 問題発生時やリスク発見時に発注者へ速やかに通知しなかった場合。

4. 善管注意義務違反を防ぐための実務ポイント

  1. 明確な契約内容
    • 契約書で業務範囲や注意義務の具体的内容を明示。
  2. 定期的な報告
    • 進捗状況やリスクについて定期的に発注者に報告。
  3. 記録の保持
    • 作業手順やトラブル対応の記録を残し、注意義務を果たしていることを証明可能にする。
  4. 専門性の維持
    • 契約で求められるスキルや知識を最新の状態に保つ。

5. 善管注意義務が強化される場合

  • 高度な専門性が求められる場合
    • ITエンジニア、コンサルタントなどの専門職は、より高い注意義務を負う。
  • 業務の重要性が高い場合
    • 社会的影響が大きいシステムや業務では、リスク管理の厳格性が求められる。

GitHubで編集を提案

Discussion