最近X(Twitter)でよく見かけて気になっていた本だったので読んでみました！
本を読み終えて、特に印象に残ったことを書きたいと思います。
米マイクロソフトで働かれている牛尾さんが書かれた本で、世界一流のエンジニアが集まるマイクロソフトで彼らがどのような思考で働いているのかが書かれています。
試行錯誤は「悪」である
エラーが起きた際や不可解な事象が起きたときに、むやみに試行錯誤するのではなく起きた事象から仮説を立て、それについて検証するという内容です。
個人的にこれは結構グサッと刺さりました。
直近もアプリケーションで不可解なエラーが続いていたときにひたすら試行錯誤しましたが、結局解決できず時間だけが溶けてしまいました。
本書でも書いてありますが、問題は『何も成長していない』点です。
時間をかけて何か新しい知識を習得していれば最悪良いかもしれませんが、今回私は何も得られませんでした。
一方でまず仮説を立て、アプローチを選定してから動くという方法は一定数、それなりの知識や経験も必要だなと思いました。
仮説を立てるための知識が不足していると仮説が立てられなかったりするので、そのためにも日頃からインプットは大事だなと感じました。
頭が良くても「理解」には時間がかかる
マイクロソフトにいる強強のエンジニアでも複雑な内容を理解するには時間がかかるという内容です。
本書で書かれてい『理解』の定義は以下の3つでした。
- 説明可能
- いつでも使える
- 応用可能
これを読んで「知ってる、できる、やってる」の違いの話を聞いたことを思い出しました。
なんとなくどういう技術か知っていても、じゃあ人に説明してくださいと言われたときに言葉に詰まることは多々ありそうです。
そういう点でアウトプット前提でインプットすることの重要性を感じました。
理解には時間がかかるものとして急がず徹底的に理解する習慣を持つということが書かれていて意識してやろうと思いました。
小さなドキュメントをコードの前に書く
設計書などという仰々しいものではなくてもワード数ページに設計のアイデアや大まかな仕様を書くことが良いという内容です。
これは最近ちょうど実践して良かったなと思ったことです。
ドキュメント書くことで自分の中でも頭が整理されますし、他のメンバーに仕様を説明するときも書いたものをシェアするだけで済むので効率的だなと思いました。
まずエキスパートに頼る
1つの解決しないことで時間費やすなら相談して他の仕事をやっておくほうが生産性が高いという内容です。
聞いてしまって解決できるならわからないことで時間を費やすよりチーム全体の効率はアップするなと思います。
無駄なことをせず肝心なことにフォーカスするという考えは非常に参考になりました。
しかし、これを実現するにはまず気軽に聞いても良いという雰囲気作りや関係性を持って置くことが大事だなと感じました。
「Be Lazy」というマインドセット
実際にだらけろという内容ではなく、より少ない時間で価値を最大化するという内容です。
タスクの中から優先順位をつけて高いものから対応するのではなく重要なものを「1つ」だけ選び対応するという話でした。
自分は要望として上がってきたものはすべて対応しようとして、本当にそれが「価値」が高いものかは考えていませんでした。
このマインドは自分にインストールしておきたい内容でした。
いかにやることを減らすか？
いかにやることを減らすかを実現するための手順が書かれています。
- １つだけピックアップする
- 時間を固定して、できることを最大化する
- 「準備」「持ち帰り」をやめてその場で解決する
- 物理的にやることを減らす
個人的にはどれもあまり実施できていない内容でした。
特に持ち帰りは結構癖でやってしまっていてMTG等で仕様を検討するときは持ち帰りますと言ってしまうことが多いので改善しようと思いました。
リスクや間違いを快く受け入れる
まずやってみて、早くフィードバックを得て、早く間違いを修正していこうという内容です。
今の時代、検討ばかりしてさっさとやらないことのほうが最大のリスクだということを肝に銘じてほしいと書いてあり、グサッと刺さりました。
ちょうど自分に当てはまる内容で、仕様を検討していてああだこうだ言っていましたが、その時間がもったいないのでAでやってみてだめだったらBにしようと考えを持っておくべきでした。
もちろんフィードバックを歓迎するムードを作る必要はありますが、Fail Fastの精神は取り入れようと思いました。
マルチタスクは生産性が最低なのでやらない
今手についている仕事を１つにしようという内容です。
書いてある中で印象的だったのが、会議時間なんてたかが知れているのでその間に内職してもやれることは限られているという箇所です。
まさに自分に当てはまる内容でまさにMTG中にエディターを開くことがありました。
これを読んでからはMTGに集中して議事録とるなりして内容を誰かに説明できるように理解しようという姿勢で取り組んでます。
生産性を上げたければ定時上がりが効率が良い
生産性を上げるには学習が必要で、そのためには定時に上がって時間をつくろうという内容です。
仕事ばかりしていても短期的なアウトプットは上がったように見えても根本的な生産性が上がっているわけではないと書かれていたのが印象的でした。
どうしても残業して終わらせようという考えで、あまり定時に上がることを意識していませんでしたが改めようと思います。
実際学習に当てる時間は残業することでほとんど取れていなかったので、時間内に仕事を終わらせることを意識し学習に時間を当てようと思いました。
最後に
個人的にこのタイミングで読んでよかったと思う本でした。
アメリカのエンジニアの話なので、文化的な違いなどでこの本に書かれている内容をすべて実践できるわけではないですが、取り入れられる部分も多々あるなと思いました。
１つのことに集中したり、小さなドキュメントを書いたりすで取り入れているものもあります。
自分だけこの思考法をインプットして実践してもできることは限られているのでチームメンバーにも紹介しようと思いました。
コメント