1.2 プロジェクト計画


 プロジェクトに先だって、その計画を立てることは必須である。ここではそのプロジェクト計画の重要性についてのべる。


1.2.1 プロジェクト計画とは
 プロジェクト計画は、プロジェクトのスムーズな遂行において不可欠なものである。したがって、プロジェクト計画は明確な表現であり、事前に関連各人に周知され承認される必要がある。
 プロジェクト計画とはそのプロジェクトを遂行していく上での柱であり、逆にその計画が明確に定義されていない場合、実質的にプロジェクトは成立しない。

(1)目的
・ システム化の目的、ねらい、課題
・ 現行システムの問題点
・ 要求分析

(2)基本構想
・ 経営戦略を支援するための情報化戦略
・ 課題およびニーズへの対策
・ 対象業務の重要ポイント
・ 戦略計画重視型
・ ブレークスルー指向型

(3)開発体制
・ システム開発の体制(人、組織、方式)
・ PMO、プロジェクトチーム
・ ユーザ
・ 運営方式

(4)スケジュールと対象システム
・ システム開発日程計画
・ 対象システムの優先順位
・ 開発手順(ウォータフォールモデル、プロトタイピング)
・ 対象業務概要

(5)開発環境と利用環境
・ 開発のためのハード等周辺機器
・ ユーザのためのハード等周辺機器

(6)事前評価
・ システム化計画を事前に評価
・ 経営戦略と情報戦略の関連性
・ システムの経済性評価
・ 情報の価値基準


1.2.2 計画のポイント

 プロジェクトの計画を策定する上でさまざまな要件が考えられる。プロジェクトによっては下記にしめすもの以外にも、計画段階で決定しておくべきものもあると思うが、最低限下記の要件は必須であろう。これらのポイントをおさえておかないと、後々プロジェクトの進捗で障害となって露見する危険性が高くなる。
・ 事前評価による推測、効果予測
・ 決意、方針、計画のまとめ
・ トップマネジメントの責任ある決断
・ システム開発計画書の作成
・ チーム、スタッフ、ユーザ等への周知徹底


1.2.3 システム開発計画の詳細

 システム開発の個々の計画に盛り込むべき内容は、以下のようなものがあげられる。これらの要件は、必要条件でありこの他にも考慮すべきポイントは多々存在するはずである。ここでは、システム開発計画における、より基本的な考慮点を挙げた。なお、マシンの新設およびリプレースを伴わない開発において省略できるポイントも、ここでは挙げている。

(1)ユーザニーズ調査分析
・ 関連部門の要員、システム部門の要員、上級管理者、経営者のニーズ調査と分析を行う。
・ 調査対象者の選択、調査範囲は十分注意して策定する。
・ インタビュー、アンケート、関連帳票等資料の収集。最初は極力広範囲に行う。その後段階的に局所的にしぼり込み、取捨選択を行っていく必要がある。
・ 曖昧な点、不完全な点は何度も確認し、誤解や取り違えのないよう気をつけること。文書で意見交換する方が望ましい。

(2)技術動向調査分析
・ ホストマシン、ワークステーション、パソコン等の情報機器や、開発ツール、開発技法等の技術動向の調査、分析を行う。
・ システム開発中や稼動直後に、新機種新機能発表等陳腐化しないよう確認する。
・ モデルチェンジや製造中止のためサポート中止になったり、より低価格で高性能な機器が後からでてきたりすることのないよう確認する。
・ 国内、国外において、同業他社の動向調査や状況を分析する。

(3)機器購入調査分析
・ 最終的な選択の理由や費用を明らかにする。
・ 単に機能面や価格面のみで判断するのではなく、システムの信頼性、安全性、効率性についての判断も行う。
・ 長期的視野にたった選択が重要である。
・ マシンや技術の選択、採用に関する不正を防止し、また注意をする。

(4)リスク分析
・ リスクには、自然災害、故障等のシステム障害、犯罪行為や破壊行為が挙げられる。
・ 発生しうるリスクの種類と原因を明確にし、その対処方法と対策に必要な概算費用を算出する。
・ リスクとは防止するものという前提でリスクを認識し、その費用対効果の高い防止策を講ずる。またトラブル発生時に、そのトラブルの早期発見のための手だてや対処方法を策定しておく。

(5)関係法令、制度調査分析
・ システム開発の対象は会社の業務であり、企業自身が様々な法律、政令、および制度、慣習や規則に支配されている以上、システム開発においても、それらを無視できない。
・ コンピュータ関連法規
建築基準法
消防法
電子計算機システム安全対策基準
システム監査基準
コンピュータウィルス対策基準
電気通信事業法
著作権法
この他、経理、人事、労務、購買、外注関連法規等も留意すべきである。

(6)関連業務、管理体制、社内規程調査分析
・ 現行の業務をシステム化した際、システム化した業務処理手順だけでなく、関連する業務処理の手順や、管理の方法、場合によっては社内の諸規程に影響を及ぼす場合がある。
・ システム化によって影響を受けると想定される、社内のあらゆる面について十分な調査分析が必要である。
・ 計画の段階でそれらを網羅的に調査分析することで、大局にたった視点から総合的に関連業務、管理体制、諸規程の見直しや変更を行うことができる。
・ システム開発による、会社全体の効率の推進を行う。
・ 事前に関連部門の積極的な協力と、各関連部署責任者の適切な支援を要請しておく。

(7)システムライフサイクル調査分析
・ 定量的および定性的効果を測定する基礎とする。
・ 開発後のメンテナンスや機器のリプレースの目安とする。
・ 計画時点で、企業を取り巻く環境の変化を考慮しながらシステムが何年程度利用でき、どのくらいの時点で再度新システムの企画、開発に着手するか予め決定しておく。
・ ライフサイクルの決定は、どのような根拠で行ったか、客観的に判断できる資料を揃えておく必要がある。

(8)定量的定性的効果
・ 当該システム開発によってもたらされる効果を予測、算定することは、開発意志決定を行う重要な要素である。
・ 効果の算定は、定性的な効果だけでなく定量的な効果もかならず算定する。
・ 効果を測定することで、調査、分析方法や開発方法についてもその妥当性を検証でき、その後のシステム開発の方法改善に役立てることも可能となる。

(9)開発期間見積
・ 開発に要する期間、資金、要員、設備取得についての期間も考慮し、システム開発期間を見積もらなければならない。
・ 開発期間は、システム化対象との業務の複雑性、特殊性にて大きく影響を受ける。
・ 特に、新規の業務のシステム構築を行う場合、適切な見積ができないばかりか、開発期間の見積が変動する可能性が高い。幅をもたせた見積が必要である。
・ 要員は、社内の開発要員や協力会社のスケジュールを考慮する。協力会社との調整は必須である。
・ 設備の取得は、そのシステム開発がマシンの導入、入れ替えを伴う場合勘案する必要がある。
・ 見積の根拠となる各期間の詳細な条件や数値の説明と、全体的な開発スケジュールを明示する。

(10)開発運用費用見積
・ 開発期間の見積に基づいて、システム開発に必要となる費用、機器や設備の費用、および運用に要する費用を見積もる。
・ 開発に要する費用の主たるものは、社内人件費と社外外注費である。
・ 運用に関する費用は、運用マシン等情報機器のリース料、保守料、CPU使用料、移設工事費用、基本ソフトウェアやユーティリティー利用料、サードパーティプロダクトの購入費用、運用施設の賃貸/使用料、回線等使用料、入出力帳票の用紙代、消耗品費用、運用オペレータ人件費などを加味する。
・ 一般的に、全ての費用の1年分の合計額として算出する。
・ 見積の根拠となった条件や、各要件ごとの詳細な費用について明示する。

(11)要員計画
・ 開発を行う要員のレベル(技術力、経験)、必要人数、確保の方法(自社内、および協力会社)、教育訓練期間および教育方法(前提知識)、職務分掌(要員の果たすべき任務)を考慮して計画作成する。
・ ユーザ側の当該システムに関する要員(企画、運用等)や、リリース後の運用管理要員についても考慮する。

(12)外部委託先調査分析
・ 協力会社および要員の両面から調査分析する。
・ 開発するシステムの分野や特性に、最も適した能力をもつ協力会社を選択することが重要である。
・ 一度選択した協力会社を開発途中に換えることは、開発の円滑かつ効率的な推進の上で望ましくないため、事前の慎重な調査が必要となる。
・ 調査項目としては、会社の経営の安定度や信頼度、組織力、過去の実績、要員の知識や経験(特に電気通信の分野において)が挙げられる。
・ 外部委託の時期や費用について十分な検討し、文書で確認をとっておく。

(13)プロジェクト編成
・ 開発業務を遂行するための組織をプロジェクトとして編成し、プロジェクトの目的、および開発要員各自の業務の分担と責任体制を明確にする。
・ プロジェクト体制は文書化し表現しておく。

(14)移行と運用
・ 当該システムの移行および運用の実現可能性を考慮する。
・ 現行システムから新システムへの移行については、起こり得るあらゆるケースを想定して、計画策定しておく必要がある。
・ 移行の際のスケジュール、制限事項等は早めに関連各部に周知しておく。
・ 運用負荷、全体的なマシン利用効率等を考慮し、関連各部にコンセンサスを得ておく。

(15)複数案の比較検討
・ 可能な限り複数の案を持ち寄って比較検討し、最も適合する案を選択採用する。
・ 費用面、開発期間面、技術面のそれぞれからアプローチする。その際、どの局面を最重視するか明確にしておく。

(16)計画の承認
・ プロジェクト計画の概要を、事前にトップマネジメントに承認を得ておく。
・ 会社の意志決定として、公式の場(専務会、会長社長説明など)で概要説明し、必ず承認を得るようにする。



情報技術スキルアップの種のページへ
GLORY's OFFICEへ

Copyright(c)1998-1999 by glory