もう随分前になりますが、このブログの中で「デスマーチ」そして「パーフェクトソフトウェア」という2つの著作をご紹介したことがあります。両者に共通するポイントはリソースは有限であるため全てのバグを取り除くことができないという点と、その有限のリソースの中でバグをどのように分類し優先順位を付けて対応するかという点であろうと思います。いずれもソフトウェア開発に関する著作ですので「バグ」が対象にはなっているのですが、もっと広くプロジェクトマネジメントという観点に引き上げてみると、バグだけではなくバグ対応を含めたToDoの捌き方のアドバイスということになります。
前者の「デスマーチ」ではトリアージという戦争時における負傷者救護の優先順位づけのアイデア（これは今の災害時の救急医療現場でも活用されているようです！）を紹介していますが、後者の「パーフェクトソフトウェア」ではトリアージを実践するための具体的なバグの分類方法を提案しています。当時のブログ記事の中でも私なりにアレンジした分類方法をご紹介しましたが、今回はより進んだ分類方法をご紹介します。
システム開発では、開発中のシステムに対する仕様の変更や追加の要求が出されることが良くあります。要求を出す方としては当然のことながらすべてに対応してもらいたいと思うものですが、要求を受ける方としても当然のことながらプロジェクトとして実施している場合は納期も予算もありますので（これがリソースが有限であるということの意味ですが）出された要求の全てに応えることができないという状況に陥ることがあります。
そんな時、要求を一覧化して対応するかしないかを選別しても良いのですが、もっと明確な基準があると判断にも迷わないですし、なされた判断も客観的で納得感が出てくると思いませんか。例えば、次のような分類を考えてみましょう。
レベル0：そもそも技術的に不可能であり、対応できない要求
レベル1：対応できなければリリース延期またはプロジェクトを中止する要求
レベル2：リリース時に無くても良いが、対応しないと業務に支障のある要求
レベル3：可能なら対応したいが、対応しなくても止むを得ない要求
これらの分類をするだけでも客観的な評価となり得ますが、次のような設問フローを作るとより客観的で論理的な判断を下すことが可能になり説得力が増します。
(1) 要求が技術的に不可能であるか。
［Yes⇒レベル0／No⇒(2)へ］
(2) 対応されなければリリース延期するか。
［Yes⇒レベル1／No⇒(3)へ］
(3) 対応されなければ業務に支障があるか。
［Yes⇒レベル2／No⇒レベル3］
判断をするときには設問に答えていくだけで客観的な優先付けを行うことができ、レベル0は除外して優先度の高いものから残されたリソースの範囲で対応できるものを決定していくことになります。これも救急医療現場で使われるABCDEアプローチのようなもので、判断を急ぐときにはシンプルで強力なツールとなります。分類の数が多くなっても設問を増やすだけで良く、状況に応じてアレンジもしやすいです。