実装後にでる不具合についてもう少しだけ考えてみた

何を作るにしても、何かしらの不具合ってでますよね。時間がなくてあわてながら実装するときは、ある程度は仕方ないなと思いますが、しっかり準備した場合でも不具合って出ます。なんだか心が折れそうになったりします。私自身も最近そんな経験があったので、少し整理してみました。

私自身の経験だけの話なので、なんとなくで読んでもらえたらと思います。

前提条件

• 5年目フロントエンドエンジニアからの目線です
• web開発を想定しています
• アジャイル開発の目線入ってます
• ガチガチの現場よりも、ふわっとした開発現場の経験が多いです

結論

不具合と言われるものの種類は以下の3種類。

• バグ、実装漏れ
• 要件漏れ
• 追加実装

上記3つを無くすことは不可能だが、できるだけ無くす努力をチーム全員で行う。出たバグが上記3のうち何に当たるかを理解し、対応の優先度を整理して、いつ対応するかを決めよう。

不具合が起きたときの気持ち

単純な不具合の場合は、「申し訳ありません！私のスキル不足です！すぐに直します！」　となります。変な汗をかきながら頑張って直します。特にエンジニア始めたての頃はひやひやでした。

しかし、以下のような場合もあります。

「この指摘、仕様書に書いてあったっけ...?」
「このパターンはたしかに考えてなかったなぁ...」
「デザイン通りに作ったけど、指摘されたほうが確かに使いやすそうだな」

それぞれに対しては、当初僕はこう思ってました。

「仕様書に書いてないけど、それを察知するのがエンジニアの仕事でもあるもんな」
「値の境界値チェックできてなかった..！検討が漏れてました、すいません！」
「指摘されたデザインの方が絶対良いし、いいもの作りたいし、修正だ！」

FBのチケットに分類なんてないんですよね。不具合は一律で不具合です。

そんなこんなでチケットがだんだん溜まってきます。実装したのは自分なので、ミスを起こしたのはすべて担当した自分の責任のように感じながら、無限に積まれていくチケットを消化していきます。成長機会だから頑張ろうと思います。

そして辛くなります。

本当に自分のせいなのかなと思い始めます。

だんだん人のせいにします。

仕様書が悪い。

デザインが悪い。

プロジェクトにアサインした上司が悪い。

...

...

だぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！！！

抱え込まない

一人で抱え込むのは良くないですね。誰かが起こしたミスや課題はチームのものです。チームで解決しましょう。

不具合の種類は3つ

上記の例のように、単なるバグだけでなく、仕様やデザイン漏れ、追加実装などが出てきます。それを分類すると以下のようになります。あくまで私個人の見解です。

1. バグ、実装漏れ
2. 要件漏れ
3. 追加実装

それぞれ見ていきましょう。

1. バグ、実装漏れ

シンプルに仕様を満たしていない実装です。
人間なので何かしらの漏れは起こすものです。

例えば？

• ボタンを押しても反応しない
• デザインが異なる
• 仕様に書かれているのに、存在しない、機能が異なる
• クロスブラウザによるバグ

どのように対応しますか？

• PM、デザイナー、チームのエンジニアと要件のすり合わせを行いましょう。いろんな目線が入ることで認識齟齬が防げます。
• コードレビュー文化を作りましょう。1人ではバグを全ては防げません。
• デザインがないけど先に実装しましょう。はできるだけやめましょう。手戻りが多くなります。
• WF、デザインから詳細設計書を書いてみましょう。自分の頭で認識がしっかり取れます。
• テストを書きましょう。テストパターンで認識漏れが発見されたりします。
• 値の境界値は意識しましょう。だいたいバグります。
• 対応ブラウザは事前にきちんと確認しましょう。そしてそれを意識しなくていいように環境構築しましょう。

詳細設計書って？

私自身どう呼ぶべきか理解してません。簡単に言うとすごく作り込まれたWFです。
過去経験した案件で、すごく作り込まれたWFに出会ってからこのように呼んでいます。そのときはPMが用意してくれました。

例えばZennの投稿ボタンを実装するとします。

それぞれ赤線で囲まれた要素に対しての挙動を洗い出します。

要素	内容	view	挙動	エラーパターン
設定ボタン	設定項目を決めるボタン	Hover時に白背景。ToolTip表示	ボタン押下で設定モーダル表示	無し
公開ボタン	記事公開選択ボタン	公開時活性: ボタン青、テキスト黒	記事公開状態を切替	通信エラーでAlert表示
下書き保存	下書き保存ボタン	ボタン押下後、1秒保存済みを表示。Hover色変更。	記事を下書き保存する	通信エラーでAlert表示

こういったWFが当たり前の現場もあれば、そうじゃない現場もあると思います。できる人とできない人もいます。PMがWFで用意してくれるときもあれば、ない場合もあります。ただ、あった方がより理解が深まります。誰がやるかは現場次第でいいと思います。私の現場では実装者がこれを書くようにしています。自分で洗い出すことで仕様への理解は深まりますし、パターン漏れもなくすことができるからです。

---

2. 要件漏れ

想定されていなかったパターンの考慮もれです。
「ちょっと直しておいて系」の案件などでも起こります。

例えば？

• データが存在しない場合の画面表示
• 特定の条件で表示するエラー画面
• 画像アップロードなどで許可するfileのtypeやsize。それを超えた場合の挙動など
• A画面のリンク変えた場合の、B画面のボタンの変更漏れ（ちょっと直して系）

どのように対応しますか？

• WFを書く担当者（案件発案者やPMなど）は、WF書きましょう。WFがないと、エンジニアはどこに向かって実装すべきかわかりません。目指すべき方向などもわからない場合、検討も浅くなるので検討漏れが発生しやすくなります。
• デザイナーはデザイン上でもある程度の動きのパターンなどが想定してデザインしましょう。エンジニアが喜びます。
• エンジニアはWF、デザインから詳細設計書を書いてみましょう。パターンの洗い出しに役立ち、要件漏れが防げます。
• テストを書きましょう。テストパターンで要件漏れが発見されたりします。

---

３. 追加実装

やっぱりこっちのほうが良かった、この挙動も実装してほしいなどです。
実装後に気づくことも多々ありますよね。

例えば？

• 要素の最大幅変更したい
• ボタンの色をちょっと変えたい
• この要素、やっぱりモーダルにしよう
• 記事の保存だけじゃなくて、下書き保存もあったらいいな

どのように対応しますか？

• 不具合の顔をして近づいてきます。まずは不具合か追加実装かを見極めましょう。
• 追加実装だと判断した場合は、優先度を話し合いましょう。必要な場合もありますが、不要な場合も多々あります。必要な工数を伝え、リリース日と相談して決めましょう。
• 必要な場合でもリリース後対応にすることもできます。大事なのは、今すべきかです。

不具合は起きるもの。みんなで防ごう。

開発規模や開発チームのレベル感にもよりますが、上記3つを完全に防ぐ事はできないと思います。なにかしら不具合や漏れは起こりえます。なので皆で起きないよう努力し合うことが大事なのかなと思ってます。。

• PMはWFできちんと方向性を示す。
• デザイナーはデザイン意図が伝わるようにする。デザインパターンを洗い出す。
• エンジニアはそれらをきちんと理解し、実装ベースで検討すべき仕様やパターンを洗い出し、すり合わせる。エンジニアチーム内でも実装方針のすり合わせを行う。

チームですり合わせながら実装することで、漏れや方向性のズレが少なくなると思います。
そして出た不具合に関しても、今すべきことなのか、優先度をつけながら検討していきましょう。

最後に

なんでこんな記事を書いたかっていうと、私自身の経験としてWFやデザインが無い案件をやることが多かったからですね。ざっくりとしたWFと簡単なインプットで実装始めて、最初はいけるだろうと思ってても実装後のFBの多さに泣いたことが多かったです。

最近はそんなことなく、きちんとWFとデザインがあって、詳細にすり合わせて実装することが多いですが、それでも不具合チケットはたくさん来ます。でるんですよね、結局。だから予防した上で、その後の対応をどうするかを考えながらやっていくことが大事だと思ったって話です。