システム企画

目次

応用情報技術者試験（レベル３）シラバス－情報処理技術者試験における知識・技能の細目－ Ver.6.1 に基づき，「システム企画」の対策ノートを作成した。

本稿は，IT ストラテジスト試験，システムアーキテクト試験，プロジェクトマネージャ試験 午前Ⅱ 問題の対策としても活用できるようにしている。

• システム化計画
• 要件定義
• 調達計画・実施
• 本稿の参考文献

システム化計画

システム開発の上流工程は，システム企画から始まる。そして，企画プロセスは，二つのサブプロセスから構成される。

システム化計画（system planning）とは，情報システム開発・導入における初期の工程の一つで，システム化する業務の内容を分析し，どのような情報システムが必要となるか，どのように開発・導入を進めるかなどの基本方針を策定する段階のこと。

(1) システム化構想の立案

システム化構想の立案は，「システム化計画の立案」に先だって実施され，事業環境，現行業務，情報技術動向などを調査した上で，経営要求・経営課題，システム化の検討対象となる業務，業務の新全体像のイメージなどを文書化し，経営者の承認を得ることを目的とするプロセスである。

システム化構想の立案では，企業で将来的に必要となる最上位の業務機能と業務組織を表した業務の全体像が作成される。

業務フロー

業務フローを記述する際に，処理の分岐や並行処理，処理の同期などを表現できる図はアクティビティ図である。

システム化構想書

地方公共団体の情報システム企画書の主な記載項目の例を次表に示す。（出典）平成27年度 秋期 IT ストラテジスト試験 午後Ⅰ 問3

財政的効果

情報システム化によって達成できる収入増加額・経費削減額の 5 年間分の累計額

その他の効果

財政的効果以外で，"住民のための効果"，"業務プロセス改善効果" といった，事業のパフォーマンスを定量化した値。事業，情報システムの特性に応じて，主管課が評価指標と目標値を設定する。

情報システム費用

5 年間に発生する総所有コスト

情報システムの構築費用

機器費用，ソフトウェア開発工程ごとの費用

年当たり定常費用

機器保守費用，ソフトウェア保守費用，及び運用費用

BABOK（ビジネスアナリシス知識体系ガイド）

BABOK（Business Analysis Body of Knowledge，ビジネスアナリシス知識体系ガイド）は，経営ニーズやステークホルダの課題を調査・整理，および検証して取りまとめる "ビジネス分析" のベストプラクティスを体系化した書籍の略称である。

7 つの知識エリアは以下の通りで，各知識エリアに合計で 32 のタスクが存在する。

ビジネスアナリシスの計画と監視

要求分析プロジェクトのプロジェクトマネジメントをおこなう

引き出し

ステークホルダの潜在的な要求を漏れなく収集する

要求管理とコミュニケーション

収集した要求を調整して，取りまとめる

エンタープライズ・アナリシス

企業の現状とあるべき姿を把握して，変革の方向性を決定する

要求分析

収集した要求を分析・整理する

ソリューションの評価と妥当性確認

提案されたソリューションを評価し価値に結びつける

基礎コンピテンシ

ビジネスアナリシスに必要なスキルや能力を定義されている

BABOK では，要求をビジネス要求，ステークホルダ要求，ソリューション要求及び移行要求の 4 種類に分類している。

ビジネス要求

経営戦略や情報化戦略などから求められる要求であり，エンタープライズアナリシスの活動で定義している。

ステークホルダ要求

利用部門や運用部門などから個別に発せられるニーズであり，要求アナリシスの活動で定義している。

ソリューション要求

組織・業務・システムが実現すべき機能要求と非機能要求であり，要求アナリシスの活動で定義している。

移行要求

新システムへのデータ変換や要員教育などに関する要求であり，ソリューションのアセスメントと妥当性確認の活動で定義している。

BPR (Business Process Reengineering)

BPR とは，企業などで既存の業務の構造を抜本的に見直し，業務の流れ（ビジネスプロセス）を最適化する観点から再構築すること。

1990 年にマサチューセッツ工科大学（MIT）の Michael M. Hammer（マイケル・ハマー）教授が提唱した概念で，その背景には高度の分業化され部分最適に陥った非効率な組織への反省がある。

『リエンジニアリング革命』"Reengineering the Corporation: A Mainfesto for Business Revolution" でハマーたちは，次のように主張した。

• QC 的改善ではなく抜本的改革を目指せ
• 社内思考ではなく徹底的に顧客志向であれ
• 中央集権の管理志向でなく現場に権限委譲せよ
• 情報システムを活用し組織を一体化せよ

SoR (Systems of Record)

日々の仕訳伝票を入力した上で，データの改ざん，消失を防ぎながら取引データベースを維持・管理することによって，財務報告を行うためのシステム

SoE (Systems of Engagement)

データの活用を通じて，消費者や顧客企業とのつながりや関係性を深めるためのシステム

(2) システム化計画の立案

システム化構想を具現化するための，システム化計画及びプロジェクト計画を具体化し，利害関係者の合意を得る。

システム化方針には，経営戦略や情報戦略に関わる経営上のニーズ，システム化・システム改善を必要とする業務上の課題，求められる成果・目標などの項目がある。

業務モデルの作成

共通フレームによれば，システム化計画の立案において，システム化機能を整理し，情報と処理の流れを明確にするために実施する作業である。

(3) システム化計画の立案における検討項目

① 全体開発スケジュール

対象となったシステムを必要に応じてサブシステムに分割し，サブシステムごとに優先順位をつける。また，要員，納期，コスト，整合性などを考え，各サブシステムについて開発スケジュールの大枠を作成する。

② 要員教育計画

業務・システムに関する教育計画について，教育訓練体制やスケジュールなどの基本的な要件を明確にする。

③ 投資の意思決定法

経済性計算の手法を利用して正確な投資の価値を算出し，投資の意思決定を行う。

PBP (payback period method)

投資効果を評価する方法の一つで，投資額が何年で回収されるかを算定し，その期間（年数）によって投資事案を評価する手法である。

投資によって生み出されるキャッシュフローの累計額が投資額と等しくなる期間を年で示す値（投資回収年数）を求め，基準よりも短期間であれば投資を行い，そうでなければ見送る。投資案件が複数ある場合，より投資回収年数が短いものを選択する。

回収期間法は計算が非常に簡単であるが，貨幣の時間的価値や資本コストを考慮しておらず，回収期間以降のキャッシュフローを考慮していないなどの欠点がある。投資リスクが大きく資金の早期回収が優先される場合には，一定の有効性があると位置付けられる。

DCF (Discounted Cash Flow) 法

企業（事業，プロジェクト，資産）が将来にわたって生み出すフリーキャッシュフローを推計し，その流列を一定の率（WACC）によって割り引いて算出した現在価値のこと。企業価値やプロジェクト投資などの投資成果の価値評価する際に使われる。

NPV（Net Present Value）

将来のキャッシュ・インフロー（現金流入）の現在価値から，投資であるキャッシュ・アウトフロー（現金流出）の現在価値を差し引いた正味の金額。投資（金融投資および事業投資）の採算性を示す指標で，投資判断の最も一般的な基準となっている。例えば，情報システムの導入と活用によって生み出されるキャッシュフローの現在価値を計算することによって，投資効果を評価したいときに使われる。

簡単にいえば DCF（Discounted Cash Flow 法）をベースに「回収額 - 投資額」を算出したもので，その投資案件で得られる正味の価値（金額）のことである。NPV が大きければ大きいほど経済価値が大きく，NPV がマイナスであれば採算が得られないことを示す。

ROI（Return on Investment : 投資利益率）

ROI は，IT 投資効果の評価に用いられ，投資額を分母に，投資による収益を分子とした比率を算出し，その大小で評価する。

TCO（Total Cost of Ownership）

ある設備・システムなどに関する，取得から廃棄までに費用の総額を表す。TCO は，初期投資額であるイニシャルコストと，維持管理費用であるランニングコストに大別できる。

イニシャルコストの例

ハードウェア購入・設置費用，パッケージソフトの購入費用・開発費，初期教育費など

ランニングコストの例

保守・サポート契約費，ライセンス料，運用人件費，消耗品費など

TCO の算定に当たって，利用部門におけるシステム利用に起因する，埋没原価などの見えない費用も考慮する。

投資種別の分類

情報システムに関する企画審査は，下表に示す四つの投資種別に分類して行うこともある。（出典）平成27年度 秋期 IT ストラテジスト試験 午後Ⅰ 問3

④ 開発投資対効果

システム実現時の定量的，定性的な効果予測を行う。また，期間・体制などの大枠を予測し，費用を見積もる。このとき，IT 投資のバランスやシステムライフサイクルを意識する。

⑤ 情報システム導入リスク分析

導入に伴うリスクの種類や大きさを分析する。リスク分析の対象を決定し，リスクの発生頻度・影響・範囲などを特定し，リスクの種類に応じた損害内容と損害額を算出する。その後，リスクに応じてリスク対策を行う。

要件定義

システム化計画に続いて，要件定義を行う。

システムへの要求を洗い出して分析することを要求分析という。要求分析の結果をまとめて明確にし，定義するのが要件定義である。

(1) 要求分析

① 要求分析の手順

要求分析は，要求項目の洗い出し，要求項目の分析，ユーザニーズ調査，前提条件や制約条件の整理という手順で行う。このとき，利害関係者から提示されたユーザのニーズや要望を識別し，要求仕様書に整理する。

② 要求分析の手法

インタビュー

インタビュー技法には，構造化インタビュー，半構造化インタビュー，非構造化インタビュー，フォーカス・グループ・インタビューがある。

構造化インタビュー

予め決められた質問紙やアンケートなどをもとに，対話をつづけていき，その質問（＝調査者の側で構造化されており，質問されたほうも思考のラインで答えることができる）の間におこった質的な情報を記載する方法である。

半構造化インタビュー

予め質問項目を決めておき，それらを録音機（IC レコーダー）やメモなどで質問を続けていく。アンケートを用意し，それを取りながら（あるいは口実にしながら），それにまつわる情報を採集する方法もある。

非構造化インタビュー

構造化されていない質問を通して情報を，対話と観察のラインで調査者（インフォーマント） から引き出す手法である。

フォーカス・グループ・インタビュー

集団を相手に特定のトピックについて話し合う。調査者は談話のファシリテーターになったり，まとめたりする。

構造化インタビューの手法を用いた意見の収集形態の例として，調査項目を全て決めてから，決められた順序で質問することで，インタビュアの技量に左右されない意見を収集する。

E-R モデル

情報システムの全体計画立案のために E-R モデルを用いて全社のデータモデルを作成する。

手順としては，企業の全体像を把握するため，主要なエンティティだけを抽出し，それらの相互間のリレーションシップを含めて，鳥観図を作成する。次にエンティティを詳細化し，全てのリレーションシップを明確にしたものを前者のデータモデルとする。

(2) 要件定義

要件定義では，システムに求められる要件を定義する。

① 要件定義の目的

要件定義プロセスは，利用者および他の利害関係者が求めるシステムに対する要件を定義することを目的とするプロセスである。共通フレーム 2013 によれば，要件定義プロセスの活動の内容には，利害関係者の識別，要件の識別，要件の合意などがある。

社内システムの要件定義では，実際にシステムを運用するユーザ部門の責任者の承認が必要となる。

利害関係者の識別

システムのライフサイクルの全期間を通して，どの工程でどの関係者が参画するのかを明確にする。

要件の識別

利害関係者から要件を漏れなく引き出し，制約条件や運用シナリオなどを明らかにする。

要件の評価

抽出された要件を確認して，矛盾点や曖昧な点をなくし，一貫性がある要件の集合として整理する。

要件の合意

矛盾した要件，実現不可能な要件などの問題点に対する解決方法を利害関係者に説明し，合意を得る。

② 要件の定義

業務要件定義

業務要件（business requirements）とは，システム開発やソフトウェア開発の初期の工程で，システム化の対象となる業務の流れを明確化したもの。

一般的には要件定義プロセスの初期の段階で定義されるもので，対象業務の現状を分析し，新たに実現すべき業務の流れを明らかにする。この段階ではシステムの存在は意識せず，業務の詳細な手順や担当者，扱う情報とその流れなどを決めていく。

業務要件が完成した後に，その中のどこをどのようにシステム化するのかを検討し，システムに要求される要件（システム要件）を定義する。業務要件は業務全体の流れを対象とするため，中にはシステム化の対象とならない（システム要件に対応する項目や要素がない）部分が存在する場合もある。

新しい業務の在り方や運用に関わる業務手順，入出力情報，組織，責任，権限，業務上の制約などの項目がある。

機能要件定義

機能要件（functional requirement）とは，情報システムやソフトウェアの開発に際して定義される要件のうち，機能や挙動に関するもの。主に要求分析や要件定義などの工程で検討・決定される。

新しい業務の遂行に必要なアプリケーションシステムに関わる利用者の作業，システム機能の実現範囲，機能間の情報の流れなどの項目がある。

非機能要件定義

非機能要件とは，業務要件を実現するためのシステムに求められる要件のうち，機能要件以外の要件のことである。一般に制約条件や品質要求がこれに該当する。共通フレーム 2007 では，非機能要件に記述する事項の例として JIS X 0129-1(ISO/IEC 9126) における 6 つの「品質特性」のほか，「技術要件」「運用・操作要件」「移行要件」「付帯作業」を挙げている。

IPA で公開している「非機能要求グレード」には，以下の 6 つのカテゴリがある。

③ 要件定義の手法

要件定義の手法には，構造化分析手法，データ中心分析手法，オブジェクト指向分析手法などがある。プロセス仕様を明らかにして DFD などを記述するのが構造分析手法である。データ中心分析手法では，E-R 図を記述してデータの全体像を把握する。オブジェクト指向分析手法では UML を利用する。

DFD (Data Flow Diagram)

DFD とは，情報システムの設計時などに作成される図の一つで，要素間のデータの流れを表した図。データがどこで発生し，どこからどこへ運ばれ，どこへ出力・保管されるのかを図示することができる。

決定表（デシジョンテーブル）

決定表（dicision table）とは，複数の判断条件の正否の組み合わせを列挙し，それぞれの場合についてどのような判断を下すかを一覧にまとめた表。

UML (Unified Modeling Language)

ユースケース図は，UML の中でもシステムの振る舞いを表現する図で，システムに要求される機能を，ユーザの視点から示した図である。ユースケース図を有効に活用することにより，システムの全体像を開発者とユーザが一緒に評価しやすくなる利点がある。

DOA (Data Oriented Approach)

DOA とは，業務システムの設計手法の一つで，システムの扱うデータの構造や関係を定義し，それに合わせて処理や手順の流れを決めていく方式。

④ 利害関係者要件の確認

ステークホルダ

IT ストラテジストは，事業部門，IT 部門，本社部門，IT 子会社などのステークホルダとともに，個別システム化構想を策定する。

要件定義者は，定義された要件の実現可能性を十分に検討した上で，ステークホルダに要件の合意と承認を得る。

(3) 情報システム戦略との整合性の検証

調達計画・実施

ここでの調達には，開発するシステムに必要な製品やサービスの購入だけでなく，組織内部や外部委託によるシステム開発なども含まれる。開発するシステムの用途，規模，取組方針，前提や制約条件に応じた調達方法を考える必要がある。

(1) 調達と調達計画

① 調達の前提

調達とは，品物，サービス，労働力などを用意することである。外部資源の利用を行い，必要なものを調達する。情報システムの場合，SI（System Integrator : システムインテグレータ）事業者にアウトソーシングすることも考えられる。

調達を行ったシステム資産及びソフトウェア資産については，ライセンス管理，構成管理などを適切に行い，管理する必要がある。

② 調達の計画

調達計画の策定では，調達の対象，調達の条件，調達の要求事項などを定義する。また，要件定義を踏まえ，既存の製品またはサービスの購入，組織内部でのシステム開発，外部委託によるシステム開発などから調達方法を選択する。

このとき，社内で実施すること，社外に委託することを決める内外作基準を策定する。

③ 外部資源の利用

システムインテグレータ

金融や製造業の専門知識，AI などの先進 IT の活用，ERP 製品の導入ノウハウなどを強みに，IT 戦略立案からシステム開発，運用保守までフルラインに対応する。

SI 事業者

SI 事業者の例を以下に示す。

• 富士通
• アビームコンサルティング（NEC）
• NTT データ
• 日立コンサルティング

アウトソーシング（outsourcing）

アウトソーシングとは，企業が業務の一部を別の企業などに委託すること。外注，外製，外部委託，業務委託，社外調達などもほぼ同義。自社で人員を確保するのが困難な高度に専門的な業務や，専業の事業者の方が低コストで処理できるような業務で行われることが多い。

SaaS (Software as a Service)

SaaS とは，ソフトウェアをインターネットを通じて遠隔から利用者に提供する方式。利用者は Web ブラウザなどの汎用クライアントソフトを用いて事業者の運用するサーバへアクセスし，ソフトウェアを操作・使用する。従来「ASP サービス」と呼ばれていたものとほぼ同じもの。

ASP (Application Service Provider)

ASP サービスとは，インターネットなどを通じて遠隔からソフトウェアを利用させるサービス。そのようなサービスの提供者のことを ASP（Application Service Provider）という。

IDC (Internet Data Center)

データセンターとは，外部へ機能やサービスを提供するためのサーバコンピュータなどを設置，運用のための施設。特に，インターネットへ向けてサービスを提供するためのものをインターネットデータセンター（IDC）という。

SOA（Service Oriented Architecture : サービス指向アーキテクチャ）

業務上の一処理に相当するソフトウェアで実現されている機能や部品を独立したサービスとし，それらを組み合わせ連携させることで言語やプラットフォームに依存せずにシステムを構築するという手法，またはそのことを指す用語である。

SOA では，機能単位の組み合わせでシステムを構築するので，ソフトウェアコンポーネントの再利用や機能の入替え，システムの再構築がしやすいという特徴がある。SOA を実現する手段として，Web サービスや ESB（Enterprise service bus），CORBA を用いた分散オブジェクトシステムなどが使われる。

SOA では，機能の変更や拡張をサービス（機能）単位でのフレキシブルなシステムの組み換えを可能とし，業務環境の変化に柔軟に対応することを目標としているため，個々のサービスが部品として独立し，サービス間の関係が疎結合（分離している）であることが重要である。

④ システム資産及びソフトウェア資産管理

(2) 調達の実施

① 調達の方法

調達の代表的な方法には，企画競争入札，一般競争入札がある。企画競争入札では，事業テーマについて企画書などの提出を求め，企画内容を審査する。それに対して，一般競争入札では，提案内容だけでなく，価格も合わせて審査する。

一般競争入札では，技術点や価格点などそれぞれの点数を合計して総合点で入札者を決定する総合評価落札方式が用いられる。

企画競争入札（プロポーザル方式）

所定の契約限度額の枠内で最も優れた提案が，入札を経ずに選ばれる。

一般競争入札（最低価格落札方式）

予定価格の制限の範囲内で最低価格の提案が選ばれる。

総合評価落札方式

総合評価落札方式は，価格のみで落札者を決定する従来の最低価格落札方式とは異なり，「価格」に加えて「価格以外の要素（専門技術の有無やノウハウ等）」も勘案した総合的な評価で落札者を決定する方式である。具体的には，入札者が示す価格と技術提案の内容を評価点に表し，入札者の中で最も総合評価の高い落札者を決定する。

随意契約

過去の採用実績が総合的に評価され，入札を経ずに業者が選ばれる。

② 情報提供依頼書（RFI）

RFI（Request for Information）は，企業・組織がシステム調達や業務委託をする場合や，初めての取引となるベンダ企業に対して情報の提供を依頼すること，またはその際に提出される文書のことをいう。RFI を発行することによって相手方が保有する技術・経験や，情報技術動向，及び導入予定のシステムが技術的に実現可能であるかなどを確認することができる。この情報は要件定義や発注先候補の選定に利用できる。

③ 提案依頼書（RFP）

RFP（Request for Proposal）は，調達者から供給者候補に対して，対象システムや調達条件などを示し，提案書の提出を依頼すること。RFP に記載する内容としては，以下のものが挙げられる。

• システムの目的や背景
• 予算，スケジュール
• 業務要求
• 必須機能
• 運用，保守
• 成果物

開発委託用の提案依頼書の記載項目（例）を下表に示す。定例報告や共同レビュー，作業場所，機器・材料負担，瑕疵担保期間や著作権など，取り決めは細部にわたる。

運用委託用の提案依頼書の記載項目（例）を下表に示す。クライアント対応や機密保持，教育訓練やコミュニケーションなど，顧客対応に関する要件が必要になる。

システム構築の提案依頼書（RFP）を作成する際の留意点として，提案の評価項目を明示することが挙げられる。

④ 提案書・見積書

ベンダ企業では，提案依頼書を基にシステム構成，開発手法などを検討し，提案書や見積書を作成して，発注元に提案する。このとき，見積りを依頼するために RFQ（Request For Quotation : 見積依頼書）を作成することがある。

システムの提案書・見積書には，以下のような項目を記載する。

⑤ 調達選定

調達先の選定にあたっては，提案評価基準，要求事項適合度の重み付けを行う選定手順を確立する必要がある。このとき，コストや工期だけでなく，法令遵守（コンプライアンス）や内部統制などの観点からも比較評価して選定することが大切である。

CSR 調達

CSR（Corporate Social Responsibility : 企業の社会的責任）調達とは，企業が製品やサービスを調達する場合，自然環境，人権などへの配慮を調達基準として示し，調達先にもそれらの遵守を求める考え方。

グリーン調達

グリーン購入基本原則は，グリーン購入を自主的かつ積極的に進めようとする個人や組織の役に立つよう，さまざまな製品やサービスのグリーン購入に共通する基本的な考え方をまとめたものである。グリーン購入とは，購入の必要性を十分に考慮し，品質や価格だけでなく環境や社会への影響を考え，環境負荷ができるだけ小さく，かつ社会面に配慮した製品やサービスを，環境負荷の低減や社会的責任の遂行に努める事業者から優先して購入することをいう。

グリーン購入基本原則は，以下の通り。

1. 必要性の考慮
   購入する前に必要性を十分に考える。
2. 製品・サービスのライフサイクルの考慮
   資源採取から廃棄までの製品ライフサイクルにおける多様な環境負荷を考慮して購入する。
3. 事業者の取組の考慮
   環境負荷の低減に努める事業者から製品・サービスを優先して購入する。
4. 環境情報の入手・活用
   製品・サービスや事業者に関する環境情報を積極的に入手・活用して購入する。

環境表示ガイドライン

環境表示ガイドラインは，適切な環境表示を推進するために，主に事業者及び事業者団体が消費者に向けて環境情報を提供する場合の望ましいあり方について，環境表示に関する国際規格（ISO/JIS Q 14020 シリーズ）への準拠を基本的な考え方として示したものである。

このガイドラインにおいて環境表示とは「製品の原料採取から製造，流通，使用，リサイクル・廃棄の段階において，環境に配慮した点や環境負荷低減効果等の特徴を説明したものをいい，説明文やシンボルマーク，図表など」と規定されている。

⑥ 調達リスク分析

調達にあたっては，内部統制，法令遵守，CSR 調達，グリーン調達などの観点によるリスク管理が必要である。リスクを分析および評価して，対策を立てる必要がある。また，調達のリスクには，信用リスク，事務リスク，風評リスクなど様々なものがあるので，リスクの内容に合わせて個々に対策を考える必要がある。

⑦ 契約締結

契約締結時には，受入システム，費用，受入時期，発注元とベンダ企業の役割分担などを明記する必要がある。また，JISA が発表するソフトウェア開発委託モデル契約，情報システム・モデル取引・契約書などを基に契約書を作成する。必要に応じて，知的財産権利用許諾契約も行う。

ソフトウェア開発委託モデル契約

主に大手ユーザ企業が情報システムを発注するにあたり，IT ベンダーと結ぶモデル契約書（マルチベンダ形態に対応，ハードウェア取引は対象外）

情報システム・モデル取引・契約書

ユーザとベンダのあるべき理想的なモデルを提示し，情報システムのライフサイクルプロセスの中で，ユーザとベンダの間でどのようなことを決定し，どのようなことを情報共有すればよいか，についての統一的な指針を目指して策定されたものである。

この指針では，見積り時期とリスクとの関係を踏まえ，ユーザ・ベンダの双方のリスクアセスメントの機会を確保する観点から「多段階契約」の考え方を採用している。多段階契約とは，委託開始に際して役割分担等の要旨だけを記した基本契約だけを先に結んでおき，具体的な委託内容については「システム化の方向性～システム化計画」「要件定義」「外部設計」「内部設計以降」というような工程毎に個別契約を締結する契約方式である。これにより曖昧な段階で行われた見積りは，要件が明らかになった段階で再見積もりされることになる。多段階契約を採用すると，契約事務の手間は増大しますが，一括契約方式と比較して開発途中で発生する仕様変更の影響を極力抑えられる利点がある。

パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書

中小のユーザ企業がパッケージソフトや SaaS/ASP を活用した情報システムを導入するにあたり，IT ベンダーと結ぶモデル契約書

重要事項説明書

IT ベンダーが「パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書」を結ぶにあたって，ユーザ企業に対する説明を行い，同意を求める説明書

（準）委任契約

準委任契約とは，通常の委託契約（請負契約）と同様に別の組織に業務を委託する契約ですが，仕事の完成を契約の目的とする請負契約と異なり，委託された仕事の実施自体を目的とする契約形態である。受託者は善良な管理者の注意をもって委任事務を処理する義務を負うものの，仕事の完成についての義務は負わない。主に業務分析や要件定義，運用テスト工程などの成果物が特定されていない状況で結ばれる。

定額契約

定額契約では，製品やサービスなどに対し，一定の決まった総額を定めて契約を結ぶ。

完全定額契約（FFFP : Firm Fixed Price Contract）

完全定額契約では，品目の価格が作業開始前に設定され，作業スコープが変更されない限り価格は変わらない。そのため，購入する側の組織の多くがこの契約を好み，最も一般的に使用されるタイプの契約のタイプである。

定額インセンティブ・フィー契約

定額インセンティブ・フィー契約（FPIF）は，合意した評価尺度の達成に対する金銭的インセンティブが関連付けられており，パフォーマンスの変動を許容するという点で，購入者にいくらかの柔軟性がある契約である。インセンティブとしては，納入者のコスト，スケジュール，技術的パフォーマンスなどが関連づけられる。定額インセンティブ・フィーでは，価格の上限が定められ，上限を超えたすべてのコストは，納入者の責任となる。

経済価格調整付き定額契約

経済価格調整付き定額契約（FPEPA : Fixed Price with Economic Price Adjustment Contract）は，インフレーションによる変化または特定物資のコストの高騰や低下など，状況の変化に応じて，事前に定義した最終調整を契約価格へ反映可能な特殊条項を含む定額契約である。経済的な変動を許容できるようになるため，経済価格調整付き定額は購入者・納入者の双方を保護することができる契約となる。プロジェクトの実施期間が長期にわたる場合，または支払いが異なる通貨で行われる場合にも使用される。

実費償還契約（CPIF，CPFF）

実費償還契約では，完了した作業にかかったすべての正当な実コストに，納入者の利益相当分を加えた金額を納入者に支払う，つまり実費を支払うという契約である。ほとんどの場合，実費償還契約は契約の実行中に作業スコープが大きく変更されることが予測される場合に使用される。

コスト・プラス定額フィー契約

コスト・プラス定額フィー契約（CPFF : Cost Plus Incentive Fee Contract）は購入者の償還対象コストと固定額の利益を納入者に支払う契約形態である。

コスト・プラス・インセンティブ・フィー契約

コスト・プラス・インセンティブ・フィー契約（CRIF : Cost Plus Incentive Fee Contract）は，購入者が償還対象コストを納入者に支払うとともに，契約時に合意したパフォーマンスの基準を達成した場合に所定の利益を支払うという契約である。コスト・プラス・アワード・フィー契約では，最終コストが当初の見積りコストより上回った場合や下回った場合は，購入者と納入者の双方が事前に取り決めたコストの分配方式に応じてその差額を負担する。

コスト・プラス・アワード・フィー契約

コスト・プラス・アワード・フィー契約（CPAF : Cost Plus Award Fee Contract）では，購入者は作業にかかった妥当な実費総額に加えて，納入者の利益となる報奨金を納入者に支払う。契約時に取決めを交わすインセンティブ・フィーに対して，アワード・フィーはより主観的に広い範囲のパフォーマンスから判断される。

レベニューシェア

開発するシステムから得られる収益を委託側が受託側にあらかじめ決められた配分率で分配する。

本稿の参考文献

• 「情報システムの信頼性向上のための取引慣行・契約に関する研究会」，平成19年4月，経済産業省商務情報政策局情報処理振興課
• 「共通フレーム2013～経営者，業務部門ともに取組む「使える」システムの実現～」独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼度化センター，2013年3月4日
• 「情報システム・モデル取引・契約書」第二版を公開
• イノウ，「IT の仕事に就いたら「最低限」知っておきたい最新の常識」，ソシム株式会社，2020年2月10日
• 「環境表示ガイドライン【平成25年3月版】」，環境省
• 要件定義～システム設計ができる人材になれる記事

ITの仕事に就いたら「最低限」知っておきたい最新の常識 [ イノウ ] 価格：1848円（税込，送料無料) (2022/3/13時点)