システム企画

2021年7月3日作成,2024年1月14日更新

目次

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

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

システム化計画

  • システム化構想の立案とシステム化計画の立案の目的,考え方,手順を修得し,適用する。
  • システム化計画の立案における検討項目を修得し,適用する。

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

表 システム企画の二つのサブプロセス
システム化構想の立案 業務の全体やそれを実現する構想を立案する。
システム化計画の立案 システム化構想を具現化する計画を立案する。

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

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

経営課題,経営要求,事業環境,業務環境,情報技術動向,業務分析,業務フロー,システム最適化手法,システム化構想書,システム化推進体制,BABOK(ビジネスアナリシス知識体系ガイド),BPR(Business Process Reengineering:ビジネスプロセスリエンジニアリング),SoR(Systems of Record),SoE(Systems of Engagement),SoI(Systems of Insight),Fit to Standard,OOBT(Out Of The Box)

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

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

業務フロー

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


    アクティビティ図とは UML(統一モデリング言語)の一種で「システム実行の流れと条件分岐」を図解したもの。上流行程のビジネスプロセスの流れや下流行程のプログラムの制御フローを表すことができる。
システム化構想書

地方公共団体の情報システム企画書の主な記載項目の例を次表に示す。(出典)平成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)

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

演習問題

"システム管理基準" によれば,情報戦略策定段階の成果物はどれか。

  1. 関連する他の情報システムと役割を分担し,組織体として最大の効果を上げる機能を実現するために,全体最適化計画との整合性を考慮して策定する開発計画
  2. 経営戦略に基づいて組織体全体で整合性及び一貫性を確保した情報化を推進するために,方針及び目標に基づいて策定する全体最適化計画
  3. 情報システムの運用を円滑に行うために,運用設計及び運用管理ルールに基づき,さらに規模,期間,システム特性を考慮して策定する運用手順
  4. 組織体として一貫し,効率的な開発作業を確実に遂行するために,組織体として標準化された開発方法に基づいて策定する開発手順
(出典)平成25年 秋期 応用情報技術者試験 午前 問64

正解は,2. である。1. 開発計画は企画業務における成果物,3. 運用手順は運用業務における成果物,4. 開発手順は開発業務における成果物である。

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

全体システム化計画,個別システム化計画,システム化計画の基本要件,システム化の目的,開発範囲,システム適用範囲,関連する情報技術の調査,業務モデルの作成,システム化機能の整理,システム方式の策定,サービスレベルと品質に対する基本方針,プロジェクト推進体制,プロジェクトオーナー(と実行責任者)

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

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

業務モデルの作成

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

表 システム化計画立案のタスク
基本要件の確認 開発や運用に関する基本要件,システム化構想の基本方針について確認する
対象業務の内容の確認 業務処理と情報を情報システムの視点から整理する
対象業務の課題の定義 業務の問題点を分析して,システム化によって解決すべき課題を定義する
対象システムの分析 業務のシステム機能やデータ,連携などについて確認・分析をする
適用情報技術の調査 業務の実現に必要な技術動向を調査する
業務モデルの作成 業務機能をモデル化する
システム化機能とシステム化方式の明確化 システム化機能を明確にする。機能実現に必要なシステム方式,データベース,サーバ,ネットワーク構成の概要を明確にする
付帯機能・付帯設備に対する基本方針の明確化 他システムとの連携や開発環境整備などに関する基本方針を明確にする
サービスレベルに対する基本方針の明確化 信頼性や性能,セキュリティなどのシステムのサービスレベルを明確にする
プロジェクト目標の設定 品質,コスト,納期について,目標値と優先順位を設定する
実現可能性の検討 各種要件が,要員,納期,費用などの前提条件で実現可能であるか検討する
全体開発スケジュールの作成 システム全体の開発スケジュールの大枠を作成する
システム選定方針の策定 ハードウェア,ソフトウェアの基本的な要件や予算枠を明確にする
費用とシステム投資効果の予測 システム実現時の効果を予測し,費用対効果によって投資効果を明確にする
プロジェクト推進体制の策定 プロジェクト推進体制を策定する
経営事業戦略,情報戦略及びシステム化構想との整合性検証 経営戦略や情報戦略,システム化構想を実現するものかどうかを検証する

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

① 全体開発スケジュール

サブシステム分割,優先順位付け,要員,納期,費用,品質,クリティカルパス

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

② 要員教育計画

教育・訓練の基本要件,教育訓練体制,スケジュール,対象者

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

③ 投資の意思決定法

PBP,DCF 法,NPV(Net Present Value:正味現在価値)

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

PBP (payback period method)

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

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

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

演習問題

IT 投資案件において,投資効果を PBP(Pay Back Period)で評価する。投資額が 500 のとき,期待できるキャッシュインの四つのシナリオ a ~ d のうち,PBP の効果が最も高いものはどれか。

a
年数 1 2 3 4 5
キャッシュイン 100 150 200 250 300
b
年数 1 2 3 4 5
キャッシュイン 100 200 300 200 100
c
年数 1 2 3 4 5
キャッシュイン 200 150 100 150 200
d
年数 1 2 3 4 5
キャッシュイン 300 200 100 50 50
  1. a
  2. b
  3. c
  4. d
(出典)平成28年 秋期 IT ストラテジスト試験 午前2 問4

正解は,d である。投資額を回収できるのは,a は 4 年目,b は 3 年目,c は 4 年目,d は 2 年目である。

DCF (Discounted Cash Flow) 法

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

NPV(Net Present Value)

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

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

正味現在価値 / 純現在価値
ROI(Return on Investment : 投資利益率)

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

ROI [%] = 投資による収益 ÷ 投資額 × 100
TCO(Total Cost of Ownership)

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

イニシャルコストの例
ハードウェア購入・設置費用,パッケージソフトの購入費用・開発費,初期教育費など
ランニングコストの例
保守・サポート契約費,ライセンス料,運用人件費,消耗品費など

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

投資種別の分類

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

表 投資種別の分類
投資種別 内容
業務効率向上のための投資 業務の効率向上,コスト削減を目的とする情報システム投資
戦略的投資 住民に対する新しいサービスの提供,地域振興などのための情報システム整備のように,特定の事業目的を実現することに重点を置いた情報システム投資
基盤投資 ネットワーク,認証基盤,クラウドコンピューティング基盤など,情報システム基盤に関する投資
義務的投資 制度改正への対応,国から指定された情報システム整備などの投資

④ 開発投資対効果

工数の概算見積り,開発効果の算定,概算費用の算出,IT ポートフォリオ,投資回収期間,NPV(Net Present Value:正味現在価値),システムライフサイクル

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

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

リスク分析の対象,リスクの発生頻度・影響・範囲,リスクの種類に応じた損害内容と損害額,リスク対応(リスク回避,損失予防,損失軽減,リスク移転,リスク保有など),財産損失,賠償責任損失,純収益損失,人的損失,リスク測定

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

要件定義

  • 要求分析と要件定義の目的,考え方,手順,代表的な手法を修得し,適用する。
  • 情報システム戦略との整合性の検証を修得し,適用する。

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

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

(1) 要求分析

① 要求分析の手順

ユーザーニーズ調査,現状分析,課題定義,要求仕様書,現状指向型アプローチ,目的指向型アプローチ,要求工学(Requirements Engineering)

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

演習問題

要件定義段階において,要求品質の向上のために発注者が留意すべきことはどれか。

  1. 現行システムと同じ機能の要求であっても,現行システムの機能や使われ方を調査して,要件定義を実施する。
  2. ビジネス要求の視点よりも,現行業務で使用されている機能が盛り込まれているか否かの視点で,要件定義の妥当性を検証する。
  3. 要件定義書はあくまでも利用者ニーズの大枠を定めたものとして,実際には設計段階以降に,受注者と議論して具体的な要件を確定していく。
  4. 要件定義段階では業務要件を整理し,システムの移行方法・運用方法など非機能要件は,システム稼働前に洗い出す。
(出典)平成25年 春期 応用情報技術者試験 午前 問65

正解は,1. である。

② 要求分析の手法

アンケート,インタビュー(構造化,半構造化,非構造化),親和図,機能分析,構造分析,データフローモデル,ペトリネットモデル,E-R モデル,並列プロセスモデル,ゴール指向要求分析(KAOS 法,アイスター),BABOK(ビジネスアナリシス知識体系ガイド)
インタビュー

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

構造化インタビュー
予め決められた質問紙やアンケートなどをもとに,対話をつづけていき,その質問(=調査者の側で構造化されており,質問されたほうも思考のラインで答えることができる)の間におこった質的な情報を記載する方法である。
半構造化インタビュー
予め質問項目を決めておき,それらを録音機(IC レコーダー)やメモなどで質問を続けていく。アンケートを用意し,それを取りながら(あるいは口実にしながら),それにまつわる情報を採集する方法もある。
非構造化インタビュー
構造化されていない質問を通して情報を,対話と観察のラインで調査者(インフォーマント) から引き出す手法である。
フォーカス・グループ・インタビュー
集団を相手に特定のトピックについて話し合う。調査者は談話のファシリテーターになったり,まとめたりする。

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

E-R モデル

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

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

(2) 要件定義

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

① 要件定義の目的

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

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

利害関係者の識別

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

要件の識別

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

要件の評価

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

要件の合意

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

② 要件の定義

業務要件定義,業務処理手順,機能要件定義,非機能要件定義,性能要件,セキュリティ要件,周辺インタフェース要件,情報・データ要件,運用要件,移行要件,保守要件
業務要件定義

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

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

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

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

機能要件定義

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

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

非機能要件定義

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

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

表 非機能要求グレード
カテゴリ 説明
可用性 システムを継続的に利用可能にするための要求
性能・拡張性 システムの性能と将来のシステム拡張に関する要求
運用・保守性 システムの運用と保守のサービスに関する要求
移行性 現行システム資産の移行に関する要求
セキュリティ 構築する情報システムの安全性の確保に関する要求
システム環境・エコロジー システムの設置環境やエコロジーに関する要求
演習問題

非機能要件の使用性に該当するものはどれか。

  1. 4 時間以内のトレーニングで新しい画面インタフェースを操作できること
  2. 業務のピーク時でも 8 時間以内で夜間バッチ処理を完了できること
  3. 現行のシステムから新システムへ 72 時間以内で移行できること
  4. 地震などの大規模災害時でも 144 時間以内にシステムを復旧できること
(出典)平成25年度 秋期 IT ストラテジスト試験 午前2 問5

正解は,1. である。

③ 要件定義の手法

プロセス仕様,DFD,DD(Data Dictionary:データ辞書),決定表(デシジョンテーブル),デシジョンツリー,UML,DOA(Data Oriented Approach:データ中心アプローチ),コード・ヨードン技法,シュレア・メラー技法

要件定義の手法には,構造化分析手法,データ中心分析手法,オブジェクト指向分析手法などがある。プロセス仕様を明らかにして 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 : システムインテグレータ)事業者にアウトソーシングすることも考えられる。

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

② 調達の計画

内外作基準,IFB(Invitation For Bids:入札募集)

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

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

③ 外部資源の利用

システムインテグレーター,SI 事業者,アウトソーシング,SaaS(Software as a Service ), ASP , IDC ( Internet Data Center ), SOA ( Service Oriented Architecture:サービス指向アーキテクチャ)を含むWeb サービス,ソフトウェアパッケージの適用,オープンソースソフトウェアの適用,OEM,ODM,ファブレス,ファウンドリ
システムインテグレータ

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

SI 事業者

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

アウトソーシング(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) 調達の実施

① 調達の方法

企画競争入札,一般競争入札,総合評価落札方式(加算方式),総合評価,価格評価,WTO 政府調達協定

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

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

企画競争入札(プロポーザル方式)

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

一般競争入札(最低価格落札方式)

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

総合評価落札方式

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

随意契約

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

② 情報提供依頼書(RFI)

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

③ 提案依頼書(RFP)

対象範囲,システムモデル,サービス要件,目標スケジュール,契約条件,ベンダの経営要件,ベンダのプロジェクト体制要件,ベンダの技術及び実績評価

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

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

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

表 開発委託用の提案依頼書の記載項目(例)
項目 内容
システム概要 システム化の背景,システム化の目的・方針,解決したい課題,狙いとする効果,現行システムとの関連,会社・組織概要,新システムの利用者,予算
提案依頼事項 提案の範囲,調達内容・業務の詳細,システム構成,品質・性能条件,運用条件,納期・スケジュール,納品条件,定例報告・共同レビュー,開発推進体制,開発管理・開発手法・開発言語,移行方法,教育訓練,保守条件,グリーン調達,費用見積り,貴社情報
提案手続 提案手続き・スケジュール,提案依頼書に対する対応窓口,提供資料,参加資格条件,選定方法
開発に関する条件 開発期間,作業場所,開発用コンピュータ機器・使用材料の負担,貸与物件・資料
保証要件 システム品質保証基準,セキュリティ
契約事項 発注形態,検収,支払い条件,保証年数(瑕疵担保責任期間),機密事項,著作権など
添付資料 要求機能一覧,DFD,情報モデル,現行フェイルボリューム,現行ファイルレイアウト

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

項目 内容
運用業務委託目的 システム運用業務を委託する目的
運用業務委託範囲と内容 委託するシステム範囲,委託する業務,委託する業務内容と役割分担,委託する機器内容
運用サービス要件 日常オペレーション,障害対応,システムソフトウェア/ハードウェア/ネットワーク導入・維持・保守,運用管理,クライアント対応,セキュリティ,施設・設備,サービス開始時期,貸与物件,資料,保証要件,気密保持,費用/契約事項
提案依頼事項 サービス内容,サービスレベル保証,セキュリティ,引継ぎ/移行,運用体制・要員,教育訓練,コミュニケーション,費用・契約,貴社情報
提案手続き 提案手続き・スケジュール,提案依頼書に対する対応窓口,提供資料,参加資格条件,選定方法
添付資料 新システムの導入目的と概要,システム運用の現状,システム運用リスク管理方針,ハードウェア構成,システムソフトウェア構成,ネットワーク構成

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

表 評価項目と配点
評価軸 評価項目 配点
要求仕様の理解度 要求仕様を正しく理解し,システム化の目的に即した,要求仕様を満足する内容が記述されているか。 システム化の目的と整合性 200
要求仕様に対する充足度 200
記述内容の具体性 機能要件,及びシステム構成,性能・信頼性など非機能要件への対応方法について,具体的かつ適切に記述されているか。 機能要件への対応方法 300
非機能要件への対応方法 300
その他の有益な具体的提案 100
計画の妥当性 提案内容を実行するための,作業項目,成果物,及びスケジュールが妥当であり,十分な体制が確保され,適切な手法で管理される計画となっているか。 作業計画 100
体制 50
管理手法 50
経験・スキル 事務センタの業務に関する知識が豊富で,類似システムの開発経験があるか。また,開発作業を適切に遂行できる十分なスキルのある人材が豊富か。 業務知識 50
開発経験 50
PM やリーダの保有資格やスキルレベル 100
(出典)平成21年度 春期 プロジェクトマネージャ試験 午後Ⅰ 問題 問2「外部委託先の選定」

提案価格については,想定される開発規模を基にした予算枠との差額について,次のように得点を付与する。

  • 提案価格が想定金額よりも低い場合には,想定金額との差額につき,一定の点を付与する。ただし,想定外に低い金額が提示された場合の問題を回避するために,価格天には上限を設ける。
  • 提案価格が想定金額よりも高い場合には,価格点は付与しない。

④ 提案書・見積書

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

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

表 システム提案書に記載する項目例
項目 内容
システム提案の目的
  • 業務の現状と問題点
  • システム化対象となる業務の範囲・領域
  • システム導入後の業務フロー
  • システム導入の効果(定性的・定量的)
導入システムの概要
  • 導入システムの構成
  • システムに利用するパッケージ・IT サービス・ハードウェア・インフラの概要
  • システムが提供するサービス・メニュー
  • システムの性能・品質要件
開発プロジェクトの進め方
  • 開発プロジェクトのスケジュール
  • 開発プロジェクトの体制(ユーザー企業,ベンダー企業)
  • システム開発の作業場所
  • システム開発の納品物
  • システム開発の前提条件(導入の課題)
コストとリスクの見積り
  • 開発コストの見積り
  • 利用するソフトウェア・ハードウェア・IT サービス・インフラの見積り
  • 費用発生スケジュール
  • リスクの見積り

⑤ 調達選定

原価構成,工期

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

⑥ 調達リスク分析

品質リスク,納期リスク,費用超過リスク,要員スキルに関するリスク

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

⑦ 契約締結

ソフトウェア開発委託モデル契約,情報システム・モデル取引・契約書,(準)委任契約,請負契約,知的財産権利用許諾契約,定額契約,実費償還契約(CPIF,CPFF),Time&Material 契約,ソフトウェア使用許諾契約,ライセンス契約,ランニングロイヤリティ,レベニューシェア,サブライセンス,グラントバック

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

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

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

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

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

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

"情報システム・モデル取引・契約書" によれば,ユーザ(取得者)とベンダ(供給者)間で請負型の契約が適切であるとされるフェーズはどれか。

  1. システム化計画フェーズから導入・受入支援フェーズまで
  2. 要件定義フェーズから導入・受入支援フェーズまで
  3. 要件定義フェーズからシステム結合フェーズまで
  4. システム内部設計フェーズからシステム結合フェーズまで
(出典)平成26年 秋期 応用情報技術者試験 午前 問66

正解は,4. である。

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

中小のユーザ企業がパッケージソフトや 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)では,購入者は作業にかかった妥当な実費総額に加えて,納入者の利益となる報奨金を納入者に支払う。契約時に取決めを交わすインセンティブ・フィーに対して,アワード・フィーはより主観的に広い範囲のパフォーマンスから判断される。
レベニューシェア

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

本稿の参考文献


inserted by FC2 system