2章まとめ

第2章まとめ
山本恭平
1
目次



２－１システム化のプロセス全般
２－２システム化における各種法
２－３プロジェクト管理
2
２-１システム化のプロセス全般
山本恭平
3
全社情報化中長期計画

会社の情報化計画は、経営計画とリンクされて
いなければならない

事業部門の経営計画の中から情報化ニーズを
吸い上げる必要がある
4
経営計画と情報化計画

いかなる企業も中長期経営計画を作成する

計画には、人、物、金の他に情報も重要な経営
資源であるという認識の下に、情報化計画が含
まれるのが一般的

情報化はそれ自体に意味があるわけでなく、あく
まで経営を支援する手段
5
全社情報化中長期計画（１）


立案はシステム部門が担当
各事業部門からの事業計画の中にすでに含ま
れている
6
全社情報化中長期計画（2）

各事業部門で共通に利用できると思われるハードやソ
フトは、どのようなものであり、どれくらいの投資額にな
るかを大まかに見積もる

全社情報化中長期計画の要点

各事業部門のシステム化計画の適否や優先順位を決
定
全社共通インフラ(ハード、ソフト)計画を作成
全社的な投資計画や推進方針などを立案


7
全社情報化中長期計画（3）
8
全社情報化中長期計画（4）

情報化の案件は専門的な検討が必要なため経
営会議の事前審議を行なう専門委員会を設置し
ている場合が多い

審議の要点
提出された情報化計画が中長期的に経営にどう
寄与するか
投資額として会社の実情に見合っているか


9
全社情報化中長期計画（5）


承認された計画
個別案件を推進していくが、多額の投資を伴う
場合は実行段階で、委員会、経営会議の審議
が必要
10
費用の年度計画(1)

各事業部門及びシステム部門は、年度計画(上
期、下期)を立案

上期末には当初の下期計画を見直す
各部門にとって活動計画の全般にわたる費用の
予算・実績をトレースする作業

11
費用の年度計画(2)



投資額は、ハード関係は固定資産として、ソフト
外注費は無形固定資産として償却され、各期に
費用として計上
ソフト外注費は5年間に固定されている
ハードはリースする企業も多く見られる
12
費用の年度計画(3)

費用の年度計画の数値が今後の投資計画すな
わちシステム計画に影響を及ぼすことがあると
いうことを知っておかなければならない
13
費用の年度計画(4)

情報化の効果は長期的な企業の体質向上など
が主目的になることが多い

各事業部門に情報化のコスト意識を持っても
らうために、システム部門の費用は、各事業
部門に直接付け替えられるか、予算立案時
に費用配賦するという制度をとっている企業
が多い
14
システム開発計画


ユーザ部門中心で検討
システム開発計画の作成の順序
システム開発の手順を明らかにし、現状の調査分析を行う
業務設計、システム機能の検討
システム構想を作成
実現させる手順を検討
システム開発計画を立案
15
システム開発計画

次のステップ
企業の決済基準に従い、委員会、経営会議の承
認を受ける
システム開発を進める

承認を得るためには？
16
システム開発計画に盛り込む
べき必要事項(1)
17
システム開発計画に盛り込む
べき必要事項(2)
経営者の関心
・費用対効果がどうなるか
つまり・・・
→経営者に該当条件の定性効果をわかりやすく説明し、
了承してもらうことが大切
例）



「在庫の縮小」→「3ヶ月分の在庫を1ヶ月分に減らす」
「納期の短縮」→「納期を1ヶ月から20日に短縮する」
「決算日程の短縮」→「財務諸表の出力を月初10日から月初3
日に早める」
18
システム開発計画に盛り込む
べき必要事項(3)


期待効果の確認は実施例の調査が良い
ユーザ部門が前面に出るように仕組む事が必
要
19
システム化に伴う業務の見直し(1)

共通フレーム98(SLCP-JCF98)の業務の視点から見たソフ
トウェアのライフサイクル
企画プロセス→開発プロセス→運用プロセス→保守プロセス
20
システム化に伴う業務の見直し(2)

現実には「コンピュータ化以前の問題」という状況

システム部門もシステム化の早期検討段階から
入っていくことが必要

ユーザが真剣に考えるように、うまく関わってゆ
くことが大切
21
外部SEなどのシステム開発計
画への参画

企画プロセスは顧客の中でもユーザ部門の仕事だが、これ
をコンサルティング会社やベンダーやソフトハウスが中心的
役割を担う場合がある。
ソリューション
22
外部SEなどのシステム開発計
画への参画(1)
23
外部SEなどのシステム開発計
画への参画(2)

顧客(ユーザ部門・システム部門)とコンサルティ
ング会社やソフトハウスのSEとでプロジェクト
チームを編成して、調査分析やシステムの仕様
検討といった作業を進める
24
外部SEなどのシステム開発計
画への参画(3)

開発者が行う開発作業は、ユーザ側から提示さ
れた要求仕様書を確認する要件定義からスター
トし、開発プロセスは
要求定義→システム設計→プログラム開発
25
外部SEなどのシステム開発計
画への参画(4)
26
システム開発プロセス

開発効率やソフトウェアの品質がよくわからない
といった問題
色々な開発モデルが提唱
大きく分けて
 ウォーターフォールモデル
 ノンウォーターフォールモデル

27
ウォータフォールモデル(1)
28
ウォータフォールモデル(2)

開発プロセスをウォーターフォール（滝）のように順
次実行していくやり方
29
ウォータフォールモデル(3)






メリット
大規模システムに有効
バリエーションが豊富
どんなシステムでも原則的に通用
デメリット
開発期間が長い場合に、要件定義に存在する欠陥の発見
が遅れる（特にV字型モデル）
ノンウォータフォールモデル
30
ノンウォータフォールモデル(1)

基となっている開発手法：プロトタイピング法

初期段階でシステムのプロトタイプを作成しユー
ザー部門がチェック

現実的には、サブシステム単位で作成し、部
分的に更新してユーザー部門がチェックし、
プログラムの改善を行う
31
ノンウォータフォールモデル(2)

ユーザーの反応を見ながら、スパイラル的に行
うことから、スパイラルモデルとも呼ばれる
32
システム保守の重要性(1)

システムライフサイクルは、開発、運用(保守)、
再開発

現実にはシステム保守が重要な意味を持ち、長
期的にみるとコストもかかる

開発期間は平均2～3年程度に対し、保守期間
は一般的に10年間程度
33
システム保守の重要性(2)

システム保守の種類
修正のための保守
改訂のための保守

システム開発後、地道なシステム保守こそ重要


34
システム保守から学ぶこと
システム効果の確認
次の開発へのフィードバック
2. 優れたシステムの学習及び業務知識の吸収
次の開発への準備
1.
35
2-2 システム化における
各種方法・手法
４４０５０８７宮崎雄吾
36
システム化における各種方法(1)
システム開発状況の視覚化＝
「文書化」
37
システム化における各種方法(2)
38
システム化における各種方法(3)
DFD:フローとストックを記述す
るもの。
ER図：DFDに既述されたデー
タストック（データストア）を
正規化し作成するもの。
39
システム化における各種方法(4)
・文書化の留意事項
１. DFDやED図以外の記述は一般技術文章に従う。
２. 仕様書には目的を必ず記述する。
３. 文章を構造化する。
４. 次の工程の担当者にわかりやすいように、フォーマットを統一する。
40
システム化における各種方法(5)



見積手法
ソフトウェアの見積もりは非
常に難しい。
上流工程ほど見積と実績の
差が大きくなる。
41
システム化における各種方法(6)
・２・４・２・３の法則
42
システム化における各種方法(7)

概算・積算見積法
・概算法は過去のソフトウェアの経験に基づいて見積もる
方
法。
・積算法は作業を洗い出しその工数を過去の経験によって積み
上げる方法。
43
システム化における各種方法(8)

見積モデル
プログラムのステップ数から工数を見積方法。
Dotyモデル、COCOMO、Putnamモデルなど。
工数＝F（ステップ数、開発環境係数、開発要員係
数・・・）
44
システム化における各種方法(9)

ファンクションポイント
法（FP法）
・見積方法のひとつ。
・良く使われる手法の一つ。
45
システム化における各種手法
・スケジューリング手法

第１次作業計画
システム稼動時期を確定し、システム開発の承認を得る
こと。

第２次作業計画
稼動時期を遵守するため、より詳細で実行可能なマス
タースケジュールやワーキングスケジュールを作成する。
46
スケジューリング手法の詳細
47
WBS

WBSとは…
要件定義から外部設計、内部設計等への過程におけ
る作業を洗い出し構造的に表現したもの。
48
システム開発のWBS
49
ネットワークダイアグラム
ネットワークダイアグラムとは…
WBSで洗い出された作業順序を決定し、作業計画を立
てる際に用いる表記法。
 プレジデンスダイアグラム法
 アローダイアグラム法
の２種類がある。
50
プレジデンスダイアグラム法

作業を表現するのにノード、作業順序を表現するのに
アローを用いる表記法。
51
アローダイアグラム法

作業を表現するのにアロー、作業順序を表現するのに
ノードを用いる表記法。
52
クリティカルパス

クリティカルパスとは…
計画全体の完了期日に影響を与える工程「クリティカ
ル」の経路のこと。
53
ガントチャート

作業の開始日、終了日、期間などを簡単にして図に
表したもの。
54
２-３プロジェクト管理
４４０５０１９小尾雅人
55
プロジェクトという仕事の特徴

プロジェクトの特徴

活動期限が限られている

システムはプロジェクトごとに異なる

仕事の進め方が定型的でない
56
プロジェクト管理の体系
「当たり前のことをキッチリやる」ことが最重要
プロジェクトの計画と管理
目標の計画と管理
コストの計画と管理
期限の計画と管理
目標の設定
予算立案
作業の洗い出し
変更管理
予算・実績管理
スケジュールの作成
欠陥管理
スケジュールの管理
57
プロジェクト計画

目標の計画


コストの計画


目標とは経営課題や企業の抱える問題点をシステム
的な観点から解決すること
コストは人件費、ハード、パッケージソフトから構成さ
れる
期限（スケジュール）の計画

クリティカルパスを明確にし、クリティカルな工程を重
点的に管理することが重要
58
プロジェクト管理

目標の管理


予算の管理


作業の適当な時点での「ウォークスルー」（関係者の
レビュー）が大切
作業実態はどうなっているのかを把握すること（進捗
管理）が重要
期限（スケジュール）の管理

予算管理と同じく進捗管理が重要
59
プロジェクトチームの編成

メンバー編成のプロセス

プロジェクトを強力に推進するリーダーを選ぶ

決定権限者を参画させる

仕事のできる実務担当者を参画させる
60
理想とされるプロジェクトリーダー






自社のあるべき姿を認識している
課題や問題点を客観的に把握している
妥協点を探る調整能力がある
社内の各部門に対する説得能力がある
使命感があり、経営陣の信頼が厚い
オープンな議論ができる
61
開発要員の変動

プロジェクトチームは開発プロセスに応じて変化
する

質的な仕事から、量的な仕事に移行していく

無計画な要因の増加は失敗の元
62
プロジェクトチームの形態

全社的か、部門的か

これによりチームの形態やメン
バーが変わってくる。
プロジェクトチーム
ユーザ
開発
63
一般的なプロジェクトチーム形態

図１大規模システムのプロジェクトチームの形態
プロジェクトリーダー
事務局・スタッフ
Ａサブシステム
Ｂサブシステム
チームリーダー
チームリーダー
・・・
メ
ン
バ
ー

・・・
メ
ン
バ
ー
メ
ン
バ
ー
・・・
メ
ン
バ
ー
プロジェクトリーダー
・・・顧客のシステムを利用する部門
の実力管理者なることが大切。
64
プロジェクトチーム形態の別の
見方
システム部門要員とソフトハウス要員が
区別されてない。



自社開発
一括外注化
ユーザ部門による開発
65
プロジェクト管理の要点
（リーダーの役割）
プロジェクト管理
・・・ルーチンワークよりも一層高い
管理スキルが求められる。
管理者にはEQの高さが、IQや専門スキル
よりも重要。
66
リーダーシップを発揮すること（1）

リーダーシップ
・・・目標を達成するために、メンバーに
その目的や方針を理解させ、自ら行
動を起こす影響を与える力。
67
リーダーシップを発揮すること（2）


リカートによると・・・
リーダーは民主的であることを基本に、
ときには専制的であることも必要。
リーダーたる者はプロジェクトに対する
「情熱」を持たなければならない。
68
リーダーシップを発揮すること（3）

目的・構想、戦略・方針をメンバーに熱く伝えること

メンバーに対して意識付けをすること

メンバーのモチベーションを向上させること

コミュニケーションをうまく図ること
69
科学的にアプローチすること（1）

ものごとを総合的に見ること
「部分の総和は必ずしも一致しない」
リーダーは全体を見渡して問題
を解決することが必要。
70
科学的にアプローチすること（2）

QCサイクルの実践
P-D-C-Aサイクル・・・仕事を論理的に推進
していく。
進行状況は目には見えないので、事実を正確に
把握することは非常に難しい。
71

Download Report