ここでは、プロジェクト計画書に記載する「背景と目的」の内容のネタをまとめる。
ネタが必要になるほどのものでもないが。
プロジェクト計画書の全体（章立て）は こちら
2章 背景と目的
なぜこのプロジェクトが立ちあがたのか（＝背景）を述べ、それを踏まえてこのプロジェクトのゴール（＝目的）をここで明確にする。最終的にこの目的が達成されればプロジェクトが完了することになる。
１．プロジェクトの背景
・プロジェクトの立ち上げに至ったきっかけやそのいきさつ
・これまでのシステム利用の歩み
・経営、ユーザー、業務、システム運用・保守等にかかわる課題と対策
| 例：
現在の●●●精算システム（以下「本システム」とする）においては、200X年に導入し現在は4世代目として20XX年にシステム更改を実施し20XX年X月現在で4年目となる。本システムのデータベースはXXXXXver2.0を利用しているが、20XX年X月にサポート停止が公示されており20XX年X月までにXXXXXver４.0へのアップグレードが必要な状態である。一方、本システムの主管となる経理業務においては、業務負荷が課題となっておりその対策、業務の統廃合や手作業の自動化を進める計画である。同様に本システム運用・保守業務においても業務負荷が課題となっており・・・記述中
|
参考：
・例えば、官公庁のシステム開発関連のプロジェクトでは、開発ベンダー向けのRFP（調達仕様書という名称）では、「背景と目的」としてこれまでの政策、業務、取り組みの流れの概要に始まり、現在の課題、要求事項、期待される結果といったことが述べられている。当サイトでは、背景と目的を分けているが「背景と目的」として分けずに書いてもよい
・なお、プロジェクトを発足する発端は、下記のような事案がきっかけとして考えられる
経営・・・新たなサービスの立ち上げ、サービスや業務の統合、クラウド化（DX化）など
サービス・・・UI改善、機能の追加など
業務・・・手作業の廃止、紙ベースの電子化、機能の追加、UIの改善など
システム運用・・・運用課題、OSやソフトウェアのサポート停止など
その他外部要因・・・制度改定、税率の変更、犯罪・災害対策、顧客要求、競合他社対策、環境問題など
・ここでは、企画書などの社内のプロジェクト発足の検討や企画した資料をそのまま引用すればよい。もし、このプロジェクトを受注した開発ベンダーの立場の場合は、依頼元が発行したRFPにプロジェクト発足の背景が書いてある場合が多い
２．プロジェクトの目的
・前述の「１．プロジェクトの背景」を踏まえて、プロジェクトが成功することにより何がどのように変わるのかを書く。下記の例ではシンプルに「１．経理業務の効率化、２．システム課題対策、３．システム運用・保守業務の効率化」としてみた
・また、具体的にどんな効果を期待するかを明記する（下記の例のポチの部分）
| 例： ＜１．経理業務の効率化＞ ・ 紙ベースで管理しているXXXを電子化し、承認や管理についてもシステムで処理できるようにする ・ XXX申請作業おいて、承認プロセスを簡素化し・・・どうたらこうたら ・ XXX画面において、帳票をXXXに対応する形式とし、XXX業務のXXX処理作業を・・なんたらかんたら ＜２．システム課題対策＞ ・ データベースのサポート期限を20XXまでに延長する ・ 現在使用しているXXXXver6.5についてOSをXXXXver8.0にアップデートする（20XX年X月に発生した大規模障害の対策） ・ ユーザー増加に伴うストレージ容量の拡張する（ストレージ使用率82%→40%） ＜３．システム運用・保守業務の効率化＞ ・ XXX処理機能を追加することにより、経理業務にかかわるXXX対応依頼数を削減する ・ XXXX申請における管理画面において、XXX管理画面と統合し一元管理や処理ができるようにする。（これに伴い、関連するマスタデータの見直し（統廃合）を行う ） |
参考：
・「プロジェクトの目的」は、プロジェクトを立ち上げるための企画書（もしくは提案書）などの企画フェーズの成果物に明記されているはずであり、プロジェクト計画書に目的を記載する際にはそれらの文言を用いればよいと思う。ただし、前述したがプロジェクト完了時の最終報告において、ここで述べた目的が達成されたかを報告することになるので、必要に応じてそのことを踏まえた表現に修正しておきたい
・後に要件定義工程のの成果物において、これらの「目的」が、要件定義（業務要件、機能要件、非機能要件）に紐づくはずである点には留意しておきたい。企画フェーズの段階でこれらの紐づけまで整理されているべきだと考える
コメント