続いては、コミュニケーション計画について記述していきます。

この章の内容については、品質管理ほど難しいものではありませんが、重要な内容となります。

多くのプロジェクトが失敗する原因の一つにコミュニケーションミスが挙げられます。

これはお客様とのコミュニケーションだけではなく、内部メンバーとのコミュニケーションなども含まれます。

特に、小規模プロジェクトでは、要員も少なく管理工数も限られているため、コミュニケーションのフローやルールを明確にせず曖昧なまま管理しているケースが散見されます

たしかに小規模でも中規模と同様の管理をすることは難しいと思いますが、プロジェクト成功のために最低限のルールを定義しておきましょう。

本サイトで提供する各種テンプレートをご利用いただければある程度管理の効率化が図れると思いますので、ぜひご活用ください。

３．コミュニケーション計画

本章では、以下の内容を記述します。

3-1.会議体

まずはプロジェクトの会議体を定義します。

プロジェクトの規模や特性から必要な会議体を定義して、お客様をはじめ関係各社様とのスケジュール調整を実施します。

最近では、プロジェクトのキックオフを含め、すべてリモート会議で完結してしまうプロジェクトも出てきております。

開催方法については、WEBの場合は、WEB会議システムを誰が用意して、招待するかなどあらかじめ決めておきましょう。

会議は必ず、目的と役割、資料/成果物は明確に定義しておきましょう

目的が曖昧な会議や、こういう会議も必要かもしれないというのは時間の無駄になることが多いので注意が必要です。

画像はクリックすると拡大表示されます。

会議体一覧のサンプルは、以下のリンクからどうぞ。

参考

会議体一覧（テンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

3-2.コミュニケーションツール

続いて、プロジェクトで利用するコミュニケーションツールの定義を行います。

お客様や関係各社とのコミュニケーション方法として検討するべきは、まずは会議体での利用するWEB会議システムがあります。

①会議システム

Webex、Microsoft Teams、ZoomやGoogleなどお客様と協議の上、利用するものを決定しましょう。

会議では、資料の共有やシステムの画面操作を説明することが多いため、画面共有の機能は必須となります。

②進捗管理ツール

進捗管理では、redmineやbacklog等のサービスのガントチャートなどを使って管理したり、Excelなどでの管理を行うことがありますが、

どのように進捗を可視化し、管理・推進していくのかを合わせて定義しましょう。

③文書管理ツール

文書管理については、redmineやBacklogを使って、コミュニケーション、進捗、文書管理を同時に行うプロジェクトも多いと思います。

お客様によっては、お客様に認めてもらっていないクラウドサービス上に文書をアップロードするのは禁止という場合もありますので、クラウドサービスを利用する場合には、事前にお客様の許可をいただき、文書の管理方針も提示するようにしましょう。

管理人

最近はリモートワークが主流となり、コミュニケーション管理のサービスも充実してきてます。

費用や機能をよく比較して、プロジェクトに合ったサービス/プランを検討しましょう

タスク・課題管理については、私もよく利用しているBacklog（バックログ）がお勧めです。

お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。

無料でお試しできますので、使ってみたいという方はこちらの記事を参考にしてください。

参考

Backlog（バックログ）を使ってタスクやプロジェクト管理を効率化しよう

Backlogのご紹介 今回は、クリエイティブコンテンツラボトウキョウがお勧めす…

続きを読む

3-3.課題管理・報告について

次に、課題管理方法や報告ルールについて記載します。

3-4.品質管理・報告について

次に、品質管理方法や報告ルールについて記載します。

品質管理に関しては、前の章で具体的にどのような品質管理を行うのか記述しているため、ここでは、主に報告ルールについて記述します。

誰が管理して、どういうルートで報告、承認するのかを定義しましょう。

※報告内容のサンプルは近日公開予定

3-5.コスト管理・報告について

コスト管理（原価）に関しては、請負でプロジェクトを受注した場合には、主に社内のプロジェクト管理として、原価管理を適正に行いプロジェクトが赤字にならないようにコントロールする必要がありますが、要件定義は準委任契約で工数ベースでの請求となるケースも多いと思います。

またアジャイル型の開発で、一貫して工数での費用請求となる場合もあるかと思います。

この場合、お客様は、常に予定していた原価に対して、今予定通り進んでいるのか、超過が発生する見込みがあるのかどうかを非常に気にされます。

適切なコスト管理を行い、可視化することでお客様にも説明しやすく安心していただけます。

そのためには、EVMでの管理が一番適しているかと思います。EVMとは、Earned Value Management(アーンドバリューマネジメント)の略称です。

プロジェクトの原価（主に人件費）で進捗管理をする手法となります。プロジェクトマネジメント手法の一つとなります。

EVMの具体的な管理方法については、別途説明しますが、プロジェクトのコストの現状と将来の見込みを正しく早期に把握し、適時お客様へ報告するための方法を定義しておきましょう。

3-6.進捗管理・報告について

次は、プロジェクトの進捗管理・報告ルールに関しての内容となります。

プロジェクト計画の段階では、プロジェクトの進捗管理に関して、どのような管理手法でどのように報告するか検討しましょう。

基本的には、お客様視点で考え、まずはマスタスケジュールに対して、遅延が発生していないかを第一に報告するようにしましょう。

マスタスケジュールについて変更が必要な場合は必ず関係各社含め、遅延の原因と対策（リカバリー策）を提示し、その上で、マスタスケジュールの変更の必要性を説明し、各社調整の上、合意ができたら変更可能となります。

自社の都合で勝手に変更して、事後報告すると大きな問題となりますので特に注意しましょう！

報告ルート等に関しては、コスト管理や品質管理と同様となります。

※報告内容のサンプルは近日公開予定

3-7.要求仕様管理（変更管理）

最後は、要求仕様の管理・報告に関しての計画を記載します。

要求仕様は、お客様から提示されるRFP以外にも要件定義工程でユーザへヒアリングしている最中にも追加や変更が発生するため、まずはプロジェクト開始段階で要求仕様の一覧を作成しておき、要件定義フェーズ中でもそれを活用して、追加・変更を管理するようにしましょう。

追加・変更の場合には、いつ誰がどういう理由で追加・変更となったのか経緯がわかるようにしておくことが重要です。ま

た都度追加・変更が発生していることを週次の定例会でお客様に提示し、共通認識を持ったうえで進めることが重要となります。

くれぐれも勝手に追加・変更と判断して、最後にこの分の金額が追加となりますというような事後報告だけはしないように気を付けましょう。

お客様はその追加・変更も含めて今の金額（工数）の中でやってもらえると思っていたという認識齟齬が発生し、問題かするケースが多いです。

（最悪の場合、訴訟にまで発展するケースもあります）

要求仕様の管理については、いろんな管理方法があると思いますが、ここではExcelテンプレートを使った管理手法をご紹介します。

画像はクリックすると拡大表示されます。

まず整理にあたっては、ある程度業務やシステム単位で領域を定義するところから始めましょう。

領域ごとにそれぞれ担当者が異なり、利用するシステムも異なってくるはずです。

領域の定義が完了したら、それぞれの担当者へのヒアリング内容やRFPの内容に基づき、現状の課題・問題点を抽出します。

そのあとは、課題・問題点に対する対策や改善効果（費用対効果を具体的に定量や定性的な観点とすること）を記載します。

そのあとは、業務への影響度や優先度の定義等を検討しますが、これは要件定義フェーズ以降でも構いません。

まずこの時点でお客様からヒアリングした要求仕様がもれなく記載されていることが重要となります。これをベースとして、要件定義を実施し、要求仕様の変更や追加、取消などを管理していくことになります。

テンプレートの各項目について記載する内容は以下となります。

要求仕様管理一覧のサンプル（テンプレート）が必要な方は、以下のリンクからどうぞ。

参考

要求仕様管理一覧（テンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

３．品質計画まとめ

以上でプロジェクト計画におけるコミュニケーション計画に関する説明が終了となります。

以降は、セキュリティ管理や標準化の内容などとなるため、基本的には自社内の管理規定やお客様から提示されている規定に準拠して記載する内容となります。

プロジェクトキックオフや計画段階で資料として記載する内容はこれまでご説明してきた内容が主な記載事項となります。

テンプレートをベースにプロジェクトに合わせてカスタマイズし、自分が使いやすいテンプレートとして保存しておくとよいでしょう。

関連記事

続いては、品質計画について記述していきます。品質管理に関しては、ここで全体を詳細に述べることはしません。

（ボリューム的には品質のところだけで本が1冊書けるくらいの内容があります）

大型プロジェクトでは、品質管理チームを用意する必要があります。

つまるところ品質は、お客様の満足度で評価されるということをよく理解しておきましょう。

品質担当にアサインされた場合は、ぜひ一度品質管理に関して本を一冊読んで理解することをお勧めします。

【お勧めの書籍】

独立行政法人情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター(SEC)

以下2点（現在はＰＤＦ版のダウンロードのみ公開されているようです）

SEC BOOKS： 定量的品質予測のススメ

SEC BOOKS：続 定量的品質予測のススメ

３．品質計画

全体計画としては、以下の内容を記述します。

• 各工程の品質計画
• レビュー計画
• テスト計画

3-1.品質計画

品質に関しては各工程のクライテリアにも関係するため、まずは各工程の品質要素の洗い出しと品質水準をどのレベルとするか内部で検討しましょう。

品質とコストはトレードオフの関係となるため、品質を上げるためには、十分なコスト（品質チェック工数）をかける必要があります。

ここで重要なことは、品質の目標値や品質管理の方法についての合意を得るということです。

お客様としては当然高品質（要求機能がきちんと実現され、バグがない状態）を要求してきます。

ただしバグを限りなく0に近づけるには相当な工数がかかるということを理解してもらう必要があります。

予算は有限であり、期間・要員も限られた中で最大限の成果を目指す必要があるため、効率的なレビューやテスト方法が求められます。

PAF法（prevention-appraisal-failure approach）では、品質コストは、予防コスト（P)、評価コスト（A)、内部/外部失敗コスト（F)に分類されます。

不良率が高い場合は、当然品質が高いとは評価されませんが、同様にいくら不良率が低くてもコストをかけすぎている場合は、品質が良いとは評価されません。

そのため不良率とコストのバランスが非常に重要となります。少ないコストでいかに品質をあげるかが求められます。

もちろんお客様の業種や業務内容によって、どこまでコストをかけて品質を高める必要があるのかは異なります。

特に、官公庁のシステム、保険や金融系システムなど、セキュリティが重要となるシステムでは、巨額のコストをかけて、品質を高めるための施策をしていると思います。

ただし、ある程度の大規模ベンダーであっても総合的に高レベルのセキュリティを担保するようなシステムを構築するのはとても難しいということを理解しておく必要があります。

その点、Salesforceでは、毎年巨額の費用をかけて、セキュリティ対策を実施しているため、日本のベンダーに依頼して構築したWEBシステムよりもはるかに高いセキュリティを持つシステムとなっています。各評価機関からの審査結果を見れば一目瞭然ですね。

そのため、近年では官公庁や金融機関も積極的にSalesforceのサービス基盤を利用したシステム構築を始めています。

同じクラウドサービスでもamazonのAWSを使って構築する場合には、専門的な知識を有した人が基盤設計をして構築する必要がありますが、Salesforceでは基盤部分は設計する必要はなく、アプリケーションの構築に専念できるメリットがあります。

【定量評価】

品質要素に関しては、作成したシステムの場合、一般的にバグ密度を用いますが、上流工程の場合には、設計書のレビュー指摘密度を用いて定量的に評価します。

レビュー指摘密度は、レビュー指摘件数を設計書のページで割って算出します。（設計書1ページあたりのレビュー指摘件数）

評価に当たっては、あらかじめ似たような過去のプロジェクトでの実績に基づき、密度の基準値を定義しておく必要があります。基準値と比較することで設計に対する品質をチェックすることができます

【定性評価】

設計書のレビューにあたり、レビュー指摘の分類毎に集計することで、どういう指摘が多いのか傾向を把握して改善策へつなげることができます。

例えば、誤記が多い場合であれば、ドキュメントの校正に力をいれたり、「合目的性」「正確性」に関する指摘が多い場合は、ユーザ要求を正しく理解できていない、システム機能要件の定義が曖昧などの原因となり、要件のヒアリングが足りていない状況だと判断できます。

品質要素、水準の定義にあたっては、経済産業省の「ソフトウェアメトリクス高度化プロジェクト」から提供されている各種ガイドを参考にするとよいでしょう。

・定量的マネジメントのための公開データ利用ガイド
・システム及びソフトウェア品質の見える化、確保及び向上のためのガイド

3-2.レビュー計画

続いて各工程で作成する成果物についてのレビュー計画を立てていきます。

基本的には、業務領域や成果物単位で、それぞれ作成者・業務担当者が異なるため、これらの単位でレビューを実施していくことになります。

例えば、財務・会計の業務領域であれば、要件定義や開発も財務・会計の知識や簿記等の資格を持っている担当者がアサインされることが多いと思います。

お客様側に関しても、部門/部署単位で担当業務が異なることがほとんどです。お客様は通常業務と並行しての作業となるため、極力必要な会議体だけ出席していただくように計画していきましょう。

画像はクリックすると拡大表示されます。

上記のテンプレートはこちらから提供しています。

参考

工程別レビュー計画書（Excelテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

3-3.テスト計画

品質管理の最後はテスト計画となります。

テスト計画に関しても実際に計画書を作成する段階では、多くのことを検討する必要がありますが、プロジェクト計画書では、その概要だけを記載しておきましょう。

ただし、テスト対象（どこまでやるのか）、実施方法（どのような手法で実施するかなど）は曖昧にせず明確に定義しましょう。お客様と認識が異なり、追加のテスト要望が出てくるとテストの工数やスケジュールに大きな影響があります

【テスト計画の記載内容】

以下の内容について、工程ベースにマトリクス表を作成して、環境や検証機能、実施者などを纏めて記載するとよいでしょう。

３．品質計画まとめ

以上でプロジェクト計画における品質計画に関する説明が終了となります。

計画段階のためあまり詳しく記載していませんが、プロジェクトではQCD（品質、コスト、納期）が非常に重要な観点となりますので、品質管理に関しては、しっかり学習しておきましょう。

続きは、次の記事へ

参考

プロジェクト計画書の作成（５）コミュニケーション管理~品質管理

プロジェクト計画書（５） 続いては、コミュニケーション計画について記述していきま…

続きを読む

関連記事

前回に続き、プロジェクト全体計画に関して説明していきます。

前回の記事をご覧になりたい方はこちらからどうぞ。

参考

プロジェクト計画書の作成（２）

プロジェクト計画書（２） それでは前回に引き続きプロジェクト計画書の作成について…

続きを読む

第2章

2-2.各工程の考え方と作業計画

ここでは、プロジェクトの各工程を定義します。

今回は、一般的なウォーターフォール型開発の工程で説明しますが、Salesforce開発プロジェクトでは、「アジャイル開発でお願いします」というお客様のリクエストが多いと思います。

ただし、よくよく話を聞くと契約方式も含めて、100%アジャイルでやるということではなく、アジャイルっぽく進めたいという曖昧な場合がほとんどです。

あとは、アジャイルとウォーターフォールのハイブリッドという便利な言い回しですね。この言葉には特に気を付けてください。

管理人

Salesforceではプロトタイプを作って、画面操作しながらシステム機能要件を確認するやり方が一般的ですが、この進め方をアジャイルと仰っている場合もあるので、お客様としっかり意識合わせしてくださいね

実際に契約はどうするのか、工程はどう考えるのか、アジャイルでシステム機能単位でテストまで含めてサイクルを回して完成させていくというスタイルで本当に進められるのか、お客様の業務やプロジェクトの特性など踏まえ実現可能か慎重に検討してください

このページで記載する内容は以下となります。

2-3.各工程の開始/終了クライテリア

工程を定義したあとは、各工程のクライテリア（クライテリアとは、各工程での主要なタスクの開始と終了を判定するための評価基準）を定義します。

【クライテリア設定の目的】

特にウォーターフォール型の開発では、スケジュールの関係などで工程が平行して進められることも多々ありますが、その場合に、全工程が終了しているかどうかを明確に判断するためにも、クライテリアの定義は重要となります。

各工程のクライテリアの例としては以下のようなものがあります。

2-4.マスタスケジュールとマイルストーン

続いて、プロジェクトのマスタスケジュール（Master Schedule)とマイルストーン（Milestone)を定義します。

新システムの稼働時期（目標）はRFPで提示されていることも多く、契約前に決まっていることがほとんどだと思います。

カットオーバー（本番運用開始）時期が決まっていてそれが変更不可の場合、カットオーバーに合わせて各工程の期間を定義していく必要があります。

ここで気を付けるべきは、各工程の比率が一般的な開発プロジェクトの比率と大きくかけ離れていないかをチェックしておきましょう。

例えば、要件定義で4か月かけて実施するのに、設計・開発が2か月となっているなど。

標準的な開発期間に関しては、独立行政法人 情報処理推進機構（IPA）が発行している「ソフトウェア開発データ白書」を参考にしてください。

マイルストーンに関しては、定義した工程のクライテリア評価時期を定義しておきましょう。

管理人

マスタスケジュールの各プロセスのうち、クリティカルパスがどこになるのか明確にしておくことをお勧めします。

お客様もどの工程（プロセス）で遅延が発生するとマスタスケジュールの遅延につながるのか気にされています。

2-5.体制と役割

体制と役割のページでは、お客様と自社及びその他関係者全員の役割と体制を定義します。

お客様側やその他ステークホルダーの体制と役割に関しては、事前に確認しておきましょう。

自社の体制に関しては、プロジェクト責任者とよく相談して決めましょう。

プロジェクトの規模にもよりますが、一般的には以下のような体制を構築します。

• プロジェクト責任者、営業担当、プロジェクトマネージャ、（PMO）、プロジェクトリーダ、メンバー

大型案件の場合、管理系作業のボリュームが大きいため、PMとサブPM、PMOを2名体制にすることもあります。

また各業務/システム領域ごとに業務リーダー（PL、サブPL）をそれぞれ立てて、各領域の進捗はそれぞれのPLが取りまとめてPMOへ報告するなどのやり方をする場合もあります。

当然体制を増やすとコストも増加するため、あらかじめ提案時にプロジェクトの規模やリスクなどを考慮し、体制を検討しておきましょう。

またお客様や第三者ベンダーとのコミュニケーションの窓口も明確にしておきましょう。

業務/システム領域で担当を分けている場合は、それぞれお客様側の業務担当者とやり取りをした方が効率が良い場合もあります。

当社内の体制と役割を明記する場合

当社内の体制と役割の詳細をさらに明記する場合は、以下のような形で提示するとよいでしょう。

こうすることで、お客様や関係者からみて、だれが何をする人なのかすぐに理解することができます。

2-6.成果物/納品物

最後にプロジェクトで作成する成果物/納品物を定義します。

納品物に関しては、基本的に契約時に提示しているはずなので、提案書の内容に基づいて記載すればよいです。

それ以外にも要件定義の確認のために一時的に作成する資料や設計の前段階で作成するような成果物があると思いますが、これらも成果物としては定義してもよいですが、納品の義務はないため、納品対象外とわかるように明記しておきましょう。

（納品対象かどうかの列を設けるとよいでしょう）

また、納品物の媒体や様式についてもこの時点で明確にしておきましょう。

できればサンプルのテンプレートを用意しておき、それらを合わせて提示することで認識の相違をなくすことができるため、早い段階で合意をしておくことをお勧めします。

例えば、一般的な要件定義では以下のような成果物を納品物として定義することが多いでしょう。

２．プロジェクト全体計画まとめ

以上でプロジェクト全体計画に関する記載の説明が終了となります。赤文字の箇所については、よく読んで理解してください。

多くのプロジェクトで問題になる可能性が高い内容となりますので、必ず内部の関係者全員で協議し、事前の対策を検討することを強くお勧めします。

続きは、次の記事へ

参考

プロジェクト計画書の作成（４）各工程の品質計画についてまとめ

プロジェクト計画書（４） 続いては、品質計画について記述していきます。品質管理に…

続きを読む

関連記事

それでは前回に引き続きプロジェクト計画書の作成について説明していきたいと思います。

前回の記事をご覧になりたい方はこちらからどうぞ。

参考

プロジェクト計画書の作成（１）

今回の記事は、プロジェクトの計画策定がテーマとなります。 営業の提案が採用される…

続きを読む

まずは、計画書の概要や目的についての記載から説明していきます。

はじめに（本書の目的）

ここでは、本書（プロジェクト計画書）の作成目的を記載します。

本ページは省略しても構いませんが、基本的に資料を作成する際は、その資料が何の目的で作成されたものかを利用者がわかるように記載しておきましょう。

目的の例）プロジェクト計画書（本書）を作成することにより、本プロジェクトに参画されるすべてのステークホルダー間で以下の内容についての合意形成を図ることを目的とします。

１．プロジェクト概要

1章ではプロジェクト概要を記載します。

1-1.プロジェクトの目的とゴール

プロジェクト概要の最初は、プロジェクトが発足する契機となった背景やプロジェクトの目的を記載します。

プロジェクトの背景については、基本的にRFPの内容を転載したり、RFPの内容をベースに記載することが多いです。

内容としては、現状の課題や問題点を挙げるケースがほとんどです。例えば、背景としては、以下のようなものがあります。

また、目的としては、基本的に上記の背景に対して、具体的な解決策の方針と最終的にどのような状態になっているべきかを記載することになります。

それぞれの課題に対になる形で目的を書いてもよいし、まとめて将来像を提示してもよいでしょう。

それぞれに対応した形で目的を書く場合の例

全体的にまとめて将来像を示す場合の例

1-2.プロジェクトスコープ（開発範囲）

プロジェクトのスコープ（開発範囲）を明記します。

あとでこの部分もやってくれると思っていたのに話が違うということがないように、最初から明確にスコープを定義しておきましょう。

スコープ（開発範囲）の表現方法はいろいろありますが、以下のようなやり方が一般的なようです。

• システム構成図（ポンチ絵）を用意して、赤枠で範囲を囲み、開発対象とそうでないシステムを明確にする
• 作業工程（要件定義、基本設計、詳細設計、開発、テスト、移行）を矢羽根で表現し、どの工程が作業範囲化明確にし、また各工程での作業概要を記載することで、作業工程と作業内容の範囲を明示する。
• 上流工程が終了していて開発以降を請け負うような場合には特に注意する必要があります。
• 開発を行う対象の機能一覧をベースにして、どの機能をどのように開発するかまでしっかり確認するようにしましょう。

1-3.要求機能概要

続いて、システムの位置づけについての説明を記載します。ここについてもRFPや提案書の内容をベースに記載すればよいでしょう。

新しく導入するシステムが経営や業務において、それぞれどのような位置づけになるかを明記します。

どのような目的で作成・利用されるのかが明確にわかるような記述にしましょう。

1-5.システム構成図

システム構成図は、大型案件であればRFPで提示されている場合も多いと思います。

提示されている場合は、それを利用しても構いませんが、要件定義書などの成果物として提示したり、プロジェクト終了まで利用することも多いため最初に作成しておくことをお勧めします。

システム構成図を作成することで、要求事項の全体像を整理することができます。

その際、現行システムとの関係性や、外部システムとの関係性、システム機能の位置づけなど不明点や未確定事項が出てくることも多く、早めに確認して対処することで認識の相違を防止することにもつながります。

1-6.ネットワーク構成図

社内ネットワークからSalesforceにアクセスする際のルートだけではなく、モバイルを利用する場合のルートや外部システム連携がある場合には、外部システムとSalesforce間のルートなどを定義します。

第一章は以上の内容となります。

次の第二章では、プロジェクトの全体計画を記述していきます。

２．プロジェクト全体計画

全体計画としては、以下の事項について記述します。

• プロジェクトの評価方法
• 全体計画（工程計画と作業概要）
• 各工程の開始/終了クライテリアの定義
• マスタスケジュール・マイルストーン定義など

2-1.プロジェクトの評価指標

まずは、プロジェクトが成功したかどうかを判断するための評価指標を定義します。

社内プロジェクトの場合などには記載していることもありますが、お客様に対して、プロジェクトの評価指標を提示するということは、プロジェクトを請け負う側のリスクになる場合があるため、明記されていないことが多いように思います。

評価指標を定義する場合は、通常QCD（Quality:品質、Cost：コスト、Delivery：納期）の観点でそれぞれ定量的に記述します。

例としては以下のような指標を定義します。

続きは、次の記事へ

参考

プロジェクト計画書の作成（３）各工程の作業計画~成果物/納品定義

プロジェクト計画書（３） 前回に続き、プロジェクト全体計画に関して説明していきま…

続きを読む

関連記事

営業の提案が採用されると、その後正式に契約となりますが、契約締結後（もしくはもう少し事前に）プロジェクト開始のための準備を始める必要があります。

プロジェクトの規模にもよりますが、通常プロジェクト開始の準備期間としては、最低数週間から1か月程度は必要となります。

お客様とキックオフの日程だけ先行して決まっていて、準備期間がほとんどないというケースも多々ありますが、最初の準備は非常に重要となるためしっかりと準備期間を設けることをお勧めします。

管理人

サイクルの短いプロジェクトが多いのはSalesforceの特徴ではありますが、しっかりと時間を確保するようにしましょう。

プロジェクト計画段階では検討すべき事項がたくさんあります。

もっとプロジェクト管理全般に関して体系的にしっかり学びたい方は、PMBOKの学習やPMPの資格を取得することをお勧めします。クリエイティブコンテンツラボトウキョウがお勧めする書籍が知りたい方は、こちらを参考にしてください。

続いて、それぞれの事項について関係者を交えて詳細を検討し、計画書（ドラフト）を作成しましょう。

ドラフトのレビューを繰り返し、プロジェクト計画書を仕上げていきます。　※（）は役割とか担当者

1. プロジェクト計画（PM)
   1. 提案・契約内容の再確認（精査）
   2. プロジェクトの目的、改善目標の明確化
   3. システム全体像、スコープ、開発方針の明確化
   4. マスタスケジュール策定
   5. WBSの作成
   6. 要員計画（外注依頼）
   7. QCD（品質・コスト・納期）計画
   8. コミュニケーション計画
   9. 開発環境計画
   10. セキュリティ、リスク計画
   11. 標準化計画
2. プロジェクト計画書ドラフト作成（PM）
3. 内部レビューの実施（営業、PM、プロジェクト責任者）
4. プロジェクト計画書の内容に関する事前すり合わせ（対お客様）
5. プロジェクトキックオフ会議での計画書説明（ステークホルダー全員）

上記とは別に、平行してプロジェクトメンバーへの内部キックオフの実施や、プロジェクトメンバーによる先行作業として以下のようなことを進める必要があります。

1. 環境構築、技術調査（コンサル）
2. 申し送り事項の確認（営業＋全員）
3. コミュニケーションツールの設定（PMO）
4. 受領資料などの整備、インプットの読み込み（全員）

1.プロジェクト計画

プロジェクト計画は、基本的にプロジェクトを受け持つ予定のプロジェクトマネージャ（以下、PM）が作成することになります。

プロジェクトマネージャの手腕が試される最初の試練といったところでしょうか。

プロジェクト計画は言うまでもなく、プロジェクト成功の要となる非常に重要なものです。

この計画ベースにプロジェクトが進行していくことになりますので、いかに精緻な計画を立てられるかが重要となります。

もちろん、プロジェクトが予定通りに進むということは極めて稀で、基本的には実体に合わせて計画を変更することもあります。

ただし何度も大きく変更が生じるとお客様にも不信感を与えてしまうことにつながるため、変更の際は部分的な見直しではなく全体を見て、現実的で最適な計画となっているかしっかりとレビューを実施する必要があります。

管理人

お客様がプロジェクト計画を承認した後に変更が発生する場合は、基本的にお客様へ説明して内容を承認してもらう必要があります。

プロジェクト規模に合わせたプロジェクト計画の策定

プロジェクト計画は、プロジェクト規模の大小にかかわらず基本的に作成すべきものになります。

（※保守案件や単発機能開発、機能改修などは不要）

Salesforceのプロジェクトは、小規模であれば数百万、大規模であれば億を超えることがありますが、プロジェクト管理という観点では小規模案件であっても本来やるべき作業はさほど変わりません。

プロジェクトである以上、PMBOKに基づく管理を要求される場合が多いです。

ですが現実的には、中小規模のプロジェクトを担当する場合は、単一案件ではなく、複数の案件の掛け持ちになることが多く、管理の作業負荷が高いことが課題となっています。

本サイトで提供しているテンプレートや標準プロセスに沿ってプロジェクトを推進することで少しでも管理作業を効率化し作業負荷を減らしていただければ幸いです。

重要なことは、お客様と管理品質レベルを事前に合意しておくこととなります。

そのためにどのような管理作業（管理対象、管理方法、報告方法など）を想定していてどの程度の工数をかける必要があるか事前に検討する必要があります。

プロジェクト計画書（章立て）

それではプロジェクト計画書の作成について説明していきます。

まず、一般的なプロジェクト計画書の章立ては以下のようになります。

※中小規模の案件（ライセンス費用など込みで、5千万程度以下の案件くらい）であれば、もう少し簡略化した計画書を作成してもよいでしょう。

超大型案件などでは、上記のほかにも多くの事項を定義することがありますが、規模に応じて使い分ければよいでしょう。

計画書の章立てを見ただけでも記載項目は多く、検討事項の内容も難しいため経験が少ないうちは何を書くか難しいと思います。

まずは社内で利用されているプロジェクト計画書のテンプレートを使ってドラフトを作成することをお勧めします。

テンプレートがないという方は、Creative Content Lab Tokyoが作成したプロジェクト計画書のサンプルを参考に作成してみてください。

プロジェクト計画書サンプル

※図をクリックすると拡大表示されます。

プロジェクト概要

マスタスケジュールとマイルストーン

コミュニケーション計画

体制と役割

テンプレートのダウンロードについて

PPTなどのテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

プロジェクト計画書

プロジェクト計画書（PPTテンプレート）サンプル・利用方法

[st-midasibox-intitle title="注意" webicon…

続きを読む

プロジェクト計画書の書式について

プロジェクト計画書のサンプルをご覧になられましたでしょうか。

プロジェクト経験豊富な方であれば、それぞれの章で記載すべき内容やなぜ記載すべきなのかということはよく理解されていると思いますが、初めてプロジェクト管理をする場合には、いきなりプロジェクト計画書を作成するのは難しいと思います。

実際には、テンプレート渡すから同じように作ればいいよー。と上司から気軽に言われて四苦八苦することが多いのが実情ではないでしょうか。

続いて、これからプロジェクト計画書を作成される方のために具体的に記載すべき内容や書き方など説明していきたいと思います。

表紙

まずは、表紙の作成から。会社のテンプレートによって表示位置やサイズなど様々ですが、基本的には以下のような構成が一般的です。

1. 顧客名（左上）
2. プロジェクト名（上下中央）
3. 版数（中央下段）
4. 作成日、作成者（会社）（中央下段）

※クリックすると画像が拡大されます。

改訂履歴（変更履歴）

続いては、改訂履歴の作成となります。

プロジェクト計画書は一度作成したらそれで終わりではなく、計画が変更になる場合は、計画書を修正してその上でステークホルダーと合意を行う必要があります。

そのため、改訂履歴のページを作成しておき、変更がある場合は改訂履歴のページを合わせて更新します。

改訂履歴のページの記載内容は以下）

本書の構成

成果物や納品物に関して、基本的に資料構成を説明するページを入れておきましょう。

全体の資料構成及び本書の位置づけがわかるようにし、ほかの文書との関連性もわかるようにしておきます。

本サイトのサンプルでは、資料の構成を表現するためフォルダやOfficeのアイコンを利用し、階層構造で表現しています。

プロジェクト計画書と補足資料の全体像とそれぞれの資料の役割がわかるように表現しましょう。

続きは、次の記事へ

プロジェクト計画書（２）

プロジェクト計画書の作成（２）

プロジェクト計画書（２） それでは前回に引き続きプロジェクト計画書の作成について…

続きを読む