見積もりのリスクはプロジェクトをやるためにコントロールするんだよ

レビューアから相談を受けるのです。

「スコープに曖昧なところがある見積もりをどうしたらいいですか。」
「当事者を集めて、“見積もれるように”スコープを仮でもいいから決めてきたら？」

数日後にまた、レビューアから相談を受けました。

「レビューは承認したのですが、心配があるのです。これこれでよかったのでしょうか。」
「そのままではコレがアレなのでダメ。」
「でも、しょうがないんです。」
「レビューアの貴方が同意したなら貴方も共同正犯ですヨ。ウォッチしてトラぶりそうになったらプロジェクトの支援するつもりなんだよね？」
「いえ、支援出来る余裕は……。」
「“貴方が”支援するんだよね？」

「それ、いつから？」
「○月からです。」
「幸いにも少し余裕があるから、担当マネージャへその○についてdue dateを申し渡してきたら？まめにトレースしてね。」
「わかりました……(ホッ)。」

本来であれば、レビューイが案件に手にれるだけの情報を持って“相談”に来てほしい案件でした。でも、どうやらレビューイにはその案件についてのリスクの識別ができなかったようです。capabilityのある組織であれば、その組織としての能力の蓄積であるナレッジをベースに自らリスクを識別しなければなりません。でも、そのレビューイの組織はまだ発展途上のようです。

ならば、レビューアが案件ごとのリスクを識別して必要な措置をさせなければ、レビューイがいくらやりたくてもストップさせなくてはなりません。それがレビューアの仕事です。気を付けなければならないことは、レビューアは“ストップさせることが仕事ではなく、やりたいことをできるようにリスクを制御させる”ように導かなければなりません。

レビューアはレビューで何をすればよかったのか
たった2つです。

リスクを識別させ、レビューイに認識させること

リスクを低減する方法を考えさせ、due dateまでに対応させること

なぜ、レビューアはレビューのタイミングでリスクの識別をしないといけないのか。それは、その場が一番レビューイが真面目に考えるからです。レビューイはレビューの直前まで、一杯いっぱいで案件の検討をしているものです。

夏休みの宿題が夏休みの終わりに集中するように。

いくら、その案件についてレビューイがセルフレビューをしてきたとしても、そんな時間的に余裕がなければ、いったいどれだけ第三者としてその案件を冷静な思考で眺められるかといえば、まぁ、無理でしょう。相応の時間がなければ考えることはできません。

そうすると、レビューが砦になるわけだし、第三者がいる場で、のレビューですからレビューイ自身身構えて臨むものです。そういう場面で、レビューアはきちんとリスクを

“恰も、自分がその案件のプロジェクトマネージャになるのだと思って”

レビューをすればいいのです。レビューアほど、腹を括らないといけない商売(＝ロール)はないんです。自分がその案件のプロジェクトマネージャだったら、と考えれば、その案件を少しでも安全な方に振りたいものです。だから、案件を安全な方に振るためにはレビューアが自分のことだと思ってその案件をみて“リスクを識別”しないといけないんです。

自分がキャリーするプロジェクトのプロジェクトマネージャとして見ないといけないのは、もう一つ理由があります。ビジネスですから、誰でも案件は欲しいものです。遊んでいるより仕事をして経験値を上げたいんです。つまり、案件を取りたい。でも、リスクがある。そのギャップをどうするか。前の“自分がキャリーする案件だと思って”にヒントがあります。

自分がプロジェクトマネージャとしてキャリーする。
リスクを識別する。
リスクはコントロールするもの。
案件はやりたい。

だから、リスクの対策を“その案件の実行までに対応させる”んです。で、それをきっちりトレースして詰めていくのがレビューアの仕事です。