トピック2.2 — 業務の優先順位づけ

一文で言うと: 優先順位づけとは、トリアージを生き延びた仕事を、価値、緊急度、リスク、工数を有限のキャパシティに照らして比較考量しながら、意図的かつ透明に順序づけることです。それにより、組織はどの瞬間も、できる限り最も価値のあることを行い、その理由を説明できます。

医療・ケアにおいてなぜ重要か#

優先順位づけは、戦略が現実になる場所です。組織の本当の戦略は、公表された計画ではなく、実際にものごとを行う順序です。医療・ケアでは、その順序が安全、公平性、公費に結果をもたらします。相互運用性の作業を後回しにすれば共有ケア記録が停滞し、技術的負債を後回しにすれば祝日の午前2時にシステムが止まり、アクセシビリティの修正を後回しにすれば、サービスを最も必要とする人々を排除します。

その圧力は構造的なものです。需要は常にキャパシティを上回り、その需要の多くは正当なものです。したがってリーダーには、最後に届いたメールが勝つ、あるいはすべてのプロジェクトが「最優先」であるようなプロセスではなく、トレードオフを明示的で説明可能にする手法が必要です。透明な優先順位づけは、政治的な空気も変えます。利害関係者が基準と順序を見られるとき、交渉は、ロビー活動から、価値と遅延のコストについての共通の会話へと移ります。本トピックは受付(トピック2.0)とトリアージ(トピック2.1)の後に続きます。順序づけるべき、見える、評価済みのバックログがすでにあることを前提とし、デリバリーのライフサイクル(第3.4〜8トピック)とポートフォリオマネジメント(トピック5.3 — エンタープライズ・プロジェクトポートフォリオマネジメント(EPPM))に入力します。

中核概念#

**優先順位づけ**は、バックログやポートフォリオを順序づけます。各案件を個別に評価し振り分けた、トリアージとは別のものです。優先順位づけは、有限のキャパシティに対して、案件を互いに比較し、現実が変わるにつれて、その比較をやり直します。

**遅延のコスト(Cost of Delay)**は、最良の手法の根底にある経済的なレンズです。これが行われない一週間ごとに、価値、害、お金の面でどれだけのコストがかかるか。遅延のコストを明示することは、優先順位づけを、「何が最も重要か」(すべて)から、「何を遅らせるのが最も高くつくか」(順位づけ可能な問い)へと組み直します。

一般的なフレームワークは、それぞれに適した場面があります。

  • WSJF(Weighted Shortest Job First、重み付き最短ジョブ優先):Scaled Agile Framework(SAFe)に由来します。遅延のコスト(ユーザー/事業価値+時間的な緊急性+リスク低減/機会創出)を採点し、ジョブの規模で割ります。WSJFが最も高いものから行います。小さく、価値が高く、時間的に切迫した仕事を自然に優遇し、埋没費用を無視します。
  • RICE(Reach × Impact × Confidence ÷ Effort、Intercomが広めた):熱意を確信度の要素で和らげる、プロダクトマネジメントのスコア。
  • MoSCoW(Must / Should / Could / Won't-this-time):DSDMに由来します。リリースや、日付固定のプログラムの範囲設定に優れた分類で、細かい順序づけとしては弱いものです。
  • 価値対工数(2×2):クイックウィンと金食い虫を見つけるための素早い視覚化。粗いが速い。
  • 狩野モデル:機能を、基本(必須)、性能、魅力に分類します。基本要件と差別化要素のバランスをとるのに役立ちます。

「正しい」フレームワークはありません。それぞれが、価値の異なる定義を符号化しており、一緒に採点するという行為自体が、数字よりも価値があることが多いのです。

運用(run)対変更(change)は、ポートフォリオレベルのバランスです。「稼働を維持する」運用の仕事(run)対新しいケイパビリティ(change)。優先順位づけは両方にまたがらなければなりません。さもなければ、技術的負債や安全/セキュリティの是正を含む、目に見えない運用の仕事は、派手な新機能とのあらゆる競争に負け、壊滅的に失敗するまで続きます。

キャパシティ基準対日付基準の優先順位づけ:キャパシティ基準の順序づけは、既知の有限なスループット(持続可能なペース)を埋め、日付基準の順序づけは、動かせない期限(規制上の稼働日)から逆算し、MoSCoWで範囲を柔軟にします。ほとんどのポートフォリオは、異なる案件に適用される、両方を必要とします。

ベストプラクティス#

  1. 主たるフレームワークを一つ選び、一貫して適用する。 自分たちの仕事に合う手法を選びます。本物の時間的緊急性のある混合の変更ポートフォリオにはWSJF、プロダクトの機能バックログにはRICE、日付固定のリリースにはMoSCoW。スコアが比較可能になるよう、一貫して使います。案件ごとにフレームワークを切り替えると、バックログが比較不能になり、操作を招きます。

  2. 特に安全と法定の仕事について、遅延のコストを明示する。 各案件について問います。「一か月の遅れはいくらかかるか」。安全上の修正や規制の期限では、答えはしばしば深刻で非線形であり、だからこそ、想定するのではなく採点しなければなりません。遅延のコストは、コンプライアンスの期限とユーザー体験の改善を、誠実に比較できるようにする共通の通貨です。

  3. 運用、技術的負債、安全のために、明示的なキャパシティを確保する。 稼働維持の仕事、技術的負債、セキュリティ/安全の是正を、新しいケイパビリティと機能ごとに競わせてはなりません。何かが壊れるまで、それらは負けます。キャパシティの一定の割合(経験則としては、意味のある、保護された一部)を、この仕事のために確保し、譲れないものとして扱ってください。

  4. 依頼者の地位ではなく、成果と価値で優先順位をつける。 誰が頼んだかではなく、組織が表明した成果と優先事項(理想的にはそのOKR — トピック10.0参照)に照らして採点します。上級の利害関係者の案件のスコアが低いとき、それはシステムが機能しているのです。フレームワークは、その会話をするための、公正で個人的でない基盤を与えてくれます。

  5. 手法を制約に合わせる:キャパシティか日付か。 持続可能な変更の流れには、価値で順序づけ、既知のキャパシティに合わせて仕事を引き込みます。動かせない日付には、逆算し、MoSCoWで「Must」を守り、「Could」を柔軟にします。二つを混同すること、つまり固定された範囲を、固定された時間と固定されたキャパシティに収めようとすることが、失敗するプログラムへの典型的な道です。

  6. 透明に優先順位をつけ、オープンに交渉する。 順位づけされたバックログと、その背後のスコアを公表します。透明性は、優先順位づけを、個別の取引の連続から、トレードオフが見える共通の交渉へと変えます。自分の案件を上げるには、何かほかを下げなければならず、誰もがそのコストを見られます。これは、デリバリーのリーダーが使える、唯一最も強力な脱政治化の手です。

  7. 定期的なリズムで再優先順位づけを行う。そして、そのときだけ。 新しいエビデンスに照らして優先順位を見直す、リズム(たとえば月次や四半期のポートフォリオレビューと、その間の軽いバックログの精緻化)を設定します。レビューの間は、一線を守り、チームが安定した助走路を得られるようにします。絶え間ない再優先順位づけは、一度もしないことと同じくらい有害です。流れを壊し、何も終わらせません。

  8. 操作と偽りの精密さに注意する。 相対的なスコア(フィボナッチ、Tシャツサイズ)は推定であり、真実ではありません。WSJFの8.3が、7.9より意味のある形で優れているわけではありません。数字は、順位づけられた会話に情報を与えるために使い、水増しされた入力に目を配り、明らかに不合理なスコアは経験に基づく判断に上書きさせます。ただし、その理由は記録してください。

チームで話し合うための問い#

  1. 私たちが先送りし続けている仕事について、「一か月の遅れは実際にいくらかかるのか」への、正直な答えは何か。 遅延のコストは、コンプライアンスの期限とユーザー体験の微調整を、誠実に比較できる共通の通貨ですが、ほとんどの組織はそれを明示せず、そのため「すべてが重要」に陥ります。これは順位づけ可能な言明ではありません。いくつかの仕事を遅らせるコストは、深刻で非線形であるため、医療・ケアでは特に切実です。先送りされた安全上の修正や相互運用性の依存関係は、何か月も無害に放置されたあとで、壊滅的に失敗しうる一方、先送りされた便利機能は、ほとんどコストがかかりません。チームは、争いのある上位の案件について、遅延のコストを実際に言葉にできるかを議論し、人気のあるプロジェクトには「ほとんどない」、目に見えないプロジェクトには「深刻なインシデントの可能性」という、不都合な誠実な答えになる事例に向き合うべきです。具体的な視点。現在バックログの真ん中で止まっている三件を取り上げ、それぞれについて、遅延のコストを一文で言わせる。技術的負債と安全の是正が、そもそも遅延のコストで採点されたことがあるのか、あるいは、競争に入らないことでいつも負けているのかを問います。良い答えは、遅延のコストがほぼ線形な案件と、期限や故障点で急上昇する案件を区別し、その形を、順序の正当化に使います。不誠実な版は、「すべてが優先事項だ」の陰に隠れます。それこそが、この問いが暴こうとする、優先順位づけの不在です。

  2. 運用、技術的負債、安全のために、どれだけのキャパシティを確保する意思があるか。そして、派手な新しい提案が来たとき、それを守れるか。 これは、最も確実にうまくいかないトレードオフです。稼働維持の仕事、技術的負債、セキュリティや安全の是正は目に見えず、祝日の午前2時に何かが壊れるまで、新しいケイパビリティとの機能ごとの競争に負け続けます。議論は、キャパシティの一部を守るべきかどうか(原則として、ほぼ全員が同意します)ではなく、具体的な割合、そしてはるかに難しいことに、上級スポンサーのわくわくするプロジェクトが、最初にその確保分を襲おうとしたとき、リーダーシップが実際にその線を守るかどうかです。医療・ケアでは、患者安全と、臨床家が頼るシステムの信頼性が懸かっているため、その一部を譲れないものとして扱うことは、単に良い衛生管理ではなく、安全に対する姿勢です。具体的な視点。直近の大きなインシデントやヒヤリハットを振り返り、それが、優先順位の競争で勝つことのなかった、先送りされた運用や負債の仕事にたどれないかを問う。保護されたキャパシティへの襲撃を拒む権限を持つ人を挙げ、その人が本当にそうするかを試します。強い答えは、具体的で保護された一部にコミットし、決定的には、良い意図に頼るのではなく、プレッシャーの下でもそれを守り続けるガバナンスを説明します。誠実な版は、確保分は、その場で最も力のある利害関係者との接触を生き延びてはじめて本物になることを認めます。

  3. 上級の利害関係者の案件のスコアが低いとき、私たちには、順位をそのままにしておく透明性と度胸があるか。 依頼者の地位ではなく、成果で優先順位をつけることは、当たり前に聞こえますが、HiPPO効果、つまり最も報酬の高い人の意見が、採点を静かに覆すことは、階層的なNHSや政府の現場での標準的な失敗であり、静かであるからこそ蝕みます。緊張は、スコアの低い上級者の案件は、システムが正しく機能していることが多いものの、透明で公表された順位づけとその採点の根拠がなければ、デリバリーのリーダーには、その会話をするための個人的でない基盤がなく、たいてい折れてしまうことです。チームは、自分たちのバックログとスコアが、依頼する組織に本当に見えているかを議論すべきです。オープンなトレードオフの交渉、つまり「あなたのものを上げるには、より高いスコアのどの案件を下げるのか、その遅れのコストに納得できるか」は、利用できる唯一最も強力な脱政治化の手であり、オープンな場でしか機能しないからです。具体的な視点。上級者の依頼が、最後にキューを飛び越えたときを思い出し、順位が公開されていたら何が起きたかを問う。採点の根拠を、取締役会、ICB、監査人に見せられるガバナンスの記録として保持することを考える。良い答えは、透明性(順序とスコアの公表)を、覆そうとする会話のための、練習済みの個人的でない台本と組み合わせ、それを保つ立場にあるのは誰かを特定します。はぐらかす答えは、これを仮定の話として扱います。現実には、ほぼ毎週起きており、計画はそれを生き延びなければなりません。

  4. 私たちは本当に一つの優先順位づけのフレームワークにコミットしているか。それとも、各案件を、それに都合のいい手法で静かに採点していないか。 主たるフレームワークを一つ選び、一貫して適用することが、バックログを比較可能にします。ある提案にはWSJF、別の提案には価値対工数の勘、三つ目には「ディレクターが強く望んでいる」が使われたとたんに、順序は意味を失い、操作が忍び込みます。緊張は、あらゆる種類の仕事に合う単一のフレームワークはないことです。WSJFは混合の変更ポートフォリオに、RICEはプロダクトの機能バックログに、MoSCoWは日付固定のリリースに合うため、誠実な議論は、どれが自分たちの主たる手法か、そして二つ目が、都合のいい逃げ道ではなく、正当に許されるのはどこかです。医療・ケアでは、コンプライアンスの期限、臨床家が求めた機能、データベースのアップグレードを、同じ尺度で比較しなければならず、一貫した手法だけが、法定の案件と便利な案件を、特別扱いの弁明なしに、互いに順位づけさせるため、これが重要です。具体的な視点。直近の十数件の優先順位づけの決定を監査し、同じ手法が本当に適用されたか、あるいは手法が、あらかじめ決まった答えを正当化するために変わったかを確認する。「フレームワークの芝居」、つまり、手の込んだ採点が、誰も行動しない数字を生む状態に注意する。良い答えは、主たるフレームワークを名指しし、別の手法が使われる狭く原則的な場合を説明し、スコアを、真実ではなく、順位づけられた会話に情報を与えるものとして扱います。弱い答えは、あらゆる依頼者に自分の計算を持ち込ませますが、それは手法がまったくないことと区別がつきません。

  5. どの仕事がキャパシティに縛られ、どれが日付に縛られているかについて、私たちは誠実か。それとも範囲、日付、キャパシティのすべてを同時に固定しようとしていないか。 優先順位づけは制約に合わせなければなりません。持続可能な変更の流れは、価値で順序づけられ、既知のキャパシティに合わせて引き込まれ、動かせない規制上の稼働日は、日付から逆算し、MoSCoWが「Must」を守り、「Could」を柔軟にします。失敗するプログラムへの典型的な道は、この二つを混同すること、つまり範囲、日付、キャパシティを同時に固定することであり、法定の期限が譲れないように感じられ、利害関係者が、全範囲も同じく譲れないと想定する、医療・ケアでは特に誘惑的です。チームは、主要な仕事の一つ一つについて、本当にキャパシティに縛られているのか、日付に縛られているのかを議論すべきです。日付主導のプログラムを、時間に弾力があるかのように扱ったり、日常業務の流れを、厳しい期限があるかのように扱ったりすると、下流のすべてを誤って優先順位づけするからです。具体的な視点。動かせない稼働日を取り上げ、どの要件が、法的な最小限として本当に「Must」で、どれが、必須の集合に紛れ込んだ「Should」や「Could」かを問う。三つの制約がすべて静かに固定されているプログラムを探し、現実に直面したときに、実際に何が折れるかを挙げる。良い答えは、仕事を、その束縛する制約によって分類し、合致する手法を意図的に適用し、キャパシティ基準のフローと日付基準のデリバリーを、別々の規律として保ちます。非現実的な答えは、固定された日付に、固定されたキャパシティの中で、全範囲を約束し、あとは祈ります。

  6. 私たちの再優先順位づけのリズムは何か。そして、レビューの間、順序を安定して保つ規律があるか。 優先順位は、新しいエビデンスに照らして見直されなければなりませんが、リズムを持って行われるべきです。月次または四半期のポートフォリオレビューと、その間の軽い精緻化です。絶え間ない再優先順位づけは、一度もしないことと同じくらい有害で、流れを壊し、何も終わらせないからです。緊張は本物です。現実は実際に変わり、新しい安全のシグナルや資金の変化は、並べ替えを正当化しうるものの、進行中の組み替えのたびに、チームは助走路を失い、半ばできた仕事が取り残されます。デリバリーのチームがしばしば逼迫し、依存関係が複数の組織にまたがる医療・ケアでは、空回りは高くつき、士気を削ぐため、レビューの間の安定した助走路は、デリバリーと同じくらい、生産性と定着の問題です。具体的な視点。直近の四半期に、バックログの上位が予定されたレビューの外で何回変わったか、その結果として何が出荷されたかを確認する。リズムを破ることを正当化する、狭い基準、つまり本物の緊急事態であって、声の大きい利害関係者ではないものに、事前に合意する。良い答えは、明示的なリズムを設定し、レビューの間の助走路を守り、順序が保たれたために実際に終わった仕事を示せます。失敗する答えは、最後のメールが届くたびに再優先順位づけし、何も完了しないのに、動きを応答性と取り違えます。

実践例:医療・ケアの事例#

あるICBのデジタルポートフォリオチームは、競合する12件の提案に対して、おそらく5件分のキャパシティしかない状況に直面していました。従来、順序は組織の序列に従ってきて、技術的負債はまったく対象になりませんでした。彼らは変更の仕事にWSJFを採用し、運用、技術的負債、安全のために、キャパシティの固定された一部を確保しました。

各提案は、デリバリー、臨床、財務の声が揃った一回のセッションで、事業価値、時間的な緊急性、リスク低減/機会創出、ジョブの規模について、一緒に採点されました。法定のデータ提出の期限は、時間的緊急性で非常に高く採点され、規模が控えめだったため、WSJFで最上位に上がりました。大規模で人気のある分析プラットフォームは、価値では高く採点されましたが、その規模が順序を押し下げました。序列に基づく順位づけの下では考えられなかった結果であり、フレームワークが、それを説明可能にしました。長く先送りされてきた、以前は目に見えなかったデータベースのアップグレードは、故障する前に、確保された運用の枠から資金が出されました。

決定的なのは、順位づけされたバックログとそのスコアが、依頼するすべての組織と共有されたことです。あるトラストが、自分たちの提案をキューの先頭に押し上げようとしたとき、会話は「誰を知っていますか」ではなく、「より高いスコアのこれらのうち、どれを下げるべきか、その遅れのコストに納得できますか」でした。交渉はオープンな場で行われ、ICBは、順序が政治ではなく、価値と遅延のコストを反映していると、取締役会に示せました。

セクター別の視点#

スタートアップ#

資金に制約のあるデジタルヘルスのスタートアップは、何よりもランウェイに照らして優先順位をつけるため、その順序づけの手法は軽く、価値主導であるべきです。価値対工数の2×2や単純なRICEのスコアで、通常は十分で、30件のバックログに対して、手の込んだWSJFの仕組みは過剰です。支配的な遅延のコストは存続に関わるものです。NICEの評価や主要な顧客が必要とするエビデンスを逃せば、会社が終わりかねず、それはあったら良い機能を大きく上回ります。最も難しい規律は、毎週が次の収益の機能を求めて叫んでいるときに、技術的負債と安全の是正のために、いくらかでもキャパシティを確保することですが、それを完全に飛ばすことこそが、若いプロダクトが、規模を拡大するまさにそのときに動かなくなる原因です。再優先順位づけは頻繁で、創業者主導のため、リスクは空回りです。対策は、何かが実際に出荷されるよう、少なくとも短いスプリントの間は、安定した順序を保つことです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、ほとんど余裕なく優先順位をつけます。同じ少数の人々がサービスと、あらゆる変更の仕事を運営するため、順序づけは徹底して単純でなければならず、チームの誰もが読める価値対工数の2×2は、誰も維持する時間のない採点モデルより価値があります。支配的な遅延のコストは、通常、法定または安全を動機とするものです。データセキュリティ・ツールキットの期限、臨床安全の修正、国のサプライヤーによる義務的なシステムのアップグレード。そして、小規模な提供者は、失敗を吸収する資源がないまま、大きなトラストと同じ義務を負うため、これらは最上位になければなりません。裁量的な改善は、サービスの運営と実際に競合するため、誠実な規律は、譲れない運用と是正の仕事のために、小さく定期的な時間の枠を守り、毎週それが患者対応の要求に負けるのを許さないことです。専任のIT能力が薄い、あるいはまったくない場合、「どうやるか」の多くは、サプライヤーと枠組み契約によって決められるため、優先順位づけは、しばしば、サプライヤー主導の変更と、診療所が制御できる少数のことを順序づけることであり、忙しい一週間と次の一週間の間に、何かが終わるよう、安定した順序を十分長く保つことです。

大企業#

NHSトラストやICSは、本物の時間的緊急性と重い運用義務を持つ混合の変更ポートフォリオを運営しており、まさにWSJFと、確保された運用/技術的負債/安全の枠が想定した形です。本当の課題は政治です。複数のスポンサー組織、HiPPOの圧力、序列が順序を決めるというレガシーな期待があるため、順位づけされたバックログとそのスコアの透明性が、大企業の主要な脱政治化の道具です。ここでの優先順位づけは、ポートフォリオ室にまたがり、日常業務の変更に対するキャパシティ基準のフローと、動かせない規制上の稼働日から逆算し、MoSCoWで範囲を柔軟にする、日付基準のプログラムとを調整しなければなりません。トラストは、取締役会、ICB、監査人に対して費用対効果を示さなければならないため、採点の根拠は、決定が下されたあとに捨てられるのではなく、ガバナンスの記録として保持されます。

政府#

NHS England、DHSC、あるいは地方分権された政府では、優先順位づけは国民規模のポートフォリオマネジメントであり、Management of Portfolios(MoP)と財務省の5つのケースモデルを通じて形式化され、遅延のコストは、集団の健康、法定のコンプライアンス、数十億ポンドで測られます。ポートフォリオの多くは裁量の余地がありません。義務づけられた提出、法的な期限、大臣の約束です。そのため手法は、やるかどうかではなく、義務づけられた仕事のどうやるかといつやるかを順位づけなければならず、動かせない日付のプログラムが支配的です。リスク選好は低く、精査は対立的です。National Audit OfficeとPublic Accounts Committeeは、順序が価値と遅延のコストを反映したのか、単なる政治的都合だったのかを検証するため、明示的で公表された優先順位づけの根拠は、管理の道具であると同時に、防御でもあります。公平性は、価値の法定の次元であるため、政府の採点モデルは、集計した利益だけでなく、最もサービスを受けていない集団への影響に重みを付けるべきです。さもなければ、すでに十分サービスを受けている人々を、体系的に優遇します。

よくある失敗パターン#

  • すべてが最優先。 本当の順序がなく、最も声の大きい人か、最も近い期限が支配する。対策: 厳密な順位づけを強いる。上位では同順位を認めない。
  • 運用と技術的負債がいつも負ける。 目に見えない運用と是正の仕事が、故障するまで飢えさせられる。対策: 確保され、保護されたキャパシティ。
  • HiPPOによる上書き。 最も報酬の高い人の意見が、毎回採点を静かに覆す。対策: 透明なスコアと、オープンなトレードオフの交渉。
  • フレームワークの芝居。 手の込んだ採点が、誰も行動しない数字を生む。対策: スコアに、実際に行動される、順位づけられた順序へ情報を与えさせる。
  • 固定された範囲+固定された日付+固定されたキャパシティ。 三つの制約がすべて固定され、失敗が保証される。対策: MoSCoWで範囲を、あるいはキャパシティや日付を、柔軟にする。
  • 空回り。 優先順位が毎週変わり、何も終わらない。対策: 決まった再優先順位づけのリズムと、その間の安定した助走路。

成熟度モデル#

観点 着手 発展 標準化 管理 統合
手法と根拠 手法なし。序列か期限で順序づけ 一貫せず、または一部の仕事にだけフレームワークを使う 一つの主たるフレームワークを一貫して適用し、遅延のコストが考慮される 採点の入力がガバナンスされ較正される。優先順位づけの決定が、表明された成果に照らして測定される フレームワークが成果/OKRに合わせて調整され、キャパシティ基準と日付基準の手法が意図的に使い分けられる
運用/変更と技術的負債のバランス 運用と技術的負債が見えず、新しい仕事にしか資金が付かない 運用/負債への一定の認識はあるが、保護されたキャパシティがない 運用、技術的負債、安全のための確保されたキャパシティ 保護された枠が指標として追跡され、運用/負債と安全の是正が目標に対して保証される 運用と変更のバランスが、価値に照らして積極的に管理・見直される
透明性とリズム 優先順位が不透明で、場当たり的に絶えず変わる バックログは部分的に見え、レビューは不定期 順位づけされたバックログが公表され、固定された再優先順位づけのリズムがある リズムの遵守と再優先順位づけの変動が追跡され、採点の根拠が取締役会と監査人のためのガバナンスされた記録として保持される オープンなトレードオフの交渉が標準で、リズムが安定し、スコアが結果に照らして妥当性を確認される

チェックリスト#

  • 一つの主たる優先順位づけのフレームワークが選ばれ、一貫して適用されている。
  • 特に安全と法定の仕事について、遅延のコストが明示されている。
  • 運用、技術的負債、安全/セキュリティの仕事のためにキャパシティが確保されている。
  • 案件が、依頼者の序列ではなく、成果/OKRに照らして採点されている。
  • キャパシティ基準と日付基準の手法が、適切な案件に使われている。
  • 順位づけされたバックログとその採点が、利害関係者に公表されている。
  • トレードオフがオープンに交渉されている。一つを上げるには、別のものが下がる。
  • 再優先順位づけが決まったリズムで行われ、その間に安定した助走路がある。
  • スコアが推定として扱われ、操作と偽りの精密さに注意が払われている。
  • 現在の順序を、取締役会に説明し、擁護できる。

主要な情報源#

  • Scaled Agile Framework (SAFe) — Weighted Shortest Job First (WSJF)と遅延のコスト。
  • Reinertsen, D. — The Principles of Product Development Flow(遅延のコスト、待ち行列の経済学)。
  • Intercom — RICEの採点モデル(Reach, Impact, Confidence, Effort)。
  • DSDM / Agile Business Consortium — MoSCoWの優先順位づけ。
  • Kano, N. — 顧客満足の狩野モデル。
  • Cabinet Office / AXELOS — Management of Portfolios (MoP) — ポートフォリオの優先順位づけとバランス。
  • NHS Digital Service Standard & GOV.UK Service Manual — 最も重要なユーザーのニーズを優先する。成果との整合のためのOKR(Doerr, Measure What Matters)。

参考文献#

  1. Prioritization — Wikipedia — https://en.wikipedia.org/wiki/Prioritization
  2. Cost of delay — Wikipedia — https://en.wikipedia.org/wiki/Cost_of_delay
  3. Scaled agile framework — Wikipedia — https://en.wikipedia.org/wiki/Scaled_agile_framework
  4. MoSCoW method — Wikipedia — https://en.wikipedia.org/wiki/MoSCoW_method
  5. Dynamic systems development method — Wikipedia — https://en.wikipedia.org/wiki/Dynamic_systems_development_method
  6. Kano model — Wikipedia — https://en.wikipedia.org/wiki/Kano_model
  7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
  8. Objectives and key results — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
  9. Weighted Shortest Job First (WSJF) and Cost of Delay — Scaled Agile Framework (SAFe) — https://framework.scaledagile.com/wsjf
  10. Reinertsen, D. — The Principles of Product Development Flow — Celeritas Publishing — https://www.celeritas.com/
  11. The RICE scoring model (Reach, Impact, Confidence, Effort) — Intercom — https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
  12. MoSCoW prioritisation — DSDM / Agile Business Consortium — https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
  13. Management of Portfolios (MoP) — AXELOS / Cabinet Office — https://www.axelos.com/
  14. Doerr, J. — Measure What Matters (OKRs) — Portfolio/Penguin — https://www.whatmatters.com/
  15. The Green Book: appraisal and evaluation in central government (five-case model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government

GitHubでこのページを編集 — 本書が信頼できる唯一の情報源であり、このサイトはそれを表示するだけです。