範囲・期日・費用の優先順位シート

なぜ3つ全部は取れないのか

範囲を広げれば時間か費用が増え、期日を早めれば範囲を削るか体制を厚くする必要があります。ここまでは多くの方が理解しています。問題は、3つとも固定したまま進めたときに何が起きるかです。多くの場合、明示的に決めていない4つ目の要素、つまり品質が黙って削られます。テストが減り、運用の準備が後回しになり、リリース直後の障害対応に時間を取られます。品質を守るためにこそ、3つのうち動かせるものを先に決めます。

ステップ1: 3つに順位をつける

範囲・期日・費用に1位から3位まで順位をつけます。同率は認めません。1位が「固定するもの」、3位が「最も動かしてよいもの」です。経営者と現場で順位が違うことは珍しくないので、それぞれが個別に記入してから突き合わせてください。ずれた場合、ずれた理由の議論がそのまま前提の確認になります。全員の順位が一致したときは、本当に検討したかを一度疑ってみる価値があります。

ステップ2: 固定する理由を検証する

1位に挙げたものが、本当に動かせないかを確かめます。期日を1位にした場合、その期日を過ぎると具体的に何が起きるかを書いてください。「早いほうがよい」は理由になりません。展示会の日程、契約の更新日、資金が尽きる時期など、動かない事実があるときだけ、期日は固定に値します。費用も同様に、枠を超えたときに何が起きるかを書きます。

• ✓期日が1位: その日を過ぎると何が起きるか（失われる機会、発生する費用）
• ✓費用が1位: 枠を超えると何が起きるか（承認が必要、資金が尽きる）
• ✓範囲が1位: 削れない理由は何か（法令、契約、検証の成立条件）
• ✓どれも「動かない事実」が書けない場合、順位を見直す

ステップ3: 動かす幅を数字で決める

3位に置いたものについて、どこまで動かしてよいかを先に決めます。「必要なら調整する」では、その場の判断になり、結局は揉めます。期日なら何週間、費用なら何割、範囲なら何を諦めるかを、具体的に書きます。ここで決めた幅を超える事態が起きたときが、経営判断を仰ぐタイミングです。幅を決めておけば、その範囲内の調整は現場で完結し、判断のたびに止まらずに済みます。

• ✓期日を動かせる幅（例: 2週間まで。それを超えるなら再検討）
• ✓費用を動かせる幅（例: 当初想定の1〜2割まで。それ以上は決裁が必要）
• ✓範囲を削る場合、最初に外す候補の順番

ステップ4: 範囲を削る順番を先に作る

実際に調整が必要になったとき、その場で削る機能を選ぶと、声の大きい人の意見が通ります。着手前に、機能を「無いと成立しない」「無くても運用でしのげる」「今回は見送れる」の3つに分け、下から削る順に並べておきます。この並びを開発パートナーとも共有しておくと、遅れが見えた段階で先回りの提案が出やすくなります。

ステップ5: 品質の下限を決める

調整の対象にしないものを明示します。動作確認の範囲、個人情報の扱い、障害時の復旧手段など、ここだけは削らないという線を引きます。この線が無いと、締め切りが近づいたときに最初に削られるのが品質です。開発パートナーにも「ここは削らない」と伝えてください。削らない前提が共有されていれば、期日が危ないときに範囲の相談が先に来ます。

• ✓リリース前に必ず確認する動作の範囲
• ✓個人情報・決済など、簡略化しない扱い
• ✓障害が起きたときに戻せる手段（バックアップ、切り戻し）
• ✓引き継ぎに必要な最低限の資料

ステップ6: 変更が起きたときの手順を決める

期中に「この機能も必要だった」と気づくことは、多くのプロジェクトで起こります。悪いことではありません。問題は、その追加が範囲・期日・費用のどれかに跳ね返ることを確認せずに進めてしまうことです。追加の相談が出たら、必ず3つのどれで吸収するかを決めてから着手する、という手順を決めておきます。小さい変更ほど、この確認が省かれて積み上がります。

• ✓追加要望が出たら、誰に相談し、誰が判断するか
• ✓追加による影響（期間・費用・削る機能）を、着手前に必ず文書で確認する
• ✓小さな変更をまとめて判断する場（週次の定例など）を設けるか

決めた内容の共有

このシートは、社内で決めて終わりにせず、開発パートナーにもそのまま渡してください。順位、動かせる幅、削る順番、品質の下限が共有されていれば、相手は状況が変わったときに適切な選択肢を提示できます。なお、費用の目安は範囲・体制・期間によって案件ごとに異なりますので、幅を決める際は相談相手と一緒に検討することをおすすめします。