デグレードとは何か？デグレ・先祖返りとも呼ばれる開発のミスの内容と防止法を解説
デグレード（先祖返り）の概要
デグレードとは開発用語の１つで、デグレードやデグレとも呼ばれ、修正前の状態に戻ることから「先祖返り」と呼ばれることもあります。
デグレードはプログラムや資料を修正した後、修正前と比べて品質が劣る、または劣る部分が発生することを示します。
デグレードの発生を防止するには、開発チーム内での密な情報共有やソースコードをしっかり管理すること、テストの自動化などが主な解決策に挙げられます。既存の機能が問題なく使えるか確認する「リグレッションテスト」の実施も有効です。
デグレードは必ずしもプログラムだけを対象にしたものではありませんが、今回はプログラムの場合を中心にデグレードを解説していきます。
なぜデグレードを防ぐ必要があるのか
デグレードを防ぐことはシステムの利用者（ユーザー）だけでなく、システムの開発側にとっても極めて重要です。
その理由は、以下の３点にまとめられます。
- ユーザーから信頼を得た上で、安心してシステムを使い続けてもらうため
- デグレード防止に関わるシステム現場の負担や、コストを増やさないため
- 他社との競争に勝ち抜くため
デグレードが問題である１番目の理由は、ユーザー側に関わる視点です。
そもそもシステム更新により不具合や機能改善が行われるはずが、逆に「今まで使えていた機能が使えなくなった」というのでは、安心して更新作業を任せることができません。
システムの変更に対し慎重になりすぎると業務を効率化する機能の採用も慎重にならざるを得ず、ユーザーに不利益をもたらす結果になってしまいます。
デグレードが問題である２番目の理由は、システム現場に関わる視点です。
過去にデグレードが発生したシステムでは、ユーザーから「今使える機能は、システム更新後も使えるように」という要望が出されることは当然といえるでしょう。
このような要望にこたえるため、リグレッションテストを広範囲に実施する必要があります。結果として多くの開発現場では開発者の残業など人的負担が増すか、人員の追加採用によるコスト増のどちらかを迫られることになります。
このため、デグレードを出すと、その後の開発でプロジェクトメンバーの疲弊か利益の減少のどちらかは避けられず、プロジェクトの痛手となります。
デグレードが問題である３番目の理由は、両者に関わる視点です。システム開発を組織内で対応できる企業・団体も増えてきましたが、まだ多くの組織が外部のベンダーに依頼し、対応しています。
依頼したベンダーが開発したシステムに頻繁にデグレードが発生すると、ユーザーは他社のシステムに乗り換えようと思うかもしれません。
また上述の通り、デグレードは開発現場の負担を増加させるものであるため、頻繁に発生すると開発現場の競争力が失われていきます。ベンダーとして、システム開発の競争力をアップするためにも、デグレードの防止は欠かせません。
デグレードはどのような場合に起こりがちなのか
デグレードの一例として、あるシステム開発において、以前解決したはずのエラーが、別のエラーの修正後に復活してしまったというものが挙げられます。
このように、デグレードはシステムに手を加えることで発生するため、以下のように開発や保守、構築といった段階で混入する可能性があります。
- 機能追加や機能改善など、システムのアップデート
- トラブルへの対応
- 機器のリプレース
上記のように、システムに何らかの手を加える限り、デグレードが発生する可能性は存在します。
そのなかでも以下にあげるケースでは、デグレードが発生しやすいため、注意が必要です。
- ソースコードのバージョン管理や、変更部分の管理が行われていない
- ドキュメントの不備が放置されている。または適切な更新がされていない
- 修正部分や影響範囲の情報共有を行っていないなど、チーム間のコミュニケーションが不十分
- システムが大規模、かつ複雑
- 機器の入れ替えなど、インフラの更新が行われる
修正や機能強化は、最新のソースコードに対して行うことが重要です。バージョン管理ソフトや変更部分の管理を行うことで、防ぐことが可能です。ドキュメントも最新の状態に更新しておきましょう。
加えて多くのシステムはいくつかのサブシステムに分かれ、複数のチームで開発が進められています。他のサブシステムから呼び出される機能は見落としがち。特にシステムが大規模になるほど、その構造も複雑になります。このため、チーム間のコミュニケーションを取ることがデグレードを防ぎます。
このほか、インフラの更新もデグレードの原因として見逃せません。特に機器そのものが変わる場合は、改めて機器やOSなどの設定を行わなければなりません。誤った設定を行えば、デグレードに直結します。インフラの担当者は、細心の注意を払うことが必要です。
デグレードが発生する原因と防止法
デグレードが発生する主な原因
デグレードで起こる事象は、いずれもユーザーの業務に悪影響を与えるため、システム開発を行う者はその発生を防止しなければなりません。
これまでデグレードが発生するケースを紹介してきましたが、デグレードが発生する原因は簡単に２点にまとめられます。
- 編集するファイルについて、組織内で情報共有ができていない
- ファイルのバージョン管理ができていない
以下、これら２つの点に注目し、デグレードの防止法をお話ししていきます。
組織内で情報共有する
デグレードが発生する主な原因は組織内で情報共有ができていないことです。
例えば、Xというファイルがあったとします。エラーの報告を受けたプログラマーAさんがファイルXのコードを修正し始めたとします。
その後、別のエラーの報告を受けたBさんが同じファイルXのコードを自分のPCで編集し始めました。
このような状態だと、Aさんがエラーを修正し、そのファイルをリリースしても、Bさんがエラーを修正した後で自分のファイルをリリースしてしまえば、ファイルが上書きされ、Aさんの修正内容は消えてしまい、デグレードが発生してしまいます。
こうした状況を防ぐためには、Aさん、Bさんをはじめ、組織内で修正内容を共有し、「同じファイルXのエラーであるならば、Aさんにすべてお願いする」「Aさんが修正した後に、Bさんが対応を始める」などの対応を検討できるようにしなければなりません。
最近では社内の情報共有のため、Slackなどのツールを導入することも多くなってきましたが、このようなツールを使って積極的に情報共有をしていきましょう。
バージョン管理をする
デグレードが発生する２番目の原因は、バージョン管理をしていないことです。
組織内で情報共有を徹底させても、時には誰かが編集中のファイルに手を加えてしまったり、ローカル環境に残されている過去に修正したファイルをそのまま利用したりして、デグレードを発生させてしまうことがあります。
このようなヒューマンエラーを防ぐためには、バージョン管理ツールを導入することをおすすめします。
バージョン管理ツールとして最近ではGitHubが有名ですが、バージョン管理ツールはファイルを管理し、ファイルの履歴や最新バージョンのファイルの取得を助けてくれます。
このバージョン管理ツールを導入すれば、最新バージョンのファイルで作業をしやすくなり、バージョンの違いに気づきやすくなります。
また、たとえデグレードが発生したとしても、ファイルの履歴をバージョン管理ツールが保存してくれているため、問題の発見や、修正が容易になります。
個人の意識も大切
以上のように、デグレードが発生する原因を踏まえると、その防止法も明らかになってきます。
ここで忘れてはいけないのが、情報共有ツールやバージョン管理ツールを使ったとしても、使用する人にデグレードの発生を防止しようという気持ちがなければ、対策も形骸化してしまうということです。
プログラマーだけでなく、彼らを統括するテクニカル・ディレクターやプロジェクト・マネジャーなども含め、システム開発をしている組織やチームが「デグレードを無くそう」という意識のもと、ファイルのバージョンの違いに気を付けていくことが大切です。