こんにちは、チャイフ(@chaif123)です。
プロジェクトマネージャーがいかに大変かを説明する連載記事です。
プロジェクトマネジメントを勉強していくと、「リスク管理」という単語が出てきます。
僕は「リスク登録簿(一覧表のようなもの)」の作成はしておらず、管理という管理はできていないのですが…一方、「QCDの観点でどんなリスクが介在しているか」 ということには常に注意を払っているつもりです。
今回は、リスクという潜在的で見つけるのが難しいモノを、どのようにして発見するか、ということについて話していきたいと思います。
それでは!
Contents
プロジェクトマネージャーとは?
プロジェクトマネージャーとはどんな仕事でしょうか?
細かい所掌範囲や定義は会社によって異なるとは思いますが、共通する要素としては、「納期までに成果物を完成させられるように、プロジェクトをマネジメント(≒管理)する」仕事ではないでしょうか。
そのために、例えばこんな業務が挙げられるでしょう。
- キックオフ
- クライアントの要望から計画の立案
- 全体スケジュールの作成
- 担当メンバーのアサイン
- プロジェクト推進
- マイルストーン管理
- 担当メンバーの進捗管理
- 担当メンバーのモチベーション管理
- プロジェクトのコスト管理
- クライアントへの進捗報告
- 問題発生時の対応
- クロージング
- 納期の調整
- 成果物の取りまとめ
- クライアントへの成果報告
プロジェクトに関わるあらゆることを調整するので、必然的にお客様(クライアント)、プロジェクトメンバー、下請け、社内の上司などあらゆる人とのコミュニケーションが発生します。したがって、情報をまとめる能力・的確に説明する能力・折衝能力・リスクを察知する力・決断力・問題解決力など、様々な適性が存在します。
リスクとは何か?
PMBOKガイドによると、リスクとは以下のように定義されています。
「PMBOK(Project Management Body of Knowledge)」とは、プロジェクトマネジメントに関する知識を体系的にまとめた参考書のようなもの
by https://www.internetacademy.co.jp/trends/education/what-is-pmbok.html#chapter2
リスクとは、それが発生すれば少なくともスコープ、スケジュール、コスト、品質といったプロジェクト目標に影響を与える不確実な事象・状態
つまりリスクとは、発生するかどうかわからないもの。リスクとは、顕在化していない潜在的なもの。それを管理するのが「リスク管理」になります。
また、リスクとはネガティブなものだけでなく、ポジティブなものも含みます。ポジティブなものは「プラスのリスク / 好機」、ネガティブなものは「マイナスのリスク / 脅威」と呼ばれます。
考え始めるとあらゆるリスクが出てきてキリがないですので、実務ではそれぞれに発生確率と影響度をつけて対応を検討することになります。
リスク管理をするモチベーションは何か?
なぜリスク管理が必要なのでしょうか?
リスク管理を行う理由は、トラブルの種に対していち早く対応できるためです。
リスクというのは”火”のようなもので、放置すればするほど影響が広がっていきます。問題が広がることを「炎上」、対処していくことを「火消し」などと喩えられることもありますね。すぐに消せば大きな問題にはならないのです。
簡単に言えば「マイナスのリスクを検知できたらアラートを上げろ」ということになります。
一方、先ほども述べた通りリスクとは潜在的なものであり、意識をしないと検知することができません。そこで、リスクを発見するための考え方を見ていきます。
リスクの発見
では早速、リスク発見の流れを見ていきましょう。考える観点は、QCDとスコープの4つです。
QCDのQ:クオリティ
1つ目が、QCDのQ、クオリティ/品質ですね。
品質といっても、「ひたすら高く目指す」というものではありません。お客様の期待する品質を目指すことになります。高ければ満足度は上がるかもしれませんがコストや納期が問題になるかもしれませんし、低くてもそれがお客様の期待通りであれば問題にはなりません。
つまり、クオリティを担保するためには、第一にお客様の要件を把握することが重要になります。
そして、プロジェクト進行中に「その要件に対して、現状どの程度進められているだろうか」という進捗確認を行い、クオリティを判断します。
それは必ずしも数値化できるものではありませんが、プロジェクトマネージャーの感覚として「何%くらいクリアできているか」は1つのモノサシになるかもしれません。
簡単に言えば、「このままのペースで進めたら要件を満たせないかもしれない」となれば、それはマイナスのリスクです。残業をする・メンバーを増やす・納期を延ばす交渉をする・スコープを狭める交渉をする…などの何らかのテコ入れが必要になりますね。
QDCのC:コスト
2つ目が、QCDのC、コスト/お金ですね。
余談ですが、工数積算の流れを書いておきます。
- プロジェクトに必要な作業と経費を洗い出す
- 工数を積算して単価をかける
- トラブル発生のバッファを乗せる
- 営業利益を乗せる
- それが全体予算となる
多くのプロジェクトにおいて、「無限にお金があって、終わってから実費精算」ということはあり得ません。あくまでも見積もった予算が基準であり、見積もった予算で発注をいただくことになります。
コストを担保するためには、第一に全体予算を把握することが重要です。クオリティと同じ文脈ですね。
平たく言えば、「お財布にいくら入ってるか」を常に意識しろ、ということです。
便利なツールの1つに、「トレンドチャート」というものがあります。
作業の進捗状況と予算の消費状況を関連付けて折れ線で示したもの
参考:https://qiita.com/lymansouka2017/items/e3712f26601ac3989bcc
この表ではコストとデリバリーしか表現されていないので、「少ないコストで多くのアウトプットが出た場合」などは表現できないですが、コストのイメージを掴むには便利です。
簡単に言えば、「このままのペースで進めたらお財布が足りないかもしれない」となれば、それはマイナスのリスクです。利益が少なくなることを社内的に許容するのかを確認したり、場合によっては追加見積の打診を検討しましょう。ちなみに、リスクに対して具体的な対処をせず静観・あるいは単にウォッチを続けることを、PMBOKの専門用語で「受容」と言います。
他の記事で何度か言っていますが、PMのミッションは「お客様に迷惑をかけないこと」です。適切な理由なく「足りなくなったのでお金ちょうだい」は通用しません。
途中で足りなくならないように、あらかじめお財布を充実させておく(適切な見積もりをする)ことも重要ですね。
QDCのD:デリバリー
3つ目が、QCDのD、デリバリー/納期ですね。
クオリティ・コストと同じ文脈で、納期を担保するためには、第一にマスタースケジュールを把握することが重要です。
- 要件を理解する
- マイルストーンを置く
- マイルストーン:要件達成のために不可欠ないくつかの中間目標。
- マイルストーンを達成するためのタスクに落とし込む
- タスクのリードタイムをスケジュールに引く
- 完成されたマスタースケジュールを見る
日々の進捗確認では、「細かなタスクの予定通り/遅延」をウォッチするとともに、「マイルストーンに対しての予定通り/遅延」も意識する必要があります。これは、メンバーではなくPMが意識する部分になります。
簡単に言えば、「このままのペースで進めたら納期に間に合わないかもしれない」となれば、それはマイナスのリスクです。品質の場合と同じく、残業をする・メンバーを増やす・納期を延ばす交渉をする・スコープを狭める交渉をする…などの何らかのテコ入れが必要になりますね。
全ての基礎になる要件:スコープ
4つ目が、スコープです。
スコープとは、「範囲」という意味で、つまりはクオリティのところで説明した、要件のことを指しています。
要件とは、お客様と合意する(握る)ものになります。「この範囲を担当するという前提で、このコスト・納期になる」という見積が作成されることになります。
ちなみに、「見積書」という資料の中にダラダラと「やること」を書くわけはなくて、別の資料が作成されます。それが「要件定義書」です。
簡単に言えば、スコープが定まっていない・「やること」に関する認識がズレている状態が、マイナスのリスクです。プロジェクトを進めるごとに要望が飛んできて要件が増えてしまっては、QCDの計画が完全に狂ってしまいます。
QCDの観点でリスク管理をする大前提として、スコープを定め、お客様と認識を合わせておくことが非常に重要になります。これが簡単にいかないプロジェクトも多いので難しいのですが…
要件定義がリスク管理の礎となる
いかがでしたでしょうか。おさらいです。
- クオリティ:「このままのペースで進めたら要件を満たせないかもしれない」
- コスト:「このままのペースで進めたらお財布が足りないかもしれない」
- 納期:「このままのペースで進めたら納期に間に合わないかもしれない」
- スコープ:スコープが定まっていない・「やること」に関する認識がズレている状態
繰り返しですが、リスク管理において、要件定義/スコープの策定がめちゃくちゃ重要です。
要件定義/スコープの策定は正直に言ってめんどくさいし難しいです。なぜなら、まだ何も始まっていない状態で机上の空論をすることになるからです。お客様もPJメンバーもなかなか具体的なイメージをもって議論をすることができません。
しかしながら、スコープの認識がズレた状態で”なんとなく”でプロジェクトをスタートさせてしまうと、始まってからマイナスのリスクが100%発生します。スコープはQCD全ての前提になっているので当然ですね。
要件定義/スコープの策定は慎重にやりましょう。つまり「要件定義」自体に潤沢な工数と資金を投入する必要があるということですね。
プロジェクトマネジメントは先は長いのです…( ˘ω˘)スヤァ
それでは。
チャイフ
コメントを残す