こんにちは、やまです。
僕は今では月収100万円以上で設計や実装に苦を感じることが少なくなってきましたが、
駆け出しエンジニア時代はコードレビューされるのに常に緊張していました。
まだ設計を考えるのが不慣れだった頃、
レビューでの指摘が「自分の意見を否定された」と思ってしまい、よく落ち込んだのを覚えています。
- 「また指摘されるのが怖いな…」
- 「こっそりレビューが優しい人に依頼しようかな…」
そんなように考えていたこともありました。
ですが、今ではレビューを受けるのは「自分ではなく運用するチーム・組織のため」と考えているため、
怖いどころか、むしろより良い案があれば欲しいくらいに前向きに捉えられるようになりました。
皆さんにお伝えしたいのは、もし今レビューで緊張しても、むしろレビューを受け入れられるマインドになれるタイミングが来るということです。
レビューを前向きに捉えられるようになれたのは、大きく以下の3点が要因かと考えます。
- インプットとアウトプットを繰り返し、設計の知見を増やしたこと
- 設計に正解はないと知ったこと
- 視座が上がったこと
それぞれ詳しくお話ししていきます。
まず、「インプットとアウトプットを繰り返し、設計の知見を増やしたこと」についてです。
先述の通り、僕は昔はレビューを受けるのが苦手だったのですが、
その背景の一つが「なぜそう実装したか？」と聞かれても、「それしか思いつかなかった」と答えるしかなかったことでした。
それが悔しくて、歯痒く感じて、書籍を中心に設計を学び、実践を繰り返しました。10冊は読んだと思います。
インプットとアウトプットを繰り返すと、徐々に設計には複数のアプローチがあることを体得していきました。
書籍での学習に慣れてきたら、企業のテックブログでも様々な設計手法を学び、実際の開発で試すことを継続しました。
自分が出したバグや組織で起きた障害からの学び、
言語が変わっても当てはまるグッドパターンの習得といったことを繰り返すと、
「こう設計・実装してしまうと後で困りそう、不具合が出やすそう」と事前に想像できるようになりました。
次に「設計に正解はないと知ったこと」についてです。
先のように自分の中で設計の知見が増えてくると、あらゆる機能を実装するにも複数のアプローチがあることがわかってきました。
多くの場合、複数の案はそれぞれトレードオフの関係にあったり、メリット・デメリットが存在するものです。
そして、それらは既存部の設計・実装にも左右されるものでもあるため、一概にどれが正解とは言い切るのが難しいことが多いです。
そして、状況が変われば今はベストでも、将来的に最適なものが変わることだってあります。
よって、システム開発は「今の自分たちの状況からベストな案を選択する繰り返し」だということに気づいたことで、自分の選択を整理して説明する重要性を知ったのです。
例えば、ある機能の実装でA案とB案があった場合、
それぞれのメリット・デメリットを考慮し、なぜA案を選んだのかを説明できるようにしました。
設計の段階や実装にかかる前に複数案を自分の中で比較・検討し、それをレビューいただくメンバーに見ていただくようになりました。
コードレビューでの指摘も「なぜその選択をしたのか？」という建設的な議論に変わっていきました。
複数案の整理をたたき台として、より良い設計をチームで議論できるようになったと思います。
最後に「視座が上がったこと」についてです。
昔は自分のタスクレベルとしてしか設計や実装を捉えられていませんでしたが、
今は組織全体として最適なシステムを作ろうと考えられるようになったということですね。
駆け出しだったり、まだ活躍する・高収入なエンジニアの思考がわかる前の頃は、
いかに自分のタスクを上手く終わらせるかが考えの中心でした。
しかし、既にフリーランスエンジニアとして評価が高く、月単価も100万円超の方から活躍でき、高収入なエンジニアの考え方を学ぶことで、タスクを組織目線で捉えるようになっていきました。
自分の設計がチームや組織全体に与える影響を理解するようになり、
例えば、ある設計変更が他のモジュールやチームメンバーにどのような影響を与えるかを考慮するようになりました。
コードレビューでの指摘も「全体最適」を意識した建設的なフィードバックとして受け入れられるようになったのです。
組織レベルで設計を考える習慣がつくと、「是非やまさんにお願いしたいです！」とサービスの根幹を担う機能の設計に関わる開発にアサインいただくことも多くなってきました。
今回は、設計に自信が持てずコードレビューに緊張していた時期の乗り越え方についてお話ししてきました。
昔は設計に自信がなく、コードレビューに怯えていた僕でも、
設計の学びと実践の繰り返しや、設計に正解はないと知ったこと、
そして、視座が上がり、設計で成果を出せるようになってきたことで、
今ではコードレビューを前向きに捉えられるようになりました。
もし、今同じようにコードレビューに苦手意識を持つ方がいらっしゃれば、
学びと実践の日頃の積み重ねが大切なので、1日2日でとはいきませんが、必ず恐怖はなくなるタイミングが来るので安心してほしいと思います。
お話ししたように視座を上げる努力も大切です。
自分のタスクだけでなく、チーム・組織全体を意識して設計・実装に取り組むことで、
コードレビューも建設的な議論として受け入れられるようになっていくと思います。
「サービスを伸ばすための運用を見越した設計」を考えられるエンジニアはどの現場でも重宝されるので、
日頃の自己研鑽を大切にしていきましょう！
今回、お話しした設計のインプットを含め、僕が実務経験5年でベテランのエンジニアマネージャーの方から評価をいただけるまでにしてきたことについてお話しする動画もあるので、もしよろしければ合わせてご覧ください！
また、メルマガもやっており、活躍する・評価され、高収入なエンジニアになるための考え方を発信しています！
こちらももし興味があれば、是非チェックしてみてください！