最初に開発業務をする時に知っておきたかった50のことPart1

はじめに

本記事は、ソフトウェアエンジニアとして働く方が、エンジニアになったばかりの人に向けて書いた海外コラムの和訳です。
新しい環境に身を置いて仕事をしていくにあたって、先輩からの助言には耳を傾けるべきでしょう。
無論、その全てに従い実行せよ、という事はありません。ですが「なるほど、こういう事が起こり得るのか」と予め知っておくことで、遠回りしたり、ネガティブに考え込んでしまうことを避けられるかもしれませんよ。

序文

もし私が時間を巻き戻して、数週間前の、フルタイムソフトウェアエンジニアとして初めて働き始める時に戻れるのなら、自分自身に伝えたい５０のことがあります。ここにそれを述べます。

ひょっとすると、その中にはあなたにとってしっくりこないものもあるかもしれませんが、お気になさらず。
これは私自身のためのリストなのです。しかしながら、あなたも若い頃のあなたへ何かアドバイスしたいことがあれば、ぜひ、SNSなりブログなりで発信してください。

１）大体の人は「手助けしてあげたい」と思っている

一般的に、あなたを陥れようとしている人は、いません。あなたの同僚や知人は、あなたの成功を手助けしたいと考えています。
他の開発者のことを信用し、助けが必要な時には頼る、というのはとてもよい考えです。

私自身にとても役立った経験則のひとつが、「他人は最善の思いを持っている、と思って接する」です。

２）テストはあなたの友達

テストを書くことは、常に楽しいとは限りません。しかし、私の最初の業務においては、私のテストスキルの構築にものすごく役に立ちました。
まず、テストを書くことは、何かしらの解決したい課題への取り組み方のメンタルトレーニングに、びっくりするほど効果的です。タスクを完了させるにあたって、ステップ毎に考える必要があるからです。
次に、テストを書くことで、「自分が書いたコードが、想定した通りに動く」という安心感を得ることができます。
このトレーニングによって、私は最初の頃のプルリクエストに自信を持つことができました。

３）誰も、自分が何をやっているか知らない

私は、最初の仕事において、インポスター症候群に苦しんでいました。（注：自分の成功を肯定できず、「自分は偽物だ、詐欺師だ」と思い込んでしまうこと）
その原因の根本は、「私の周りの人々皆が、私よりも技術に詳しい」と信じ込んでいることにありました。

私の考えは誤っていて、どんなプロジェクトにも、関わった人それぞれが苦しんで取り組んだ箇所があるのです。

４）自分が何をやっているか、理解している人もいる

プロジェクトのいくつかの箇所が、開発者にとって難しい、チャレンジングな内容であるということに関してですが、それらの箇所は、チーム内の何人かの開発者にとっては習熟できるであろう内容です。

そういった人を見つけ出して、その人に学び、その人の専門分野において私が苦しんでいるところを質問する。
このことは、プロジェクトにおいて私が快適に作業できる環境を構築するのに大いに役立ちました。

５）オープンソースは怖くない

オープンソースは、生活のためソフトウェア開発を始めた頃の私にとってものすごく恐ろしいものでした。
もしあの頃、オープンソースは全く怖いものではない、ということを知っていたら、もっと早く成長できたでしょう。
（そして私のキャリアにとても良い影響を与えてくれたでしょう・・・）

６）あなたの憧れの人も、ただの人間

「憧れの人には実際に会わない方がよい。何故なら失望するから」と、人々は言います。
私は敢えて、「憧れの人には積極的に会うべき。何故なら、彼らもただの人間であることが分かるから」と主張します。
私は、半年～7か月を、自分の憧れの人に会う極めて重要な時間に費やしました。
そこで私が気付いたことは、私が尊敬している人も、私と同じような人間であり、私が苦しんでいるような事と全く同じことに悪戦苦闘しているのだ、ということです。
この一致に気付いて、私は、チャレンジすること・憧れの人のように振る舞うことを恐れなくなりました。
もし彼らが私が抱えているのと同じ問題で苦しんでいたら、彼らのことを称賛せずにはいられません。

７）全てを把握する必要は、ない

ソフトウェアエンジニアリングは、不条理なほど複雑なもので、訓練法も多岐にわたります。
今現在その全容理解している、または将来理解する人間は、地球上に存在しません。言うまでもなく、チャレンジする必要もありません。

私は最初の仕事で、自分の知識の無さにショックを受けました。しかし、自分の知らない事全てに注力するよりも、
いずれかを選んで、それを本気で習得するのに時間を費やすべきでした。そして、学ぶ時間が無いものについては、より良い機会が訪れるまでいったん無視するべきでした。

８）”深さ”は”広さ”に勝るかもしれない

この考えを持ち続けるために、時には何かについてものすごく熟知することは、とてつもない価値を持つことがあります。
私はこのことを、継続して取り組んでいるオープンソースプロジェクトから学びました。

９）”広さ”は”深さ”に勝るかもしれない

一方で、世間はジェネラリストを求めています。あなたのプロフェッショナルとしての目標によっては、幅広い知識を持つことは、大変重要な資産となり得ます。

私の現在の仕事、マネジメント業務に関するものですが、それにおいては、無関係な情報群をうまく吸収するという私の能力はとても重宝されています。
また、その幅は、私に新しいことを学ぶための強固な基盤を与えてくれました。

１０）シンプルなコードはよいコード

あまりに多くの初学者（かつても私自身も含め）が、複雑なコードは強い印象を与えるものだと思い込んでいます。

しかし、最も良いコードというのは、シンプルで理解しやすいものです。コードが複雑で分かりづらいものであるとき、それを理解できないあなたに非はありません。そのコードを書いた人間に非があります。

自分自身を責めるような考えを持たないようにしましょう。

１１）あなたの仕事は、学ぶこと

この事実は、数多くのインターン生や新卒社員と一緒に働いた時に直面したものです。仕事をしながら学ぶ事について罪悪感を抱く必要はありません。それが、仕事なのですから。

熟練した人たちでさえ、仕事において、チュートリアルを読んだり新たなスキルを学んだりするのに膨大な時間を費やしているのです。あなたも、業務時間内にそれらをやっていくべきです。

１２）第一原理は、暗記よりも優れている

暗記することは大いに役に立ちます。私も実際、反復練習で自信をつけました。
しかしながら、対象のコンセプトによっては、暗記は常にベストな学習法とは言えないのです。

もし私が、使用した技術に含まれるアプローチの背景にある「理由」を学ぶことに時間を使っていたら、
それは、直面した課題を解決するための適切な戦略を決定する事に大いに役立っていたことでしょう。

１３）「今何を学んでいるのか」を書こう

私がソフトウェアエンジニアについて積極的に何かを書くことを始めたのは、本当にごく最近のことです。
その結果は顕著なものでした。情報を常に効果的に保持しておくことができ、そしていつでも書面で参照できるようになったからです。

これは、私がクリス・オリバー氏にインタビューした際に話をされたことでもありますが、あなたが学んでいることをプライベートなままにしておくのは、全くもって無意味です。
あなたが書き記したノートはシェアし、あなたの考えはブログなりdev.toなりで公表しましょう。

最低でも、何か技術的なことを思い出す時に参照できるオンラインの場所を持つことができます。
あるいは、最もラッキーな事に、あなたの書いたことが誰かの助けになり、名前を覚えてもらうことで何らかの利益を得る、ということがあるかもしれないのです。

１４）コードレビューに対して、遠慮しない

コードレビューまたはペアプログラミングをやっている時、例え正しくないとしても、あなたは自分の意見を共有すべきです。

理由の一つは、それによってあなたのチームが書いているコードの質が向上する可能性があるからです。また、あなたの同僚にメンターシップを与える機会にもなるかもしれません（例え同僚が先輩であっても）。

二つは、あなたが間違っていた場合、それを正す機会を得られるからです。あなたはこれを「よい機会」と捉えるべきです。例え相手が無礼であっても、あなたは希望の光を見出し、そこから何かを学ぶ事ができるのです！

１５）ペアプログラミングの舵取りを行う

ペアプログラミングのシチュエーションにおいて、最も経験の浅い開発者は、キーボードにかじりつくべきだと強く感じます。私の最初の仕事において、熟練の開発者をキーボードから遠ざけることで、多大な恩恵を受けた経験は数えきれないほどあります。初学者がペアプログラミングを行うにあたっての「恩恵」とは2通りの意味があります。

まず、初学者がペアプログラミングの主導を担っている時、熟練の開発者に各ステップを説明する必要があります。
尚、その説明によって、熟練者がコンテキストや背景知識を共有したくなるようなものである必要があります。

2つ目は、この訓練は、イライラした熟練開発者が、何十行にも渡るコードを説明なしに書き出すという不可避の事態を緩和することができます。
発生していた問題がどのように解決したのかの説明が全くないまま熟練開発者が作業を続ける事ほど、最悪な事はありません。熟練開発者が、知識をケチケチ小出しにするのを許してはいけません。教える事は、彼の仕事の内だからです。

１６）壊れてもいいオモチャを作る

プログラミングを職業として始めた時、私は便利なソフトウェアを作ることに注力していました。

しかし結果として、何も作り出すことができませんでした。何故なら、他の人が使うことが出来るようなものを作る準備が全く出来ていなかったからです。

重要なものを壊すことを恐れずに、ハッキングに適したシンプルなプロジェクトさえ作成していれば、遥かに速いスピードで学ぶことが出来ていたでしょう。そして、将来役に立つものを作ることが出来ていたでしょう。

１７）休息を取る

脳を休めましょう。この仕事は、効率よく考えることが全てです。週に90時間も働くのは、効率の良い思考に寄与しません。

１８）エクササイズ

休息をとるのと同じくらい、エクササイズはあなたの脳の健康にとても良いものです。
これは、私が最初の仕事の時に見落としていたことであり、私は対価を支払いました。体調不良、不規則な睡眠サイクル、気持ちが常に不安な状態・・・これらはすべて、運動をしない事によって引き起こされたものだったのです。

私は過去、色々とオススメされました。もし高負荷な運動が苦手で、ゆったりと体を動かしたい時は、ディスクゴルフにチャレンジしてみてください。
もし課題解決に取り組んでいる最中でしたら、インドアボルダリングはとてもオススメです。
もし脳のストレッチをしたり、集中力を高めたいなら、長距離ランをやってみましょう。
最近、私はムエタイボクシングに取り組んでいるのですが、実践的な運動をしたい方にはうってつけです。

１９）リファクタリングに固執しない

私は、完璧なコードを書こうとすることに時間を費やしすぎました。
初学者にとっては、パーフェクトなコードを書くことは仕事ではありません。一緒に働く同僚に、「とりあえずのクオリティ」のコードを見てもらいましょう。そうすれば、彼らはそのコードを良くするためのアドバイスをくれるはずです。

２０）失敗したことを書き記す

私は、自分が失敗した事を書き記すことをやり始めるのに、ものすごく時間がかかりました。
自分の失敗（と、それらの失敗を避ける為の手順）を記録しておくことは、同じ失敗を繰り返さないために役立ちます。

２１）自分の成果を書き記す

同様に、自分の成果を記録しておくことも必要です。が、理由は異なります。
インポスター症候群に立ち向かう最も良い方法のひとつは、キャリアの中であなたができる全ての素晴らしい事を思い出すことです。

例えば、プロダクトにおいてあなたが書いて実行したコード、プロセスまたはドキュメンテーションに対して行った改善、あなたが構築した仕組みの自動化などです。それらのすべては価値のあるものであり、そしてあなた自身も価値のある開発者であることを思い出させてくれるものでもあります。

２２）メンターを探すことはカンタン

私が最初に働き始めた時、「メンターとは正式な取り決めをしなくてはならない」と思っていました。
私は、週に一度ぐらいの頻度で自分の懸念事項を相談できるベテランエンジニアを探していました。
そうした関係は価値あるリソースになり得ますが、必須のものではありません。

後に学んだことですが、メンターというのはもっと砕けた関係でよいのです。私のpodcastのゲストの皆さんが、私にとってのメンターです。

私には、数か月に一度会ってコーヒーを飲むような友人が何人かいますが、全てのメンターと定期的に面談する必要はないと考えます。属するコミュニティの中で何人かを見つけ、30分、時間をもらえないかと尋ねてみましょう。
そこまで学べることの多さに驚くと思いますよ。

２３）メンターの専門家になる必要はない

初学者は、メンターであるべきです。

私がソフトウェアの開発において初学者だった頃、「メンターになる為にはある程度の専門性が必要だろう」と常に感じていましたが、厳密にはそれは誤りでした。

勿論、JavaScriptで何も作ったことが無い状態で、Reactについて語る事にチャレンジしてはいけません。
しかし、全てを知らなくても周囲の誰かを助けることは出来ます。

あなたが知っている事を、周りの人と共有する機会を探しましょう。それが「私の見つけたクールなエディタープラグイン」というような事でも良いのです。他の人と共有するという行為が、メンターという役割をこなす事の快適さを促進させてくれるのですから。

２４）「分かりません」と口に出すことは、良い発信

多くのエンジニアが、ある何かについて自分に知見がないと認めることを恐れています。
私は、キャリアの中のある段階でついに、学ぶ事とは無知を認めることだ、と気付いたのです。

分からないことを分からないと認めることで、気持ちを楽にしましょう。そして、周囲の人が、あなたが作り出したそのきっかけに追従する頻度にびっくり仰天することでしょう。
また、運が良ければ、多少知識がある人があなたに教えてくれるかもしれません。

２５）まだ、という言葉を忘れない

自分にとって「分からない」アドバイスについてのフォローとして、何であれ「まだ」と付け加えることを忘れないようにしてください。
個人的に、「yet(まだ）」という言葉は、英単語の中でも最もパワフルなものだと思っていて、もしあなたがそれを正しく使えば、自分自身に嫌気が指すような時でも、あなたを励ましてくれるかもしれません。

「今はまだ、分かりません。」
「今はまだ、満足していません。」
「今はまだ、オープンソースに貢献できていません。」

このマインドセットによって、自分の職業との関係が根本から変わりました。
この価値を、最初の仕事の時に知っていたらなぁ、と思う次第です。

まとめ

いかがでしたか。
エンジニアになったばかりの頃は誰しも、分からないことだらけで悩み、手が止まってしまうものです。
ですが記事の通り、それは誰しもが通る道。周りと自分を比べて落ち込むことはありません。

記事の中で、「自分の失敗したことを書こう」という項目がありましたが、これは、

• 書くために自分の頭の中を整理するので、改めて理解が深まる
• Web上に公開することで、同じようなエラーが起きて困っている人にとっての助けとなり得る

というように、良い事づくめです。
とはいえ、公式ドキュメントのような堅苦しく詳細なものである必要はありません。
「自分用のメモを書こう」というくらいの軽い気持ちで書くから始めてみてはいかがでしょうか。

本記事が、読者の皆さまにとって、エンジニアとしての仕事に注力する助けになれば幸いです。

＼　ログインしなくても検討機能が使える♪　／

新着のエンジニア案件を見てみる