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

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

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

http://ht-jp.net/blog/pc/dev-memo/degrade2

タイトルの通りで、始末書書かされました。社内での信用０です。先日のデグレの時もでしたが、今日も思いっきり怒られましたよ。電話越しの無言は怖い。いいよもう、いっそ、このまま窓際にしてくれよ。ボーナス査定も何もかも最低でいいから、事務仕事やって定時で帰らせてくれれば。って感じで、絶賛始末書書いてます。派遣のほうがよっぽど使えるって言われたし、なら、開発には派遣使ってくれよって。でもまぁ、PGとかに関しては派遣の方が使えるのは事実なので、反論も出来ない。今回は、デグレではないので、厳密には違うのです...

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

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

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

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

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

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

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

絶対に起こしてはいけないデグレード
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
にあるように、リグレッションテストをやる必要があるのかなと。
もちろん、その前に、該当機能の仕様を把握していないと、そもそもデグレかどうかの判断も出来ないので、形だけのリグレッションテストでは駄目ですが。

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

デグレは

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

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