デグレをぶちかましたので、開発作業を1週間以上止められた話。

投稿日:2017-07-20

自分が改修を担当した画面でデグレが発覚してしまい、開発作業を1週間以上止められました。
止められたのは自分だけですが、マジです。
そんだけ、開発現場において、デグレってのは駄目な話です。

一回、こういうことをやらかすと、些細なことですら怒られたりするので、気を付けましょう・・・

そりゃぁもう、滅茶苦茶怒られました・・・
自分では完全にテスト時にスルーしてたので、全く気づかなかったんですよね。
機能の置き換えをしたんですけど、そんな機能が元の処理に残ってたとは・・・って感じでした。

リリース直前に発覚したので、お客さんに怒られるという事態は避けられたものの、プロジェクトリーダーに小一時間、電話で絞られました。
「なんで、こんなデグレが起こったんだ?」と問い詰められても、「すいません・・・」としか答えることの出来ない沈黙の時間は異常に長く感じられました・・・

で、「しばらく、プロジェクトの作業をするな」と・・・。

やったね、遊べるよ(☝︎ ՞ਊ ՞)☝︎

とは行かないですが・・・

 

デグレの恐怖というか、なぜ駄目なのか?っていうのは、いくつか参考になるページをあげておきます。
自分の観点でまとめると以下。

  • お客さんの信用ががた落ちになる
  • 発見が遅れるほど、影響範囲が大きくなるため、再改修の費用も時間もかかる
  • そもそも発見が困難

絶対に起こしてはいけないデグレード
http://www.techvan.co.jp/media/quality/degrade
更新後にデグレードが見つかってしまうと、利用者側の期待や信用を裏切ることになってしまう。既に利用者が作業で使用されているシステムであれば、その作業にも支障が出てしまう可能性があるため、必ずテスト段階でデグレードを発見し修正しなければならない。

「デグレードとサヨナラ」〜ようこそ!ノンデグの世界へ〜
http://www.ogis-ri.co.jp/column/pm/1225904_7539.html
今までちゃんと動いていたのに、全く関係のないこの機能がなぜバグるんだ!」とお叱りを受けることになります。

Friendlyを作った理由 その1
http://ishikawa-tatsuya.hatenablog.com/entry/2014/12/01/011121
そして調べてみるとですね・・・。

修正箇所は影響範囲が大きいのですね。

何といっても複数の機能から使われていますから。

修正確認を本気でやると凄いお金が掛かりますよね。

で、リリース前なので時間もないし、リスクも高い

しかも、運が悪いことに、今回は偉い人に見つかってるから、話も大きくなっています・・・。

リグレッションテストはどこまでやるのか
http://taka-2.hatenablog.jp/entry/20110615/p2
大半の機能をリグレッションテストすることになった。
人が少ないという理由で、普段自分が保守を担当している部分+他人が保守を担当している部分まで、リグレッションテストすることになった。

お客さんの信用ががた落ちになる

社内での心証も悪いんですが、何よりお客さんの心証が駄々下がりになります。
なんていったって、使えていた機能が使えなくなるんです。

デグレとは違いますが、MicrosoftのOfficeがリボンスタイルになったときは、周囲の反応はこんな感じでした。
作業に該当するアイコンが分からないんです」
今までメニューを辿って機能を選択していた人にとって、同じことが出来なくなるという状態は、ストレスでした。
実際、今でこそ普通に使ってますが、当初はメニュー?(相当するアイコン)が分からないっていう声が多かった。

別の機能で代替出来ることもあるけど、慣れ親しんだ作業から変えるというのは、ものすごいストレスを与えます。

最近の例だと、iOSのTwitterアプリでしょうか。
アイコンの配置が変わったりしてるので、非難ごうごうです。

自分も最初は、操作に戸惑いました。

  • Twitterの使い方って人それぞれで、「いま」起きてることや話題を確認しない人もいる。
    むしろフォロ〜してる人の「いま」を知りたい
  • 新しいメニューは慣れるまで使いづらい
  • ヘッドライン不要
  • 丸みデザインの意味がわからない
  • デザインが変わって、重要なこともわかりづらい
  • そもそも切り替え方法がわからない
  • 非直感的・・・

個人的な感想でもこんな感じでした。

発見が遅れるほど、影響範囲が大きくなるため、再改修の費用も時間もかかる

http://ishikawa-tatsuya.hatenablog.com/entry/2014/12/01/011121
を参考にしますが、デグレを含んだ機能や画面を継承していたりすると、それ以降の処理や画面の全てにおいてデグレが存在することになります。
で、そのどれかの画面・処理でデグレが発覚した時に、関連する画面・処理の洗い出しと、根本対策が必要となります。
見つかった画面・処理だけ修正して終わり!とはなりません。

他の画面でデグレが発生していないということをお客さんに証明する必要もあります。
もしくは、デグレの完全解消の証明。

当然、一回デグレが見つかると、お客さんも疑いの目を持って触るようになるので、余計にデグレが見つかった時の印象は悪くなる・・・と。
普通のバグでさえも、デグレに関連してるんじゃないか?って疑われたりする。

そもそも発見が困難

修正してる本人は、多分気づかない
だって、意図してデグレなんて仕込まないから。
単体テストでは、多分、スルーしてしまう・・・。

そうなると、上位で総合テストとかでも、デグレなんか意識してないので、デグレを要点としたテストなんてしません。
しようと思ったら、それこそ、全機能の単体テストレベルから再テストする必要があります。

デグレを起こさないためには

http://taka-2.hatenablog.jp/entry/20110615/p2
にあるように、リグレッションテストをやる必要があるのかなと。
もちろん、その前に、該当機能の仕様を把握していないと、そもそもデグレかどうかの判断も出来ないので、形だけのリグレッションテストでは駄目ですが。

大きく処理が変更する時は、割と注意するんですが、ちょこっとした変更(のつもり)だと、デグレなんて意識の隅に追いやられてしまうので、そういう時こそ、注意して作業したほうがいい。

 

デグレは

  • 怒られる
  • 信用を無くす
  • 時間がかかる
  • お金もかかる

で、誰にも何もいいことがないので。







-開発メモ
-,


  1. 納会。 | より:

    […] […]

comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

[ORACLE]ORA-00918:列の定義が未確定です・・・のエラーにならなかった

なんでエラーになるものをマージしてるんだ? と、怒られました。 一瞬、理解が出来ず・・・ で、エラーを再現してもらう・・・と。 あっさり発生。 早く修正しろって突っ返されました。 頭には「?」しか浮か …

先日のデグレに引き続き、作業を一個抜かしたら、超絶怒られて始末書書かされた件

タイトルの通りで、始末書書かされました。 社内での信用0です。 先日のデグレの時もでしたが、今日も思いっきり怒られましたよ。 電話越しの無言は怖い。 日本の中心付近で仕様変更と闘うSE日記  …

「別のプログラムがこのフォルダーまたはファイルを開いているので、操作を完了できません。」と表示された場合の対処法:Windows7

今日は2017年秋期の情報処理試験でしたが、受験されたみなさまいかがでしたでしょうか? ろくすっぽどころか、参考書すら買ってない状態だけど、情報処理試験の午前だけは受けに行く(起きれたら)。 午前は択 …

no image

C#で正規表現が使えたらな〜って時は以外と多いので、ちょっと正規表現を頑張って使ってみた。

あー、正規表現が使えたらな〜って時は以外と多いので、ちょっと正規表現を頑張って使ってみた。 別にC#に限らないんだけど、ソースの中に正規表現を書く時の書き方?っていうのかな。が分からなかったので、調べ …

[Windows]タスクバーに表示される「最近使ったもの」が多すぎて消せないので、一括削除する方法

さて、Windows使いの人なら、地味に便利に使っている・・・かもしれない「最近使ったもの」という一覧。 確かに、同じフォルダを開きたい時とかは重宝します。 が、たまにウザいw 場合によっては消さなき …


カテゴリー