デグレとは？デグレ発生の原因と起こさないための対策
「デグレ」と聞いても、ITエンジニア以外の人は、何のことやらと首を傾げるばかりではないかと思います。どんな意味なのか、何の言葉の短縮形なのか、きっと想像もつかないのではないでしょうか？
ですが、ITエンジニアにとっての「デグレ」は、自分のいるプロジェクトでは絶対に耳にしたくない、それなのに「業界あるある」と言わざるを得ないくらい頻繁に発生してしまうトラブルを表す業界用語なのです。しかも、そのトラブル原因のほぼ9割が「人的ミス」に因るものなのですから、始末に負えません。
本稿では、「デグレ」とは何か？という根本的な疑問に答えつつ、「デグレ」が発生する原因、対策、そして、「デグレ」が発生するとどんな怖ろしいことが起こるのかについて、筆者の恐怖体験も含めてお話しようと思います。
１．「デグレ」とは何か？
「デグレ」とは、ずばり「デグレード(degrade)」を略したIT用語です。
それでは、「デグレード（degrade）」とは何かと言えば、「低下する、落ちる」を意味する接頭語の「de」と「等級、階級」を意味する「grade」がくっついた英単語なのです。そして、IT業界における「デグレード（degrade）」とは、システム開発におけるプログラム修正やインフラ設定の変更等により、それまで正常に動作していた機能が動かなくなるという、品質低下のトラブル事象を指します。
ちなみに「デグレード(degrade)」は、日本のIT業界でしか通じない特殊な業界用語です。同じ事象のことを、英語では「リグレッション(Regression)」と呼びますが、日本では何故か「デグレード(degrade)」で定着してしまいました。本稿も、以降は略称である「デグレ」で統一して表記します。
「デグレ」は、その発生元により凡そ以下の3つに分類することができます。
１-１．プログラム修正により発生する「デグレ」
まずひとつめの「デグレ」は、プログラムを修正したことにより、他のプログラムの機能に悪影響を与えてしまう「デグレ」です。
ひとつ具体例を挙げてみましょう。
本番リリース後の保守・運用が主な業務の某プロジェクトは、「A」「B」「C」の3つのチームから構成されていました。お客様の要望により、Aチームが担当するプログラムを機能追加することになりました。修正担当のSくんは、修正前の影響調査をかなり厳密に行ったつもりです。
修正後のテストも問題なく終了し、迎えたリリース日。Sくんが思ってもみなかったCチームのプログラムが異常終了し、本番業務が止まってしまいました。お客様は、修正対象外のプログラムが原因で、本番業務が停止してしまった事実にカンカンです。
図 1-1. プログラム修正により発生する「デグレ」のイメージ図
関連記事
１-２．インフラ変更時の設定誤りにより発生する「デグレ」
「デグレ」は、プログラムを修正した時だけに起こるトラブルというわけではありません。ふたつめの「デグレ」は、インフラの設定変更を行ったことにより発生してしまう「デグレ」です。これも具体例を挙げて説明しましょう。プロジェクトの構成や状況は、「1-1.」と同じ設定です。
本番業務でトラブルが発生し、Bチーム担当のミドルウェアの設定値を緊急修正する必要があります。通常、プログラムやミドルウェアを変更する場合は、バージョン管理ソフトから最新バージョンのファイルを提供してもらい修正しますが、今はそんな余裕は全くありません。お客様からも催促の電話がバンバン掛かってきています。
Bチームのリーダーは、緊急性を重視し、止むを得ずミドルウェアの設定値を直接修正することを許可しました。担当者のKくんには、トラブル収束後、必ず今回の修正を最新ファイルに反映するように言い含めました。
トラブルは、発生当日に無事収束。Bチームのリーダーも担当者のKくんも事後作業に追われてしまい、手修正を最新ファイルに反映することをすっかり忘れてしまいました。そして、トラブル発生から3ヶ月後、同じトラブルが再発！お客様は再発したトラブルにカンカンです。
図 1-2. インフラ変更時の設定誤りにより発生する「デグレ」のイメージ図
１-３．ドキュメントの不備により発生する「デグレ」
そして最後の「デグレ」は、プロジェクトで使用するドキュメントの不備により発生してしまう「デグレ」です。これも具体例を挙げて説明しますが、先に挙げた「1-1.」の発生事象をベースにします。
修正担当のプログラムの影響調査に失敗し、「デグレ」を発生させてしまったAチームのSくん。彼は、何故「デグレ」が発生したCチームのプログラムを見落としてしまったのでしょうか。
Sくんは、自分が担当するプログラムがどこから呼ばれているかを表したマトリクス表を、最新の情報が反映されていると思い込んで、影響調査を行ってしまったのです。そして、そのマトリクス表には、「デグレ」を発生させる原因になったCチームのプログラムは、記載されていなかったのです。
Cチームのプログラムは数ヶ月前に新規追加されたもので、Cチームのメンバーは、別チームの資料への追記が必要だとは認識していませんでした。
図 1-3. ドキュメントの不備により発生する「デグレ」のイメージ図
２．「デグレ」は何故発生するのか
「書き出し」にも記載しましたし、1章の「デグレ」の事例からも薄々感じている方もいらっしゃる通り、「デグレ」が発生する原因は、ほぼ9割が「人的ミス」です。人の不注意、勘違い、思い込み、怠惰等が原因で発生するトラブルだからこそ、より深刻であり、お客様からの心象も悪いトラブルなのです。
「デグレ」が発生する「人的ミス」の原因はいろいろありますが、特によくある原因について、以下に3つご紹介します。
２-１．修正時における影響調査を見誤ったため
「1-1.」に記載した「デグレ」の発生事象の原因を探ってみましょう。
「デグレ」が発生したのは、修正担当のSくんが「思ってもみなかった」Cチームのプログラムでした。Sくん自身は、影響調査を厳密に行ったつもりだったのに、何故Sくんの想定外のCチームのプログラムで「デグレ」が発生したのでしょうか。
Sくんは、影響調査を行う際に決定的な人的ミスを2点犯していたのです。
- 修正対象のプログラムは、Aチーム内でしか「使用していないはず」だと思い込んでしまったこと。
- 影響調査で用いたマトリクス表に最新情報が「記載されているはず」だと思い込み、実際の環境下では全文検索を行っていなかったこと。
どちらのミスも「はずだ」と思い込まずに、謙虚に全グループを対象に影響範囲を確認していれば防げたミスです。
２-２．管理ルールや管理方法に不備があるため
こちらについても「1-2.」の「デグレ」の発生事象を元に、原因を明らかにしてみましょう。細かい原因を挙げたらキリがありませんが、大きな原因として考えられるのは以下の3点です。
- Bチームのリーダーが、ファイル管理のルールの逸脱を指示してしまったこと。
- しかも、トラブル収束後にリーダーも担当者も修正内容の反映を忘れたこと。
- そもそもファイル管理ルールが煩雑で時間がかかり、緊急時には対応不可だったこと。
トラブル発生時の優先順位を考えたら、リーダーの判断は止むを得なかったのかもしれません。しかし、収束後に修正内容の反映を忘れ「デグレ」を発生させてしまった以上、ファイル管理ルールの煩雑さについて苦言を呈したところで、あとの祭りです。
それどころか、自責を棚に上げていると見なされ、お客様の心象はますます悪くなるでしょう。
しかも、大抵の場合、一度「デグレ」を発生させてしまうと、以降の管理ルールは改善されるどころか、再発防止のために更に厳しくなります。結局は、不備に感じるルールだったとしても、逸脱して良いことは唯のひとつもありません。逸脱した結果、「トラブルを早く収束できた」「ルールがなくても、今までうまくやってきた」と言う人もいるかもしれませんが、それは単に「たまたま運が良かった」だけです。
２-３． 修正情報の共有が徹底されていないため
「1-3.」のドキュメント修正の「デグレ」発生事象において、AチームのSくん、Cチームのメンバに共通する原因があることにお気づきでしょうか。それは、「他チームの修正情報を知らなかった」ことです。
- 「1-1.」でプログラム修正を担当したAチームのSくんは、数ヶ月前に新規追加されたCチームのプログラムの存在を知らなかった。（だから、マトリクス表にCチームのプログラムがないことにも気が付かなかった）
- Cチームのメンバは、数ヶ月前のプログラムの新規追加時に、Aチームのマトリクス表に記載追加が必要だということも、自分たちが新規追加したプログラムから呼んでいるAチームのプログラムに修正が入ったということも知らなかった。
筆者の経験上、上記のような原因による「デグレ」は、ビッグプロジェクトにおいて各チームのベンダー企業が異なる場合に、発生することが多いような気がします。要は、チーム間の情報共有不足であり、コミュケーション不足なのです。
チーム間の風通しが良く、普段から他チームの状況等がうまく共有されていれば、防げた「デグレ」だったと言ってよいでしょう。実は、このような情報共有の不備により発生する「デグレ」は、状況設定こそ異なりますが、筆者にも身に覚えがあります。やはり、チーム間でベンダー企業が異なるプロジェクトにいた時のことです。
他チームでは当然のこととして認識されていた修正情報を、何故か筆者のいたチームだけが知らずに、「デグレ」を発生させてしまったのです。幸いにも、この時の「デグレ」は、本番業務ではなく開発途中の工程で発生したので、それほど大きな問題にはなりませんでした。
それでも「デグレ」が発生してしまった時に感じた「恐怖」と、その原因がわかった時に感じた「怒り」は、今でも忘れられません。他チームからの嫌がらせか？とすら思いました。結局、この「デグレ」の直接的な原因は、筆者のチームのチームリーダーが、修正情報をメンバーに周知し忘れていたという酷いオチでした…。
このように、プロジェクトに複数ベンダーが参入している場合には、特に注意が必要です。ベンダーごとに「当然」「当たり前」と思うことが、全く異なる場合があるからです。
３．「デグレ」を起こさないようにするためには
それでは、「デグレ」を起こさないようにするためには、一体どうしたら良いのでしょうか。
「デグレ」の主だった原因が「人的ミス」である以上、修正する人やその周りの人が意識的に注意するしかないのですが、ここでは、敢えて基本的な対策について3つご紹介します。どれも極々当たり前なことばかりですが、「デグレ」は、その当たり前と思っていることを怠ったことによって発生しているのです。まさに「怠惰が原因」と言っても、過言ではありませんね。
３-１．影響範囲の調査を慎重に行うこと
まずは、修正を実施する前の準備作業としての注意です。
修正作業によって、どのくらいの範囲に、どのような影響が及ぶのか、慎重にしっかり確実に影響調査を行いましょう。影響調査を行う際のコツは「現状ファースト」、そして、自分の認識を「疑ってかかる」ことです。本末転倒かもしれませんが、紙に出力してある資料は、特に信用してはいけません。それが、真実情報か否かの保証が難しいからです。
それだったら、最初から今現在稼働している開発環境、または本番環境に対して、影響調査を行った方が確実ですし、調査結果を説明する際にも説得力が増します。
そして、「ＡはＢだったはずだ」という自分の認識を、まずは疑ってかかることです。あなたが「だったはずだ」と思っていた情報は、次の日にあなたの知らないところで、こっそり修正されているかもしれないのです。
影響調査の範囲はできる限り広く、そしてそこで得た結果が、調査時点での真実です。謙虚に、冷静に影響範囲を判断するようにしましょう。なお、影響範囲を判断する際には、思い込みを避けるためにも、2人以上で行うことをオススメします。
また、予算が潤沢な場合には、検索ツール等を導入して極力人力を排した影響調査を行うことも、「人的ミス」を防ぐための有効な手段です。
３-２．ファイル版数等の管理ルールや管理方法をプロジェクト当初からきっちり決めておくこと
前述の「3-1.」の最後に、「予算が潤沢な場合」の対策をひとつご説明しました。それでは、予算が潤沢ではない場合には、どうしたらよいのでしょうか。
実は、予算が多いの少ないのに関係なく普遍的な対策なのですが、修正が発生した場合の変更履歴やコメント等の書き方ルールや、ファイル版数等の管理方法について、プロジェクトの開始当初からきっちり定め、プロジェクトメンバー全員に周知徹底しておくことです。
変更履歴や修正時のコメント等は、もちろん人的に挿入されるものですが、しっかりとした規約に従って記入された変更履歴やコメントは、影響調査を行う際の大事な道しるべになるのです。正しく設計されたシステムが正しく管理されていると、「デグレ」はそれだけで発生しにくくなります。
３-３．修正後のリグレッションテストでしっかり確認すること
そして、3つめの対策は、修正完了後にリグレッションテストを行い、修正に対する無影響確認をしっかりと行うことです。
リグレッションテストとは、プログラムの修正やインフラ機器の設定値の修正に伴い、システムに予想外の影響を与えていないか、「デグレ」を引き起こした箇所がないかを確認するためのテストのことです。リグレッションには「回帰」「退行」という意味があるため、「回帰テスト」「退行テスト」と呼ぶ場合もありますが、本稿では「リグレッションテスト」で統一して表記します。
修正作業の完了後に、改めてそれまで正常に動作していた処理や操作を再現し、問題なく同じ動作が行われることを確認するために行うリグレッションテストは、「デグレ」が発生しないことを担保するためにも、とても大事な工程です。
そして、リグレッションテストが十分ではないからこそ「デグレ」が発生し、大きなリスクを背負い込むことになるのです。
テスト範囲を絞り込まずに、すべてのテストを最初からやり直す「フルリグレッションテスト」というものもありますが、大抵の場合、そこまで広範囲のリグレッションテストを行う余裕はありません。
リグレッションテストは大事です。だからと言って、納期や予算に制限がある以上、むやみやたらと工数をかけるわけにもいきません。そこで大事になってくるのが、リグレッションテストの実施範囲なのです。
リグレッションテストの実施範囲を定めるためのポイントは、以下の3点です。
- 変更対象の影響範囲を的確に把握すること。（そのためにも、影響調査は慎重、確実に行う必要がある。）
- 仮に「デグレ」が発生した場合に、リスクが高い箇所を優先的に検証すること。
- 過去の不具合の発生傾向がわかれば、それに加えて変更対象の機能の重要度や顧客業務への影響度を考慮して、テストの優先度を判断すること。
更に、テスト工数を減らすという観点では、修正内容が影響する箇所と関係するデータを扱う箇所のみにテスト範囲を絞り込むというやり方もあります。しかし、あまりテスト工数削減にばかり囚われてしまうと、リグレッションテストの精度が下がり、結局は「デグレ」が発生するリスクを抱え込むことになります。
リグレッションテストは、「デグレ」が発生しないことを担保するための「保証書」とも呼べるものです。だからこそ、「デグレ」が発生した場合のお客様の心象は、新規トラブルに比べてより悪くなるのです。
４．「デグレ」が発生するとどんな怖ろしいことが起こるのか
本稿において何度も申し上げているように、「デグレ」は、他のトラブルに比べてお客様への心象が格段に悪くなる、ITエンジニアにとっては絶対に起こしたくないトラブルです。それでは「デグレ」が発生すると、一体どんな怖ろしいことが起こるのでしょうか。
特に恐怖度の高いものを、以下に3つご紹介します。想像するだけでも、筆者は怖ろしくて鳥肌が立ちそうです…。
４-１．顧客からの信用が失墜する
まず、何よりお客様の信用がガタ落ちになります。今まで正常に動いていた機能が動かなくなる上に、その原因が「人的ミス」なのですから、当たり前です。
更に悪いことには、一度「デグレ」を起こしてしまうと、その後も何かトラブルが発生するたびに「デグレ」ではないのか、と疑いの眼で見られますし、トラブル回復に対するお客様からの要求も厳しくなります。
下手したら、工数をかけてもフルリグレッションテストを実施せよ、と要求される場合も十分考えられます。
４-２．リグレッションテストや影響調査等により本来不要なはずの工数、コストがかかる
「デグレ」が発生した場合、当然そのトラブルを吸収するための詳細な影響調査やリグレッションテストが必要です。一度「デグレ」が発生してしまった以上、中途半端な影響調査やリグレッションテストでは、お客様は納得しません。もちろん、想定していなかった工数もコストもかかります。
そして、そもそも不要な工数をかけた結果、スケジュール遅延、予算オーバーになる可能性も高いでしょう。更には、本来開発すべきシステムのリリースが間に合わないという事態にも成りかねません。仮にそんな事態になるとしたら、最悪は契約違反と見なされ、下手したら損害賠償ものです。
何より「デグレ」が頻発するようなシステムの品質など「推して知るべし」です。
４-３．負のスパイラルが発生する
「4-2.」の畳みかけるような恐怖の連続から薄々お気づきかもしれませんが、悪いことというのは、次の悪いことを呼びます。怖ろしいことに、「デグレ」は次の「デグレ」を呼び、そこに「負のスパイラル」が発生してしまいます。
通常「スパイラル」とは、らせん状に上昇していく上向きなイメージですが、「負のスパイラル」は、反対に下にグルグル落ちていく、恐怖の永久ループ状態です。まさに、1章で記載した「デグレ」の発生事例がそれに当たります。
「1-3.」のCチームが犯した「ドキュメント不備」により、「1-1.」のAチームで「デグレ」が発生。また、「1-2.」のBチームの「デグレ」の影響を受けた次の改修で、また「デグレ」を作り込んでしまう可能性も多分にあります。
次も、また次も…。そして、その間にもお客様の信用は更に失墜し、「4-1.」の状態に戻ります。永久ループが発生した場合、どうやって止めるかご存知でしょうか？バッチだったら、[Ctrl] + [Shift] + [A]キーを押下。要するに強制終了ですね。
プロジェクトをまさか「強制終了」するわけにはいきませんから、誰かが「デグレ」の永久ループ状態に楔を打つ必要があります。
さぁ、ここでリーダーの判断力、決断力が問われる「腕の見せ所」です。怒っている場合ではありませんよ。
５．まとめ
IT業界の特殊な用語である「デグレ」について、できるだけ丁寧に説明してきたつもりですが、いかがでしたか？「デグレ」とは、ITエンジニア誰もが怖れおののくトラブルである、という恐怖感を感じていただけたら、嬉しいです。
最後に、1章から4章までの内容を簡単にまとめて終わりたいと思います。
- 「デグレ」とは「デグレード(degrade)」を略した、日本のIT業界でしか通じない特殊な業界用語。
- プログラム修正やインフラ設定の変更等の失敗により、今まで正常に動作していた機能が動かなくなるという恐怖のトラブルが「デグレ」。
- 「デグレ」は、プログラム変更時にだけ発生するわけではなく、インフラ設定の誤りや、ドキュメントの記載不備でも発生する。
- 「デグレ」の原因のほぼ9割は「人的ミス」
- 「デグレ対策・その１」影響範囲の調査は大事。慎重に確実に。
- 「デグレ対策・その２」修正時のファイルの管理ルールや管理方法は、プロジェクトの最初に決める。周知徹底しないと意味がない。
- 「デグレ対策・その３」リグレッションテストは、「デグレ」が発生しないことを担保する「保証書」。
- 「デグレ」が発生して、良いことはひとつもない。（お客様の信用失墜、本来不要なコスト、工数による、下手したら契約違反、損害賠償請求）
- 「デグレ」は次の「デグレ」を呼ぶ。
- 「負のスパイラル」に楔を打つことが、リーダーの腕の見せ所。
コメント