プロジェクトの監視とパフォーマンスの評価【プロジェクトマネジメントの基礎】
今回はプロジェクトの監視とパフォーマンスの評価方法について解説していきます。
たとえばソフトウェア開発プロジェクトでは、プロジェクト・マネジャーと開発指揮を執る人が異なる場合があります。
その場合、プロジェクトの計画が終わり開発が始まると、プロジェクト・マネジャーの負担はそれまでの工程に比べると軽くなります。
しかし開発に入っても、プロジェクト・マネジャーは計画と実績を比べて評価し、プロジェクトに問題がないか監視しなければなりません。
今回はその評価の方法を解説していきます。
評価の基準
ベースラインとパフォーマンス・レビュー
プロジェクトのパフォーマンスは計画していた作業やスケジュール、予算をベースラインとして、評価していきます。
たとえば、当初計画していたスケジュールと現在の進捗を比べて評価・分析します。このようにベースラインと実績を比較し、評価することをパフォーマンス・レビュー（Performance Review）と呼びます。
ベースラインには、「スコープ・ベースライン」、「スケジュール・ベースライン」、「コスト・ベースライン」が存在します。ここからは、これらのベースラインはどのような資料から確認できるかを解説していきます。
スコープ・ベースライン
スコープ・ベースラインは、計画していた作業範囲のことです。
つまり、プロジェクトのタスクリストやWBS（ワーク・ブレークダウン・ストラクチャー）がスコープ・ベースラインとなります。
これらの資料と現在消化されているタスクを比較し、作業に漏れがないか、進捗に問題がないかを評価します。
スケジュール・ベースライン
スケジュール・ベースラインは計画していたスケジュールのことです。
たとえばガントチャートでスケジュールを作成していた場合は、スケジュール・ベースラインの重要な資料となります。
このほか、あらかじめ設定していたマイルストーンなどを考慮し、実績と比較しながら、プロジェクトがスケジュールどおりに進んでいるかを確認します。
コスト・ベースライン
プロジェクトの予算や費用の見積りはコスト・ベースラインとして使用できます。
当初見積っていた費用に比べ、現在はどの程度の費用を使っているのかを比較し、コスト超過が発生していないか、また発生する兆候がないかを評価します。
品質の基準
品質は品質マネジメント計画書（品質計画書）を参考にしながら、評価をしていきます。
品質マネジメント計画書には目標や評価手法が記述されているのみで、ベースラインのように、単純に実績と比較して評価できるものではありません。
多くの場合、検査を実施してそのデータを収集し、目標としていた水準や要件を満たしているかを評価します。
進捗の確認と予測
プロジェクトの評価はベースラインと実績を比較することで行えますが、データを加工することで、現在の状況がより把握しやすくなります。
ここからは進捗の確認に使える手法を紹介していきます。
バーンダウン・チャート
バーンダウン・チャートは、ひとつの課題を進める上での時間と作業量の関係を示すグラフです。
具体的には、残りの作業量を指定の期限までに完了できるかを表したグラフのことです。時間が進むにつれて残りの作業量が減少することから、右肩下がりのグラフになります。
バーンダウン・チャートを作成することにより、スケジュールに問題がないか、予定していた作業が消化されているかが確認できます。
詳しくは下記の記事もご参照ください。
https://ssaits.jp/promapedia/method/burndown-chart.htmlアーンド・バリュー・マネジメント（EVM）
アーンド・バリュー・マネジメント（Earned Value Management、以下EVMと略記）とは、予定されていた見積額と完了した作業量、使用したコストを比較し、 プロジェクトの進捗状況を把握・評価する手法です。
EVMでは各作業に応じた金額を指標にするため、進捗の確認だけでなく、コストの状況も把握することができます。
EVMについては下記の記事もご参照ください。
その他予測の方法
バーンダウン・チャートやEVMは、現状の把握だけでなく、作成したグラフからプロジェクトの今後の展開を予測することができます。これらの他にも傾向分析や回帰分析などの予測の手法があります。
品質の評価
上述のとおり、品質の評価はテストや検査をしなければ、状況が把握できません。
ここからはテストや検査の手法を紹介していきます。
ソフトウェアのテスト手法
単体テスト、結合テスト、総合テスト
ソフトウェアのテスト方法には様々なものがありますが、基本は単体テスト、結合テスト、総合テストです。
単体テストとはモジュールが期待したとおりの動作をするかの確認を行うテストです。
この工程ではプログラムロジックの誤りの検出、および修正を行います。
結合テストとは、単体テストが完了したプログラムを組み合わせ、動作を確認するテストのことです。
総合テストでは要件を満たしているかの確認を行うことを目的としてアプリケーション全体をテストします。ここでのテストは要件定義書に記載されている内容が実現できているかのテストになります。
ホワイトボックステストとブラックボックステスト
テストには、大別してホワイトボックステストとブラックボックステストの２種類があります。
ホワイトボックステストは、システム内部のプログラムの動きに対するテストです。
プログラムの構造、ロジック、制御の流れなどについて検証を行うもので、プログラム知識だけでなく、システムに対する理解が必須となります。そのためホワイトボックステストは主に開発者によって実行されます。
ブラックボックステストは、システムの入力と出力の正しさに着目したテストです。
プログラムの内容には注目せず「入力した数値に対し想定どおりの出力がされたか」のみテストを行います。
内部のプログラムに対する知識が必要ないため、開発に関わっていない第三者でも実行可能なテストです。
単体テストではホワイトボックステスト、結合テスト以降ではブラックボックステストで実施されることがほとんどです。
ホワイトボックステストとブラックボックステストについては、下記の記事もご参照ください。
テストの効率化
複雑なコードのソフトウェアを開発する場合、すべての機能のあらゆる組み合わせをテストするのは、テストの回数が膨大になるため、スケジュール的にもコスト的にも現実的ではありません。
そのため、テストにも効率化を図る手法がいくつか存在します。
同値分割とは、入力データを仕様書から導き出した範囲ごとにグループ化し、グループの中で代表的な値を１つ、テストケースとして選ぶ方法です。
一方、境界値分析とは、値グループの境界値をテストケースとして選ぶ技法です。
直交表は、テストしようとしているソフトウェアの機能の数、その機能の値の種類に注目してテスト表を作成します。
その他品質検査の手法
品質検査手法や品質管理については、これまで工場管理などの分野で研究がなされています。
それらの手法を一部紹介します。
OC曲線
OC曲線とは、検査特性曲線とも呼ばれ、縦軸にロットの合格率、横軸に不良率をとり、抜き取り検査でロットの品質とその合格率の関係を視覚的に表したものです。
グラフの縦軸は合格率、横軸は不良率を表します。不良率が高くなるほど、そのロットが合格する確率は下がっていくことになるため、左上から右上に向かって、ゆるやかなカーブを描くようなグラフになります。
散布図
散布図（scatter plot）とは、縦軸と横軸に別の特性を割り当て、２項目間の分布や相関関係を把握するために使用される図法です。品質管理の「QC７つ道具」の１つに数えられています。品質管理で利用しているデータが不十分と感じて、品質管理基準を見直す際に散布図が使用されます。
計数サンプリングと計量サンプリング
計数サンプリングとは、検査や検討の対象となる各要素の特性や属性が存在するか否かに注目する品質測定方法です[1]PMBOK第６版、704頁。。
一方で計量サンプリングは、検査や検討対象の適合度について連続的尺度を用いて測定する方法です[2]PMBOK第６版、274頁。。
ステークホルダーとの関係
プロジェクトを成功に導くには、ステークホルダーの協力が不可欠です。ステークホルダーと一口に言っても様々な立場の人がいるため、その立場に応じた適切なツールを使って、彼らの満足度や心理状態を測っていく必要があります。
ここからはその代表的な指標やツールを紹介していきます。
ネット・プロモーター・スコア（NPS®）
ネット・プロモーター・スコア（NPS®）とは、ステークホルダーがプロダクトやサービスを他者に推奨する度合いです。ネット・プロモーター・スコアは後述する計算式により-100～+100の範囲で算出されます。この数値は顧客のロイヤリティや満足度、企業に対する熱意を評価するために使用されます。
ムードチャート
ムードチャートは、ムードトラッカーと呼ばれる手法の１つです。ムードチャートは自分の気分を日次で記録します。現在では様々なWebサービスやスマートフォンアプリでこのムードチャートを試すことができます。
ムードトラッカーおよびムードチャートについては下記の記事もご参照ください。
アンケートによる士気の測定
ムードチャートはプロジェクト・メンバーのモチベーションを知るツールとして簡単に導入できますが、あまりに主観的なデータであるという欠点があります。そのため、客観的なデータを得るためにも、アンケートによって士気を測る必要性をPMBOKは訴えています。たとえば、PMBOK第７版では以下のアンケート項目が紹介されています[3]PMBOK第７版、104頁。。
- 私は、自分の仕事が全体的な成果に貢献していると感じている。
- 私は、評価されていると感じている。
- 私は、プロジェクト・チームが協力して行う仕事の進め方に満足している。
これらのアンケート項目に対して、プロジェクト・メンバーに１～５の点数で評価してもらい、プロジェクト・メンバーやチームの士気を測定します。
離職率
離職率はプロジェクト・チームの士気を測る重要な指標です。高い離職率は士気の低さに由来している可能性があるので、その動向に注意する必要があります。
変更の手続き
プロジェクトの評価をしていると、様々な変更の要望が出てきます。
「当初の計画より遅れているため、スケジュールを伸ばしたい」「当初予定していなかった機能が必要になったため、作業を増やしたい」
このような要望を「変更要求」と呼びますが、すべての変更要求に対応していると、プロジェクトは予算超過になり、作業が増え、いつまでたっても終わらなくなってしまいます。
また、各人の判断で変更欲求に対応してしまっても、プロジェクトは混乱してしまいます。
そのため、変更要求は専門の委員会を設けて対応の可否を判断し、委員会の承認を得たものだけを実施します。この委員会は変更管理委員会と呼ばれます。
変更管理委員会が設置されたプロジェクトでは、変更要求は以下のように解決されます。
- プロジェクト中に発生した変更欲求が蓄積される
- 変更管理委員会で変更要求が審査される
- 承認を得た変更要求の内容が実施される
変更要求はMicrosoft社のWordやExcelで管理しても良いですし、最近ではGoogleのスプレッドシートなど、Webアプリケーションで管理すると共有がしやすくなります。
変更管理委員会は定期的に開催するのも良いですが、緊急度の高い変更要求もあるため、あらかじめ召集のタイミングも決めておくと良いでしょう。
このように、プロジェクトに変更が入った場合の体制をあらかじめ用意しておくことで、よりトラブルの少ないプロジェクトマネジメントを実現することができます。
こうした手法をPMBOK第６版では「統合変更管理」と呼びますが、詳しくは下記の記事もご参照ください。
