私の同僚に Y さんという人がいる。Y さんは30代後半、エンジニア歴は15年くらい。チーム内の評価は常に上位で、難しい設計判断はだいたい Y さんに集まる。新人からの信頼も厚い。
ただ、Y さんには面白い特徴がある。
- 勉強会には行かない（社内も社外も）
- 技術書はほとんど買わない
- 資格は基本情報すら持っていない
- 趣味で個人開発もしない
- Twitter で技術アカウントもフォローしていない
世間でよく言われる「成長するエンジニアの習慣」とされるものを、ことごとくやっていない。それなのに、Y さんは間違いなくチームで一番優秀なエンジニアの一人だ。
私はずっと不思議だった。Y さんは何をやって、その実力を維持しているのか。今日はその観察記録を書きたい。
観察1: 業務時間中の「読み方」が違う
Y さんと一緒に働いてみて、最初に気づいたのは「業務中の読み方」が他の人と全く違うことだった。
たとえば、新しいライブラリを業務で使うとき。普通のエンジニアは、必要な API のドキュメントだけを読んで、サンプルをコピペして使う。だが Y さんは、そのライブラリの README を全部読み、CHANGELOG を最新から3年分くらい遡り、GitHub の Issues で評価の高いものを上から10件くらい目を通す。これに30分から1時間かける。
私は最初、「それ、業務時間の無駄じゃないですか」と思っていた。だが Y さんを観察していると、あとで何かトラブルが起きたときに、Y さんは「ああ、それは去年の Issue で議論されてた件ですね」と即座に思い出す。30分の投資が、後から何時間もの調査時間を節約していた。
Y さんは勉強会に行かない代わりに、業務で触れるすべての技術を、その場で深く読む、という習慣を持っていた。これが Y さんの「学習」だった。
観察2: コードを読む量が異常
Y さんは、自分が書くコードよりも、他人のコードを読む時間のほうが圧倒的に長い。
具体的には、こんな感じだ。
- 朝の30分は、必ず前日のチームのプルリクを全部読む（自分がレビュアーでなくても）
- 自分が触る OSS ライブラリは、
node_modulesの中身を実際に開いて読む - 障害対応でログを見るとき、関連する周辺コードを「ついでに」読む
- 新しく入ってきたメンバーが書いたコードを、レビュー前に自分から読みに行く
Y さんに「なんでそんなに読むんですか」と聞いたとき、Y さんはこう答えた。
「自分で書くコードって、どうしても自分のクセが出るじゃん。新しい考え方を入れるには、他人のコードを読むのが一番早いんだよ。本を読むのと同じだけど、本より生々しくて勉強になる」
Y さんが本を買わない理由が、ここで分かった。Y さんにとって、業務で触れる「他人のコード」が本だったのだ。
観察3: 会話で学んでいる
Y さんはチームの中で、誰よりもよく雑談をする。コーヒーマシンの前、トイレの帰り道、昼休みの休憩室。
その雑談の中身を聞いていると、半分くらいは技術の話だ。だが「最新のフレームワークどう思う？」みたいな表面的な話ではない。「あの障害、なんで起きたんだっけ」「あの設計、結局正解だったと思う？」みたいな、過去の事例を振り返る話が多い。
Y さんは、チームメンバーの経験を、雑談を通じて自分の経験として吸収していた。これは勉強会に1日行くより、たぶん効率が高い学習だ。
観察4: 「考える時間」を意識的に作っている
Y さんを観察していて、もう一つ気づいたことがある。Y さんは1日のうち、明らかに「何もしていない時間」がある。
具体的には、午前と午後に1回ずつ、20分くらい、ぼーっとしているように見える時間がある。デスクに座って、画面を見ているわけでもなく、Slack を見ているわけでもなく、ただ椅子に深くもたれて天井を見ている。
最初、私は Y さんがサボっているのかと思った。だが、その「ぼーっとしている」時間の直後、Y さんは決まって何か新しい設計案を出してきたり、ずっと議論していた問題の解法を提示してきたりする。
Y さんは「ぼーっとしている」のではなく、意識的に「考える時間」を確保しているのだ、と気づいた。コードを書く時間、コードを読む時間、会話する時間、そして考える時間。これら全部を1日の中に意識的に配置している。
Y さんの哲学
ある日、Y さんと飲んだとき、私は思い切って聞いた。「Y さんって、なんで勉強会行かないんですか？本当に1冊も技術書買わないんですか？」
Y さんは少し笑って答えた。
「いや、興味がないわけじゃないんだよ。ただ、俺の経験上、勉強会で聞いた話って、業務で実際に使わないと1週間で忘れるんだよね。それなら、業務で実際に使うものを、業務時間中にじっくり学んだほうが、定着率が10倍くらい高い」
「本も同じ。本を1冊読み終える時間で、業務で触ってる技術のドキュメントを最後まで読んだほうが、たぶん仕事に直結する知識が入る。本を否定してるんじゃなくて、俺には本の効率が悪いってだけ」
「俺がやってるのは、勉強会行かないとか本読まないとか、そういう『やらないこと』じゃない。業務時間中の密度を異常に上げるってこと。だから業務時間外で勉強する必要がない、という結果になってるだけ」
これを聞いて、私は深く納得した。
結論
「勉強会行かない・本読まない・資格取らない」それでも評価される人の共通点は、たぶんこれだ。
業務時間そのものを、最強の学習機会として使い切っている。
業務時間に「ただ仕事をしている」エンジニアは、業務時間外に勉強しないと成長が止まる。だが、業務時間に「仕事しながら全力で学んでいる」エンジニアは、業務時間外の勉強を必要としない。
これはどちらが正しいという話ではない。私自身は今でも本を読むし、たまに勉強会にも行く。それは私の学習スタイルがそうだ、というだけの話だ。
ただ、もし「業務時間外に勉強する時間が取れない」と悩んでいるエンジニアがいるなら、Y さんのスタイルは一つの希望になるかもしれない。業務時間そのものを学習機会にする、というやり方だ。
Y さんは今日も、コーヒー片手にチームのプルリクを30分かけて読んでいる。それが Y さんにとっての「勉強」だ。