Transcript 3章のまとめ - 教職員・研究者のためのコンピュータ利用案内

３-１ 開発計画とは
手順・その対象範囲
４４０５０３７坂本
1
開発計画に至るまで(1)

開発計画はプロジェクトの一部だが、そこに至る
経緯によってその様子、性格が決まる

プロジェクトの必要性がどこからきたのか？



買い換え？
経営上の戦略？
顧客のもつ問題意識の差に違い
2
開発計画に至るまで（2）
では（顧客の意識により）変わらないものは何
か？
→システムは単にシステムだけで成り立ってはい
ない
システムとは仕事や情報の流れ、関係のこと

3
開発計画に至るまで（3）

顧客の視点からシステム開発に望んでいること
は何か？




これにより仕事がもっと楽になるのではないか
売り上げが伸びるのではないか
在庫・棚卸し資産が減るのではないか
個人やチームの能力が向上するのではないか
といった事を暗に求めている！
4
開発計画に至るまで（4）

顧客の経営、業務問題の解決・改善のため
に・・・




業務の仕組みを再構成・再考察
ユーザーの必要にあったものを
実際に活用してもらえるシステムを・・・
システム開発とは業務の改善・改革活動だとい
う認識が必要！
5
開発計画の手順
（１）システムの目的・対象業務・範囲の明確化
（２）組織が置かれた状況を概観、目標達成のため
の新たなシステムを構想
（３）その具体的な実現方法を考察
（４）実現方法のプロセスを展開、機能を定義
（５）システムの概形を設計
6
開発計画の手順（2）
（６）どのように作るか？推進計画を策定
（７）具体的な作成日程を決定。計画を立案
（８）投資対効果を検討し、経営陣に提案
（９）細かな規定・指示・指針・検討事項を文章化す
る
→ユーザ部門・システム部門の応援が不可欠
7
開発計画とは・・まとめ


（１）プロジェクトの立ち上げ
（２）システム構想の立案


（３）システム化計画の立案


業務の改革・改善
システムの開発
（４）実際の活用をフォロー
8
３-２ 開発計画プロジェクト
の立ち上げ
４４０５０４９ 砂押佳佑
9
プロローグ

検討の始まりは何らかのきっかけから
↓
きっかけは経営レベルから来ることも、オペレー
ションレベルから来ることもある。
↓
プロジェクトチームの性格を決める
10
開発計画策定へ向けた活動計
画の立案

情報システムの開発計画を立案するには、開発
計画で解決すべき課題を整理する必要がある。

課題は組織の活動に関係したものが大半を占
める。そのため、開発計画を策定するプロジェク
トを立ち上げて、専門技術あるいは業務に精通
した関係者が集まって検討する必要がある。
11
プロジェクトを立ち上げに至る
までの主な活動
活動項目
活動内容
基本方針の設
定
・企業の経営方針・企業（部分）目標・中長期
の構想などの確認・プロジェクトの目的・目標
の設定
開発計画策定 ・対象範囲、実行方法の検討・投入リソース
に向けた活動計 （期間、予算、人材）の検討・活動計画の作
画の立案
成・関係者との合意の形成
プロジェクトチー ・プロジェクトメンバーの選定
ムの編成
・プロジェクトの立ち上げ
12
対象領域の絞り込み

プロジェクトの活動計画を検討する上では、対象
領域の選定とプロジェクトチームの編成の2点が
ポイント。

対象が漠然とした状態からスタートしたプロジェ
クトでは、開発計画の策定より事業戦略の検討
のほうが中心。
13
システム化領域の選定
14
プロジェクトチームにおける
SEの役割
情報システムを構築するということは、業務と情
報技術を組み合わせて新しい仕組みを創造する
ことを意味する。
↓
開発計画を策定するということは、経営層や
ユーザ部門の要求に基づいて、情報システムの
具体的な仕様をまとめ上げ、それを実現する実
行計画を作ることを意味する。
15
開発計画の立案に参加する
ＳＥに期待される役割

開発計画の立案に参加するＳＥには開発計画を
立案するプロジェクトのガイド役としての役割が
期待される。具体的には




情報技術が業務にどう活用できるかを提案する
プロジェクトの進め方をガイドする
仕様の記述方法を指導する、あるいは、ユーザ部門
と一緒に使用を作成する
計画のフィージビリティスタディ（実現性の評価）を行
う
16
プロジェクトの立ち上げ（1）

大まかな手順としては、




ある程度の方向性と基本的な構想がまとめる
プロジェクトチームを編成
計画内容と方針をメンバーに説明
異論があるなら議論する
17
プロジェクトの立ち上げ(2)


最初は、ある程度人数を絞った企画チームで計
画のコアを固める。
徐々にメンバーを加えつつ、最終的には関係部
門の代表者をメンバーとするプロジェクトチーム
へと移行。
18
開発計画策定に向けた活動計
画例
項目
内容
目的
商社・代理店の販売力強化
対象業務
販売管理
実施事項
(1)商社・代理店を含めたビジネスプロセ
スを見直し、それに対応した販売管理シ
ステムを再構築する(2)現行システムをメ
インフレームからオープンシステムに移行
させる
推進体制
営業部門の担当役員を責任者とするプロ
ジェクトチームを結成する
スケジュール 構想立案１年、システム開発１年、２年後
稼動
19
3-3システム構想の立案
4405023 加治正記
20
システム構想を立案する手順(1)
現状の調査・分析
図1 システム構想を立案する手順
21
システム構想を立案する手順(2)
表1 システム構想の立案における主な活動
22
現状調査・分析(1)

調査分析
1.
目的をはっきりさせる
その目的にあった調査方法を選択し実行
調査した事実に基づいて問題を構造化
2.
3.
問題の真の原因を分析
23
現状調査・分析(2)
一般的な調査項目

ビジネス環境：

現行業務：

情報システム：
市場、競争先、取引先、法規制など
組織・業務上の課題、技術動向、業界動向など
現行システムの機能、アーキテクチャ、
処理能力、保守・運用方法など
24
現状調査・分析(3)
■
A社の調査結果
1. 商社・代理店での戦略製品の販売は既存の顧客が
中心で、対象の市場は広がっているのに新規顧客の開拓が
できていない。
2. 営業部でも新規顧客からの引き合いに満足な対応ができていない。
3. 商社・代理店の営業担当者に新製品情報が浸透していない。担当者は資
料を読むだけでは理解できない 。
4. 事業系列を超えた製品を組み合わせた注文が多いが、事業部システム
に別個に照会するのが面倒である。
25
業務のあるべき姿の検討(1)

SWOT分析
外部環境、内部環境の分析から事業の方向性を
見出す手法
S
W
O
T
…
…
…
…
Strength
Weakness
Opportunity
Threats
（自社の強み）
（自社の弱み）
（自社にとっての機会）
（自社にとっての脅威）
26
業務のあるべき姿の検討(2)

A社の対象業務とシステム機能
1. 商社・代理店が直接納期や在庫を確認して注文できる
2. 事業部システムの照会業務機能を販売管理システムの中に
一元化する
3. インターネットを活用して新製品情報を提供するなど 、
最終顧客と直接コンタクトする
4. 商社・代理店の営業担当者を対象にした Webトレーニング
システムを導入する
27
業務のあるべき姿の検討(3)
現状
構想案
図2 A者営業業務モデル
28
ギャップ分析
“あるべき姿の現実のギャップ”
“ギャップが大きければ
段階的な構築を検討する“
図3 ギャップ
29
業務プロセスへの展開(1)
概念的業務モデル
業務プロセス
オペレーションズレベル
業務プロセスの再構成
30
業務プロセスへの展開(2)

A社業務組織面の主な課題
1. 売り上げ規模の異なる商社と代理店とで別の営業支援
機能で別メニューで提供すること
2. 製品情報の提供や営業担当者の教育の担当窓口を
一本化すること
3. 新規顧客への対応やサービス機能を充実させるための
専門組織が必要となること
31
業務プロセスへの展開(3)
図3 A社営業業務モデル （改定案）
32
システム方式の策定(1)

情報システムの概略の設計
新たな業務プロセスの各機能
● 情報システムで行う
● 人手で行う
情報システムの
システム機能、使用するハードウェア・ソフトウェア
構成をそれぞれ定義
33
システム方式の策定(2)
1 . 導入システム
導入システム機能を以下のように定め、それぞれの処理フ口ー、処理機能、
関連データを定義。
( 1 ）販売管理システム
基本的な機能は従来のシステム機能を踏襲する。
商社・代理店へ提供するシステム機能を追加する。
エンドユーザの要望を取り入れ、一部の機能を改善する
( 2 ）情報提供システム
自社ホームぺージとは別に製品情報を提供する Web サイトを立ち上げる。
最終顧客向けの製品情報と営業担当者向けの教育コンテンツを本システムから
提供する。コンテンツ作成ソフトはパッケージソフトを購入する。
34
システム方式の策定(3)
2 . システム構成
使用する機器（サーバ、 PC ) の仕様、導入台数の概算、既設 PC を
活用するための追加ソフト
3 . ネットワーク構成
商社・代理店とのネットワーク接続方法、営業拠点との回線増強の
要求内容
35
3-4 システム化計画の立案
4405086 三堀慎太郎
36
システム化計画の概要
システム面→システム化計画として具体化
人の作業→業務改革計画もしくは業務改善計画と
して策定
37
システム化計画の基本要件の
確認
38
その他の要件の考慮事項
・新システムへの移行方法
・ソフト開発の利用環境や稼動後の運用環境
・教育訓練・品質管理体制・セキュリティー対策を検討。
39
開発計画の策定
各業務機能別の稼動時期を設定
↓
業務面、システム面の作業課題をスケジュール化
マスタースケジュールの作成
開発推進体制の立案
40
システム構築の
プロジェクトチーム体制例
業務改革チーム
システム改革チーム
41
費用と期待効果の算定と評価
・一時費用→機器の取得費、ソフト開発費
・運営費用→稼動後に発生
42
一時費用と運営費用
43
費用と期待効果の算定と評価
（1）



定量化効果→システム構築の期待効果を金額換算
定性的効果→金額換算できない
効果が見込めない場合は？
→プロジェクト開始時の基本的方針に誤りがあったということ
44
費用と期待効果の算定と評価
（2）


計画内容の妥当性を判断
基準に達しない場合
→計画の差し戻しもある
45
3-5 開発計画書の作成
山本恭平
46
開発計画書の用途（1）

システム構築プロジェクトの進捗管理や稼動後
の評価などに活用

それ以外にも、ＲＥＰ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｐｒｏｐｏｓａｌ）
の作成などにも利用
47
開発計画書の用途（2）
48
開発計画書の用途(3)
49
組織名の変化

情報システム部門は組織名がたびたび変化
－１９６０年代 経理部門 → コンピュータ室
－１９７０年代 情報システム部、システム部
－１９９０年代 情報企画部、情報企画室

情報技術の進歩や経営からの要請の変化に対
して部門としての役割を変えてきた結果
50
作成者とまとめた人
作成者
 3-1
坂本 康輔
 3-2
砂押 佳佑
 3-3
加治 正記
 3-4
三堀 慎太郎
 3-5
山本 恭平
まとめは 坂本 康輔でした。

51