最近は殆ど本を読まなくなっていて、長期休暇があったときに1冊読むかどうかになっています。 お正月に読んだ本は「世界一流エンジニアの思考法」です。 自分がエンジニアをしていることもあり、発売当初から本屋を見て気になっていました。
筆者が米国のマイクロソフトに働いているということで、自分とはエンジニアとしてのジャンルも環境も違うのですが、 何か参考になればと思い読んでみました。
Kindleで読んで、メモをした部分を中心に書いていきたいと思います。
基礎の習得には時間がかかる
つまり、誰もが知っている「基礎」が身についていなかった。そして、「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」 ものなのだ。
自分のエンジニアとしての能力は低いと自覚していることもあるので、このあたりの項目には興味持って読むことができました。 内容としてはエンジニア以外にも通じると思うのですが、どんなに凄い人でも基礎の取得は大変ということで、ただ基礎ができていれば、いちいちAIに聞いたりググったりする必要がないのでコードを書く効率は良くなるというものです。
ポイントとしては、自分が新人だろうがベテランだろうが、うまくいってないものは「わかっていない」。基礎的なことがうまくできない段階で、下手に試行錯誤して自分流に考えてアレンジすると、かえってめちゃくちゃになって成功しない。王道を愚直に実行し、ゆっくりと基礎を理解しよう。
自分も基礎できていない部分多分にありそうなので、C#をもう少し見直してみようと思いました。
頼る
とくに 既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」というのはベストプラクティス だと思う。
これは私も意識していますが、プロジェクトが大きくなるにつれて、各機能の把握が難しくなります。 実際に操作している人に直接尋ねる方が効率が良い場合が多いでしょう。 大切なのは、こうしたやり取りをしやすくする環境を作ることです。
総じてイケてる技術者の人ほど、知らないことは知らないと素直に明かして気軽に質問する。これはアメリカのカルチャーによるところも大きいと思う。
相手の時間を取ることへの罪悪感や、基本的すぎる質問を恥ずかしく感じるなどの阻害要因をなくすことが求められます。 私自身も、自分の能力が低いと感じられるのを避けたいと思うことがあります。 しかし、プロジェクト全体の進捗と比較して考えれば、これらは些細なことです。プロジェクトの進捗のためならば、質問を恐れずに進むべきだと思います。
マネージャー
アメリカでは納期が近くなっても、「無理して機能を完成させなくていいから、品質の良いものをつくるようにしようよ」とマネージャから言われる。
マネジャーの主な仕事は、モチベーションを高めることだとされています。 スケジュール管理や具体的な作業指示は行わず、エンジニアが効率良く働けるような環境を考え、整える役割を担っています。
私は、スケジュール管理を含む裏方作業をしてくれることを非常にありがたいと感じています。 重要なのは、エンジニアが集中しやすい環境を共に創り上げることだと思っています。
プログラマたちがきちんと理解して実装できるようになれば、次からは開発が速くなる。 だからマネージャとしては急かさないことによって「未来への投資」をしているようにも見える。
スケジュールに関しては決まってはいるが、そこまで重視していないのがマネージャー（プロジェクト）のあり方が違いそう。 近視眼的な見方ではなく、遠い目で物事を見ているのではないかと思いました。
マルチタスク
会議の時間なんてたかが知れている。その間に内職したってやれることは限られているし、ほかの人からチャットが来ても、 30 分、１時間後にまとめて対応する時間をとれば十分早いレスポンスじゃないか？ 「マルチタスク」はしないほうが絶対に脳の生産性が高まる。
これは私の反省点の一つですが、自分に直接関係が少ない会議が設定されていることがあります。そうした場合、ただ出席するのではなく、意見を積極的に発言したり、議論に参加することに集中した方が良いと感じました。
記憶の定着
「後で人に説明する」ことを意識するだけでも、相当集中力や記憶力が向上する。準備もしなくていいので、これはとても楽だ。
ブログに書くことなど、記憶の定着方法については昔から色々な本に書かれているので、それをちゃんとやろうと言う話。 人に説明するレベルまでの理解は簡単ではないですが。
プルリクエスト
だが、PullRequestのレビューを減らすには、「読んだ人がどう感じるか？」を意識しながらコードを書く必要があった のだ。
自分もコメントたくさんいただくことが多いのですが、このあたり意識して書こうと思いました。 とりあえず機能として動くだけではなく、命名は正しいか、この変更でデグレの可能性ないかなど。
海外の人も気にするものはする
が、「In my opinion」。日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」 みたいなニュアンスだ。 このノリで話すと、たとえ相手のアイデアと正反対の意見でも、言われたほうが「心にぐさっとこない」感じになる。心が痛まないのだ。
海外で人々が率直に物を言うというイメージは、実際には皆が気を使い合っているということだそうです。 私も時には言いにくさを感じ、どのように伝えれば良いかといった余計な気遣いをすることがありますが、これはおそらく世界共通の状況なのでしょう。 意見を言う側も言われる側も、それをどう受け止めるかが難しいと感じます。
学習
「生産性を上げるためには学習だよ。だから、僕は仕事を定時ぐらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。ずっと仕事していると疲れるし、たとえ同じプログラミングでも、仕事と切り離したものはリラックスしてできるよね」
生産について、効率化など色々言われているが、このあたりの考え方は結構良いのではと思いました。
だから、アメリカではみんな「専門性を高める」という蓄積に価値が置かれ、スピードは思ったより重視されない。 結局は時間をかけて小さな努力を積み重ねるほうが圧倒的に良いものがつくれるのだから。
その他
引用する文章ないのですが、 私は新しい取り組みを始める際、とりあえず様々な方法を試してみることが多いのですが、これは実際には非効率で、優秀なエンジニアは、実際に手を動かす前に、推論を立てて十分な検討を行う時間を費やしているという点を知り、大変参考になりました。
