プロジェクトに潜む不確実な要因を見抜き、
正しい道筋へ導く「リスク審査」

いずれ生じるであろうリスクを
「マネージャの目」で予測する

NTTデータアイでは、システム開発のプロジェクトにおいて「リスク審査」という工程を設けています。システム開発では、計画「QCD（品質、価格、納期）」を守り開発を進めることが重要であり、このQCDを阻害する主たるものをリスクと見ています。リスク対策を怠ると、「品質（システムの完成度）不良、コスト超過、サービス開始遅延」という事態を招く恐れが高まります。つまり、いかにリスクに対応できるかがプロジェクトの成否を左右する大きな要因になるわけです。

ではリスクには、どのようなものがあるのでしょうか。例えば、計画段階。新規のお客様や経験のない分野での新規システム開発の場合、「業種、業態に対する知見やノウハウを持った人員が足りない」ために、「充分な体制を取ることが難しい」場合もあります。

プロジェクトには、さまざまな不確実な要因が潜んでいるものです。そして、不確実な要因が多いとリスクも高まります。この問題を放置して開発を進めると想定していない事態が次々と起こり、開発着手前に作った計画に沿って進めることが困難になってしまうことも。

このような可能性を取り除くには、知見を持ったプロジェクトマネージャ（PM）経験者によるリスク審査が効果的なのです。「現状を確認しこの先、計画に支障が出ないか」と不確実な要因を先回りして指摘、アドバイスをしながら改善を促すことが「リスク審査」という仕事です。もちろん、その後の経過もフォローして、リスクが取り除けたか、またリスクに変化が生じていないかを確認しつつ、新たなリスクが確認されれば改めて指摘します。そのようにしてプロジェクトにとって望ましい状況を増大し、望ましくない影響を防止、低減しようとしているのです。

NTTデータアイがリスク審査を設けるようになったのは、15年前にさかのぼります。当時、さまざまな業界でデジタル化を求める機運、今までにない斬新なサービスを求める風潮が強くなりました。当然、未知のプロジェクトに挑戦すればリスクも高まります。

そこで第三者的な観点からリスクをチェックする「リスク審査」を設けたのです。もちろん、各プロジェクトにはPMという責任者がいて、リスクにも目を配っています。しかしPMは、開発チームと常に一緒に行動する立場にあります。そのため「今のメンバーで頑張れば、なんとか乗り切れる」と無理をしがちです。そのようなときに、客観的な立場からリスクを指摘し、改善を促すアドバイザーがいれば、「大火事」になる前に対処し、「ボヤのうちに消火する」ことが可能になるのです。

プロジェクトの外側からPDCAを回して、
リスクを低減する

リスク審査はどのような形でプロジェクトに関わるのでしょうか。基本的に各プロジェクトはPMを中心に進められますが、リスク審査人は客観的な立場で関わります。状況をチェックし、必要に応じてアドバイスやアクションプランを発出するなどし、プロジェクトを正しい方向に進むよう促します。

PDCAを回しながらプロジェクトを推進しているPMの、ひとつ外側で大きなPDCAを回しているのがリスク審査だと考えると、この仕事の位置づけがわかりやすいと思います。プロジェクトの進む道に隠されている地雷を踏まないような安全なルートへと導き、プロジェクトを完遂までサポートする仕事といえます。

といっても常に関わるわけではなく、リスク審査人は節目節目にプロジェクトに関与します。NTTデータアイでは、開発の節目に会議の場を設けてプロジェクト状況やリスク状況について審査しています。またプロジェクトチームは、月ごとに「重要案件報告」という資料を提出したり、幹部に状況を報告する場を設けたりしています。そのようなタイミングでリスク審査人が関わります。

プロジェクトの特徴から
網羅的にリスクを洗い出す

プロジェクトの進行段階によってリスクの着目点も変わります。主に、「受注／開発着手前、設計完了、製造完了、結合試験完了、サービス開始前」などにリスク審査を行いますが、特に重要視しているのは計画の実行精度を確認する「受注／開発着手前」になります。

その段階でのリスク審査のポイントは、網羅的にリスクを洗い出せているかを確認すること。通常、洗い出しというと「リスクや課題を探す」というイメージを持つと思いますが、NTTデータアイではその前の段階、「プロジェクトの特徴の抽出」からスタートします。

リスクの洗い出しの大まかな流れとして、例えば、冒頭に紹介した、新規のお客様や経験のない分野での新規システム開発であることも特徴といえます。また、ソースコードが10万行の案件と50万行の案件では、5倍の違いと思うかもしれませんが、開発の規模感はそれ以上に大きな違いがあり、初めて50万行の案件に取り組むPMにとっては未知の経験となるでしょう。こうしたプロジェクトごとの特徴を大きなものから小さなものまで、網羅的に洗い出していきます。

次の段階では、明らかになった特徴から起こりうる「現象」を想定します。ここで起こりうる現象の内容を見ることで、プロジェクトが抱えているリスクや課題が明確になるのです。

その上で、その現象を引き起こす「原因」を推定し、「原因への対策」を検討します。対策の方向性を決め、それをもとに実施すべき対策を具体化し、プロジェクト計画に反映させていきます。

リスクの洗い出しや対策の検討に関する実際の作業はPMを中心としたプロジェクトメンバーが実施します。リスク審査ではそのような流れを踏んで網羅性を持ってリスクが洗い出せているか、また洗い出したリスクや対策が妥当なものであるかなどを確認することになります。

また、リスク審査から生まれた知見を具現化したものに「プロジェクトコンピタンスチェックシート」があります。これは、開発着手段階からサービス開始前までを範囲に、プロジェクトの計画や実行力を確認するもので、開発着手段階ではプロジェクトで作成した計画が充分なものになっているかを確認する手段として活用を想定しています。この中にリスクに関する項目も200ほど用意されています。

このシートは現在試行段階ではありますが、PMが項目を埋めていくことで自然にプロジェクトの特徴やリスクの洗い出しが充分であるかを確認することができるようになっています。

このような体制でリスク審査を行うことは、PMにとっても「この方針で進めて間違いない」という安心感を生むと感じています。やはりプロジェクトの全責任を負う人は心理的な負担が強いので、客観的な立場にあるリスク審査人から「認識が一致している」という確認がもらえたら、確信を持ってプロジェクトを率いることができるでしょう。

クライアントであるお客様には「リスク審査をしている」とアピールしているわけではありませんが、「会社組織としてプロジェクトを正しい方向に導く仕組みを持っている」ということから、「NTTデータアイに任せて安心」と感じてもらえるところに寄与しているのではないでしょうか。

リスク審査に求められるスキルを、
次のリーダーに学ばせるには

リスク審査は誰にでもできる仕事ではありません。私はこれまでの経験から、PMに必要な資質やスキルを次のように考えています。

リスク審査では「リスクや課題を見つけて対応し、ちゃんと直っていることを確認して開発を進める」というPDCAを繰り返しますが、これはまさにマネージャの基本的な動作。つまり、いろいろな種類のプロジェクトを経験したPMが、リスク審査に向いていると言えます。

プロジェクトの成否の多くは計画段階にかかっているので、開発着手前はPDCAの「P」が重視されます。

一方着手後は「PDCAを機能させていく」ことが重要で、特にPDCAの「C」に当たる「事実に基づいた正確な状況認識」がポイントになります。例えば、プロジェクトの進捗が遅れながらも、なんとか期日までに終わり、「大変だったけれども、みんなの努力で乗り切った」と満足しているとします。

ところが、それは正確な状況認識とはいえません。リスク審査の視点から見ると、前提として「進捗が遅れた結果、完成したシステムの品質が落ちている」「もし遅れが生じる前に対策を打てたら、品質を落とさずに済んだ」と考える必要があるからです。このような客観的な事実に基づいて分析できる能力がリスク審査には欠かせません。

NTTデータアイでは、長年、リスク審査というプロセスを開発プロジェクトの中に組み込んできた結果、問題を早めに認識してしかるべき対策が打てるようになっており、実際ここ数年は問題も起こりにくくなっています。

リスク審査の直接の目的は、その案件を「問題プロジェクトにさせない」ことにあります。問題が起こった場合、お客様の要求に応えられなくなる可能性が生じるからです。また会社の利益を消失させることにもなりかねません。それにプロジェクトに関わる社員に無理を強いることになるので、精神的にも健康面でも悪影響を及ぼすかもしれません。

リスクを先読みして問題発生を避けられたということは、プロジェクトを円滑に完了できたということでもあります。つまり、関わった社員が成功体験を積めたということ。その経験は社員にとって大きな成長につながるでしょうし、会社にとっても社員の成長は財産です。これもリスク審査に携わらせていただいているものの醍醐味ですね。