こちらの記事は、Mitchell Irvin 氏により2019年1月に公開された『 What I Learned in My First Two Years as a Software Engineer 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。
以下は、ソフトウェアエンジニアとして最初の2年間働いた後の2つの物語、学んだこと、後悔していること、そして目標です。
大学と職場
2015年、私はフロリダ大学の学生でした。 その間、私は教授の下で勉強していました。その教授は、おそらく学科の中で最も難しいと思われるクラスを担当していて、学期を通して複数のチームベースのプロジェクトを割り当てていました。 各プロジェクトの最後に、教授は各学生を個別に評価します。 次のプロジェクトがやってきたとき、この教授は以前の課題からの最高の学生と自分のチームの最悪の学生を集めました。 学期の終わりまでに、各学生は強力なチームへの道に入れるように頑張り成功したか、または低パフォーマンスのメンバーが集まったチームに入ってしまい失敗するかのどちらかでした。 素晴らしいものでした。 強者は弱者に足を引っ張られる状況を強いられませんでした、そして、弱者は強くなるか死ぬかのどちらかでした。 この環境は、実力主義という言葉で適切に説明できます。 このシステムは、最も才能のある学生が報われて、一生懸命働いていない学生が自分の船で沈むことを可能にしました。 私はそれが好きでした。
一年後、私は卒業しました。 この4年間勉強してきた分野で、元気で、理想を持って、自分のものにしようと思っていました。 インターンシップ後、評判の良い大企業でソフトウェアエンジニアのオファーをもらいました。 私は初日、素晴らしいソフトウェアエンジニアになりたい気持ちに満ち溢れていました。
私は、リソース不足のプロジェクトで仕事を始めることになりました。 私たちは、ほとんどのWebアプリケーションと同じようなWebアプリケーションを構築していました。データを公開し、ユーザーがそれを操作できるようにするのです。 私は他に2人のエンジニアと開発を担当し、1人の品質保証エンジニアがテスト側を担当していました。
ほんの数か月たつと、私がすべてを支え続けるキーストーンになっていると思うようになりました。 ユーザーが新しい機能の実装を望んでいる？ 私がなんとかします。 ふりかえりをしてくれる人が必要? もちろん私がやります。 私なしでは、ほとんど何も動かない状況にあるということがすぐに分かりました。 22歳のとき、私はフォーチュン25の会社で主任エンジニアの役割を果たしていました。
しかし、ちょっと待ってください...1年近くも大部分のウェイトを背負っていたにもかかわらず、私の給料は経験豊富なチームメンバーが家に持ち帰る給料の何分の一かでした。 私が「A」をとっているというわけでも、彼らが「F」をとっているというわけでもありませんでした。 ストックオプションはありませんでした。 休暇もあまりありませんでした。 私は何を手に入れているのでしょうか？ これらのことに気づくのに長い時間はかからず、欲求不満を表に出すようになるまですぐでした。 ソフトウェアに慣れていないエンジニアとペアを組むとき、私は忍耐強く、助けになるチームメイトになるように努めました。 私の無関心が膨れ上がり、私の生産性は急落しました。 私が別のエンジニアとペアを組んで、彼らのペースで動いた場合（たとえ私のペースの5％であっても）、私はまだ仕事をしてるといえるでしょうか？
こんな感じで最後の3ヶ月を過ごし、ちょっとした土壇場でプロジェクトは最後の休息地に着地しました。 チームの士気は低下していました。 この14か月の活動の最高潮を実際に祝った人は誰もいませんでした。 さらに重要なことは、チームメイトの何人かは将来再び一緒に仕事をするという見通しに興奮しないだろうことを分かっていました。 自分の職場環境に対する態度が、自分自身や周りの人たちにどれほど悪影響を及ぼしているかを実感し始めました。
数週間後、私はチームメイトとしてどのように改善できるかについてフィードバックを求めるアンケートを送信しました。 調査の結果、1つのことが明らかになりました。 パフォーマンスがすべてではないのです。 私のキャリアを歩み始めてから、学校で高く評価していた能力主義の黄金の基準は、職場で支持される基準と同じであると思っていました。 強者には適切な報酬があり、弱者には迅速な正義があります。 この認識は、他人とうまく仕事をする能力、他人の貢献に感謝する能力、謙虚に学ぶ能力、忍耐強く教える能力を蝕んでいました。 人々の（私に対する）認識は、「彼はパフォーマンスに集中しすぎている」になりました。
教訓1：同僚との関係（対人/リーダーシップスキル）と技術力（ハードスキル）も同様に重要です。 優れたソフトウェアエンジニアになるには、何年にもわたって技術を磨く必要があります。
時間の経過とともに、ダニングクルーガーチャートのプロットを上下に移動し、再びバックアップします。 進むにつれて、間違いを犯し、他の人から学び、知識を共有します。 あなたはあなたの技術分野で強みを持っているに違いません。 ただし、これが唯一の強みである場合、不幸になるでしょう。 あなたの目標が可能な限り最高のソフトウェアエンジニアになることである場合、その旅は可能な限り最高のチームメイト（そしておそらくリーダー）になることの追求を含まなければなりません。 これは、自分と同じくらいあなたの周りの人々を優先することから始まります。
私が今まで働いた中で最高のエンジニア
9月のある朝、2人の新しいフリーランサーが私たちのチームに加わりました。 私たちのチームは規律としてペアプログラミングを追求しているので、私は結局、「ペアリングステーション」で2人のフリーランサーのうちの1人の隣に座り、その日の作業を開始することにしました。 次の7時間ほどの間に、このエンジニア（彼をボブと呼ぶことにします）が質問しました。 新しい機能に取り組んでいるときに、ボブは使用していた言語とフレームワークについて質問しました。 ビジネスルールの詳細を修正しているときに、ボブはそのプロダクトと私たちが解決しようとしていた問題について質問しました。 その日、ボブはコードをあまり書きませんでした。 その日の終わりに、ボブには少しがっかりしました。 私は彼のエンジニアとしてのスキルに大きな期待を抱いており、彼が私から学ぶことができる誰かであることを望んでいました。
翌日、ボブと私は別の機能の作成に取り組みました。 私がその機能の最初のテストケースを書いて、それを実行し、すべての緑のチェックマークが画面に表示されたとき笑みがこぼれました。 ボブは物思いにふけって見ていました。 テストが終わった後、彼はテストされたメソッドのあるファイルを開き、1〜2行変更しました。 私は反対し始めました。「ちょっと待って！ その動作は正しくありません。」 彼はうなずき、それからテストケースの実行を再開しました。 すべてのテストは合格していました。 私は驚きの声をあげました。
ボブと私がペアプログラミングを続けてから、数週間が過ぎました。 私たちが仕事に取り掛かる間、彼は質問を続けました。 私が操作しているときに（キーボード/マウスでアクティブに）彼は提案をし始め、彼が適切だと思ったタイミングで自分で操作するために介入してきました。 彼は私たちのフレームワークと言語の内部の仕組みについて、私のいくつかの質問に答え、私が知らないオブジェクト指向デザインパターンを紹介してくれました。 ドメインと私たちのビジネス問題に関する彼の質問は、私たちのソフトウェアに穴を開け始めました。 彼は私たちのコードのバグと欠陥を明らかにしました。私一人ではそれらのバグは存在しないと約束できたでしょう それでも私はそれらのバグを見ることできました。明白にです。 時間が経つにつれ、ボブと私は彼が発見したバグを解決し、ソフトウェア設計の防弾対策を行い、ビジネス上の問題とコードとの関係を大幅に改善しました（詳細については、ドメイン駆動設計のユビキタス言語のアイデアを参照してください）。
私たちのチームの会話では、ボブは誰かが間違っていると思った時にはその人を威圧したりしませんでした。 彼は質問しました。 質問に答えていくうちに、ボブがずっとどこにいたか(私が思うに)を知ることがよくありました。 チームが行ったほぼすべてのソフトウェア関連の決定の中心に、ボブの質問がありました。 ボブはチームへの貢献を主張しませんでした。 彼は自分のスキルをエンジニアとして言及したことはありません。 ペアプログラミングしているときにタイピングに実際に費やした時間は気にしていなかったようです。 ボブは私が今まで働いた中で最高のエンジニアです。
教訓２：他人に影響を与える能力は、自分がしたのと同じ結論に相手が到達するのを手助けする能力によって最も顕著に決まります。
ボブは「これが私たちがすべきことであり、なぜそうするのか」ということはほとんど述べていません。 彼は検討中の他のアイデアについて質問しました。 ほとんどの会話が終わる頃には、彼の質問のおかげで検討中のほとんどのアイデアが排除されるようになっていました。 ところで、ボブは全て完璧なアイデアを持っていたというわけではありませんでした。 非常に多くの場合、彼は彼の質問の１つに対する答えを見つけて、「良い点です。 それで行きましょう。」というようなことを言っていました。 しかし、彼は私たちのチームの推論に影響を与える強力な能力を持っていたため、私たちのソフトウェアの品質に最良の影響を与えることができました。 それでも、彼は自分の考えを共有するよりもはるかに多くの時間を質問に費やしました。
教訓３：解決策を考え始める前に多くの質問をするのは、偉大な問題解決者の証です。
ソフトウェアエンジニアとしての私たちの中心にあるのは問題解決です。 何か新しいことを学ぶことは、問題を解決することです。 コーディングは解決すべき問題です。 コミュニケーションも解決すべき問題です。 優れたソフトウェアエンジニアは優れた問題解決者であり、優れた問題解決は、質問をして問題を理解することから始まります。 質問することは、他の人のアイデアを尊重することを示します。 質問することは、他の方法では理解することが難しいことを理解するのに役立ちます。 質問することで、答えを共有するときにその答えが適切である確率が向上します。 最も優れた解決策を思いつく人は、問題を理解するために時間をかけた人なのです。
ボブについて最後に一言。 彼は頼みの綱としてチームをリードするのに十分な技術的才能を持っていました。 彼が望めば彼は建築家になることができると私は確信しています。 彼はそうしません。 ボブはコードを書くのが好きです。 ドメイン分析をするのが好きです。 ビジネスオブジェクトの設計と堅牢なテストスイートの作成が好きです。 高品質のソフトウェアを提供するのが好きです。
振り返り
私の最初の2年間は冒険でした。 私はソフトウェアを作り、ソフトウェアを壊し、そしてソフトウェアを修正してきました。 私は文字通り、人々がテーブルで眠ってしまうような会議に参加したこともあります。 何度か舌打ちされたことがあります（よく未来の自分に）。 私は喜びと苦しみをすべて纏って、仕事に身を投じました。
振り返ってみると、次のような後悔があります
- 人より仕事を優先させることが多かったということ。 仕事（プロダクト）は常になんとかなります。 ただし、人間関係を修復および維持するのははるかに困難です。
- 検討して調べるのではなく、周囲を見渡すのに時間を使ってしまったということ。 他の人が改善できることにあなたが集中することでは、あなたはより良いチームメイトにはなることはできません。 あなたは自分の弱点と長所を認識することによってより良いチームメイトになれます。
- 耳を貸すべきだったときに私が喋るのに時間を使ってしまったということ。 自分が話しているときに、より賢くなったり、他者に共感を得たりすることはできません。
- 私が何かに不満を感じていて、リーダーに率直に正直にそれを伝えなかったこと。 問題が何であるかを知らなければ彼らは助けることはできません。
- AngularJSの学習に費やした時間。 RIP。
あなたが一生懸命努力し、自分がしている仕事に関心があるなら、誰かの癪にさわるようなことをしてしまうことがあるでしょう。 あなたはおそらく誰かを怒らせるでしょう。 あなたは常に失敗するでしょう。 その時は、人を第一に考えましょう。 責任を持ち、誠意をもって謝罪し、前進してください。 これを行う能力は、「ソフトウェアエンジニア」で頭打ちになる個人と、最終的には業界のリーダーになる個人との違いです。 余談ですが、あなたが一緒に働いている全ての人について多くの 批判を私に話すことができるのであれば、おそらくあなたは前者ですが、あなたやあなたのパフォーマンスについて間違いだと言っているわけではありません。
私が前進するとき、ここに心の底にあるものがあります：
- 目標：可能な限り最高のソフトウェアエンジニアになること。 それは千マイルの旅であり、それは一度に一歩ずつ起こります。
- 目標：最高のチームメイトになる。 最高のエンジニアであることは、私がポジティブな関係勢力でなければ、ほとんど意味がありません。 チームの結束は個々の才能を打ち負かします。
- 目標：優先順位を維持する。 ソフトウェアは、神との関係、結婚、友情、健康よりも重要ではありません。 あなたの最優先事項は何かを考えてください。 私はそれらのいずれかを犠牲にしてより「生産的」になるつもりはありません。
2年前、私が考える最高のソフトウェアエンジニアになるためにこの道のりを歩み始めました。 私は以前よりもはるかにゴールに近くなり、自分がゴールからどれだけ遠くにいるのかをはるかに意識できるようになりました（ゴールは本当にあるのでしょうか？）。 この記事に書いた話や考えは、その旅の一部を表しています。 運良く、これらの教訓が何らかの形であなたの人生のお役に立てますように。
翻訳協力
Original Author: Mitchell Irvin
Thank you for letting us share your knowledge!
この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: @r_pg10
翻訳担当: @r_pg10
監査担当: @_masa_u
公開担当: @r_pg10
ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。Twitterでもご意見を受け付けております。
みなさまのメッセージをお待ちしております。