優先順位付けのテクニックはたくさんあり、それぞれ異なる課題を解決するために設計されています。価値と労力に基づいた優先順位付け手法、たとえばRICEなどをすでに使ったことがある方も多いでしょう。意図的に設計したアンケートでターゲットユーザーから学ぶKANOモデルを試した方もいるかもしれません。どの手法にもそれぞれの活用場面があり、多くの有益な意思決定に役立ってきたはずです。
しかし、これらの戦略はより上位レベルの優先順位付けを想定しています。つまり、機能Aと機能Bのどちらを先に実装すべきか、あるいは機能Cが次のバージョンに本当に必要なのかといった判断です。しかし、タスクやサブタスクのレベルにはスケールしません。そのため、特定の機能の中でやりすぎてしまう可能性があります。また、早期にフィードバックを得るためにいつユーザーの手に渡せるかという問い――リーンスタートアップ手法のようなユーザー重視のアプローチ――にも答えてくれません。スケールに依存しない手法、たとえばMoSCoWメソッドを選ぶこともできますが、そのカテゴリは抽象的すぎて、人によって各カテゴリへの期待が異なるため、評価が難しくなります。
Laser Focus 優先順位戦略の目標は、明確な評価カテゴリを提供し、タスクスコープの管理を支援し、解釈しやすい方法を提供することです。この3つの側面が組み合わさることで、レーザーのような集中力を保てます。
Laser Focus カテゴリ
カテゴリで達成したい目標は3つあります：
現在計画しているリリースのスコープ内にあるタスクを決定する。
AlphaやBetaバージョンに必要なタスクを他のタスクよりも高い優先度にする。
カテゴリ名自体が、行動につながる自己完結した意味を持つ。
すべての要件を満たす以下のカテゴリを提案します：
Vital（不可欠）
最初のテストに必要な絶対最小限。見た目は粗くてOK。
「Vital」の機能やタスクだけを実装した段階で、小規模なテスターグループに製品を出荷して早期フィードバックを得ることができます。もちろん、このAlphaテストのスコープは明確にして、まだ不足している基本機能やタスクを伝える必要があります。そうすればテスターが不要な報告をすることを防げます。ただし、製品や機能の核心部分はすでにテストでき、正しい方向に進んでいるかどうかの最初のフィードバックを得られます。
Essential（必須）
基本的な機能に必要な中核的要素。粗削りな部分があってもOK。
すべての「Essential」機能やタスクが実装されたら、2回目のより大きなテストラウンドを開始できます。このレベルでは特定のテストスコープを伝える必要はなく、基本機能は揃っているがまだ多くのものが不足または不完全な「Beta」バージョンと呼ぶだけで十分です。
Completing（完成）
粗削りな部分を磨き、機能を完成させる。
「Completing」レベルは、最終製品がリリース可能になるスコープを定義します。場合によっては、例えば特定の日にリリースが告知されている場合、一部の「Completing」タスクが未完了でもリリースは可能ですが、その場合は公に「Beta」と明記すべきです。通常、このレベルにはより大きなユーザーベースにとって重要だが、製品の核心を評価するためには関係ないすべての機能やタスクが含まれます。
Optional（任意）
あると嬉しいが、後のバージョンに延期したり完全にスキップできるもの。
「Optional」レベルは、そう評価された機能やタスクは望ましいものの、長期的に見ても製品のファイナライズに一切必要ないという意味を持ちます。したがって、チームのリソースに応じて簡単に延期したり削除したりできます。
Retracting（撤回）
一見良さそうだが、改善よりも害をもたらす可能性があるもの。
「Optional」とは異なり、「Retracting」と評価された機能やタスクは積極的に避けるべきです。なぜ避けるべきかの理由とともにどこかに記録しておくことが有意義です。将来同じアイデアが再浮上した際に時間を節約できます。また、複数の人が評価に関わっている場合、タスクの製品への影響について議論が必要な箇所を特定するのにも役立ちます。
Laser Focus マトリクス
Laser Focus 戦略の第2の柱は、その多次元的なスケーラビリティです。これが何を意味し、なぜ重要なのかを説明するために、ここまでのカテゴリを例に適用してみましょう。1日を通して行うさまざまな作業の時間を記録するストップウォッチアプリを開発するとします。以下は機能アイデアの初期リストで、Laser Focus カテゴリで評価しています：
プロジェクトを作成する → Essential（アプリに不可欠だが、プリセットのプロジェクトで最初のテストには十分）
プロジェクトを編集する → Completing（テスト目的には不要だが、最終リリースには必要）
プロジェクトを削除する → Completing（整理タスク。テスト目的には不要だが、最終リリースには必要）
タイマーの開始/停止 → Vital（アプリの核心的アイデア、不可欠な部分）
タイマーのプロジェクトを選択する → Vital（プロジェクトを選択しないとアプリの目的が果たせない）
過去の記録時間を編集する → Retracting（V2で競合機能を予定、不正のリスクあり）
過去の記録時間を削除する → Optional（あると便利、時間の追加ではないので不正リスクなし）
選択したプロジェクトの履歴時間を表示する → Essential（アプリの中核ユースケース）
最も多く記録されたプロジェクトを表示する → Essential（アプリの中核ユースケース）
カテゴリ分けのおかげで、最初のリリースから2つの機能を除外でき、おそらく実装すべきでない機能（6）も認識して恒久的に記録できます。さらに重要なのは、4と5が最初に実装すべき「Vital」機能だとわかったことです。
それでは、これらのサブタスクに取り掛かりましょう：
4. タイマーの開始/停止：（Vital）
a. 開始/停止ボタンのレイアウトをデザイン（低忠実度） b. 開始/停止ボタンの色・アイコンをデザイン（高忠実度） c. 開始/停止ボタンのパルス影エフェクトをデザイン（アニメーション） d. 開始/停止ボタンのレイアウトを実装（低忠実度） e. 開始/停止ボタンの色・アイコンを実装（高忠実度） f. 開始/停止ボタンのパルス影エフェクトを実装（アニメーション） g. 基本的な記録時間のデータベースモデルをセットアップ h. 開始/停止アクションをデータベースに永続化
5. タイマーのプロジェクトを選択する：（Vital）
a. プロジェクトセレクターのナビゲーション＆レイアウトをデザイン（低忠実度） b. プロジェクトセレクターの形状・色・アイコンをデザイン（高忠実度） c. プロジェクトセレクターのナビゲーション＆レイアウトを実装（低忠実度） d. プロジェクトセレクターの形状・色・アイコンを実装（高忠実度） e. 選択したプロジェクトを記録時間のデータベースモデルに永続化
さあ、始めましょう！……ですよね？
いいえ。読み進めながら気づいた方もいるでしょう。問題があります。テスト可能にするために本当に必要なものは何かを考えて機能の優先順位を付けました。しかし今、同じ問題が別のレベルで再び発生しています。これらのタスク（そしてそのサブタスクも）がすべて、ユーザーの手に渡す最初のバージョンにとって「Vital」というわけではありません。これをどう修正すればいいのでしょうか？タスクにも別の評価を適用すべきでしょうか？
はい、間違いなく！これは実際にLaser Focus戦略の要件です：すべてのレベルで評価を適用することです。上位レベルでは他の優先順位付けテクニックを使っても構いませんが、開始地点から下のレベルはすべてこの方法で評価すべきです。
タスクにもLaser Focusカテゴリを割り当てて、全体の優先度にどう影響するか見てみましょう：
4. タイマーの開始/停止：（Vital）
a. 開始/停止ボタンのレイアウトをデザイン（低忠実度） → Vital b. 開始/停止ボタンの色・アイコンをデザイン（高忠実度） → Completing c. 開始/停止ボタンのパルス影エフェクトをデザイン（アニメーション） → Optional d. 開始/停止ボタンのレイアウトを実装（低忠実度） → Vital e. 開始/停止ボタンの色・アイコンを実装（高忠実度） → Completing f. 開始/停止ボタンのパルス影エフェクトを実装（アニメーション） → Optional g. 基本的な記録時間のデータベースモデルをセットアップ → Essential h. 開始/停止アクションをデータベースに永続化 → Essential
5. タイマーのプロジェクトを選択する：（Vital）
a. プロジェクトセレクターのナビゲーション＆レイアウトをデザイン（低忠実度） → Vital b. プロジェクトセレクターの形状・色・アイコンをデザイン（高忠実度） → Completing c. プロジェクトセレクターのナビゲーション＆レイアウトを実装（低忠実度） → Vital d. プロジェクトセレクターの形状・色・アイコンを実装（高忠実度） → Completing e. 選択したプロジェクトを記録時間のデータベースモデルに永続化 → Essential
ここで重要なのは、タスクの評価の基準値は直接の親である機能であるという点です。つまり、「開始/停止アクションをデータベースに永続化するのは、機能『タイマーの開始/停止』にとってVitalなのかEssentialなのか？」と自問したのであって、アプリ全体やその他の基準ではありません。こうすることで、判断がずっと簡単になります。
この2つの異なるレベルの評価をシンプルなマトリクスで可視化しましょう。X軸に機能の評価、Y軸にタスクの評価を配置します。丸はタスクを表しています：
ご覧の通り、タスク4a、4d、5a、5cは左下のフィールド、「Vital-Vital」フィールド、略して「VV」にあります。このフィールドの背景は赤色で着色されています。最初に集中すべきすべてのタスクが含まれています。これらがすべて実装されたら、最初のテストラウンドを開始でき、Alphaフェーズが始まります。
黄色で着色された「Vital-Essential」フィールド（略して「VE」）のタスク4g、4h、5eは次に取り組むべきです。3つの黄色フィールド（VV、VE、EV）のすべてのタスクが完了したら、Betaフェーズが始まります。
「VC」フィールドの「Vital」機能に対する「Completing」タスクは、ここまで定義したタスクの中で最後に取り組むべきです。すべての緑色フィールド（VC、CV、EC、CE、CC）のタスクが完了したら、リリースの時です。
上の例では、Vital以外の機能のタスクは省略しました。それらも評価していたら、「Retracting」評価も含めた完全なマトリクスは次のようになったでしょう：
Alpha、Beta、リリースのタスクが原点（左下隅）を中心に円形にレイヤー化されているのがわかります。原点からの距離に基づいて、各タスクの優先度が視覚的にわかります。これは、例えば各タスクにサブタスクが追加された場合、3番目の軸にも簡単に拡張できます。形式的には、任意の次元数にスケールします。最下位レベルの要素の全体カテゴリを計算するには、すべての祖先を調べて、最も低い優先度を全体カテゴリとして選択するだけです。例えば、あるサブタスクが「Essential」、親タスクが「Vital」、その親機能が「Completing」と評価されている場合、最も低い優先度は「Completing」なので、このサブタスクの全体カテゴリは「Completing」です。
全体カテゴリの計算だけでは、特に5つの異なるフィールドがある「Completing」では、多くのタスクが同じレベルになる可能性があります。同じカテゴリ内で機能やタスクの優先順位を付ける方法は、自身のカテゴリとすべての祖先のカテゴリの平均を計算することです。各カテゴリに数値を割り当て（1=「Vital」から5=「Retracting」）、最下位レベル（例：サブタスク）はタプルで表現できます。例えば上の例では(2, 1, 3)です。平均は(2 + 1 + 3) / 3 = 2.0と計算します。同じ全体カテゴリ「Completing」で、より多くの祖先を持つ別のタスクは(3, 2, 3, 1)と評価され、平均は(3 + 2 + 3 + 1) / 4 = 2.25となるため、優先度は低くなります。全体平均が高いほど優先度が低くなる――原点からの距離にほぼ対応するので、とても理にかなっています。
ただし、実際にこれらの平均を計算する必要はありません。上で見たマトリクスに基づく、十分な精度のより簡単な方法があります：
上の図は、原点からの距離に基づいてフィールドをどの順序で処理すべきかを示しています。2位、4位、5位にそれぞれ2つのフィールドが配置されていることに注目してください。これらのフィールドについては、状況によって異なる選択をする必要があります：より多くの機能を追加することに集中すべきか？それともすでに着手した機能の改善に集中すべきか？機能の拡張を先にするなら、「Feature category」の方向に進むべきで、例えば「VE」の前に「EV」を処理します。既存機能の改善を先にする場合は逆順です。
Laser Focus ブレイクダウン
前のセクションで、複数レベルでのカテゴリ分けがLaser Focusの概念の鍵であることを学びました。これを自分のプロジェクトにすぐ適用しようとすると、多くの、あるいはすべての機能やタスクが「Vital」か「Essential」になってしまうことに気づくかもしれません。これは、タスクの分割が効率的でないことを示すサインです。
だからこそ、カテゴリ分けの前に正しい方法でタスクをブレイクダウンすることが重要です。機能をタスクに、またはタスクをサブタスクに分割する際の指針となる質問は、「完成させるためにどんなステップが必要か」だけに限定すべきではありません。各ステップの労力も考え、労力が無視できないほどある場合は、分離することを検討すべきです。時にはそれが難しく感じることもありますが、多くの場合、「まず動くようにしてから、改善する」というアプローチに従ってタスクを分割するのが良いアイデアです。
例えば、上の機能「タイマーの開始/停止」は3つのタスクに分割できました：「開始/停止ボタンをデザインする」「開始/停止ボタンを実装する」「データを永続化する」。しかしこれでは完成度の異なるレベルがありません。さらに細かく分割する方が良いのです。もちろん、これらのタスクの下にサブタスクとして追加することもできますが、優先度の計算を簡単にするために、より少ないレベルで行うことをお勧めします。そこで代わりに「開始/停止ボタンのレイアウトをデザイン」「開始/停止ボタンのレイアウトを実装」、そして同じ2つのタスクを「…色・アイコン」と「…パルス影エフェクト」でも作成しました。
各パートが独自の労力を持つかどうかを自問し、必要な労力に基づいて優先順位付けする価値があるようにタスクを分割しましょう。マイクロタスクは分離せず、別のタスクの一部として残しましょう。優先順位付けするほどの小さなタスクではないからです。
適切なブレイクダウンは、Laser Focus戦略を効果的にするために非常に重要です。
まとめ
Laser Focus 優先順位戦略を正しい順序でまとめましょう：
機能やタスクを異なる完成度レベルのより小さなステップにブレイクダウンする
各レベルで「Vital」「Essential」「Completing」「Optional」「Retracting」で評価する
すべての祖先を考慮して、最下位レベルの全体的な優先度を可視化または計算する
プロジェクトの任意の時点でこれらのステップを適用すれば、重要なことに集中し続け、合理的なタイミングで作業中のバージョンを自信を持ってユーザーの手に届けることができるでしょう。