ネガティブ・ポジティブの力

グロービス 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が大好きで、何もかもそっちに嵌まろうと思い。
自分がやった作業について	自信がない、きっと問題があるから、セルフチェックする。結果はいいものを作成する。偉い人間ほど作品を仕上げる時間が長い。	自分の腕を信じて、問題ないと思い込む。結果は何時かは問題が発生する。
適当な成果に対する考え	これでは、ユーザー満足度が下がる。改善に挑む	適当になった理由を探す。ユーザーが理由に興味ないし、似た商品（サービス）があると、すぐ離れる

結論

「ネガティブになる、ポジティブになる」ではなく、自らネガティブ・ポジティブになり、物事を考えて、決断をした方がいい。