プロジェクト実行計画3～管理対象～

こんにちは！おおはしりきたけです！

今回はプロジェクトの「管理対象」について書かせていただきます。

プロジェクト管理とはよく言いますが、皆さん何を管理していますか？規模、メンバーに合った管理をしていますか？管理によってメンバーのパフォーマンスを下げるようなことにはなっていませんか？プロジェクトによって、管理の頻度は変わるかもしれませんが、管理対象は主に以下が多いと思います。実行計画時には、以下のことを決めておきましょう。

■スケジュール管理

進捗管理の目的は、メンバーが担当している各作業の実績を把握することで、プロジェクトを進めていくため予実との乖離を把握し、コントロールしていくために行います。決して内部用、外部用(報告のため)など異なるような管理はしないようにしましょう。

○進捗状況の確認

進捗確認のインターバル（毎日、毎週)、タイミング(朝会、定例)を決めましょう。

○予実乖離の場合の対策検討

進捗に遅延が発生した場合や、課題が発生し進捗に影響が出た場合、いつどこ（インターバル、タイミング）で対策検討を行うかを決めましょう。

○進捗報告

進捗確認で把握した進捗を、お客様に対していつどこ（インターバル、タイミング）で報告を行うかを決めましょう。

○進捗管理ツール

進捗を管理するツールは、様々なものがあります。MicrosoftProjectで管理してたものが、お客様からExcelで必要といわれ、作り直した方もいると思います。ツールが途中で変更になると、無駄な作業が発生するため、開始時点でツールも決めておきましょう。

■ 問題管理

プロジェクトを遂行していくと、ほとんどの場合、なにかしら問題が発生します。問題管理の目的は、プロジェクトに影響ある課題を把握し、その問題をどのように解決してプロジェクトを計画通りに進めるためです。「問題」というのはかなり漠然としています。「問題」自体を管理するというよりは、「問題」を「課題」にし管理していくべきです。例えば、プロジェクトが遅れているというのは「問題」だけなので管理しづらいですが、○○さんが朝来ないからプロジェクトが遅れているという原因までわかれば「課題」として扱えます。問題を管理するときは、課題にまでして管理しましょう。実行計画にの問題管理は以下のことを決めましょう

○問題管理の対象

まず、問題を管理する対象を決めましょう。プロジェクト内で問題ととらえる範囲を明確にしておきましょう。前述の○○さんが来ないという問題は、問題管理対象として本当に必要か？と考えた場合、不要だと思います。本当にプロジェクトで必要な問題の対象を決める必要があります。

○管理項目

管理する上でどのような項目が必要かも決めましょう。以下の項目があれば、あらかた大丈夫だと思います。

• 記入日
• 記入者
• 課題分類
• 重要度
• 緊急度
• 課題内容
• 対応状況
• ステータス
• 期限
• 完了日

○問題管理ツール

これも進捗管理ツールと同様で、何で管理するかというのを計画時に決めておきましょう。弊社ではツールとして「Trac」(たまにRedmine）を使うことが多いです。お客様に合わせ、Excelで管理していることもあります。メンバー、お客様に合わせ、しっかり検討しプロジェクトに最適なツールの導入を行いましょう。

■障害管理

 実行計画時には以下をしっかり決めておきましょう。

○障害の定義

障害というものが、何に対し障害というのかを明確にしましょう。例えば、「テストで検出したバグ、不具合を障害と呼ぶ」と明記して、「えっ！これ障害じゃなくて仕様変更なんじゃないの？」ということが起こらないようにしましょう。

○障害管理ルール

障害管理を行うためのルールを決める必要があります。ルールというのは、障害が解決のゴールは何にするか、障害の記入者は誰が行うか、障害全体の管理をどのように行っていくかなどです。

 ○障害管理をするテスト

障害管理はどのテストで行うのか明記しておいた方が良いです。

○障害管理ツール

進捗や問題管理同様、障害管理をどのようなツールを使って管理するのか、明記しましょう。こちらも弊社では「Trac」を使うことが多いです。Trac万歳！！

■環境管理

開発環境などもしっかり管理対象にしておきましょう。決めておくのは主に以下です。

• 対象とする開発環境
• 管理する期間
• 環境の所有者(管理責任者)

■構成管理

「構成管理を制する者は、プロジェクトを制する」と僕のおじいちゃんが言っていました。構成管理を甘く見ると本当に泣きを見ます。構成管理を対象とするリソースをしっかり決め、コミットルールをしっかり決め、後々「なんでこのバージョンコミットしたの分からないorz」ということが無いように注意しましょう。

 ■品質管理

品質ってなんですか？品質が良い/悪いってなんですか？品質って意外に認識が一致していないことが多いです。ISO9126に品質は定義されていますが、あくまで概念レベルでの定義であり、実行計画時に品質の定義を行い、何を管理するか、いつ管理するかしっかり決めましょう。

■変更管理

いくつかプロジェクト経験していますが、プロジェクト開始時から終了まで変更がなかったプロジェクトというのを体験したことがありません。大小様々ですが変更はプロジェクトにはつきものです。「アジャイル開発だから変更管理なんて (ﾟ⊿ﾟ)ｲﾗﾈ」とか思っている方もいるでしょうか？アジャイル開発は、仕様変更に柔軟することは可能ですが、そのためにより変更の管理はしておく必要があります。

■契約管理

契約明確になってますか？営業さんがそのまま持ってきた話で進めてませんか？弊社では主に【請負契約】、【準委任契約】の契約形態で行うことが多いです。ほどんどは【請負契約】ですが、スコープが未確定な場合や、変動リスクがある場合は【準委任契約】で契約しています。中には請負ながらスコープが未確定のものもあったりもします。。。実行計画時に決めておくのは以下になります。

○プロジェクトスコープ

今回の契約が、どのスコープを対象としているかを決めます。

○成果物と納品判定

請負の場合、納品物というものが発生します。また、その納品物の判定はどのように行うか等も決めましょう。

○プロジェクト継続管理

何らかの事情でプロジェクトが中断する可能性もあります。その場合にプロジェクトの終結をどのように進めていくか決める必要があります。終結措置として以下の内容は決めておきましょう。

• 終結完了までの期間
• 終結時の納品物
• 終結時の検収金額
• 検収月
• プロジェクトチームの解体の条件と解体予定日

■まとめ

プロジェクトの管理対象というのは、様々なものがあります。管理者は管理するのも仕事ですが、管理対象をガチガチに決めすぎてメンバーのパフォーマンスを下げ無いようにするのも必要があります。メンバーのパフォーマンスを最大限に引き出すのも管理者の仕事です！今は、様々なプロジェクト管理ツールがでてきているので有効に使ってプロジェクトをエンジョイしましょう。

さて、最後に巷で話題のなぞかけでしめたいと思います。

プロジェクト管理ツールと掛けまして引っ越しとときます。

その心は

どちらもTrac(トラック)を有効に使うことで、パフォーマンスが発揮されるでしょう。

今回のなぞかけは、ちょっと無理やりでしたね(汗

さて、プロジェクト実行計画については、これにて終了です。次回はまとめ記事を書きたいと思います。