Transcript システム開発計画 - 教職員・研究者のためのコンピュータ利用案内

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