ITプロジェクトを設計する

プロジェクトを設計するというと、少し変な感じがするがこの概念は勝手に自分が考えた。勝手にプロジェクト設計と名をつける。あるいはプロジェクトのためのプロジェクト(PfP:Project for Project)と名付ける。※商標登録しておこうかな。主に発注者側である企業さんに対してであるが、RFP(Request For Proposal)のさらに一段手前において

• 何をプロジェクトの目的とするか
• その手段として何を用いるか（ITなのか業務改善なのか、あるいはその両方なのか）
• どうやって目的の達成具合を測定するか
• おおよその規模感（1億円なら投資できるが、10億円は無理とか）

等々を明確化し、組み立てていく、要求をできるだけ定義していくのがこのフェーズの目的である。当然決まっていないこともあると思うが、それは「決まっていない」と明確化していく。（それによって提案も変わってくるから）成果物はプロジェクト計画書（設計書）となる。プロジェクト計画書の目次は、

1. プロジェクト目的
2. 対象業務・システム
1. 対象業務・システム概要
2. 主要課題
3. 手段
1. ITによる目的達成部分と達成手段の概要
2. 業務改革による目的達成部分と達成手段の概要
4. 効果
1. 効果概要
2. 効果の測定方法
5. 意思決定者（組織）
6. 実行組織
7. 関連組織
8. 要員規模
1. 実行組織の要員規模
2. 関連組織の要員規模
3. 外部調達する要員規模
9. プロジェクト終了に向けたスケジュール概要
1. 内的主要マイルストーン（※プロジェクト自体のマイルストーン）
2. 外的主要マイルストーン（※プロジェクト外で発生するマイルストーン、例えば法改正等）
10. プロジェクト課題
1. 主要課題
2. 課題責任者
3. 課題対策
11. プロジェクトリスク
1. 主要リスク
2. リスク責任者
3. リスク対策

ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。（血判状的な）※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。

これぐらいをまず検討していると、プロジェクトの成功確率がぐっと高くなるのではと考える。