仕事の順番は、
優先度関数の設計問題？
（優先キューの考え方）

by

関連記事

1. 仕事の進め方はキューかスタックか

仕事の進め方を、キューとスタックのどちらか一方しか選べないとしたら、どちらが有用でしょうか。

1. 仕事の進め方はキューかスタックか

キューは先に入ったものから順に処理する方式で、FIFO（First In, First Out）とも呼ばれます1。
スタックは後から入ったものを先に処理する方式で、LIFO（Last In, First Out）とも呼ばれます2。

スタックだけに頼ると、新しい依頼が来るたびに優先されるため、古い仕事が下に積まれたまま処理されません。
「後回しの固定化」が起き、未処理の仕事が増え続けます。
緊急対応には向いていますが、通常業務の設計として使うには危ない。

キューは「先に待っていたものが順に進む」という性質を持ち、見通しが立てやすく、他者への説明もしやすいです。
二択ならキューを選ぶ理由はここにあります。

ただし、純粋な到着順にも弱点があります。
重要度の低い仕事が先にあると、重要な仕事が待たされます。
なので実用上は、重要度や締切で並び替えた優先度付きキューが現実に近い。
優先度付きキューは英語で priority queue と呼ばれます3。

1.1. FIFOとLIFOは、優先キューの特殊形

優先キューの動作原理はシンプルで、仕事が1つ終わるたびに「今の時点で最も処理すべきものはどれか」を選び直します。

この視点に立つと、FIFOとLIFOは優先キューの特殊形として統一的に扱えます。

FIFOは「古く入ったものほど優先度が高い」という評価関数を使った優先キューです。
LIFOは「新しく入ったものほど優先度が高い」という評価関数を使った優先キューです。
締切順も「締切が近いほど優先度が高い」という関数に過ぎません。

一般化するとこうなります。

次に処理する仕事 = 評価関数で最も高くスコアされた仕事

並べ方のルールと、次に何をやるかを評価するルールは別の概念ですが、前者は後者の特殊ケースとして包含できます4。

2. 優先度関数の設計問題に置き換える

「仕事をどういう順番で進めるか」という問いは、抽象化すると「各仕事の優先度をどう計算するか」という問題になります。

2. 優先度関数の設計問題に置き換える

形式的には、こう書けます。

priority(task, worker, context) → score

taskは仕事そのもの、workerは担当者や役割、contextは締切・時刻・組織状況・依存関係などの環境情報です。
この関数で各タスクをスコアリングし、最高スコアのものから処理していきます。

入力項目の例として、締切の近さ、影響の範囲、損失リスク、他の仕事への依存、放置時間の長さ、判断の可逆性、必要な工数、今の自分の集中力、相手の都合などが挙げられます。

「緊急・重要」の2軸で分類するフレームワークはよく知られていますが、これはpriority関数の入力を2変数に粗く近似したモデルと見るとしっくりきます5。

priority = f(緊急度, 重要度)  ← 2変数の簡易近似

「重要だとわかっているが動けない」「緊急と重要の区別がつかない」という感覚は、2軸では情報が粗すぎることから来ています。
「重要」の中には、顧客への影響、売上への影響、信用の毀損、将来の選択肢の増減など、性質の異なるものが混在しています。
それらを同じ1軸に押し込むから、判断が迷うのです。

2.1. 重みは人によって違う

priority関数の入力項目が同じでも、それぞれの重みは人・役割・状況によって変わります。

同じタスク群があったとして、営業担当は商談機会や顧客影響を重く見る。
エンジニアは障害リスクや依存関係を重く見る。
マネージャーはチーム全体の停滞や締切を重く見る。
経営層は戦略的重要度や判断の不可逆性を重く見る。
関数の形が違えば、並び順も変わります。

自分がどのパラメータにどれだけの重みを置いているかを意識できるかどうかが、ここでの分かれ目です。

意識しないままでいると、「急かされたもの」「目についたもの」「気が楽なもの」「直近で来たもの」が優先されがちになります。
実質的には無自覚なLIFO、あるいは感情ベースの優先キューになっています。

重みを明示すると、完全に数値化しなくても判断が安定してきます。
「今やるべき仕事」と「今やりたくなっている仕事」を分けやすくなる、というのが実用上の効果です。
厳密なスコアリングが目的ではなく、場当たり的な反応を説明可能な選択に変えることが目的です。

3. 終わらない仕事は設計の出力

すべての仕事をこなせるという前提でワークフローを設計すると、未完了が出た瞬間に「努力不足」「管理不足」の話になります。
しかし実際には、仕事量は処理能力を常に超えがちです。

3. 終わらない仕事は設計の出力

前提を変えます。
「すべて終わらせる仕組み」ではなく、「限られた時間の中で何を処理し、何を処理しないかを決める仕組み」を設計します。

この前提に立つと、時間切れになった仕事は「その優先度設計のもとでは処理されなかった仕事」として説明できます。
未完了は個人の曖昧な反省の対象ではなく、構造として分析できる対象になります。

毎回同じ種類の仕事が時間切れになるなら、その仕事の優先度の重みが低すぎるか、タスク量が処理能力を超えているかのどちらかです。
どちらも、重みづけや仕事量の調整として検討できます。

優先キューで常に高優先度のタスクだけが選ばれ続けると、低優先度のタスクが処理機会を得られなくなります。
これを飢餓状態と呼びます。英語ではstarvationです6。
対策として、時間が経つほど優先度を少しずつ引き上げるエイジングという考え方があります。英語ではagingです7。
実務でも「放置時間が長いほどスコアを上げる」という重みを入れると、古い仕事が永遠に埋もれるのを防げます。

3.1. 捨て方もワークフロー設計

ワークフローの設計で見落とされがちなのは、「何を処理するか」だけでなく「何が時間切れになるべきか」まで含めることです。

優先度関数を明示すること、時間切れになった仕事を記録して重みを見直すこと、そして「この優先度設計ではこの仕事は今週処理されない」と事前に伝えられること。
これらが揃うと、未完了は異常ではなく、設計通りの出力として扱えます。

「仕事の順番をどう決めるか」は、直感や習慣の問題ではなく、自分が何に重みを置いているかという関数の問題です。
その関数を意識することが、仕事の進め方を変える入り口になります。

  1. コンピュータサイエンスでは、FIFOはプリンタのジョブ管理やCPUのタスクスケジューリングなど幅広い場面で採用されています。 – FIFO Principle of Queue – GeeksforGeeks
  2. スタックはプログラム言語の関数呼び出し管理（コールスタック）やテキストエディタの「元に戻す」機能など、直近の状態に素早くアクセスしたい場面で活用されています。 – What Is LIFO (Last-In-First-Out) in IT? | phoenixNAP
  3. 優先度付きキューはコンピュータサイエンスでは抽象データ型のひとつで、ヒープというデータ構造を使って実装されることが多く、各要素の挿入・取り出しをO(log n)の時間計算量で処理できます。 – Priority queue – Wikipedia
  4. 優先度付きキューの理論では、FIFOもLIFOも「優先度の計算方法が異なるだけ」として同じ枠組みで扱えます。この統一的な見方は、スケジューリングアルゴリズムの設計においても基礎的な考え方です。 – Priority Queue | Baeldung on Computer Science
  5. この2軸フレームワークはアイゼンハワーマトリクスと呼ばれ、アメリカ第34代大統領ドワイト・アイゼンハワーが1954年の演説で引用した「緊急なことは重要ではなく、重要なことは緊急ではない」という言葉に由来します。現在の4象限の形式はスティーブン・コヴィーが著書『7つの習慣』（1989年）で体系化しました。 – Avoid the “Urgency Trap” with the Eisenhower Matrix – Todoist
  6. オペレーティングシステムの優先度スケジューリングでも同じ現象が起きます。低優先度のプロセスが高優先度のプロセスに常に先を越され、実行機会を得られない状態を飢餓状態と呼び、indefinite blockingとも言います。 – Starvation and Aging in Operating Systems – GeeksforGeeks
  7. エイジングはOSのスケジューリング理論における標準的な対策で、待ち時間に応じて優先度を段階的に引き上げることで飢餓状態を防ぎます。固定優先度スケジューリングを使う場面では広く採用されている手法です。 – Aging (scheduling) – Wikipedia