優先順位と優先度

プロジェクトで課題管理や問題管理、はたまたバグ一覧などを作ると必ず項目として存在するのが「優先度」があると思うんですが、ちょっとPCの中からその類の一覧表をいくつか確認していただけますでしょうか。

ね。あるでしょ？こんな具合ですよね。

項番

大分類

中分類

小分類

概要

状況

優先度

担当者

解決希望日

解決実績日

決定事項

備考

7番目の「優先度」がそれですね。で、その優先度には、こんな選択肢を用意していたりします。

優先度	高い、普通、低い 重要、普通、低い H、M、L

で、この様式、この項目で運用されるとどうなるか……。

項番	大分類	中分類	小分類	概要	状況	優先度	担当者	解決希望日	解決実績日	決定事項	備考
1	アプリ	Aシステム	aサブシステム	パッケージが予定しているOSのバージョンをサポートしていない。	2014/09/12　起票。	高い	Aさん	2014/10/30	-	-	-
2	アプリ	Aシステム	bサブシステム	インストールが失敗する。	2014/09/12　起票。	高い	Bさん	2014/09/19	-	-	-
3	共通	管理	品質管理	決められたレビュー手法では運用できない	2014/09/12　起票。	高い	Cさん	2014/10/10	-	-	-

極端な例ですけど、優先度が全部「高い」になっています。それはそうですよね。起票した人には目の前の課題を解決しないと後続の作業がストップしてしまうということがわかっているんですから、そりゃ急ぎたい、と思います。だから、「高い」を選ぶわけです。

きちんと、課題が生じて影響しているタスクの納期と課題が解決した後の残タスクの工期を想定できているなら、優先度はホント「高い」なのか、っていう観点で優先度の設定が適切であるかを観ないといけないのですけど、でも決められるのは課題を解決する主体者なんですけど。まぁ、プロジェクトマネージャが「いついつまでに解決するように動きなさい。」と言うこともありますけどねー。それは解決希望日がプロジェクトのスケジュールと整合性が取れていないとか、後工程のリードタイムの考慮漏れ、があるときですねー。

優先度を「高い」でも「重要」でもいいのですが、それを選ぶことは目の前の課題を解決して先に進みたいからですが、でもその課題を解決するリソースである人は、大体チームの中の人だったりするわけで、全部が「高い」であるなら課題解決の担当者は

「どれからやるのよ？」

と質問が出てくるわけで。そこで課題を起票をした人がバラバラに複数いて解決先が一人とかだと、もう、スタックしますよね。競合するから。そうしたところが拙いんですよね、優先度って。

じゃあ、優先順位なら解決するのか。

すると言えば解決するけど、それって優先度が「高い」もののグループを片付けようとするときに結局、「どれからやるの？」という裁定をするわけですが、その時になってからやるんじゃなくて先に、例えば起票時とか、定期的なサイクルで優先順位付け直すことができれば回避は出来ますね。

その方が、サイクルで見直す都度のプロジェクトの置かれた状況に柔軟に対応できるので、やり慣れないとアレですけどこっちの方がいいでしょうね。つまり、優先度はやめた方がいいということです。

ただ、対外に出す資料で曖昧性を持たせたいとかそういった理由なら、それはそれでありですけど内部としては優先順位で行くのがいいでしょうね。