こんにちは、たびとです。
プロジェクトのインシデント管理（または障害管理・課題管理など）と呼ばれるモノは、 重要度と緊急度の2列から優先順位を付けるようになっていて、 この「重要度」と「緊急度」は、3または5段階に分けられいるかと思います。
3段階の場合、「重要度×3」×「緊急度×3」= 9通りの組合せがありますが、 この 9 通りの優先順位はどう付ければよいのでしょうか。
プロジェクトによっては「３通り × ３通り」の掛け算の値で優先度を決めていることもありましたが、 同じ値 (例えば重要度2・緊急度3 と重要度3・緊急度2) のときは、どうすればいいの？と誰もが質問することになります。 ここで、重要度と緊急度のどちらが優先されるべきかの議論が起こりますが、結論が出たことはありません。
このように考え方が曖昧なため、大抵のプロジェクトでは誰もが、 インデントを発行する場合、重要度と緊急度の値付けに悩んで、 最終的に感覚で決めてしまうことが多くなると思います。
炎上したプロジェクトを立て直すとき、優先順位を付け間違えると崩壊が加速します。 そうした数多くの炎上プロジェクトを鎮火するなかで、結局シンプルな考え方が最適解と思えたので、 それを紹介したいと思います。
この記事の対象者
- 重要度と緊急度の関係性を理解したい方
- 優先順位を決定する判断基準について学びたい方
- 炎上プロジェクトの立て直し方のヒントを欲しい方
優先順位の考え方
どのプロジェクトでも、インシデント管理を「重要度」と「緊急度」の判断基準で 優先度を決めているのですが、その関係性を説明しているモノには遭遇したことがありません。
「重要度」と「緊急度」の 2 つの軸から、どうやって優先度を付ければいいのかと、 誰もが悩んでいることではないでしょうか。
あるとき、2軸ということは、XY座標のように表現できるのでは？と思うようになりました。 それが、優先度の考え方を整理する上で最も重要なことでした。
判断基準を作ることの難しさ
以前、某省のプロジェクトで霞が関の庁舎でコンティンジェンシープランを 説明したとき、頭の切れる担当の方に、 「この運用設計は、実例は豊富にありますが、新たな事象が発生したとき、我々はどのように判断すればよいのですか？その判断基準、つまりモノサシを教えてください。」と言われ、 即答できずに、次回の宿題にさせて頂いた記憶があります。
この宿題は、誰に聞いても即答できる人はいなくて、 コンティンジェンシープランの判断基準を作るのに、 とても苦労した記憶がありますが、最終的にできた判断基準は、 3 段階のシンプルな基準で、誰が見ても理解できる内容でした。
このように判断基準を作るコツは、分け過ぎないことです。 細かく分ければ分けるほど難解になって、誰も理解できなくなり、 実際に運用したとき、形骸化してしまい効果が半減します。
この「 誰が見ても理解できること 」が、非常に重要で、 これを作り出すのには、物凄いエネルギーが必要なのですが、 出来上がったモノは、シンプルで分かり易いため、 「当たり前のことしか書いてない」となってしまい、 モノサシを作ったことがない人達には、残念ながら低評価されることになります。
重要度とは
重要度のモノサシは、「高い」か「低い」の二択です。 ここで最も大切なことは、原則として「 変化しない 」ということです。 「高い」モノは高く、「低い」モノは低いままです。
図の A と B は、アルファベット通り、A から先に実行します。
緊急度とは
緊急度のモノサシは、時間軸を表しています。 ここで最も大切なことは、「 変化する 」ということです。
つまり、図の「後日」は時が経てば確実に「即時」に変化します。 また、新たなインシデントが発生した場合も見直す必要があります。
この緊急度は、注意深く監視する必要があるのですが、 経験上、インシデントの棚卸のときも重要度の高さは意識しても 緊急度の変化に注意を向ける人は少ないと思います。
優先順位の決め方
重要度を縦軸に緊急度を横軸にすると、 「A.(重要度)高/(緊急度)即」・「B.(重要度)低/(緊急度)即」・ 「C.(重要度)高/(緊急度)後」・「D.(重要度)低/(緊急度)後」の4つの領域から構成されます。
重要度の高い順に処理するのは当然ですが、期限が設定されている以上、 重要度が低くても期限内に完遂させる必要があります。 これが、ABCDに分類する理由で、そのまま優先順位の順番を意味しています。
また、原則として「重要度は変化しない」かつ「緊急度は変化する」ことから、 「 重要度の高い AとC 」・「 重要度の低い BとD 」の推移に気を配ります。 この時間の推移は直ぐに忘れるため、定期的な棚卸が必要となります。
実際に運用した限り、このシンプルな考え方は、現場の誰もが理解してくれました。 この誰もが理解できることが重要で、情報を共有するスピードが上がると、 連動してタスクを消化するスピードも上がってきます。
運用時のポイント
プロジェクトが順調であれば、好きにやっても問題ないと思いますが、 もし、プロジェクトが炎上中の場合、目標を約 7 割程度に引き下げて、 どうしても達成しなけばならないモノを残して、後は全力で捨てましょう。
そのとき、残ったタスクは以下のように対処しましょう。
- A領域 に全力を注ぎましょう
- B領域 は督促が来るまで放置するか、誰かに依頼しましょう
- C領域 は A に遷移する前に延期調整、または誰かに依頼しましょう
- D領域 とにかく忘れましょう（督促が来てからで大丈夫）
死にそうとアラームを上げても、タスクを振る人は多いので、賢く立ち回りましょう。 最終的に受けるにしろ、安請け合いをせず、最初に全力で拒否しましょう。 そうすることで、延伸や捨てるための交渉で優位に立てる確率が上がります。
管理層が注意すること
プロジェクトの関係者は、誰もが「A領域」に注目していますが、 管理層は、誰も気にしない「 Ｃ領域 」に注意しましょう。
特にインシデントが 3 桁を超えてくると、 A の進捗に気を取られて、C から A への遷移に気付くのが遅れます。 A は問題が発生しないかぎり、放置して大丈夫です。C の変化に注意しましょう。
管理層が原因でプロジェクトが崩壊すると、以下の現象が発生して、マネジメントが機能不全になります。 そして次々にリーダ層が送り込まれてくる訳ですが、大抵はデスマーチに向かうことになります。 理由は単純で、炎上プロジェクトを立て直せるような人材は、常に忙しいからです。
- 顧客や上層部への報告書作成と報告書説明に忙殺されている
- 上記の報告書のために、仕事終わりに各チームリーダに進捗の報告書を作らせる
- 午前中の会議で前日の進捗を報告させ、自分が理解するために質問攻めにして午前中を潰す
プロジェクトの状況が把握できないのは、技術力や業務スキルの不足に起因することが大半なので、 プロマネの勉強よりも先に、技術力や業務スキルを上げる努力をしましょう。 ある程度の技術力や業務スキルがないと、顕在化している Ｃ領域 の対策ができないだけでなく、 隠れた Ｃ領域 の問題を発見することができなくなります。
管理層は、外野からの依頼は簡単に引き受けず、雑務からメンバーを守り、 A領域 に集中できる環境を作りましょう。
まとめ
今回は、プロジェクトにありがちな「重要度」と「緊急度」についてのアプローチを紹介しました。 プロジェクトが順調なときは、意識しなくても上手くいきますが、意識して管理すると崩壊を未然に防ぐ確率が上がると思います。
この優先順位の付け方は、緊急度という時間軸を意識できるようになっていることが最大の特徴です。 タスクが 3 桁を超えてくると、時間軸まで意識することが難しくなるため、シンプルに考えることは重要になります。
結局、「重要なモノを先に、重要でないモノは後へ」って当然のことを説明しているだけですけどね。 ただし、通常時に B領域 のタスクを督促が来るまで放置すると、人間関係が悪くなるのでほどほどに。
では、皆さん、よい旅を。
