プロジェクトマネジメントにおける実践的なデータ活用例

はじめに

プロジェクトマネジメントは大変だ！プロマネにはなりたくない！　よくある話ですよね。確かに大変になる要因が山ほどあります。中でも大変なのが「関係者に動いてもらう」お仕事ではないでしょうか。

プロマネは、プロジェクトの状況に応じてお客様を説得する必要があります。またメンバーに想定外の仕事を依頼しなければなりません。場合によっては上司にメンバーの追加を要求しなければなりません。

プロマネはストレスを抱えながらがんばりますが人が相手のお仕事なので思った通りに出来ません。無理やり進めると人間関係が悪くなったりします。そのためプロジェクトマネジメントは大変だ！プロマネにはなりたくない！という人が多いのではないかと思います。

関係者に動いてもらうために

お客様もメンバーも上司も納得しなければ動いてくれません。何らかのお願いをしたときに「なぜ？」と聞かれる場合は納得感が無いためです。納得を得るためには理由が必要です。また理由を裏付けるためのデータが求められます。

データには定量データと定性データがあります。これらのデータを常に最新化し、プロジェクトの開始から関係者全員に周知し続ける事が重要です。なぜなら、ある日突然出てきたデータには信憑性が無いからです。そのため日頃から以下のようなデータを準備しておき、関係者と会話する際、すぐに取り出せるようにしておきます。

データの種類	常に利用するデータの例	補足
定量データ	作業量、進捗率、予実差、残作業量、レビュー密度、バグ発生率など	プロジェクトの計画とメンバーの実績報告に基づく
定性データ	プロジェクトルール、スコープ、WBS、役割分担、計画変更の経緯、リスクなど	プロジェクトの計画と変更の記録、発見したリスクの記録に基づく

データの最新化と関係者への周知

とはいえ、これらをキチンとやろうとすると時間がいくらあっても足りません。関係者が100人を超える規模になると、データの収集、集計、分析だけで疲れてしまいます。特に定量データを扱う作業は機械的でボリュームが多いため、人手で行うとプロマネやメンバーがヘトヘトになってしまいます。

機械的でボリュームの多い作業は自動化するのが定石です。うまくツールを活用すれば、機械的な作業から開放され、人間的な仕事（物事の判断や創造）に集中できるようになります。以下は従来のやり方とツールを活用したやり方の比較です。

No.	作業	従来のやりかた	ツールを活用したやり方
1	データの収集、集計、分析	定例会の前夜にExcel、メール等のデータから管理資料を最新化（徹夜）	データ収集の省力化、集計、分析の自動化
2	データの分析	疲れて出来ない → 問題が顕在化するまで気がつかない	毎日ツールを使って分析を行い問題を早期発見 → No.4へ
3	関係者への周知	週1回（エンドレス定例会、終電逃す）	毎日（10分くらい）
4	関係者に動いてもらう事態発生	No.1から再起動（徹夜）	ツールを使ってデータを示しながら関係者に動いてほしい内容を説明

関係者に動いてもらう頻度を上げる

従来のやり方では、問題が大きくなって誰にも動いてもらえないような事態が発生する恐れがあります。こうなると、どんなにデータを集めても無意味です。

ツールをうまく活用すると関係者に動いてもらう事態が早い段階で見つかります。つまり先手を打つことができるのです。これが出来るようになると関係者に動いてもらいやすい状況を作り出すことが出来ます。

比較項目	従来のやりかた（後手）	ツールを活用したやり方（先手）
契機	問題が大きくなって、誰にも動いてもらえない事態になった後	データから積極的に問題の芽を発見し、問題として顕在化する前
頻度	ある日突然	日々
難易度	今さら無理	簡単

ツールを活用したプロジェクトマネジメントの具体例

ツールの選定や使い方は様々な選択肢がありますので、ここでは私が実践したやり方を記載します。目的は関係者に動いてもらいやすいプロジェクトの状況を作り出すことです。組織的にツールを使いこなすには少し時間がかかりますが、メンバー全員で目的を共有しながら続ける事で徐々に効果が現れます。

以降の説明は「プリザンター」という.NETで動くチケット管理ツールの機能を前提に記載します。プリザンターはプロジェクトマネジメント等「マネジメント業務全般」の快適化を目指した汎用ツールです。元々は自分の仕事を楽にするために開発したツールですが、少しでもマネジメントに携わる方々の役に立てればと思いOSSとして公開しています。

プリザンター GitHub
https://github.com/Implem/Implem.Pleasanter

進捗の見える化

納期が定められたプロジェクトにおいて、進捗は最も注目されるデータです。進捗が悪い場合、メンバーに頑張ってもらうのか、要員を追加するのか、納期やスコープを変更するのか判断しなければなりません。

バーンダウンチャート

このチャートでは進捗の全体感を見ます。

以下のような観点でツールを確認します。必要に応じて関係者に動いてもらいましょう。

• 予実差を数字で確認し、遅れが大きい場合には仕事量や期限を調整するか要員の追加を検討します。進んでいる場合には休暇の取得等を提案します。
• グレーの線は計画線です。この線が急降下している期間は負荷が集中している事を表します。要員計画等に問題が無い事を確認し、必要に応じてスケジュールを見直します。
• 緑色の線はタスクの総量の推移です。この線が上昇している時は途中で仕事が増えています。あまりに増えすぎて計画が破綻しないよう関係者と調整します。
• 各メンバーが報告した進捗量が適切か確認します。数字が少なすぎたり多すぎたりする場合には問題が発生していないかメンバーと会話します。
• 全体感の確認ができたらフィルタを使用して作業工程別や、担当者別などの切り口でドリルダウンを行います。

ガントチャート

このチャートでは個別のタスクの進捗状況をチェックします。

以下のような観点でツールを確認します。必要に応じて関係者に動いてもらいましょう。

• ピンクで表示されているタスクは進捗率よりもスケジュール消化率が多いタスクです。全体に影響があるものは速やかに対処します。
• 機能分類別にチームが分かれている場合はチーム毎に状況を報告してもらいます。報告が実態とずれていないか会話することが大切です。分類はカスタムフィールドを使用して任意に設定します。
• チェックの時間が少ない場合には「遅延」フィルタで遅れているタスクだけをチェックします。遅延の解消に他チームの協力を必要とする場合には、関連する課題を起票して協力を得やすい状況を作ります。

担当者の負荷の見える化

担当者に割り当てられたタスクの量をチェックします。

以下のような観点でツールを確認します。必要に応じて関係者に動いてもらいましょう。

• 特定の担当者に負荷が集中している場合には、負荷の分散を提案します。
• 複数の要員で並行して行えるタスクがある場合には、タスクを分割し、他の担当者に割り振る事で負荷を分散します。

期限超過の見える化

期限が超過しているタスクや課題をチェックします。

以下のような観点でツールを確認します。必要に応じて関係者に動いてもらいましょう。

• サイトに赤い数字が表示されている時は期限超過が発生しています。期限超過の理由を確認し、期限の見直しなどを提案します。
• 期限超過を放置すると「期限超過があたりまえ」の状態となりますので、常にゼロになるように対処する事が重要です。
• 期限超過が存在するにも関わらず更新日時が古すぎる場合は、チームリーダーがきちんとマネージできていない可能性があります。必要に応じてアドバイスを行います。

品質の見える化

時系列チャートで障害記録を分析します。

以下のような観点でツールを確認します。必要に応じて関係者に動いてもらいましょう。

• 障害記録の発生量が伸びているのか、おちついてきているのか確認します。リリース直前になってもグラフが伸び続けている場合には、最悪の場合リリースの延伸を検討します。
• 障害記録を、いくつかの観点で分類し弱点が無いか確認します。障害が発生している機能や、原因を作りこんだ工程などでチャートを確認し偏りを見つけます。

ツールによるマネジメントの有効性を高めるためのヒント

その1：チリツモの手番を減らす

記録や報告を求めるツールが個別バラバラに多数存在する環境はプロマネにとってもメンバーにとってもストレスです。進捗管理表、課題管理表、レビュー記録表を深い深いツリーのファイルサーバーや暴力的な量の電子メールで共有していませんか？　フォルダを開く、ファイルを開く、行を探す、コピペする、すごく大変ではありませんか？　どんなツールを使うにしても、できるだけ開くとか探すとか、そういうチリツモの手番を減らすことが大切です。こうした手番を減らすと、心が軽くなり、積極的に問題を探したりプロセスを改善したりする余力が生まれます。

その2：フィードバックする

記録や報告をしても何の反応もない。では記録や報告をするのはなぜ？ 社会人だからあたりまえ。給料をもらっているからあたりまえ。ルールで決められているからあたりまえ。という謎の宗教の信者になっていませんか？　フィードバックが無いと記録や報告のモチベーションは極端に下がります。フィードバックによってメンバーをモチベートする事はプロマネやリーダーの大切なお仕事です。

その3：マネジメントだけのツールにしない

ツールを進捗確認にしか使わないケースがありますが、うまくいかない事が多いです。進捗報告のためだけにツールを開くのは面倒ですし、忘れがちになります。できればツールはコミュニケーションをメイン機能として使用して、「ついで」に進捗などを報告してもらうようにすると、メンバーの協力を得やすくなります。

その4：できるだけツールに寄せる

メンバーが技術情報のURLをメールで送りますと言っていたら、関連するタスクのコメント欄に書いてもらうように依頼します。また、あの情報どこにありましたっけ？という質問に対しては、その情報が記載されているタスクのIDまたは、検索キーワードを伝えます。メールやチャットでの会話は簡単で便利なのですが、後から探しにくいという問題があります。こうしたやりとりをツールに寄せて、検索で見つけるという流れを基本動作にすると、ツールの有用性がどんどん高まります。

その5：マイクロマネジメントしない

ツールを使うと様々な実態を見える化出来ますが、プロマネやリーダーは、大局に影響しない些細な問題を見逃す勇気が必要です。メンバーが気づいていないようであれば、それとなく伝えますが、事細かにやり方を指示するのは懸命ではありません。メンバーが自らデータを見て、あ、これは対策しないとまずいな！と自発的に行動してもらえるよう適切な距離を保ってフォローしていくようにしましょう。

その6：次のプロジェクトでは分類を見直す

データをうまく活用するためには、どのように情報を分類するかが重要です。プロジェクトが1つ終了したら分類を見直してみましょう。データの分類が良くなるとプロジェクトの見通しが良くなります。よりよいベストプラクティスを見つけるためにも試行錯誤が大切です。

おわりに

プロジェクトマネジメントは人が相手のお仕事なので思った通りに出来ません。どんな優れたツールを使っても全ての問題を片付けることはできないでしょう。それでも、現場でご苦労されている皆さんのマネジメントが、少しでも快適になればと思います。長文を読んでいただきありがとうございます。

追記

プリザンターの解説記事を投稿しました。
簡易な業務のWeb化に使えるOSS「プリザンター」作ってみた