改めて認識した「問題の切り分け」の大切さについて

最近「**問題の切り分け**」の大切さを再認識できるような出来事があったため、まとめてみました。
## 出来事について

あるWebサイトを使用していたらバグに遭遇したため、メールで問い合わせました。 
そのバグとは「登録済のユーザー情報を更新できない」というものでした。
以下がメールの内容となります。（サイト名など特定できそうな情報は変更しています）

```
Aサイトで会員情報を更新できません 

To A運営
ご担当者様

会員番号000のBです。

以下の会員情報編集機能について確認させてください。
https://---/mypage/

「次へ」ボタンを押した後に表示される「お客様情報の確認」ページで「登録する」ボタンを押しても内容が反映されません。
具体的には「登録する」ボタンを押しても以下のページ(「お客様情報の確認」ページ)が何度も表示されてしまいます。
https://---/mypage/edit_confirm

以下が↑の現象が発生した私の環境です。

OS X 0.0.0
Chrome 00.0.0000.000 (64-bit)
Firefox 00.0.0

よろしくお願いいたします。
```

以下内容の返信が来ました。

```
【Aサイト】お問い合わせの件につきまして

B様

Aを最初期よりご支援くださり誠に有難うございます。

お問い合わせを頂戴いたしました問題につきまして、
ウェブ制作チームまで問い合わせましたところ、
現象を再現することが叶いませんでした。

引き続き検証を重ねさせていただきますが、もし差し支えございませんようでしたら、
以下の2点をお願いできますでしょうか。

1)
JavaScript、cookieが無効になっていらっしゃいましたら、
有効に変更頂き、キャッシュをお消しになってブラウザ再起動下さいませ。

2)
お手数おかけしてしまい恐縮でございますが、
・どの項目を
・どのように
変更頂きましたでしょうか。
ご教示下さいませ。

引き続き、何卒宜しくお願い致します。
```

現象の再現ができないということだったので、以下内容の返信をしました。

```
ご担当者様

返信が遅れてしまい申し訳ありません。

> JavaScript、cookieが無効になっていらっしゃいましたら、有効に変更頂き、キャッシュをお消しになってブラウザ再起動下さいませ。

JavaScriptとCookieは有効となっています。

> お手数おかけしてしまい恐縮でございますが、 ・どの項目を ・どのように 変更頂きましたでしょうか。 ご教示下さいませ。

問題発生時の操作を記録したgifを添付したので確認していただければと思います。

asite_chrome.gif
Chromeでの問題発生時の記録。
(「○○○」に「test」を追記して更新しようとしています)

asite_firefox.gif
Firefoxでの問題発生時の記録。
(「○○○」に「firefox」を追記して更新しようとしています)

以下が↑記録時の環境です。
OS X 0.0.0
Chrome 00.0.0000.000 (64-bit)
Firefox 00.0.0

Chormeはいくつか拡張が入っていますが、
Firefoxはアドオンを入れていないため、アドオンや拡張機能が影響している可能性は低いと考えています。

以上、お手数ですがよろしくお願いいたします。
```

この時点で以下が原因の可能性は低いと判断していました。理由は↑のメール本文の通りです。

* ブラウザの差異
* ブラウザ拡張機能の有無 

メールを送った2〜3時間後にWindows機を使う機会があったのでWindows機でも試してみた所、同様の現象を再現できたため、以下内容をメールで補足しました。

```
こちら補足ですが、Windows機でも試してみたところ、同様の挙動を再現できました。(ブラウザはIEを使用)
なのでOS依存というわけでも無さそうです。
OSやブラウザ依存でないとすると後はネットワーク環境くらいしか思いつかないですが、
なぜ自分の環境のみ発生しているのかは依然不明です。。

もしかしたら、今現在の自分の登録済情報が影響しているのかもしれません。
(初回登録時はフローが違うため、更新時には使用できない何らかの文字が登録できてしまった、など)
```

この時点で以下が原因の可能性は低いと判断していました。理由は↑のメール本文の通りです。

* ブラウザの差異
* ブラウザ拡張機能の有無
* OSの差異

なので「なぜ自分の環境だけ？」と考えていたのですが、↑のメールを書いている最中に「**初回時に登録した情報が影響しているのでは**」という可能性を思いつきました。

そこで改めて自分の登録していた情報を確認してみると、少し怪しい項目がありました。
他の項目は1行程で収まっていたのですが、その項目だけ他と比較して入力文字数が多いという状況になっていました。
と言っても85文字10行ほどの文字数で、`textarea`に入力する値としてはそこまで違和感の無い文字数です。
ただ怪しい項目がそれぐらいしか無かったため、試しに入力文字数を半分程に減らしてみると更新に成功しました。

具体的な原因が判明したため、以下内容のメールを送りました。

```
ご担当者様

会員番号000のBです。

こちら原因が分かりました。 
「○○○」に入力したテキストの文字数が問題だったようです。

初回登録時には以下内容が登録できていたのですが、 
-
aaa
bbb
ccc
ddd
eee
fff
ggg
-
更新時だと↑の文字数ではバリデーション？に引っかかるようです。
試しに半分くらいに減らしてみると更新できました。

これが仕様かバグかは分からないですが、もしこれが仕様だとするならば、
入力可能最大文字数はフォームのどこかに掲示しておく、
もしくは、何が問題で更新に失敗したかをバリデーション後に表示されるページで説明してもらえると親切かと思います。

お節介かもですが、Aサイトさんのことは応援していますので、今後共よろしくお願いいたします。
```

すると以下の返信が来ました。

```
B様

この度はサイトの不具合につきましてご教示を賜り誠に有難うございました。

頂戴いたしましたメールは全て技術チームまで回させていただき、
検証の際の参考にさせていただきました。

非常に詳しく、かつ簡易にお書き下さりましたこと、感謝申し上げます。

ご指摘頂いておりました通り、
バリデーションの問題とのことで、
入力可能数を3000字とさせていただく形で
サイトを修正いたしました。

今後とも、もしお気付きの点等ございましたら、
改善に尽力いたしますので、
ご教示いただければ幸いです。

これからもAを、何卒宜しくお願い申し上げます。
```
同様の現象を再現し、修正もしてもらえたようです。

以上が今回「**問題の切り分け**」の大切さを再認識することができた出来事についてです。


## まとめ
「**問題の切り分け**」はソフトウェアのデバッグ時のみならず、何かしらの問題を解決に導く上で非常に重要なプロセスです。
どんなに複雑な問題でも一つ一つ可能性を潰していけば、いずれは原因に辿り着けます。(辿り着いた原因が解決可能な原因かは別問題ですが)

よって、こういった考え方は普段の生活時から実践できるように心がけておきたいところです。