社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

プロジェクト計画書の書き方:プロジェクト概要

プロジェクト計画書の書き方の説明です。

第二回は、プロジェクト概要(目的、背景、範囲、特徴、前提・制約事項等)の説明です。

1.目的と背景

中身のない形式的な目的・背景を記載するプロジェクト計画書が多いですが、ある程度の規模以上(1億円以上)のプロジェクトでは、目的・背景の記載はとても重要です。

ある程度の規模だとプロジェクト期間が1年、あるいはそれ以上になることが多く、最初はメンバー全員が目的や背景を共有していたとしても、時が経つにつれて記憶が薄れていきます。またプロジェクトの途中で、さまざまな理由で主要メンバーの交代も発生します。

プロジェクトを進めると、どうしても手段に目が行きがちになります。そして徐々に本来目指していたゴールとずれていってしまいますが、プロジェクト計画書に目標を明記することで本来のゴールに向けて軌道修正することができます。

難しいのは記載するレベルです。

あまり経営よりの目標や背景を記載しても、ベンダー等、他社の人たちは実感を持つことができません。ゴールのイメージが他人事になるからです。そのため、他社の人たちでも自分ごと化できるようなレベルでの記載が重要です。

2.プロジェクトの範囲

簡単にいえば、システム化する部分とシステム化しない部分の明確化です。

特に業務部門と認識を合わせることを目的とします。表現方法としては、業務フローを記載し、そのフローの中でどこをシステム化するかを明示します。

また関係するシステムがある場合には、ベンダーの委託範囲も明確にします。表現方法としては、システム構成図・連携図を記載し、その中でどこのシステムが委託対象であるかを明示します。

通常は RFP にも記載しているので、それと同じ内容になります。

3.特徴

今回のプロジェクトがどのような特徴があるのかを記載します。

通常のプロジェクトとの相違点を記載することで、リスクの認識が深まります。

「通常のプロジェクト」って何?と堅苦しく考えてしまうと、何も書けなくなってしまうので、自分の経験に照らし合わせて、未経験のものがあればそれを記載する、くらいの軽い気持ちで記載するのが良いと思います。

ステークホルダーが非常に多い

・今のシステムと再構築するシステムを3ヶ月間並行稼働させる必要がある

・他社と共同利用するシステムを構築する

アジャイル開発に挑戦する

・並行して動くプロジェクトが多い

・元請ベンダーがいなくて、マルチベンダー体制である

・開発したベンダーと異なるベンダーが大規模な改修をする

4.前提・制約事項

基本的には RFP に記載した内容と同じになりますが、ベンダー選定を行っている中で前提条件や制約事項が変わることもあるので、内容を最新化します。

ここで注意が必要なのが、前提条件です。

前提条件とは、その条件下で費用や期間を算出したという情報であって、決して保証されたものではないということです。

プロジェクト期間中は常に、前提条件が崩れる兆候がないか、アンテナを張る必要があります。

例えば物流システムを導入するにあたって、物流拠点のネットワークは既存のものを利用する前提としたとします。

それが物流システムを設計していく中で、想定以上に通信量が多くなることが判明したとします。その場合には、物流拠点のネットワークの増強を検討しなければなりません。

【振り返り】

今回はプロジェクト計画書に記載するプロジェクト概要の説明でした。次回は開発方針の説明です。

①プロジェクト概要(目的、背景、範囲、特徴、前提・制約事項等)
②開発方針(開発手法、技術、テスト環境、パッケージのカスタマイズ方針等)
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール