HOW TO TD(User Engagement)Treasure Data User Engagement

プロジェクトマネジメント実践(3)

ホーム » プロジェクトマネジメント実践(3)

こんにちは、カスタマーコンサルティングチームの小谷 将来です。

前回、私の経験則から、プロジェクト失敗における根本的な原因について、主な3つの要因である「品質の未定義」「プロジェクトにおける組織の役割不明確」「小さいリスクの放置」についてをお話しさせていただきました。今回は、プロジェクトを失敗させないために、問題への対処方法について、お伝えさせていただきます。

プロジェクトで起きる問題の分類

まず、問題とは何を指すか、から整理します。問題は大きく3つに分類ができます。

問題分類 発現状況 想定可能な事象
課題 顕在化
リスク(既知の未知) 潜在化 想定可能
リスク(未知の未知) 潜在化 想定不可能

上記の分類によって対処が異なりますので、こちらを順に対処方法をいくつかご紹介させていただければと思います。

「課題」への対処方法

課題とは、計画していたコスト・スケジュール・品質等のベースラインに対し、何らかの事象が発生したことで、達成することができない障害を指します。プロジェクトマネジメントあるいはチームリードを経験している方は、課題をリスト化することを日常的に実施していると思いますので、リスト化の必要性についてはここで語ることはせず、リストで管理すべき重要な項目について述べさせていただきます。

課題マネジメントの問題
プロジェクトを進める中で課題の発生は避けれません。むしろ課題を探し、解決していくことがプロジェクトマネジメントにおけるメインタスクであると思います。しかしながら、プロジェクトを進めるにつれ、課題は山積し、全体像の把握や適切な対処が十分に出来なくなることがよくあります。定期的な進捗確認会などでは、今誰が課題のボールを持っているかを確認し、その場に本人がおらず持ち帰る。次週の進捗確認会では、さらに追加の課題が発生しており、課題の全てを確認するようなことは出来ず、お互いに気になることベースで話を進めてしまい、課題マネジメントが困難になる…。そのような光景を何度か見たことがあります。

課題オーナーの設定
上記の問題は何でしょうか。第一に課題オーナーが設定されていないことが挙げられると考えます。課題において5W1Hの議論は言うまでもなく、担当者が設定されることは通常です。ただ、課題は重要な事柄や複数の問題が絡むことから担当者が複数人に設定されることがあり、責任の所在が不明確になることがあります。加えて、担当者になった人が単なる窓口だけの存在となり、関係者の前を右往左往し、解決に時間がかかるということがあります。

課題オーナーとは課題に対し中心的な役割を担うことはもちろんのこと、個々の課題に対する責任を持たせます。そのとき責任だけでなく、必要であれば、PMから個々の課題に対する権限も移譲することが重要です。課題は周辺の協力を得て解決をすることが多いですが、一担当者だとどこまで協力を求めて良いのか判断に迷うことがあります。PMは各課題オーナーに対し、課題解決のための必要な権限を確認・移譲し、課題解決に向けたPM代行者として関係者への協力を得ること状態を作るのが、ポイントかと思います。

課題解消条件の明確化
また、課題の長期化もマネジメント上の問題として、よくあります。この原因として多いのが、課題の解消条件、すなわちGOALが不明確のため、いつまでも関係者間でのやり取りがなされ、課題が一向に完了しないことがあります。

このとき求められるのは課題を解消するための条件を詳細かつ具体的に設定することが重要です。よくある事例として、「〜を検討する」「〜を対応する」といった課題解消条件を記載するパターンがありますが、検討、対応は曖昧な文言であり、明確なアウトプット、および行為が無いとGOALがよくわからず、いつまでも残り続けることがあります。誰でもわかるような解消条件を設定することが、課題マネジメントをスムーズに行えるコツと言えます。

リスク(既知の未知)の対処方法

リスクは課題とは異なりまだ発生しておらず、発生するかどうかも不確実なイベントのことを指します。PMBOK(Project Management Body of Knowledge)上ではプラス要素も好機のリスクとして捉えますが、ここではマイナスのリスク、すなわち脅威について論じたいと思います。また、リスクには「既知の未知」、と「未知の未知」があるとされてます。「既知の未知」は、過去の経験やデータ収集・分析等で内容が想定可能なリスクを言います。想定リスクへの内容への対応策を。

日本のプロジェクトはリスクマネジメントが苦手
日本のプロジェクトでは総じて、リスクマネジメントは軽視されがちの傾向にあると言われています。上位層において、まだ発生していないことにコストは掛けられない、と判断することが多いようです。優先順位として、まず目の前の課題に対処することは必要でありますが、リスクが課題として発現した際、取り返しのつかない課題であるため、プロジェクトが中止になるような事態に陥ることもあります。

それらを避けるためにも、リスクを予め特定することがPMに求められます。リスクの特定手法はいくつかありますが、最も簡単で効果的なものは過去のプロジェクト経験にもとづく、チェックリスト化です。とはいえ、プロジェクトは固有のものであり、必ずしも全てに当てはまるようなことはないので、リスクを特定するための自社の共有財産として作成・更新し、全社的に共有することが望ましいです。

リスクを繰り返し、特定、評価するサイクルをPJ内で構築
実際にプロジェクトが始まるとリスク管理は後手に回ることがあります。先ほど述べた通り、実害がないため、足許課題を優先することがほとんどです。プロジェクトを進める上では決して間違いではないと思いますが、重要なのはリスクを見て見ぬフリをしないことです。そのためにもPJルールとして、リスク管理表等を作成し、月単位で管理表をアップデート、ならびに第三者等(内部組織含む)を含めた評価をすることが必要であると思います。

また、評価方法は予め体系的に定めておき、リスクに対する優先順位づけをすることで、リスク対応をすべき対象の選定をすることがあります。よく使われる技法として、発生確率と影響度をマトリクス上にして、リスクのスコアリングをする方法です。

リスク評価に応じた対応戦略を決定
評価によって、リスク対応が必要であるとした場合、PJにおいて対応戦略を決定します。このときの対応はPMBOK上では以下の5つに分類されています。

  • エスカレーション:PM権限を超えており、上位層にオーナーシップを移転
  • 回避:スケジュール延期、資金調達等によるリスクの完全除外
  • 転嫁:第三者にオーナーシップを移転(主に保険、保証等)
  • 軽減:追加テスト実施やベテラン人材の配置等、リスク発生確率を減少
  • 受容:リスクを認めた上で、発現まで対応なし

対応はリスクの内容によって様々ですが、リスクの軽減策を講じた上で、受容し、リスクマネジメントのチームが定期的にリスクのレビューをすることが基本的な対応策になるかと思います。

リスク(未知の未知)の対処方法

最後にリスクの「未知の未知」、すなわち何が起きるのかはわからないため、具体的な対処が検討できない事象についてです。

基本的に予算を積む以外の対処方法はない
何が起きるのか分からないがため、対応策を検討することは出来ず、基本的にリスクバッファ費用(PMBOKではマネジメント予備費)を積むことしか対処の方法がありません。しかしながら、「未知の未知」を如何に「既知の未知」に変えることが出来るのかがリスクマネジメント上、ポイントになってきます。

コスト見積りにおける上位層の理解が重要
予算を積むしか無い以上、コスト見積りを上位層に承認を得る必要がありますが、実態として、なかなか厳しいと思います。しかしながら、プロジェクトマネジメントの観点から見ると、そこも含めて上限内にハマらないのであれば、そもそものスコープを減らすか、一定のリスクを許容することを、PMから上位層に理解させることが重要です。

まとめ

問題解決において、課題への対処は重要な事柄ではありますが、社会のデジタル変革への意識向上やコロナによる外部環境の変化により、想定外の事象への対処が一層求められてきています。そのため、相対的にリスク管理が非常に重要になってきており、「不確実性」が増してきている社会への適応が必要と感じております。

次回以降は、変革が求められる現状において、旧態然としたプロジェクトマネジメントの変化をお話しできればと思います。

小谷 将来

Customer Consultingチーム

2006年よりNTTデータ系列の都市銀行の金融システム開発SEに従事。要件定義から開発、運用まで、一貫したSI開発を経験。経営層へのビジネス参画を若くして経験したく、2012年にアクセンチュアに転職し、銀行業界向けのITコンサルティングに6年半携わる。大規模プロジェクトのマネジメント支援を中心に、IT戦略立案、業務プロセス改善、AWSをベースとした情報系システム構築、BIベンダー選定等、様々なコンサルティング業務を経験。その後デジタルの最前線を肌で感じるため、2020年にトレジャーデータに参画し、カスタマーコンサルティングチームにて、Treasure Data CDP活用のためのコンサルティングを担当。現在は、大手製造メーカーへの新規プロジェクトのPM支援、および大手自動車メーカーへのCDP導入支援に従事。

得意領域 : プロジェクトマネジメント、コンサルティング、システム統合プロジェクト推進、銀行業界知識、DX

Back to top button