新規事業の現場で、私はよくこんな光景を目にします。 膨大な機能リストが並んだエクセル。その全ての行に「優先度：高」と記されている仕様書。そして、「これら全てが実装されなければリリースできない」と主張するビジネス担当者。
断言します。「全て重要」とは、「何も考えていない」のと同じです。
リソース（予算・時間・人員）は有限であり、市場の要求（欲望）は無限です。このギャップを埋めるのは、気合や根性ではなく、冷徹なまでの「引き算の論理」です。 今回は、成功するプロジェクトだけが実践している**『動的優先順位マネジメント（Dynamic Prioritization）』**について解説します。
1. 「仕様書」ではなく「価値創造リスト」を作る
従来のプロジェクト管理では、分厚い「要件定義書」を作成し、それをすべて実装することをゴールとしました。しかし、プロジェクトが進むにつれて「あれも必要だった」「この機能は実は要らなかった」という事態は必ず発生します。
そこで私が推奨するのは、静的な書類の代わりに、生きた**「価値創造リスト（Value List）」**を持つことです。 （※アジャイル開発における「プロダクトバックログ」に相当する概念ですが、より経営視点で捉え直します）
このリストには、以下の3つのルールがあります。
- 顧客への提供価値で書く 「ログイン画面を作る」ではなく、「顧客が安全に自分のデータにアクセスできる」と記述します。機能（Function）ではなく価値（Value）で定義することで、手段の柔軟性が生まれます。
- 上にあるものほど具体的、下は抽象的 直近で着手する項目は詳細に詰め、数ヶ月先の項目は「ワンフレーズ」程度に留めます。どうせ状況は変わるため、未来のことに詳細な定義時間を割くのはムダだからです。
- 強制的に順位をつける 「同率1位」は認めません。1番から100番まで、必ず一列に並べます。
2. リーダーの最大の仕事は「捨てること」
このリストを管理する責任者（ビジネスリーダー）に求められる最大の能力。それは「何を作るか」を決めることではなく、「何を作らないか」を決める勇気です。
パレートの法則（80:20の法則）は、ソフトウェア開発にも当てはまります。顧客が得る価値の80%は、全体の20%の機能から生み出されます。残りの80%の機能は、実は「あったらいいな（Nice to have）」レベルのものであり、必須ではありません。
成功するリーダーは、リストの下位80%を勇気を持って切り捨て、上位20%の磨き込みにリソースを集中させます。 「念のために入れておこう」という機能が、開発スピードを落とし、システムを複雑にし、結果としてバグの温床となるのです。
「やらないこと（Not To Do）」を明確にすること。 これこそが、最短でPMF（プロダクト・マーケット・フィット）に到達する唯一の道です。
3. 朝令暮改こそが正義である
「価値創造リスト」は、一度作って終わりではありません。 市場環境の変化、競合の動向、あるいは先行リリースのフィードバックを受けて、毎日のように順位を入れ替える必要があります。
「先週はA機能が最優先と言ったが、市場調査の結果、B機能の方が緊急度が高くなった。だからAを下げてBを上げる」
これはブレているのではありません。学習しているのです。 この優先順位の入れ替え（リ・プリオリタイゼーション）を、開発チームと定期的に同期すること。これさえ出来ていれば、開発現場は「また言うことが変わった」と疲弊するのではなく、「ビジネス価値が高い順に作業している」という納得感を持って動くことができます。
4. ROI（投資対効果）で判断する
優先順位に迷ったとき、判断基準となるのは「声の大きさ」や「政治力」ではありません。**ROI（Return On Investment）**です。
- その機能を作るのにどれくらいのコスト（開発規模）がかかるか？
- その機能を作るとどれくらいのビジネスインパクト（売上・削減効果）があるか？
「コストは低いがインパクトは絶大」なものが最優先です。逆に「コストは莫大だがインパクトはそこそこ」なものは、後回しにするか、簡易的な代替手段を検討すべきです。 次回の記事で詳しく解説しますが、この判断を行うためには、開発チームによる「規模の見積もり」が不可欠となります。
まとめ：意思決定という責務を果たせ
エンジニアに対して「全部作ってくれ、期限は守ってくれ」と言うのは、マネジメントの放棄です。 「リソースはこれだけしかない。だから、今回はこの3つに絞る。残りは次のフェーズに回す責任を私が負う」と言い切るのが、ビジネスリーダーの仕事です。
動的な優先順位付けは、組織の新陳代謝を高めます。 次回は、この「優先順位判断」の精度を劇的に高めるための技術、**『なぜあなたのプロジェクトは常に遅れるのか？ 「相対見積もり」で不確実性を可視化する』**について解説します。
コメント