トレードオフ
「何かを得るためには、別の何かを諦めなければならない」という二律背反の関係性のこと。Web プロジェクトにおいては、QCD と呼ばれる「品質(Quality)× 予算(Cost)× 納期(Delivery)」のバランスをはじめ、「機能の多さ × 公開までのスピード」「デザインの自由度 × 運用時の保守費用」など、あらゆる場面にこのジレンマが存在する。完全な正解はなく、「何を選び、何を捨てるか」のセットを持てるかが、プロジェクトの成否を決める。
運用の要点：「やらないこと」を決める現実主義のディレクション
担当者に求められるのは、「やらないことを明確に決断する」というシビアな姿勢。制作業者との値引き交渉でも、「仕様はそのままで金額だけ下げて」という要求は破綻を招く。「予算を削るなら、代わりにこの機能を削る(あるいは公開日を 1 ヶ月延ばす)」といった等価交換のカードをセットで提示するのがプロの基本。実務の会議では、「全部やりたい」というフワッとした感情のまま議論を引き伸ばさず、「スコープ(実装する機能や対応範囲)・予算・期間の 3 軸のうち、今回はどれを最優先にし、どれを妥協するか」を明確に突きつけ、意思決定マップに乗せる。さらに、後で社内から蒸し返されないよう、議事録に「選んだ理由と、諦めた理由」を必ず 1 行残しておくのが鉄則(優先度の低い機能はフェーズ 2＝MVP思考に回すのも定石)。
現場でよくある「落とし穴」
- 「全部盛り」の強要が招く、公開日の大炎上(品質の犠牲)：担当者が「予算は増やせない、公開日も絶対にズラせない、でもあの機能もこの機能も全部入れて!」と、トレードオフを無視した無茶な要求を業者に押し通してしまう。悲惨な末路として、予算と納期を固定された業者は、スケジュールに間に合わせるために「画面からは見えない裏側の品質(セキュリティ対策、ブラウザの表示テスト(公開前チェック)、コードの整理など)」をこっそり削って納品する。結果、公開初日に致命的なバグが多発したり、個人情報が漏洩したりと、取り返しのつかない大炎上事故を引き起こす。
- 経営層への「お伺い」によるプロジェクトの停止：課題を表面化させたものの、「どの機能を削るかの優先順位は社長が決めることだから」と判断を上に投げ、担当者としての意思決定が止まってしまう(担当者自身が「私はこれを削るべきだと考える」という意思を持つ必要がある)。
言葉をよく利用する人
- Web 担当者(発注側)
- プロデューサー
- ディレクター
- 経営層
- マーケター
会話上での使用例
経営層が「採用も EC も多言語も全部やる」と言い出した場面
-
経営層
今回のリニューアルは採用も EC も多言語対応も、全部やってしまおう。優先順位はあとから決めればいいだろう。
-
Web 担当者
気持ちはわかるのですが、全部に手を広げると、どれも中途半端になってしまうトレードオフがあります。まずは優先する 2 つを先に決めて、3 つ目はフェーズ 2 に回しませんか。
-
経営層
なるほど。では今のスコープ・予算・期間で何を取って何を諦めるか、次回の会議で整理しよう。
業者に値引きを相談する場面
-
Web 担当者
見積もりなのですが、できれば 2 割ほど下げていただきたくて。
-
業者ディレクター
金額だけ下げるのは難しいですが、品質か期間とのトレードオフで考えれば調整は可能です。たとえば採用ページをフェーズ 2 に回す、修正回数を 5 回から 3 回にする、写真素材を御社支給にする、このあたりで等価交換にできますよ。
-
Web 担当者
それなら社内でも通しやすいです。その 3 つで再見積もりをお願いします。