システム開発のプロジェクトマネージャーを任命されたけど、何から始めればいいの？
プロジェクト計画ってなに？
プロジェクト計画の書き方がわからない？
プロジェクトが立ち上がり、プロジェクトマネージャーに任命されたら、プロジェクト計画を策定する必要があります。計画といってもスケジュール（WBS）だけではありません。まずは、プロジェクト概要からまとめましょう。
ここでは、家族旅行をプロジェクトの題材にして、プロジェクト計画の書き方をわかりやすく解説します。
前回のおさらい（プロジェクトとは？）
前回は、身近な家族旅行を題材にして、プロジェクトマネジメントとは何かを解説しました。
どうしても「プロジェクト」と聞くと大規模な事業やシステム開発をイメージしてしまいますが、少しは身近なものに感じていただくことができたのではないでしょうか。
では、プロジェクトを成功させるために何から始めればいいのでしょうか？
それはプロジェクト計画です。まずは計画を立てるところから始めます。
家族旅行も同じですね。どこにいくのか、いつ行くのか、だれといくのか、どのように行くのか、そのために何をしなければいけないのか？などを決めていくと思いますが、それはプロジェクトでも同じです。
なぜプロジェクト計画が必要なのか？
そもそも、なぜプロジェクト計画が必要なのでしょうか？
それは、プロジェクトに関係する者全員（ステークホルダーといいます）が１つの目標に向かって進むためです。
プロジェクト計画では、システム化の目的や背景を確認し、システム化の対象範囲（スコープ）、スケジュール、コスト、すべての関係者（ステークホルダー）、それらを取り巻く環境を明確にして文書化していきます。
それによって、プロジェクトマネジメントで重要な品質（Quality）、コスト（Cost）、納期（Delivery）をステークホルダーで共有しながらゴールに向かって進める準備が整います。
前回の「システム開発のプロジェクトマネジメントとは？身近な旅行で考えるプロジェクトマネジメント」で、
プロジェクトとは 「適正な資金＝コスト（Cost）と適正な品質（Quality）で計画した納期（Delivery）を順守するため、プロジェクトの関係者全員で状況を共有しながらゴールに向かって進めること」
と説明しましたが、まさにその準備というわけです。
もしも文書化し難いものが出てくるのであれば、今後発生しうるリスクと捉えることができます。それらはいずれプロジェクトに悪影響を与えるものかもしれません。
※リスク管理の目的、手順と対策を解説しています。よろしければお読みください。
ステークホルダーは、開発メンバー全員はもちろん、お客様は責任者だけではなく、業務を詳しく知る担当者も含まれます。 もし社内・社外問わずデータ連携先があれば、その連携先（社外の場合はその会社）の責任者や担当者、開発を請け負っている開発会社の方々もステークホルダーです。
ステークホルダー（stakeholder）とは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指す。日本語では利害関係者（りがいかんけいしゃ）という。具体的には、消費者（顧客）、労働者、株主、専門家、債権者、仕入先、得意先、地域社会、行政機関、利益団体（業界団体・労働組合・当事者団体等）の構成員など。
引用：ウィキペディア｜ステークホルダー
※ステークホルダーについてもっと詳しく知りたい方はこちらも合わせてお読みください。
家族旅行のプロジェクト計画とは？
それでは前回に続き、家族旅行の計画をまとめてみたいと思います。
※前回の解説をまだ見ていない方は参照いただくと理解が深まると思います。
| 目的 | 動物園と温泉に行き、楽しい思い出をつくる |
| 背景 | お祖母さんの還暦祝いとして旅行を計画 |
| 旅行先 | 北海道 ただし、札幌から行ける範囲とする |
| 時期 | ７月～８月 二泊三日とする |
| 予算 | ３０万円 |
| 参加者 | 家族３人（夫婦・子供一人）と妻の両親の合わせて５人 |
| 前提条件 | ・家族全員が休める日にする ・旅行者が多い土曜日・日曜日は避ける ・２泊目に温泉地に行く ・妻は運転免許が無い（レンタカーは夫だけが運転） |
| 制約条件 | ・７月３０日～３１日は来客があるため自宅にいる必要がある ・お祖母さんは足が悪いため長距離を歩けない ・商店街の景品でもらった旅行クーポンの期限が８月末で切れる |
| 環境 | 両親の自宅は交通の便が悪くてマイカーも無い |
| 期待 | ・家族や両親に喜んでもらえる ・温泉で元気になってもらえる |
いずれの項目も特に珍しいものはなく、誰もが家族旅行を計画する時に考える内容だと思います。そして、これらの項目はシステム開発のプロジェクト計画でも明記しなければならない項目になります。
上の表に、システム開発のプロジェクト計画で使う項目名（赤字）を３列目に追加するとこのようになり、システム開発のプロジェクト計画であっても特別な項目があるわけではないことがわかります。
| 目的 | 動物園と温泉に行き、楽しい思い出をつくる | システム化の目的 |
| 背景 | お祖母さんの還暦祝いとして旅行を計画 | システム化の背景 |
| 旅行先 | 北海道 ただし、札幌から行ける範囲とする | システム化対象範囲（スコープ） |
| 時期 | ７月～８月 二泊三日とする | スケジュール |
| 予算 | ３０万円 | コスト |
| 参加者 | 家族３人（夫婦・子供一人）、妻の両親の合わせて５人 | ステークホルダー |
| 前提条件 | ・家族全員が休める日にする ・旅行者が多い土日は避ける ・２泊目に温泉地に行きたい ・妻は運転免許が無い（レンタカーは夫だけが運転） | 前提条件 |
| 制約条件 | ・７月３０日～３１日は来客があるため自宅にいる必要がある ・お祖母さんは足が悪いため長距離を歩けない ・商店街の景品でもらった旅行クーポンの期限が８月末で切れる | 制約条件 |
| 環境 | 両親の自宅は交通の便が悪くてマイカーも無い | システム稼働環境・開発環境 |
| 期待 | ・家族や両親に喜んでもらえる ・温泉で元気になってもらえる | 期待効果 |
つまり、みなさんが家族旅行の計画を考える時、意識せずにプロジェクト計画と同じ内容の作業を行なっていたということです。
そして、これらがプロジェクト計画の最初にまとめるべき「プロジェクト概要」になります。
まずはプロジェクト概要をまとめよう
プロジェクト概要に記載する内容は極めて重要な項目です。なぜなら、課題が発生した時の判断基準となるからです。
あくまでもシステム化は手段です。そのプロジェクトの目的を達成するための手段でしかありません。プロジェクト概要を文書化しておくことで、課題が発生して判断に迷う時でもプロジェクト概要を見て目的に沿った判断かどうか見極めることができます。
プロジェクト概要をステークホルダーで共有し、正しい判断でプロジェクトを進めていきましょう。
ここからプロジェクト概要のポイントをまとめます。
システム化の目的
最も大事な項目です。目的が間違っていると正しい方向に進めません。
一番間違いに陥りやすいのが目的と手段をはき違えることです。システム化することが目的ではありません。 何かしらの目的があって、その手段としてシステム化するわけです。
なぜシステム化する必要があるのか？
なんのためにシステム化するのか？
この質問を常に意識して、正しく目的を設定することがプロジェクトを成功に導く第一歩です。繰り返しになりますが、システム化自体が目的とならないように注意しましょう。
システム化の背景
システム化の背景を知ることで、お客様の視点で考えることができます。
なぜこの業務改善（システム化）が必要なのか、お客様がかかえる業務課題やシステムの問題点、お客様の社内外の環境変化などを書き出しておきます。
システム化対象範囲（スコープ）
システム化する対象範囲をスコープといいます。対象となる業務はどれか、どこまでの機能を開発するのかなど、システム化する範囲を一覧化して明確にします。
対象範囲だけではなく、対象外となる部分も明記しましょう。もし未確定の部分があればそれも明記しておきましょう。
ただし、対象外の範囲をすべて書き出すのは難しいことです。対象外に記載されていないものはすべて対象範囲とお客様が誤解することもあり、間違って理解されないように注意が必要です。あくまでも対象範囲に記載されているものだけがシステム化する範囲です。
スケジュール
プロジェクトのスケジュールには、プロジェクト全体の日程を俯瞰した「マスタースケジュール」と、具体的な作業に担当者を割り当てた「WBS」がありますが、プロジェクト概要では全体を俯瞰したマスタースケジュールを指します。
マスタースケジュールはプロジェクトのベースラインとなるもので、ステークホルダーが共有することで各担当者の役割を理解し、混乱せずにプロジェクトを進めるために必要となります。
もし、マスタースケジュールに影響する事態が発生しても、プロジェクトマネージャーであっても勝手にマスタースケジュールを変更してはいけません。お客様はもとより、ステークホルダーの責任者が集まって検討し、変更が承認されてからマスタースケジュールを変更しましょう。
前提条件
前提条件は、計画通りに進めるために前提となってくる条件のことです。
実際のプロジェクトで発生すると思われる事例を参考に記載します。
- 現在の業務フローは存在しないため作成する必要がある
- 対象業務に詳しい実務担当者をプロジェクトメンバーにする
- 営業部門の業務はシステム化しない（現行のままとする）
- 業務マニュアルのお客様が作成する
- 新システムの操作教育はお客様のキーマンのみとし、全社展開はお客様のキーマンが実施する
- システムに合わせて業務を見直す（カスタマイズしない）
制約条件
制約条件は、外的要因によって発生し、変更できない条件のことです。
プロジェクトに参画する関係者によって発生するもので、プロジェクト計画に制限がかかるようなものです。
実際のプロジェクトで発生すると思われる事例を参考に記載します。
- 現行システムで利用しているサーバの保守契約が２年後に切れる
- 消費税率が変わる〇〇年〇〇月までにシステム改修する必要がある
- データ連携先のシステムが再構築されるため、それまでに当社のシステムも改修する必要がある
- データ連携先が多いため、サービス停止できるのは年末年始の3日だけで、その期間でデータ移行する必要がある
- 会社が合併する〇〇年〇〇月までに新システムを導入する必要がある
コスト
システム化のコストを見積もります。
コストには一時的に発生するコスト（開発費用や初期セットアップ等、初回のみ必要なコスト）とランニングコスト（ソフトウェアライセンスやハードウェアのリース費用やクラウド費用等、月単位や年単位に繰り返し発生するコスト）があります。
一時的なコストだけではなく、ランニングコストや本稼働後の運用保守に必要なメンテンナンス要員のコストも忘れずに見積もりましょう。
実際のプロジェクトで発生するコストの事例を参考に記載します。
- ソフトウェア購入費用
- ハードウェア購入費用、リース費用
- ネットワーク機器費用、リース費用
- クラウド利用料
- ライセンス使用料、購入費用
- 開発要員費用（社内の場合は人件費、社外の場合は委託費用）
- その他費用（開発者の事務所費用、交通費、携帯等通信費、紙代等）
システム開発の見積もりについて詳しく知りたい方はこちらもお読みください。
なぜ見積もりを失敗するのか、見積もり方法とポイントを解説しています。
ステークホルダー
ステークホルダーは、開発メンバー全員はもちろん、お客様は責任者だけではなく、業務を詳しく知る担当者も含まれます。
もし社内・社外問わずデータ連携先があれば、その連携先（社外の場合はその会社）の責任者や担当者、開発を請け負っている開発会社の方々もステークホルダーです。
システム稼働環境・開発環境
システム開発のプロジェクトでは、必ず現在稼働しているシステムがあると思います。
全くシステム化されていない業務であっても、既存システムや他社サービスなど、他システムとのデータ連携が必要になります。
システム化にあたって、それら現行システムが稼働する環境をおさえておく必要があります。サーバ環境はどうなっているか、開発環境とお客様にテストしてもらう環境は分ける必要があるのか、お客様とデータ連携している他社サーバ（連携サービス）はどれだけあるのか、稼働時間やメンテナンス時間（停止時間）などを洗い出します。
期待効果
期待効果は、できるだけ定量的に書き出します。
定性的な評価でもよいですが、曖昧な評価となるため注意しましょう。
実際のプロジェクトで発生すると思われる事例を参考に記載します。
- 費用削減効果 月々〇〇万円の削減
- 作業工数削減 営業部の人件費が月々〇〇万円の削減
- 通信費用削減 FAX送信件数〇〇件廃止により毎月〇〇万円減
- 業務効率向上 データ自動取込みにより受注インプット〇〇分削減
プロジェクト概要の次は何をするか？
これでプロジェクト概要がまとまりました。どのようなプロジェクトなのか全体が見えてきたと思います。
プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、今回のプロジェクト概要を含めて11項目あります。
これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。
- プロジェクト概要 今回はここ
- マスタースケジュール・WBS 次回はこちら
- プロジェクト体制
- 成果物
- 変更管理
- 欠陥管理
- 課題管理
- コミュニケーション計画（会議体）
- 要員計画
- リスク管理
- プロジェクト標準
次回はマスタースケジュール・WBS（Work Breakdown Structure）について解説していきます。よろしければ次の記事もお読みください。
