はじめに
今回は「世界一流エンジニアの思考法」を読んで、エンジニアが持つべきメンタルモデルについて考えてみます。
結構流行りの本なので、要約記事も多く存在しますが、個人的に重要だと感じた部分をピックアップして個人的な所感をまとめてみます。
「理解に時間をかける」を実践する
私たち職業プログラマは、日々新しい技術と対峙し、複雑な問題を解決するために努力しています。この過程でしばしば採用されるのが、「とりあえず動くものを作る」というアプローチです。
新しい技術に触れ、手を動かしながら理解を深めることは重要です。しかし、急ぎ足で開発を進め、理解が浅いままにしてしまうと、将来同じ技術を使う際に再び同様の問題に直面するリスクが高まります。
技術の基礎をしっかりと理解しておくことは、その技術を幅広く応用するための土台となります。また、一度しっかりと理解しておけば、後々になって都度調べる手間が減り、長期的に見れば時間の節約にもつながります。
「急がば回れ」ということわざが示すように、初期段階で時間をかけて理解を深めることが、結果的には効率的な道になると思います。
使用している言語やフレームワークに対する深い理解は、システム全体への理解を深めるのに役立ちます。しかし、実際には言語のドキュメントやフレームワークのソースコードをじっくりと読む機会は少ないかもしれませんがこれらの知識を習得し、理解を深めることに時間をかけることは、将来的に大きなレバレッジとなり、効果を発揮します。
基礎の理解を深めておくことは、エラーが発生した場合に原因を特定しやすくなるというメリットもあります。
プログラミングにおけるエラーは避けられないものですが、その背景にある原理を理解していれば、問題の解決に向けたヒントを得ることが容易になります。これは、プログラミングにおけるストレスの軽減にもつながり、より快適な開発を実現することができます。
プログラミングにおいて「理解に時間をかける」ことの重要性は非常に高いです。基礎をしっかりと理解することで、長期的な視点で見たときに効果的な開発が可能となります。
「Be Lazy」というマインドセット
「より少ない時間で価値を最大化するという考え方」だと紹介されています。
いわゆるエンジニアの三大美徳の1つ、「怠惰」ですね。
書籍の中では2-8の法則を引用して、全体の2割の仕事が8割の価値を生むのだから、その2割に集中すべきだと説明されています。(参考: パレートの法則)
個人的にこの考え方に沿って生きてきましたが、改めて言語化するととても重要度が高いなと感じます。
特に、定時を超えての残業が当たり前のような環境で働いていると、どうしても「時間をかければ何とかなる」という考え方になりがちですが、それは間違いです。
以前の職場では比較的残業が多かったのですが、今と比較すると明らかに自分の出せている価値は低かったと感じます。
その理由は、重要なことはどれなのかを見極めることができていなかったからです。全体のタスクのうち、納期を絶対に守るべきだという機能は自社開発の場合はそこまで多くはならないはずで、少なくとも見積もる段階で残業を前提にすることはないはずです。
それでも残業が常態化している場合は、やらない場合の影響が少ないタスクを無理に抱えている可能性が高いと思います。
個人的には残業は突発的なタスクに備えて避けておき、その分の時間を自己投資に使うことで、将来的な生産性に投資することが大事だと感じています。
本当に価値を出したいなら、自分の持っている時間とエネルギーを注力するタスクは1つに絞ることが大事です。
書籍の中では、タイムボックスという考え方が紹介されています。これは、1日のうち、何時から何時までとタスクにかける時間を決めておくというものです。
たとえタスクの途中でも、その時間になったら切り上げるようにします。この方法のメリットは複数あります。
- タスクにかける時間を明確にすることで、その時間内に集中できる
- 生産性を上げるための学習の時間を確保しやすい
- 脳を休める時間を確保しやすく、生産性の向上につながる
作者の体感ベースではあるので、個人差はあると思いますが、私自身も極力タイムボックスを意識して日々の業務を進めています。
ちょっとの残業、ちょっとの無理を当たり前にせず、しっかりと区切る習慣そのものが生産性を上げるための大事な要素だと感じています。
自己組織型チーム
書籍では、従来のリーダーシップと比較してサーバントリーダーシップを推奨しています。
違いとしては、従来の「コマンドアンドコントロール」制ではマネージャが部下に指示をする。「サーバントリーダーシップ」制ではメンバーが主体で動き、マネージャは彼らの障害を取り除く役割を担うというものです。
仕事を楽しみ、メンバーがそれぞれ自分の仕事と人生に対して責任を持つことができるような環境を作ることが大事だと感じます。
リーダーはメンバーに対して指示を出すのではなく、メンバーが自身でタスクを選択し、自分で進めていくなかで発生する障害を取り除くことに注力することが大事です。
これを実現するためには、リーダーに全責任があるというような従来の考え方を捨てて、メンバー全員が同じ責任をもつという意識作りをする必要があります。
メンバーは基本的にpull型、つまり必要な情報があればそれを知っている人から自ら情報を引き出す姿勢が求められます。
この姿勢は、価値を出すためには必要ですし、エンジニアとして成長するために必須の要素だと感じています。
書籍全体を通して、メンバーがそれぞれ主体的に動くことを重視していて、その環境作りの方法や文化づくりについても触れられていました。
運動習慣
あまりほかの要約記事で取り上げられていないんですが、運動習慣についても書かれていました。
個人的には、リモートワーク中心のエンジニアこそ能動的な運動習慣を持つことが大事だと感じています。
ブログを定期的に書きつつ、副業を始めたりこの一年間は自分の時間の使い方がかなり大きく変わりました。
その中で、新しく以下のような課題に直面しました。
- 肩こり
- 業務後に疲れが残っている
- 集中力が続かない
これらの課題を解決したのは、運動習慣を持つことでした。
特に、リモートワーク中心のエンジニアは、運動不足になりがちです。個人的に取り組んだのは、ジムの契約と季節によっては昼休みに散歩をすることです。
定期的な運動が必要で、筋トレ、有酸素運動はストレス緩和にもかなり効果がありました。また、マッサージ機の導入も肩こりに効果がありました。
自宅のデスク環境は整えているつもりでも、一日10時間以上同じ姿勢でいると、どうしても肩こりが発生します。長時間稼働できること、それを維持できることは重要ですが、その時間の質を高める工夫が必要です。
運動を阻害する要因を考えてみましょう
- 運動をする時間がない
- 運動を全くしていない場合、運動しはじめは30分も運動すればしんどいので捻出できます
- 運動をする場所がない
- 自宅でできる運動も多いです。特に筋トレは自宅でできます
- 運動をする習慣がない
- 自宅での運動が続かないのは、習慣化が難しいからだと思います。私の場合はジムを契約することで行かないともったいない状況を作りました。
運動習慣を持つことで、集中力が続く時間が増え、業務後の疲れが減りました。また、肩こりも解消され、業務に集中できる時間が増えました。
ただ、肩こりについては一時的に緩和されますが、根本の原因は姿勢の悪さなので、デスク環境への投資も重要です。
まとめ
- 理解に時間をかける
- Be Lazyの精神
- メンバーが主体的に動ける環境を作る
- 運動習慣を持つ
所感
結局のところ、著者のような周りの優れた人のいいところを観察し、自分に取り入れることのできる著者の姿勢が何よりエンジニアに必要なんじゃないかという気がします。
チームメンバー全員が目的を見失わないように、効果的な手段を考えて選択することのできる組織、環境をエンジニア自身が作り主体的に動くことが大事だと感じます。
エンジニアとして、より仕事や人生を楽しむためには時間の使い方にメリハリをつけ、健康的な生活を送ることが大事だと感じます。
職業エンジニアの場合はパフォーマンスを出し続けることが一番重要なので、学習の習慣はもちろん、仕事を楽しめているか、健康で過ごせているかという視点を常に意識していくことが大事だと感じました。
