仕事をしていると、QCDという単語が良く出てくる。
- Quality(品質)
- Cost(コスト)
- Delivery(納期)
の頭文字をとったものだ。なぜ、これらの単語が3点セットで呼ばれているかというと、これらが3つ巴の関係となっているためだ。
- Qを優先すれば、Cは上がり、Dは延びる。
- Cを優先すれば、Qは下がり、Dは延びる(かもしれない)。
- Dを優先すれば、Qは下がり、Cは上がる。
何かを優先したいなら、何かを犠牲にしなければならないのだ。
プロジェクトが炎上してくると、たいていこのQCDという単語が登場する。QCDすべてを満足できない状況下、何を優先してプロジェクトを進めるべきか、プロマネたちは必死で考えるのだ。筆者の経験では、Qは守る/Cは諦める/Dは交渉、というようなプロジェクトが多かった気がする。
QCDの前にやるべきこと
しかしながら、QCDの検討をする前にやるべきことがある。それは、スコープの議論だ。
スコープというのは、システム開発としてやるべき範囲のことをさす。下記の記事でも説明しているが、要件定義の「定義」を英訳すると「define」となるが、この単語の語源はde(完全に)+finis(境界を決める、終わらせる)である。したがって、「要件を定義する＝完全に境界を定める＝スコープを決める」となり、要件を定義することは、スコープを決めることなのだ。
プロジェクトが炎上してきたら、早めにスコープの議論をすべきだ。議題は「どこまでスコープを削れるか＝どの要件を落とせるか」である。顧客は当然渋るであろう。でも、できないものはできないのだ。正直に説明するしかない。「できます」と言って「やっぱりできませんでした」よりは、「できません」といった方が、お互いの被害は少ない。ただ、単純にできませんといっても顧客の譲歩は引き出せない。「ここまでならできる、これに関してはできない」と言うのだ。これが、炎上中でベンダができる、最も誠実な回答だ。顧客も人間だ。できなくなった理由を説明し、できないなりに誠意を見せた回答をすると、ある程度は譲歩してくれる。それでも納得できないならば、訴訟してもらえばいいだけの話だ。
要件定義を事前にしっかりやっておけば、プロジェクトはもめない
今回言いたいのはここだ。
上記の記事では、要件リストを作成する際に、嬉しさを明記しておくとよいとした。嬉しさを明記しておくことで、優先度が決められるようになる。こうしておくことで、システム開発の進捗が危うくなってきたときに、発注側は、落とす部分を速やかに決めることができるのである。もちろん、落とさずに開発を進められるのがベストではある。あくまでもリスク回避の手段として、優先度が決められるようにしておくことを進める。
たいていの炎上プロジェクトというのは、そもそもの要件定義がしっかりしておらず、かつ、優先度も決まっていないので、あやふやな開発が行われ、時間だけが過ぎた結果炎上するというものだ。
要件定義をしっかり行い、優先度をつけておき、もしもの時は、スコープを削るというやり方することで、顧客側も被害を最小限に食い止め、システムの炎上を最小限に食い止められると、筆者は考える。
