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

2359 ワード
思考法 思考法 テキストリンク

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

結論

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