はじめに
昔の話ですが、とあるプロジェクトの終盤、PMから次のようなことを言われた経験があります。
「有給を取って、工数ゼロでこの作業を対応してほしい」
当然ながら、この依頼は断りました。理由は感情論ではなく、リスク管理・プロジェクト管理の観点から明確に「不適切」だったからです。
当時の背景として、問題となっていたのは以下の状況でした。
- 問題の機能は 外部ライブラリを利用
- 開発チームからは「サポート終了状態の外部ライブラリ側の問題なので不具合の修正は不可能」という回答
- 顧客は「どうしてもこの機能を業務で使いたい」
結果として、 「直せない」「でも使いたい」 という平行線の状態に陥っていました。
※ 本記事はプロジェクト構造上のリスクマネジメントの話として整理しています。
リスクマネジメントとは
本記事ではこの経験を振り返りながら、下記について整理してみたいと思います。
- PM管理工数とコンティンジェンシーの違い
- 既知のリスクと未知のリスクの扱い
- ITIL4のリスクマネジメント・プラクティスとの関係
工数ゼロという依頼は、何が問題なのか
結論から言うと、工数ゼロでタスクを依頼すること自体が、リスクを「見えなくしている」ということになるため最大の問題であると言えます。
工数＝コストであり、リスク対応の手段
プロジェクトにおける工数は単なる「作業量」ではありません。
- 調査する
- 関係者と合意形成する
- 実装する
- レビュー・テストを行う
これらはすべて リスクを低減するためのコストです。にもかかわらず、下記のような状態にしてしまうと、リスクは消えるどころか増大します。
- 工数ゼロ
- スケジュール影響なし
- 責任は個人任せ
PM管理工数とコンティンジェンシーの違い
この話題でよく混同されがちなのが、次のことです。
- PM管理工数
- コンティンジェンシー（予備）
PM管理工数（既知のリスクへの対応）
PM管理工数は、以下のような想定内のリスクに対して使われるべきものです。
- 調整コストの増加
- 仕様の曖昧さ
- ステークホルダー間の認識ズレ
- 軽微な手戻り
つまり、「発生する可能性が分かっているリスク」 に対する管理コストです。
コンティンジェンシー（未知のリスクへの備え）
一方、コンティンジェンシーは、 「起きるか分からないが、起きたら影響が大きいリスク」 に備えるためのものです。今回のケースで言えば、
- 外部ライブラリの制約
- 製品側ではどうにもならない不具合
上記は、 後になって顕在化した時点で「既に現実の問題」 です。
これを「工数ゼロで個人に吸収させる」のは、コンティンジェンシーの考え方とも真逆です。
ITIL4のリスクマネジメント・プラクティスとの関係
ITIL4では、リスクマネジメントは以下の考え方を重視しています。
- 不確実性を理解する
- リスクを可視化する
- 組織として意思決定する
- リスクを受容・回避・軽減・移転する
ITIL4の観点で見た今回の問題
このケースをITIL4のリスク管理プラクティスで整理すると、次のようになります。
| 観点 | 実態 |
|---|---|
| リスクの識別 | 外部ライブラリ依存という明確なリスクが存在 |
| リスクの分析 | 修正不可という影響が把握されていた |
| リスク対応 | 「工数ゼロで個人任せ」という非組織的対応 |
| 意思決定 | プロジェクト外にリスクを追い出していた |
つまり、 リスクを管理するのではなく、隠蔽していた 状態だったと言えます。
実際に行った対応：別プロジェクトとして切り出す
最終的にこのタスクは、第2期プロジェクト(一人)という形で正式に立ち上げられて無事に完了することができました。
- 顧客側課長の決裁範囲
- 別プロジェクト
- 私一人が担当
なぜうまくいったのか
成功要因を整理すると、次の通りです。
✅ 工数と責任が明確
✅ 「直す」ではなく「新しく作る」判断
✅ 仕様決定を顧客側担当と1対1で高速に進められた
✅ 顧客IT部もレビューに参加
✅ リスクが事前に洗い出されていた
もちろんこの別プロジェクトは非常に健全なプロジェクトになりました。
- PM管理工数を使う必要なし！
- コンティンジェンシー発動なし！
- 計画通りに完了！
学び：リスクは「消す」のではなく「置く場所」が重要
この経験から得た最大の学びはこれです。
リスクは存在そのものよりも、「どこに置かれているか」が問題
「工数ゼロでよろしく」は、リスクを個人に押し付けて可視性を失わせる最悪の選択です。ITIL4が示すように、リスクは次のように扱うべきです。
- 認識され
- 議論され
- 意思決定される
おわりに
プロジェクト管理とは、進捗管理でもスケジュール管理でもなく、 不確実性をどう扱うか その積み重ねだと感じています。
もし「工数ゼロで何とかして」と言われたら、それは技術の問題ではなく リスクマネジメントの問題かもしれません。同じような経験をした方の参考になれば幸いです。
一般的マネジメントプラクティス一覧
- アーキテクチャ管理
- 情報セキュリティ管理
- ナレッジ管理
- 測定と報告
- 組織変更の管理
- ポートフォリオ管理
- プロジェクト管理
- 事業関係管理
- リスク管理
10.サービス財務管理
11.戦略管理
12.サプライヤ管理
13.要因及びタレント管理 ← 今回はコレ
14.継続的改善
株式会社ジールができること(宣伝)
AIを活用するためには確かなデータ基盤とPDCAのそもそもPを始めるためのデータの可視化が必要です。ジールではZ-BISS BI製品選定サービスというものを提供しております。はじめてのデータ活用、もっとデータ活用したい方へ。また、数十以上のBI製品を取扱う安心安全のBI選定サービスをご利用になりたい方は、 BI・データ活用の窓口「Z-BISS」 へアクセスしてみてください。もしれません。同じような経験をした方の参考になれば幸いです。