ネガティブ思考が最高に活きる、エンジニアの仕事で見るその有用性
冒頭にかなりキャッチーな、フリー素材のサムネイルを利用していますが特に他意はないです笑。ネガティブチックな画像ならなんでも良かった。
貴方はネガティブ思考になりがちですか？僕の場合は、プライベートで言えばポジティブな割合が多く、仕事の際はネガティブな割合が多いです。世間一般的にはネガティブ思考からは何も生まれないという意見が圧倒的多数かと思いますし、好まれるのはいつもポジティブ思考です。僕自身は二者択一の思想というものを持ち合わせていない人間なので、その両方が好きだったりします。
今回は、そんな世間一般的には忌み嫌われるネガティブ思考が、エンジニアの仕事をするうえで大切な役割を担っているというお話を綴ります。ここからはポジティブ・ネガティブを楽観・悲観と別の言い方に言い換えてお伝えしますね。
楽観性・悲観性と共存する
エンジニアの仕事というのは、医療従事者程ではないにしろ、かなり失敗が許されない世界でもあります。それは扱っている仕事の規模が大きければ大きい程、その傾向にあります。システムが不具合を起こしたり停止したりすれば、莫大な金銭的・信用的損失や、下手をすると人命に関わる事だってあります。
僕の場合はWeb業界なので人命はないですが、重責のない仕事かと言えばそうでもなく、クライアントとの秘密保持義務でサービス名は載せれませんが、現在も数百万人単位が利用するサービスの中でアプリからインフラまで僕が設計開発したものが動いていたり、バグを出せば業務過失・利用企業に補填対応しないと駄目なレベルのものもやってたりします。
ここで楽観性と仲良くする事、悲観性と仲良くする事はどちらも非常に重要になってきます。また、それぞれと仲良くする事は重要ではあるのですが、過度に悲観性と仲良くしすぎると体や心を壊してしまうし、過度に楽観性と仲良くなり過ぎると必ず破滅します。
各フェーズでそれぞれとの付き合い方を変える
ちょっと自慢ぽい話の内容になってしまいますが、僕はこのWeb業界に10年以上在籍していますが、大きなバグや不具合で修羅場に陥った事がありません。バグを出した事は？と言われれば、過去に結構ありますし、直近でもあります。
でも出したバグが「すいません、それ次のリリースで直しておきますね」ぐらいの規模感のバグが圧倒的で、致命的なものや、金銭的・信用的においてそれらを損なうレベルのものがありません。
またシステム開発プロジェクトというのは大きく遅延したり、頓挫して炎上するのがザラにある業界なのですが、ここに関してもスケジュールが遅延したり炎上したという記憶が無く、正常に納品・稼動しています。
僕はこの結果を、個人のスキルや開発能力だとは思っておらず、楽観性と悲観性との付き合い方をフェーズで変えていくのが上手である結果だと考えています。
思えばいつも大きな悲劇を生むのは、悲観的であるべきフェーズで楽観的であった時
最近の例を話させてもらうと、セブンペイの不正アクセス問題などはその最たるものでした。電子マネーが絡むシステムで、業界最大手のブランド名を冠していて、セキュリティ周りにはとことん悲観の極みで対応しなければならないはずなのに、蓋を開けてみれば、業者から名簿リストさえ入手出来てしまえば、経験の浅いエンジニアでも数日で作った総当りプログラムで軽々とハッキング出来てしまうものでした。
上記の話に限らずに、僕が過去に見てきた人の失敗の多くが、楽観的な人は楽観的なまま、悲観的な人は悲観的なまま仕事をしていて、仲良くする相手（楽観・悲観）をフェーズで切り替えずにずっと一緒にいるということです。
前者の場合はやはり大きなバグや、セキュリティリスクをそのままにしてしまったり、考慮漏れでプロジェクトを炎上させてしまったり。後者は開発スピードが極端に遅かったり、人付き合いが苦手だったり、体や心を壊してしまって業界から去っていたりします。
いつ誰と仲良くしているの？？
ここからはあまり一般の方には有用じゃないかもしれませんが、僕のnoteを見てる人はWeb業界の方も多いと思うので、どーいうフェーズで誰と仲良くしていて、どーいう思想になっているか開発の参考になればと思います。特に悲観が強くなっているところは、僕が絶対に失敗したくない箇所という表れでもあります。僕の好きな料理のフェーズで先に例えてみたのでご覧ください。
何が食べたいか聞く - 【楽観40%：悲観60%】
レシピ検討 - 【楽観5%：悲観95%】
調理 - 【楽観80%：悲観20%】
味見する部分を決める - 【楽観20%：悲観80%】
味見する - 【楽観90%：悲観10%】
提供する - 【楽観90%：悲観10%】
何が食べたいか聞くフェーズでは、本当にそれが食べたいのか？本当は別のものが食べたいんじゃないのか。カレーライス食べたいって言ってるけど、本当はハヤシライスなんじゃないかとか。食べたいって言って作らせて、なんか廃棄しそうだなとか。ビーフストロガノフ食べたいって言われたから作ったら、なんか労力だけめちゃくちゃかかって、食べた際になんか普通だねって顔されて喜ばれなさそうだなとか。
何作るか決まったレシピ検討フェーズでは、ちゃんと材料が全部冷蔵庫に揃っているよねとか、調味料あるよねとか、調理器具揃ってるよねとか、ガス止められてないかとか。調理器具が壊れてるかもしれないから一回全部動かして動作確認しておこうとか。調理フローはしっかりスケジュール引いてあって、並列で完成のタイミングで全てがちゃんと合流するよねとか。完成したタイミングで実は料理を盛る食器が割れてるんじゃないかとか。器が小さくて盛れないんじゃないかとか。カレーなのにフォークしかないんじゃないかとか。冷蔵庫から取り出した食材の消費期限見たら実は過ぎてないかとか。
調理のフェーズでは完璧なレシピフローに従って、がつがつ作っていきます。がつがつ作りながらも、大丈夫だよね。忘れてるものないよねって思いながら作ります。
味見する部分を決めるフェーズでは、使ったのは本当にビーフンだったよね、春雨じゃない事を確認しなければいけないとか。食べれるキノコに似た毒キノコが混じっていなかったか確認しなければいけないとか。
味見フェーズでは、やっぱりこの素材・味で間違いない事を確信します。
提供するフェーズでは、もう完璧に出来た！と思いながらも、中に髪の毛や虫とかが混入してしまっていないかとそっと確認しながら、直前で引っ込められるようにしつつ、やはり問題ないと確信して提供します。
真面目にシステム開発の専門用語に直すと、下記の対応表になります
要件定義 - 【楽観40%：悲観60%】
設計 - 【楽観5%：悲観95%】
開発 - 【楽観80%：悲観20%】
テストケース作成 - 【楽観20%：悲観80%】
テスト実施 - 【楽観90%：悲観10%】
リリース - 【楽観90%：悲観10%】
特に、設計フェーズでは悲観の極みです。ここを失敗すると、大抵失敗します。次から次にマイナス発想をしてこのタイミングで膿みを出し切ってしまう事が肝心です。後半のフェーズになって設計フェーズでの抜け漏れが発覚すると、今までかけた労力を全て放棄して、またこのフェーズからやり直す必要があります。マイナスオーラびんびんに出しているフェーズなので、周りの人は迷惑だと思うし、注意が必要です。
この割合は絶対に失敗できないプロジェクトでの内訳になっているので、より重要ではないプロジェクトになればなるほど、各フェーズでの悲観の割合を下げてスピードを重視させるようにするのがバランスが良いと思います。
最後に
こうして文章にすると、楽観君・悲観君からするとサイコパスみたいな友達ですよね。いきなり「仲良くしようよ、君と友達になりたいんだ」と近づいてきたと思ったら、いきなり「お前とはもう絶交だ」といなくなる。またしばらくすると仲直りしたいと言ってきて、また絶交する、都合の良い超絶サイコパス
人生概ね楽観的であれば上手くいく事も多いと僕自身も思うけれど、やっぱり悲観的である事も、要所要所では非常に大事。どちらが優れているかという二者択一の視点を持たずに、今後も生きていけたらなあって思っています。ここまで読んでいただきありとうございました！