開発の手戻り

  • SmartBee

最終更新⽇:

掲載⽇:

プロジェクトを進めていくと開発したはずの部分に手戻りが発生している場合があります。
所謂デグレというものです。
正式な呼び名としてはデグレードで【degrade】と書きます。
あるソフトウェアの開発をし、バージョン更新を行った際に品質が、更新前よりも悪くなってしまう現象を指します。
また、修正したはずのバグや不具合が再発・復活したり、新しいファイルを古い内容で宇和がいてしまった際もこの言葉を使用します。

この何故か発生してしまうデグレですが、大まかな原因としては新しく開発した部分のテストやデバッグが不十分なため発生するものです。

開発の体制としては基本的に管理者が前に立ち、その下に複数人の開発者がつく形をとります。
開発は管理者が要件をまとめ、それをもとに仕様書を起こします。
開発者は仕様書の通り開発を行っていくわけですが、開発が終わった段階でのテストがポイントとなります。

開発担当者は少なくとも手元のローカル環境にて動作確認を行い、ほかのメンバーとソースを共有するわけですが、その開発で影響のありそうな他の場所に不具合が出ていないかを確認することを怠る場合があります。

管理者は顧客とのやり取りを行うほか、開発者が行った開発内容の確認が必要でこれを逐一見ていきます。
確認ポイントとしては主に修正、追加を行った項目が要件を満たしているか、仕様通りの動きになっているかというところですが、この際他の関連しそうな箇所に影響が出ていないかも見ます。
しかし、際限なく見てしまうとただでさえ顧客との折衝がある管理者のリソースが足りなくなります。
特に管理者は一つの案件のみを見ているわけではなく複数兼任していたりと仕事内容は多岐にわたります。
そのため、ある程度は開発者の中で完結する必要があり、これがデグレの原因となるのです。

これらの解決方法として考えられるものはいくつかありますが、簡単に思いつくものは管理者の数を増やすということです。
多対一になりがちな業務の負担を減らすことで開発メンバーを見る時間を増やすことができます。

次に、中間層のメンバーを増やすという方法、開発を直接管理者が見るのではなく中間に1名置き、そのメンバーが開発の品質を保つという方法です。

とは言えこの様な方法も一時的なもので、恒久的なものとなるとやはり何かしら策を講じる必要がありそれが企業そのものの力になってくると考えます。

何にせよデグレが発生しないようにするには管理者だけでなく全体で検討することが大事になります。