グロービス Advent Calendar 2017 の7日目です。
**「ネガティブではダメ、ポジティブでいい」**ってよく言われますが、ネガティブとポジティブ、そのものはいいことでもない、悪いことでもない、うまく使いば力になると思います。
ネガティブとポジティブとは
物事を如何考えているかの違いで、ネガティブは否定的で、陰陽の陰極であり、ポジティブは肯定的で、陰陽の陽極です。分離して存在することはできないじゃないかと思います。
ネガティブとポジティブの力
| 物事 | ネガティブ | ポジティブ |
|---|---|---|
| ユーザーからシステムの動きがおかしいって言う問い合わせが来ました。でも再現できない | システムにきっとbugがある、問い合わせをしてないユーザーもあるはずと考えて、調査・修正して、システムを改善する | システムには問題ない、ユーザーの使い方が悪いと思うと、結果はシステムは変わらない、ユーザーが離れる |
| vim勉強 | vimの勉強のハードルが高いから、諦める。 | 最初のハードルが高いが、慣れると楽になる。勉強した結果、生産性が高くなった。 |
lockが発生するsql（update users set num = num + 1）をtransactionに入れるべきか（データが変になっても大きな問題にはならないケース） |
データの整合性を保つためにはtransactionに入れるべき、結果はdeadlockになりやすい、rqsが減る | 整合性の問題発生はデータベースが処理途中でdownしたり、ネットワークが切れたり以外は発生しないし、頻度は超稀で、年に数えるぐらいしか発生しないから、transactionの外にlockが発生するsqlを書く。結果はrqsに影響ない。変なデータも少ない |
lockが発生するsql（update users set num = num + 1）をtransactionに入れるべきか（データが変になるのは絶対許さないケース） |
データの整合性を保つためにはtransactionに入れる | 問題意識がない、稀に発生するから大丈夫と思う。稀にしか発生しないが、発生したら、大きなトラブルに繋がる。 |
| 変な仕様 | 自分の判断を信じない、変な仕様通りに作業を進んで、結局、問題が発生し、ユーザーに迷惑かけ、残業で対応する。 | 自分の判断を信じて、仕様をもう一回確認する。結果は手戻り作業を減らし、ユーザーに迷惑かけない。 |
| 原発 | 原子力がコントロールできないだから、使わない方がいい。結果はもっとgreenエネルギー開発に投資 | 原子力は安全性が検証されているから、使ってもいい。実際は安全なものはない、問題発生したら、解決できるかを一回見直す必要がある。 |
| active record | 弱点がもあるから、生sqlでよりシンプルになるものは生sqlでやる | active recordがいい、全てをactive recordで書く、結果はperformanceが低い、読みにくいコードになる |
| best practice | best practiceがあくまで参考で、個別の課題に対する解決案ではない | best practiceが大好きで、何もかもそっちに嵌まろうと思い。 |
| 自分がやった作業について | 自信がない、きっと問題があるから、セルフチェックする。結果はいいものを作成する。偉い人間ほど作品を仕上げる時間が長い。 | 自分の腕を信じて、問題ないと思い込む。結果は何時かは問題が発生する。 |
| 適当な成果に対する考え | これでは、ユーザー満足度が下がる。改善に挑む | 適当になった理由を探す。ユーザーが理由に興味ないし、似た商品（サービス）があると、すぐ離れる |
結論
「ネガティブになる、ポジティブになる」ではなく、自らネガティブ・ポジティブになり、物事を考えて、決断をした方がいい。