プロジェクト管理 &#8211; AI開発実践ラボ

故障管理表（バグ管理表）（Excelテンプレート）サンプル

1.テーラリングガイド

1.テスト進捗（サマリー）

テスト進捗の全体サマリーのページです。こちらでは、報告日時点の状況を集計して予実分析をした結果を表とグラフで表示しています。

また進捗コメント欄を設け、進捗に対する定性報告も記入できるようにしてます。

遅延している場合のリカバリー案などは、別途詳細な内容を記載したほうが良い場合もありますので、その場合は適宜必要な項目を追加してご利用ください。

上記の表にある、消化済ケース数の合計は、報告日を起算日として、明細のシートから自動的に数値を取得する数式を設定しています。

また、表の数値をベースにグラフを作成しているので、こちらも報告日を変更すると自動的に更新されるように作成しています。

グラフは2種類用意しており、当初計画の予定テストケース数（総数）に対して、報告日時点で、どの程度消化できているか（進んでいるのか遅れているのか）すぐに判断できるように可視化しています。

また、もう一つのグラフでは、全体の残ケース数をベースとしており、今のペースで進めていって計画通りの期限までに終了するのか判断できるように可視化しています。

プロジェクトで管理したい指標に合わせて、取得するデータや可視化したいグラフは個別に追加・カスタマイズしてもよいでしょう。

２．テスト進捗管理表（明細）

明細のほうでは、日単位でのケース消化状況を確認できるような内容としています。

テスト期間（FROM-TO)にあわせて、実施予定日を入れて、各予定日にどのシナリオ、ケースを実施するのか決めたら、日単位で消化見込みのケース数を入力します。

（当日消化予定数）消化数累積（予定）と残ケース数（予定）は自動的に計算されるように数式を設定しています。

実績の項目についても同様で、当日消化数（実績）を入力すると累積と残ケース数が計算されるようになっています。

また、実績欄には、消化率（％）を計算する項目も用意しています。

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

最後に予実欄では、消化予定のケースに対しての進捗状況を判断する数式を入れています。

予定ケース数＜実績ケース数の場合、前倒しとして、＝の場合はオンスケ、予定ケース数＞実績ケース数の場合は、遅延と判断しています。

テストの生産性を鑑みて、日々消化可能なケース数を設定するとよいでしょう。

最初のサマリーの状況と合わせて進捗状況を判断し、遅延が発生しそうな見込みがあれば、休日や残業対応や要員を増やすなどの具体的な施策を検討する必要があります。

さらに、テストを実施するとバグの対応も必要になってきますので、上記軸だけで見ているとバグ改修の対応工数が見えなくなるため、バグ管理表と組み合わせて、1つのファイルで管理するのもよいでしょう。

故障管理表のテンプレートも用意しているので、そちらも合わせてご利用ください。

参考

進捗報告書を作成しよう（１）進捗報告（概要）~スケジュール

2.テスト進捗管理表テンプレートのダウンロード

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

ダウンロード前に利用規約を必ずお読みください。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

テスト進捗管理表（EXCEL版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

テスト進捗管理表（EXCEL版）のダウンロードはこちら

サポーターさん

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

にほんブログ村

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。皆様の役に立つように改善していきたいと思います。

要員計画を立てる（山積み表・リソースヒストグラム）（Excelテンプレート）

セールスフォース標準化推進ラボ — Sun, 21 Nov 2021 05:47:48 +0000

今回は、提案やプロジェクト計画の段階で必要となる、要員計画（リソース計画）について説明します。

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要員計画の山積み表のテンプレートをご提供しておりますので、併せてご利用ください。

1.要員計画

要員計画が最初に必要になるのは、提案の段階です。提案の段階で概算見積を作成する際には、まずシステム構成や要件を整理し、最終的にシステム機能一覧のレベルまで落とし込みをする必要があります。

見積手法によって、やり方は異なりますが、主な見積手法では、ざっくりと以下のように見積を行います。

※見積方法については、別の記事で詳細に説明する予定です。

参考

類推見積：過去類似プロジェクトや開発したシステムをベースに超概算レベルの工数や金額を算出する場合に利用します。同じシステムを別のお客様や部署へ展開するような場合に利用できそうです。
ボトムアップ見積：作成する成果物や作業内容から想定工数を算出し、積み上げて合計工数を算出する。
パラメトリック：係数モデルを利用して重み付けをして工数を算出する手法で、有名なものとしては、ファンクションポイント法となります。
- ファンクションポイント法：機能ベースで、開発種別（オンライン、バッチ、帳票など）や開発難易度や規模などにより重みづけ係数を設定し、工数を算出する方法です。ある程度開発する機能が明確になってこないと利用するのが難しいのが難点となります。

作業工程別要員計画

各工程で作業に必要な工数概算が算出できた前提で、次に進みます。

※マスタスケジュールも事前に作成してください。

マスタスケジュール、マイルストーンに基づき、各作業工程の作業期間と必要な要因を以下の表のように取りまとめます。

例では、最初の現状分析の工程では、作業期間2カ月に対して、主に作業を実施する業務コンサルタントを2カ月配置しています。

また、プロジェクトマネージャは基本的に開始から終了までの全ての期間で必要となるため、全期間1人月で割り当てています。

※プロジェクト規模によっては、サブPMを配置したり、PMOを増やしたり調整が入ります。

各工程で必要となる役割やスキルはことなるため、まずは工程ごとに役割と必要な人数を定義しておきます。工程ごとの作業工数合計は、最初に成果物、作業ベースで見積した工数を超過しないように注意しましょう。

あとは、各工程ごとに役割と工数を配置していきます。最終的に細かい工数の調整を行うときには、見積の工数や原価を見ながらの調整となるため、役割と工程ごとに工数を集計しておき、また役割ごとに標準原価を使って、全体の想定原価を算出しておくとよいでしょう。

工数、金額を鑑みて、プロジェクト責任者や営業担当も交えて、最終的な要員計画を仕上げるようにしましょう。

リソース計画（人別計画）

作業工程別の要員計画が完了したら、プロジェクト開始までに具体的な人の名前を入れて計画を詳細化していきましょう。

上記の例では、Aさんをプロジェクトマネージャとして、21年1月から22年4月までアサインするように計画しています。

また、コンサル部分については、外注する場合もありますので、その場合は外注費用の原価に合わせて標準原価を調整してください。

上記はあくまで計画となるため、実際の作業工数の管理は別途行う必要があります。

遅延により残業が発生したり、人の入れ替えが発生したりなど、様々な要因で工数が上振れすることは多いため、常に適正な工数の範囲で進んでいるかモニタリングする必要があります。

２.要員計画表（山積み表・リソースヒストグラム）テンプレートのダウンロード

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

ダウンロード前に利用規約を必ずお読みください。

一般公開資料

（Update：2022/04/14）エクセルを直接ダウンロードできるリンクを追加

要員計画表（Excel版）のダウンロードはこちら

（以下、スプレッドシートで開く）

要員計画表（Excel版）のダウンロードはこちら

サポーターさん

資料はダウンロードしてからお使いください

サポーターさん

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

にほんブログ村

プロジェクト進捗報告書（PPTテンプレート）サンプル

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 16:26:43 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したプロジェクトの進捗報告書のテンプレートをご提供しております。

1.ページサンプル

テンプレートPPTのサンプルがわかるようにイメージを添付します。（一部のみ）

プロジェクト進捗報告書

プロジェクト進捗報告書(目次)

プロジェクト進捗報告書(スケジュール)

2.進捗報告書（PPTテンプレート）の利用方法

進捗報告書（PPTテンプレート）の利用方法については、以下の記事を参考にしてください。

参考

今回の記事は、プロジェクトの進捗報告資料作成がテーマとなります。プロジェクトの…

3.進捗報告書（PPTテンプレート）のダウンロード

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

ダウンロード前に利用規約を必ずお読みください。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

進捗報告書（PPT版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

進捗報告書（PPT版）のダウンロードはこちら

まとめ

サポーターさん

テンプレート関連の記事

サポーターさん

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

にほんブログ村

進捗報告書を作成しよう（２）工程別詳細報告~その他連絡事項まで

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 15:53:42 +0000

プロジェクトの報告資料作成の後半は、各工程ごとの詳細な進捗報告とともに、課題の棚卸や要求仕様に関する変更の報告などに関する説明となります。

もう一度、全体の章立てを掲載しておきます。後半では、このうち第3章以降の内容が対象となります。

【進捗管理報告資料（章立て）】参考

前回定例会のTODO確認
2.進捗状況（サマリー）ご報告
1. マスタスケジュールの計画に対する進捗状況
2. 工程別スケジュールに対する進捗のご報告
3. WBSベースの定量報告
4. 遅延発生時のリカバリー策ご報告
工程別進捗状況ご報告
1. 要件定義
2. 設計・開発・単体テスト
3. 結合テスト、総合テスト、受入テスト
4. 教育、移行
課題の対応状況に関するご報告
1. 重要課題の発生状況と対応方針に関するご報告
2. 課題管理表の棚卸
要求仕様の追加・変更に関するご報告
1. 要求仕様管理状況ご報告
ご連絡・ご依頼事項
1. 全関係者様へのご連絡・ご依頼事項
2. 個別のご連絡・ご依頼事項

プロジェクト進捗報告書の前半（1章、2章）の内容を確認したい場合は、以下の記事を参照してください。

参考

進捗報告書を作成しよう（１）進捗報告（概要）~スケジュール

今回の記事は、プロジェクトの進捗報告資料作成がテーマとなります。プロジェクトの…

3.工程別詳細状況報告

前半では、プロジェクトの全体のサマリーについて報告してきましたが、後半では工程別の詳細な状況報告をしていきます。

工程別ということで、要件定義、設計、開発、テストという順番となりますが、基本的に複数プロジェクト同時並行でないような場合や、アジャイル開発でない場合は、特にウォーターフォールの場合には、基本的に工程が重複することはあまりないと思います。

工程ごとに報告すべき内容や観点が異なってきますが、それぞれの工程での進捗が明確にわかるように定性報告に加えて、定量的な報告も合わせて実施するようにしましょう

まずは定性報告を行い、そのあと定量報告を分けて行う（順序はどちらが先でもよい）といった報告がよいでしょう。

サンプルでは要件定義に関する報告内容を例としていますが、定性報告については、要件定義以外の他の工程についても同様の報告で問題ないでしょう。

以下は、報告のまとめ方の1つの例です。

今週の作業予定に対して、実績はどうだったのか。
予定分の内容がすべて検討できたのか、積み残しとなっているタスクや課題があるかどうか。
次週予定している作業は何か。積み残しについては、次回で消化できるのか、別途追加の調整が必要なのか。
今週発生した課題についての報告。※特にQCD（品質・コスト・納期）に影響するような内容は必ず報告に含めてください。
進捗遅延については、具体的にどのようにリカバリーするのか対策も報告する

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

続いて、以下は定量報告のサンプルとなります。要件定義フェーズの場合、定量報告する基準としてここでは成果物をベースにした報告を実施しています。

要件定義書（ドキュメント）の構成に対して、各章ごとに何ページ作成する予定で、それに対して報告時点でどの程度（何ページ）出来上がっているのかをもって進捗率を算出しています。

ここで重要なのは、「進捗率の何%ってどの程度仕上がっている状態なのか」を明確に定義してお客様と合意しておくことです。

下記の例では、0%を未着手とし、お客様の最終レビュー完了で90%としてます。

その間の作業中や内部レビューなど細かく分けていますが、細かくするほど管理が大変になるので、プロジェクトの規模や進捗管理担当者によって適切な管理粒度としてください。

また何をもって実績の頁数としてカウントするのかを明確にして、補足として記載しておくとよいでしょう。

ページ下段のグラフについては、スケジュールの進捗と同様、報告時点での計画に対する進捗が一目でわかるように添付してもよいでしょう。

※図の中の数値はランダムなものに差し替えています。

補足）

設計・開発フェーズでは、定量報告の指標として機能数ベースの成果物とするのが基本となります。

Salesforce〇〇システム　会計業務領域　NN機能　作成予定設計書数：NN件　開発プログラム：NN件

また、テストフェーズでは、計画数（テストシナリオ件数、ケース数）に対する実績数（消化済みシナリオ、ケース数）が一般的です。

さらに、品質管理の観点から、バグの検出率などについても報告したほうがよいでしょう。

バグについては、故障管理表などを用いて、どの工程でどのようなバグが何件発生したのか、定性的、定量的に把握し傾向分析を行い、結果によってテストケースの追加ややり直し等を検討する必要があります。

バグの内容やバグの傾向分析は必ず実施し、同じようなバグが多発している場合には、原因を特定し対策を検討してください。

また、同じようなバグがないかどうか必ず横展開して確認するようにしましょう。

まずは正しく状況を把握し、報告できるようにしましょう。故障管理表を用いた品質管理については、以下の記事を参考にしてください。

参考

故障管理表（バグ管理表）（Excelテンプレート）サンプル

4.課題の対応状況

4-1.重要課題の発生状況と対応方針に関するご報告

プロジェクトのQCD（Quality、Cost、Delivery）に影響するような重要課題がある場合には、別途詳細な報告を行います。

課題については、これまでどうよう課題の内容に加えて、原因と対策をしっかり報告するようにしましょう。

特にこの場合、発生原因は重要で、例えば開発メンバーによるスキル不足により遅延が発生しマスタスケジュールの変更が必要な場合などには、開発ベンダー側に非があるため、追加コストは開発ベンダー側で負担しないといけない場合があります。

逆にお客様起因の場合には、追加費用は支払っていただくように調整する必要が出てきます。

4-2.課題・TODOの棚卸

タスク・課題管理の棚卸を実施する場合には、PPT（パワーポイント）のスライドで説明するよりも、課題管理のエクセルや課題管理ツールを使って報告したほうが効率的でしょう。

会議の時間も限られているため、無駄の内容に要点だけを伝え、状況を確認、報告するように心がけましょう。

課題管理ルーツについては、Backlog（バックログ）の利用がお勧めです。お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。

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

参考

5.要求仕様の追加・変更に関するご報告

続いて、要求仕様の追加・変更に関する報告を行います。プロジェクト開始前にご提案した内容に対して、要件定義を進める中で、もともとお客様が要求していた機能について、変更や取り下げが発生したり、追加の要求が出てくる場合が多々あります。

こういった追加、変更についてお客様と都度合意せず曖昧に進めた結果、開発費用が当初見積もりの倍の金額になってしまい、お客様は予算枠が決まっているため、追加分のお金は払えないということになってしまう可能性があります。

できる限り、週次定例会などで都度お客様と確認するようにしましょう。

要求仕様の管理については、上記の目的以外にも、そもそもお客様の要件がもれなく定義されているか、実現方式や改善効果、優先度などを確認するためにも一覧に取りまとめて管理することを推奨します。

要求仕様管理一覧は、こちらの記事からダウンロードしてご利用いただけます。

参考

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

プロジェクト進捗報告書（PPTテンプレート）サンプル

6.ご連絡・ご依頼事項

最後は、お客様や関係各社への連絡・依頼事項を記載します。

6-1.全関係者様へのご連絡・ご依頼事項

関係各社向けの連絡、依頼事項を記載します。

連絡事項に関しては、具体的に記載し、責任者と期限を明記するようにしましょう。また担当が決まった場合には、タスク管理ツールなどへ転記し進捗を管理するように心がけましょう。

6-2.個別のご連絡・ご依頼事項

お客様や個別の関係者様への連絡、依頼事項を記載します。

進捗報告書作成のまとめ

ここまでで進捗報告書作成の説明は以上となります。

最後に、本記事で説明した進捗報告書のテンプレートを利用したい方は、以下からダウンロードしてご利用ください。

参考

進捗報告書を作成しよう（１）進捗報告（概要）~スケジュール

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 15:32:50 +0000

今回の記事は、プロジェクトの進捗報告資料作成がテーマとなります。

プロジェクトの進捗報告については、誰に対して何を報告するか、また報告対象や作業工程によって報告すべき内容は異なってきますが、今回はプロジェクト開始から、お客様に週次定例会で報告するような内容を想定して解説していきたいと思います。

【進捗管理報告資料（章立て）】参考

前回定例会のTODO確認
2.進捗状況（サマリー）ご報告
1. マスタスケジュールの計画に対する進捗状況
2. 工程別スケジュールに対する進捗のご報告
3. WBSベースの定量報告
4. 遅延発生時のリカバリー策ご報告
工程別進捗状況ご報告
1. 要件定義
2. 設計・開発・単体テスト
3. 結合テスト、総合テスト、受入テスト
4. 教育、移行
課題の対応状況に関するご報告
1. 重要課題の発生状況と対応方針に関するご報告
2. 課題管理表の棚卸
要求仕様の追加・変更に関するご報告
1. 要求仕様管理状況ご報告
ご連絡・ご依頼事項
1. 全関係者様へのご連絡・ご依頼事項
2. 個別のご連絡・ご依頼事項

管理人

進捗報告をしっかり行うことでお客様に安心感を与えることができますし、信頼感を得ることにもつながるため、報告すべき内容をしっかり理解して報告書を作成しましょう。

大規模プロジェクトになってくると、上記以外にもより詳細な報告内容を求められることはありますが、中規模程度のプロジェクトでは上記内容で問題ないと思います。

※お客様によって求められる観点とか書式も異なるため一概には言えませんが、プロジェクトの特定に合わせて適宜変更してください。

1.前回定例会で発生したTODOの確認

定例会の場合には、前回の定例会で発生したTODOの進捗状況を確認する場を設けることが多いと思います。

先にプロジェクトの進捗報告を行うほうが良い場合もあります。会議の時間枠や重要な議題があるかどうかなどで、優先順位をつけてスライドを構成するようにしましょう。

また、課題・TODOについては以下のようなスライドにタイトルと内容（サマリー）を纏めて簡単に確認できるようにするとよいでしょう。

もしくは、バックログ（Backog）などの課題・タスク管理ツールを利用している場合には、課題を一覧で表示して状況の確認とアップデートを行うことでタスク管理の効率化が図れます。

エクセルなどで管理されている方は、一度こういったサービスを検討してみるのもよいと思います。

タスク・課題管理については、私もよく利用しているBacklog（バックログ）がお勧めです。お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。

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

参考

進捗報告書を作成しよう（２）工程別詳細報告~その他連絡事項まで

2.進捗状況（サマリー）ご報告

続いて、進捗状況のサマリーを報告するページを作成します。

ここでは、あくまでプロジェクト全体状況のサマリーの報告となるため一目でわかるように要点だけを簡潔に説明しましょう。

報告するお客さまがどの層の方なのかによって、記載内容や粒度は変えたほうが良いです。

経営に近い方が参加されるような場合には、QCD（品質、コスト、納期）に関する事項を優先して報告するようにしましょう。参加されるトップの人が何を知りたいのかを意識して資料を作成しましょう。

どうしても自社の視点で資料を作成してしまうことが多くなりがちですが、お客様の視点（または第三者の視点）に立って、報告することが大切になってきます。

報告内容は以下のように基本的に1つの事項に対して1、2行程度でまとめて状況を記載します。重要な事項や補足は別のページで詳細を報告します。

参考

本日時点で設計70%完了の計画となっているが仕様調整が難航しており達成率65%で遅延しているが、設計要員を0.5人月追加することで、今月中にリカバリー可能な見込み。マスタスケジュールへの影響はなし

スケジュールの遅延が発生していたり、仕様変更や追加等でお客様の予算を超過しそうな状況が発生しているような場合には、状況と合わせて、具体的な対策を検討したうえで打ち合わせに臨むようにしましょう。

2-1.マスタスケジュールの計画に対する進捗状況の報告

全体の状況を簡単に報告したあとは、個別のサマリーを報告します。まずは、マスタスケジュールに対する進捗状況を報告します。

各工程間で多少のスケジュールの遅延があったとしてもマイルストーンの節目やリリース時期が遅延しないというのが最重要事項となります。

お客様は、システムリリースに向けて、エンドユーザとの調整や業務・運用切替の準備、検収・支払いなどで経理部門との調整を行うなど、多岐にわたっての調整・承認が必要となります。

またお客様自身のプロジェクト推進の評価にも直結するため、スケジュールに遅延がないかどうかは非常に気にされる事項となります。

報告日の時点で、スケジュールの遅延があるかないかをまずは明確に報告しておきましょう。

もし遅延が発生もしくは遅延のリスクがある場合には、正直に報告するとともに、リカバリー策を提示して承認をいただくようにしましょう。

例えば要件定義工程で要件の取りまとめが遅れており、4人日程度の遅延が発生しているといった場合には、週末の2日間に2名出勤して遅延をリカバリーするなど。※あまり休日出勤や残業してリカバリーというのは推奨できませんが、本番リリース直前など状況によっては、このような対策も講じる必要がでてきます。

遅延しているのをお客様に隠して、リカバリーもできなくなってから報告するような事態だけは避けるようにしましょう

2-2.工程別のスケジュールに対する進捗の報告

マスタスケジュールの進捗の次は、工程別の進捗状況サマリーを報告するページを用意します。

こちらでは、作業工程ごとの進捗（オンスケジュール、遅延あり（リカバリー可能）、遅延（リカバリ不可）、クリティカルな課題あり）など状況が一目でわかるようにアイコンを使って図示するなど工夫をするとよいでしょう。天気のアイコンなどで表現するとわかりやすいでしょう。

ポイントとしては、工程別に遅延が発生している場合には、その原因は何か具体的に記述することです。

また合わせてリカバリー策を検討し、記載しておきましょう。原因は、外部要因と内部要因に分けて記述し、それぞれに対して対策を検討するようにしましょう。

外部要因：

（発生原因）お客様側で課題の対応や仕様の検討が遅延している。お客様内部の承認プロセスが遅延しているなど。

（対策）期限を明確に設定して、いつまでに実施いただけない場合は、スケジュールの遅延が発生するなど、お客様にスケジュール遅延のリスクがあることを説明し、催促する。

内部要因：

（発生原因）テストケースの検討が遅延している。バグが大量に発生してバグ改修に時間がかかっているなど。

（対策）開発メンバーを増員して、バグの改修効率を上げる。

2-3.WBSベースの定量報告

工程別のスケジュール報告では、定量的な方向となりますが、続いては、WBSのタスクベースでの定量報告を行います。

ここでは、WBSのタスクを工程別などある程度の単位に取りまとめて集計した結果を報告するとよいでしょう。

計画に対して、現時点の完了率、達成率を集計し、遅延が発生している場合には、遅延しているタスクの数や遅延日数と合わせて備考欄に遅延内容や理由などを記述します。

また合わせて集計結果をグラフ化しておくとタスクの消化具合も一目でわかるので可能なら入れておきましょう。

WBSの集計は、タスク管理ツールを利用していれば自動的に集計される場合が多いと思います。

最初にご紹介したBacklogでもバーンダウンチャートでタスクの消化具合はトップページで確認することができます。工程ごとにバーンダウンチャートは表示されるため、Backlogをお使いの場合は、これをそのまま進捗報告資料に添付するやり方が効率的かと思います。

（Backlogのバージョンチャート）

2-4.遅延発生時のリカバリー策についてのご報告

これまでの報告の中で、進捗に遅延がある場合には、リカバリー策を報告するようにしましょう。

リカバリー策は、具体的で現実的な案としましょう。

まとめ

ここまでは、進捗報告のサマリー部分の報告内容となります。後半は、詳細な進捗報告とともに課題や仕様変更に関する報告の説明となります。

後半の内容を確認したい場合は、次の記事を参照してください

参考

プロジェクトの報告資料作成の後半は、各工程ごとの詳細な進捗報告とともに、課題の棚…

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

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 14:37:53 +0000

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

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

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

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

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

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

1.現状調査(AS-IS)

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

参考

現状(AS-IS)調査、要件整理
- 組織構成確認
- 現行システムの調査
- 現行業務プロセスの調査
- 現行業務フロー図の作成

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

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

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

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

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

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

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

参考

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

2.システム要件定義

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

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

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

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

将来像（TO-BE）モデルの検討
- 新業務フロー図の作成
- 新業務一覧の作成
- システム化方針
- 機能要件の整理（要求機能一覧）

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

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

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

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

参考

システム機能要件の検討
- アクター定義、新業務フロー定義、状態遷移（ステートチャート図）の作成
- システム機能一覧の作成
- データモデルの検討
  - ER図（データモデル定義）、オブジェクト一覧の作成、項目定義書の作成
  - CRUD図（機能レベル）
- UI規約の定義
  - UI規約、画面一覧、画面遷移図
  - 帳票定義、帳票一覧、帳票定義書
- 外部インタフェース定義
  - 外部インタフェース一覧、外部インターフェース連携図（概要）

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

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

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

参考

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

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

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

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

参考

非機能要件検討
- 非機能要求グレード表を用いた要件のヒアリング
- セキュリティ方針
- 運用・保守性の検討
- 可用性検討、信頼性要件、上位互換性要件
- 規模要件、性能・拡張性検討

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

IPA情報処理推進機構「システム構築の上流工程強化（非機能要求グレード）」

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

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

参考

設計・テスト方針書の作成
- 設計方針
- テスト方針
教育要件の検討
- 教育方針、対象者、実施方式、スケジュール
移行要件の検討
- 移行方針、移行範囲、体制」役割の検討、移行スケジュール（概要）
- 移行環境、業務移行方針、システム移行方針、データ移行方針
標準化ドキュメント一覧（更新）
- - プロジェクト標準用語定義書
  - 名称付与基準
  - コード定義書
  - システム運用作業支援ツール一覧
  - 標準化ドキュメント一覧

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

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

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

参考

プロトタイプ作成
- 環境構築
- オブジェクト設定（〇〇）
- 画面レイアウト整理

まとめ

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

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

参考

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

作業計画を立てる（WBSを作成する）（２）プロジェクト計画系タスク

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 12:41:14 +0000

前回はWBSやガントチャートのツールをご紹介しましたが、今回の記事は、実際にWBSの作成について説明していきたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考

プロジェクト準備（計画）
システム要件定義
設計
開発
単体テスト
内部結合テスト
外部結合テスト
総合テスト（システムテスト）
運用テスト、受入テスト

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

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

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

管理人

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

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

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

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

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

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

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

参考

提案内容の引継ぎ
プロジェクト計画書作成
要員調達
プロジェクト管理ツール準備
標準テンプレートの用意
プロジェクト内キックオフ
お客様とのキックオフ実施

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

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

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

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

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

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

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

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

参考

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

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

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

参考

プロジェクトの目標とゴールが明確に定義されているか（お客様のRFPの内容とずれていないか）
当初提案内容が盛り込まれているか（システム化の方針、ソリューション、成果物、スケジュール等）
前提条件や共有しておくべきリスクと対策が盛り込まれているか
プロジェクトのマスタスケジュールや進め方は現実的なものとなっているか

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

レビュー計画表

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

レビュー指摘表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

参考

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

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

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

参考

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

作業計画を立てる（WBSを作成する）（１）タスク管理方法の検討

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 11:58:58 +0000

今回の記事は、作業計画を立てる（WBSを作成する）がテーマとなります。

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

一般的には、これらは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との連携などプロジェクト管理には欠かせない機能がたくさんあります。

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

参考

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

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

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

スケジュール管理に便利！ガントチャートの簡単な使い方（Backlogブログより）

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

Google スプレッドシートを使って、Backlogに課題を一括登録しよう（Backlogブログより）

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

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

Asana（アサナ）

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

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

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

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

Asana for Salesforce

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

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

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

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

サポーターさん

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

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

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

Jira（atlassian製品）

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

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

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

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

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

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

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

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

ATTRASIAN（公式HP）

Redmine

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

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

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

MY REDMINE

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

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

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

redmine_backlogs（GitHubより）

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テンプレート）サンプル

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

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 05:18:31 +0000

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

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

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

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

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

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

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

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

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

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

参考

会議体、コミュニケーションツール
各種管理（課題管理、品質管理、コスト管理、進捗管理、仕様管理）報告のルール、様式、報告ルートなど

3-1.会議体

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

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

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

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

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

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

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

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

参考

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

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

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

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

①会議システム

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

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

②進捗管理ツール

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

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

③文書管理ツール

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

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

管理人

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

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

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

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

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

参考

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

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

参考

報告対象：課題報告対象（業務課題、技術課題、プロジェクトQCDに関する課題）
内容：報告対象に対して、具体的にどのような観点、内容で報告するのか定義します。
様式：報告様式を定義します。
報告ルート：報告ルートをフロー図等で記載。誰から誰に対して報告するのか、誰がレビュー/承認するのか明確にします。
※チームメンバー→チームリーダ（内部Review）→PM（内部承認）→お客様窓口→お客様上位層（承認）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考

要求仕様No.：要求仕様を特定するための一意の番号を採番します。プロジェクトによっては、業務領域の識別子をもうけて、識別子＋シーケンスのようにしているところもありますが、プロジェクトに合わせて自由に定義してください。
業務領域：業務領域もしくはシステムごとに領域を定義してください。担当者が異なったり、システムの利用が異なるなど、抱えている課題が異なるような単位で定義するとよいでしょう。
業務プロセス：業務領域内での大きな業務工程の定義を記載します。通常、業務プロセスごとに発生する課題・問題点は異なります。
課題・問題点：各業務プロセスで発生している課題・問題点を記載します。現状どのようになっていて、本来どうあるべきかという視点で考え、現状とあるべき状態の差が課題となります。
課題に対する対策：洗い出した課題・問題点に対して、どのようにアプローチするのか、対策を検討しその結果（案）を記載します。フィジビリティ検証や、要件定義を進める中でよりよい対策がないか検討するためのベースとなります。
改善効果（費用対効果）：課題に対する改善対策を行った場合に見込まれる改善効果を具体的に定義します。可能であれば定量的に記載し、具体的な数値でどの程度の改善が見込めるのか記載することが望ましいです。難しい場合には、定性的に記載します。
業務影響度：課題・問題が業務に与える影響度を選択します。
優先度：基本的に対応優先度は、業務へのインパクトが高いものとなりますが、費用対効果を勘案し、[業務インパクトが高いｘ費用対効果の高い]が最優先での対応となります。
対応方針：システムでの対応か、業務改善による対応か、両方による対応、もしくは対応不可を判断します。
依頼者、依頼日：誰がいつ依頼した内容となるのか、これも重要な情報となるため必ず残すようにしましょう。
要求分類：プロジェクト発足時の当初要求なのか、新規要求、要求変更、取消を判断するための項目となります。
承認者、承認日：要求仕様の対応方針及び、要求分類（追加、変更、取消）について必ずお客様に承認をいただき、承認者と日付を残すようにしましょう。

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

参考

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

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

３．品質計画まとめ

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

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

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

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

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

セールスフォース標準化推進ラボ — Sat, 30 Oct 2021 00:35:51 +0000

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

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

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

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

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

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

【お勧めの書籍】

以下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テンプレート）サンプル