ソフトウェアエンジニアとして安定した成果を出したいと思っている人は多いでしょう。妥当な方針を危なげなく定め、素早く的確に実装し、滞りなく仕事を片付けていきたいものです。しかし、いつでもそのように成果を出せるようになるのは簡単ではありません。言語、ミドルウェア、クラウド、アーキテクチャと、身につけるべき知識が無限に並んでおり、それら全てに習熟する日は永遠に来ないとすら思えてきます。
にもかかわらず、この記事を読むみなさんの同僚には、安定して成果を出せるエンジニアが相当数いるだろうとも思います。これは一体どういうトリックなのでしょう。彼ら彼女らは全てを勉強しているのでしょうか。もちろんそれに近い研鑽を積んでいる人もいるでしょうが、多くの人はそこまでしていないと予想します。少なくとも僕はそこまでやっていませんが、技術面でもそこそこバリューを出して、テックリードを1年勤め上げました。この記事では、もう少し再現性高く安定した成果を出していく方法について、自分の経験に基づいて議論します。
安定して成果を出せるようになる方法
その方法とは、自分が面倒を見ているシステムのコードをとにかくたくさん読むことです。そしてそれによって、「真似をしたら平均点が出せる」という無難なやり方のメンタルモデルを構築することです。
現実のソフトウェア開発は真似の連続です。ミクロには、HTTPのクエリパラメータの処理の仕方や、RDBから取得したデータをモデルにマッピングする方法といったもの。もう少しマクロには、非同期に処理を行う方法や、どのようにキャッシュをするかといった話題もあるでしょう。既にそのシステムがある程度の規模で動き続けているのなら、こうしたやり方をゼロから考える機会は思いのほか少ないものです。それどころか、既存のやり方を無視したコードは全体の一貫性を損なうため、ゼロから考えるのは望ましくないとすら言えるでしょう。
既に動いているコードというのは素晴らしいものです。様々な無難な(少なくとも動く)処理の仕方を教えてくれるだけでなく、パフォーマンスやリソース効率の観点でも実績があります。チームメンバーが見慣れたコードになるのでレビューもスムーズに進みます。真似をすることで、そうした信用情報を自分の仕事にも適用できます。これほど頼もしいことはありません。既存のコードと比較して優れたり劣ったりすることはなく、"平均点"と呼ぶにふさわしい成果物ができるでしょうが、これが安定した成果を形成する重要なパーツだと考えます。
真似から始めて大きな成長へ
コードを読んで真似して手札を増やすことは、単に仕事を上手く進める以上の利益をもたらします。「こうやったらうまくいくんだな」という具体例をひとつでも持つことで、エンジニアとしての思考に重要な広がりが生まれます。
ひとつは、新旧、優劣といった技術の質に関する広がりです。何か未知の概念に出会ったとき、「自分たちが使っているものと比べてどうであるか」という視点で見て、自分の中で位置付けられるようになります。その概念を単に上から下まで見るよりもずっと深い理解を得られるでしょう。
もうひとつは抽象度に関する広がりです。何か抽象的な知見を前にしたとき、そこに自分たちのやり方を当てはめてみて考えることができます。実際に当てはまるにしても、当てはまらないにしても、その思考実験から多くの示唆を得ることができるでしょう。単に言葉尻を追いかけるよりもずっと楽しい学びになるはずです。
よく、技術書の内容を覚えていないとか、読むのが大変といったことが界隈の話題に上がりますが、こういった点と関係があるようにも思います。上で紹介したような思考の広がりの中で目にした情報は高い強度を持ちます。忘れる忘れないといった次元の心配とは無縁で、自転車の乗り方のように体に身に付きます。こうした構造を狙っていくと自己効力感を持って楽しく学ぶことができるかもしれません。個人的な体験としても、社会人になって面倒を見るシステムができてからの方が技術の勉強をするのが楽しく感じます。
テックリードへの道
ここまで議論したことは、「テックリードになるにはどうしたら良いか」という問いにもよく答えています。テックリードの要件は色々ありますが、その中でも多くの場面で無難な方針を出す能力はとても重要だと思っています。信頼度が高くひとまず動く方針は、叩き台やセーフティネットとしてとても優秀で、ソフトウェア開発の健康な進行につながります。これは基本的には、システムのコードをたくさん読み、何度も真似し、システムを深く理解することで得られる能力です。
以前、自分のメンターから「テックリードの『理由はうまく言えないけど危なそう』はだいたい合っているから自信を持って」と言われたことがあり、これも近いことを言っていると気づきました。テックリードは既存のシステムで上手くいっている方法をよく知っているので、まだ言語化できるほどの理解が及んでいないにしても、そこから外れたときに違和感をキャッチできるのではないかということです。もちろん既存のやり方が100%正しいとは限りません。それでも、既存のシステムが持つ信用情報を適用できないことを認識するのは有益です。
また、そうしたメンタルモデルがよく構築されていることで、筋の良い変化にも踏み出すことができます。技術の質に関する相対感を獲得し、よい技術選択ができるようになるでしょう。単に選ぶだけでなく、チームの現状からどれくらいギャップがあるのかを認識することで、変化のためのアプローチをうまく構築できるはずです。また、具体と抽象に関する広がりを獲得し、説得力のある説明で他のメンバーを導けるようになります。より発展的な仕事を志向するにしても、既存のシステムに関するメンタルモデルが頼もしい踏み台になるでしょう。
まとめ
この記事では、自分の経験を元に安定して成果を出すための近道について考えました。面倒を見ているシステムのコードをよく読み、チームの無難なやり方のメンタルモデルをよく構築することが、安定して成果を出す近道であるという議論を展開しました。単に既存のコードの信用情報に裏打ちされた仕事ができるだけでなく、さらなる学びやリードの踏み石としても機能することが期待できます。成長したいのに伸ばし方が分からない時は、素朴に目の前のシステムに100%の力を注いでみると道が開けるかもしれません。