体制図については、クラウドサービスを使って作成することも増えてきていますが、プロジェクト計画書など関係者で共有する資料の場合、加工ができないと困る場合もあると思います。

今回はパワーポイントの図を使って体制図や役割表を作成しているので、容易に加工してご利用いただくことが可能となっています。

サポーターさん

プロジェクト計画で各作業工程と成果物を定義する際にご利用ください。

1.テーラリングガイド

１．表紙

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

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

※（プロジェクト計画（工程定義）（本書）は基本的にプロジェクト計画書などに組み込んで利用していただく想定で作成したものとなるため、表紙は本体の方で設定していただいて構いません。

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

３．プロジェクト体制図（サンプル１）

体制図のサンプルは上記の4種類となります。

作成時の注意事項としては、指揮命令系統を明確に定義することと、全体のチーム構成などがわかるようにしましょう。

またお客様や関係者も含めた構成とする場合は、それぞれのコミュニケーションルートを明確にすることと、役職など階層は合わせるように注意しましょう。

４．担当者の役割定義

各担当者の役割や責任範囲、作業内容などを定義します。

誰がどのような役割で参画し、何に対して責任を持つのか。またどのような作業を担当する予定か明確にわかるように定義しましょう。

５．工程ごとの役割と担当範囲

こちらの資料は補足となります。

各工程ごとに誰がどのような役割となり、具体的にどの作業に対して責任をもって作業を行うのか明確にします。

この粒度で作業担当を明確にしてからプロジェクトを開始するようにしましょう。

体制図・役割表（PPT版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※クリック後は、ダウンロードが開始されるまでお待ちください。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

こういった工程や作業内容、成果物を明確に定義してお客様と合意していないプロジェクトも散見されますが、ステークホルダ（プロジェクト関係者全員）と認識合わせをしておことは非常に重要なため、普段実施していないという方は、取り入れてみてください。

サポーターさん

プロジェクト計画で各作業工程と成果物を定義する際にご利用ください。

1.テーラリングガイド

１．表紙

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

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

※（プロジェクト計画（工程定義）（本書）は基本的にプロジェクト計画書などに組み込んで利用していただく想定で作成したものとなるため、表紙は本体の方で設定していただいて構いません。

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．利用規約

こちらは、削除してご利用ください。本書に関する規約と補足事項を記載しています。

３．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

またプロジェクトごとに記載の粒度やルールを検討してください。

４．目次

目次についても本体に組み込んでご利用いただく場合は、こちらのスライドは削除していただいて構いません。

・各作業工程と成果物の定義

・各作業工程と開始・終了条件

５．プロジェクト各作業工程の定義

１．プロジェクト作業工程の定義（工程名称、作業内容、成果物）

最初のスライドでは、要件定義から設計工程について、工程の名称と作業内容、成果物を定義しています。

工程の呼び方に関しては、会社やプロジェクトごとに呼称が異なると思いますが、名称について補足説明をいれておくとよいでしょう。例：RD（requirements definition）など

以下は、各工程の作業内容の説明（サンプル）となります。契約内容に基づき適切な工程と作業内容を定義してください。

要求分析（SA）：現場担当者へのインタビューを実施し、現行業務プロセスの整理。本来あるべき姿と現状のギャップ（課題・問題点）を抽出したうえで、新業務プロセスの検討を行う。また、新業務プロセスに合わせて構築するITシステムの範囲や要求仕様を明確にし、関係者で合意する

システム要件定義（RD）：業務要件定義で抽出した要求仕様に基づき、システムに求められる機能要件/非機能要件を明らかにし、要件定義書として文書化する

外部設計（BD）：データモデルの検討、画面遷移、画面一覧、帳票一覧、入出力設計、外部システム連携方式、バッチ処理方式などについてのシステム設計を行う

内部設計（DD）：以下についてのプログラムレベルの設計書を作成

・システム機能詳細設計、非機能（アカウント、権限設計、セキュリティ）、データベース詳細設計、外部IF詳細設計

ソフトウェア開発（PG）：データベースの構築、（オブジェクト、項目設定）、アカウント作成、権限設定、プログラム開発

ソフトウェアテスト（UT）：

前工程で開発したプログラムを構成する最小単位（ユニット）の機能が正しく動作することを検証するためのテスト

※Apexクラスに関しては、全ロジックを網羅するテストクラスを作成し自動テストを実行する。（カバレッジ目標NN％以上）

内部結合テスト（IT-a）：本システム内で開発したプログラムや機能を結合してテストを実施することで、要求仕様を満たしているか検討する工程

外部結合テスト（IT-b）：本システムと外部システム間を結合して行うテスト、外部設計（基本設計）で設計したシステム間のデータ受け渡しが正しいことを検証

システムテスト（ST）：本番相当の運用環境を用いてシステム全体のテストを実施する。要件定義工程で定義した機能要件/非機能要件を満たしていることを確認するためのテストを実施する。※性能・負荷試験も実施・移行リハは別途定義

受入テスト（UAT）：構築したシステムが合意した要求仕様を満たしていることを検証していただく

教育：本番での業務運用開始に向けて、本システムの利用者、システムの操作方法などをハンズオン形式で教育する。運用管理者に対しては、管理者向けの内容を実施する。

移行リハ：業務、システム、データの移行に関して、移行計画書に基づき移行リハーサルの実施

本番移行：本番移行作業計画を作成し、作業承認の上、本番移行作業を実施する

運用保守：サービスカタログに基づき、運用保守の作業を実施する。本番運用開始後3カ月間は、現地サポートを行う

６．各作業工程の開始・終了条件（Criteria）

各作業工程を定義したあとは、作業工程の開始条件・終了条件・承認者などについて整理します。

何をもってその工程を完了とするのか明確な基準を定義しておきます。また承認者や時期なども定義しておくとよいでしょう。

プロジェクト作業工程と成果物の定義（PPT版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

※ダウンロードされるまで少し時間がかかる場合があります

関係者用資料

※ダウンロードされるまで少し時間がかかる場合があります

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

今回の記事では、要件定義移行の工程のWBSタスクについての説明をしていきたいと思います。

1.要件定義フェーズの主なWBSタスク

Salesforce導入プロジェクトの要件定義工程のタスクは以下のようなものとなります。Salesforce以外のシステム開発以外がない場合については、基本的に基盤（インフラ関連）の要件検討が不要となります。

また、非機能要件に関しても基本的にはセールスフォース・ドットコム社が提示している内容に準拠したものとなるため、一般的なシステム開発と比べると要件の検討にかかる工数は少なめになるかと思います。

ただし、お客様はクラウドサービスに対する不安として、機密情報やお客様の個人情報の漏洩がないかなど、セキュリティ面に関しては、厳しい目でチェックされるため、Salesforceの基本アーキテクチャやセキュリティ対策についてはしっかり内容を理解して説明できるようにしておきましょう。

1.現状調査(AS-IS)

最初に定義するタスクの分類としては以下のようなものになります。

Salesforceでは、ロールやプロファイルを使って、システムの権限設定を行いますが、その際に、お客様の組織図ベースで検討をすることも多いため、最初にお客様の組織構成は把握しておくことをお勧めします。

また、業務体系を把握する場合やヒアリングを行う場合にも、どのような部署が存在して、組織内での業務上の役割は何かということを把握するためにも必要となってきます。

続いて、お客様の現行業務の境調査を行います。プロジェクトによっては、要件定義の前のグランドデザイン（基本構想/戦略）工程で実施する場合もあると思います。その場合には、現状調査した結果の成果物（業務フロー、業務説明書、課題と施策一覧）などがあれば、次の検討を実施することができるため、タスクとしては不要となります。

要件定義工程で実施する場合であっても、要件定義を短期間で効率的に実施するために事前に現状の業務内容についての事前調査を各現場の担当者へ依頼しておくとよいでしょう。

普段実施している業務であっても意外と説明できなかったり、課題として意識されていないこともあるため、事前に検討してもらうことで効率的に課題を抽出したり業務内容を整理することができるようになります。

また、この時点で現場担当者が抱えている課題・問題点や改善要望も合わせて確認しておくことをお勧めします。

現状の業務ヒアリングのテンプレートは以下に公開しておりますので、ご利用ください。

参考

業務ヒアリングシート（Excelテンプレート）

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

続きを読む

2.システム要件定義

現状調査が完了したら次は将来像（To-Beモデル）の検討となります。インプットは、現状調査した業務フローや課題・要求事項などとなります。

これらを用いて、業務改善ポイントの検討やシステム化要件を取り纏めていきます。

業務コンサルタントがいる場合には、業務改善の工程が入ってきますが、本記事ではシステム要件定義にフォーカスして説明していきます。

現状調査結果に基づき、システム化の方針を検討し、新システムを用いたプロセスを検討し、新業務フロー図を作成します。また機能要求については、別途要求機能一覧として整理しておきます。

上記タスクの定義が完了したら、取り纏めた内容をもって、現場担当者を交えて検討会（ワークショップ）を開催して、課題の対応方針や新業務プロセスについて現場の意見を取り入れてブラッシュアップしていくというタスクがあります。

システム化の方針と要求機能一覧が整理できてきたら、システム機能詳細の検討に入っていきます。

システム機能要件の検討段階では、以下のようなタスクが発生します。

（要求機能を具体的なシステム機能に落とし込んでいく作業）

一般的な要件定義では、要求機能一覧をベースにシステム機能一覧を作成していきます。

システム機能一覧の作成手順などは、別途要件定義の記事で詳細を説明しますが、ここでは要求機能からシステム機能への落とし込みをしていくためのインプットとなる要求仕様の整理を行います。

要求仕様の一覧を作成し、業務領域、プロセス、課題・問題点、業務要求、改善効果、対応方針などを取りまとめておきます。これをもって、業務改善/システム化の切り分けや対応の優先順などを決めていきます。

参考

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

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

続きを読む

機能要件の整理とは別に非機能要件の要件検討タスクも定義します。

SalesforceはSaaSのため、インフラ関連の非機能に関しては、検討事項は少なくなりますが、非機能で検討すべき内容は、IPAが公開している非機能要求グレード表を用いて、検討が必要な項目の洗出しのタスクは定義しておきましょう。

非機能要求グレードについては、以下、IPAの公式HPからダウンロードして利用することができます。詳しい利用方法の解説もあります。

続いて、設計やテスト方針、教育要件、移行要件に関するタスクを定義しましょう。

教育や移行に関しては、要件定義では方針、スコープ、体制・役割、（大日程）スケジュールについての検討を実施するためこれらの検討タスクを定義しておきましょう。

標準化については、プロジェクトで利用する用語集の作成や設計フェーズ以降で必要となる命名規約等のドキュメントの作成タスクを定義します。

そのほか、Salesforceの要件定義では、プロトタイプを作成して、画面イメージや操作感などを検証することが多いと思います。

その場合には、環境の準備やプロトタイプを作成するための設定・開発工数がかかるためこれらもタスクとして定義しておきましょう。

まとめ

以上が、要件定義工程のタスクの説明となります。

クリエイティブコンテンツラボトウキョウが提供するExcelのWBSテンプレートをダウンロードしたいという方は、こちらをどうぞ。

参考

WBS（work-breakdown-structure）（Excelテンプレート）サンプル

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

続きを読む

関連記事

WBSを作成するためには、プロジェクトの各工程で必要な作業内容や作業工数を理解しておく必要があります。

まだプロジェクトの経験が少ない場合もあると思いますので、そうした場合には、Salesforce導入プロジェクトの標準WBSを使って、それをテーラリングして利用するという方法がお勧めです。

先輩社員などが別のプロジェクトで利用したWBSなど社内で共有されているものがあれば積極的に活用していきましょう。

そうした資産がまだないという場合には、クリエイティブコンテンツラボトウキョウが本サイトで公開している標準WBSのテンプレートを利用してください。

テンプレートは、本記事の最後にご紹介しているリンクを参照してください。

1.WBSを作成する（プロジェクト計画）

WBSを作成する場合に、どんな粒度でタスクを記述するか、工程ごとに作成するかプロジェクトの全工程まとめて記述するかということで悩んだ方も多いと思います。

これについては、一概にこれが正しいやり方というのは存在しません。

プロジェクトの特性（アジャイル開発なのか、ウォーターフォール型の開発なのかなど）、プロジェクトの規模、担当領域など様々な要素に応じて最適なものが変わってきます。

そのため標準テンプレートを利用する場合でも、タスクレベル（記載粒度）はプロジェクトに合わせて最適化して利用してください。

タスクを定義する粒度としては、チーム単位ではなく、一人の担当者に割り当てられるようなレベルのタスクと成果物を記載するようにします。

また作業工数については、目安として1タスクあたり2、3日までで終わるようなタスクレベルで定義するとよいでしょう。

たとえば、要件定義書作成というタスクがある場合に、1つの章を2，3日で作成すると想定して、章ごとに1つのタスクを定義するなど。

最初にレベル１のタスクを定義する

まずは、レベル１（大項目）の作業タスクを定義します。一般的にレベル1では、作業工程を定義することが多いです。（要件定義、設計、開発…など）

※システム領域をレベル１にしているものもありますが、このような場合には、システムごとにWBSを分けて作成したほうがよい場合があります。

一般的には以下のような工程をレベル１として定義します。

各工程をレベル１で定義したら続いて作業期間を設定しますが、期間はプロジェクト計画時に作成しているマスタスケジュールに合わせて設定します。

基本的には上記のような大まかなマスタスケジュールに沿って、各工程ごとに開始終了期間を設定します。

プロジェクト管理経験が少ないＰＭが設定するとマスタスケジュールに合わせてきっちり開始、終了期間を設定する場合がありますが、基本的にはバッファを持たせた日程を設定するようにしましょう。

管理人

各工程間にバッファを持たせるもしくは、最後にまとめてバッファを積むことを意識しましょう

内部的には各タスクの終了期日を少し前倒しで設定することで、作業メンバーには多少プレッシャーがかかりますが、何か問題が発生した場合のリカバリー期間が確保できます。

プロジェクトが小規模な場合は全工程を纏めてWBSに記載してもよいですが、基本的には工程ごとに分けたほうが管理しやすいと思います。

プロジェクト計画タスク（準備）を定義

まずは、プロジェクトの準備タスクを定義しましょう。

プロジェクト開始前にやるべきタスクは意外と多いですが、しっかりと準備しておくことでプロジェクトの垂直立ち上げが可能となるため、頑張ってやっていきましょう。

プロジェクトの計画段階における準備タスクの分類としては以下のようなものがあります。

お客様から内示をいただいたらすぐに実施するべきことは、プロジェクトマネージャのアサインです。

大型の案件では、提案時点からプロジェクトを担当予定のPMが必ず参加しないといけない場合もありますが、プロジェクト担当となったPMは早い段階からプロジェクトにアサインし、準備を始めるようにしましょう。

また可能であれば、PMOも一緒にこの段階から参加してもらうのがよいでしょう。

準備タスクの最初は、提案内容の引継ぎとしていますが、提案に最初からＰＭが入っている場合には特に必要ないタスクとなりますが、提案に加わっていない場合は、しっかりと引継ぎの時間を確保しましょう。

引き継ぐ内容としては、主に営業担当者からの引継ぎとなると思いますが、プロジェクトの背景や目的、最終的なゴールはＲＦＰベースで説明してもらうようにしましょう。

また、お客様から受領した資料や打ち合わせのメモなど必要な情報が漏れなく連携されるように受領資料の引き渡しも忘れないようにタスクとして定義しておくとよいでしょう。

つづいて、プロジェクトのキックオフに向けて、プロジェクト計画書の作成タスクを定義します。こちらは主にＰＭ主体で実施する作業となりますが、プロジェクト計画書に記載する事項は多岐にわたるため、時間がない場合はPMOやプロジェクトメンバーと分担して作業するとよいでしょう。

プロジェクト計画書の作成については、以下の記事で作成手順やテンプレートを公開しているので、参考にしてください。

参考

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

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

続きを読む

プロジェクト計画書については、営業担当者やプロジェクト責任者を交えてしっかり内部レビューを実施したうえで、お客様や関係各社へ説明するようにしましょう。レビューのタスクを定義するとともに、レビューに備えてレビュー観点表を用意しておきましょう。

プロジェクト計画書のレビュー観点としては以下のようなものがあります。

レビュー計画書やレビュー指摘票のテンプレートは以下からダウンロードしてご利用いただけます。

レビュー計画表

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

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

続きを読む

レビュー指摘表

レビュー指摘表（Excelテンプレート）サンプル

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

続きを読む

プロジェクト計画と合わせて、要員のアサインもタスクとして管理しておきましょう。

外部パートナーに参画してもらう場合には、面談や契約手続きなども必要となるため、早めに実施するようにしましょう。

PMOが早い段階で作業可能な場合には、プロジェクト管理ツール（タスク管理、課題管理、コミュニケーション管理、ファイル管理）などの準備を進めたり、プロジェクト管理や要件定義、設計書などのファイル様式（ドキュメントフォーマット）を準備しておくようにしましょう。

こういったタスクも以外と作業時間がかかるため、プロジェクトの垂直立ち上げのためには可能な限り前倒しで準備を進めるようにしましょう。

タスク管理、コミュニケーション管理の用意ができたら、直近のタスクはそちらを使って推進するようにしましょう。

本サイトでご紹介しているBacklogを利用すると、タスク/課題管理やファイル管理がまとめて行えるため非常に効率的に作業を進められます。

気になった方は、以下から無料トライアルをはじめてみてはいかがでしょうか、

【100万人以上が使う】タスク管理・プロジェクト管理ツール「Backlog」の新規無料トライアル

計画書の準備が終わり、プロジェクト初期メンバーのアサインが終わったら、プロジェクト内部のキックオフを実施しましょう。

キックオフでは、プロジェクト計画に沿って、プロジェクトの概要やスケジュール、進め方などをメンバーに説明します。

また体制・役割を説明し、メンバーに対して期待している役割とタスクを説明しておきましょう。具体的なタスクはWBSに定義し、Backlogなどの管理ツールを使って、日々の進捗を管理するようにしましょう。

最後に、お客様や関係各社を集めてのプロジェクトキックオフミーティングを開催します。

キックオフミーティング後は、さっそくお客様や関係各社とのコミュニケーションが必要となってくるため、コミュニケーション管理ツールを使っての運用ルールなども説明し、すぐに使い始められるようにしておきましょう。

まとめ

以上が、準備段階のタスクの説明となります。準備だけでも深堀をしていくと、必要なタスクがたくさんあることがご理解いただけたと思います。

続いては、要件定義、設計、開発などのタスクについて説明していきたいと思います。

続きは、次の記事をご覧ください

参考

作業計画を立てる（WBSを作成する）（３）要件定義フェーズの主要タスク

前回はWBSの最初のタスク（プロジェクト準備）について説明いたしました。 今回の…

続きを読む

次の記事の前に、クリエイティブコンテンツラボトウキョウが提供するExcelのWBSテンプレートをダウンロードしたいという方は、こちらをどうぞ。

参考

WBS（work-breakdown-structure）（Excelテンプレート）サンプル

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

続きを読む

関連記事

プロジェクト計画では、全体の作業スケジュール（マスタスケジュール）を作成しましたが、プロジェクトの細かい進捗管理のためには、詳細なタスクベースの計画が必要となります。

一般的には、これらはWBS（work breakdown structure）を使って定義します。

WBSは、作業分解構成図のように訳されることがありますが、その名前の通り、作業（タスク）を詳細レベルに分解して、親子関係、前後関係、優先度などを定義したものとなります。

WBSはタスクのレベルを定義します。

以下の場合は、大項目、中項目、タスクと3段階となっていますが、大規模プロジェクトで5段階以上で定義されることもあります。

またタスクの前後関係や作業期間を可視化するためのガントチャート（進捗を管理するためのスケジュール表※下図の右側）と合わせて利用することが多いです。

WBSを作成するには、プロジェクトの各工程の中で必要となる作業（タスク）やどの程度の作業日数（工数）が必要か理解している必要があります。

そのため、WBSの作成にはある程度のプロジェクト経験が必要となります。

特に開発作業（特に設計やプログラミング）の経験がないPMやPMOの場合、厳密にこれらの作業工数を見積するのは難しいのではないかと思います。

そういった場合は、開発費用を見積もりする際に算出した作業工数をベースにするとよいでしょう。

セールスフォース（Salesforce）の案件では、比較的小さな規模の場合、一人や数人で要件定義からリリースまで対応することも多いため、すべての工程を経験しているエンジニアの方も多いのではないでしょうか。

1.WBS・ガントチャート作成ツール

WBS作成にあたり、プロジェクトでどのようなツールを使うのがよいか検討するところから始まります。

会社で用意されているものやお客様から指定がある場合を除いて、プロジェクトマネージャやPMO自身が用意することが多いのではないかと思います。

最近では、クラウド系のWBSやタスク管理ツールが充実していきていますが、やはり王道のExcel管理も外せないといったところでしょうか。

WBSやガントチャートはあくまで進捗の管理がメインとなるため、それぞれのタスクの細かい状況や課題を管理するのには向いてません。

そのため、WBSのタスクと課題管理を合わせて実施するのが効率的な管理となってきます。

（注意）以下のランキングは、クリエイティブコンテンツラボトウキョウが独自に評価したもので、サービスの品質を保証するものではありませんので、ご注意ください。

Backlog

私がお勧めするのは、Backlogを使って、作業タスクと課題、スケジュール管理を同時に行うという方法です。

Backlogc（バックログ）は、ほかにもファイル管理やGitとの連携などプロジェクト管理には欠かせない機能がたくさんあります。

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

参考

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

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

続きを読む

Backlogの場合、タスクを登録すると自動的にガントチャートが生成されます。

日々の進捗管理で、直近の進捗状況をガントチャートで確認するのに非常に役に立ちます。詳細な使い方などは以下を参照ください。

場合によっては、Excelと並行して利用するような状況も出てくるかもしれませんが、BacklogではExcelのタスクを一括で取り込む機能があるため、登録の手間は省略可できます。

とにかくプロジェクト管理では、管理するべき内容が多岐にわたり作業工数も膨大になりがちなので、タスク、課題、進捗、構成管理、コミュニケーション管理などある程度まとめて管理できるBaclogのようなサービスを利用することで非常に効率的に管理ができ、作業不可もかなり低減することができます。

気になった方は、以下から無料トライアルをはじめてみてはいかがでしょうか、

【100万人以上が使う】タスク管理・プロジェクト管理ツール「Backlog」の新規無料トライアル

Asana（アサナ）

Asana（アサナ）

プロジェクト管理ツールのAsanaは、大企業での実績も多く、機能が充実しているだけではなく、デザインが非常に優れていると思います。

機能としては、以下のようなものが用意されておりますが、それ以外にも100を超えるサービスとの連携が可能となっているようです。（2021年7月25日現在）

• タスク管理（リスト、かんばんボード）
• ガントチャート（タイムライン）
• カンレダー
• ワークフロー
• ダッシュボード

Asana for Salesforceを使うことで、Salesforceとの連携も可能となっているようです。

お客様や関係各社と共同でタスク・課題管理ツールを利用する場合によくある問題が、誰が最終的に承認してクローズをするのかということです。

Backlogでも、承認者や承認日の項目を設けて対応することは可能ですが、asanaの場合には、専用の承認ワークフローが定義できるため、複雑な承認ワークフローが必要な場合には、Asanaを選択するのもよいでしょう。

タスクの表示方法は、Backlogと同じようにリスト表示やタイムライン（ガントチャート）、ボード（かんばん）の3種類があるようです。

ボードの場合には、ドラッグ＆ドロップでステータスの更新が可能です。

サポーターさん

ダッシュボードの機能は非常に便利なものとなっており、そのまま利用すればプロジェクトの進捗報告も捗りますね

Basicプラン（個人利用）は、無料となっています。

試してみたい方はBasicプランから始めてみてはいかがでしょうか。

Jira（atlassian製品）

続いては、atlassian製品であるJIRAとなります。グローバルプロジェクトではJIRAとConfluenceの組み合わせがよく利用されています。

JIRAはプロジェクト管理ツールで、タスク管理を得意とします。

保守サービスなどの運用において、チケットのやり取りで利用されることもあります。

主な機能は、以下の通りですが、Confluenceと一緒に使うことでプロジェクト管理を効率的に行うことができるようになっています。

• 課題の編集（要約、説明、担当者の変更など）
• ワークフローの操作
• ファイルの添付
• コメントの追加
• 作業時間のチェックと記録
• 課題に関連したソースコードのコミット

グローバルなど大規模プロジェクトでのコールセンターや保守サポートなど、他のシステムと連携してリアルタイムでチケットの管理を行うような場合には、非常にお勧めのツールとなります。

Confluenceについては、ドキュメントコラボレーションツールの位置づけとなっており、会議などの議事録としての用途やアイデアを形にする際に、ホワイトボードにマーカーで自由に描くように、ブラウザ上で自由に文字を書いたり、表や画像を挿入したり、文章にコメントしたり、課題と紐づけたりすることができます。

無料プランでも小規模プロジェクトであれば十分使える内容となっているので、試してみたい方はAtlassianの公式HPより登録してみてください。

Redmine

Redmineの機能としては、タスク管理、ガントチャート、wiki、ファイル管理などBacklogに近い機能が多くあります。

Backlogと比較してredmineはセットアップが多少面倒なところがあるのと、使い慣れるまでに少し時間がかかるというのが印象です。

日本人の場合には、MY REDMINEという日本人向けのサービスがありますので、そちらを利用するのもよいかもしれません。（以下の公式のURL）

redmineのよいところは拡張性が高いということでしょうか。豊富なプラグインが提供されており（有償のものが多い）、プロジェクトの特性に合わせてプラグインを利用することで非常に効率的な運用ができます。

例えば、アジャイル開発を行う場合には、Redmineの「Redmine Backlogs」というプラグインを利用することで、スクラム（Scrum）ができる環境を簡単に実現できます。

Redmine Backlogsは、GitHubでプラグインが公開されており、redmine環境へインストールすることで利用可能となります。

ExcelベースでのWBS管理

お勧めツールとして、各種クラウドサービスをご紹介してきましたが、Excelベースのものがよいという声もありますので、ExcelのWBSをご紹介したいと思います。

ExcelのWBSテンプレートやツールはWEBで無料公開されているものが多くありますが、その中でもおすすめのものをご紹介いたします。

クリエイティブコンテンツラボトウキョウが提供するSalesforceの標準WBSのテンプレート（サンプル）もExcel版でご用意していますので、ぜひご活用ください。

EXCELのWBSであると便利な機能としては以下のようなものがあります。

・タスクの親子、前後関係の自動紐づけ（あると便利）

・ガントチャート表示（あると便利）

・担当者毎の工数集計機能（あると便利）

・ＥＶＭ（Earned Value Management 出来高管理）（プロジェクトによってはEVM管理を必須とする場合がある）

・進捗の集計（計画数、実績数、計画の乖離、遅延日数など）（あると便利）

開発マイルストーン

無料で使えるExcelのWBSとしては有名な開発マイルストーン。単純にWBSとガントチャートの機能としては必要なものは一通りそろっています。

・開始終了日を設定するとガントチャートが自動的に表示されます。またガントチャートは、月・週・日・時間の単位に切り替えて表示ができます。

（イナズマ線も自動的に設定されます）

・稼働工数（予定と実績）の自動集計が可能

・祝日も設定しておくと自動的に土日と祝日を考慮して終了日の計算が実行されます。

・MSProject（XML形式）のデータをインポート可能

以下、全メンバーの作業工数の集計結果

muraka進捗管理表

こちらはＥＶＭ（Earned Value Management 出来高管理）ができ、且つ非常に細かくタスク管理や工数管理ができるツールとなっています。

ただし、シェアウェアとなっているため、お金を払って利用するのであれば、クラウドサービスのほうがお客様とリアルタイムで状況共有できるなどのメリットも多いため、評価を少し下げています。

まとめ

WBS作成ツールのご紹介は以上となります。ほかにもExcelのテンプレートでお勧めしたいものはありますが、また別の記事で詳しく書きたいと思います。

続いては、クリエイティブコンテンツラボトウキョウがSalesforce導入プロジェクトで利用している標準WBSのテンプレートと、WBSの作成手順をご紹介していきたいと思います。

続きは、次の記事をご覧ください

次の記事の前に、クリエイティブコンテンツラボトウキョウが提供するExcelのWBSテンプレートをダウンロードしたいという方は、こちらをどうぞ。

参考

WBS（work-breakdown-structure）（Excelテンプレート）サンプル

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

続きを読む

関連記事

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

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

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

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

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

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

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

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

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

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のアイコンを利用し、階層構造で表現しています。

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

続きは、次の記事へ

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

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

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

続きを読む