この本を手に取ったきっかけ
今まで現場の上司や同僚から、仕事のやり方や考え方を吸収してきました。それらのやり方を自分のものにできて、成果も安定して出せるようになってきました。しかし、なんとなく、気持ち的に無理をして、精神を削って仕事をしている感覚がありました。そして、ここ最近、ストレスが原因で体調を崩すことが多くなっているなと感じています。
そんなとき、この書籍に出会い、”マイクロソフトで働いている方ってどういう考え方でエンジニアをしているのだろうか”と興味を持ち、読んでみることにしました。
驚愕した一流エンジニアのマインドセット
この本を読んで、いままで私が成果を出すために必要だと考えていたマインドセットがひっくり返ることがいくつもありました。それらをまとめてみます。
１．まずエキスパートに頼る
以前、約一年アサインされたチームのリーダーが「ググレ,カス」を体現した人だったので、いったん聞いてみるが心理的に不可能でした。(自分なりに検討しても、毎回どやされて、、、疲弊して、、、という最悪な心理安全性の上司でした、、、お客様に毎週出す定例資料を”この資料無駄”の一言で目の前で全削除されたのは今となってはいい思い出です)
そのため、自分自身で解を導き、なんとかゴールまでもっていく日々を過ごしました。この期間で自分自身で問題解決までもっていく力は相当ついたものの、疲弊し、若干鬱っぽくなりました。
ただ、本書では「エキスパートに頼ること」がベストプラクティスだとされています。
今まで、私自身の力不足で、質問しても答えてくれない、どやされる、と自責していたことがそうではなかった。 むしろ私はベストプラクティスに近いことをきちんと実践していました。 今後は以前の上司は悪の権化と認識し、いったんエキスパート/上司に聞く、を継続していこうと思います。
2．”Be Lazy”
今まではどのような成果物にも（自分だけしか見ないものでも）誤字脱字、フォーマット揺れ、不具合を許さず、完璧を求めることを自身に課してきました。これが上司やお客様から評価されてきたことは事実としてあります。しかし、いかんせん、とても疲れるんですよね、、、
本書はこれを勧めず、Be Lazyなことをベストプラクティスだと示してくれました。
”最もバリューが出ること1つに注力し、いかに苦労しないかが大切なことだ”
この考えかたは、私のいままでのマインドセットを根本からちゃぶ台返ししてくれました。
たしかに、別に資料の「メイリオ」「明朝体」の揺れがあっても、同じ日本語だから読めないことは絶対にないし、「おはうよごいざます」のように多少の誤字があっても別に人間の脳は処理して読んでくれます。こんなことに労力を使って、本当の価値を生み出すことに時間を割かなかったことがもったいなく感じています。
3．不確実性を受け入れる
私が経験してきたどんな開発でも仕様変更が入ってきました。
Aで初期開発⇒Bに変更⇒やっぱりAに変更⇒そもそも他サブモジュールが対応できていないので動かない、、、なんてこともありました。当時は、なんでそこを最初から議論しないのか、、、とストレスが溜まっていったわけです。
でも人間間違えて当然だし、複雑なシステムを開発しているので、最初から完璧な仕様なんて検討できるわけないですよね。むしろ、早く気づけて良かったねと褒めたたえるべきだと思います。
とりわけ私はこの不確実性というものがとても苦手です。例えば休日でもある程度脳内に行動スケジュールを組んで、それを大きく逸脱したくない性格です。最初はこのマインドセットを自分のものにできないかもしれませんが、ゆっくりと浸透させていければと考えています。
まとめ
ここまで読んで超ざっくりいうと”全部完璧にこなさなくていいよね！一番楽に、楽しく開発しようぜ！失敗してもいいからさ！”って感じだと思います。お客さん含め、みんな緊張してがちがちに仕事しすぎなのだと感じました。もっと肩の力を抜いていいんだと、認識させられました。
あとがき
思い立ってアウトプットしてみましたが、自分の言葉にすると改めて、変えていくべきだなと感じる部分が多々ありました。別の記事として以降の章で得られたマインドセットを書いていければと思います。