三ツ星★★★人生

勢いで会社を辞めた元女SEのその後

品質、費用、納期。エンジニアが最優先すべきは?

結論から言うと、エンジニアが最も優先すべきは「品質」です。

 

Quality(品質)、Cost(費用)、Delivery(納期)は相反する

品質を高めようとすると、費用、時間(納期)が増えます。
納期や費用を優先すると、品質が低下します。

全てが合格点に達していれば何も問題ありませんが、
状況がひっ迫してくると、マネージャーは苦しい選択を迫られることになります。


たとえば、リリース直前に大きなバグが見つかった場合。
影響範囲が大きく、それを洗い出すだけでもかなりの工数を消費してしまいます。
たとえ改修できても、影響範囲全てを完璧にテストしていては納期に間に合いません。

こんな時、あなたならどうするでしょうか?

1.品質重視の場合
・顧客に追加でお金をもらって人を増やす。(費用↑)
・納期を伸ばしてもらい、テストをやりきる。(納期↑)
・あるいはその両方(人を増やして納期も増やす)

 

2.費用重視の場合
・今の体制でできる範囲のテストだけやって、リリースする。(品質↓)
・納期を伸ばしてもらい、追加請求なしでやりきる(納期↑)

 

3.納期重視の場合
・とにかく、納期を守ってテストが終わっていようがいまいが、リリースする。(品質↓)
・人数を増やしてできるだけテストをして、納期通りリリースする。(費用↑)

 

みなさんもご承知の通り、どれが正解、というのはありません。
状況に応じて柔軟に判断するしかありませんし、
この判断をどれだけ考えて結論するかが、マネージャーの存在価値を決めるといっても過言ではありません。

 

しかるべき機会を逃すと全く意味がなくなってしまうようなコンシューマー向けのサービスや製品だったら、納期を優先すべきです。

FXのWebサービスや銀行の基幹システムのような「お金」に直接関与するもの、医療関係の「命」に関与するものの場合、何をおいても品質を重視すべきです。

数年しか使わない臨時福祉給付のシステムのようなものであれば、いかに開発コストを下げるかに注力すべきです。


では、なぜ「最優先すべきは品質」なのか?

理由は、「品質」が最も定義しにくいからです。

 

納期は最もわかりやすいですね。
「○月○日にリリース」「△月△日までにドキュメントを提出する」みたいに。
ほとんどの場合、最初の契約時点で定められており、契約書にも明記されています。

 

二番目が費用。
場合によっては少々ぼやかして、「○人以内の体制で」とか
「○万円~△万円」のように金額レンジだけ決める場合もあります。

 

最後に品質。
これは明確に定義することはほとんど不可能です。
バグ○個以内ならOK、みたいに決められないし(そもそもバグの数なんて日々変動するし)
テストユーザが触って問題なかったらOK、というのもユーザのレベルや主観によって変わってきます。


この順番でマネジメントをすると、品質が最もおざなりになるわけです。
結果、納期、費用は顧客の要求通りだったとしても、バグだらけでまともに動かなかったり、使いにくすぎて全く利用されなかったり。。。
最悪の場合、瑕疵対応(無償対応)、場合によっては損害賠償請求に発展することもあります。


よって、エンジニアは「意識的に品質を最優先する」くらいで
ちょうど良いQCDのバランスを取ることができるのです。