未熟なエンジニアである私が上司とぶつかって学んだこと
※ この記事はちょっと嫌な表現があるかもなので閲覧注意です。
※ この記事の内容はあくまで個人の感想です。
※ この記事は特定の誰かを責める意図はありません。
こんにちは。kubopです。
数年前のお話ですが、いろいろと問題があり、その時の経験を消化して次に学びとして活かさねばと思い、筆を取りました。
見る人によっては気分を害されてしまうかもしれません。
私はとある会社に未熟なジュニアエンジニアとして入社しました。
年齢的にポテンシャル枠で入社しており、かつこれ迄の経験的にSIerだったため、細かいWeb開発の知識がありませんでした。
元々はJavaを使っていて、その会社では新しい言語での開発となりました。
開発は行ってはいたものの、完全に我流。上流工程を担当することが多く、
デザインパターンの存在も知らない、SOLID原則もままならない、AWS何それ美味しいの？といった状況。戦力になる要因は一つも無かったですが、新しい環境で新しいことを学べることが楽しいという時期でした。（いわゆる未経験エンジニアに近いです。）
そんな中、入社してすぐに1つの機能の保守管理を担当しました。
裏側で動くバッチの保守管理、それに関する機能追加のプロジェクトにアサインされたのです。チームとしては実装担当が私1人、あとは上司がマネジメント、もう1人はSREがいる、といった体制です。
ペアプロやイントロダクションは特になく、チケットに書いてある内容を読み取り、既存コードを読み解いて実装していく、といった流れです。
当時の私は特にそこに問題点を感じずに、ひたすら新しい言語のコードを読み解いて必死にコードを書いて、自分で調べて追加していくといった仕事をしていました。
入社して1ヶ月程度で、大きめの新機能の開発のメイン担当をすることになりましたが、そのような状況でコードを書いていると、色々と問題がありました。
まず、PRへのコメントが400件近く頂くことがありました。
コードの静的解析、フォーマッターが存在しておらず、コードは上手く動作していてもインデントが1文字ズレていたりしていたのです。
当時の私は本当に開発のことを知らず、1PRで50file変更するみたいなえげつないビックバンリリースをしてしまっていたのも原因の一つでした。
（レビューする側も大変だったろうなぁ…
また、基本ソロでコーディングをしていたため、その機能に対する知見が私に集中してしまって誰にも引き継ぐことができず、38度の熱があっても納期通りにリリースしなければならなくなり、大変な思いをしました。
さらに、上司との折り合いが悪く、PRのレビューでは毎度ボコボコにされていました。
一言「ここはダメです」だけ書かれてしまってどこをどう直せば良いかわからない。
「インデント」「フォーマット」と、フォーマットのURLだけコメントが残されており、準拠するフォーマットのドキュメントのどの部分が違反しているのかわからない。
ほぼ動作確認が済んでいる状況で「そもそもここはこうしない方がいいです」とこれまでのコードをひっくり返されてしまう。
私の欠点である「わからないとおもったことを聞かないで自己解決しようとする」ということも相まってほぼ聞くことができませんでした。
私は当時ソフトスキル面でも未熟だったため、自分で調べて相手が求めるコードを書くしかありませんでした。
求められているコードは確かにあるのですが、ノーヒントで理想のコードにたどり着くしか無い、という状況です。
また、リリースが独特でリリース担当者にチケットを発行して、その内容通りにリリースを行ってもらう、という運用をしていました。
手順の明文化がされていなく、リリースごとにコマンドも異なるため、間違えてしまうことがありました。
その際は何故間違えたのか、何故出来なかったのかと問い詰められてしまうことがありました。
わからない事を聞いた際には、何故わからないのかを逆質問されてしまってなかなか聞くに聞けない状態、ということが常態化してしまっていて、どこに地雷があるかわからず、聞くこと自体が怖くなって萎縮してしまっていました。
話し合うという選択をしたのですが、「論理的では無い」と一蹴されてしまい、そこから「論理的とはなにか」と論理学に関する哲学書で学んだりしていました。
当然ですが、このような状況でミスが許されず、質問もできないとなると、ケアレスミスがどんどん増えていきます。
レビューで指摘されたことを、従順に想像で補填して直していくと自分が組み立てたロジックに穴が空いて意図しない挙動となってしまったり、
ケアレスミスを直そうとしてさらにケアレスミスを重ねてしまったりしていました。
さらに、そのケアレスミスについての原因分析と称してなぜなぜをして詰められてしまうということも起きました。
ある日では、1-2時間ほど個室でなぜ出来ないのか、ミスが起きたのか、今後どうすればいいのかを詰められることもありました。
また、私が入社してプロジェクトにアサインされてから開発速度が鈍化していると全体MTGで言われてしまっていたりして、自分の未熟さが皆んなに迷惑をかけてしまっている。と自責の念が日々高まり、さらにケアレスミスを起こし、信頼を無くしてしまうという最悪のスパイラルに陥っていました。
毎日焦りに焦っていて、動作確認が漏れていたり、QAとしての知見も無かった当時は本当に困っていました。
こんな中、なんとかしなければと解決策を考えていました。
まず、PRのレビューに工数がかかりすぎていて、「インデント」や「段落」といったコメントがこれまで数百件あることが調査の結果わかりました。工数で考えると、数十時間はそのコメントをするためだけに時間を割いていることが計算してわかりました。
そのため、まずはフォーマッターの導入をするべきではないかと提案しました。また、静的解析により一定のケアレスミスを無くせるのでは無いかと思い、CircleCIでの静的解析の導入調査をしました。
フォーマッターの選定にあたり、IDEの統一化、標準化をしなければならなかったため、エンジニアが利用しているIDEの調査、意識調査を開始しました。また、CircleCIをローカルで動作させ、静的解析が出来る状態にしました。
諸々の条件を揃えて提案したものの、答えとしては「却下」でした。
コストがかかりすぎるとのこと、他開発者からの賛同をうまく得られなかったからでした。特に上司からは反対されてしまい、やむなく断念しました。
それに伴い、インフラの知識をきちんと学び、今後リリースする際に適切に表現・指示できるようにしたいと提案しましたが、1on1で却下されてしまいました。
上司からは「そういうことを期待しているわけではない」と言われてしまい、何を求められているのかがわからない、何処を伸ばして良いかわからないという状態になってしまいました。
…
その数ヶ月後、なんとIDEが統一され、CircleCIが導入されることが決まりました。私はその話を一切聞かされていませんでした。
私が提案した後、全く別の場所で議論されていたようでした。
私はジュニアエンジニアで、ポテンシャル枠で、入社してから日も浅かったため参加する権限すらなかったのかもしれません。全く悪気がなかったのかもしれません。
ですが、かなりのショックを感じたのを覚えています。
導入のため、日々のタスクをこなしながら残業して私なりにかなり調査していました。それがあっさり通るということは、私のやったことはほぼ無駄だったという結論に自分で至ってしまいました。
このあたりで完全に心が折れてしまいました。
これ以上何かしても無駄だという気持ちに支配され、また自分の未熟さに苛立ちを覚えました。
そこから自らインフラ構築から、アプリケーション構築まで学び直そうというきっかけになり、自身でアプリケーションを開発して一通りのことを自分で出来るよう勉強しました。
…
かなり苦い思い出ですが、いくつか学びがありました。
開発者としては、
1PRはなるべく細かくする事。レビューしやすいコードにすること。
要件の擦り合わせは必ず、実装前に要件を握る事。
わからない、と思ったことは正直に聞くこと。わからない・未熟であることは悪いことではなく、学ばないのが悪だということ。
デザインパターン・SOLID原則など、押さえておくポイントはきちんとおさえて自己学習しなければならないということ。
動くものをきちんと素早く出して中間レビュー、確認会を設けたほうが早いということ。
ミスを無くすことはできない、QAをして予防することはできるが、その方法は学ばなければならないということ。
質問の仕方を気をつけること。WhyとWhatを明確に伝え、何が目的かがわかるようにすること。
受け身の開発では良くなく、レビュー通りに直すということは必ずしも良いこととは限らないこと。
HRT原則は大事。特に他者へのリスペクトが大事だということ。
コメントでは的確に、リスペクトをもってコメントすることがモチベーションや人との関係性に大きく関係すること。
全体としては、
コミュニケーションコストは最大限下げること。コミュニケーションのとりやすさこそ正義であるということ。
心理的安全性の欠如・詰めの文化は、開発スピードを鈍化させ、品質を落とすということ。
チームで開発を行う場合は、メンバー全員の納得感を重視したほうが効率的であること。
全体に関わる施策は、事前に少しずつ関連する人に伝えておき、課題抽出しながら丁寧に進めて行くこと。ビックバンで提案しないこと。
ペアプログラミングや、チームで進めて行くこと、知識を共有したり、ドキュメンテーションを書くということは、何より自分の身を守るということ。
人間は論理では納得しない。感情でものごとを決める、好きか嫌いかで決めること。
1人で抱え込まない。仲間を1人でいいから見つけること。
プロセスの標準化やルール化においては、違反した人を責めずシステムで解決できるように動くこと。
人に対する「なぜなぜ」は、場合によっては暴力になり得ること。
自分の性質としては、
自分の性質が、プロダクトコードというよりも仕事の進め方や組織に関することを考えることが好きだということ。
ドライなコミュニケーションの環境下ではなく、ウェットな環境でわいわいやることのほうが好きであるということ。
間に受けすぎると病むので、一旦課題は認識はしつつ受け取るかどうかは自分でコントロールしていくことが重要であること。
以上のことを、色々経験した上で学び、私の今の仕事のやり方やメンタルモデルに大きな影響を与えてくれました。結果として成長出来てよかったですが、当時はどんどん自分らしさを失っていき、元気がなくなっていました。
当時上司だった方も、こんな未経験エンジニアを雇ってめちゃくちゃ大変だったろうな…と今なら思えます。
たくさんご迷惑をおかけしてしまって、いまだに申し訳ない気持ちがあります。
当時はぶつかったりして、色々問題がありましたが、
どちらが悪い、というわけではなくて期待値のミスマッチという感じだったのかなぁと思います。
この記事が気に入ったらサポートをしてみませんか？