 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 2. 課題の定義 | ||||||||||
|
先の「プロジェクト基本要件の定義」で定義した目的を達成するために解決しなければならない課題を明らかにします。課題は複数になる場合もあります。また、その解決策を検討し、目的を達成できることを確認します。 問題点を分析することで課題を明らかにします。問題点分析を行う際の大まかな流れは以下のようになります。
表3：問題点分析の流れ 問題点分析の結果、明らかになった課題それぞれについて解決策を検討します。あわせて、課題を解決することによって目的を達成できるかどうかを確認します（情報システムを開発するだけでよいのか、組織や業務ルールを変更する必要はないのか、といったこと）。達成できないことが明らかになった場合には課題の再設定を含む問題点分析のやり直しが必要になります。 |
||||||||||
| 3. システム機能の定義 | ||||||||||
|
「課題の定義」で検討した課題解決策のうち情報システムの開発を必要とするものについて、必要とされる情報システムの機能を定義します。 システム定義で難しいのは「第2回：事前にシステム構築の費用を決めるために」でも取り上げた「どこまで定義するか」ということです。次の図はシステム定義の成果物とそれらを作成するための難易度・工数をまとめたものです。  図2：成果物の種類と難易度・工数 業務機能一覧表とは業務機能をWBS（Work Breakdown Structure）形式で整理したものです。階層が3レベルくらいのものを「骨格」、5レベルくらいのものを「詳細」とします。 データモデルについては主要エンティティとKEY、RKEY、および5W2Hをあらわす主要データ項目が記載されたものを「骨格」、すべてのエンティティとデータ項目が記載されたものを「詳細」とします。 データ定義については、主要項目、業界・会社特有の用語のみ定義したものを「骨格」とし、すべてのデータ項目について定義したものを「詳細」とします。 入出力については、入出力（画面・帳票）の一覧表を「骨格」、それぞれの入出力にどのような項目が必要かを定義したものを「詳細」とします。データモデルであれば、現状の骨格データモデルの作成難易度が一番低く、少ない工数でできますし、新規の詳細データモデルは作成難易度が一番高く、作成には多くの工数が必要ということになります。 提案依頼先であるベンダーにシステム機能を正確に伝えるためには、すべての成果物について新規の詳細なものを作成するに越したことはありません。しかし、それでは工数がかかり過ぎてしまいます。RFP作成に費やせる工数・期間は限られています。いかに工数をかけずにベンダーにシステム機能を伝えることができるかが鍵になります。 RFP作成においては、どの成果物をどこまで作成するかをあらかじめ決めておかなければなりません。筆者らは図2で下線のついた（1D）新規の詳細業務機能一覧表、（2C）新規の骨格データモデル、（5B）現状の入出力のコピー、（5C）新規の入出力一覧表をRFPにおける標準成果物としています。 ただし、あくまでも標準成果物であり、提案依頼内容やRFP作成期間、RFP作成の体制などによって、どの成果物をどこまで作成するかはその都度、検討する必要があります。例えば、特殊な業務であれば、業務フローやデータ定義までを作成する場合もあります。 |
||||||||||
| 4. 環境要件の定義 | ||||||||||
|
システム機能をベンダーに正確に伝えるためには、次のように環境要件を決めていきます。
表4：環境要件 これらの環境要件はすでに全社レベルで標準が決まっている場合がありますので、事前に標準が決まっているかどうか、決まっていればその内容を確認しておきます。 「システム機能の定義」で定義した内容をもとに標準の決められている環境要件については標準の内容で問題ないかを確認し、その他の環境要件についてはその内容を定義します。標準外を適用する可能性がある場合には、その必要性も含め、情報戦略担当者と協議の上、環境要件を定義します。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
