【QCD】「品質の悪さ」を「納期の遅れ」に変換する

こんにちは！CodeClub965のKです！

今回は、前回の記事の続きです。

前回の記事をまだ読んでいない方は、ぜひ読んでみて下さい。

前回の記事で、

・チームリーダーであればQualityに１番注視するのが良い
・CostやDeliveryは状況が悪くなれば自然と検知ができる
・Qualityだけは気付いた時には手遅れになる可能性がある

といった内容を書きました。

Qualityの悪さをDeliveryの悪さに変換する

チームリーダーであれば、Qualityに対して１番気を配って、悪くなれば手を打っていかなければならないと私は考えます。

しかし、Quality（品質）は可視化するのが難しいものでもあります。
なので、ついつい目に見えやすい納期が優先されてしまいます。

機能面の品質であれば、まだ良いのですが、コードの品質は特に軽視されがちです。

「コードの品質が悪いが、納期に遅れてしまっているので、リファクタリングは今度やる」

このようなシーンは誰しも経験があるのではないでしょうか。
そしてこのような場合、大抵はリファクタリングは一生行われません…。

私はこのようなシーンでは基本的には、コードの品質を担保して、無理に納期に間に合わせようとしないように、チームに働きかけるようにしています。

つまり、「品質の悪さ」はしっかり時間をとって対応するようにして、「納期の遅れ」に変換するようにしています。

品質の悪さは放置すると、そのまま見えなくなってしまうためです。

納期の遅れであれば見えなくなることはありません。

従って、納期の遅れをどうにかしようとチームは考え続けるようになるのです。

結果として、「残業をして納期を間に合わせる」、最悪の場合には「納期を調整する」というような形になってしまうかもしれませんが、少なくともそのまま放置されることはありません。

もちろん、どうしても納期を優先せざるを得ないシーンもあるとは思いますが、私の基本的な考え方は書いた通りです。

ちなみに、Qualityは悪くなると後々Deliveryも悪くなっていきます。
Qualityの悪さに気付いた時には、時間をかけてでもなるべく早く手を打っていきましょう。

最後に

前回、今回とQCDについて書きました。
みんさんが少しでもQCDについて考え、意識してもらって今後のシステム開発に活かせてもらえればと思います。

それでは、また！

Follow me!