「プロジェクトの影に潜む火種をどう見つける？」リスク管理の本質と実践方法
プロジェクトを進めるものに付きまとうものはなんでしょう？と問われたら皆さんはどう答えますか？私は真っ先に「リスクです」と答えますｗ
PMBOKでは、リスクとは「プロジェクトの目標にプラスやマイナスの影響を与える不確実な事象」と定義されています。
プロジェクトには常に不確実性がつきまとい、リスクは発生し得るものです。そして、悲しいかな私たちは未来を予測できないので、リスクを完全につぶすことはできません。ただ、リスクが大きくなる前の「火種」として早期に見つけ、適切に対応することで、被害を軽減することは十分に可能です。本記事では、「火種を見つけること」に焦点を当て、リスク管理のポイントについて普段考えていることを書いておこうと思います。
リスクは避けられないからこそ、早期発見が鍵
プロジェクトには大小さまざまなリスクが付きまとい、それらを完全に防ぐことは難しいものです。例えば、外部のパッケージを導入するにあたり、仕様を見る限りではバッチリ。でも、いざ進めてみたらエラーコードが続出して進まない。このようなリスクを避けるのは困難ですが、「火種」を早期に見つけておくことで、大きな問題に発展する前に手を打つことができます。
この火種となるリスクを「いかに早期に見つけるか」がリスク管理の要であり、プロジェクトの成否を左右する重要なポイントです。リスク管理とは、発生をゼロにするのではなく、リスクが現実化する際の影響を抑えるための準備なのです。
リスクの火種を見つけるための方法
では、どうやってそのリスクの火種を見つけるか。まったく0にすることができない以上、どうにか０に近づけるためにどうすればいいかでしかないのですが、私の見解としては有識者に「当てまくる」です。私が問題が顕在する前の状態は、ある人の考えの中では成立していた=ゆえに誰かに助けを求めることをしなかったということは非常に多いです。つまり、自分の中では成功するイメージでいたということです。かく言う私もこの状態になっていることはままあります。
観察力と日常の対話で兆候をキャッチする
火種を早期に見つけるためには、日々の観察とコミュニケーションが不可欠です。プロジェクトが進行する中で、小さな違和感やズレに気づく力が求められます。例えば、メンバーが抱えている不安や懸念を聞き出し、プロジェクトの進捗やスケジュールに影響を及ぼす可能性がある問題を把握することが重要です。
また、プロジェクト内でのオープンな対話も大切です。メンバーが率直に意見を述べられる環境を作ることで、隠れたリスクが浮上しやすくなります。例えば、定期的なミーティングや1on1などを行うときに「リスクありますか？」と聞くと、聞かれた相手もあったかなとなってしまいます。なので、その人が一番関心ごとが強そうなことを質問したりします。仕組みに強い人であれば、仕様についてのやり取りがエンジニアとどうなってるか、コミュニケーションが得意な人であれば、誰かの状況について聞いてみたり。人は往々にして得意なところの解像度は高いものです。そのため、得意なところを聞くと、その人だけが見えているアラや課題感があるので、そこから深堀をしていき自分もその思考をインプットするわけです。
定量的なものからパターンを見つける
火種を見つけるもう一つの手段として、データの活用があります。上記が割と定性的なやり方だとしたらこれは定量的なやり方です。過去のプロジェクトで起きたトラブルの記録や不具合の発生パターンを見出すことでリスクを予測することが可能です。
例えば、進捗が急に遅れ出したり、タスクの完了が遅延する傾向が見られる場合には、何かしらのリスクが潜んでいる可能性があります。こうしたデータをもとに、通常と異なる動きを見つけた際には火種の兆候として対策を検討します。タスクをチケット管理しているならば、解決するまでの時間や1日あたりどれくらい解消をしているかなどを見るのもいいでしょう。これは私の経験を含むのですが、期日から遅れる時は、その遅れた分でクオリティーを担保していることはほぼないような気はしています。何もほぼ進んでないから遅れるという状況に近いです。
火種を見つけた後の対応
問題が大きくなる前に「小さな修正」を
火種が見つかったら、問題が深刻化する前に小さな修正を施し、リスクの影響を抑えることが重要です。少しでも違和感を覚えたらディープダイブしましょう。正直なところ、これをやりすぎると周りからはあまりいい顔をされないことがありますが、そこは心を鬼にして行いましょう。
火種はよくよく考えみたら、杞憂に終わることも少なくないですが、小さな対応を積み重ねることで、火種が拡大し、大きな問題に発展するリスクを抑えることができます。場合によっては、事前に準備していた対応策の一部を試しに導入することで、火種の拡大を防ぐことができます。少し暇をしてるかなと思った時には、大体その数週間後に大きな問題が出てくるので、走り続けるのが肝要です。
ステークホルダーの期待値調整をする
ここまで書いておいてなんですが、極論リスクというのは相対的なことであることが多いです。例えば、スケジュールが遅れることはもちろんいいことではないですが、遅れても何か損害が出ることは少なく、むしろ中途半端な状態で出してユーザーにマイナスの印象を与えるほうがリスクだったりもするわけです。そして、それを誰が判断するかと言えば、事業長であったり、クライアントだったりするわけです。こうした中で、リスクが発生した際に、どのような対応が「最もプロジェクトにとって有益か」を判断するのは、最終的にはステークホルダーとの期待値調整にかかっています。PMとしては、リスクの影響度を多角的に分析し、ステークホルダーが納得できる形で情報を提供することが求められます。具体的には、スケジュールが遅延することで発生するリスクと、そのリスクを回避するためのリリース延期や追加リソース投入の利点・欠点を明確に提示し、外部ステークホルダーが意見を持ちやすくすることが重要です。
まとめ
あらためてですが、リスクを完全予想するのは難しいです。ですので、リスクを発見する確度を1%でも上げる。そのために自分の頭だけどうにかしようとし過ぎずに、他人の視点を借りることを前提にオープンコミュニケーションを取る。もし、違和感らしきものを覚えたら、徹底的に自分が納得するまで「なぜ、そうなっているのか」「何が起こりうるのか」を突き詰める。ということかなと思います。私もまだまだ未熟ではありますが精進していきたいところですね。
なお、今回は割と実体験に基づいて書きましたが、PMBOKでもリスクマネジメントとして書かれているくらいに重要なのことですので、体系的に学びたい方はぜひそちらも調べてみてください。