オンラインジャーナル/PMプロの知恵コーナー

　向後　忠明 (コウゴ　タダアキ)

向後忠明
1968年より日揮(株)にて20年各種プロジェクトに従事
1988年よりNTTインターナショナル(株)に出向しその後移籍
ここで電気通信関係JICA調査団団長、トルコ、対中央銀行のシステム開発
インドネシアおよびスリランカのNTT投資の電気通信会社役員
その後NTTコム、NTTリース(NTTファイナンス)にてシステム開発やPMアドバイザー
2009年より日本セルロース(株) 技術顧問
団体役員：PMAJ理事、IPA　PM委員

先号　　　次号

ゼネラルなプロ (146) （リスクマネジメントと失敗の構図）

向後　忠明　[プロフィール]　：12月号

　「日経コンピュータ」によると情報システム部門でのプロジェクトにかかわる2018年調査の報告記事に『半数が失敗」』と見出しを付け、成功率52.8％、失敗率47.2％という結果を報じています。確かに「半数が失敗」なのだが「半数が成功」とも言える。2018年の回答者の6割は情報システム部門であり、2003年と2008年の回答者とほぼ同じ集団だと強引に見なせば、2003年の26.7％、2008年の31.1％、2018年の52.8％という結果から、成功率は上昇していると言ってよいだろう。
　上記は主に情報システムに関するプロジェクトの成功率の話であるが、一方プロジェクトマネジメントに習熟したエンジニアリング系では情報処理系より高い値の成功率となっている。

　そこの違いは情報システム関連のプロジェクトは要件を曖昧にしたままプロジェクトを進めてしまうと、経営者や利用者が真に求めていたシステムができあがらず、品質ないし満足度が下がる。プロジェクトの途中で要件に問題があると気付いた場合、要件定義をやり直し、仕様を変更したりするため、スケジュールが遅れる。修正後の要件に基づいて追加開発をすればコストがかさむことになる。
　本件についてはすでにゼネラルなプロ（136）から（143）での課題解決のところで話してきましたが、ロジカル手順とその後の処理に不慣れで適切な対応ができなかったことにも原因があると思います。
　しかし、昨今のエンジニアリング及び建設系のインフラ及び社会関連プロジェクトにおいても要件が曖昧なケースが出てきているようです。
　プロジェクトの失敗の原因にはいろいろあるが、失敗の原因として下図のようなことが言われている。（畑中正太郎の失敗学、ナツメ社出版の書籍より）

（1）未知
これまで経験したことのない以下のようなプロジェクトへの対応不足
1. ① 全く経験のない技術革新を要求されるプロジェクト
2. ② 現状からの脱皮、多様性への対応が必要なプロジェクト
3. ③ 新規技術による既存業務のイノベーションを求めるプロジェクト
（2）無知
上記に示すようなプロジェクトへの対応や手順や立ち上げ時の手抜き（GAP分析によるリスク分析不足）
（3）不注意

要件内容の確認などの立ち上げ時の手抜き（情報分析、リスク分析不足）
外部環境及び自社の環境（技術、各種リソース、体制等々）を考えない計画とその実行
リスクへの対応不足（契約条件の未確認と詰めの甘さ）
情報収集不足または過信による対応（入札者や競合相手に関する情報）

（4）手順の不注意
経験からの過信による独断専行及び手順やルール無視の行動
ISO 9001規格（品質マネージメント）に従った不適合・是正処置手順無視の行動
（5）誤判断

要件への初期判断のミス
立ち上げ時の手抜き（情報分析とリスク対応不足）

（6）調査検討の不足

立ち上げ時の手抜き（GAP及びリスク分析不足）

（7）制約条件の変化

不可能かつ意味不明の要求により作業の停滞
コミュニケーションと交渉能力の欠如

（8）企画不良
状況の的確な把握なしの立ち上げ時の各種分析の不手際
（9）価値観不良
これまでの経験や知識でプロジェクト遂行が十分可能と判断したが実作業に入ったら食い違いがわかり失敗（立ち上げ時の検討と判断ミス、過信によるPJ推進）
（10）組織運営不良

提案時に起きた重要事項（競争入札や交渉時での異事事項発生時のPMの独断専行）
プロジェクト要件の分析の欠如とそれに対応する組織体制のミスマッチ

　以上の事例から見て、失敗の原因はほとんど立ち上げ時での検討不足とプロジェクト遂行中での異時事項発生時の検討不足によるものが多いようです。
　この失敗の原因を見ても、契約前であろうが後であろうがプロジェクトをスタートする時には過去の教訓を最大限に活かし、想定されるリスクは出来うる限り列挙し、その対応策をとっておく必要があることがわかります。

　また、問題・課題が予兆された時または、発見された時は、早めに、隠さず顕在化させることが重要です。隠しても必ず顕在化し、後になればなるほど対応が難しくなり、そして失敗の構図を作ることになります。このように隠しても、必ず顕在化し、後になればなるほど対応が難しくなりそして失敗の構図を作ることになります。

　以上が失敗の原因ですがここに示す項目は主にプロジェクトマネジメント面からのことですが、今の技術革新、産業構造の変化等により、ビジネスの基本構造が変わりつつある中、企業経営においても同じことが言えます。

　このように企業経営においてもプロジェクトにおいても多くの各種の潜在的なリスクが内在し、いわゆる失敗の原因となる各種の地雷原があります。地雷を踏まないためには、まずは近場の地雷を発見するための地雷探知器のようなツール（個人の経験と知識・技法）、そして、先々の地雷の位置を推察し人々を安全な方向に導く地雷除去経験とその知識を持った人によるマネジメントが必要となります。
　この人材がプロジェクトマネジャや組織の長であり、地雷を計画的に処理していくマネジメントをリスクマネジメントと言います。
　このリスクマネジメントに従事するプロマネを含め組織の長は各種の多くのプロジェクトや関連業務を実践し、そこで遭遇した問題やその処置結果を整理し、問題解決を図り、そのリスク対応策を取り、問題に対処できる“転ばぬ先の杖”を持っている人であることが必要です。しかし、“杖”を持っているだけでは不十分であり、この“杖”をどのように最も効率の良い手順で利用し、問題を解決しながら仕事を進めていくといった工夫が必要となります。
　それではリスク事象はどのような段階で大きくなるか次ページ図（プロジェクトライフサイクル）から見てみることにします。
　この図からも分かるように初期時点すなわちリスク事象の多い期間にリスク除去の手段を取っていればそれだけプロジェクトの成功率は上昇することとなり、プロジェクト各段階での対応がスケジュールおよびコスト面においてもプロジェクトの終盤において大きな差異が出てくることは明らかであることがわかります。
　特に曖昧な課題を含むようなプロジェクトすなわち概念設計（不確定要件を含む課題解決にかかわる作業と要件の確認にかかわる作業）から始まるようなプロジェクトは特に慎重な状況調査と十分な検証を行うことが必要でしょう。

　以下の図にプロジェクトライフサイクルとリスクについて示しますがリスクとはこれから遂行しようとするプロジェクトや業務の目標に対して影響を与える事象であり、それによって引き起こされる結果であり、その影響度によりリスクの大、小が決まる。

　そして、リスクの性格や内容はプロジェクトのライフサイクルの各段階でのリスク事象への対処によってそのインパクト（リスク発生による損害額）は異なってくる。

　今月は以上で続きは来月号とします。