システム戦略(2)
システム企画
システム化計画
 
情報システム戦略に基づいたシステム化の構想とシステム化の基本方針を立案し、対象業務を分析して、各システムの開発順序や概算コスト、効果といったシステム化の全体像を明らかにする。システムの導入には業務のどこからどこまでをシステムに反映させるのかを見極めておく必要がある。適用範囲は大きいと使いこなせず、小さいと効果が出にくくなるため、最適な適用範囲を設定することが必要です。また、開発するシステムの費用対効果の考慮も欠かせない。システム開発から運用に至るまで、効果に対して費用が掛かりすぎれば採算が取れない。目標とする費用対効果は、常に評価する必要がある
システム化の適用範囲
システムの導入には業務のどこからどこまでをシステムに反映させるのかを見極めておく必要がある。適用範囲は大きいと使いこなせず、小さいと効果が出にくくなる
費用対効果
開発するシステムについて「費用対効果」があるかどうかの検討は、経営戦略の成否にかかわるため、大変重要。開発・運用にかかる費用を割出、その費用を上回る利益や費用に対応した効果が見込めるかどうかを検討する必要がある
スケジュールの検討
システム化計画では、経営戦略に基づいたシステムが必要になる時期を最終目的として、システムの構築順序から業務の移行、教育、訓練といったものをすべて踏まえ、全体的な開発のスケジュールを組む
開発体制の検討
開発スケジュールに則り、開発に携わるシステム開発部門や、実際にシステムを利用するユーザ部門(業務部門)を含め、適所に適任の責任者と業務担当者といった人員配置を行う
リスク分析
システムの開発から運用までに、リスクがどのような形で潜んでいるかを検討する。リスクの発生やその影響といった部分を測定しておくことでその対処への順位を決めておく
リスクの種類 | 原 因 | |
---|---|---|
ハードウェア障害 | ・電源の入れ忘れ ・機器の設定ミス | ・機器の接続不良 ・機器の故障 など |
ソフトウェア障害 | ・ユーザの操作ミス ・OSやソフトウェアの設定ミス | ・ソフトウェアのバグ ・コンピュータウイルス など |
ネットワーク障害 | ・ケーブルの断線 ・ネットワーク機器の設定ミス ・ネットワーク機器の故障 | ・IPアドレスの設定ミス ・制約の違反 など |
データ障害 | ・データの破損 ・データの形式が異なる | ・フォーマット形式が異なる ・データの記憶領域の不足 など |
性能障害 | ・メモリの不足 ・ディスク容量の不足 ・データ量の増加 | ・ファイルの断片化 (フラグメンテーション) など |
災害による障害 | ・火災、水害、地震の発生 など |
リスク対策
リスク分析の結果に基づいて、情報資源を維持するための具多的な対策を決定する。損失の発生を防止、軽減するための主な手法4つを下に挙げる
リスク回避 | リスクが発生しそうな状況を避けること | 情報資産をインターネットから切り離す 情報資産を破棄する |
---|---|---|
リスク低減 | 損失を招く原因や情報資産を複数に 分割し、影響を小規模に抑えること | 情報資産を管理するコンピュータや 人材を複数に分けて管理する |
リスク転移 | 契約などにより、他社に責任を移転する | 情報資産の管理を外部に委託したり 保険に加入したりする |
リスク保有 | 自らが責任を負い、損失を負担する リスクがあまり大きくない場合に採用 | 引当金や補償金を用意して対応する |
要件定義
システム化をするために必要となる業務内容や業務フローといった要件を定義したもの
業務要件の定義
経営戦略やシステム戦略、利用者のニーズなどを考慮し、システムに求める機能や要件を定義する
利用者の要求を調査・分析
利用者の要求を調査し、調査内容を分析することで、業務の遂行に必要案機能や業務フローの改善要求、ヒューマンインタフェースの設計などを定義する
現行業務を分析
システム化に必要な内容であるかを検討するため、現行業務を分析することも大切

機能要件の定義
システム化を行う業務そのものである機能要件を定義し、具体的に実現する内容を整理する
ソフトウェアライフサイクル
全体的なシステム化を計画するにあたり、全体的なプロセスの流れである
「ソフトウェアライフサイクル」を考慮することが重要
調達計画・実施
システム化の推進を行うために、要求事項に合う製品やサービスを調達する必要がある。要件定義の内容を踏まえ、規制の製品やサービスを購入するか、内部でシステム開発を行うか、外部にシステム開発を委託するかといった調達方法を決定し、調達の際の条件などを定義し、「調達計画」を策定する
調達の流れ
情報提供依頼書(RFI)の作成
「情報提供依頼書」は発注先となる企業に対して、システム化に関する情報提供を依頼する文書のこと。 システム化に必要なハードウェアやソフトウェアなどの技術情報や同業他社の構築事例、運用・保守に関する情報を広く収集することが可能
提案依頼書(RFP)の作成・配付
「提案依頼書」はベンダ企業に対して、導入システムの概要や提案依頼事項、調達条件などを明示し、提案書の提出を依頼するための文書のこと。提案依頼書にはシステム概要や目的、必要となる機能や求められるシステム要件、契約事項といったシステムの基本方針を盛り込む。発注予定となる企業への提案依頼という役割のほかに、事前にシステムの要件を明らかにすることで、実際の開発段階に入ってからの混乱を未然に防ぐ役割も担っている
提案書の入手
ベンダ企業においてRFPを基にシステム校正、開発手法などを検討し、提案書を作成、依頼元に対して提案する。依頼元の企業は、提出された提案書を評価し、発注先の企業の選定資料にする
見積書の入手
見積書はシステムの開発、運用、保守などにかかる費用を示す文書。取引先の選定や発注内容の確認に重要な役割を持っており、発注元の企業はこれを選定基準と照らし合わせて最終決定を行う
発注先企業の選定
名 称 | 説 明 |
---|---|
企画競争 | 複数のシステムベンダなどの企業に対して企画書の提出やプレゼンテーションの実施を求め、提案内容を競争させて調達先を選定する方法 |
一般競争入札 | 入札情報を公告し、一定の参加資格を満たしたすべての参加者に対して、見積書の提出を求め、価格を競争させて調達先を選定する方法 |
契約締結
事前に契約内容を明らかにしておくことで、口約束や曖昧な発注による開発現場の混乱や紛争の発生、納期の遅れ、システム障害などのトラブルを未然に防ぐことができる
作業範囲記述書(SOW)
プロジェクトの目標、作業範囲、納入時期などを記載した文書のこと。一般的に、委託・受託関係において契約書の付属文書として作られることが多い。作業途中で要求事項に合っているかを確認したり、作業後に契約内容に合った性能かどうかを判断したりする基準となる。関係者の合意形成を円滑に進めるためにも重要な書類となる
製造業の業務の流れ
@購買:必要な原材料や設備を購入する
A原材料により製品を製造する
B製造した製品を顧客に販売する
販売業務の流れ
@受注:顧客からの注文により受注処理を行う
A在庫引当:発注した商品の在庫を確認する
B出荷指示:在庫がある場合には出荷を支持する
Cピッキング:出荷指示に従って商品を倉庫から取り出す
D積載:商品をトラックなどに積み込む
E配送:商品を顧客に配送する
販売業務における書類のやり取り
@見積書:顧客の購入要求に対して、商品の金額、納期、支払方法などを提示する
A注文書(発注書):顧客が商品を企業に注文(発注)する
B注文請書:企業が顧客からの注文を受けたことを知らせる
C納品書:企業が顧客に納品した商品を知らせる
D受領書(検収書):顧客が商品を受け取ったことを企業に知らせる
E請求書:企業が顧客に対して代金を請求する
F領収書:企業が顧客から代金を受け取ったことを知らせる
 

