なぜ炎上してしまったのか・炎上しないために必要だったこと
話題の記事は ユーザを批判している ように読み取れる文章となってしまっていたため、広範囲に火が燃え上がってしまった。
炎上商法なのであれば完成度の高い記事ではあるが、おそらく違うだろう。
該当記事が炎上しないために必要だったことは、 「褒めるときは "ヒト" を。叱るときは "モノ" を。」 の精神。
（本記事も該当記事の作者を批判しているのでは？というツッコミはさておき。）
ユーザを悪者にしていなければ、もう少し火の勢いを抑えることができただろう。
また、 想定読者（誰が読むのか、誰に読んでほしいのか）を捉え違えた のも炎上の一因であろう。
正直なところ、記事中のSaaSプロダクトを開発していた社内に閉じた文章であれば、そこまで悪くないものである。
記事内で触れられているように、（正しかったかはさておき）しっかり段取りした上でリリースしたものの、ちゃぶ台返しされてしまう事態が発生したようだ。
そのような状況下にあるPdMやエンジニアのメンタルを加味すると、該当記事は「自分たちがやっていたことは間違っていなかったんだ！」と背中を押してくれる内容になっており、彼らの精神を回復してくれる良い材料だ。
……そういった意味では、該当記事の作者も諸々の開発やユーザ対応が落ち着き、冷静に振り返れる状態になってから記事を公開すべきだったのかもしれない。
（すでに冷静な状態で執筆・公開したのかもしれないが）
炎上したからこそ得られた学び
ここから先は（ここから先も）個人の感想強め。
今回はエンジニア界隈、デザイナー界隈ないしはIT界隈で燃え上がったということもあり、感情的な批判だけではなく有益情報を添えたコメントが多く見受けられた。
- クレームとフィードバックの違い
- 健全なユーザ向き合いとは何か
- 色に関するデザインの知識
- ドメイン知識の大切さ
こういった学びが得られたのは傍観者として良かった。
（本記事を書いている時点でもはや傍観者ではないが）
クレームとフィードバックの違い
健全なユーザ向き合いとは何か
極論、ユーザ様からの問い合わせは基本的にプロダクトへのフィードバック、つまり価値向上に繋がる可能性の塊と捉えて良いのでは！？
to Cはわからないけど、to Bであればそもそもクレーム割合少なそう。（偏見）
少なくとも、ユーザには真摯に向き合いましょう。
というか、ユーザ以外にもPdMに対してもエンジニアに対しても、それこそデザイナーに対しても、みんな仲良くしよう！
（求む！平和な世界！）
あと、「時間が解決してくれるさ」の精神は問題に向き合っていないだけ、というド正論パンチが飛んでくることを知ったので、ビジネス場面では気をつけたい。
（私生活の問題は時間が解決してくれ）
色に関するデザインの知識
色覚特性や色、コントラストについて学ぼうぜ！というコメントがあり、なるほどとなった。
そもそも件の仕様変更のモチベーションが「見やすくしようぜ！」で、それに必要な知識が色々なコメントから得られたのは良かった。
なお、何が正しいのかわからないのでここではまとめない。
（本音：本記事書くの飽きてきた）
ドメイン知識の大切さ
該当記事では「Googleカレンダーで採用されているからこのプロダクトでも同様の仕様が正しい」と主張していますが、ユースケースもしくはプロダクトの利用環境を想定しきれていないように感じる。
ユーザはデスクワーカーではなく、物流センターで働く人。
物流センターについてもっと詳しければ、その環境下で使いやすいプロダクト作りにより貢献できただろう。
今回の事例でいうと、オフィス内ではなく自然光が入り込む場所での使用を想定した色合い、を初めから考えることができた……かもしれない。
と思ったけど、事前のユーザヒアリングでもドメイン知識は蓄えられているので、今回の事態を防ぐならば実際に現場に赴くしかなかったのかな。
この辺は予算や時間の都合もあるから理想論。
参考情報
"話題の記事" はこちら。
上記記事を分析した記事もおもしろかったので。
